On Wed 28 August 2013 00:29:18 NeilBrown wrote: > On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown <ne...@suse.de> wrote: > > On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller" > > > > <h...@goldelico.com> wrote: > > > Hm. That sounds quite different from the situation about 1 year ago > > > when you did the first releases of QtMoko and I always thought that > > > the 3.7 kernel is working well enough, so that I started to add new > > > features. > > > > > > Has it become worse since then? > > > > I like drawing graphs. So I did - see attachment. > > > > For the last year or so my GTA04 has been logging the power usage during > > suspend for every suspend cycle longer than a few seconds. I do this by > > reading the "charge_now" value from the bq27000 in the battery, comparing > > the "before" and "after" values, and dividing by the number of seconds. > > > > I currently have my phone configured to wake from suspend every 5 > > minutes, check that the modem is still working, and go back to suspend. > > This has helped collect quite a lot of values. > > > > To get the graphs I collected all those values, discarded negative > > numbers (when the battery was charging) and a few numbers that were > > clearly ridiculous (numbers more than 1 amp), and sorted the remainder. > > > > > > So we get a cumulative frequency graph of different current levels. > > > > The red line ('/tmp/uamp') is for the last couple of days since last > > reboot. This is running 3.7 with offmode disabled. > > The green line ('tmp/uamp2') is for the last year, running a variety of > > different kernels. > > > > Obviously there is a very different number of samples in each. 342 in > > uamp 10031 in uamp2. So I normalised the X values so the graphs are > > comparable. They are much the same shape which suggests the pattern is > > fairly robust. > > > > The Y axis is microamps. > > The green values below 20000 (20mA) are with offmode enabled I assume. > > The red values are all greater because I have offmode turned off to > > improve reliability. > > > > The steps are a bit of a surprise. They are all about 2mA. I don't > > think this is an artefact of the precision with which measurements are > > taken as the charge value read from the battery has a much higher > > precision. > > I think it must be an actual 2mA difference in (average) current usage. > > This could be 2mA more for the whole time, or 4mA more with a 50% duty > > cycle etc. > > > > So if we can make off-mode really usable (which possibly means find and > > fix some bug in the omap usb code) and if we can find out what is > > causing these 2mA steps and resolve that, then might might be a little > > closer to acceptable power usage. > > > > I might try running for a while with the modem turned off and see what > > result I get. > > Here are results with modem powered off. > > 1/ The minimum current is higher!!! without the modem at work. - 28mA > rather than 24mA. > 2/ The maximum is much lower. 36mA vs 97mA. > 3/ We still see a 2mA step. Most of the values are 30mA or 32mA. A few > are 2mA lower, or 2,4,6 mA higher (roughly). > > This is very strange. The very rare high values when modem is working are > quite believable. The steps and the high minimum are harder to explain. > > Suppose some parallel bi-directional buss ended up in suspend with both > ends driving outputs. Suppose also that if they were driving the same > value it would cause minimal current drain, but if they were driving > different values it would cause 2mA drain on each line that was > unbalanced. > Then if the actual output bits on one side were random as we enter suspend, > we would see a range of different multiples of 2mA in current drain. > > If this parallel bus were related to the modem, then when the modem wasn't > in use we would see much less variability. But maybe higher average as > some bits might stuck on a "bad" value. > > Now there is a bi-directional bus between the OMAP and the USB PHY. But I > would be very surprised if both (or either) side were driving outputs on > suspend, and I count at least 12 steps in the green line, so it would have > to include the 8 data line and 4 control lines ... which is getting > increasingly unlikely. > > I might be able to try holding the PHY in reset during suspend. That > should force all pins to tri-state. However first I think I'll try 15 > minute suspends rather than 5 minute and see if that makes a difference. > > Is there another credible explanation for the 2mA steps? > > NeilBrown
check ULPI. also check the bus from CPU to musb core. And why would both ends need to be driven? In my book a 2mA is sth like 1.8V into 1kR termination, for example /j -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (alas the above page got scrapped due to resignation(!!), so here some supplementary links:) http://www.georgedillon.com/web/html_email_is_evil.shtml http://www.nonhtmlmail.org/campaign.html http://www.georgedillon.com/web/html_email_is_evil_still.shtml http://www.gerstbach.at/2004/ascii/ (German)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community