Dear Aneesh V,
In message 4DEDE8D9.7030306@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