[Gta04-owner] Donations to investigate suspend current?

Dr. H. Nikolaus Schaller hns at goldelico.com
Thu Apr 10 14:56:57 CEST 2014

Hi Ben,

Am 10.04.2014 um 14:23 schrieb Benjamin Deering:

> On 04/10/2014 03:06 AM, NeilBrown wrote:
>> On Thu, 10 Apr 2014 08:26:34 +0200 Christoph Mair<christoph.mair at gmail.com>
>> wrote:
>>> Am 10.04.2014 01:49 schrieb "Benjamin Deering"<ben_deering at swissmail.org>:
>>> Measuring less than 20mA with thermal imaging is quite hard, especially if you've got a multilayer board with lots of copper in it which spreads the heat... 
> Thanks for the response, I wasn't sure of the limitations of thermal imaging.
>> Would it make sense to collect donations specifically to fund some
> thermal imaging to see what has changed?
> Is there another specific goal that requires funding?  This is assuming that people are more likely to donate for a specific project than a general one.

Well, 3.7 is working quite well - but has limitations in power management. 3.12 is working almost on the same level of functionality (only the 3D-GPU driver is missing), but AFAIK nobody did look into power management yet. So it is quite unknown if it is better or worse - and in which areas.

But: the biggest challenge ahead is to stabilize 3.15ff.

Why shouldn't we simply stick with 3.7?

IMHO because 3.14 already is a major breakthrough into a brighter future. We have almost everything converted to "Device Tree". And after that is done, we do no longer have to maintain some of our own patches, because the mainline kernel is fully concentrating on the device tree based devices. Therefore we are also trying to upstream our diffs (I submitted 4 simple patches today). Patches coming from linus/master will then no longer make big problems as in the past and tracking will just need a git merge linus/master.

So it can be expected that future (of 3.16 and later) kernel improvements will come almost for free. Maintenance to get security fixes and new kernel features will become much simpler because our kernel is less and less deviating from kenrel.org (we already have reduced 142 significant diffs to 104 from 3.14.0 to 3.15-rc0).

Work invested on 3.7 or 3.12 needs additional forward-porting to 3.14ff - and some fixes might be completely incompatible - or no longer needed because someone has worked on it in parallel to us and found a different solution. Don't forget, there are different boards and groups which share most of our hardware: BeagleBoard-XM and Gumstix Overo "Fire" (even uses the same WiFi/BT combo) and OpenPandora (to a smaller extent). There is also an OMAP3 based IGEP board or even N900/RX51. All these groups may have people who optimize the kernel (for themselves and us).

As soon as we have 3.15 working, we can spend more efforts into optimizing power management. But for that we need a working and bug free basis first. This is what we (marek, lukas, myself) are currently working on and pushing.

>> I could easily be wrong, but I think that a lot of the remaining power drain
>> is related to the USB interface to the Option 3G chip.
>> I'm certain that the drive for the EHCI interface on the OMAP3 has power
>> management issues.  I suspect there might be interactions between it and the
>> usb transceiver (parallel to serial converter) which waste power too.
> I thought disabling usb during suspend saved a lot of power on 3.7 as well, but I may be remembering it wrong.

Yes, it is disabled during suspend, but what Neil has found out is that the disabling might effectively increase the power drain of the USB chip because of an unknown leakage current. Something there works differently than described in the data sheets (if it is specified at all). And it is difficult to analyse because there is no room to connect an oscilloscope or amperemeter...

>> Unfortunately the only way I can think of to make progress is to pour over
>> the code in detail, read as much documentation for the EHCI interface as I
>> can find, and try some things out.  i.e. lots and lots of work with no
>> certainty of reward.
> That sounds like it would be beyond my abilities, but I may take a look at what changed.

The problem IMHO is that this works almost autonomously between the EHCI controller and the USB-PHY chip.


More information about the Gta04-owner mailing list