On 20:03 Sat 08 Aug , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090808152633.GD17045@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.