From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
Marek Vasut <marek.vasut@mailbox.org>
Cc: Tom Rini <trini@konsulko.com>,
Marek Vasut <marek.vasut+renesas@mailbox.org>,
u-boot@lists.denx.de,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Nobuhiro Iwamatsu <iwamatsu@nigauri.org>,
Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: [PATCH] sh: cache: Fill in invalidate_icache_all()
Date: Wed, 11 Sep 2024 09:23:03 +0200 [thread overview]
Message-ID: <2c133f811fca225a0f796b8b94b16e63b33e56a6.camel@physik.fu-berlin.de> (raw)
In-Reply-To: <CAMuHMdVvHtVmH+YP=m20U9-buXKi1+Kwcrkf8vWhQYagcg4JRQ@mail.gmail.com>
Good morning Geert,
On Wed, 2024-09-11 at 09:19 +0200, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, Sep 10, 2024 at 7:55 PM Marek Vasut <marek.vasut@mailbox.org> wrote:
> > On 9/10/24 7:21 PM, Tom Rini wrote:
> > > On Tue, Sep 10, 2024 at 02:15:58AM +0200, Marek Vasut wrote:
> > >
> > > > Implement invalidate_icache_all() by clearing all V bits in
> > > > IC and OC. This is done by setting CCR cache control register
> > > > ICI and OCI bits.
> > > >
> > > > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > > > ---
> > > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > > > Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> > > > Cc: Tom Rini <trini@konsulko.com>
> > > > Cc: u-boot@lists.denx.de
> > > > ---
> > > > arch/sh/cpu/sh4/cache.c | 11 +++++++----
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/sh/cpu/sh4/cache.c b/arch/sh/cpu/sh4/cache.c
> > > > index d3c480e79ed..99acc599965 100644
> > > > --- a/arch/sh/cpu/sh4/cache.c
> > > > +++ b/arch/sh/cpu/sh4/cache.c
> > > > @@ -33,8 +33,9 @@ static inline void cache_wback_all(void)
> > > > }
> > > > }
> > > >
> > > > -#define CACHE_ENABLE 0
> > > > -#define CACHE_DISABLE 1
> > > > +#define CACHE_ENABLE 0
> > > > +#define CACHE_DISABLE 1
> > > > +#define CACHE_INVALIDATE 2
> > > >
> > > > static int cache_control(unsigned int cmd)
> > > > {
> > > > @@ -46,7 +47,9 @@ static int cache_control(unsigned int cmd)
> > > > if (ccr & CCR_CACHE_ENABLE)
> > > > cache_wback_all();
> > > >
> > > > - if (cmd == CACHE_DISABLE)
> > > > + if (cmd == CACHE_INVALIDATE)
> > > > + outl(CCR_CACHE_ICI | ccr, CCR);
> > > > + else if (cmd == CACHE_DISABLE)
> > > > outl(CCR_CACHE_STOP, CCR);
> > > > else
> > > > outl(CCR_CACHE_INIT, CCR);
> > > > @@ -103,7 +106,7 @@ void icache_disable(void)
> > > >
> > > > void invalidate_icache_all(void)
> > > > {
> > > > - puts("No arch specific invalidate_icache_all available!\n");
> > > > + cache_control(CACHE_INVALIDATE);
> > > > }
> > > >
> > > > int icache_status(void)
> > >
> > > Thanks for filling this in, I wasn't sure how the implementation would
> > > look from a quick skim of the linux kernel code.
> > I believe it should look like the above, but lemme CC Geert to be on the
> > safe side.
>
> I have no idea. I removed the corresponding (but incomplete) code
> from Linux in commit 25c7d77d695a4104 ("sh: boot: Remove sh5 cache
> handling"), as it was a relic of sh5 cache handling.
>
> SH4 cache handling seems to be buried deeper. At least the above
> matches for invalidation:
>
> arch/sh/mm/cache-sh4.c- /* Flush I-cache */
> arch/sh/mm/cache-sh4.c: ccr = __raw_readl(SH_CCR);
> arch/sh/mm/cache-sh4.c- ccr |= CCR_CACHE_ICI;
> arch/sh/mm/cache-sh4.c: __raw_writel(ccr, SH_CCR);
Odd, I haven't received the original mail.
@Marek: Could you resent your patch CC'ing the current maintainers of arch/sh?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
next prev parent reply other threads:[~2024-09-11 7:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240910001612.88569-1-marek.vasut+renesas@mailbox.org>
[not found] ` <20240910172151.GG4252@bill-the-cat>
[not found] ` <1cd4c1c1-b709-43aa-aff8-14cb1d21aee2@mailbox.org>
2024-09-11 7:19 ` [PATCH] sh: cache: Fill in invalidate_icache_all() Geert Uytterhoeven
2024-09-11 7:23 ` John Paul Adrian Glaubitz [this message]
2024-09-11 7:29 ` Geert Uytterhoeven
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=2c133f811fca225a0f796b8b94b16e63b33e56a6.camel@physik.fu-berlin.de \
--to=glaubitz@physik.fu-berlin.de \
--cc=geert@linux-m68k.org \
--cc=ilias.apalodimas@linaro.org \
--cc=iwamatsu@nigauri.org \
--cc=linux-sh@vger.kernel.org \
--cc=marek.vasut+renesas@mailbox.org \
--cc=marek.vasut@mailbox.org \
--cc=trini@konsulko.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).