Date: Fri, 28 Dec 2007 14:30:40 -0800 From: Marcel Moolenaar <marcelm@juniper.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> In-Reply-To: <20071228.150443.-924279995.imp@bsdimp.com> References: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> <20071228.130329.43010549.imp@bsdimp.com> <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net> <20071228.150443.-924279995.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 28, 2007, at 2:04 PM, M. Warner Losh wrote: > We're never going to get around the fact that we have to have a > different bus attachment for each of the enumeration mechanisms in the > kernel. Euh... the whole point of our discussion is exactly about creating an abstraction layer that hides the details of the enumeration mechanism from the driver so that you can in fact have a single bus attachment. ocpbus(4) is inherently useless if we still need to create different bus attachments for different, bus similar, busses. While I don't intend ocpbus(4) to be the one and only bus attachment, it should at least unify busses and/or configurations that aren't self-enumerating. > If I understand your proposed method, then we would create a new > integer of some flavor assigned for each and every type of device > there is. You'd have us have something like: > > #define DEVICE_TYPE_UART 1 > #define DEVCIE_TYPE_NETIF 2 > #define DEVICE_TYPE_MMCSD 3 > #define DEVICE_TYPE_SYNC 4 > #define DEVICE_TYPE_SPI 5 > #define DEVICE_TYPE_WIRELESS 6 > #define DEVICE_TYPE_OHCI 7 > #define DEVICE_TYPE_PCIB 8 > #define DEVICE_TYPE_UHCI 9 > ... > > #define DEVICE_ID_16550 1 > #define DEVICE_ID_ATMEL_SERIAL 2 > #define DEVICE_ID_ARM_LTD_SERIAL 3 > #define DEVICE_ID_CIRRUS_SERIAL 4 > #define DEVICE_ID_ATMEL_SSC 5 > #define DEVICE_ID_ATMEL_MCI 6 > #define DEVICE_ID_ATMEL_MCI2 7 > #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ > #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ > #define DEVICE_ID_ATMEL_SPI 10 > #define DEVICE_ID_ATMEL_TWI 11 > #define DEVICE_ID_ATMEL_RTC 12 > #define DEVICE_ID_ATMEL_PMC 13 > #define DEVICE_ID_ATMEL_ST 14 > #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func > serial port */ > #define DEVICE_ID_ATMEL_UDP 16 > #define DEVICE_ID_ATMEL_PIO 16 > #define DEVICE_ID_CIRRUS_ETHER 18 > #define DEVICE_ID_CIRRUS_GPIO 19 > #define DEVICE_ID_XSCALE_MMC1 20 > #define DEVICE_ID_XSCALE_MMC2 21 > #define DEVICE_ID_XSCALE_MMC3 22 > #define DEVICE_ID_XSCALE_GPIO 23 > ... > > Am I understanding your proposal correctly? I can't see how else it > would work if this isn't the case, but if you have some clever scheme, > I'd be interested. No, this is more or less the gist of it. The type and id can be chosen in any way we like, including using the type as the id. The abstract bus driver does not need to know anything other than maybe translate a table into a newbus hierarchy and using the type/id combination to flag a child. Any newbus node that implements the ocpbus handshake is then automatically an ocpbus driver even though there's no mention of how it obtains the device information. As I said before: it's about avoiding the flurry of bus attachments, not about dictating how devices are enumerated. -- Marcel Moolenaar marcelm@juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FA37AAF-8113-44DE-8FF9-5BB203188912>