> > One thing that was talked about at OLS this year was a common table
> > standard for platforms that control their own firwmare: linuxbios, some
> > embedded PPC folk, and some arm folk. Typically, each wants to be able to
> > tell the kernel about the devices that are on the system (feed the kernel
> > an already constructured device tree), and resource information about some
> > of those devices.
>
> If the other platforms already have a table then we may not be able to
> change it. Because tables tend to be the ABI of the firmware to the kernel.
> At the very least you don't want to change the recognition sequence.
AFAIK, they don't have table formats. Or, they have some minimal mechanism
for passing configuration data. But, there was no unified mechanism for
representing devices until 2.5, so it's always been a PITA to do something
like this..
> What is shareable is a good model kernel side, and possibly some subtables.
> Roughly prepopulating the kernels device tree so it doesn't need to do
> dangerous probes for onboard ISA type devices. Having a version of lm_sensors
> that automatically configures itself would be very nice.
Yes, that is very nice, and exactly what is needed by all parties. That is
actually what ACPI wants to do. One ACPI requirement is that the OS use
ACPI to enumerate as many devices as it can before the OS does any probing
(native enumeration in ACPI-speak).
I have a patch I wrote a few months ago that uses the ACPI tables to
discover devices, rather than probing for them. It's pretty nifty, and
will probably be instructive to see how another firmware 'driver' does it.
I'll be updating it and posting probably in the next month (once some
other issues get resolved.) I'll be sure to touch bases with you when I
do..
> When I started looking at this the first thing I realized is that
> devices are not connected as a tree. So the idea of a device tree is
> basically silly. There are devices with multiple ways to get to them,
> and various other interesting tidbits.
Most devices are connected in a tree, and the kernel really wants to
believe that, for various reasons - power management, shutdown sequences,
hotplugging. You want to represent ancestral relationships as accurately
as possible, to make these things easier to do.
I would really stress trying to adhere to an accurate tree as much as
possible. The ones that tend to not conform are:
- legacy devices
These are typically hanging off the southbridge, usually as functions of
the superio chipset. Make them children of the southbridge.
- system devices
CPUs, APICs, PITs (?), etc. In the device tree, I've made a pseudo system
bus for these devices. I would recommend grouping them under something
similar, or have some sort of ID tag to identify that it's a device of
Type X, so you know it belongs on the system bus.
- thermal sensors, fans, etc.
I'd say these are system devices as well, as they usually have an intimate
relationship with the system devices.
> In addition, there are several times when you run into cases where
> devices need some aditional information to run. lm_sensors needs
> calibration data on their sensors. ioapics need data that maps
> their irq inputs to irq sources, etc. Given that bus id's change
> the only sane way of handling this information is attaching it
> to the device tree.
Yes, and legacy devices need resource information, since you don't
necessarily want to assume that they appear at their legacy I/O port.
I don't know how you represent this, but I might suggest something like
- define a resource structure for each type of device
- create a table type for resource structures for each type of device
- index each device of a particular type in the device tree, so it
can map back to an entry of the resource table for that type
You will end up with several more table types, but each will be simple and
their meaning clear.
How would bus IDs change for these devices? The types of devices that you
typically need this information for are the ones that are attached to the
motherboard. If you change these devices, you'll have to change the table
anyway..
One final question: do you use PnP IDs? I don't buy into a lot of the
cruft of Microsoft and Intel specs, esp. WRT firmware. But, they have gone
through and attached IDs to nearly all types of devices that are found on
motherboards. It's what ACPI and PnP BIOSes use to tell the OS about
devices.
In the patch that I wrote to do ACPI-based enumeration, I map the PnP IDs
to something generic in the kernel, like "serial" or "pci" (host bus). For
whatever mechanism that you use to identify devices, you'll have to do
something similar.
You may hate PnP IDs. But, using an existing mechanism would make some
things easier... ;)
-pat
