1 Some notes on IODC, its general brokenness, and how to work around it.
2
3 Short Version
4
5 IODC is HP's pre-PCI standard for device identification (a la PCI vendor,
6 device IDs), detection, configuration, initialization and so on.
7
8 It also can provide firmware function to do the actual IO, which are slow,
9 not really defined for runtime usage and generally not desirable. (There
10 are other firmware standards, such as STI, to do real IO).
11
12 Usually, there are two parts to IODC. The actual ROMs, which are laid out,
13 detected aso in a bus-specific manner (IO_DC_ADDRESS / IO_DC_DATA on
14 GSC/Runway, PCI spec - compliant ROMs for PCI, God-only-knows how on EISA),
15 and the slightly cooked data read by PDC_IODC.
16
17 The ROM layout is generally icky (only one byte out of every 4-byte-word
18 might be valid, and many devices don't implement required options), so
19 using PDC_IODC is highly recommended. (In fact, you should use the device
20 lists set up by the kernel proper instead of calling PDC_IODC yourself).
21
22 Now, let's have a look at what the cooked ROM looks like (see iodc.pdf for
23 the details, this is the simplified version).
24
25 Basically, the first 8 bytes of IODC contain two 32-bit ids called HVERSION
26 and SVERSION. Those are further split up into bit fields, and
27 unfortunately just ignoring this split up isn't an option.
28
29 SVERSION consists of a 4-bit revision field, a 20-bit model field and a
30 8-bit opt field. Now, forget the revision and opt fields exist. Basically,
31 the model field is equivalent to a PCI device id (there is no vendor id.
32 this is proprietary hardware we're talking about). That is, all your
33 driver cares for, in 90 % of the cases, is to find all devices that match
34 the model field.
35
36 The rev field is - you guessed it - roughly equivalent to the revision
37 byte for PCI, with the exception that higher revisions should be strict
38 supersets of lower revisions.
39
40 The last byte of HVERSION, "type", and the last byte of SVERSION, "opt",
41 belong together; type gives a very rough indication of what the device
42 is supposed to do, and opt contains some type-specific information. (For
43 example, the "bus converter" (ie bus bridge) type encodes the kind of
44 bus behind the bridge in the opt field.
45
46 The rest of HVERSION contains, in most cases, a number identifying the
47 machine the chip was used in, or a revision indicator that just fixed
48 bugs and didn't add any features (or was done in a shrinked process or
49 whatever).
50
51 So, here's the interface you actually should use to find your devices:
52
53
54 /* Find a device, matching the model field of sversion only (from=NULL
55 * for the first call */
56 struct iodc_dev *iodc_find_device(u32 sversion, struct iodc_dev *from);
57
58
59 Here's a function you should use if you have special requirements, such
60 as finding devices by type rather than by model. Generally, if you're
61 using this, you should be me).
62
63 /* Find a device, masking out bits as specified */
64 struct iodc_dev *iodc_find_device_mask(u32 hversion, u32 sversion,
65 u32 hversion_mask, u32 sversion_mask, struct iodc_dev *from);
66
67
68 Philipp Rumpf <prumpf@tux.org>
This page was automatically generated by the
LXR engine.
Visit the LXR main site for more
information.