Message-ID: <CA+T6QPkWLXx6-Bh-4VdsdoHypHNkJ4hTdkk-rqUEyGEswpW6fQ@mail.gmail.com>
Date:	Fri, 2 Nov 2012 12:07:08 -0400
From:	Jason Kridner <jkridner@...gleboard.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Russ Dill <Russ.Dill@...com>, balbi@...com,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	"Cousson, Benoit" <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
	Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> >> 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.

>
>> >>
>> >> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists