Date: Fri, 28 Dec 2007 13:44:57 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: olivier@gautherot.net Cc: embedded@freebsd.org, marcelm@juniper.net Subject: Re: ocpbus(4) Message-ID: <20071228.134457.-1540395924.imp@bsdimp.com> In-Reply-To: <dcfb161c0712281231y4d726502v42959fa7217d7376@mail.gmail.com> References: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> <20071228.130329.43010549.imp@bsdimp.com> <dcfb161c0712281231y4d726502v42959fa7217d7376@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <dcfb161c0712281231y4d726502v42959fa7217d7376@mail.gmail.com>
"Olivier Gautherot" <olivier@gautherot.net> writes:
: Hi there!
:
: On 12/28/07, M. Warner Losh <imp@bsdimp.com> wrote:
: > 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.
:
: Excuse my ignorance about obio, ocpbus and the like...
: If we envisage to use a PCI-like approach to initialise the on-chip
: drivers, couldn't we generate a table on a per CPUID basis?
: In PCI land, the device enumerates all the functions it supports
: and the kernel installs the approriate modules. In this case, we would
: have a table of devices indexed by the CPUID - for instance, the
: MPC5200 has 2 UARTs at addresses x and y, the MPC5512 has 3 UARTs
: at addresses x, y and z, etc. These tables would be used only during
: boot time and would only use up ROM space... When compiling the
: kernel, we would then enable only the tables that apply (ideally, just
: one - and make sure at run time that it is the correct one).
:
: It does not sound like rocket science to me so I guess it has been
: evaluated at some point?
The problem is more complicated than just UARTs. The problem is
defining the enumeration itself. Each device type in these SoCs
typically is a custom job, apart from a few standard things like
uarts. This means that one would have to add to the enumerated type
every time one ported to a new SoC. It adds an extra step. It also
makes it harder to come up on a new revision of an old chip that might
have the same, or very similar, attributes to the old version, but has
a new CPUID. With the hinted scheme, you could at least get partial
information. Basing everything on the CPUID would mean that once that
changes, you go to having zero knowledge of what's on the chip.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.134457.-1540395924.imp>