FS#10308 - AMSSansa Add Preset frequency configurations to clock-target.h. e200v2 Radio Workaround.

Attached to Project: Rockbox
Opened by Jack Halpin (FlynDice) - Tuesday, 09 June 2009, 18:14 GMT
Last edited by Rafaël Carré (funman) - Friday, 30 July 2010, 23:11 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This patch adds selectable preset configurations to clock-target.h for AMSSansa's.

You can still "roll yer own" frequency configuration as the current way is still in place as one of your choices. Two of the preset choices offer a 32MHz dbop clock which allows the radio to work on the e200v2 until a better solution can be found there.

If no choice is made the default is the same as now, 248/62/62.
This task depends upon

Closed by  Rafaël Carré (funman)
Friday, 30 July 2010, 23:11 GMT
Reason for closing:  Out of Date
Comment by Thomas Martitz (kugel.) - Tuesday, 09 June 2009, 18:32 GMT
I'm not sure we really need this in SVN. Ideally, we aren't changing the frequencies anymore once we found a good one (what we have I think).
Comment by MichaelGiacomelli (saratoga) - Tuesday, 09 June 2009, 18:40 GMT
I think it makes more sense to put these in SVN then to leave them to rot on the tracker. They could be quite useful for future testing or ports to other AMS devices.
Comment by Rafaël Carré (funman) - Wednesday, 10 June 2009, 19:40 GMT
i don't think we need presets since all frequencies are configurable already : we can make & test individual changes
Comment by Jack Halpin (FlynDice) - Sunday, 14 June 2009, 22:26 GMT
This version is mainly just formatting and the addition of PLLA 390MHz possibilities. The code now respects an 80 column limit.
I added in the PLLA 390MHz settings as it is possible to hit the PCLK upper limit of 65 with this setting.

I don't know that we need this in SVN and that was not really the goal I had in mind when putting it together.

I want to make it easy to change setups in a testing environment to a known condition that I can have confidence in.
Yes, current svn is very flexible and we can use it to get whatever frequencies we want.
But I'm not good enough to get it right every time, and I find myself having to go back and fix my stupid mistake too often, wasting time I'd rather not waste.
When I use a preset I know what I'm going to get. I've already verified it and all I need to do is choose a verified set of dividers by uncommenting what I want. It's even hard for me to screw that up ;).
It's not as flexible as svn, but certainly useful. And if you still need the flexibility it is there as one of your choices.

Of course if we have actually figured out that current default of 248_62_62 is the "best" then all of this is really irrelevant anyway.
We could simply use the dividers in that preset and get rid of everything else...

By the way, if anyone else does see this as useful and wants some other presets let me know and I'll add & verify the settings.
Comment by Rafaël Carré (funman) - Sunday, 14 June 2009, 22:52 GMT
what are you looking at with all these changes : a better compromise for performance / battery life than the current SVN code ?
Comment by Jack Halpin (FlynDice) - Monday, 15 June 2009, 04:58 GMT
"what are you looking at with all these changes : a better compromise for performance / battery life than the current SVN code ?"

For the most part, yes that is my main motivation. I am still astounded by the magnitude of the runtime underperformance of the 62_31_31 fastbus vs the 248_62_62 sync bus.
I am very curious to understand why this is so and if indeed other configurations can improve upon it.
Since I've already gotten one result that has given me a paradigm shift I figure several more tests are in order... Hence, a patch to facilitate that.
Comment by Thomas Martitz (kugel.) - Monday, 15 June 2009, 05:03 GMT
Unfortunately, we have still bigger problems to fight.
Comment by Bertrik Sikken (bertrik) - Friday, 30 July 2010, 23:08 GMT
Is this patch still relevant (it's over a year old)?
Comment by Rafaël Carré (funman) - Friday, 30 July 2010, 23:11 GMT
No, that file is already long enough