Lines Matching refs:the
4 Within the Linux bus framework, the FMC device is created and
5 registered by the carrier driver. For example, the PCI driver for the
8 do exactly the same for the VME carrier (actually, it should do it
9 twice, because the SVEC carries two FMC mezzanines). Similarly, an
13 The contents of the EEPROM within the FMC are used for identification
14 purposes, i.e. for matching the device with its own driver. For this
15 reason the device structure includes a complete copy of the EEPROM
16 (actually, the carrier driver may choose whether or not to return it -
17 for example we most likely won't have the whole EEPROM available for
20 The following listing shows the current structure defining a device.
21 Please note that all the machinery is in place but some details may
22 still change in the future. For this reason, there is a version field
23 at the beginning of the structure. As usual, the minor number will
24 change for compatible changes (like a new flag) and the major number
27 just set it to the value FMC_VERSION, and be ready to get back -EINVAL
43 __iomem void *slot_base; /* Set by the driver */
44 struct fmc_device **devarray; /* Allocated by the bus */
45 int slot_id; /* Index in the slot array */
47 unsigned long memlen; /* Used for the char device */
52 uint32_t device_id; /* Filled by the device */
57 The meaning of most fields is summarized in the code comment above.
59 The following fields must be filled by the carrier driver before
66 * op: the operations to act on the device.
68 * irq: number for the mezzanine; may be zero.
70 * eeprom_len: length of the following array.
74 * eeprom: the full content of the I2C EEPROM.
78 * carrier_data: a unique pointer for the carrier.
80 * fpga_base: the I/O memory address (may be NULL).
82 * slot_id: the index of this slot (starting from zero).
84 * memlen: if fpga_base is valid, the length of I/O memory.
91 Please note that the carrier should read its own EEPROM memory before
92 registering the device, as well as fill all other fields listed above.
95 later by either the bus or the device driver:
99 * fru_id: filled by the bus, parsing the eeprom.
101 * slot_base: filled and used by the driver, if useful to it.
105 * nr_slots: set by the core at registration time.
113 * mezzanine_data: available for the driver.
118 Note: mezzanine_data may be redundant, because Linux offers the drvdata
119 approach, so the field may be removed in later versions of this bus
123 the fmc-bus environment, and is a good reference to look at.
129 The carrier provides a number of methods by means of the
131 (again, it is a moving target, please refer to the header rather than
149 The individual methods perform the following tasks:
153 These functions access FPGA registers by whatever means the
154 carrier offers. They are not expected to fail, and most of the time
155 they will just make a memory access to the host bus. If the
156 carrier provides a fpga_base pointer, the driver may use direct
157 access through that pointer. For this reason the header offers the
159 the respective method is NULL. A driver that wants to be portable
166 two or more boards of the same kind. Validation is based on the
167 busid module parameter, if provided, and returns the matching
168 index in the associated array. See *note Module Parameters:: in in
169 doubt. If no match is found, `-ENOENT' is returned; if the user
171 returned by the validate method can be used as index into other
172 parameters (for example, some drivers use the `lm32=' parameter in
180 will need to reprogram the FPGA by calling this function. If the
181 name argument is NULL, the carrier should reprogram the golden
182 binary. If the gateware name has been overridden through module
183 parameters (in a carrier-specific way) the file loaded will match
184 the parameters. Per-device gateware names can be specified using
185 the `gateware=' parameter, see *note Module Parameters::. Note:
187 calls this method and parse the SDB tree of the FPGA.
193 operations. The interrupt number is listed in the device
194 structure, and for the mezzanine driver the number is only
195 informative. The handler will receive the fmc pointer as dev_id;
196 the flags argument is passed to the Linux request_irq function,
197 but fmc-specific flags may be added in the future. You'll most
198 likely want to pass the `IRQF_SHARED' flag.
201 The method allows to configure a GPIO pin in the carrier, and read
207 Read or write the EEPROM. The functions are expected to be only
208 called before reprogramming and the carrier should refuse them
210 within 8kB (the current size), but addresses up to 1MB are
211 reserved to fit bigger I2C devices in the future. Carriers may
213 methods: for example the SPEC driver may define that its carrier
214 I2C memory is seen at offset 1M and the internal SPI flash is seen
215 at offset 16M. This multiplexing of several flash memories in the
217 by a driver that has verified the `carrier_name' field.
224 Support for GPIO pins in the fmc-bus environment is not very
227 While the general idea of a carrier-independent driver seems to fly,
228 configuration of specific signals within the carrier needs at least
229 some knowledge of the carrier itself. For this reason, the specific
232 pointer to an array of struct fmc_gpio items, as well as the length of
233 the array. This is the data structure:
238 int _gpio; /* internal use by the carrier */
243 By specifying a carrier_name for each pin, the driver may access
245 expected to return the number of pins successfully configured, ignoring
247 no structure at all refers to the current carrier_name), the operation
248 returns an error so the caller will know that it is running under a
252 the SPEC and the SVEC may request configuration of two different GPIO
254 it most likely means that the current carrier is a still-unknown one.
257 special number in the gpio field, using one of the following macros:
267 provided the carrier_name field in the data structure is left
269 between virtual and physical GPIO numbers. The carrier may then use the
270 _gpio field to cache the result of this mapping.
272 All carriers must map their I/O lines to the sets above starting from
274 points 0 through 3 (even if the test points on the PCB are called
280 suitable GPIO pins. Clearly, the person running the drivers will know
281 the order used by the specific carrier driver in assigning leds and
282 testpoints, so to make a carrier-dependent use of the diagnostic tools.
285 the wr-nic (which uses IRQ(1) on the SPEC card) should configure
287 IRQ(1) if the test fails. This probing step should be used because even
288 if the wr-nic gateware is known to use IRQ1 on the SPEC, the driver
290 actually, the knowledge that IRQ0 may fail is carrier-dependent
291 information, but using it doesn't make the driver unsuitable for other
296 * If no pin in the array can be used by the carrier, `-ENODEV'.
300 * On success, 0 or positive. The value returned is the number of
301 high input bits (if no input is configured, the value for success
304 While I admit the procedure is not completely straightforward, it
306 Given the typical use case of FMC devices, GPIO operations are not
308 used to configure the interrupt pin, mode and polarity. Especially
310 capabilities in the hot path, you should consider using the kernel's