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