ocpbus(4)

[Marcel Moolenaar]

On Dec 28, 2007, at 12:03 PM, M. Warner Losh wrote:

> In message: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3 at juniper.net>
>            Marcel Moolenaar <marcelm at 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 at juniper.net