Date: Fri, 28 Dec 2007 12:55:57 -0800 From: Marcel Moolenaar <marcelm@juniper.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net> In-Reply-To: <20071228.130329.43010549.imp@bsdimp.com> References: <20071228.114559.-311937481.imp@bsdimp.com> <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
On Dec 28, 2007, at 12:03 PM, M. Warner Losh 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).
I don't make that distinction at all. I see a probe method
that's called to match a driver to a device. Whether that
probe method is called only when it's known up-front that
the driver matches the device is, to me, irrelevant.
All I'm trying to achieve is:
1. we can relief the SoC or bus driver from having to know
about device drivers by allowing it to create wildcard
children that are being probed and attached in a generic
way by allowing probe methods to obtain information (in
am abstract way) about the corresponding hardware so as
to have everything fall into place.
2. Avoid a flurry of bus-attachments to generic drivers by
providing an abstract bus to which they can attach and
from which they can obtain whatever information they need
to function (IVARs were suggested) so as to allow many
instances of a single driver that's attached to many and
varying busses.
3. Keep the separation between bus and device pure by only
using a generic handshake or protocol to pass information
from one to the other.
This has nothing to do with the origin of the device tree
(firmware, kernel or other) or whether the bus is self-
enumerating or not. Any bus that's not self-enumerating
is enumerable in some other shape or form, including those
that need hardcoded tables in the kernel. I don't care and
that's why I want it abstracted from drivers. They should
not have to care either.
> : > 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.
Yes there is. If the table is not in firmware, it
typically is in the kernel. The ID may not be needed
if the table references the driver directly, but
other than that it's exactly the same. There's no
confusion. There's simply no distinction. Somewhere
it's recorded that something exists. The ocpbus(4)
idea is to abstract the details of where that
information comes from by making it available in a
generic way.
> 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.
My point exactly ;-)
> 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.
It's irrelevant to the abstraction whether a new
device is dynamically found or whether it needs
to be added to some static table by virtue of a
firmware or kernel upgrade. The ability to allow
a dynamic scheme does not impact static schemes.
--
Marcel Moolenaar
marcelm@juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B62C4CEF-F7CE-4388-B57F-288812BD9696>