On Mon 26 August 2013 13:17:09 Radek Polak wrote: > On Saturday, August 24, 2013 03:20:10 PM joerg Reisenweber wrote: > > On Sat 24 August 2013 14:22:55 Radek Polak wrote: > > > 1/ poor power management > > > > [...] > > > > > something. But i always worked in userspace. I barely understand kernel > > > and i have no EE skills and equipment to contribute. I can contribute > > > only as a tester. I thought that i will deliver working userspace and > > > IMO QtMoko is very good at it. But without working kernel and HW there > > > is not much point to improve it. > > > > many thanks for this contribution, it's already a better help than much > > of the discussion about what's wrong with our community and the GTA04 > > project at large. > > > > However one remark about it: it's not that simple to blame kernel for > > poor power management. What we learned from last maybe 6 years of > > different OM distros and from maemo and mer and nitdroid etc is: poor > > power management is way too often caused by userland, like sensorfw and > > WLAN connection manager and X11/windowmanager and audio (alsa/PA) and > > whatnot else. > > Yup, after playing with alsa settings i could save a few mAmps on GTA04 > too. > > > Often it's even rogue apps that do silly stuff like updating their system > > status icon 25 times per second or constantly chatting with internet or > > even just polling files when you should use inotify instead. > > Kernel power saving measures are relatively simple to test and fix, and > > usually it's not kernel to blame for abysmal standby time and/or > > operation time. > > > > To give you a simple example: on N900 maemo you have "scanning period" in > > settings-internet, which makes device scan for WLAN APs only every 5, 10, > > ... even 30 min. This is needed since the WLAN chip cuts thru the battery > > in less than 3 hours when you constantly scan for APs. Clearly a userland > > issue where kernel can't do much. Now you can start to blame kernel WLAN > > driver for not doing proper powersaving but that won't help establish a > > decently working usable OS on N900. > > I think in case of QtMoko on GTA04 we can blame kernel/HW a little bit > more, since we are using suspend to RAM whereas N900 is always on (which > really cool btw). So while GTA04 is in standby there should be idealy just > PMU+RAM+modem turned on, everything else should be off. But something is > wrong and noone has yet figured what it is. At best there is ~16mA with > omap enable_off_mode - but then we hit "imprecise external abort" bug so > currently we have ~22mA at best. If you compare this with GTA02 or N900 > it's really bad. GTA02 is 12mA and i'd say N900 is even better. Together > with reenumerating modem it makes GTA04 barely usable even for a few > hardcore supporters but unusable for normal users. > > Regards > > Radek
Yes, absolutely (I can't confirm neither deny your facts). N900 easily goes down to ~10mA in *standby*, see http://wiki.maemo.org/N900_Hardware_Power_Consumption and also http://wiki.maemo.org/N900_software_power_management What I can think of are floating lines making chips eat more than they should - may particularly due to suspend mode. Let's hope we'll iron that out during next few months cheers jOERG -- () 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
