[U-Boot] Bitfield macros (was: Re: [PATCH v3 02/10] armv7: add miscellaneous utility macros)

[Simon Glass]

On Mon, May 16, 2011 at 10:27 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <BANLkTine7BFSYOusgxwg0rg3owNbPN_dOQ at mail.gmail.com> you wrote:
>>
>> There are a few very primitive macros in setbits and clrbits. I would
>> very much like to see at least:
>
> Maybe we can agree to use these existing macros then instead of
> inventing new ones with the same functionality.

The existing macros do not have enough functionality in my view. If we
seriously want people to use these then I believe they need to be
enhanced to be easier to use and more powerful.

>
>> - define a field once in a header in an easy format along with any
>> enums which define allowable values if applicable
>> - pack and unpack a value into a field: so set a bitfield to 13, for exampl=
>> e
>> - obtain a mask for a field (i.e. with all bits set)
>> - equivalent of writel and readl for a bitfield (writel in fact being
>> read/modify/write so perhaps a different name)
>>
>> Some of these exist, some don't.
>
> Do you know of examples of such more complex definitions in the Linux
> kernel code?

Which complex definitions? I was suggesting adding a more powerful
group of bitfield macros to U-Boot. It would be better if they were
easier to use rather than more complex.

Linux does not have very good bitfield macros in my view. The saving
grace is that Linux typically creates such complex views of hardware
that the actual SOC register access is a tiny part of the code. For
example look at the clock code. All of the SOC functions are mirrored
in C structures, with strings and pointers, etc. The ugliness of
shifting with readl() and writel() is drowned out in the mountain of
code. I happen to believe that Linux should have better bitfield
access macro too but I'm not here to talk about Linux :-) U-Boot  has
quite a bit of hardware initialization code where there is little else
but writing to SOC bitfields.

I think clrbits and setbits are a start but they are primitive and we
can do better. If we do better, people will use the better options. If
lots of people use them then we can start requiring that people do. In
the end we get a consistent way of accessing SOC registers at the bit
level, as we now do at the word level.

>
>> Any thoughts? I we get something in there I suspect ARM people will
>> use it at least, and that will reduce the number of ways this gets
>
> I doubt that.  You can see that even the existing macros are unknown
> to many, and they also do not bother to check around or asdk.  It's
> always so much easier to invent your own new shiny macro that fits
> your current purpose perfectly.

Well speaking for myself I wrote some USB code with the existing
macros, which I found after a bit of a search, and keenly  felt their
shortcomings. So maybe if the built-in macros were just a little more
shiny people would use them. And in any case patch review could pick
this sort of thing up.

>
>> done. At present the local bitfield macros are not accessible to even
>> other SOCs, let along other architectures. As this thread shows (and
>> some of the code I have been reviewing recently) there is a demand for
>> something more functional.
>
> How is this problem being addressed in Linux?  At the very minimum we
> should chose a compatible implementation.

I think it is already compatible, in that we have a
lowest-common-denominator solution. I would like to see a more
functional option.

>
> Best regards,
>
> Wolfgang Denk
>

Regards,
Simon


> --
> 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
> Forty two.
>