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 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 works, so when configure you can see messages as soon as boot starts.
Wake from suspend on data-received works (for console at least).
Driver is upstream.
When aggressive power-saving is enabled, the UART is likely to lose or corrupt the first character it receives. This applied to baud rates from 115200 up. Lower baud rates are not affects.
For 3.2, power-saving is enabled by writing a number of seconds to /sys/devices/platform/omap/omap_uart.2/sleep_timeout. For 3.3 you write a number of milliseconds to /sys/devices/platform/omap/omap_uart.2/power/autosuspend_delay_ms. You need to do this to all uarts in 3.2, or both 2 and 3 in 3.3 to be fully effective.
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.
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 is upstream from 3.3-rc1.
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)
The AUX button generates "KEY_PHONE", the power button generates "KEY_POWER".
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. Low-latency click-free audio has been demonstrated using a small stand-alone program to copy the audio from between sound cards.
Wake-from-suspend on incoming call and SMS works.
Driver is upstream, however a small patch to driver is needed to improve power usage. Patch has not been sent upstream.
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
There 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
Device reboots cleanly when requested to.
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 95mA as lowest idle current drain. We should be able to get a lot less.
3.3-rc1 currently doesn't get much below 120mA.
Future work
Find out where the power is going.