[U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:45 Fri 04 Sep     , Dirk Behme wrote:
> Kyungmin Park wrote:
> > Hi,
> > 
> > As he goes to home, I reply it instead.
> 
> Nice weekend then :)
> 
> > On Fri, Sep 4, 2009 at 5:43 PM, Dirk Behme<dirk.behme at googlemail.com> wrote:
> >> Dear Minkyu Kang,
> >>
> >> Minkyu Kang wrote:
> >>> Current code is supported only omap3 soc.
> >>> this patch will support s5pc1xx(s5pc100 and s5pc110) soc also.
> >> Thanks for this patch!
> >>
> >> How is this patch related to
> >>
> >> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
> >>
> > 
> > It's not good idea to move invalidate_cache to omap directory. we need it.
> 
> Well, yes and no ;)
> 
> Most probably you (== Samsung) can't use the invalidate_dcache version 
> we move in above patch to omap directory, because the version we move 
> above is OMAP3 specific (it has calls to OMAP3 ROM code). So no, it's 
> a good idea to move OMAP3 specific code to omap directory.
It's certainly not as the OMAP3 does not need to call the ROM code
so we can share the same for for S3P and omap3

> 
> But yes, you might need DCache flush (*). So the idea of above patch 
> was to have your own (or generic) implementation, but let OMAP3 use 
> the custom one where needed.
no need for omap3

> 
> (*) Do you really need DCache flush? It always was Jean-Christophe's 
> argument that U-Boot doesn't use any DCache at all.
It's true but U-Boot is not necessarely the first stage loader so yes
we will clean all cache
> 
> "0xC100" is the device type of s5pc100 then? So it should be
> 
> if (get_device_type() != S5PC100_DEVICE)
> 
> ? I hear some people crying "please use macro" ;)
> 
> But I don't like this selection here. When we get additional similar 
> SoCs, we will end with something like
> 
> if (get_device_type() != 0xC100) ||
>    (get_device_type() != FOO) ||
>    (get_device_type() != BAR))  ||
>    ... {
> 
> modifying each time cpu/arm_cortexa8/cpu.c.
> 
> I would like more that we are able to compile the functionality based 
> on the config file we use for compilation. E.g. provide emtpy 
> l2_cache_disable(); function for SoCs that don't need it, but have 
> functionality behind it where needed.
multiple soc support will clearly simplify board support and improve code
testing but it's need to have the possiblity to be disable as the compile
to minimize the size impact

Best Regards,
n
J