[Gta04-owner] Linux 3.5 on GTA04

NeilBrown neilb at suse.de
Tue Jul 24 08:13:07 CEST 2012

Linus has released 3.5 and not to be out done by him, I've release 3.5-gta04.
You can find it at the usual places on git://github.com/neilbrown/linux
(gta04/3.5.y branch) or git://neil.brown.name/gta04 (3.5-gta04 branch).

I've written about it here: http://neil.brown.name/blog/20120724060722 which
I'll paste below... don't know how the formatting will transfer.

You should be warned that there are changes which mean that just switching
kernel on a distro that expects 3.4 or earlier might lead to surprises.
In particular the wake-up signal from the 3G module is delivered differently,
and the GPS and Bluetooth are powered on differently.  Read on for details.


Linus released Linux-3.5 a couple of days ago so it is long past time to have 3.5 available for the OpenPhoenux GTA04. By the time I publish this blog entry it will be, both on github at https://github.com/neilbrown/linux/tree/gta04/3.5.y and on my own server at http://neil.brown.name/git?p=gta04;a=shortlog;h=refs/heads/3.5-gta04.

Quite a lot has gone into 3.5-gta04. A lot of that was bug fixes. 3.5 seems to have more changes that break my phone than other recent kernels, though I haven't counted bugs or hours so that could be misleading. Certainly I have quite a lot of patches in my 'bugs' branch which is mainly for fixing regressions, but then 8 of those are all related: the libertas has a new async firmware loader which seems to be broken. I haven't examined it closely, but wifi didn't work until I revert those patches.

On a happier note I've found time to make various improvements.

    Wifi reset is now handled directly by the mmc driver, rather than having a pseudo regulator do it for me. This is mostly just a code clean up, but it does mean that the voltage is now set correctly on the wifi regulator. That doesn't seem to change performance significantly but I haven't looked closely. 

    The OMAP serial ports can how have a 'virtual DTR' which is a GPIO line that transitions up or down as the device is opened or closed. This allows the next two point... 

    The bluetooth is automatically powered up when /dev/ttyO0 is opened, and powered down when it is closed. This is much nicer (more automatic) than having an 'rfkill' device. So running hciattach /dev/ttyO0 any will power on the device, and killall hciattach will turn it off. Simple. Power is turned off when the device suspends too so you don't need to kill hciattach before suspend. 

    Rather more interestingly, the GPS is now turned "on" or "off" when /dev/ttyO1 is opened or closed. This is rather tricky as both changes require the same down/up pulse on a gpio and it is not trivial to know if the device is currently on or off. But I have a driver that manages all of that - it watches the RX line for traffic whenever the GPS should be off and pulses the line again if needed. This is particularly important at boot - if the GPS is found to be on at boot it is immediately turned off. After that its state should stay in sync with expectations.

    When turned 'off' the GPS is not actually off - it does maintain some state and seems to use extra current though I'm not completely sure of that yet. I don't know of any way to turn the GPS off more firmly.

    The virtual-DTR line doesn't turn off power to the antenna - that still requires an 'rfkill'. If the GPS is partly on when it is officially 'off', it might be useful to leave the antenna on so it can monitor satellites occasionally. Until I know exactly what turning it off means I don't want to exclude the possibility of GPS off but antenna on. For now I have created /etc/gpsd/device-hook to call 'rfkill' as appropriate, and made 'rfkill' setuid - rather horrible but it works for now. 

    The GPIO that is used to sense the state of the GPS antenna is now reported using the new 'extcon' (external connector) framework. /sys/class/extcon/gps_antenna/state will contain either 'internal' or 'external' as appropriate. When there is a change a UEVENT is created so e.g. udev could be configured to do something interesting. 

    The wakeup signal from the GSM/3G chip is now an input key rather than a bare 'gpio' line. This makes it easier to integrate with the auto-suspend code.

    To get notifications of wakeups you need to open the right [/dev/input/event] device and listen for key presses of KEY_UNKNOWN. The GTA04/udev-rules/input.rules file has the necessary udev magic to make the right file appear as [/dev/input/incoming]. 

I think that is all. Power management seems to be largely unchanged - 25mA when in suspend, about 70mA when idle, awake, screen off, and about 200mA when idle and awake with screen on. I'll be using this on my phone on a regular basis and see how it goes. 
-------------- 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/20120724/034b6eb9/attachment.bin>

More information about the Gta04-owner mailing list