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

[Olof Johansson]

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.

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


-Olof