Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
Mihail Zenkov:
--- Quote from: saratoga on June 04, 2015, 09:07:12 PM ---
--- Quote from: Mihail Zenkov on June 04, 2015, 07:09:42 PM ---Now I know - why read speed was three times slower than write :)
http://gerrit.rockbox.org/r/#/c/1191/
--- End quote ---
Does that flip read and write?
--- End quote ---
Yes.
--- Quote from: saratoga on June 04, 2015, 09:07:12 PM --- Does your patch change the timer frequency?
--- End quote ---
No. We should change it. But it hardcoded as define: if we fix it at boost clock we get 100hz at boost and 20hz at normal. I try it and have problem (5 times longer) with lcd timeout and idle/shutdown timeout.
In any case it not root of freezes. We should find why it freeze. If it freeze because we have interrupt between pmu settings we should disable irq. Or possibly we have some task (called from call_tick_tasks) that also need access to codec registers.
Mihail Zenkov:
--- Quote from: saratoga on June 04, 2015, 09:08:30 PM ---We do have a mono mode. If setting the hardware to mono really helps, I don't see why not.
--- End quote ---
I try it today - no success. Codec don't pack two 16-bit samples in one 32-bit register (as in stereo mode). It just ignore second sample.
LolaPalocz:
Current git version built with your 2 patches (I haven't touched any other "tunables" i asked about) :
--- Quote from: Mihail Zenkov on June 04, 2015, 11:08:34 AM ---You should try add this patch to your build: http://forums.rockbox.org/index.php/topic,48549.msg233958.html#msg233958
It hack (we still don't have better solution) but it critical in some case.
--- End quote ---
--- Quote from: Mihail Zenkov on June 04, 2015, 11:08:34 AM ---Not very good solution as backlight have quite big timeout. Try attached hack for GUI_BOOST - if you press any key cpu boost for one second.
--- End quote ---
Responsiveness is back ! Something like this gui_boost should be included in the final patch, otherwise it may frustrate people like it did for me.
I haven't had any freeze yet (does that irq patch still do something after your discovery these freeze problems have another cause on other clips ?).
I noticed something strange with this build only :
when i power off and power it on back after a few seconds or minutes, it's fine
but if i wait > 15 mn to power it on back, it is stuck on the 2nd boot screen (the one with the version number) for ~8 secondes - then 1 second black, then the now playing screen (Backlight timer has been started : I have it set to 10 seconds, and backlight goes off 1 second after i see the now playing screen).
If i power it off and then on early enough, it's fast. If I wait 15mn or 4 hours, it's slow, very reproducible. Didnt happen yesterday before these 2 patches.
Thanks.
Mihail Zenkov:
--- Quote from: LolaPalocz on June 05, 2015, 03:27:42 PM ---(does that irq patch still do something after your discovery these freeze problems have another cause on other clips ?).
--- End quote ---
Yes. We still don't have batter solution.
--- Quote from: LolaPalocz on June 05, 2015, 03:27:42 PM ---I noticed something strange with this build only :
when i power off and power it on back after a few seconds or minutes, it's fine
but if i wait > 15 mn to power it on back, it is stuck on the 2nd boot screen (the one with the version number) for ~8 secondes - then 1 second black, then the now playing screen (Backlight timer has been started : I have it set to 10 seconds, and backlight goes off 1 second after i see the now playing screen).
If i power it off and then on early enough, it's fast. If I wait 15mn or 4 hours, it's slow, very reproducible. Didnt happen yesterday before these 2 patches.
--- End quote ---
This patches shouldn't have side affect like this. You can try switch off database auto update.
LolaPalocz:
--- Quote from: Mihail Zenkov on June 05, 2015, 04:51:01 PM ---This patches shouldn't have side affect like this. You can try switch off database auto update.
--- End quote ---
(I dont have database enabled - and it's not as reproducible as i thought.)
But I figured out it's related to "dircache" (General settings/System/Disk/Directory Cache).
I had it enabled (the default).
If enabled, it's build at every boot (we can see the time taken to build in the debug menu).
With my 20141111 git build without any battery life patch), it always takes 2-3 seconds (whether I had 1500 entries or 3000 on both internal and SD storage).
With amsv2_scaling_v8, it takes either 2-3 seconds, or 8-9 seconds (I didnt find any condition that triggers one or the other).
(Without your 2 patches, i can see the message "Scanning directories" during these 8-9 seconds - with your 2 patches, it stays 8-9 seconds on the 2nd boot screen.)
I can see in apps/main.c and firmware/common/dircache.c that cpu_boost is involved during the building, so may be there's a race condition where cpu freq is reduced before the rebuild is done. I dont understand very much about this code though.
Also, one time, I got to the now playing screen in 2 seconds, and i could quickly go to the debug screen and witness the dircache being built live (took 14 seconds). It's supposed to be a background thread, but I dont know why sometimes it blocks the boot till it's done, and that time not.
I tested with dircache enabled or disabled :
- without amsv2_scaling_v8, file browsing is very responsive (no difference felt whether dircache enabled or disabled)
- with amsv2_scaling_v8 and without your GUI_BOOST patch : with dircache enabled, file browsing is a bit slow (my initial report), but with dircache disabled, it is very very slow.
- with amsv2_scaling_v8 and WITH your GUI_BOOST patch : with dircache enabled, boot may sometimes be slow, but then file browsing is very responsive - with dircache disabled, boot is always fast and file browsing is very responsive (so i'll stick to this configuration for now).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version