[U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090808152633.GD17045 at game.jcrosoft.org> you wrote:
> 
> > >so NACK
> > 
> > Let's summarize:
> > 
> > - First, you NACK because of device_type and function name
> > - Then, you mention "this code is omap3 specific"
> > - Then, you mention "this code is not needed at all"
> > 
> the current implementation is wrong

I try to stay out of this flame war, but Jean-Christophenm I cannot
prevent myself from stating that indeed with each noew message from
you in this thread you come up with new arguments. This is not exactly
a convincing method, and it makes me (and probably others) wonder if
you are just argumenting because you want to have some fight or if
ther eis really some technical argument.

If there is one, it should remain contant, so we can try to understand
what you mean.

> and yes I do want to have armv7 name in the armv cache function

And this is something which does not make any sense to me. If we have
a function flush_dcache() it should be indeed a genric one, so it can
be used everywhere in the code where we need to flush the data cache.
What would be the sense to stick the architecture name in it? If we -
for example -  decide we need to flush the data cache somewhere in the
generic code, then I want to be able to write

	flush_dcache();

Your proposal sounds as if we would end up with

#if defined(_ARMV7_)
	armv7_flush_dcache();
#elif defined(_OMAP3_)
	omap3__flush_dcache();
...
#elif defined(_MIPS32_)
	mips32_flush_dcache();
#elif defined(_MIPS64_)
	mips64_flush_dcache();
...

This cannot be your intention?

A _generig_ name is a must, I think.


> I known you will tell but the other does not
> I agree the other arm flush code need to be clean and it's plan anyway
> as I need it to add the mmu and d-cache support
> which will be done later

Again this argument of some clenup that might be performed some time in
the future. If this should happen one day, then changing one funcktion
name more or less probably makes only marginal difference.

> > As already mentioned, let us apply the patch so that other Cortex A8
> > patches are not stalled any more. Then everybody (including you) can
> > send additional patches for further improvements.
> It's plan as I'm working currentlty on the mmu and d-cache support for arm
> and the current arm implementation will be udpated really soon to allow
> this and after I'll take a look in the relocation scheme on arm

So this is all plans for some future release. Fine.

But what we're discussing here is a patch for the current release.
And we've been told that other development depends on getting this
into a working state, so I even tend to consider this a bug fix.

I think specific needs for the current release must have higher
priority than some unspecific and unconfirmed plans for some later
release.


Best regards,

Wolfgang Denk

-- 
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
"I've seen it. It's rubbish."          - Marvin the Paranoid Android