Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 05/25/2014 02:34 PM, Mark Brown wrote:
> On Sat, May 24, 2014 at 12:06:30PM +0200, Hans de Goede wrote:
>> On 05/23/2014 06:27 PM, Mark Brown wrote:
>>> On Fri, May 23, 2014 at 01:50:40PM +0200, Hans de Goede wrote:
>>>> On 05/23/2014 01:22 PM, Mark Brown wrote:
> 
>>>> The compatible is not a Linux specific thing, it is a marking saying
>>>> that something needs to take care of enabling the clks (and whatever
>>>> else we will make part of the binding for this compatible), before
>>>> scanning the mmc bus.
> 
>>> We could just say that the mere presence of a child node with the right
>>> properties is sufficient to trigger the bus to do the startup?
> 
>> Yes, except that most involved property names are standardized, ie clocks,
>> and we want to be able to opt out of the KISS mmc core code for
>> (future) complex power on sequences.
> 
> This is why I'm suggesting keying off the specific compatible strings
> for drivers that want to opt out of the helpers rather than having a
> compatible string to enable the helpers (which may depend on the
> particular Linux version if the feature sets of drivers change for
> example).
> 
>>> If the device is sufficiently complicated to need a special power up
>>> sequence I'd expect we'd be able to have a compatible string which would
>>> provide enough information for us to figure things out.
> 
>> Hmm, so what you're suggesting is indeed more of an opt out then my initial
>> opt-in to KISS powerup idea. So to be clear what you're suggesting is:
> 
>> mmc core walks host mmc-child nodes. Loads drivers based on compatibles
>> there. The checks a flag field in the driver to see if the driver wants to
>> opt-out of the KISS powerup code. The problem with this is that it won't
> 
> Yes.
> 
>> work reliable with modules, think the mmc probe being done from the ramdisk,
>> and the driver in question only being available from the rootfs. I really
> 
> Why is that a problem - if we have no driver for the device there is no
> point in powering it up in the first place is there?

Well the driver may show up later, so if we only do the power-up once we have
a driver, this means we need to re-check if we need to do the powerup later.

Also the mmc people are very much against specifying a driver, as that is
something which should be probed not specified. I agree with them I've
already seen boards were more or less standardized sdio modules from different
vendors are used, they have various standard sdio powerup related things, like
an enable signal in standard places, but different editions of the boards
have different sdio modules soldered on, using different drivers.

I expect that with some care we can make all variants of these boards work with
a single dts file, by using a simple sdio wifi powerup mechanism, and after
that letting the mmc core figure out which module is actually soldered on.

>> believe that using opt-in with a compatible such as simple-sdio-powerup
>> is by far the safest thing to do, and as an added advantage we don't need
>> to worry about how to deal with the future complex power on cases at all,
>> we leave all the room in the world for various future scenarios. since as
>> soon as the simple-sdio-powerup compatible is not there the mmc core will
>> behave as it does today.
> 
> Please remember that the DT is *supposed* to be an ABI - systems are
> supposed to be able to ship with a fixed DT and have it work with random
> operating systems they have no knowledge of (and may not even exist at
> the time the DT is being created).  This means we can't rely on removing
> a compatible string later on.

I know that the DT is an ABI, and I'm not arguing for removing support for
the simple-sdio-powerup compatible from the kernel when a more complex
case arrives, nor am I arguing to remove it from the DT for existing working
boards. The idea behind the simple-sdio-powerup compatible is that it makes
the simple powerup behavior opt-in. So if a new board comes along which
requires something more complex, the people working on this can do what ever
they want / need without the simple powerup code getting in the way, as
long as they don't *add* the simple-sdio-powerup compatible to their *new*
DT file.

Basically the idea behind the simple-sdio-powerup compatible is to make
the worst case scenario for more complex boards to be the scenario which
we have today, i.e. no support for sdio powerup at all, rather then having
something in place which actually may get in the way, making things worse
then they are today.

Regards,

Hans