From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Wed, 18 Aug 2010 13:33:33 +0200 Subject: [U-Boot] [PATCH v2] TI: DaVinci DA850 EVM: support passing device speed grade information to kernel In-Reply-To: <20100818104919.282B6157D71@gemini.denx.de> (Wolfgang Denk's message of "Wed, 18 Aug 2010 12:49:19 +0200") References: <1281591735-15623-1-git-send-email-nsekhar@ti.com> <20100817184618.3C67C157D71@gemini.denx.de> <20100818104919.282B6157D71@gemini.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, > Dear Detlev Zundel, > > In message 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