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