[U-Boot-Users] [PATCH/review] Blackfin: add support for BF538/BF539

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday 04 June 2008, Detlev Zundel wrote:
> >> that may later be used to take down the whole project has got zero to do
> >> with subscribing to "the FSF mentatlity".  Thinking about it, it doesn't
> >> even make sense to me that you express your distaste of the FSF from
> >> such a non-correlated topic.
> >
> > i dont think people really care what my opinion is on the matter and it
> > is certainly off topic on this list
>
> Indeed, why did you bring it up then?

i was responding to a comment Wolfgang made

> >> As I did not follow this discussion, can you enlighten me to what the
> >> *actual* positive effect of defines like the following is (random pick)?
> >>
> >> #define pVR_CTL                        ((uint16_t volatile *)VR_CTL) /*
> >> Voltage Regulator Control Register (16-bit) */ #define
> >> bfin_read_VR_CTL() bfin_read16(VR_CTL)
> >> #define bfin_write_VR_CTL(val)         bfin_write16(VR_CTL, val)
> >>
> >> To me (as a simple code reader), this will ultimately only make the end
> >> c code harder to read.  As it does not contain all the details any more
> >> I potentially have to lookup every single define if I want to understand
> >> what is going on.
> >>
> >> Thinking hard, I cannot see a positive result.  At first I thought you
> >> may hide the actual data sizes in this define layer (disregarding the
> >> fact whether this is a good or bad thing to do), but this is not the
> >> case, as the types will permeate the layer.  So can you please tell me
> >> what positive effects this is supposed to have?
> >
> > the data sizes are hidden from the developer (in so much that they dont
> > need to worry about it in the important cases),
>
> Even if I don't like hiding data sizes at such a place, I cannot follow
> your argument.  If you have correct typing on the called functions,
> surely these types are in no way encapsulated by these shim-macros.

people access the MMRs via the helper functions only, and they update the 
values using bit defines provided by the headers.  currently the core bfin 
accessor functions are defines, but there are plans to convert them to inline 
asm.  yes, the sizes of the types are handled correctly so that people do not 
cram a 32bit value into a 16bit one.

> > we use functions to read/write values rather than pointers (which is
> > common convention) and really is easier to read/manage), people dont
> > have to look up random addresses in the HRM for their particular
> > variant, etc...
>
> I also cannot follow this.  The macro substitution uses a symbolic
> constant named exactly like the macro.  What _exactly_ is that giving
> you?

i really dont know what you're referring to

> To be honest, as far as I can see, all other architectures get by
> without such "macros" without loosing anything and the arguments you
> gave this far did not convince me that they are needed.

other arches do not have a central control of the architecture and allow any 
random group out there to create their own.  these headers provide API 
compatibility across all Blackfin compilers and projects.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080604/d59d5071/attachment.pgp