Received-SPF: pass (google.com: domain of linux-kernel+bounces-168261-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240503135455.966-1-ansuelsmth@gmail.com> <20240503135455.966-6-ansuelsmth@gmail.com>
 <5529fe79-e2f8-47ab-a0cf-2b37bb13bbd7@broadcom.com> <CABwr4_sz4DKjp_cJqTNBCyQSUhXGJM4_h1JSiK-h=8uAbPPoVQ@mail.gmail.com>
 <66355403.050a0220.9e59a.8031@mx.google.com>
In-Reply-To: <66355403.050a0220.9e59a.8031@mx.google.com>
From: =?UTF-8?Q?Daniel_Gonz=C3=A1lez_Cabanelas?= <dgcbueu@gmail.com>
Date: Fri, 3 May 2024 23:34:41 +0200
Message-ID: <CABwr4_u6bgdWHeYwyDTW3xoM-z+JaEPan98jY7QZjP6thgkGRA@mail.gmail.com>
Subject: Re: [PATCH 5/6] mips: bmips: enable RAC on BMIPS4350
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Florian Fainelli <florian.fainelli@broadcom.com>, Hauke Mehrtens <hauke@hauke-m.de>, 
	=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>, 
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Rob Herring <robh@kernel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, 
	Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, 
	=?UTF-8?B?w4FsdmFybyBGZXJuw6FuZGV6IFJvamFz?= <noltari@gmail.com>, 
	linux-mips@vger.kernel.org, devicetree@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

El vie, 3 may 2024 a las 23:15, Christian Marangi
(<ansuelsmth@gmail.com>) escribi=C3=B3:
>
> On Fri, May 03, 2024 at 11:11:13PM +0200, Daniel Gonz=C3=A1lez Cabanelas =
wrote:
> > El vie, 3 may 2024 a las 20:56, Florian Fainelli
> > (<florian.fainelli@broadcom.com>) escribi=C3=B3:
> > >
> > > On 5/3/24 06:54, Christian Marangi wrote:
> > > > From: Daniel Gonz=C3=A1lez Cabanelas <dgcbueu@gmail.com>
> > > >
> > > > The data RAC is left disabled by the bootloader in some SoCs, at le=
ast in
> > > > the core it boots from.
> > > > Enabling this feature increases the performance up to +30% dependin=
g on the
> > > > task.
> > > >
> > > > Signed-off-by: Daniel Gonz=C3=A1lez Cabanelas <dgcbueu@gmail.com>
> > > > Signed-off-by: =C3=81lvaro Fern=C3=A1ndez Rojas <noltari@gmail.com>
> > > > [ rework code and reduce code duplication ]
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > ---
> > > >   arch/mips/kernel/smp-bmips.c | 12 ++++++++++++
> > > >   1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bm=
ips.c
> > > > index 6048c471b5ee..7bde6bbaa41f 100644
> > > > --- a/arch/mips/kernel/smp-bmips.c
> > > > +++ b/arch/mips/kernel/smp-bmips.c
> > > > @@ -617,6 +617,18 @@ void bmips_cpu_setup(void)
> > > >               __raw_readl(bmips_cbr_addr + BMIPS_RAC_ADDRESS_RANGE)=
;
> > > >               break;
> > > >
> > > > +     case CPU_BMIPS4350:
> > > > +             u32 rac_addr =3D BMIPS_RAC_CONFIG_1;
> > > > +
> > > > +             if (!(read_c0_brcm_cmt_local() & (1 << 31)))
> > > > +                     rac_addr =3D BMIPS_RAC_CONFIG;
> > > > +
> > > > +             /* Enable data RAC */
> > > > +             cfg =3D __raw_readl(bmips_cbr_addr + rac_addr);
> > > > +             __raw_writel(cfg | 0xa, bmips_cbr_addr + rac_addr);
> > >
> > > This enables data pre-fetching (bit 3) and data-caching (bit 1), have
> > > you tried with 0xF to see if this provides any additional speed-up?
> > >
> > > Looks correct to me otherwise, I wonder if a flush would be in order
> > > right after enabling, though I did not see any specific instructions
> > > towards that part in the programming notes.
> > >
> > > > +             __raw_readl(bmips_cbr_addr + rac_addr);
> > > > +             break;
> > > > +
> > > >       case CPU_BMIPS4380:
> > > >               /* CBG workaround for early BMIPS4380 CPUs */
> > > >               switch (read_c0_prid()) {
> > >
> > Hi Florian.
> > Bits 0 and 1 are already enabled by the bootloader, so no need to

I meant bits 0 and 2. These are the RAC bits:
#define RAC_FLH         (1 << 8)
#define RAC_DPF         (1 << 6)
#define RAC_NCH         (1 << 5)
#define RAC_C_INV       (1 << 4)
#define RAC_PF_D        (1 << 3)
#define RAC_PF_I        (1 << 2)
#define RAC_D           (1 << 1)
#define RAC_I           (1 << 0)

> > write 0xF. I checked it on some devices with BCM6328, 6358, 6368 SoCs.
> >
> > Example, without the patch, reading the RAC Configuration Register 0 an=
d 1:
> >
> > - BCM6368 booting from TP0:
> > root@OpenWrt:/# devmem 0xff400000
> > 0x02A07015
> > root@OpenWrt:/# devmem 0xff400008
> > 0x0000000F
> >
> > - BCM6368 booting from TP1:
> > root@OpenWrt:/# devmem 0xff400000
> > 0x02A0701F
> > root@OpenWrt:/# devmem 0xff400008
> > 0x00000005
> > root@OpenWrt:/#
> >
>
> [ fixed the top-post ]
>
> If that's the case then i'm setting 0xf since we verified it doesn't
> cause problem and it's already set.

It's harmless to re-enable the instruction bits. BTW the log commit
refers only to data RAC, 0xF is enabling both the data and instruction
RAC.

Daniel
>
> --
>         Ansuel