You are looking at an old revision of the page Mainline-Status. This revision was created by Neil Brown.
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.
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.
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.
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.
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.