Rockbox

Tasklist

FS#11297 - as3525v2: set_cpu_frequency

Attached to Project: Rockbox
Opened by Rafaël Carré (funman) - Wednesday, 19 May 2010, 22:16 GMT
Last edited by sideral (sideral) - Friday, 06 May 2011, 08:16 GMT
Task Type Patches
Category Drivers
Status Assigned
Assigned To No-one
Operating System Sansa AMSv2
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This patch modifies hardware registers for pclk & fclk in one instruction.

I'm currently testing it on Clipv2 to see if it gets rid of crashes
This task depends upon

Comment by Jack Halpin (FlynDice) - Thursday, 20 May 2010, 05:28 GMT
From the View HW page it appears that no frequency changing is actually happening at least for my clip+. I've got 926ejs freq at steady 240MHz and PCLK at 24 MHz. I also watched the actual register values and they never change. I tried manually boosting/unboosting and still no change. Also no changes while inserting/removing uSD. The good news is no crashes after 30 mins though....
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 09:17 GMT
Indeed it didn't change, no wonder why it didn't crash then.

Updated patch: use &CGU_PROC in the asm instead of CGU_PROC.

Apparently the asm wrote to *(CGU_PROC) , which was *(void*)(0x00000001), so it just erased the reset / undef instruction and software interrupt vectors
Comment by Marc Hewson (marc2003) - Thursday, 20 May 2010, 11:00 GMT
testing the 2nd patch on my clip v2 and it's hard locked after 30 minutes or so. i set the back light to stay on and the music just stopped and the screen has frozen. i had to hold power to turn it off.
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 13:11 GMT
crashed quickly on Clip+ too (freeze)
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 14:04 GMT
Another approach

Use a table of fclk/pclk dividers to ensure PCLK doesn't go too low / too high

On Clipv2/Clip+ it goes to: 20, 24, 26.66, 40 and 48MHz

I didn't calculate a table for fuzev2
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 14:25 GMT
Added fuzev2 table: pclk goes 20, 24, 30, 40, 48MHz
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 15:27 GMT
Use a single table for boosting & unboosting, just change PCLK & FCLK in the reverse order when unboosting.

Also cache CGU_PERI value without divider.

Clipv2/+: 20/24/40/48MHz
Fuzev2 : 20/30/40MHz
Comment by Marc Hewson (marc2003) - Thursday, 20 May 2010, 15:33 GMT
i've been testing v3 and got the freeze after 45 minutes.
Comment by Thomas Martitz (kugel.) - Thursday, 20 May 2010, 17:38 GMT
no freeze after almost 3 hours of playback.
Comment by Marc Hewson (marc2003) - Thursday, 20 May 2010, 18:02 GMT
i wasn't sure if there were any functional changes between v3 and v5 but i tried v5 anyway. got this error after 20 minutes or so...

Data abort
at 3004A31C
FSR 0x8
(domain 0, fault 8)
address 0xE12FFFA6

(clip v2)
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 18:07 GMT
19:53 < FlynDice> funman: clip + cpu freq patches v 4 & 5 still crash

This patch adds back the delays removed in r25753
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 18:38 GMT
clipv2 crashed (screen was off) with this v6 patch
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 19:17 GMT
My fuzev2 and kugel's one didn't crash so far, unlike my clips.

Suggested by kugel: use 40MHz pclk on Clips too
Comment by Sascha E. (Ahcsas) - Thursday, 20 May 2010, 19:55 GMT
No freeze after 2 hours (playing flac's). [patch v5]

But I have artefacts during navigation (clicking/whirring sound) also.
The patch does not fixed this issue.

-------------------------------------------------------------------------------
Clip+ (firmware, bootloader and mkamsboot from r26200)
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 21:51 GMT
- Remove the delays
- Correct the 24MHz Clip table : PCLK would go as low as 12MHz.

Now it goes: 20, 24, 40MHz
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 22:08 GMT
- Restore the delays

it crashed quickly on Clipv2

So far we have:
- no crash on fuzev2
- v1 / v2 crashing
- v3/v4/v5/v6 crashing on clip (incorrect table)
- v8 crashing on clip (no delay)

- v7 working so far (Clip using 40MHz)
- v9 ??
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 23:19 GMT
v9 crashed on clipv2
Comment by Marc Hewson (marc2003) - Friday, 21 May 2010, 07:55 GMT
v7 is working good for me on the clip v2. i left it overnight running a battery bench and it's still going, around 8 hours in.....
Comment by Rafaël Carré (funman) - Friday, 21 May 2010, 09:53 GMT
v7 ran overnight just fine on Clips & Fuzev2

- This version disables clk_wait() delay (the function is still there but commented out)
- Run Clip clocks @40MHz just like the Fuzev2

I will check again the clip table of dividers for 24MHz, it's weird because we stay in the same range than when using 40MHz
Comment by Rafaël Carré (funman) - Friday, 21 May 2010, 10:01 GMT
The table in v8/v9 (the one in v10 is the same than in v7) is OK: in the same 20-40MHz than the Fuzev2, and goes to 20,24,40MHz
Comment by Marc Hewson (marc2003) - Friday, 21 May 2010, 13:02 GMT
my v7 battery benchmark didn't complete successfully. i last checked around the 10 hour mark and i went to check it again just now (13 hours-ish) but it was off. turning it back on shows 35% battery left but there's no trace of the battery_bench.txt file. :(

(i'm pretty certain i started the plugin but i can't be 100% sure :0 )
Comment by Jack Halpin (FlynDice) - Friday, 21 May 2010, 14:51 GMT
Clip+ crashed after 31 mins with v10.
Comment by Jack Halpin (FlynDice) - Friday, 21 May 2010, 19:40 GMT
2nd crash with v10 playing ogg off of uSD. Data abort at 3004A628, appears to be in timeout_register looking at my rockbox.map: http://pastie.org/971596.

FSR 0x8
(domain 0, fault 8)
address 0xE59FE070
Comment by Rafaël Carré (funman) - Friday, 21 May 2010, 21:03 GMT
Can you remove the #if 0 in clk_wait() and see if it crashes?

Clip+/Fuzev2 still playing (off of internal) for ~10 hours, i'll double check which version went on those when they power off or crash

With other patches I have seen similar messages so I think it's definitely related to this patch and not µSD.
Comment by Mark Mitchinson (xanikseo) - Friday, 21 May 2010, 23:08 GMT
Haven't been able to crash fuzev2 with v10. Fiddling with EQ and all, it won't budge! Great!
Comment by Rafaël Carré (funman) - Monday, 24 May 2010, 10:23 GMT
With PCLK@40MHz I got 15h15 runtime on Clip+, it's a bit lower than SVN
Comment by Thomas Martitz (kugel.) - Monday, 24 May 2010, 11:10 GMT
That seems strange, I'd expect freq scaling to have a nice effect on the runtime. Where can I find your previous results?
Comment by Rafaël Carré (funman) - Monday, 24 May 2010, 11:41 GMT
We should compare with PCLK@40MHz without cpufreq scaling to really see the effect.

Btw I think I remembered wrong, r25799 showed 14h20 runtime.

Fuzev2+patch shows 19h07 runtime.

I have a bunch of battery_bench files, I can send them to you if you want
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Saturday, 19 June 2010, 09:54 GMT
I had the v10 version of the patch applied for a few days on a FuzeV2 without crashes.
Comment by Rafaël Carré (funman) - Saturday, 03 July 2010, 18:56 GMT
sync to r27257
Comment by Rafaël Carré (funman) - Sunday, 04 July 2010, 18:21 GMT
- use 248MHz PLLA
- the table of dividers is not changed (should work)
- use 24.8MHz PCLK on Clipv2/Clip+
Comment by Rafaël Carré (funman) - Monday, 05 July 2010, 13:28 GMT
This last patch crashed on Clipv2/Clip+

Saratoga, should we use 40MHz instead ?

battery life with PCLK@40MHz + dynamic cpu freq improves a lot anyway compared to PCLK@24MHz + fixed cpu freq
Comment by Rafaël Carré (funman) - Monday, 05 July 2010, 13:37 GMT
Fuzev2 powered off correctly after 18h15, which is 1h45 less than my last SVN benchmark?

Luca_S have you compared the runtime of SVN versus this patch?
Comment by Magnus Holmgren (learman) - Monday, 05 July 2010, 14:44 GMT
Hm, I'm think this patch is the cause for the slight graphics corruption I get on the main backdrop after having played a track (a short horizontal line of black pixels, a bit to the right and below the center of the screen). This with both v10 and v11 of the patch.
Comment by Rafaël Carré (funman) - Tuesday, 06 July 2010, 14:08 GMT
Last patch + boosting forced to 248MHz seemed to work:
- 15h40 on clipv2
- 16h35 on clip+
Comment by Rafaël Carré (funman) - Tuesday, 06 July 2010, 16:28 GMT
- 21h on fuzev2 when boosting forced to 248MHz

I don't understand why dynamic cpufreq reduces battery life.
Comment by Thomas Martitz (kugel.) - Wednesday, 07 July 2010, 06:24 GMT
Back when it was being disabled in svn someone messured 3 or 4 hours reduced runtime (i.e. dynamic boosting gave more runtime). We need more tests to be sure what effect it really has.
Comment by Luca Leonardo Scorcia (LucaLeonardoScorcia) - Wednesday, 07 July 2010, 18:09 GMT
I did a couple of accelerated battery benches with my FuzeV2. Default settings, except for backlight set to always on, hold button, a single album looping.

Plain SVN: 8 hrs 00 min - http://www.pastie.org/1034689
Plain SVN + V11: 8 hrs 20 min - http://www.pastie.org/1034693
Comment by sideral (sideral) - Friday, 18 February 2011, 13:15 GMT
In a recent IRC discussion, someone suggested that the annoying background noise audible during playback on the ClipV2 (FS#11915) could be related to the CPU frequency.

Did anyone experimenting with the AMSv2-adjustable-CPU-freq patch notice any difference in the amount or nature of the background noise?

What is the current status of this patch? Where should I start if I wanted to experiment with this work?
Comment by Sei Aoyumi (Aoyumi) - Friday, 03 June 2011, 20:35 GMT
In my Clip+, the problem is not found in latest patch for the moment.
But I made a patch in it because a response worsened.

Following patch lets a CPU work at full speed during backlight lighting to prevent a response decline of user interface.

This is for Clip+ only for the moment.

Loading...