On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox [off-list ref] wrote:

quoted

quoted

quoted

Fair enough. But there's no such thing a 'hotplug enumeration
construct' in Linux yet, and a bus is the closest thing to it. It does
take advantage of the nice way device code matches drivers and devices
though.

A bus is the wrong construct. You need something to add devices onto the
busses. You can do that. The Intel SFI layer on phones for example
enumerates devices through a firmware table set and creates them on the
right actual physical bus not on their own fake one.

Physically, it is a bus, though it is made up of several other busses.
While I could certainly see people using the mechanism for enumerating
soldered-down devices over the fixed busses, there is a physical
connector that deserves some abstraction/identification.

Further, it is critical to enable hardware vendors to avoid writing
any code for which there are existing drivers.

It's not hotplug in the sense that the phone happens be a fixed
configuration but it does support hotplug behaviour because the order of
the drivers and enumeration is undefined (and both orders work).

I think SFI is interesting, but certainly lacks all of the interfaces.
It seems reasonable to me to extend the specification to add the
missing interfaces, but what doesn't seem to map is the fact that the
SFI structures are initially processed in the bootloader and passed
statically to the kernel, rather than enabling run-time operation.
Users may make run-time trade-offs and also need mechanisms for
performing initial debug on products like "proto capes".

Capebus seems to me to provide this solution fairly well. I don't
believe the SFI approach covers the most critical aspects of hotplug
behaviour.

quoted

quoted

quoted

I'm afraid that having the I2C/SPI drivers doing the detection won't
work.  The capes can have arbitrary I2C/SPI devices (and even more
weird components).  There is no way to assure for example that the I2C
device responding to address 'foo' in cape A is the same I2C device
responding to the same address in cape B.

your ->detect() method should take care of that.

There isn't some magical serial number in I²C devices that a
->detect() method can read and the implementation of I²C is somewhat

It doesn't matter.

What you are basically talking about is


        cape layer
                - wtf is this
                - how do I plumb it

                - create device nodes with correct name for
                  binding, address etc on the right bus


        i2c layer
                - ooh a new i2c device
                - probe as indicated by device name
                - attach correct driver

Many of the devices cannot be probed.

Architecturally its possible you want to make some caps MFDs if they have
their own bus heirarchies etc but generally I doubt it.


Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of
a platform which parses tables and attaches devices to the right physical
bus in a manner they can be reliably probed even when the device has no
sane autodetect.

I know I *am* the slow person in the room, but doesn't this approach
require the code to be compiled into the kernel to support the devices
ahead of time? While I think it might be reasonable to have hardware
developers provide DT fragments in their EEPROMs, there's no way to
get them to submit code patches in order to get their hardware to
work. They need to ship hardware that works with pre-existing
software, since there will be hundreds of boards created by people
with little to no previous Linux experience (akin to Arduino). I seem
to be missing how that approach would get us there.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html