Date:	Fri, 25 Oct 2013 18:33:45 +1100
From:	NeilBrown <neilb@...e.de>
To:	Alex Courbot <acourbot@...dia.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thierry Reding <thierry.reding@...onic-design.de>
Subject: Re: Any news on Runtime Interpreted Power Sequences

On Fri, 25 Oct 2013 15:23:45 +0900 Alex Courbot <acourbot@...dia.com> wrote:

> Hi Neil,
> 
> On 10/25/2013 09:22 AM, NeilBrown wrote:
> >   I'm wondering if there was any news on the Runtime Interpreted Power
> > Sequences?
> > The most recent news I can find is
> >    https://lkml.org/lkml/2013/4/27/73
> > where you say they might be ready for 3.11.  Clearly that didn't work
> > (predictions being hard, especially about the future).
> >
> > I'm really keen to see them turning into a reality and I gather others are
> > too. So ... can we hope?
> 
> A prerequisite of power sequences was to merge the gpiod interface, and 
> this is finally happening. It took much longer than I wanted, sorry 
> about that.
> 
> Logically speaking nothing should now stand in the way of a new version 
> of the power sequences. Expected maybe my own skepticism about them.
> 
> The first version of the power seqs is mainly the result of my 
> misunderstanding of the device tree. Reconsidering it now, if we strip 
> the DT support away power seqs would just become a simplified way to 
> describe how to power a device up and down. In other words, it would be 
> another way to express what can be expressed with C code and would not 
> bring any additional flexibility that DT-described power seqs would have 
> (and I say this totally convinced now that power sequences in the device 
> tree were a bad idea).
> 
> The advantage I could see is that using power sequences we could get rid 
> of the cumbersome and mistake-prone error checking code which is 
> basically the same for most devices. You would just need to describe 
> what you want to activate, and in which order, and the power seqs 
> framework would catch and report any error.
> 
> I'm not sure if this is a sufficient reason to introduce another 
> framework into the kernel, but if this is deemed a good reason by more 
> experienced people then I'm ok to give it a shot. If you have other 
> motivations for this, please also state them so I can get the whole 
> picture. Maybe I just need to be a little bit more motivated about this 
> idea myself. :)
> 
> Thanks,
> Alex.

Hmmm... I'm not encouraged that you don't see them as belonging in
device-tree, as that is exactly where I want them.

Let me explain what I'm thinking.

I have two (or three) use-cases on my board ("GTA04" replacement motherboard
for Openmoko Phone).

Firstly the wifi chip is very fussy about being reset properly before being
accessed.  However it shares the same power regulator as the bluetooth chip.
So if the bluetooth is in use when you "ifconfig down; ifconfig up" the
wifi, it won't get powered down, so it won't get reset, so it won't work.

What I need to do is to tell the 'mmc/sdio' driver that when it wants to
power-on the wifi, it must
   pull a reset-gpio low
   turn-on the regulator (which might already be on)
   pull the reset-gpio high again

I currently have that hacked into the omap-hsmmc driver but I don't think the
code really belongs there.
I would much rather that the omap-hsmmc could be given a 'RIPS' instead
of (or as well as) the regulator and be told to just turn that RIPS on or off.
The RIPS would do the appropriate timed fiddling with GPIO and Regulator.
The only place I can think of the describe the RIPS would be in device-tree.

Secondly I have two devices that are behind serial ports - a GPS and the
bluetooth.
It makes perfect sense to tie the  power-on/off of these to the serial-port
concept of "DTR".  The omap-serial doesn't have a physical DTR, but is can be
configured with a GPIO to use as the DTR (it gets asserted on 'open' and
de-asserted on 'close').

I currently have a "gpio-to-regulator" converting driver plugged between the
serial port and the blue-tooth's regulator.  When I open the serial port for
bluetooth it asserts the gpio line which is routed through gpiolib to my
driver which enables the appropriate regulator.  I have something similar for
the GPS.

I think the gpio-to-regulator driver is a kludge.  I would much rather tell
the omap-serial to activate/de-activate a RIPS as the DTR action.  That RIPS
could then control GPIO for a "real" dtr line, or control a regulator to
support my bluetooth.

For the GPS, power on/off is really messy.  There is a toggle connected to a
GPIO so you need to know what the current state is before you can know how to
"turn off".  So you need to either plug into the serial driver and watch for
input, or use pinctrl to grab the RX pin and treat it like a GPIO.
This is admittedly quite horrible and it makes sense to have a dedicated
driver for it, but as the purpose of the driver would be to power
something up or down it would be nice if the interface it presented was a
power-up-down interface which is exactly what RIPS promised.


I imagine a device-tree interface a bit like GPIO but with more details.
We would have #defines for 
#define RIPS_REG_ON <0>,
#define RIPS_REG_OFF <1>,
#define RIPS_GPIO_ASSERT <2>,
#define RIPS_GPIO_DEASSERT <3>,
#define RIPS_DELAY <4>,
#define RIPS_NATIVE_ON <5>,
#define RIPS_NATIVE_OFF <6>,

Then

 rips-on = RIPS_GPIO_ASSERT  "wifi-reset",
           RIPS_DELAY         <10>,
           RIPS_REG_ON       "wifi",
           RIPS_DELAY         <10>,
           RIPS_GPIO_DEASSERT "wifi-reset";
 wifi-reset-gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
 wifi-supply = <&vaux4>;

would would power-on my wifi-chip.  It's probably a bit ugly, but it is
simple and does follow an established pattern to some extent.

I expect some people will hate it and I won't be able to argue coherently
with them, so please pay more attention to my proposed use-case than to my
concrete example.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists