[U-Boot] [PATCH] ARM: Generic cache ops skeleton

[Simon Glass]

Hi,

On Sun, Nov 6, 2011 at 10:07 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
>> On Sunday 06 November 2011 07:39:56 Marek Vasut wrote:
>> > > On Saturday 05 November 2011 21:16:23 Marek Vasut wrote:
>> > > > This patch should allow a CPU to register it's own cache ops. This
>> > > > shall allow multiple CPUs with different cache handlings to be
>> > > > supported.
>> > >
>> > > sorry, what's the point ?  this would make sense if you wanted to build
>> > > one u- boot image to run on multiple SoCs, but since that doesn't make
>> > > sense, i don't see what this patch gets you.
>> >
>> > Well that's the ultimate goal, isn't it ...
>>
>> is it actually ?  i must have missed the memo.

It's actually a lot more than cache ops. SOCs have there own clock
stuff, pinmux things, power mgmt, timers and the like. While it might
be desirable to provide this feature it is a fair bit of work and we
need to be careful not to make things more complex.

I would settle for an initial step of getting some sort of unified but
simple clock/pinmux support in across all ARM. Anyone interested in
that? I mean an API that covers the lot, not an implementation. Also
it would be nice to avoid the heavy-weight data structures and strings
that Linux has. If we got that far then we could make the interface
virtual as Marek has done for caches.

On this particular patch, I feel it should be more explicit about L1
cache, which is what I think it deals with. We may want to support L2
also through a similar API. And a CONFIG option is a good idea.

Finally, even the CP15/cache/MMU code is duplicated in different
arch/arm/cpu subdirs. Can we unify this a bit?

Regards,
Simon

>>
>> support for multiple-SoC-support-in-a-single-image shouldn't bloat the
>> single SoC case.  this code seems to do just that.  so it sounds like you
>> should find a CONFIG name for this setup and start putting everything
>> behind that.
>
> That's a good point indeed. The other question is, if gcc4.6's LTO won't fix
> that for us. Surely enough though, we can't rely on that.
>>
>> maybe something like CONFIG_SYS_MULTI_SOC.
>
> Yea
>
>> -mike
>
> M
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>