Letux Kernel

Mainline-Status

You are looking at an old revision of the page Mainline-Status. This revision was created by Neil Brown.

Table of Content

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

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 upsteam. 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. I not auto-ejected on suspend.

Driver is upstream.

Serial ports

There are 3 serial ports: Which appears 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 blog 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 occasionally the Power button doesn't.

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, not '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 not yet been configured.

Future work

Configure and 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 one the USB port the device 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.

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

No driver yet

compass

No driver yet

Barometer / Thermometer

No driver yet

Gyroscope

No driver yet

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.

When power is available via USB, sometimes immediately turns on again.

Future work

  • disable STARTON_VBUS at power-off
  • 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 90mA. Some of this might be related to USB.

Future work

Identify cause of power drain and rectify it.

Wake from suspend

  • AUX button and serial receive reliably wake from suspend.
  • power button, USB-plug and USB-unplug usually wake from suspend.
  • RTC alarm sometimes wakes from suspend but not always.
  • GSM incoming does not wake from suspend.

Future work.

  • implement GSM wake-from-suspend (should be easy)
  • understand why RTC and others don't wake reliably.