Date: Fri, 28 Dec 2007 13:09:11 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.130911.84364727.imp@bsdimp.com> In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> References: <20071228.121213.-494094613.imp@bsdimp.com> <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> <20071228.130329.43010549.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20071228.130329.43010549.imp@bsdimp.com> "M. Warner Losh" <imp@bsdimp.com> writes: : In message: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> : Marcel Moolenaar <marcelm@juniper.net> writes: : : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: : : : : > If the ocpbus has a table of bus types, what's wrong with having it : : > directly assign the driver when it ads its children? : : : : It violates newbus in that drivers compete for a device. : : If the bus assigns the driver, then there's no competition : : possible. The fact that the bus is abstract should not : : mean that we should change its paradigm. : : No it doesn't. There's two kinds of busses in newbus. Those that : self enumerate based on the hardware present (ie pccard, pci, usb, : firewire) and then those that are told what's there (oldcard-style : pccard, pure ISA, I2C, etc). The busses on the SoC more strongly : resemble the latter than the former. The former busses already are : enumerated with hints, but the actual mechanism is just a few calls : that could be replaced with something better. Just a correction... 'The latter busses already are already..."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.130911.84364727.imp>