Re: [PATCH 0/6] soc: Add Baikal-T1 SoC APB/AXI EHB and L2-cache drivers

From: Sergey Semin
Date: Wed Apr 01 2020 - 11:32:51 EST


On Thu, Mar 12, 2020 at 04:25:57PM -0500, Rob Herring wrote:
> On Fri, Mar 06, 2020 at 04:19:47PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 6, 2020 at 2:07 PM <Sergey.Semin@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > From: Serge Semin <fancer.lancer@xxxxxxxxx>
> > >
> > > Aside from PCIe/SATA/DDR/I2C/CPU-reboot specific settings the Baikal-T1
> > > system controller provides three vendor-specific blocks. In particular
> > > there are two Errors Handler Blocks to detect and report an info regarding
> > > any problems discovered on the AXI and APB buses. These are the main buses
> > > utilized by the SoC devices to interact with each other. In addition there
> > > is a way to tune the MIPS P5600 CM2 L2-cache up by setting the Tag/Data/WS
> > > L2-to-RAM latencies. All of this functionality is implemented in the
> > > APB/AXI EHB and L2-cache control block drivers to be a part of the kernel soc
> > > subsystem (as being specific to the Baikal-T1 SoC) and introduced in the
> > > framework of this patchset.
> > >
> > > This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> > > commit 98d54f81e36b ("Linux 5.6-rc4").
> >
> > I have no objection to the drivers, but I wonder if these should be
> > in drivers/bus and drivers/memory instead of drivers/soc, which have
> > similar drivers already. The driver for the L2 cache is not really a
> > memory controller driver, but it may be close enough, and we
> > already have a couple of different things in there.
>
> I don't have the driver side in my inbox, but isn't setting up cache
> latencies in a driver a little late?
>
> Rob

Generally speaking there is no much difference at what moment the driver
is loaded and device is probed. First of all the L2-RAM latencies should be
setup by the system bootloader before RAM is detected and the memory controller
is enabled and run (though default value is normally Ok to use). In a worst case
if the bootloader did something wrong it may cause either the performance
degradation (up to 10% - 20% drop), or the system may get to be absolutely
unstable. In the later the kernel (and bootloader) may collapse at any moment,
most likely before the driver is loaded even at the very first possible stage.
Due to this uncertainty the upcoming l2-cache tuning stage doesn't really matter.

So this driver can be used either to tune the system performance up by updating
the system dtb while leaving the bootloader code unchanged, or by setting the
latencies from user-space to the corresponding sysfs nodes exported by
the driver.

Regards,
-Sergey