On Wednesday, September 14, 2011 11:13:40 Simon Glass wrote:
> On Wed, Sep 14, 2011 at 6:10 AM, Aneesh V wrote:
> >> not specific to your patch, but this seems kind of dumb to copy & paste
> >> the same thing between all the arm sub arches/boards. why cant the
> >> default enable_caches() look like this for arm:
> >> void enable_caches(void)
> >> {
> >> #ifndef CONFIG_SYS_DCACHE_OFF
> >> dcache_enable();
> >> #endif
> >> #ifndef CONFIG_SYS_ICACHE_OFF
> >> icache_enable();
> >> #endif
> >> }
> >
> > That was how it was earlier. But then many boards were not cache ready
> > and still didn't define CONFIG_SYS_DCACHE_OFF, so they were broken. So,
> > the current situation is that the absence of CONFIG_SYS_DCACHE_OFF
> > doesn't mean that the board is cache-ready.
> >
> > I like the suggestion made by Jason Liu, that of using
> > CONFIG_SYS_DCACHE_ON instead. In the present situation ARM cpus that
> > properly support cache handling seems to be in the minority, so
> > CONFIG_SYS_DCACHE_ON may be more appropriate. But Wolfgang doesn't seem
> > to like this.
>
> My concern with this is that the situation will never improve. At
> least this way there will be an incentive to sort things out, since
> one day the cache enable code will be in arch/arm/lib/board.c. I hope
> it is soon, but it will need more driver support first.
right ... this sounds like the sort of thing that takes much longer than it
should. i'm not the arm maintainer, but it seems like it'd have been better
to add CONFIG_SYS_{I,D}CACHE_OFF to all the arm board configs and leave it up
to the maintainers to turn off. then there'd be no duplication in core code
and no long term migration need.
until that happens, CONFIG_SYS_{D,I}CACHE_ON sounds like a reasonable way to
get things back under control.
-mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
