[U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel

[Detlev Zundel <dzu@denx.de>]

Hi Wolfgang,

> Dear Detlev Zundel,
>
> In message <m28w44gx6a.fsf@ohwell.denx.de> you wrote:
>> 
>> > Even though its pretty descriptive - for the sake of consistency I
>> > recommend to omit the "_mhz" part. 
>> 
>> I know that I will mutter a not so nice remark every time I use the
>> variable and am forced to look up the documentation for a single setenv
>> command instead of typing 4 more characters.
>
> I understand what you mean, but then - have a guess on how many "*clk"
> and "*clock" symbols we use in U-Boot, and how many in Linux - and
> how many of these use a unit suffix?

Sure - if one uses the canonical unit, then no suffix is needed.  I
never said anything else.

> Actually I also think that using MHz as unit is broken by design -
> keep in mind that we use Hz basicly everywhere else, and for a reason.
>
>> I still remember the days of "clocks_in_mhz" and the waste of time it
>> produced - maybe this is why I continue to raise this concern.
>
> Note that the Linux kernel changed this interface from MHz to Hz by
> then!

Sure - still this left an impression on me ;)

> Where would be the problem?  In this case, we are talking about an
> environment variable; here we are using a string representation of
> (more or less) arbitrary size.
>
> If we really shoould see CPU clocks way beyond 4 GHz one day, the code
> needs to deal with htat in an appropriate way - but even if you decide
> to operate in a MHz unit internally, you can still use Hz at the
> interface.

Yep, I know.  I only stated that using Hz for such numbers for user
changeable values probably will create a few "misentries" which will be
somewhat hard to diagnose.  If this is not a concern - I'll gladly go
with the canonical unit.

> As long as all other clocks are specified in Hz, I strongly recommend
> to do the same here, too.

Well sure - as always, it's a compromise.  One should consider all the
pros and cons and then _decide and document_.  We are in complete
accordance.

>> > Can we agree on "cpumaxclk" ?
>> 
>> If nobody else shares my concerncs this sounds good.
>
> Thinking again about this, I actually tend to prefer
>
> 	"maxcpuclk"
>
> :-)

Whatever - my concerns were not coupled to permutations ;)

Cheers
  Detlev

-- 
Microsoft gives you windows, Linux gives you the whole house.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de