linux-kernel - Re: [PATCH 5/6] mips: bmips: enable RAC on BMIPS4350

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 3 May 2024 23:15:46 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: Daniel González Cabanelas <dgcbueu@...il.com>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Rafał Miłecki <zajec5@...il.com>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Álvaro Fernández Rojas <noltari@...il.com>,
	linux-mips@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/6] mips: bmips: enable RAC on BMIPS4350

On Fri, May 03, 2024 at 11:11:13PM +0200, Daniel González Cabanelas wrote:
> El vie, 3 may 2024 a las 20:56, Florian Fainelli
> (<florian.fainelli@...adcom.com>) escribió:
> >
> > On 5/3/24 06:54, Christian Marangi wrote:
> > > From: Daniel González Cabanelas <dgcbueu@...il.com>
> > >
> > > The data RAC is left disabled by the bootloader in some SoCs, at least in
> > > the core it boots from.
> > > Enabling this feature increases the performance up to +30% depending on the
> > > task.
> > >
> > > Signed-off-by: Daniel González Cabanelas <dgcbueu@...il.com>
> > > Signed-off-by: Álvaro Fernández Rojas <noltari@...il.com>
> > > [ rework code and reduce code duplication ]
> > > Signed-off-by: Christian Marangi <ansuelsmth@...il.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-bmips.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 = BMIPS_RAC_CONFIG_1;
> > > +
> > > +             if (!(read_c0_brcm_cmt_local() & (1 << 31)))
> > > +                     rac_addr = BMIPS_RAC_CONFIG;
> > > +
> > > +             /* Enable data RAC */
> > > +             cfg = __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
> write 0xF. I checked it on some devices with BCM6328, 6358, 6368 SoCs.
>
> Example, without the patch, reading the RAC Configuration Register 0 and 1:
>
> - BCM6368 booting from TP0:
> root@...nWrt:/# devmem 0xff400000
> 0x02A07015
> root@...nWrt:/# devmem 0xff400008
> 0x0000000F
>
> - BCM6368 booting from TP1:
> root@...nWrt:/# devmem 0xff400000
> 0x02A0701F
> root@...nWrt:/# devmem 0xff400008
> 0x00000005
> root@...nWrt:/#
>

[ 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.

-- 
	Ansuel