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

[Mark Brown]

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.

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

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140528/580648d8/attachment.sig>