diff options
| author | Martyn Welch <martyn.welch@ge.com> | 2012-05-03 12:36:54 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-05-08 19:01:34 -0400 |
| commit | cc4729826fd1a478f235fbcf58c0f97663f8d7e3 (patch) | |
| tree | 6941470e83d0dd00882e7ce020027b5494ad3ab0 /drivers/vme | |
| parent | a11cfdf4589f2f9f70d398d123c459d33dfc6bb2 (diff) | |
VME: Move API documentation to Documentation folder
The documentation for the VME device driver API is currently in
drivers/vme/vme_api.txt, move this to Documentation/vme_api.txt
Signed-of-by: Martyn Welch <martyn.welch@ge.com>
Acked-by: Rob Landley <rob@landley.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/vme')
| -rw-r--r-- | drivers/vme/vme_api.txt | 396 |
1 files changed, 0 insertions, 396 deletions
diff --git a/drivers/vme/vme_api.txt b/drivers/vme/vme_api.txt deleted file mode 100644 index 856efa35f6e3..000000000000 --- a/drivers/vme/vme_api.txt +++ /dev/null | |||
| @@ -1,396 +0,0 @@ | |||
| 1 | VME Device Driver API | ||
| 2 | ===================== | ||
| 3 | |||
| 4 | Driver registration | ||
| 5 | =================== | ||
| 6 | |||
| 7 | As with other subsystems within the Linux kernel, VME device drivers register | ||
| 8 | with the VME subsystem, typically called from the devices init routine. This is | ||
| 9 | achieved via a call to the following function: | ||
| 10 | |||
| 11 | int vme_register_driver (struct vme_driver *driver); | ||
| 12 | |||
| 13 | If driver registration is successful this function returns zero, if an error | ||
| 14 | occurred a negative error code will be returned. | ||
| 15 | |||
| 16 | A pointer to a structure of type 'vme_driver' must be provided to the | ||
| 17 | registration function. The structure is as follows: | ||
| 18 | |||
| 19 | struct vme_driver { | ||
| 20 | struct list_head node; | ||
| 21 | const char *name; | ||
| 22 | int (*match)(struct vme_dev *); | ||
| 23 | int (*probe)(struct vme_dev *); | ||
| 24 | int (*remove)(struct vme_dev *); | ||
| 25 | void (*shutdown)(void); | ||
| 26 | struct device_driver driver; | ||
| 27 | struct list_head devices; | ||
| 28 | unsigned int ndev; | ||
| 29 | }; | ||
| 30 | |||
| 31 | At the minimum, the '.name', '.match' and '.probe' elements of this structure | ||
| 32 | should be correctly set. The '.name' element is a pointer to a string holding | ||
| 33 | the device driver's name. | ||
| 34 | |||
| 35 | The '.match' function allows controlling the number of devices that need to | ||
| 36 | be registered. The match function should return 1 if a device should be | ||
| 37 | probed and 0 otherwise. This example match function (from vme_user.c) limits | ||
| 38 | the number of devices probed to one: | ||
| 39 | |||
| 40 | #define USER_BUS_MAX 1 | ||
| 41 | ... | ||
| 42 | static int vme_user_match(struct vme_dev *vdev) | ||
| 43 | { | ||
| 44 | if (vdev->id.num >= USER_BUS_MAX) | ||
| 45 | return 0; | ||
| 46 | return 1; | ||
| 47 | } | ||
| 48 | |||
| 49 | The '.probe' element should contain a pointer to the probe routine. The | ||
| 50 | probe routine is passed a 'struct vme_dev' pointer as an argument. The | ||
| 51 | 'struct vme_dev' structure looks like the following: | ||
| 52 | |||
| 53 | struct vme_dev { | ||
| 54 | int num; | ||
| 55 | struct vme_bridge *bridge; | ||
| 56 | struct device dev; | ||
| 57 | struct list_head drv_list; | ||
| 58 | struct list_head bridge_list; | ||
| 59 | }; | ||
| 60 | |||
| 61 | Here, the 'num' field refers to the sequential device ID for this specific | ||
| 62 | driver. The bridge number (or bus number) can be accessed using | ||
| 63 | dev->bridge->num. | ||
| 64 | |||
| 65 | A function is also provided to unregister the driver from the VME core and is | ||
| 66 | usually called from the device driver's exit routine: | ||
| 67 | |||
| 68 | void vme_unregister_driver (struct vme_driver *driver); | ||
| 69 | |||
| 70 | |||
| 71 | Resource management | ||
| 72 | =================== | ||
| 73 | |||
| 74 | Once a driver has registered with the VME core the provided match routine will | ||
| 75 | be called the number of times specified during the registration. If a match | ||
| 76 | succeeds, a non-zero value should be returned. A zero return value indicates | ||
| 77 | failure. For all successful matches, the probe routine of the corresponding | ||
| 78 | driver is called. The probe routine is passed a pointer to the devices | ||
| 79 | device structure. This pointer should be saved, it will be required for | ||
| 80 | requesting VME resources. | ||
| 81 | |||
| 82 | The driver can request ownership of one or more master windows, slave windows | ||
| 83 | and/or dma channels. Rather than allowing the device driver to request a | ||
| 84 | specific window or DMA channel (which may be used by a different driver) this | ||
| 85 | driver allows a resource to be assigned based on the required attributes of the | ||
| 86 | driver in question: | ||
| 87 | |||
| 88 | struct vme_resource * vme_master_request(struct vme_dev *dev, | ||
| 89 | u32 aspace, u32 cycle, u32 width); | ||
| 90 | |||
| 91 | struct vme_resource * vme_slave_request(struct vme_dev *dev, u32 aspace, | ||
| 92 | u32 cycle); | ||
| 93 | |||
| 94 | struct vme_resource *vme_dma_request(struct vme_dev *dev, u32 route); | ||
| 95 | |||
| 96 | For slave windows these attributes are split into the VME address spaces that | ||
| 97 | need to be accessed in 'aspace' and VME bus cycle types required in 'cycle'. | ||
| 98 | Master windows add a further set of attributes in 'width' specifying the | ||
| 99 | required data transfer widths. These attributes are defined as bitmasks and as | ||
| 100 | such any combination of the attributes can be requested for a single window, | ||
| 101 | the core will assign a window that meets the requirements, returning a pointer | ||
| 102 | of type vme_resource that should be used to identify the allocated resource | ||
| 103 | when it is used. For DMA controllers, the request function requires the | ||
| 104 | potential direction of any transfers to be provided in the route attributes. | ||
| 105 | This is typically VME-to-MEM and/or MEM-to-VME, though some hardware can | ||
| 106 | support VME-to-VME and MEM-to-MEM transfers as well as test pattern generation. | ||
| 107 | If an unallocated window fitting the requirements can not be found a NULL | ||
| 108 | pointer will be returned. | ||
| 109 | |||
| 110 | Functions are also provided to free window allocations once they are no longer | ||
| 111 | required. These functions should be passed the pointer to the resource provided | ||
| 112 | during resource allocation: | ||
| 113 | |||
| 114 | void vme_master_free(struct vme_resource *res); | ||
| 115 | |||
| 116 | void vme_slave_free(struct vme_resource *res); | ||
| 117 | |||
| 118 | void vme_dma_free(struct vme_resource *res); | ||
| 119 | |||
| 120 | |||
| 121 | Master windows | ||
| 122 | ============== | ||
| 123 | |||
| 124 | Master windows provide access from the local processor[s] out onto the VME bus. | ||
| 125 | The number of windows available and the available access modes is dependent on | ||
| 126 | the underlying chipset. A window must be configured before it can be used. | ||
| 127 | |||
| 128 | |||
| 129 | Master window configuration | ||
| 130 | --------------------------- | ||
| 131 | |||
| 132 | Once a master window has been assigned the following functions can be used to | ||
| 133 | configure it and retrieve the current settings: | ||
| 134 | |||
| 135 | int vme_master_set (struct vme_resource *res, int enabled, | ||
| 136 | unsigned long long base, unsigned long long size, u32 aspace, | ||
| 137 | u32 cycle, u32 width); | ||
| 138 | |||
| 139 | int vme_master_get (struct vme_resource *res, int *enabled, | ||
| 140 | unsigned long long *base, unsigned long long *size, u32 *aspace, | ||
| 141 | u32 *cycle, u32 *width); | ||
| 142 | |||
| 143 | The address spaces, transfer widths and cycle types are the same as described | ||
| 144 | under resource management, however some of the options are mutually exclusive. | ||
| 145 | For example, only one address space may be specified. | ||
| 146 | |||
| 147 | These functions return 0 on success or an error code should the call fail. | ||
| 148 | |||
| 149 | |||
| 150 | Master window access | ||
| 151 | -------------------- | ||
| 152 | |||
| 153 | The following functions can be used to read from and write to configured master | ||
| 154 | windows. These functions return the number of bytes copied: | ||
| 155 | |||
| 156 | ssize_t vme_master_read(struct vme_resource *res, void *buf, | ||
| 157 | size_t count, loff_t offset); | ||
| 158 | |||
| 159 | ssize_t vme_master_write(struct vme_resource *res, void *buf, | ||
| 160 | size_t count, loff_t offset); | ||
| 161 | |||
| 162 | In addition to simple reads and writes, a function is provided to do a | ||
| 163 | read-modify-write transaction. This function returns the original value of the | ||
| 164 | VME bus location : | ||
| 165 | |||
| 166 | unsigned int vme_master_rmw (struct vme_resource *res, | ||
| 167 | unsigned int mask, unsigned int compare, unsigned int swap, | ||
| 168 | loff_t offset); | ||
| 169 | |||
| 170 | This functions by reading the offset, applying the mask. If the bits selected in | ||
| 171 | the mask match with the values of the corresponding bits in the compare field, | ||
| 172 | the value of swap is written the specified offset. | ||
| 173 | |||
| 174 | |||
| 175 | Slave windows | ||
| 176 | ============= | ||
| 177 | |||
| 178 | Slave windows provide devices on the VME bus access into mapped portions of the | ||
| 179 | local memory. The number of windows available and the access modes that can be | ||
| 180 | used is dependent on the underlying chipset. A window must be configured before | ||
| 181 | it can be used. | ||
| 182 | |||
| 183 | |||
| 184 | Slave window configuration | ||
| 185 | -------------------------- | ||
| 186 | |||
| 187 | Once a slave window has been assigned the following functions can be used to | ||
| 188 | configure it and retrieve the current settings: | ||
| 189 | |||
| 190 | int vme_slave_set (struct vme_resource *res, int enabled, | ||
| 191 | unsigned long long base, unsigned long long size, | ||
| 192 | dma_addr_t mem, u32 aspace, u32 cycle); | ||
| 193 | |||
| 194 | int vme_slave_get (struct vme_resource *res, int *enabled, | ||
| 195 | unsigned long long *base, unsigned long long *size, | ||
| 196 | dma_addr_t *mem, u32 *aspace, u32 *cycle); | ||
| 197 | |||
| 198 | The address spaces, transfer widths and cycle types are the same as described | ||
| 199 | under resource management, however some of the options are mutually exclusive. | ||
| 200 | For example, only one address space may be specified. | ||
| 201 | |||
| 202 | These functions return 0 on success or an error code should the call fail. | ||
| 203 | |||
| 204 | |||
| 205 | Slave window buffer allocation | ||
| 206 | ------------------------------ | ||
| 207 | |||
| 208 | Functions are provided to allow the user to allocate and free a contiguous | ||
| 209 | buffers which will be accessible by the VME bridge. These functions do not have | ||
| 210 | to be used, other methods can be used to allocate a buffer, though care must be | ||
| 211 | taken to ensure that they are contiguous and accessible by the VME bridge: | ||
| 212 | |||
| 213 | void * vme_alloc_consistent(struct vme_resource *res, size_t size, | ||
| 214 | dma_addr_t *mem); | ||
| 215 | |||
| 216 | void vme_free_consistent(struct vme_resource *res, size_t size, | ||
| 217 | void *virt, dma_addr_t mem); | ||
| 218 | |||
| 219 | |||
| 220 | Slave window access | ||
| 221 | ------------------- | ||
| 222 | |||
| 223 | Slave windows map local memory onto the VME bus, the standard methods for | ||
| 224 | accessing memory should be used. | ||
| 225 | |||
| 226 | |||
| 227 | DMA channels | ||
| 228 | ============ | ||
| 229 | |||
| 230 | The VME DMA transfer provides the ability to run link-list DMA transfers. The | ||
| 231 | API introduces the concept of DMA lists. Each DMA list is a link-list which can | ||
| 232 | be passed to a DMA controller. Multiple lists can be created, extended, | ||
| 233 | executed, reused and destroyed. | ||
| 234 | |||
| 235 | |||
| 236 | List Management | ||
| 237 | --------------- | ||
| 238 | |||
| 239 | The following functions are provided to create and destroy DMA lists. Execution | ||
| 240 | of a list will not automatically destroy the list, thus enabling a list to be | ||
| 241 | reused for repetitive tasks: | ||
| 242 | |||
| 243 | struct vme_dma_list *vme_new_dma_list(struct vme_resource *res); | ||
| 244 | |||
| 245 | int vme_dma_list_free(struct vme_dma_list *list); | ||
| 246 | |||
| 247 | |||
| 248 | List Population | ||
| 249 | --------------- | ||
| 250 | |||
| 251 | An item can be added to a list using the following function ( the source and | ||
| 252 | destination attributes need to be created before calling this function, this is | ||
| 253 | covered under "Transfer Attributes"): | ||
| 254 | |||
| 255 | int vme_dma_list_add(struct vme_dma_list *list, | ||
| 256 | struct vme_dma_attr *src, struct vme_dma_attr *dest, | ||
| 257 | size_t count); | ||
| 258 | |||
| 259 | NOTE: The detailed attributes of the transfers source and destination | ||
| 260 | are not checked until an entry is added to a DMA list, the request | ||
| 261 | for a DMA channel purely checks the directions in which the | ||
| 262 | controller is expected to transfer data. As a result it is | ||
| 263 | possible for this call to return an error, for example if the | ||
| 264 | source or destination is in an unsupported VME address space. | ||
| 265 | |||
| 266 | Transfer Attributes | ||
| 267 | ------------------- | ||
| 268 | |||
| 269 | The attributes for the source and destination are handled separately from adding | ||
| 270 | an item to a list. This is due to the diverse attributes required for each type | ||
| 271 | of source and destination. There are functions to create attributes for PCI, VME | ||
| 272 | and pattern sources and destinations (where appropriate): | ||
| 273 | |||
| 274 | Pattern source: | ||
| 275 | |||
| 276 | struct vme_dma_attr *vme_dma_pattern_attribute(u32 pattern, u32 type); | ||
| 277 | |||
| 278 | PCI source or destination: | ||
| 279 | |||
| 280 | struct vme_dma_attr *vme_dma_pci_attribute(dma_addr_t mem); | ||
| 281 | |||
| 282 | VME source or destination: | ||
| 283 | |||
| 284 | struct vme_dma_attr *vme_dma_vme_attribute(unsigned long long base, | ||
| 285 | u32 aspace, u32 cycle, u32 width); | ||
| 286 | |||
| 287 | The following function should be used to free an attribute: | ||
| 288 | |||
| 289 | void vme_dma_free_attribute(struct vme_dma_attr *attr); | ||
| 290 | |||
| 291 | |||
| 292 | List Execution | ||
| 293 | -------------- | ||
| 294 | |||
| 295 | The following function queues a list for execution. The function will return | ||
| 296 | once the list has been executed: | ||
| 297 | |||
| 298 | int vme_dma_list_exec(struct vme_dma_list *list); | ||
| 299 | |||
| 300 | |||
| 301 | Interrupts | ||
| 302 | ========== | ||
| 303 | |||
| 304 | The VME API provides functions to attach and detach callbacks to specific VME | ||
| 305 | level and status ID combinations and for the generation of VME interrupts with | ||
| 306 | specific VME level and status IDs. | ||
| 307 | |||
| 308 | |||
| 309 | Attaching Interrupt Handlers | ||
| 310 | ---------------------------- | ||
| 311 | |||
| 312 | The following functions can be used to attach and free a specific VME level and | ||
| 313 | status ID combination. Any given combination can only be assigned a single | ||
| 314 | callback function. A void pointer parameter is provided, the value of which is | ||
| 315 | passed to the callback function, the use of this pointer is user undefined: | ||
| 316 | |||
| 317 | int vme_irq_request(struct vme_dev *dev, int level, int statid, | ||
| 318 | void (*callback)(int, int, void *), void *priv); | ||
| 319 | |||
| 320 | void vme_irq_free(struct vme_dev *dev, int level, int statid); | ||
| 321 | |||
| 322 | The callback parameters are as follows. Care must be taken in writing a callback | ||
| 323 | function, callback functions run in interrupt context: | ||
| 324 | |||
| 325 | void callback(int level, int statid, void *priv); | ||
| 326 | |||
| 327 | |||
| 328 | Interrupt Generation | ||
| 329 | -------------------- | ||
| 330 | |||
| 331 | The following function can be used to generate a VME interrupt at a given VME | ||
| 332 | level and VME status ID: | ||
| 333 | |||
| 334 | int vme_irq_generate(struct vme_dev *dev, int level, int statid); | ||
| 335 | |||
| 336 | |||
| 337 | Location monitors | ||
| 338 | ================= | ||
| 339 | |||
| 340 | The VME API provides the following functionality to configure the location | ||
| 341 | monitor. | ||
| 342 | |||
| 343 | |||
| 344 | Location Monitor Management | ||
| 345 | --------------------------- | ||
| 346 | |||
| 347 | The following functions are provided to request the use of a block of location | ||
| 348 | monitors and to free them after they are no longer required: | ||
| 349 | |||
| 350 | struct vme_resource * vme_lm_request(struct vme_dev *dev); | ||
| 351 | |||
| 352 | void vme_lm_free(struct vme_resource * res); | ||
| 353 | |||
| 354 | Each block may provide a number of location monitors, monitoring adjacent | ||
| 355 | locations. The following function can be used to determine how many locations | ||
| 356 | are provided: | ||
| 357 | |||
| 358 | int vme_lm_count(struct vme_resource * res); | ||
| 359 | |||
| 360 | |||
| 361 | Location Monitor Configuration | ||
| 362 | ------------------------------ | ||
| 363 | |||
| 364 | Once a bank of location monitors has been allocated, the following functions | ||
| 365 | are provided to configure the location and mode of the location monitor: | ||
| 366 | |||
| 367 | int vme_lm_set(struct vme_resource *res, unsigned long long base, | ||
| 368 | u32 aspace, u32 cycle); | ||
| 369 | |||
| 370 | int vme_lm_get(struct vme_resource *res, unsigned long long *base, | ||
| 371 | u32 *aspace, u32 *cycle); | ||
| 372 | |||
| 373 | |||
| 374 | Location Monitor Use | ||
| 375 | -------------------- | ||
| 376 | |||
| 377 | The following functions allow a callback to be attached and detached from each | ||
| 378 | location monitor location. Each location monitor can monitor a number of | ||
| 379 | adjacent locations: | ||
| 380 | |||
| 381 | int vme_lm_attach(struct vme_resource *res, int num, | ||
| 382 | void (*callback)(int)); | ||
| 383 | |||
| 384 | int vme_lm_detach(struct vme_resource *res, int num); | ||
| 385 | |||
| 386 | The callback function is declared as follows. | ||
| 387 | |||
| 388 | void callback(int num); | ||
| 389 | |||
| 390 | |||
| 391 | Slot Detection | ||
| 392 | ============== | ||
| 393 | |||
| 394 | This function returns the slot ID of the provided bridge. | ||
| 395 | |||
| 396 | int vme_slot_get(struct vme_dev *dev); | ||
