[Letux-kernel] twl4030 charging

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


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.

7.4.1.1.3 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 7.4.1.2.1 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.

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

BR,
Nikolaus


-------------- 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/60ad940b/attachment.asc>


More information about the Letux-kernel mailing list