[Gta04-owner] Kernel progress
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon May 5 14:45:34 CEST 2014
I have merged linus/v3.14-rc4 - but for unknown reasons it hangs after booting
(and running) udev. Since there are no obvious OMAP patches but some in the
deep guts of the kernel it might be a general bug that will be solved by the kernel
Or one of our non-upstream patches is now conflicting because some kernel API has
1. BMA180 accelerometer
we did have big problems getting it working with the device tree.
The main reason is that we use the drivers/input/misc/bma150.c
which presents acceleration events on /dev/input/accel since ages,
which means that it is already in Neil's 3.7 kernel.
Neil did make it work on the board file kernel back then by a very
simple patch (1 line). But we were very, very, very lucky that
it did work that way reasonable so that nobody did think about
it later on.
The reason for the problems is that only the data registers for
the BMA150 and BMA180 are the same. I.e. reading out values is
done from the same register addresses.
But all other registers are completely different!
So we were lucky that letting the BMA150 driver poke around in BMA180
registers did not do harmful things and was simply ignored or insignificant
and therefore never recognised as a potential problem.
And we were lucky that the BMA180 does automatically start to get acceleration
values and send regular interrupts.
But this also means that there is no power management for the BMA180
because the BMA150 driver is setting the wrong bits. Well, it isn't much
energy but should be approx. 600-900 uA.
A preliminary patched driver is here:
It still has some limitations, e.g. the range and bandwidth and sample
rates can not be properly set. And it is not possible to define gesture
and high-g thresholds. Finally, it does not report correctly scaled values
since the BMA180 has a 14 bit ADC while the BMA150 has only 10 bits.
But this is now just some work to shape it in a way that it can be tested
and works. And finally can be upstreamed.
Marek has invested time and patched the device tree and some error
reports on the kernel log have gone. But it does still not show any sound
the UART problem appears to be solved. It has something to do
with out extensions to connect a virtual GPIO to the "DTR" line to
control the GPS module and the bluetooth power, as soon as the
/dev/ttyO port is opened.
So we know where to look for the problem. But it needs time to really
pinpoint it to some lines of code.
More information about the Gta04-owner