From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:31:05 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED0A616A417; Fri, 28 Dec 2007 20:31:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9800B13C4DD; Fri, 28 Dec 2007 20:31:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSKP4Gx076651; Fri, 28 Dec 2007 13:25:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:29:51 -0700 (MST) Message-Id: <20071228.132951.-432836769.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200712281500.55155.jhb@freebsd.org> References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marcelm@juniper.net, freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:31:06 -0000 In message: <200712281500.55155.jhb@freebsd.org> John Baldwin 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.= : : 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