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

[Ulf Hansson]

On 27 May 2014 20:55, Olof Johansson <olof at lixom.net> 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.

Using "power-method" might work.

It's would simplify things quite a bit regarding the synchronization
point, in the mmc_of_parse().

But... does it prevent us from handling fine grained power management
through runtime PM? See more comments below.

>
>> > 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.

To handle the fine grained power management, runtime PM is for sure
what we should use here. So, then we need a struct device to be
created to represent the power-method.

Now, if we don't implement this through a "powerup driver" which may
have runtime PM callbacks set up - how do we handle this?

I suppose we could register a specific "mmc power bus", and create/add
the struct device representing the power-method to it. Would that
work?

Kind regards
Ulf Hansson