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

[Ulf Hansson]

On 28 May 2014 13:03, Mark Brown <broonie at kernel.org> wrote:
> On Wed, May 28, 2014 at 10:19:11AM +0200, Ulf Hansson wrote:
>> On 27 May 2014 19:53, Mark Brown <broonie at kernel.org> wrote:
>
>> > 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?
>
>> Since the sdio bus is a discoverable bus, we must leave the "SDIO card
>> device id" outside the information of the DT child node. Instead the
>> "SDIO card device id" will be fetched once the card has been properly
>> powered and initialized. From sdio bus' ->match(), the "SDIO func
>> driver id" will be matched with the "SDIO card device id".
>
>> What we need to describe in the child node is only what "powerup
>> driver" to use (an obviously it's resources). I don't see why there
>> should be a conflict in using a compatible property, but I might be
>> missing your point.
>
> I wouldn't assume that the SDIO bus will always be accurately
> discoverable - hardware engineers can always repurpose things for other
> purposes.

Right! Though I think we should be able to handle most if these issues
through the mmc quirks.

>
>> > 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).
>
>> Yes, that's is also a reason to why I thought it would make sense to
>> have a "powerup driver". Typically this driver should support runtime
>> PM to handle these kind of fine grained power management.
>
> No, runtime PM isn't really fine grained - I'm talking about things
> like starting and stopping individual resources or configuring them.

Are you saying that you have several levels of quiescent mode of your
external chip?

>
>> The SDIO func driver will have access (through the struct
>> mmc_card|host) to the "powerup driver's" struct device, and can use
>> pm_runtime_get|put() for it, to tell the "powerup driver" when it may
>> go into power save state.
>
>> This kind of fine grained power management is not related directly to
>> the SDIO specification, and should not be a part of the mmc core in my
>> opinion.
>
>> If we don't have a compatible string in the DT child node of the mmc
>> host, but just a DT property - is there a way to achieve the above
>> anyway?
>
> I don't see any relationship between having compatible strings and the
> ability to achieve things like that to be honest.  Having compatible
> strings has no real impact on what we can implement, the power driver
> you're talking about can easily be library code or a feature of part of
> the code that already exists - so long as we know what hardware is there
> it's up to us how we interpret that.

Agree.

I am a bit puzzled of how such library should look like, but I suppose
we need to be able to go to different power states through it.
Typically the library may be invoked both from the mmc core to do
power up/off and from the sdio func driver to handle power save.

Does it make sense to you as well?

Kind regards
Ulf Hansson