Comment 1 by Nikolaus Schaller, Apr 16, 2014

Locking of the 3.15 kernel has been fixed thanks to a patch by David 
Fries.

But HDQ is still partially broken. During boot it gets two times a 
reasonable value for the 'flags' but afterwards, only 0xff is 
received. This is interpreted as a missing battery (with a printk 
added to the driver):

root@gta04:~# dmesg|fgrep bq27x00_update
[    3.553466] bq27x00_update flags=4
[    9.429595] bq27x00_update flags=4
[   14.966522] bq27x00_update flags=255
[   98.646545] bq27x00_update flags=255
[  213.004882] bq27x00_update flags=255
root@gta04:~#

Comment 2 by Nikolaus Schaller, Apr 26, 2014

More tests have shown that the HDQ controller is more or less 
suddenly stopping to respond or send IRQs (hdq_isr is not called) 
and this leads to ETIMEOUT (-110).
It is not (yet) clear if the HDQ module in the OMAP is failing or 
the delivery of interrupts.
Since we have neither changed the omap-hdq nor the bq27xxx drivers, 
and HDQ did still work on the non-dt kernel it is likely that 
something in the device tree setup (clocks or interrupt 
controllers?) works differently.

Comment 3 by Nikolaus Schaller, May 22, 2014

It appears to break as soon as the special GPIO controllers for 
WLAN/GPS/BT are initialized and hooked up to the DTR GPIO of the 
omap-serial. So we just might see a symptom (irq being lost) 
triggered by something else.

Comment 4 by Nikolaus Schaller, Jun 1, 2014

Appears to be solved by fising the DTR clients.

Comment 5 by Nikolaus Schaller, Jun 2, 2014

Reopened because it is unreliable - sometimes works and sometimes 
doesn't.

Comment 6 by Nikolaus Schaller, Nov 4, 2014

Has been fixed by 3.18-rc3. It was necessary to
* adjust the "compatible" entry to the default in 
omap3.dtsi
* add module aliases to load the w1_bq27000 wrapper and the bq27000 
driver
* add a requestÄ_module call to the w1_bq27000 wrapper

Comment 7 by Nikolaus Schaller, Nov 4, 2014