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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
