[U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros

Wolfgang Denk wd at denx.de
Tue Jun 7 12:39:23 CEST 2011


Dear Aneesh V,

In message <4DEDE8D9.7030306 at ti.com> you wrote:
>
> As I had mentioned in a previous mail, please note that the above
> macros are not for the same use-case as clrsetbits*() or friends (I had
> one macro that did something similar to clrsetbits*() and I intent to
> remove that in the next revision)
> 
> The above macros are for bit-field manipulation in a C integer variable
> - nothing more.

Why cannot we use the existing macros?

> So, if I have to write 5 different fields in a register I first write
> them into a variable and finally call writel() instead of making 5
> clrsetbits*() calls.

It does not make much difference to me if you call one macro or
another 5 times.

It does mater to me to have several incompatible implementations doing
essentially the same thing.

> There aren't any standard routines available for this need in
> Linux or U-Boot. I think you had agreed on this fact sometime back.

I agree in so far as I am not aware of any such macros in Linux
either.  But my conclusion is a different one - it boils down to:
Linux is way more complex than U-Boot, so if they don;t need this, we
don't need it either.


> No. It was not about code quality. The question was whether these
> macros were generic enough to be used as the standard U-boot ones. The
> key question is how do you represent bit fields. There are different
> alternatives for this.
> 
> a. bit range (say 5:3)
> b. shift(3) and field width(3)
> c. shift(3) and mask(0x38)

d) Value and mask

> We traditionally use (c) and we have auto-generated defines in this form.
> So, my macros use this format. I was not sure if other SoCs follow the
> same approach. That's why I suggested making them OMAP specific if you
> think (c) is not the standard approach.

Actually it does not matter.  See my previous message to Simon: you
can cover all this with the existing macros, and without adding any
significant overhead.

So far, I did not see a single good argument why any new, nonstandard
macros would be needed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can fool some of the people all of the time, and You can fool all
of the people some of the time, but You can't fool mom.


More information about the U-Boot mailing list