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>