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

[arend@broadcom.com (Arend van Spriel)]

On 05/23/14 13:50, Hans de Goede wrote:
> Hi,
>
> On 05/23/2014 01:22 PM, Mark Brown wrote:
>> On Fri, May 23, 2014 at 11:13:44AM +0200, Hans de Goede wrote:
>>
>>> Thinking more about this, I would like to make one change to my
>>> proposal, the mmc-core should only do power up of child-nodes if
>>> they have a compatible of: "simple-sdio-powerup". This way
>>> when we add something more complex, we can keep the simple powerup
>>> code in the mmc core, keeping what we've already using this working
>>> and the mmc core won't respond to the child nodes for more complex
>>> devices, so it won't conflict with more complex power-up handling
>>> handled by some other driver.
>>
>> Would it not be better to have this be something in the driver struct
>> rather than in the device tree?  Putting a compatible in there would be
>> encoding details of the Linux implementation in the DT which doesn't
>> seem right especially since these are details we're thinking of changing
>> later on.
>
> 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.
>
>> Something like have the driver set flags saying if it wants
>> to do complicated things.
>
> Chicken<->  egg, we won't know which driver to use before we've probed
> the mmc bus, and we cannot probe the bus before enabling the clks, etc.

The approach I took with brcmfmac is that upon module init I search the 
DT for "brcm,bcm43xx-fmac" compatible and get the clock and/or gpio 
resource and enable them before registering the sdio driver. The 
difficulty is probably when using the driver built-in as the clocks and 
gpios may not be available yet and we can not rely on deferred probing 
in module init stage.

Regards,
Arend

>>> FWIW if we ever get truely complex cases I think modeling the
>>> power-up hardware as a pmic platform device is not a bad idea,
>>> we would then need to have a generic mmc-host pmic property, which
>>> would be used both to do the initial powerup before scanning, as
>>> well as for the sdio device driver to get a handle to the pmic,
>>> for run time power-management (if desired).
>>
>> I don't know if this will ever apply to SDIO but with other buses the
>> complicated bits come when the driver wants to take over some of the
>> power management do things like turn some of the supplies or clocks on
>> and off independently at runtime for low power modes.
>
> Hmm, good point in that case actually having these things in the
> child node makes most sense, because then the driver can find them
> their. Note that the mmc core enabling things does not mean that
> the driver cannot later disable them if needed.