[Gta04-owner] Linux 3.2-rc2 on GTA04

[Dr. H. Nikolaus Schaller]

Am 21.11.2011 um 12:32 schrieb NeilBrown:

> 
> Hi,
> I decided that the only kernel that I really wanted to run on my Phoenux is
> current mainline (plus necessary patches of course).
> 
> And I have been paying for that decision - there was a substantial rewrite of
> twl4040-irq recently which broke it.  But I now understand threaded nested
> interrupts and it is all happy again.
> 
> So current mainline kernel + patches boots on my GTA04.  Battery changing and
> monitoring works, as does USB networking (and all the basic stuff of course).
> I haven't tried much else and there is clearly lots to do :-)

Great!

> 
> You can see my current code at
>   git://neil.brown.name/gta04
> The 'merge' branch is a merge of several other branches, currently
> gta04 i2c bq27000 twl4030-irq power
> some of which are tidier than others.
> Also visible at
>   http://neil.brown.name/git/gta04
> but remember to select the "head" that you want.
> 
> You can get my config with
>   make gta04a3_defconfig

I will add a note/links to the gta04-kernel homepage.

> 
> it has lots of debugging options turned on - once it actually starts being
> usable I'll turn a lot of those off.
> 
> This is largely based on David's 3.1 based kernel.  I haven't added anything
> not in there - just fixed things and removed cruft.  e.g. I'm using the
> mainline twl4030_charger rather than the older twl4030_bci_charger.

The problem we had with the mainline driver is that we could not
backport it to 2.6.32. And it was lacking quite some functionality.

After some research we had found out the history. TI submitted a complete
TWL4030 (TPS65950) driver package to mainline. Everything was accepted
except the twl_bci_charger. The reason was that people thought that
it provides a battery driver API, although the chip is a charger and not a battery.
So they insisted on separating the charging functions from battery monitoring.
This took quite a while (I think 2.6.38).

> I plan to regularly rebase all these branches on current mainline, so they are
> more useful for fetching that pulling into a working tree.  I really hope to
> feed a lot of things upstream as soon as they are ready.  bq27000 and

That would be great!

> twl4030-irq are the only bits that are ready at the moment.
> 
> The next big thing I want to work on is proper integration of the LED
> controller - with the 'wlan reset' line looking like a GPIO output rather
> than an LED :-)

Does this matter?

IMHO it is 

	echo "const1" >somepath and
	echo "const2" >somepath

So user space daemons should be able to be configured so that it matches
whatever the hardware/kernel needs.

My idea of the TCA6507 driver was to provide a general I2C LED driver similar
to others. This makes it much more useful to others and raises chance of being
accepted upstream.

That we mis-use one of the outputs as a WLAN reset, should IMHO not be
hard-coded in the kernel or drivers. It could change for future hardware revisions.
E.g. if we use a WLAN module without reset. Or assign a real GPIO.

> 
> But there are bugs I really want to fix too:
> 
> - omap2430.c registers a blocking notifier on an atomic notifier call chain
> - something causes 'udevadm settle' to block for up to a minute at boot.
>   It is very variable and may be related to reading the bq27000 battery
>   status
> - find out why reading battery status is sometimes slow and either fix or
>   hide the slowness.
> - I don't think the battery charger is charging the backup battery (for RTC).

I think this did need some patch on the 2.6.32 as well but I didn't fid it immediately.
And, writing the RTC needs a patch for the MSECURE line.

> - Battery charging doesn't start until I plug in the USB cable.  i.e. if I
>   boot with USB plugged in, I have to unplug and replug before charging
>   works.

This may be related to the order how initialization is done. A similar problem
was with the g_ether in the 2.6.32 kernel. So we have added some
"virtual replugging" code.

> - power-down doesn't - e.g. "halt -f -n -p" doesn't actually shut down.
> - "echo b > /proc/sysrq-trigger"  reboots, but USB networking doesn't work
>   again.  Strangely "reboot -f -n" does end up with USB networking
>   working again.

I remember to add two patches to the hw-validation kernel so that 'halt' really
shuts down:

https://github.com/goldelico/gta04-kernel/commit/d8c5533f5695ec948dea89fba332144644584680
https://github.com/goldelico/gta04-kernel/commit/02817bee826e84aef4cefdb620f2d85ccb300944 (including some non-related modifications)

This may be incomplete because the patches were not pushed in good
logical groups.

> - despite setting a host MAC address for usb networking it very occasionally
>   used a random MAC address of the host.
> 
> - check this:
> [   12.232055] ===============================
> [   12.236419] [ INFO: suspicious RCU usage. ]
> [   12.240783] -------------------------------
> [   12.245147] /home/git/gta04-mainline/drivers/base/power/opp.c:153 suspicious rcu_dereference_check() usage!
> 
> 
> Any suggestions or patches for any of these would be most welcome :-)
> 
> So much to do - so little time!


The more are working together the faster it should go - at least in theory.

BR,
Nikolaus