Some work on the cn700 ram init

[Corey Osgood]

It isn't quite complete, but there's a couple fairly important bits in
there. I'm trying to reconstruct a lot of the work I've done in the last few
months from memory, so bear with me ;)

[Peter Stuge]

On Fri, Feb 22, 2008 at 02:30:35AM -0500, Corey Osgood wrote:
> Squash a major bug in the previously committed cn700 patch (spd
> data only shifted 1 bit instead of 4), add Urbez Santana Roma's
> fixes for the ram setup data, and add the start of dynamic ram
> setup. This is an intermediate patch, there will be another to
> finish the dynamic ram setup, but the fix is very necessary. Note
> that this is not build tested.
>
> Signed-off-by: Corey Osgood

I'd like to see Urbez' signoff in this commit too.
> +/* Table to transform the ram speed register value into a MHz value */ 
> +static int ram_speeds[6] = {100, 133, 166, 200, 266, 333};
> +/* Transform spd byte 40's tRFC value into a decimal */
> +static int byte_40_tRFC[6] = {0, 25, 33, 50, 66, 75 };

Could this be something like:

static int ram_speed_tRFC[][2] = {
    {100, 0}, {133, 25}, {166, 33}, {200, 50}, {266, 66}, {333, 75}
}

instead? Other than that:

Acked-by: Peter Stuge

[Corey Osgood]

On Fri, Feb 22, 2008 at 7:08 AM, Peter Stuge  wrote:
> On Fri, Feb 22, 2008 at 02:30:35AM -0500, Corey Osgood wrote:
> > Squash a major bug in the previously committed cn700 patch (spd
> > data only shifted 1 bit instead of 4), add Urbez Santana Roma's
> > fixes for the ram setup data, and add the start of dynamic ram
> > setup. This is an intermediate patch, there will be another to
> > finish the dynamic ram setup, but the fix is very necessary. Note
> > that this is not build tested.
> >
> > Signed-off-by: Corey Osgood
>
> I'd like to see Urbez' signoff in this commit too.

I agree.
> +/* Table to transform the ram speed register value into a MHz value */
> > +static int ram_speeds[6] = {100, 133, 166, 200, 266, 333};
> > +/* Transform spd byte 40's tRFC value into a decimal */
> > +static int byte_40_tRFC[6] = {0, 25, 33, 50, 66, 75 };
>
> Could this be something like:
>
> static int ram_speed_tRFC[][2] = {
>        {100, 0}, {133, 25}, {166, 33}, {200, 50}, {266, 66}, {333, 75}
> }
>
> instead?

Yes, but I really don't like it. The two are used entirely independently, I
don't like combining two tables that are completely unrelated to one
another.
> Other than that:
>
> Acked-by: Peter Stuge

Thanks, I'll commit once Urbez can sign off.

-Corey

[Peter Stuge]

On Fri, Feb 22, 2008 at 05:25:51PM -0500, Corey Osgood wrote:
> > > +static int ram_speeds[6] = {100, 133, 166, 200, 266, 333};
> > > +/* Transform spd byte 40's tRFC value into a decimal */
> > > +static int byte_40_tRFC[6] = {0, 25, 33, 50, 66, 75 };
> >
> > Could this be something like:
> >
> > static int ram_speed_tRFC[][2] = {
> >        {100, 0}, {133, 25}, {166, 33}, {200, 50}, {266, 66}, {333, 75}
> > }
> >
> > instead?
>
> Yes, but I really don't like it. The two are used entirely
> independently, I don't like combining two tables that are
> completely unrelated to one another.

Hm. Maybe I misunderstood.

I thought one [] was used to find an index from a known/probed value,
and that index then used to look up a value in the other [].

Never mind my comment if that's not what's happening. :)

//Peter

[Corey Osgood]

On Sat, 2008-02-23 at 13:35 +0100, Peter Stuge wrote:
> On Fri, Feb 22, 2008 at 05:25:51PM -0500, Corey Osgood wrote:
> > > > +static int ram_speeds[6] = {100, 133, 166, 200, 266, 333};
> > > > +/* Transform spd byte 40's tRFC value into a decimal */
> > > > +static int byte_40_tRFC[6] = {0, 25, 33, 50, 66, 75 };
> > >
> > > Could this be something like:
> > >
> > > static int ram_speed_tRFC[][2] = {
> > >        {100, 0}, {133, 25}, {166, 33}, {200, 50}, {266, 66}, {333, 75}
> > > }
> > >
> > > instead?
> >
> > Yes, but I really don't like it. The two are used entirely
> > independently, I don't like combining two tables that are
> > completely unrelated to one another.
>
> Hm. Maybe I misunderstood.
>
> I thought one [] was used to find an index from a known/probed value,
> and that index then used to look up a value in the other [].
>
> Never mind my comment if that's not what's happening. :)

Sorry I didn't reply, been crazy busy lately (haven't even had time to
watch Stargate). It sort of is, the value from ram_speeds[] is used
multiple times for most of the timings, it gets a MHz speed for the ram
from the register value, which is then converted to a nanosecond cycle
time. byte_40_tRFC[] is only used once, to sort out the mess JEDEC made
with tRFC, and that part uses the ram_speeds[] value too. If there's
some size/speed benefit, then it's fine, but otherwise, combining them
just adds unnecessary confusion. Still waiting for a sign off from
Urbez.

-Corey