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

[Tom]

Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>>> Applying the basic functionality (function move) now allows others
>>>>>>> to finally go on with their long waiting patches.
>>>>>>>               
>>>>>> no this code is omap3 specific and there is no need ot this
>>>>>> rename or move the function make no sense
>>>>>>             
>>>>> Yes, it is OMAP3 specific (as already mentioned in the patch
>>>>> description). So it's totally fine to move it to an OMAP3 specific
>>>>> file. So it's totally fine that others (!= OMAP3, e.g Samsung) can
>>>>> re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
>>>>>           
>>>> the flush MUST NOT be soc specific as there is NO need to do this
>>>> at all
>>>>
>>>> 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"
>>>
>>> Sorry, but this sounds somehow confusing, better let us stop here.
>>>
>>> As already mentioned, let us apply the patch so that other Cortex
>>> A8 patches are not stalled any more.
>>>       
>> At the weekend, I missed the point why this code is OMAP3 specific
>> and why it has to be moved to omap3 directory, so short update:
>>
>> It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g.
>> Samsung. That is, it must be moved to not stall others any more.
>>     
> so I'll repeat this only once there no need to call the rom code as the
> generic armv7 cache full work fine
>
> so no-need to use omap3 specific code
>
>   
I am not sure if the generic code can replace the omap3 code.
I do not have access to the ROM code.
 From what I have seen on the l2_cache code, it seems that in
some cases that the ROM code handles earlier revs of the hardware.
I would be in favor of phasing in the new generic code so that if
older hardware needed to use the ROM code it could.
Not know knowing full effect of the change we should go slowly and provide
options for legacy support up front.
Tom
> Best Regards,
> J.
>