SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[funman]

Do we use the ide interface at all for the ams sansas?  I'm trying to understand why the ide interface gets enabled and clocked in sd_init.  I thought the internal sd was on the nand interface and the microsd was on the sd/mmc interface, connected to the processor through the apb/ahb bus.   Does the ide interface need to be enable for some reason? DRAM? What's the connection here?

The IDE interface is needed for internal SD to operate correctly, but I don't know how it is connected internally : probably a Sansa extension.
To verify, just comment out the line which enables IDE clock and see if SD works.
Note : if we reset IDE interface (in CCU_SRC, see system_init()) SD stops working, all other peripherals can be resetted.

[FlynDice]

I posted http://www.rockbox.org/tracker/task/10191 to see if synchronous clocking has any advantage.  For MAX speed it runs the processor at 248Mhz and peripherals at 248/4= 62 MHz.  For NORMAL speed it runs the processor and peripherals at 31 Mhz.  I don't know that this is any better than what we do now but I thought it was worth checking out.  It seemed to be more stable while I was investigating the mmu but I think funman may have found a solution there.  The one thing I can say for sure is better is the wheel light flashes much less during disc accesses, but it still flashes once in a while.

[rp]

How is the wheel light connected to this?
I thought it's controlled by GPIO D7?

[bertrik]

If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz.

By the way, I noticed that AMS has a new revision (rev1.13) of the as3525 datasheet on their website, see http://www.austriamicrosystems.com/eng/Products/Mobile-Entertainment/High-Performance-Microcontrollers

[Llorean]

You really should make the full speed available while boosted, I'd imagine. Otherwise you're potentially cutting off file formats (ApeV2 at certain compression levels possibly) as well as restricting the bitrates and possibly resolutions at which video can be encoded.

The whole point of being boosted is that things that need a large amount of CPU can get the full capabilities of the player behind them.

If there's a role for "not quite full power" it should probably be engineered in as a general thing, rather than choosing to limit just one port (well, set of ports).

[saratoga]

If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz.

Can it be adjusted on the fly?  If so, the beast has the same problem due to its frequency/voltage scaling.  We should probably consider a more general solution to this problem, either by having more complicated boosting code or by allowing codecs/plugins to request a higher clockspeed/voltage level.

By the way, I noticed that AMS has a new revision (rev1.13) of the as3525 datasheet on their website, see http://www.austriamicrosystems.com/eng/Products/Mobile-Entertainment/High-Performance-Microcontrollers

" Added definition of Power Management Output Voltages"

[kugel.]

You really should make the full speed available while boosted, I'd imagine. Otherwise you're potentially cutting off file formats (ApeV2 at certain compression levels possibly) as well as restricting the bitrates and possibly resolutions at which video can be encoded.

The whole point of being boosted is that things that need a large amount of CPU can get the full capabilities of the player behind them.

If there's a role for "not quite full power" it should probably be engineered in as a general thing, rather than choosing to limit just one port (well, set of ports).

That would probably also mean to to lose our zero-wait boosting. Sad thing, but I generally agree with you. However, zero wait boost is probably wanted once we get more into a gui boost.

[FlynDice]

If we run the processor at less than 200 MHz, the core voltage can be reduced from 1.2V to 1.1V, according to the as3525 datasheet (see the note in paragraph 6.2.2) . This could save some power (in a simple approximation dissipated power is inversely proportional to the *square* of the voltage). I think we don't really *need* to run at absolute maximum speed of 248 MHz, so we could save power by running slightly lower than 200 MHz

Can we adjust that voltage somehow or was that a choice sandisk made when they designed the player?

[saratoga]

The AMS chip has its own voltage regulators which are under software control. 

[FlynDice]

Ah yes found it now.
Does this note on the next page under 6.2.3 have any bearing on this lower frequency?

(1) This setting must not be used for AS3525 core supply because the lower voltage limit is out of core supply specification limits.

EDIT: I suppose this could apply for the above 200Mhz clocking and if we're below that  the note on the previous page would apply.  Otherwise why would there be a setting for lower?

[saratoga]

Ah yes found it now.
Does this note on the next page under 6.2.3 have any bearing on this lower frequency?

(1) This setting must not be used for AS3525 core supply because the lower voltage limit is out of core supply specification limits.

EDIT: I suppose this could apply for the above 200Mhz clocking and if we're below that  the note on the previous page would apply.  Otherwise why would there be a setting for lower?

The voltage needed depends on the clock speed and the the process used to make the chip.  Low voltage runs of chips are possible either by optimizing for power consumption in the fab or by limiting clock speed.  Thus theres typically many more settings for voltage available then each individual chip is rated for.  If we were willing to accept low clocks for all components, we could probably use lower voltages then the chip is designed for too.

[daytona955]

Is there a good reason for AS3525_DBOP_FREQ to be 8MHz (clock_target.h)?
The AS3525 data sheet says <= 65MHz (para 7.3.12.7 on P92).

I've changed it to 62MHz (i.e. PCLK) on a build in an e260v2, and it seems to work well. Responsiveness of the scroll wheel is much improved - to the point where spacerocks becomes playable

On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?

Sorry if there are obvious answers to these - I'm a bit new to Rockbox.

[FlynDice]

On a slightly different clocking issue, the ARM922 tech ref (para 5.4) says that for asynch mode, FCLK must have a higher frequency than BCLK. But without boost, Rockbox seems to run FCLK at 31MHz & BCLK (aka HCLK in the AS3525) at 62MHz. How does Rockbox get away with that?

funman realized the same thing a few days ago and said he had found some success with the caching and mmu problems by increasing the frequencies.  See: FS#10048 mmu-dcache

I managed to get synchronous up and running with this patch:FS#10191 synchronous clocking

There is a problem with the i2c (ascodec) clocking though.  Read the message traffic on those two FS's and it should give you a good idea of where things are.  I haven't seen any comments from funman in a couple of days so I don't know if he's had any success in sorting out the clocking issues.  I have not found anything new to add in the past couple of days.

EDIT:  I finally tried some tests on SVN vs synchronous clocking.  The synchronous clocking setup turns out faster from what I can tell;
                    sync              SVN
test_codec    132.59      vs  142.5  (mp3)
test_fps         42.2 fps   vs   30.6 fps

[daytona955]

Regarding DBOP clocking, is this code

    CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);

in ams3525_dbop_init() correct?

For example, with PCLK=62M, and a desired DBOP clock of 8M, CLK_DIV gives 8 (truncated from 8.74999...).  (I think 62 & 8 are effectively the current SVN values.)

62M/8 gives 7.75M, which is less than 8M (and so is safe if 8MHz was an absolute limit).

But the AS3526 data sheet says  that DBOP_PREDIV_SEL is only 3 bits, so we cannot set it to 8.

Also, the actual division ratio is 1/(DBOP_PREDIV_SEL+1).

So for this example, the actual division ratio becomes 1/((0x8 & 0x7)+1), i.e. 1.

I think the code needs 1 subtracted from the divisor to have the correct effect.

Edit:
Actually, the PCLK value in SVN (clock-target.h) is

#define AS3525_PCLK_FREQ        65000000

The actual PCLK will be 62MHz, but the DBOP clock would calculated on 65MHz. This would give give a divisor of 9, giving a real value of 2 when programmed to the hardware.

However, subtracting 1 would not fix the problem in this case...

[kugel.]

Regarding DBOP clocking, is this code

    CGU_DBOP = (1<<3) | CLK_DIV(AS3525_PCLK_FREQ, AS3525_DBOP_FREQ);

in ams3525_dbop_init() correct?

Initially, it ran at PCLK speed (see http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/sansa-fuze/lcd-fuze.c?r1=19276&r2=19330). During the work for r19330, we played with the clocks and found ~20MHz (PCLK / 3) quite usable. I'd say 8MHz is not intended.

Edit: Yes, CLK_DIV seems to give wrong results. And to be honest, if it really was 8MHz, I think the the LCD would be next to infunctional. So, currently it's at PCLK / (1+1)=32.5 MHz. I think we could change it to be = PCLK and clock down when the backlight is off to save power.