[Community] [Gta04-owner] GTA04 power management [was: About cost and business models for community hardware]

H. Nikolaus Schaller hns at goldelico.com
Wed Sep 30 10:12:31 CEST 2015


Hi Neil,

Am 30.09.2015 um 01:18 schrieb Neil Brown <neilb at suse.de>:

> "H. Nikolaus Schaller" <hns at goldelico.com> writes:
> 
>> Hi Neil,
>> 
>> Am 29.09.2015 um 02:45 schrieb Neil Brown <neilb at suse.de>:
>> 
>>> "H. Nikolaus Schaller" <hns at goldelico.com> writes:
>>>>> 
>>>>> I think Radek ‘lost interest' because of lack of some of the lower level points in my list above, principally the battery consumption.
>>> 
>>> Battery consumption is the main issue that depresses my enthusiasm.
>>> It *seems* insoluble.  It probably isn't, but I haven't found a way
>>> forward.
>> 
>> I think we should address it a little more analytically.
>> 
>> IMHO we have two problems with more modern kernels:
>> * they do not yet have all features (e.g. we are still lacking e.g. hardware voice routing and some other features)
>> * device tree and CPU power management has changed significantly - and faster than we can understand the changes
>> 
>> Therefore we have no stable basis ("all features work") to optimize power.
>> 
>> Regarding power saving I think we have to address:
>> * all peripherals are properly turned off in power-down mode
>> * RAM is in self refresh
>> * CPU is sleeping in lowest possible state
>> * until a call is coming in, a button is pressed or USB power is plugged in
>> 
>> So which parts are not working well?
> 
> That's the $60,000 question.  The only measurement I have to suggest any
> problem is that the power drain on the battery is too high.  I have
> looked at every component and every driver in every way I know how and I
> cannot see a difference between 4.2 and 3.7, but 4.2 uses nearly twice
> the current in suspend.

Ok, this means suspend current is already down to <50mA.

> All the regulators that can be turned of are off.  All the sensors that
> can't be turned off are in their lowest power state, the RAM refresh
> programming is identical in the two kernels (or I tried copying the
> relevant code from 3.7 to 4.2 and it made no difference).  The CPU seems
> to be reaching the same low-power state.
> There is clearly something that I'm missing, but I'm at a loss to
> identify it.

Ok, there are 4 areas to look at:
1. CPU - power states of the SoC are sort of a black box and might still differ between 3.7 and 4.x
2. RAM - unlikely since you say that programming is the same
3. regulators - there may be regulators that are not properly turned off (although driver says) or regulators w/o driver
4. sensors

Most likely I guess it is something in the SoC.

What could differ - even if the drivers look the same - is the sequence code is executed.
So there may be a dependency on boot order.

Another thing: AFAIK there are differences in the interaction with the boot loader (e.g. pinmux).
I.e. 3.7 kernel may turn something off which 4.x doesn't or vice versa. So if you
look what is turned on, you may miss it.

> 
>> Is this related to our code or to CPU core driver?
>> How (well) does the N900 (RX51) mainline code handle this?
>> 
>>> 
>>>> 
>>>> Well, with 3.7 it was almost good.
>>> 
>>> I would say 3.7 is just barely usable - if you have a new battery.
>>> 
>>>> 
>>>> A problem for me is that QtMoko has some very nice tools to support battery consumption measurements. But because it does neither run on 3.12 or later kernels, we can’t even test battery consumption easily. How to improve the kernel if a good GUI is missing.
>>> 
>>> Measuring battery usage isn't that hard.  In the simplest case you just
>>> need to log the time (seconds) and the charge-now value from the
>>> bq27000 and graph those.  I log them on every 'suspend' and 'resume' so I
>>> can easily get data.
>> 
>> Yes, there are other techniques, but QtMoko already provides such
>> tools.
> 
> But as QtMoko is not available, that doesn't seem relevant.

Well, if someone else should help testing and finding out, it needs a working test
environment. Using QtMoko appears to be a good candidate to give into the hands
of a tester.

Otherwise, people helping to test (or trace down bugs) need a good description
how to operate the setup.

> 
>> 
>>> 
>>> I find it a bit harder at present because all of my batteries with
>>> bq27000 in them have died.
>> 
>> Oops. How does this come? I now have the first of several that appears
>> to have a problem (charges within short time and is then empty...).
> 
> I don't know much about battery chemistry, but I assume there is some
> shelf-life issue.
> 
>> 
>>> I've got a Nokia BL-5C in my phone at the
>>> moment.
>>> I ripped the bq27000 board off one of the dead batteries and managed to
>>> attach it to another BL-5C so I can do measurements, but only on my old
>>> "spare" board (which has lost its USB connector so I need WIFI for all
>>> networking...)
>> 
>> For the GTA04A5 board there will be an additional bq27621 chip on the main
>> board to measure battery status. So even a battery w/o bq27000 can be measured.
>> But I don't know the precision.
> 
> That's an excellent idea.  In the battery is best of course, but on the
> board as well means we don't have to depend on the battery.

And the good thing is: if a HF08 battery is uses, there are two status meters
that can be compared.

> 
> 
>> 
>>> 
>>> If I could even get current mainline down to 3.7 power usage levels I'd
>>> probably be motivated to keep working on upstreaming things, but I've
>>> hit a brick all there too.
>> 
>> The question is in which subsystem the problem is located? Where do
>> you hit bricks? What is not working as you expect?
> 
> As I said only one thing is not working as expected.  Power usage is too
> high.

Could you share a complete description of your setup? So that it is reproducible?
I.e. which kernel, which user space, command to suspend/wakeup, boot loader
version, how you measure suspend current etc.

Every bit of information may hide the answer to win the $80.000
(which nobody knows if it exists).

BR and thanks,
Nikolaus

> 
> Thanks,
> NeilBrown
> 
>> 
>> Probably we should discuss more about such issues and help
>> each other instead of individually trying to run against walls in small
>> black boxes.
>> 
>> BR,
>> Nikolaus




More information about the Community mailing list