Date: Fri, 28 Dec 2007 13:29:51 -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: <20071228.132951.-432836769.imp@bsdimp.com> In-Reply-To: <200712281500.55155.jhb@freebsd.org> References: <20071228.114559.-311937481.imp@bsdimp.com> <B5E9CBD1-0F16-422C-9AFA-CC33D988630C@juniper.net> <200712281500.55155.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200712281500.55155.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> writes:
: On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote:
: > > : Q1: Do people think it's worthwhile to pursue a generic
: > > : ocpbus(4) definition?
: > >
: > > Generally, yes. In fact, I've done a bunch of things with what I've
: > > called obio (On Board I/O) that does similar things, but relies
: > > entirely on hints to do the job. Since that's how we do things
: > > elsewhere, this seems like a reasonable approach. If we move to doing
: > > things differently, then we can talk about that.
: >
: > 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.
How does one separate the topological information from the
proscriptive information? Eg, is the irq=4 an instruction to the
driver to use IRQ 4 for the device (proscriptive), or is it an
instruction to the bus to help locate COM1 (topological).
: There would be a new-bus level framework to enumerate the various devices that
: have properties and bus drivers would "claim" a device and bind it to a child
: device_t. Each bus could then expose the properties as it saw fit. For
: example, if you had this:
:
: device.FOO.at=pci4.5.0
: device.FOO.vendor=0x5555
: device.FOO.device=0x1212
Same question here. If the first one was 'device.FOO.at=pci' then
what would the other two things mean, especially if there was a
driver/unit forced for this device?
: then the PCI bus could use that to override what gets returned via the vendor,
: device, and devid IVARs used in probing.
:
: You could still implement the bus_enumerate_hinted_children() API using this
: alternate backend.
Assuming one could clear up the ambiguity, yes.
: Also, fwiw I'm thinking of having a 'device' command in the loader that is a
: bit of a frontend so you can do things like:
:
: 'device COM1 at isa0 irq 4 console'
:
: that might translate into setting 'at=isa0', 'irq=4', 'console=1'.
Again, the same questions: what parts of this are topological and what
parts proscriptive?
: I also think there might be a generic way to get at any properties associated
: with a device_t by doing:
:
: int property_get_str(device_t dev, const char *name, char *buf,
: size_t buflen);
: int property_get_bool(device_t dev, const char *name, int *val);
: int property_get_int(device_t dev, const char *name, int *val);
:
: etc.
:
: Maybe devprop_* instead, but you get the idea.
We already have similar interfaces to get the hinted properties...
What would the translation be.
Also, I think that even though this is mildly relevant for the ocpbus
discussion, we shouldn't let ourselves get sidetracked by it.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.132951.-432836769.imp>