Re: How is gta01 charger ID resistor detected?
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
How is gta01 charger ID resistor detected?
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
RTC failure in January (was: New significant speedups coming to FreeRunner)
On Mon, 18 Jan 2010, Neil Jerram wrote: > One more possible issue with this kernel. The boot messages always say > > [21474539.53] pcf50633-rtc pcf50633-rtc: hctosys: unable to read > the hardware clock I'm seeing this on my build from a recent git pull as well. It also has the unpleasant side effect of also failing to set the time on resume so the clock seems to lose time during any suspend. :-( I finally looked into it, and this is the problem (with RTC debugging enabled): [21474537.86] pcf50606-rtc pcf50606-rtc: PCF_TIME: 24.00.10 06:26:41 [21474537.86] pcf50606-rtc pcf50606-rtc: RTC_TIME: 24.4294967295.110 6:26:41 [21474537.86] pcf50606-rtc pcf50606-rtc: hctosys: unable to read the hardware clock That month fails rtc_valid_tm(), leading to the EINVAL. The commit/fix Werner made last April seems to be not interacting well with the zero-based month count in the pcf50606 RTC (set, in my case, by an old kernel I booted at some point in January): diff --git a/drivers/rtc/rtc-pcf50606.c b/drivers/rtc/rtc-pcf50606.c index e059093..434cfc1 100644 (file) --- a/drivers/rtc/rtc-pcf50606.c +++ b/drivers/rtc/rtc-pcf50606.c @@ -70,7 +70,7 @@ static void pcf2rtc_time(struct rtc_time *rtc, struct pcf50606_time *pcf) rtc->tm_hour = bcd2bin(pcf->time[PCF50606_TI_HOUR]); rtc->tm_wday = bcd2bin(pcf->time[PCF50606_TI_WKDAY]); rtc->tm_mday = bcd2bin(pcf->time[PCF50606_TI_DAY]); - rtc->tm_mon = bcd2bin(pcf->time[PCF50606_TI_MONTH]); + rtc->tm_mon = bcd2bin(pcf->time[PCF50606_TI_MONTH]) - 1; rtc->tm_year = bcd2bin(pcf->time[PCF50606_TI_YEAR]) + 100; } Since hwclock does a read before a write of the RTC, we can't fix this as easily as one might think. I guess in another 7 days it will be working again. :-) I was able to escape the catch-22 by booting an old kernel, setting the RTC to a date in February 2010 with hwclock and then booting the new kernel again. -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
SHR buildhost: unstable gta01 images gone?
The http://build.shr-project.org/shr-unstable/images/om-gta01 directory has seemingly vanished. The om-gta02 directory is still there. Is this permanent? That was my favorite place to get kernels. :( -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 "snappy" can the Openmoko GUI get using GTK?
On Mon, 3 Sep 2007, I wrote: It's all appropriate in a development environment - we just have to factor that in when considering the responsiveness of the device. IMO it's appropriate for the primary focus to be functionality and the secondary focus to be user interaction effectiveness at this point. Just to be clear, by "user interaction effectiveness" I meant the interaction paradigms used and the use case solutions. Not response time... -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How "snappy" can the Openmoko GUI get using GTK?
On 2 Sep 2007, at 14:57, denis wrote: Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being "snappy". (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and "snappy" can the Openmoko GUI using GTK get? I'm looking at this from the user point of view, I'm not a developer so it would be very interesting to me what can be expected in the future. What are you're expectations? Will it get as snappy as the old PALM Pdas had been? I haven't seen anyone else mention the obvious: some of the device drivers and alot of the code have debugging output enabled. Start the X server manually, and watch the debugging info spew forth, and you'll get an idea where a bunch of CPU cycles are going. As an example, every stylus press results in at least 4 debugging msgs printed, something happening in a place I would consider latency-sensitive. In addition various things complain constantly of missing icon image files, etc... things that would surely be cached if they were present, and those complaints take cycles. It's all appropriate in a development environment - we just have to factor that in when considering the responsiveness of the device. IMO it's appropriate for the primary focus to be functionality and the secondary focus to be user interaction effectiveness at this point. -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Lars Hallberg wrote: This is a new one (Layout is 'numlock' one): http://www.micropp.se/openmoko/res/key2key.py denis wrote: I've tested the input system and it works very well even for a beginner like me. It is very intuitive and after a short time of practice I'm very fast writting with it. Though I was skeptical due to the apparent complexity in the description :-) I also found it fairly easy to use even without practice. Nice one, Lars. -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: VMWare-Image (again)
On Wed, 8 Aug 2007, S??bastien Lorquet wrote: Okay the first image is bitorrenting at: http://tracker.unsads.com/torrents-details.php?id=3 I'm now leeching, then I'll be another seed... in roughly 18 hrs it looks like. -Andy___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Landscape mode
On Sun, 5 Aug 2007, Krzysztof Kajkowski wrote: 2007/8/5, Andy Poling <[EMAIL PROTECTED]>: Here's an capture of dillo with the 2007.2 window management framework in landscape: This is VERY nice! Did you think of writing down how to do that on openmoko wiki? I just flashed alphaone's 2007.2 images, and then I did an "xhost +" on my neo (danger - insecure), and on my desktop ran "DISPLAY=192.168.0.202:0 dillo". I didn't mean to mislead anyone into thinking I had built dillo for openmoko. I'm just running apps from my desktop displaying on my neo to get a feel for what they look like on the neo's screen and what the interaction feels like. Here's a somewhat absurd example :-) http://www.realbig.com/firefox.png -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Landscape mode
I've been experimenting with landscape mode display and running remote X apps from my desktop to see how they work. Quite a few things seem better in landscape, maybe because I'm used to having to scroll vertically to see the whole page, but scrolling horizontally feels strange. Here's an capture of dillo with the 2007.2 window management framework in landscape: http://www.realbig.com/dillo_landscape.png -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2007.2 - questions
On Fri, 3 Aug 2007, Thomas Gst??dtner wrote: If you want to try it, you can take a look at alphaone's builds http://people.openmoko.org/alphaone/images/ They work for me, but they are very (and I mean very!) basic. I tried alphaone's build, and I must say I like what I see. I was able to pretty quickly grasp the UI paradigms (something I'm still struggling with on .1), and I like the fact that the main buttons are larger and easier to use. I can't find a way to power off under .2 though. :-) -Andy PS - That reminds me... am I the only one who thinks you should be able to select "power off" from the battery status icon?___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 3G sim cards
Many people (including I) have not been able to get the at&t 3g sim card (the one with the "3g fireball") working in our neos. The older cingular ones do work (they are "64K smart chip"). I have two cingular "64K smart chip" SIMs that won't work in the neo1973 (CME 10), but they both work in both my razr and sierra ac860 card. Both SIMs are about 9-10 months old now - maybe they changed a while back while keeping similar markings? On the back, one says "3G" (with a tiny "c" after it) and has the numbers 64205G and 3020. The other also has 3G(c) and has 64205O (capital "o") and 4020. I dug up an old SIM (also cingular) that does work (so I know the GSM chip and SIM socket aren't faulty), but that account is no longer active. -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
