]> git.proxmox.com Git - mirror_ubuntu-artful-kernel.git/blob - drivers/staging/vme/vme_api.txt
staging: vme: add struct vme_dev for VME devices
[mirror_ubuntu-artful-kernel.git] / drivers / staging / vme / vme_api.txt
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 char *name;
22 const struct vme_device_id *bind_table;
23 int (*probe) (struct vme_dev *);
24 int (*remove) (struct vme_dev *);
25 void (*shutdown) (void);
26 struct device_driver driver;
27 };
28
29 At the minimum, the '.name', '.probe' and '.bind_table' elements of this
30 structure should be correctly set. The '.name' element is a pointer to a string
31 holding the device driver's name. The '.probe' element should contain a pointer
32 to the probe routine.
33
34 The arguments of the probe routine are as follows:
35
36 probe(struct vme_dev *dev);
37
38 The device structure looks like the following:
39
40 struct vme_dev {
41 struct vme_device_id id;
42 struct vme_bridge *bridge;
43 struct device dev;
44 };
45
46 The 'bridge' field contains a pointer to the bridge device. The 'id' field
47 contains information useful for the probe function:
48
49 struct vme_device_id {
50 int bus;
51 int slot;
52 };
53
54 'bus' is the number of the bus the device being probed is on. 'slot' refers
55 to the specific slot on the VME bus.
56
57 The '.bind_table' is a pointer to an array of type 'vme_device_id':
58
59 struct vme_device_id {
60 int bus;
61 int slot;
62 };
63
64 Each structure in this array should provide a bus and slot number where the core
65 should probe, using the driver's probe routine, for a device on the specified
66 VME bus.
67
68 The VME subsystem supports a single VME driver per 'slot'. There are considered
69 to be 32 slots per bus, one for each slot-ID as defined in the ANSI/VITA 1-1994
70 specification and are analogious to the physical slots on the VME backplane.
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
93 struct vme_resource * vme_master_request(struct vme_dev *dev,
94 vme_address_t aspace, vme_cycle_t cycle, vme_width_t width);
95
96 struct vme_resource * vme_slave_request(struct vme_dev *dev,
97 vme_address_t aspace, vme_cycle_t cycle);
98
99 struct vme_resource *vme_dma_request(struct vme_dev *dev,
100 vme_dma_route_t route);
101
102 For slave windows these attributes are split into those of type 'vme_address_t'
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.
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.
130 The number of windows available and the available access modes is dependent on
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
185 used is dependent on the underlying chipset. A window must be configured before
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
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.
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
323 int vme_irq_request(struct vme_dev *dev, int level, int statid,
324 void (*callback)(int, int, void *), void *priv);
325
326 void vme_irq_free(struct vme_dev *dev, int level, int statid);
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
340 int vme_irq_generate(struct vme_dev *dev, int level, int statid);
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
356 struct vme_resource * vme_lm_request(struct vme_dev *dev);
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
402 int vme_slot_get(struct vme_dev *dev);