From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Date: Mon, 5 Nov 2012 23:59:45 +0100 [thread overview]
Message-ID: <201211052359.45918.marex@denx.de> (raw)
In-Reply-To: <CAPnjgZ2NqxRKuoQhFntR4JCu+5L_xEwHXZqv7+xvet-E5ES+OQ@mail.gmail.com>
Dear Simon Glass,
> Hi,
>
> On Wed, Oct 31, 2012 at 9:52 AM, Tom Warren <TWarren@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@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.
Just apply this. PXA is mostly dead anyway.
Best regards,
Marek Vasut
prev parent reply other threads:[~2012-11-05 22:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 23:38 [U-Boot] [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2 Simon Glass
2012-10-31 11:55 ` Marek Vasut
2012-10-31 14:44 ` Tom Rini
2012-10-31 16:41 ` Marek Vasut
2012-10-31 16:52 ` Tom Warren
2012-11-05 20:47 ` Simon Glass
2012-11-05 22:59 ` Marek Vasut [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201211052359.45918.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox