[U-Boot] [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2

[Simon Glass]

Hi,

On Wed, Oct 31, 2012 at 9:52 AM, Tom Warren <TWarren at nvidia.com> wrote:
> Marek,
>
>> -----Original Message-----
>> From: Marek Vasut [mailto:marex at denx.de]
>> Sent: Wednesday, October 31, 2012 9:41 AM
>> To: Tom Rini
>> Cc: Simon Glass; U-Boot Mailing List; Tom Warren
>> Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
>>
>> Dear Tom Rini,
>>
>> > On 10/31/12 04:55, Marek Vasut wrote:
>> > > Dear Simon Glass,
>> > >
>> > >> These platforms don't include dcache support. Define
>> > >> CONFIG_SYS_DCACHE_OFF so that functions don't try to call
>> > >> non-existent routines like flush_dcache_range().
>> > >>
>> > >> Signed-off-by: Simon Glass <sjg at chromium.org>
>> > >
>> > > Is that needed? Why not fix PXA by defining stub cache routines ?
>> >
>> > Adding stubs sounds more like a work-around than disabling support
>> > that we won't have to me.
>>
>> Yes, but then, the stubs will be optimized out.
>>
>> I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should
>> implement at least cache operations stubs, then it'd be valid to use
>> CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the
>> code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or
>> disabled.
>>
>> We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF
>> option.
>
> You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
>
> If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.
>

Is that the final word? If so, Tom Warren should be able to pull this
through. If not, Marek are you going to send a patch to replace this
patch? If that is coming soon, I suggest we wait a few days. If not,
then we can perhaps take this patch and then Marek can clean up later.

Regards,
Simon

> Tom
>>
>> Best regards,
>> Marek Vasut
> --
> nvpublic