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

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:03 Sat 08 Aug     , Wolfgang Denk wrote:
> 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();
again no need of omap3 flush code
so just armv7_flush_cache
> ...
> #elif defined(_MIPS32_)
> 	mips32_flush_dcache();
> #elif defined(_MIPS64_)
> 	mips64_flush_dcache();
> ...
> 
> This cannot be your intention?

no on more and more soc as cortex from armltd
the difference between two soc for U-Boot point of view will be the cache version
which we detect via the cp15 and have only one U-Boot for both

> 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.
no the patch cleanup nothing it just move code in omap3 that is mostly armv7
specific and not omap3 specific. The only part that is omap3 specfic is non
need anyway so move it make no sense
> 
> > > 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.
as the current code fix nothing and on contrary introduce a bug as the code in
most armv7 specifc not omap3

the true fix will to remove the omap3 code as it's not needed

Best Regards,
J.