Re: [iPAQ] Cpu scaling ??

(Some nice kind person pointed me at this message.)

First point: Determining SDRAM timing parameters without prior knowledge of
which chips might be fitted is extremely difficult to do, if not impossible.

It would not be right for the kernel to try to work out what type of SDRAM
is fitted. Firstly, there is very little the kernel can do, since any
attempt to fiddle about with SDRAM will crash the kernel (since it is
running from SDRAM). Secondly, if the kernel knows about 500 SDRAM parts
and their timings, and only 5 are actually going to be present in the iPAQ,
should it really probe for all 500? Don't think about 500 #ifdefs please.
Don't think about 500 new CONFIG symbols please.

Basically, The boot loader can do a lot more with the SDRAM timings and can
detect the number of row bits, etc etc, which the kernel will never be able
to do, and it can have a good idea of a selection of SDRAM types that are
likely to be fitted, and supply the relevant details to the kernel.

It has been my intention to introduce a method to pass SDRAM information
from a boot loader *IN A NON-MACHINE-SPECIFIC MANNER* (really stress this
point, make sure it doesn't get missed by anyone) to the cpu frequency
scaling code.

> Here I have to make a number of assumptions which feel free to contest/modify:
> 1) add the necessary code to RMK's cpu-sa1110.c module;

I've already got the H3100 stuff (I think) from one of Jamey's post that
someone was nice enough to bounce to me.

> 4) add the conditional compile and off we go!!!!

Definitely no thanks. Maintainence nightmare, and who's going to write
all those Configure.help text entries, and maintain them?

> 5) test the changes and submit to RMK? or handhelds.org? for inclusion.

I would like to receive tested changes. IE, if you try the parameters out
and they appear to work for you, submit them both to the handhelds.org
people _and_ me.

> 2 above is at variance to the way Erik has done the sdram timings in
> cpu-sa1100.c, but I think dynamic calculations make more sense if we are
> going to have to deal with a number of sdram variants.

(2) is not at variance. SA1100 cores are different from SA1110 cores -
the two have to be handled completely separately. Ignore the SA1100
stuff for the purposes of this discussion - you don't have one in your
iPAQ.

> 3 may not be an issue if the sdram timings are sufficiently similar for each
> memory size, ie 32 and 64Mb. I think it would be incumbent on anyone
> introducing a memory upgrade to provide the sdram timings and detection
> method for future memory configurations.

Unfortunately different RAM sizes have different number of row address bits,
which is one of the bits of information the kernel needs. Nothing to stop
the boot loader passing this with the rest of the information (in fact,
it's already required). No, it shouldn't read it from the registers,
even though it is there since that's a machine specific method (see the
bit above in big letters).

> I note Erik's comment about continuing this on the linux-arm-kernel mailing
> list, but I don't subscribe to that list (we all have to draw the line
> somewhere about the number of lists we track:)) and given this is ipaq
> specific I am happy to continue on here.

The main ARM Linux lists are freely open - you can post to them without
subscribing to them, and people will CC: you replies. This means you
can start a discussion there, and continue it without even being
subscribed. It operates just like the rest of the Linux world.

Please continue discussion of this topic on linux-arm-kernel.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html