Re: Any news on Runtime Interpreted Power Sequences

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Tue, 29 Oct 2013 09:18:16 -0700 Mark Brown <broonie@kernel.org> 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?

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]