ocpbus(4)

[John Baldwin]

On Friday 28 December 2007 04:49:59 pm Marcel Moolenaar wrote:
> 
> On Dec 28, 2007, at 12:00 PM, John Baldwin wrote:
> 
> >> Hints can be used to implement the device tree or
> >> device list, but is rather limited. I'd like us to
> >> implement something richer in the future. For that
> >> reason I don't want to expose hints to the driver,
> >> but rather abstract the implementation of the device
> >> tree or the device list behind IVARs. That makes it
> >> possible to implement the "bus" in many different
> >> ways without having to change the device drivers that
> >> attach to the bus.
> >
> > So to jump in here.  I've been thinking more since the last hints  
> > debacle and
> > am thinking of replacing hints with the generic device metadata we'd
> > discussed some at the end of the last thread:
> >
> > device.FOO.<property>=<value>
> >
> > where any driver or unit wiring is a new property rather than  
> > encoded into
> > FOO's name.  Thus:
> >
> > device.COM1.at=isa0
> > device.COM1.irq=4
> > device.COM1.port=0x3f8
> > device.COM1.driver=sio
> > device.COM1.unit=0
> >
> > or some such.
> 
> Just a comment: there's a lot of value in taking a look at language
> and DB theory. Both syntax and semantics can be very important
> properties in the applicability and success of the new description.
> Yes, we may want to be able to compile it into some binary form
> for embedding it into the kernel...
> 
> For example: busses may nest and may need to be described. This
> is especially true in the embedded space. The e500 has a local
> bus within the CCSR, which may contain i2c busses for example.
> 
> Using the hints-way of describing hardware is just not going to
> fly in that case, because you're still keying off of device names
> and unit numbers. Let that be a consequence of the metadata, not
> an integral part of... (device.COM1.* does exactly that).

Redo the 'at' hints like this (pci was already this way in the existing hint 
wiring stuff anyway, i.e. it's _not_ a new-bus device name in 'at').  I'll 
use all-caps to make it stand out:

device.COM1.at=ISA

device.USBA.at=PCI0:4:0		// domain 0 is implicit if not specified

device.FOO.at=BAR

Bus drivers would be responsible for parsing the 'at' and deciding whether or 
not to "claim" a set of device properties.  They may then either bind those 
properties to an existing device enumerated elsewhere (ACPI/PNPBIOS/PCI) 
based on 1 or more property values or create a new device entirely described 
by the property values.  You could even support something like this:

device.BAR.at=PCI0.13.0

device.FOO.at=BAR:42

If you wanted if the driver for 'BAR' (or a child device that was a bus if the 
PCI device_t is not a bus itself) by letting the driver for BAR query 
it's "property name" and use that when evaluating "at".

Some other possible locations (which is what "at" is in this context):

device.COM1.at=ACPI:_SB_.PCI0.LPC0.COMA

(and possibly it could take the short name as well:)

device.COM1.at=ACPI:COMA

-- 
John Baldwin