Status of development kernel that is tracking mainline

Running a mainline kernel on your GTA04

Unfortunately you cannot (yet) run a mainline kernel (from Linus) on your GTA04. There are 3 main reasons for this.

1. Bugs. Untested code is buggy code and as few people have had a GTA04 for long, few people have tested mainline on that hardware so there are doubtlessly bugs. As bugs are identified and fixed the fixes should get upstream relatively easily.

2. Missing drivers. While much of the hardware in the GTA04 has drivers in mainline, there are a few exceptions. As drivers are written it should not be too hard to get them upstream, though we should expect at least one release cycle before they are included.

3. Explicit board support. This topic is slightly more complicated.

   Previously each distinct "board" (printed circuit board with components) would have a dedicated "board" file which describes the various components and how they are connected. This approach means that each different board needs a different kernel specially compiled for it. This is not good for distributors who want to provide a single kernel that can boot anywhere.

   The new approach is to describe the hardware using a "device tree" file. The kernel then reads this file and initialises all the requires devices appropriately. At the time of writing Linux is in a transition between the two. New board files are not accepted - or at least strongly discouraged - but support for device tree is still very limited.

   Consequently it is not likely that our GTA04 board file will ever get into mainline Linux so we won't be able to run a pure mainline kernel until device-tree support is sufficiently complete, and we have a device-tree file for GTA04. This is not a serious problem and is really just a good goal to help work towards.

The remainder of this page describes the state of support for each component and feature on the GTA04, identifying what is implemented, how much is upstream, and what still needs to be done.

The code described here can be found in the "merge" branch of git://neil.brown.name/gta04 This branch will be repeatedly rebased as new -rc kernels are released.

There is also a "3.2-gta04" branch which is based on 3.2 and might be more stable.

Status of support

Being cautious, I (NeilBrown) will only report that something does work if I have personally tested it. Otherwise I may just say that it is reported to work. Others are welcome to add specific test results.

LCD display

Reported to work.

Driver for the video controller in the OMAP SOC is upstream. Driver for the LCD controller needs cleaning up before it can be submitted.

LCD backlight

Reported to work. Visible in /sys/class/backlight/pwm-backlight/

Requires omap "pwm" driver which is not yet upstream.

touch screen

Reported to work. Appears (typically) as /dev/input/event0.

Driver is upstream.

uSD card

Works reliably. Powers down when not in use. Is not auto-ejected on suspend.

Driver is upstream.

Serial ports

There are 3 serial ports: Which appear as ttyO0, ttyO1, ttyO2.

ttyO0 is connected to bluetooth and is reported to work. Special care is needed to run at speeds above 115200 bps, but this is reportedly possible.

ttyO1 is connected to GPS. This works reliably.

ttyO2 is the 'console' port which is available through the 8 pin connector on the back of the board. This works reliably.

early_printk() is not supported so kernel messages are not printed until after the serial port is fully initialised.

Wake from suspend on data-received works (for console at least).

Driver is upstream.

Future work

It should be possible to route the ttyO2 port out through the USB-OTG port, using D+ and D- as RX and TX. This would allow console access while board is inside case.

Supporting early_printk() would be very helpful.

IrDA

Untested.

bluetooth

Reported to work. HCI-UART access is via ttyO0. Audio access is via the "gta04headset" ALSA device. There are no mixer controls.

Power supply is managed by rfkill device "Bluetooth". Blocking this device does not actually remove power unless the wifi device is also inactive.

Driver is upstream.

Wifi

Works well, and powers-off when not in use (unless bluetooth is keeping the power supply on).

Driver is upstream but requires a closed firmware blob which is free-to-distribute.

LEDs

Works and provides hardware support for blinking at a range of rates. Will remain on in suspend and will continue blinking in suspend if a blink rate was selected which is supported by the hardware (on and off times between 300 and 27000ms are supported as are a few others).

Driver has been submitted upstream and is being shepherded by Andrew Morton in the -mm tree.

AUX and Power buttons

Work and are reported (normally) through /dev/input/event1 and /dev/input/event2. Either will wake-from-suspend though the Power button doesn't when a USB cable is connected.

A quick-press while suspended will wake the device but will not be reported properly through the input device (just a 'Sync' event will be seen, no 'Key' event)

Driver is upstream.

Future work

The key-press should be captured properly even when suspended.

Audio

Audio in through main mic and headset mic, and out through earpiece, speaker, and headset work using "gta04" sound device.

There are many more mixer controls than are meaningful of the way the hardware is configured.

The core driver is upstream but the board configuration for the GTA04 (which is separate from other board configuration) is not.

Future work

The visible mixer controls should be limited to those which are meaningful.

Headset Detect

untested.

Vibrator

Reported to work.

Controlled via the Audio device.

Driver is upstream.

Video-out

Untested.

GSM/UMTS

Connected via USB and appears as:

• 6 tty ports ttyHS0 - ttyHS1. In /sys/class/tty/ttyHS?/hsotype these report as: "Diagnostic", "GPS", "GPS Control", "Application", "Control", "Modem".
• A network interface "hso0"
• an rfkill interface "hso-5"
• An audio interface "gta04voice" which has no mixer controls.

This reportedly works, though low-latency, click-free audio transport between the GSM device and the mic/speakers has not yet been demonstrated.

Wake-from-suspend has been configured but not tested.

Driver is upstream, however a small patch to driver is needed to improve power usage. Patch has not been sent upstream.

Future work

Test wake-from-suspend for incoming GSM call/text.

USB gadget

Tested with g_ether (ethernet device) and g_mass_storage. Should work with all gadget drivers.

Currently reports that 2mA of current is needed, but will try to draw 600mA to charge the battery.

Driver is upstream.

Future work

Report sensible current draw and stick to it. Maybe report several version of each function with different current draws, and only charge battery if high-current function was selected by host.

USB OTG

When a USB-OTG connector cable is used, can drive a device that claim to need at most 100mA and will provide 100mA current.

My USB flash drives claim to need 200mA so I hacked the code to accept that and then I successfully mounted a filesystem of such a device.

My wireless pocket-size keyboard claims to only need 100mA but does not work when plugged in. Maybe it needs more than 100mA.

Driver is upstream.

Battery Charging

This works but there is room for improvement.

When power is available on the USB port the GTA04 will try to draw 600mA of current to run the device and charge the battery. This is fine for a charger and probably OK for a USB port on a powered hub or PC (which are only really meant to deliver 500mA) but would be bad on an unpowered hub or USB-1.1 port.

Charging is disabled when machine enters suspend or is turned off. The first is not desirable, the second is less certain.

The backup battery is charged when needed.

If battery is flat, device will charge battery slowly and will not turn on until voltage level reaches a threshold. There should then be enough charge in the battery to keep the device alive until the charging circuitry is enabled. This has been tested a couple of times and takes a couple of minutes before boot starts.

Most of the driver is upstream but various fixes to make it work well - e.g. to work with the Openmoko charger or to charge the backup battery - are not upstream. I probably won't submit them until I have a clearer idea how it all should work.

Future work

• reliably detect charger and only draw high current when charger is present
• only draw any current from non-charger if host as said it is OK.
• keep charger active during suspend
• possibly keep charger active when off.

GPS

Providing the hardware mod has been made (for GTA04A3) GPS works well. Data appears through /dev/ttyO1.

Power to the Antenna is controlled using the 'GPS' rfkill device.

The GPS device is turned on or off by writing "0" then "1" to /sys/class/gpio/gpio145/value. Writing these two values toggles off->on or on->off.

The external antenna can be detected by inspecting /sys/class/gpio/gpio144/value which will be '1' if the 'rfkill' device is enabled and the external antenna is installed.

Future work

• Integrate the on/off toggle into the 'rfkill' device.
• export the 'external antenna' connected via a 'switch' or 'extcon' class device once one of the other arrives in mainline.

Accelerometer

The is a simplistic driver for the BMA150 which is an earlier version of the accelerometer. This has been hacked to work with the BMA180 for testing. A proper driver will eventually be written to replace this, so don't depend on current functionality.

When this is configured in it normally appears as /dev/input/event1 pushing the buttons up to '2' and '3'.

compass

A driver for the HMC5843 is upstream. This driver should work with the HMC5883L with minor modifications since both chips are quite similar.

Future work: - Add interrupt handling (new data available)

Barometer / Thermometer

Driver for BMP085 is upstream (in misc/) and works well.

Future work: - Add interrupt handling (new data available)

Gyroscope

Driver for ITG3200 is available from https://gitorious.org/freerunner-navigation-board/itg3200. It exports a quick and dirty sysfs interface. Needs to be cleaned up and a proper interface (input/IIO/whatever) should be added.

Future work: - Add meaningful interface. - Add interrupt handling.

FM radio transceiver

No driver yet

Camera

Not tested

Reboot

Currently fails, possible some pending interrupt isn't cleared at reboot and isn't ignored properly at reboot. Seemed to stop working when audio was enabled.

Future work

Understand problem and fix it.

power-off

Works, but also powers-off battery charger.

Once powered-off only the power-button or an RTC alarm will wake the device.

Future work

• possibly leave battery charger on at power-off

Suspend power saving

Current suspend works but does not save as much power as expected. We expect to draw around 10mA during suspend but actually draw about 65mA.

Future work

Identify cause of power drain and rectify it.

Wake from suspend

• AUX button and serial receive reliably wake from suspend.
• When a USB cable is connected, wakeup sources in the power-management chip, which include Power button, RTC alarm and USB cable events are masked. This problem is understood but the best fix has not yet been determined. When USB cable is not plugged in, these wakeup sources should work.
• GSM incoming should wake from suspend.
• touch-screen tap should wake from suspend.

Future work.

Fix problem with wakeup events from power management chip.

Runtime power management

runtime power management involves powering down individual components when they are not in active use. Ideally this should bring current usage close to suspend current levels when most things are idle.

Currently:

• wifi, USB-port, audio seem to auto-power-down correctly.
• Internal USB (connecting the GSM chip) powers down.
• Bluetooth, GSM need to be explicitly controlled.
• LEDs are naturally low-power when not used.
• GSM does it's own power management.

I have measures about 160mA as lowest idle current drain. We should be able to get below half of that.

Future work

Find out where the power is going.