[Gta04-owner] Sporadic USB charging issue identified

NeilBrown neilb at suse.de
Tue Feb 19 00:19:58 CET 2013

[cc: to list re-added]

On Mon, 18 Feb 2013 19:45:25 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> Am 17.02.2013 um 22:22 schrieb NeilBrown:
> > On Sun, 17 Feb 2013 20:44:14 +0100 "Dr. H. Nikolaus Schaller"
> > <hns at goldelico.com> wrote:
> >> My question now:
> >> 
> >> does anyone know how and where this hysteresis is implemented?
> >> is it in the TPS hardware?
> >> or programmable through registers?
> >> or is it part of the twl4030 USB charger driver?
> > 
> > My guess would be that it is a subtle interplay between the TPS hardware and
> > the twl4030 charger driver.
> > 
> > When the USB voltage drops below 4.4V, the TPS hardware turns off charging.
> > When a cable is plugged in, an interrupt triggers some sort of notification
> > from the USB driver to the CHARGER driver which turns on charging.
> > 
> > In your case, the hardware notices the voltage drop, but there is no "cable
> > plugged in" event.
> > 
> > To delve further I would enable the
> > 	dev_dbg(bci->dev, "BCI irq %02x %02x\n", irqs2, irqs1);
> > line in twl4030_bci_interrupt() in twl4030_charger.c
> > If you have dynamic debugging turned on you can do this with something like
> > 
> >  echo file twl4030_charger.c function twl4030_bci_interrupt +p \
> >> /sys/kernel/debug/dynamic_debugging/control
> > 
> > (I probably have the syntax a bit wrong - there is a file in Documentation/)
> > 
> > Then see if any BCI interrupts happen at the key time.
> > 
> > You might need to look for usb interrupts as well which would be 
> > twl4030_usb_irq() in drivers/usb/otg/twl4030-usb.c.  This currently calls do_notify()
> > which calls through a notifier chain to the charger module.
> > 
> > You possibly need to get twl4030_charger_enable_usb(bci, true) to run after
> > the voltage has stablised again.  Alternately it could be that the USB PHY is
> > being powered down (twl4030_phy_suspend) and not powered up again
> > (twl4030_phy_resume).
> > 
> > I think it is very likely that there is a race somewhere in the software
> > responding to hardware changes.  Once you can identify exactly the sequence
> > of operations seen by the software it shouldn't be too hard to find a way to
> > close the race.
> I have not yet looked for interrupts or alike, but have studied the TPS65950
> charger control registers and looked into the driver code.
> To me it appears that the driver is simply doing the wrong thing based on false
> assumptions that USB unplugging is always detected in the same way by OTG
> and by the charger. But in fact there are two separate detectors.
> If an OTG plug event is detected, twl4030_charger_enable_usb() enables the
> charger by setting TWL4030_USBFASTMCHG=1.
> Now the charger autonomously detects an USB-unplug event because
> VBUSUNPLGEN=1 (default after reset!) and then sets
> TWL4030_USBFASTMCHG=0 which stops charging (but does not generate
> interrupts).
> This is called "hardware method".
> So it is exactly as I did conjecture that the charger is finding VBUS < 4.4V and
> interprets this autonomously as an unplug event. While the OTG interface doesn't.
> And no part of the system takes care of re-enabling the charger because
> neither the hardware nor the OTG driver feels responsible to do so...
> So it is not a race of events, it is simply that there are no events at all.
> IMHO,  the better implementation would be the "software method". This would mean
> that we actively set VBUSUNPLGEN=0. And extend twl4030_charger_enable_usb to
> actively reset USBFASTMCHG on OTG unplug detection.
> But I fear that we don't ever get this into mainline, because this part has
> been written by TI and others.
> And, another reason may be that using the "hardware method" is more
> robust to kernel problems.
> But do you see a chance to get it to mainline if we make this a configure option?
> I.e. Hardware vs. Software unplug detection.
> If yes, I will try to write a patch.

I certainly think the "hardware method" is likely to be more robust, but that
doesn't mean the "software method" shouldn't be used if it provides better
There is no reason to expect an alternate driver wouldn't be accepted into
mainline, providing the code was well written and had appropriate
license/copyright status.   I don't understand your reference  to "written by
TI an others".  What is written by them, and why would that affect mainline

My understanding of the software method (which I haven't examined closely) is
that it requires constant monitoring.  i.e. it sets voltages and needs to
check that the current stays in an appropriate range.  Or something like
that.  Sounds a bit complex.
However there is already a driver that does something like that in the kernel.
I think it is meant to be a generic frame work that other drivers can plug in
to, but again - I haven't looked very closely.

However I'm not yet convinced that all this is needed.  We certainly get an
interrupt when the battery stops charging.  If the problem is that the
voltage disappears and comes back then it would be simple to set a little
watchdog timer whenever the power disappears, to check 100ms later to see if
it is back.
But really, I want to check all the interrupts that we actually get at the
time.  Maybe there is something that triggers when the voltage returns that
isn't obvious from the docs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130219/d6bab9f9/attachment.bin>

More information about the Gta04-owner mailing list