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

[Arend van Spriel]

+ Russell

On 05/25/14 21:20, Hans de Goede wrote:
> 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.

Hi Hans,

I recalled a recent patchset from Russell King. He was working on i.MX6 
platform with brcmfmac device and ended reworking sdhci/mmc host 
controller code in a series of patches [1]. Patch 34 might be similar to 
what you are trying to accomplish.

Regards,
Arend