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

[Simon Glass]

On Sun, May 15, 2011 at 7:23 PM, Eric Cooper <ecc at cmu.edu> wrote:

> On Sun, May 15, 2011 at 03:15:46PM -0700, Simon Glass wrote:
> > I believe that this problem is getting worse - e.g. USB on Tegra2 writes
> > various fields of about 20 registers to get things up and running. I find
> > translating SOC datasheet register definitions into C code with shifts
> and
> > masks to be slow and error-prone work. Also we do need to maintain this
> > code, and it gets reused for new SOC variants, etc. So it is not as if it
> is
> > written once and then buried and forgotten. There is also a tendency to
> use
> > 'magic' constants rather than #define values or something with a sensible
> > name, then hopefully add a half-hearted comment. This requires constant
> > return looks at the datasheet to see what bits were chosen.
>
> I have nothing against helper functions like this (although I think they
> should be inline functions, not macros, to guard against bugs
> due to side-effects in arguments).
>

This does limits the functionality unfortunately. With macros it is possible
to (for example) derive a shift and mask from a single base token.

>
> But wouldn't it be even better to define the registers as C structures
> containing bitfields, so the C compiler can do the error-prone
> shifting and masking?  Well-commented structure definitions for these
> registers also eliminate the need to refer back to the datasheet when
> working on the code.
>

I believe the problem here is the read/modify/write behaviour which is not
well-defined in C. One ends up using volatile to ensure the right behaviour,
and then this doesn't necessarily work either. Where one write must happen
before the next read the compiler must have barriers to indicate this, which
would then have to be inserted manually (rather than just in the writel()
macro). The opposite problem is that if you update several fields at once
the compiler may or may not optimise these into a single access, and this is
not under programmer control. So writel() and readl() are preferred.

Perhaps in newer compilers bitfield semantics have been improved?


>
> --
> Eric Cooper             e c c @ c m u . e d u
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>