From: Geert Uytterhoeven <geert@linux-m68k.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Arnd Bergmann <arnd@arndb.de>,
linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh: boot: Remove sh5 cache handling
Date: Mon, 29 Apr 2024 10:06:44 +0200 [thread overview]
Message-ID: <CAMuHMdXRDRfTB7WCP8O2ubgN3_9L6Hz2yEcUY3urFksM-2FEmg@mail.gmail.com> (raw)
In-Reply-To: <23a3abf08f358588ef448c1a2f2ef53013ce6b69.camel@physik.fu-berlin.de>
Hi Adrian,
On Mon, Apr 29, 2024 at 9:52 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Mon, 2024-04-29 at 09:49 +0200, Geert Uytterhoeven wrote:
> > On Mon, Apr 29, 2024 at 9:46 AM John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> > > On Wed, 2024-04-24 at 13:54 +0200, Geert Uytterhoeven wrote:
> > > > Commit 37744feebc086908 ("sh: remove sh5 support") in v5.8 forgot to
> > > > remove the sh5 cache handling.
> > > >
> > > > Suggested-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > > > --- a/arch/sh/boot/compressed/cache.c
> > > > +++ /dev/null
> > > > @@ -1,13 +0,0 @@
> > > > -// SPDX-License-Identifier: GPL-2.0
> > > > -int cache_control(unsigned int command)
> > > > -{
> > > > - volatile unsigned int *p = (volatile unsigned int *) 0x80000000;
> > > > - int i;
> > > > -
> > > > - for (i = 0; i < (32 * 1024); i += 32) {
> > > > - (void)*p;
> > > > - p += (32 / sizeof(int));
> > > > - }
> > > > -
> > > > - return 0;
> > > > -}
> >
> > > Interesting, looking at boot/compressed/cache.c, it seems that the whole code
> > > is actually a no-op and does nothing but increasing a pointer. So I agree we
> > > should just delete it.
> >
> > It is not a no-op: it also reads from memory, to load new data in
> > the cache, and evicting the old data.
>
> Yeah, I actually came to this conclusion right after sending my reply. However, the
> command parameter is never used.
>
> Don't have the 32-bit SH CPUs any caches? The code itself is unconditionally executed,
> it seems.
They do. E.g. SH7751 has 8+8 KiB of L1 cache.
But e.g. sh7724 has 32+32KiB L1 cache, and 256 KiB of unified L2 cache.
SH772[34] have l2_cache_init() to enable the L2 cache, so probably they
boot with L2 disabled, and we are fine.
Unfortunately I don't have access to a SH772[34] system.
Sato-san: can you confirm?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2024-04-29 8:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 11:54 [PATCH] sh: boot: Remove sh5 cache handling Geert Uytterhoeven
2024-04-29 7:46 ` John Paul Adrian Glaubitz
2024-04-29 7:49 ` Geert Uytterhoeven
2024-04-29 7:52 ` John Paul Adrian Glaubitz
2024-04-29 8:06 ` Geert Uytterhoeven [this message]
2024-04-29 8:22 ` John Paul Adrian Glaubitz
2024-04-29 8:29 ` Geert Uytterhoeven
2024-05-02 13:50 ` Yoshinori Sato
2024-05-01 9:26 ` John Paul Adrian Glaubitz
2024-05-02 7:25 ` Geert Uytterhoeven
2024-05-02 10:32 ` John Paul Adrian Glaubitz
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=CAMuHMdXRDRfTB7WCP8O2ubgN3_9L6Hz2yEcUY3urFksM-2FEmg@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=arnd@arndb.de \
--cc=dalias@libc.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-sh@vger.kernel.org \
--cc=ysato@users.sourceforge.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.