Re: How is gta01 charger ID resistor detected?

2010-01-26 Thread Andy Poling
On Tue, 26 Jan 2010, Ben Wilson wrote:
 I could be wrong, but I thought the 47K resistor cable ID feature was
 one of the things they added into GTA02.
 I assumed GTA01 didn't have it.

It's there in the hardware, according to the schematics.  :-)

I've spent some quality time today with the gta01 schematics and pcf50606
docs, and I understand a little better now how this is supposed to work.  The
USB ID pin is connected to the ACD (accessory detection) pin on the pcf50606,
and the 47k (48K in the schematic) resistor will pull the pin down to approx.
1.5V.

Something is setting the ACD threshold (probably u-boot), but nothing is
handling the ACDINS (insert) or ACDREM (remove) interrupts.  I found that
pcf50606-charger.c is not setting up those interrupts to be handled.
Additionally, I found this in arch/arm/mach-gta01.c:

/* TODO */
static void gta01_pmu_event_callback(struct pcf50606 *pcf, int irq)
{
/*TODO : Handle ACD here */
}

OK - that answers that question.  It hasn't been handled, at least since the
new split set of pcf50606 drivers were introduced.  Looking at the original
monolithic pcf50606 driver, it was handled there.  It looks to me like none of
the other MBC-related interrupts are currently being handled either for the
same reason.

By adding ACDINS and ACDREM to the list of IRQs to handle in
pcf50606-charger.c and by adding 6 lines of code in gta01_pmu_event_callback()
to handle them by setting/unsetting AUTOFST, I can now see AUTOFST being
enabled and disabled when I plug and unplug my charger cable with the ID
resistor.  It's a quick hack, but it shows it can work.

I guess I know what my next project will be.  :-) I'll take that to the kernel
list.

-Andy

It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so. - Mark Twain

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: How is gta01 charger ID resistor detected?

2010-01-25 Thread Ben Wilson
I could be wrong, but I thought the 47K resistor cable ID feature was 
one of the things they added into GTA02.
I assumed GTA01 didn't have it.

Ben.

Andy Poling wrote:
 I have made a couple of custom charging cables for use with my gta01 and dumb
 USB chargers (selected because they were rated at least 500ma).  I made the
 cables by connecting a 47K resistor between the ID pin and ground leads.

 However, after struggling with constantly inability to reliably charge my
 gta01 on dumb chargers, some investigation has shown that the phone (running,
 at the moment, a recent git pull) is settling into trickle charge despite the
 presence of the ID resistor.

 What is supposed to detect the resistor?  What happens when it does?  How can
 I tell if it's working?

 I've modified the pcf50606 reporting in my kernel to reveal more bits of the
 registers to track this down.  I've changed the charger sysfs online attribute
 to use the low bit of CHGVINSTAT for bit 0 and CHGAPE for bit 1.  I've changed
 the chgmod attribute to also reveal the CHGAPE and AUTOFST bits.

 The first thing I noticed is that CHGVINSTAT is always set, even when there's
 no charger present.  I don't know why.  That seems contrary to the pcf50606
 spec.  It's possible it's a bug in my change to the driver.

 But the real problem I noticed is that AUTOFST is getting cleared when a cable
 with the ID resistor is connected.  Here's a log made by a shell script
 monitoring changes in the values reported through sysfs as I unplugged from my
 desktop and then plugged into a dumb charger with my modified cable:

 Jan 24 23:47:50 neo logger: BATSTAT=Charging BATCHG=100 CHARGER=3 
 CHARGEMODE=15
 (bits set indicate CHGAPE=1, AUTOFST=0, CHGMOD=fastcccv)
 ** unplugged from desktop USB **
 Jan 25 03:24:02 neo logger: BATSTAT=Discharging BATCHG=100 CHARGER=3 
 CHARGEMODE=31
 (bits set indicate CHGAPE=1, AUTOFST=1, CHGMOD=idle)
 [...]
 Jan 25 03:28:03 neo logger: BATSTAT=Discharging BATCHG=94 CHARGER=3 
 CHARGEMODE=31
 ** plugged into dumb charger and modified cable **
 Jan 25 03:28:34 neo logger: BATSTAT=Charging BATCHG=96 CHARGER=3 CHARGEMODE=5
 (bits set indicate CHGAPE=1, AUTOFST=0, CHGMOD=precharge)
 [...]
 Jan 25 10:53:46 neo logger: BATSTAT=Charging BATCHG=23 CHARGER=3 CHARGEMODE=5
 ** unplugged from dumb charger and modified cable **
 Jan 25 10:54:16 neo logger: BATSTAT=Discharging BATCHG=18 CHARGER=3 
 CHARGEMODE=29
 (bits set indicate CHGAPE=1, AUTOFST=0, CHGMOD=idle)
 [...]
 Jan 25 10:56:48 neo logger: BATSTAT=Discharging BATCHG=20 CHARGER=3 
 CHARGEMODE=29
 ** plugged into desktop USB **
 Jan 25 10:57:18 neo logger: BATSTAT=Charging BATCHG=43 CHARGER=3 CHARGEMODE=15
 (bits set indicate CHGAPE=1, AUTOFST=0, CHGMOD=fastcccv)
 [...]
 Jan 25 10:59:19 neo logger: BATSTAT=Charging BATCHG=56 CHARGER=3 CHARGEMODE=15

 As you can see, I never get more than trickle charge when on the dumb charger
 and modified cable.

 Along the way I encountered several things about the pcf50606 MBC control
 driver that I think can be improved/fixed.  I guess I'll take that discussion
 to the openmoko kernel list.

 -Andy

 It ain't what you don't know that gets you into trouble.
 It's what you know for sure that just ain't so. - Mark Twain

 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 


 No virus found in this incoming message.
 Checked by AVG - www.avg.com 
 Version: 9.0.730 / Virus Database: 271.1.1/2645 - Release Date: 01/26/10 
 08:36:00

   

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community