Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.2
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by FlynDice - 2009-06-09
Last edited by funman - 2010-07-30

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

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.

Closed by  funman
2010-07-30 23:11
Reason for closing:  Out of Date

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).

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.

i don’t think we need presets since all frequencies are configurable already : we can make & test individual changes

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.

what are you looking at with all these changes : a better compromise for performance / battery life than the current SVN code ?

“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.

Unfortunately, we have still bigger problems to fight.

Is this patch still relevant (it’s over a year old)?

No, that file is already long enough

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing