[Letux-kernel] twl4030 charging

H. Nikolaus Schaller hns at goldelico.com
Tue Jul 26 17:57:17 CEST 2016

Hi Andreas,
things are becoming more strange...

> Am 26.07.2016 um 10:57 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> Hi,
>> Am 26.07.2016 um 08:58 schrieb Andreas Kemnade <andreas at kemnade.info>:
>> On Mon, 25 Jul 2016 21:50:34 +0200
>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> [...]
>>> So what does that mean?
>>> I have studied the source code a little more and have tried to
>>> understand twl4030_charger_update_current().
>>> That function sets several limit current values for comparators (in a
>>> way that I must admit that I don't understand at all - strange bit
>>> patterns not directly related to the data sheet).
>>> Now what could be is that these calculations are wrong. And set the
>>> wrong bit patterns so that the charger stops immediately. But what
>>> "immedialtey" means depends on the speed of the BCI ADCs and might
>>> also depend on hardware induced noise.
>> Well, I disabled the ADC magic there and set the current directly to
>> the target setting. But that does not help. I suspected the there would
>> be some conflict between ADC access from code and via BCI/USB
>> twl4030-internal.
> I had tried that as well with no significant change.
>>> Another thought is that since the battery is connected in parallel
>>> with the system to the charger, this means that all current
>>> measurements are based on the sum of the charging current + system
>>> demand.
>>> So such current limits heavily depend on the system load - and mixed
>>> with battery quality. Here the driver might make assumptions that are
>>> not always true. This might explain why it works on some devices and
>>> doesn't on others. Which must be some hardware dependency.
>> Hmm, perhaps low battery current (even because of low usb current) ->
>> false conclusion: battery is full -> stop charging.
> Ok! Yes, that is a plausible explanation.
> Especially as I get a ICHGLOW interrupt!
> Perhaps there is some code missing that restarts charging after ICHGLOW
> is detected and prevent auto-shutdown.
>> Seen that often
>> during my experiments with disabling VBUSUNPLUGEN.
>> That might be triggered by the timing of setting current limit
>> (max. Iusb, end-of-charge-current, etc.) registers.
> It looks as if twl4030_charger_update_current() is called 2 or 3 times
> with 500mA (default) before charging is enabled. So the current limit
> should be set properly. And it should be updated by the ICHGLOW
> interrupt.
> Unfortunately I did not yet understand Figure 7-5. Main Charge State-Machine
> yet...
> And what I don't understand is why there is no VBUS detection any more
> and MADC also reports VBUS 0mV. Without unplugging the cable...
> So something else must be shut down automatically which should be
> enabled for VBUS detection and measurement.
> VBUSUNPLGEN can control if charging automatically stops on VBUS
> going below threshold or if software must do it actively. But there is no
> code to enable/disable. So I think it is on by default.
> VBUS Detection
> says that there is a (fixed) threshold of 4.4V.
> Or - maybe - I should study the USBFASTMCHG and USBSLOWMCHG
> bits.
> One sentence makes in General Description me wonder if it
> is implemented correctly:
> 	• When the USB charger is plugged in, the software detects the
>          type of device (USB charger or carkit charger). The software
>          must set the POWER_CTRL[5] OTG_EN bit to 1 at least 50 ms
>          before forcing the BCIMFSTS4[2] USBFASTMCHG bit to 1.
> I have not seen any mdelay() for such a condition... And no i2c_write to
> control this OTG_EN bit in the charger code.
> It is done in the phy code:
> http://lxr.free-electrons.com/source/drivers/phy/phy-twl4030-usb.c#L329
> So I should add some printk() there and check the timing relationship.
> Indeed there is some timing relation because twl_bci probing fails until
> twl_phy succeeds. And the VBUS event may come earlier than 50 ms
> after that.

first observation: OTG_EN would be set by twl4030_usb_set_mode()
but that is never called!

> All this does not explain why VBUS reports 0mV and why it does not
> work on second attempt (cable unplug/replug) or if the GTA04 is booted
> w/o cable and USB plugged in later.
> But let's see.
>> So maybe
>> simplifying that. I thought I have already done that. I will try again.
>> Regards,
>> Andreas

Now the strange thing:

I have booted our kernel on the BeagleBoard XM (with Openmoko Panel).
This should exclude any hardware issue - because it does not even
have a battery connection and charger...

But the behaviour is almost the same.

No ethernet gadget, register shortly showing 0x1b and falling back
to 0x12 indicating that ITHEN has been disabled.

And something I already had observed on the GTA04 but thought
it is some background process.

There are spurious writes to twl4030. Unrelated to charging and USB.
At least it appears so.

To some register "5e" translated to "b9" and coming from section
TWL_MODULE_PM_RECEIVER (whatever this is).

It alternatingly writes 0x30 and 0x21.

I have not yet researched what it is - it *might* be some LEDs connected
to the twl4030.

Apropos LEDs. This was also strange on BB XM. Some LEDs are
initialized to show the heartbeat. This was slow and irregular. Until
I pressed the touch screen. After releasing it became irregular again.
After pressing the AUX button it became normal. Even after release.

The only reason I know for such things is I2C congestion.


Problem becoming more complex than ever before.

BTW: we have some

[    9.471618] ===============================
[    9.476013] [ INFO: suspicious RCU usage. ]
[    9.480377] 4.7.0-letux+ #565 Not tainted
[    9.484588] -------------------------------
[    9.488983] include/trace/events/rpm.h:63 suspicious rcu_dereference_check() usage!
[    9.497009]
[    9.497009] other info that might help us debug this:
[    9.497009]
[    9.505401]
[    9.505401] RCU used illegally from idle CPU!
[    9.505401] rcu_scheduler_active = 1, debug_locks = 0
[    9.516784] RCU used illegally from extended quiescent state!
[    9.522796] 1 lock held by swapper/0/0:
[    9.526824]  #0:  (&(&dev->power.lock)->rlock){..-...}, at: [<c048b418>] __pm_runtime_suspend+0x20/0x7c
[    9.536743]
[    9.536743] stack backtrace:
[    9.541290] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-letux+ #565
[    9.548217] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    9.554809] [<c010f0e0>] (unwind_backtrace) from [<c010b6d8>] (show_stack+0x10/0x14)
[    9.562957] [<c010b6d8>] (show_stack) from [<c03ed230>] (dump_stack+0x98/0xd0)
[    9.570526] [<c03ed230>] (dump_stack) from [<c0489ad8>] (rpm_suspend+0x124/0x714)
[    9.578369] [<c0489ad8>] (rpm_suspend) from [<c048b428>] (__pm_runtime_suspend+0x30/0x7c)
[    9.586975] [<c048b428>] (__pm_runtime_suspend) from [<c0426c04>] (omap2_gpio_prepare_for_idle+0x4c/0x5c)
[    9.597015] [<c0426c04>] (omap2_gpio_prepare_for_idle) from [<c0120238>] (omap_sram_idle+0x94/0x228)
[    9.606597] [<c0120238>] (omap_sram_idle) from [<c012048c>] (omap3_pm_idle+0xc0/0x264)
[    9.614898] [<c012048c>] (omap3_pm_idle) from [<c0107ae0>] (arch_cpu_idle+0x18/0x3c)
[    9.623016] [<c0107ae0>] (arch_cpu_idle) from [<c017606c>] (cpu_startup_entry+0x20c/0x364)
[    9.631683] [<c017606c>] (cpu_startup_entry) from [<c0a00bec>] (start_kernel+0x32c/0x398)
[    9.640258] [<c0a00bec>] (start_kernel) from [<8000807c>] (0x8000807c)

This type of error might leave the whole system in a wrong state. Especially if it is related
to pm_runtime_suspend

Any idea what "RCU" is?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20160726/6d0d13a7/attachment.asc>

More information about the Letux-kernel mailing list