[Gta04-owner] USB questions

Andreas Kemnade andreas at kemnade.info
Mon Mar 19 20:18:00 CET 2012


On Fri, 16 Mar 2012 11:16:42 +1100
NeilBrown <neilb at suse.de> wrote:

> On Wed, 14 Mar 2012 09:22:07 +0100 Andreas Kemnade <andreas at kemnade.info>
> wrote:
> 
> > Hi,
> > 
> > I have some questions regarding USB.
> > 
> > 1. The most critical thing and the most annoying problem with the GTA04 in
> > general is the fact that GTA04 does not cope with power supplies which cannot
> > provide the full current at some time. Voltage breaks down and the GTA04 does 
> > not use the power supply at all. So the voltage goes up again. Seen with 3.2
> > kernels and 2.6.32. In contrairy GTA02 does not stop drawing power in such 
> > situations. What can be done here? Simply ignore VBus disconnect events 
> > (perhaps until iD is low)?
> 
> Correct.
> 
> The current code always programs the GTA04 to draw (up to) 600mA from the USB
> if 5V appears.  The commandline parameter twl4030_charger.allow_usb=1 says
> this is OK to do.
> 
> If you
>   echo 0 > /sys/modules/twl4030_charger/parameters/allow_usb
> 
> it will stop doing this - then it won't change at all.

Well, that's what it is doing now. Not charging at all in such situations.
My problem is not that the power supply should be protected so that the GTA04
does not toast it with its excessive current. The GTA04 tries just to be
intelligent here and it is not. If it would not detect a VBUS disconnect
event (in auto mode, the charger does that automatically here I found out after
some deep look into the datasheet) everything would be fine. Vbus
would just stay a little bit higher than battery voltage and the battery
would be charged with as much current as possible (that's what GTA02 does).

But does this also mean that if there is a short interruption (even with a
powerful charger) in the power supply GTA04 does not start charging again and
so the battery gets empty despite being connected to a charger which can
deliver a high current? 

Just some words about my charger: It is a bike with a hub dynamo and
a regulator afterwards. The 600mA are no problem if I'm cycling fast enough.
Same problems might also exist with other non-wall-plug-chargers.
I usually do long distance bike travels in summer (>1000km) so that
is a vital problem. That is well approved with GTA02. My ipaq h2200
also did not have these problems.

> [...]
> I suggest you read the  TWL4030 data sheets - the battery charger interface
> section.  Read it several times.  Then go find something easier to play
> with :-) that is what I did.
> 
Well I did have a first look at that section then I decided to write here in
the hope that someone is more familiar with that and has quick answers. Now I'm
digging deeper. 

BCIMFEN4/VBUSVT seems to be interesting. In addition the non-auto mode
also seems to be interesting. Of course, some wild scripting in connection 
with a sysfs control for setting the maximum current might be a last resort.
But then recovering from flat batteries will be difficult.
Maybe placing a simple max1811 charger with a separate connector in the empty
space near the battery might be a hardware solution (if the twl4030 beast really
cannot be tamed).

If I manage to get the maximum current adjusted, I'll send you a patch
for a sysfs control for that. I guess that would be useful for other people,
too.
> 
> 
> > 
> > 2. The usb mode sysfs control does not evaluate what is written to it or
> > am I missing something? (in both 3.2 and 2.6.32). What's going on there?
> > in musb_core.c the platform mode callback is called is called and passed on to
> > but in musb/omap2430.c musb_platform_set_mode() does not evaulate the mode
> > parameter.
> 
> I don't think you can just arbitrarily switch between 'host' and 'gadget'
> mode - which I think is what you are talking about.
> If the ID pin is shorted to ground, you get HOST mode.  If not you get gadget
> mode.
> I think this is a way to swap ends - pulsing the power line or something.
> I think more reading about "OTG" is probably needed.
> 
Hmm, as far as I understand OTG is about how devices can decide who is host.
There is a differentiation between host, otg and peripheral mode in many
places in the code.
If I cannot just be switched in software, the sysfs interface is stupid.
BTW: If I connect ID to GND in 3.2, it stays in host mode, even if
I remove that connection, In 2.6.32 that behaviour is different. So there is
some software control.

Is there somewhere a datasheet of this inventra musb stuff included in the 
SoC? About things like MUSB_DEVCTL

> > 
> > 3. In 2.6.32 there is code in otg/twl4030_usb.c commented out dealing with
> > the OTG_CTRL_DRVVBUS because it is done in mbus. But I cannot find it there.
> > Where is it done?
> 
> drivers/usb/otg/ulpi.c ??
> 
Thats not compiled in. So probably it is done by the inventra musb stuff
in hardware.
> 
> NeilBrown
> 
> 
> 
> > Anyway I found out that clearing DRVVBUS after ID is pulled low gives the
> > opportunity to use it as unpowered and so you can reuse stuff like old special
> > cables created for GTA02 (including USB hubs giving out power to the host side)
> >  if ID pin is low.
> > 
> > Greetings
> > Andreas Kemnade
> > PS: I have not forgotten that si4721 stuff.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120319/99b960de/attachment.bin>


More information about the Gta04-owner mailing list