Re: Any news on Runtime Interpreted Power Sequences

From: NeilBrown
Date: Thu Oct 31 2013 - 01:00:09 EST

On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown <broonie@xxxxxxxxxx> wrote:

> On Tue, Oct 29, 2013 at 11:10:37AM +1100, NeilBrown wrote:
> > Yes, the device is soldered down and has a reset line that needs to be pulsed
> > low at about the same time that the MMC port enables the regulator.
> > How do you propose that I describe this? Which driver should know about the
> > reset GPIO, how to I tell it about the GPIO, and which function should do the
> > pulsing?
> I'd expect the driver for the device to know about this, obviously
> depending on what this actually does it might want to use this at
> runtime (for example, putting the device into reset to minimise power
> while it's idle). We really need a generic way for devices such as this
> on enumerable buses to run before the current probe() in order to allow
> them to manage their power up sequences in embedded systems, this is
> *far* from a unique situation.

I agree.
To me, this sounds a lot like saying "We need a way for enumerable buses to
be given a power-on-sequence to power on the attached device". That is what
I hopped RIPS would provide.

Maybe various devices could allow other devices to register for call-backs
when the first device activates or deactivates a port (whether an MMC port or
USB or Serial or whatever).
Then a driver that needs to control the power-on sequence would register as a
platform-device which registers a call-back with the appropriate parent and
performs the required power-on/off.

Does that sound like the right sort of thing?


Attachment: signature.asc
Description: PGP signature