[Gta04-owner] QtMoko v44

[NeilBrown]

On Sun, 15 Apr 2012 00:01:25 +0200 Andreas Kemnade <andreas at kemnade.info>
wrote:

> On Sat, 2012-04-14 at 20:58 +0200, Dr. H. Nikolaus Schaller wrote:
> > Am 14.04.2012 um 16:59 schrieb Andreas Kemnade:
> 
> > > http://projects.goldelico.com/p/gta04-kernel/page/Wireless/ is a bit
> > > clearer. But copying from the hw-test-script is of course a very good
> > > idea. I have just done that now. 
> > 
> > BTW, it also check if the modem has powered up on a device
> > that has no GPIO186 (i.e. the GTA04A3 boards).
> > 
> > > But I guess that should definitively go into the kernel as a rfkill
> > > device, I just do not know yet how and where to put the lsusb | grep
> > > into the kernel in a clean way
> > 
> > Another option could be to check if the HSO driver module has been loaded.
> > Or check the existence of /dev/ttyHS*
> > 
> > But I don't know if that is easier to handle in kernel space...
> > 
> Hmm, a long
> grep 'detecting usb devices' /dev/brain 
> gives the following:
> 
> ugly method: add a global variable to the hso driver saying if it is
> used and checking it from a rfkill driver.
> 
> better method: bus_register_notifier()
> check for BUS_NOTIFY_BOUND_DRIVER and then for the name of the driver
> bound. That looks like a clean way, a separate module and no need
> to mess around at multiple places in the kernel. 
> 
> 
> > And, Neil may comment on this since we have a similar
> > toogle button control for the GPS module. There, an rfkill driver
> > should monitor the serial line for (missing) incoming data.
> > 
> > So I think both areas may have similar needs (timed monitoring of
> > some /dev/tty from some other driver and pulsing a GPIO).
> > 
> I think for the GPS module, the mechanism has to be a bit different.
> The ugly method will be the same, but I do not know the better method
> yet.

If I understand your classification scheme correctly, the "better" method is
to reprogram the RX pin as a GPIO when the GPS should be off, and if we get
an interrupt on that GPIO, toggle the control pin.

BTW, I haven't tested this properly yet, but it seems that once my GPS gets
a good fix, the power usage during suspend goes up - about 20 or 30 mA.
I don't think toggling the control line actually turns it off.  Rather it
causes it to stop sending updates and possibly puts it into a lower power
state.  Certainly it gets a fix much faster after 'turn back on' if it had a
fix before turning it off.

If that is so, we'll want to figure out how to use SiRF to force the GPS into
an even lower power state.

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCUQFjAA&url=http%3A%2F%2Fgpsd.googlecode.com%2Ffiles%2FSiRF-SiRF-v2_4.pdf&ei=qwOKT_fFM6LqmAWT_vTXCQ&usg=AFQjCNHtBego11gP7wNTiLWqk2stPZXt2g

or:

        http://preview.tinyurl.com/d784vha

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120415/69b456c8/attachment.bin>