Date: Mon, 31 Dec 2007 18:49:53 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: marcelm@juniper.net, freebsd-embedded@FreeBSD.org Subject: Re: ocpbus(4) Message-ID: <20071231.184953.1708679834.imp@bsdimp.com> In-Reply-To: <200712311606.25424.jhb@freebsd.org> References: <200712281500.55155.jhb@freebsd.org> <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200712311606.25424.jhb@freebsd.org>
John Baldwin <jhb@FreeBSD.org> writes:
: 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).
Actually, the hints way of describing the hardware like the e500 has
is working today in the at91 port. We do exactly this to describe
what iic devices are on the bus, what spi items are on the spi bus,
etc. While it would be nice to have an extra layer of indirection
there, I don't see what it buys us in the general case. The iic bus
is in turn on the twi device which is on the atmelbus which is on the
nexus. The nesting is already supported.
: 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
If Marcel really objects to hints, this isn't going to be much
better. It appears to be as expressive as hints with one extra layer
of indirection. I'm not sure I see what that buys us, frankly.
If you really want to support nesting, without complexity getting in
the way, you'll likely need to have a better language to describe
things. Something like:
nexus 0 {
atmelbus 0 {
at91_twi 0 {
iicbus * {
icee 0 { addr = 0x80; }
icee 1 { addr = 0x90; }
icee 2 { addr = 0xa0; }
icee 3 { addr = 0xb0; }
}
}
at91_spi 0 {
spibus * {
at45d 0 { select = 0; }
}
}
}
}
and have that be translated to something the kernel can easily parse.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071231.184953.1708679834.imp>