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

[Dirk Behme]

Tom wrote:
> 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.

Yes. Agreed.

Best regards

Dirk