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

[Detlev Zundel <dzu@denx.de>]

Hi Mike,

Let's recap that.  The macros I chose to discuss (random pick) were:

#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)

Now you tell me:

>> > the data sizes are hidden from the developer (in so much that they dont
>> > need to worry about it in the important cases),

Again, where do you think you hide data sizes in those macros?  Just
because you are saying so, I still cannot see it.  But ok, somehow the
situation changed:

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

So you are now saying you do not hide data sizes?

>> > 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

I'm referring to that you claim that a macro like

#define bfin_read_VR_CTL()	 bfin_read16(VR_CTL)

prevents pepole from having to "look up random addresses in the HRM for
their particular variant".  I cannot see this, no matter how hard I
look.  If I use the substitution, where exactly do I have to look up an
address?

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

Ah now this is an intersting piece of information.  I again cannot
follow what those defines of yours have to do with defining an
"architecture" as I understand it, but I now better understand your aim.
Reminds me of Java to be honest.

It's interesting however that the success of Free Software ultimately
was the total inability of anyone to have "total control" over any one
piece, but one probably can ignore that.

Personally I believe that from a technical point of view it is a
questionable aim to have the "patent solution for everything",
especially if we are talking about a boot loader here.

Just my thoughts.

Cheers
  Detlev

-- 
Programming is like sex: One mistake and you have to support it your lifetime
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de