Date: Fri, 28 Dec 2007 15:46:20 -0500 From: John Baldwin <jhb@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: marcelm@juniper.net, freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <200712281546.21288.jhb@freebsd.org> In-Reply-To: <20071228.132951.-432836769.imp@bsdimp.com> References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> <20071228.132951.-432836769.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 December 2007 03:29:51 pm M. Warner Losh wrote: > 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). The bus chooses. For the isa0 case it's complex, but it would basically work the way my current hint-wiring patches work. The acpi0 (ACPI) or isa0 (non-ACPI and using PNPBIOS) busses would use the resourcse to match COM1 to an existing device if possible. isa0 then does a second pass to actually add device_t's for any "hint" devices that weren't already matched. For smarter busses like pci(4) and usb(4) the topological info would be much more restrictive. pci(4) could probably just match solely on the "at" attribute and require it to specify the bus/slot/func (and optionally domain). > : 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? pci(4) wouldn't allow for just "pci", it would only match a set of properties for a device hard-wired to a specific location. > : 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? See above. Look at the hints wiring patch I had. Basically you are doing 's/hint.sio.0/device.COM1/'. It actually works out the same. Once you can assign named properties to devices then wiring becomes a separate property. > : 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. This would replace hints and resource_*(). resource_*() might still hang around in some form for things that use hints w/o new-bus such as SCSI wiring. > Also, I think that even though this is mildly relevant for the ocpbus > discussion, we shouldn't let ourselves get sidetracked by it. Well, I think it is relevant to the idea of creating a set of abstract-but-not-really ivars to try to replace hints. :-P -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712281546.21288.jhb>