static and dynamic devices (again)

[Greg Watson]

Thanks Ron, post this tome at 10pm so I have to stay up late...

As Ron points out, I spent some time today seeing if it was possible 
to unify the static and dynamic device code. It certainly is 
possible, but it turns out that we're trying to do things in two 
fundamentally different ways. The result is that we just push the 
separation between the two types of devices down another level. I'm 
not sure is something that we want to do, because it just makes 
things more difficult to understand.

My feeling is that keeping them separate is probably the way to go. 
Modifying the current device code so that  dynamic trees can hang off 
a static device (such as a northbridge) will solve some problems that 
are on the horizon. This will also allow code development to move 
forward without major changes, but not preclude unifying the two 
schemes in the future if it becomes necessary.

I'm also interested in any comments on this approach.

Greg

At 10:08 PM -0600 22/7/03, ron minnich wrote:
>Greg has spent the day exploring options for how to merge the static and
>dynamic device trees in LinuxBIOS, per Eric's comments. He wrote a
>substantial amount of code, which at this point we may not commit. The
>goal of the code was to see if it makes sense to merge the static and
>dynamic trees. I am not convinced such a merger makes sense.
>
>Discussion follows.
>
>The problem is this: on a given motherboard, there are a static set of
>devices, such as northbridges, southbridges, so on: these are soldered to
>the board. Then there are dynamic devices, plugged into PCI slots.
>
>On a motherboard, we know that the static devices are there, and we even
>know a lot about them, such as what certain registers do.  We need on
>the motherboard to initialize components of the static devices. In other
>words, we have knowledge about:
>o the type of the device;
>o instances ofthe device;
>o special operations we need to do to the device to modify internal
>   state (e.g. turn off the IDE controller, turn on Ethernet, etc.)
>o special control information that is highly device-specific
>
>These operations are operations that we have to do because the OS assumes
>they will be finished when the OS starts, or we need to do them to
>initialize things, such as DRAM.
>
>Dynamic devices are known only in a generic fashion. In LinuxBIOS, the sum
>total of our knowledge of dynamic devices is the Base Address Register
>set, the Command register, and possibly (in future) the IRQ. LinuxBIOS has
>no knowledge of device-specific I/O registers. For dynamic devices,
>LinuxBIOS does a few generic operations and lets the OS do the rest.
>
>So for dynamic devics we know about:
>o instances of the device
>o Generic control information that is not device-specific
>
>So, to sum up: for static devices, LinuxBIOS needs knowledge that goes
>beyond what the OS knows, and will perform device-specific operations
>based on internal knowledge LinuxBIOS has about the device. LinuxBIOS will
>maintain information about the type of the device and all instances of the
>device. In many cases, LinuxBIOS will do operations on the device that the
>OS is not capable of doing.
>
>For dynamic devices, LinuxBIOS only does the most general configuration,
>and has no knowledge of device internals. The OS manages device-specific
>operations.
>
>The dichotomy is pretty clear.
>
>It is kind of like a house. There are walls and floors and outlets and
>phone jacks. These are fixed (static). Then there are chairs and lights
>and phones. These are dynamic. You know all about the phone jacks, but you
>don't know about what phones are plugged in, and the phones change all the
>time, especially if you have children in the house. The static devices
>(walls) are a fundamentally different thing than the dynamic devices
>(chairs).
>
>We are calling static devices 'chips'. Chips are structured as follows:
>there is a chip_control structure for a TYPE of a chip, with generic
>information about the chip and a pointer to a control function that is
>specific to that chip. Then, for each instance of the chip, there is a
>chip structure that contains a pointer to the chip_control structure and
>information specific to the INSTANCE of the chip.
>
>Think of chip_info as the class definition, and chip as instantiations of
>the chip.
>
>Chips are statically declared and initialized, and form a tree with a root
>at the mainboard, with sibling pointers for chips at the same level --
>e.g., two devices hung off the same southbridge are siblings. These
>structures are filled out at compile time.
>
>Dynamic devices are called struct device. There is (currently) a device
>struct allocated dynamically for each function on a device.
>
>[digression:  The PCI heritage of devices is very clear once you start
>looking at them. This is reasonable, as even on HyperTransport everything
>looks like a PCI device.  But it may bite us at some point.]
>
>Devices also form a tree, with children, parents, siblings, etc. One
>assumption we've noticed in the device code is that of a 'root bus'. 
>Properly, this should not really exist: there can be multiple northbridges
>in a system, each with a PCI bus. But the device code so far inherits from
>freebios 1.0 the PC assumption that there is one root bus, and that it is
>configured from a common point of control -- on PCs, the 0xcf8/0xcfc
>mechanism.
>
>Our early assumption was that we could take the static tree, build a
>dynamic tree, and then populate the tree with dynamic devices. Eric would
>like to see this happen. Greg and I are no longer convinced this makes
>sense. Hence the source of this discussion.
>
>At minimum, if you build a dynamic tree from the static tree, you'll have
>to mark the devices as static. You'll have to handle them differently
>because the resources work differently. Some resources such as Base
>Address Registers won't exist on devices in the static tree. You'll have
>to note that some devices are capable of having device-specific code, and
>others are not. You'll end up with structure that really contains two
>structures inside: structure members for static devices only, and
>structure members for dynamic devices only. It won't be a happy marriage. 
>Finally, all your code will have to handle two cases: static and dynamic
>devices. Once we looked at this, we saw that we ended up with a dynamic
>tree with static devices grafted in, with no apparent savings on
>complexity and no real code reuse.
>
>Here is what we think makes sense. The dichotomy between static and
>dynamic devices should remain. The static devices will not be converted
>into some form of dynamic device. There will need to be a linkage from the
>static devices to dynamic devices. This linkage will be at the northbridge
>-- as it is in hardware.
>
>Northbridges, i.e. devices which have an attached PCI bus (or more than
>one), will have a device structure pointer in the device-specific data
>structure (i.e. in the chip structure). At some point, as part of the code
>that walks the statically allocated northbridge, pci enumeration for that
>northbridge takes place.  This has a major advantage for non-PC platforms
>(such as PPC) that don't use the standard PC 0xfcf8/0xcfc mechanism for
>configuring the PCI bus -- it makes sense to talk to the northbridge
>device directly to configure the bus(ses) on that northbridge. It is also
>a big win for systems with more than one northbridge -- these will be more
>and more common. And for switched, not bus-based, systems the advantage is
>apparent.
>
>We thus have a static tree (representing the static resources) with links
>at certain places to the dynamic tree (representing dynamic resources). 
>LinuxBIOS can do device-specific operations on devices in the static tree,
>and can attach dynamic devices to nodes in the static tree. On the
>whiteboard in Greg's office, this setup makes lots of sense. We'll see how
>it is in practice.
>
>We plan to prototype this in the coming few days and try it out.
>
>Comments and questions are welcome. We need to open this discussion up. I
>would really like to hear from you folks. As Eric pointed out, we're
>trying to define the 2.0 core functionality, and we want to make it a good
>structure but also one that is easy for people to do new ports. It is
>essential to hear from those of you who are doing ports -- there are lots
>of you on this list.
>
>thanks
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios