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

[Arend van Spriel]

On 05/27/14 20:55, Olof Johansson wrote:
> On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote:
>> On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote:
>>
>>> To describe the HW in DT, the embedded SDIO card (actually it could be
>>> any type of embedded card) shall be modelled as a child node to the
>>> mmc host in DT. Similar to what you have proposed, but with the
>>> difference that the child node _must_ contain a DT compatible string,
>>> which means a "powerup-driver" can be probed.
>>
>>> Yes, I understand we might need one DT compatible string per board,
>>> but that's because we need to model the hardware - and it differs.
>>
>>> To clarify my view, we do need a "powerup-driver" and the primary
>>> reason is that we must not model "power up sequences" within DT.
>>> Typically I see the "powerup-driver" as a simple platform driver
>>> attached to the platform bus, but I that could of course differ.
>>
>> This then either conflicts with cases where we need to describe the
>> actual contents of the slot with a compatible string or means that the
>> SDIO driver needs to handle powerup sequencing since we should be
>> binding to the first compatible we find.  If the host controller driver
>> and/or subsystem is going to deal with the powering up it's not clear
>> that it specifically needs to be the compatible property that's used
>> to determine the powerup method, it could just be a boolean or a
>> 'power-method = blah' property (where blah is one of a series of strings
>> defining methods).  Alternatively we could have separate nodes for the
>> slot and SDIO device but that feels meh.  What's the hard requirement
>> for it to specifically be a compatible property?
>
> +1. Just because we have a subnode in a device tree, we don't have to have
> a driver bind against it. The MMC core code could go down into the subnodes,
> find a "power-method =<foo>" property and go ahead and parse the rest of it.
> There's no requirement that we do this through the Linux driver model of
> probe(), etc.

I prefer a power-method property over compatible matching. The fact that 
the subnode has a compatible string and properties for the device driver 
should not matter.

>>> The slot will be the first level of child node under the mmc host,
>>> then each slot may have a child node which models the embedded card.
>>> But, let's leave that discussion for now. :-)
>>
>> OK, that's the separate node for the slot and device.
>>
>>> Powerup driver's ->probe():
>>> Typically the "powerup driver" will need to register a few callback
>>> functions towards the mmc core. Typically at mmc_of_parse(), those
>>> callbacks will have to be connected to a particular mmc host.
>>
>>> I would like to see three different callbacks, mirroring each of the
>>> mmc_ios power_mode states MMC_POWER_OFF|UP|ON.
>>
>>> The power up sequence, performed by the mmc core:
>>> The mmc_power_up|off functions, will invoke the registered "powerup
>>> driver's" callbacks if they exists for the particular host it operates
>>> on.
>>
>> There's also the need for the SDIO device to be able to get at the
>> resources provided and actively work with them at runtime if it wants to
>> manage things more actively (partial poweroff for low power states or
>> managing clock rates for example).
>
> Again, I think it gets overly complicated by using a full driver for the
> power management. Abstracted out into something separate and scalable
> as number of devices grow? Sure, definitely. As a driver? Not convinced.

I think somewhere in the thread Hans already indicated the term 'driver' 
was a misnomer. While monitoring the discussion I was wondering whether 
this type of power-up sequence handling is specific to mmc/sdio or could 
it also apply to say spi, i2c, or whatever. In other words, could the 
power-up sequence code be placed in drivers/of code.

Regards,
Arend