Date: Fri, 28 Dec 2007 13:03:29 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.130329.43010549.imp@bsdimp.com> In-Reply-To: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
: > I guess I agree with you that we need an abstraction layer, but
: > quibble over the details. I especially object to creating an
: > enumeration where an actual device driver name would do.
:
: Agreed. We should not use device driver names. We could use
: strings instead of numbers, but other than that it's an
: abstract name or number that.
:
: > Plus the
: > problem is complicated because none of these devices is standard.
: > Sorry if my first reply came on a little strong on the enumeration
: > point. If there is a compelling argument for it, I'll listen, but it
: > isn't as if we have competing drivers for devices in this domain like
: > we did with sio vs uart.
:
: We should not abandon competition, because that would
: be a step away from generalization. Even though we're
: discussing this in the context of embedded systems,
: I don't see any reason why it couldn't equally apply to
: the LPC devices in PCs that are enumerated by ACPI...
That's a different case. Do not confuse these cases. ACPI has a
table of devices that associated resources with an ID. There's no
such tables in the SoC world, typically. At most, you have a CPU ID
you can read and from that know, based on a hardwired set of tables,
the devices that are present. It isn't extensible in any way when a
new CPU ID comes along. With ACPI you'd get new devices and you
wouldn't worry. With the new CPU ID in the SoC world, you'd get
nothing until you created a new table. Any construction of an
artificial device ID would likely just make it harder to write drivers
for these platforms. Rather than just adding a driver and something
to the table (hints, say) and having it work, one would have to also
allocate a new device ID (one that might conflict with others doing
similar work, causing integration problems later) as well as write
code to test for that ID.
I guess I don't see that many SoCs that have that many devices that
are shared with others. 16550-like UARTs are about the only thing
that has any big amount of commonality. The rest of the devices are
specific to a chip or a small family of chips. Even the 16550 uarts
are wired up differently and have different access requirements.
: True, competition is not likely to be a often-used
: feature in an embedded system but modules may be and
: it's so much easier to deal with modules if you keep
: the existing paradigm and not have the bus driver
: assign device drivers. For in that case the bus driver
: need to be made aware that a new device driver was
: loaded and see if it's one it can assign to a device.
They aren't incompatible at all. The device creates a node in the new
bus tree that's assigned to "at91_twi" for instance. If there's no
at91_twi driver loaded, then nothing happens. If one is later loaded,
at91_twi will automatically probe that device. The name is what is
important. When a module that implements a device of the right name
is loaded, the right things happen. OLDCARD did this for years, and
I've done it more recently with I2C stuff. If you load/unload drivers
like this, it just works. You don't need competition for this to
work.
That doesn't answer the question of 'Is competition always needed?'
but that's a point we differ on.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.130329.43010549.imp>