No subject

static int __init parse_tag_clock(struct tag *tag)
{
        /*
         * We'll figure out the clocks by peeking at the system
         * manager regs directly.
         */
        return 0;
}
__tagtable(ATAG_CLOCK, parse_tag_clock);

Anyway, I can see the talk of "speed" and board "revision" has created
some confusion.

What if instead of "maxspeed", I named the variable as "soctype" and had
values like "am18x-300", "am18x-375", "am18x-450" passed to it?

It means the same thing, but will probably create a different perception?

I wanted to avoid taking this route since the same code supports
different SoC part numbers and passing part number specific values
can cause some confusion for users of other parts. That is all.

The question is why should a new ARM ATAG be introduced if an existing
one is good enough for the purpose?

> >> Using HZ would probably settle the "which unit is used" question, but
> >> the code would overflow at ~4.2 GHz and the numbers will be large and
> >> entry errors have to be expected.  As Hz is too fine for CPU frequenci=
es
> >> this would lead me to use either kilo or megaherz but I would express =
it
> >> in the variable name.
> >
> > I don't have a very strong inclination on this so I will go with
> > your suggestion.
>
> Did you check if we can learn from other code already present in U-Boot?
>
> Let's see - in arch/mips/cpu/incaip_clock.c there is an environment
> variable "cpuclk" which is in MHz. Aha, the 8xx parts also use a
> "cpuclk" environment variable which is even documented in
> doc/README.MPC866.

Yes, U-Boot online documentation also has a reference to it:
http://www.denx.de/wiki/view/DULG/UBootEnvVariables.

>
> Ah, now I'm in a tight spot - contrary to my previous writings when I
> belived we did not have a comparably construct - I would now vote to use
> exactly the same name and thus unfortunately not use a "_mhz" suffix but
> still specify the clock in mhz.

You mean replace "maxspeed" by "cpuclk"? As I have noted a number of times
before, we are not passing the cpu clock speed here. That information kerne=
l
directly reads from system registers. No need to pass it from U-Boot. The
example you are giving is not the right comparison.

The cpuclk variable in MPC866 is used to set the current cpu speed and pass=
 that
information to kernel. I had a feeling this confusion is going to arise and
that is why I noted in my patch description:

"
Note that U-Boot itself does not set the CPU rate. The CPU
speed is setup by a primary bootloader ("UBL"). The rate setup
by UBL could be different from the maximum speed grade of the
device.
"

Thanks,
Sekhar