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

Message

Serge Semin March 6, 2020, 1:07 p.m. UTC

From: Serge Semin <[e-mail]>

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").

Signed-off-by: Serge Semin <[e-mail]>
Signed-off-by: Alexey Malahov <[e-mail]>
Cc: Maxim Kaurkin <[e-mail]>
Cc: Pavel Parkhomenko <[e-mail]>
Cc: Ramil Zaripov <[e-mail]>
Cc: Ekaterina Skachko <[e-mail]>
Cc: Vadim Vlasov <[e-mail]>
Cc: Thomas Bogendoerfer <[e-mail]>
Cc: Paul Burton <[e-mail]>
Cc: Ralf Baechle <[e-mail]>
Cc: Rob Herring <[e-mail]>
Cc: Mark Rutland <[e-mail]>
Cc: Arnd Bergmann <[e-mail]>
Cc: Olof Johansson <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]

Serge Semin (6):
  dt-bindings: Add Baikal-T1 AXI-bus EHB dts bindings file
  dt-bindings: Add Baikal-T1 APB-bus EHB dts bindings file
  dt-bindings: Add Baikal-T1 L2-cache Control Block dts bindings file
  soc: bt1: Add Baikal-T1 AXI-bus EHB driver
  soc: bt1: Add Baikal-T1 APB-bus EHB driver
  soc: bt1: Add Baikal-T1 L2-cache Control Block driver

 .../soc/baikal-t1/be,bt1-apb-ehb.yaml         |  66 +++
 .../soc/baikal-t1/be,bt1-axi-ehb.yaml         |  52 +++
 .../bindings/soc/baikal-t1/be,bt1-l2-ctl.yaml | 108 +++++
 drivers/soc/Kconfig                           |   1 +
 drivers/soc/Makefile                          |   1 +
 drivers/soc/baikal-t1/Kconfig                 |  49 +++
 drivers/soc/baikal-t1/Makefile                |   4 +
 drivers/soc/baikal-t1/apb-ehb.c               | 381 ++++++++++++++++++
 drivers/soc/baikal-t1/axi-ehb.c               | 250 ++++++++++++
 drivers/soc/baikal-t1/common.h                |  37 ++
 drivers/soc/baikal-t1/l2-ctl.c                | 325 +++++++++++++++
 11 files changed, 1274 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/baikal-t1/be,bt1-apb-ehb.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/baikal-t1/be,bt1-axi-ehb.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/baikal-t1/be,bt1-l2-ctl.yaml
 create mode 100644 drivers/soc/baikal-t1/Kconfig
 create mode 100644 drivers/soc/baikal-t1/Makefile
 create mode 100644 drivers/soc/baikal-t1/apb-ehb.c
 create mode 100644 drivers/soc/baikal-t1/axi-ehb.c
 create mode 100644 drivers/soc/baikal-t1/common.h
 create mode 100644 drivers/soc/baikal-t1/l2-ctl.c

Comments

Arnd Bergmann March 6, 2020, 3:19 p.m. UTC | #1

On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
>
> From: Serge Semin <[e-mail]>
>
> 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.

          Arnd

Rob Herring (Arm) March 12, 2020, 9:25 p.m. UTC | #2

On Fri, Mar 06, 2020 at 04:19:47PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> >
> > From: Serge Semin <[e-mail]>
> >
> > 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

Rob Herring (Arm) March 12, 2020, 9:26 p.m. UTC | #3

On Fri, Mar 06, 2020 at 04:07:15PM +0300, [e-mail] wrote:
> From: Serge Semin <[e-mail]>
> 
> 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").
> 
> Signed-off-by: Serge Semin <[e-mail]>
> Signed-off-by: Alexey Malahov <[e-mail]>
> Cc: Maxim Kaurkin <[e-mail]>
> Cc: Pavel Parkhomenko <[e-mail]>
> Cc: Ramil Zaripov <[e-mail]>
> Cc: Ekaterina Skachko <[e-mail]>
> Cc: Vadim Vlasov <[e-mail]>
> Cc: Thomas Bogendoerfer <[e-mail]>
> Cc: Paul Burton <[e-mail]>
> Cc: Ralf Baechle <[e-mail]>
> Cc: Rob Herring <[e-mail]>
> Cc: Mark Rutland <[e-mail]>
> Cc: Arnd Bergmann <[e-mail]>
> Cc: Olof Johansson <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Cc: [e-mail]
> 
> Serge Semin (6):
>   dt-bindings: Add Baikal-T1 AXI-bus EHB dts bindings file
>   dt-bindings: Add Baikal-T1 APB-bus EHB dts bindings file

These 2 look fine other than the same comments given on your other 
patches.

Rob

Arnd Bergmann March 26, 2020, 2:12 p.m. UTC | #4

On Fri, Mar 6, 2020 at 4:19 PM Arnd Bergmann <[e-mail]> wrote:
>
> On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> >
> > From: Serge Semin <[e-mail]>
> >
> > 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 see a reply to Rob's or my comments, so I assume you are not currently
updating them and I will wait for a new version after the v5.7 merge window.

Dropping the series from patchwork for now, see [1].

       Arnd

[1] https://patchwork.kernel.org/project/linux-soc/list/

Serge Semin April 1, 2020, 3:06 p.m. UTC | #5

Hello Arnd,

On Fri, Mar 06, 2020 at 04:19:47PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> >
> > From: Serge Semin <[e-mail]>
> >
> > 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.
> 
>           Arnd

Sorry for a delay. I was analyzing and fixing comments, which were raised
in the framework of anther patchsets I've submitted. Some of them including
yours cause bigger changes than just a few fixups and might be resolved
at once by a solution I've described in RFC: https://lkml.org/lkml/2020/3/22/393
You've been in Cc there, so feel free to send your comments.

Regarding ehb drivers. You are right. They should be moved to the drivers/bus
(it has also been described in the RFC). It is more suitable place for them.
I'll do it in v2.

Regarding l2 driver. Do you really think that L2 cache should be in
drivers/memory? First there is no any cache-related drivers in that
subsystem (at least I couldn't find any). Second the Baikal-T1
L2-cache-RAM config block has just indirect connection with RAM.
The block just tunes the L2-cache<->RAM stall clock cycles up on
WS/Tag/Data RAM IO-operations. This config seems more SoC-specific,
than memory-like. Do you think that the driver should still be in
drivers/memory?

On the other hand the block is part of the System Controller. I could
just embed the l2-cache driver functionality into the System Controller
MFD driver. Though honestly IMHO the functionality should live in
a dedicated driver and drivers/soc is a better place for it. I also have
doubts this part will be well accepted by Lee (drivers/mfd maintainer).

So what do you think?

Regards,
-Sergey

Serge Semin April 1, 2020, 3:32 p.m. UTC | #6

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 <[e-mail]> wrote:
> > >
> > > From: Serge Semin <[e-mail]>
> > >
> > > 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

Serge Semin April 1, 2020, 3:37 p.m. UTC | #7

On Thu, Mar 26, 2020 at 03:12:46PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 6, 2020 at 4:19 PM Arnd Bergmann <[e-mail]> wrote:
> >
> > On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> > >
> > > From: Serge Semin <[e-mail]>
> > >
> > > 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 see a reply to Rob's or my comments, so I assume you are not currently
> updating them and I will wait for a new version after the v5.7 merge window.
> 
> Dropping the series from patchwork for now, see [1].
> 
>        Arnd
> 
> [1] https://patchwork.kernel.org/project/linux-soc/list/

Yeah, sorry for the delay. I'll send an update very soon. A solution for
the ehb'es is settled. We agreed to move the drivers to the drivers/bus
subsystem. While we still don't know what to do with l2-cache driver.
Please see my last response to your comment on the cover-letter.

Regards,
-Sergey

Arnd Bergmann April 1, 2020, 7:10 p.m. UTC | #8

On Wed, Apr 1, 2020 at 5:06 PM Sergey Semin
<[e-mail]> wrote:
> On Fri, Mar 06, 2020 at 04:19:47PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> > >
> > > From: Serge Semin <[e-mail]>
> > >
> > > 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.
> >

> Regarding l2 driver. Do you really think that L2 cache should be in
> drivers/memory? First there is no any cache-related drivers in that
> subsystem (at least I couldn't find any). Second the Baikal-T1
> L2-cache-RAM config block has just indirect connection with RAM.
> The block just tunes the L2-cache<->RAM stall clock cycles up on
> WS/Tag/Data RAM IO-operations. This config seems more SoC-specific,
> than memory-like. Do you think that the driver should still be in
> drivers/memory?

Either way could work, and both locations are a bit of a dumping
ground for different kinds of drivers. My preference would be
drivers/memory, but if anyone has a strong opinion the other way,
drivers/soc would be acceptable as well.

> On the other hand the block is part of the System Controller. I could
> just embed the l2-cache driver functionality into the System Controller
> MFD driver. Though honestly IMHO the functionality should live in
> a dedicated driver and drivers/soc is a better place for it. I also have
> doubts this part will be well accepted by Lee (drivers/mfd maintainer).
>
> So what do you think?

If you make it a combined driver with the system controller,
drivers/soc would be the most logical place. drivers/mfd should
only be used for a multiplexer with child drivers doing the
actual functionality.

        Arnd

Serge Semin April 1, 2020, 9:52 p.m. UTC | #9

On Wed, Apr 01, 2020 at 09:10:20PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 1, 2020 at 5:06 PM Sergey Semin
> <[e-mail]> wrote:
> > On Fri, Mar 06, 2020 at 04:19:47PM +0100, Arnd Bergmann wrote:
> > > On Fri, Mar 6, 2020 at 2:07 PM <[e-mail]> wrote:
> > > >
> > > > From: Serge Semin <[e-mail]>
> > > >
> > > > 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.
> > >
> 
> > Regarding l2 driver. Do you really think that L2 cache should be in
> > drivers/memory? First there is no any cache-related drivers in that
> > subsystem (at least I couldn't find any). Second the Baikal-T1
> > L2-cache-RAM config block has just indirect connection with RAM.
> > The block just tunes the L2-cache<->RAM stall clock cycles up on
> > WS/Tag/Data RAM IO-operations. This config seems more SoC-specific,
> > than memory-like. Do you think that the driver should still be in
> > drivers/memory?
> 
> Either way could work, and both locations are a bit of a dumping
> ground for different kinds of drivers. My preference would be
> drivers/memory, but if anyone has a strong opinion the other way,
> drivers/soc would be acceptable as well.
> 
> > On the other hand the block is part of the System Controller. I could
> > just embed the l2-cache driver functionality into the System Controller
> > MFD driver. Though honestly IMHO the functionality should live in
> > a dedicated driver and drivers/soc is a better place for it. I also have
> > doubts this part will be well accepted by Lee (drivers/mfd maintainer).
> >
> > So what do you think?
> 
> If you make it a combined driver with the system controller,
> drivers/soc would be the most logical place. drivers/mfd should
> only be used for a multiplexer with child drivers doing the
> actual functionality.
> 
>         Arnd

I see. Thanks for the comment. I'll move the l2-cache driver to the
drivers/memory then and send a new patchset referring to this discussion
when it's ready. I'll make sure it'll be Cc'ed to you too.

Regards,
-Sergey

Serge Semin May 7, 2020, 10:41 p.m. UTC | #10

Baikal-T1 SoC CPU is based on two MIPS Warrior P5600 cores. Their main
memory Non-Coherent IO interface is connected to the OCP2AXI bridge, which
in turn is then connected to the DW AMBA 3 AXI Interconnect (so called Main
Interconnect) with nine masters and four slaves ports. Main Interconnect is
responsible for the AXI-bus traffic arbitration (QoS) and its routing from
one component to another. In addition there is a Errors Handler Block
(EHB) responsible to detect AXI protocol errors and device not responding
situations built on top the interconnect. Baikal-T1 AXI-bus driver included in
this patchset will be responsible for working with that functionality,
though currently it doesn't support QoS tuning. Instead it's capable of
detecting the error events, reporting an info about them to the system
log, injecting artificial errors to test the driver functionality.
Since AXI Interconnect doesn't provide a way to find out which devices are
connected to it, so its DT node is supposed to be compatible with
"simple-bus" driver, while sub-nodes shall represent the masters attached
to the bus.

One of the AXI Interconnect slaves is an AXI-APB bridge used to access the
Baikal-T1 SoC subsystems CSRs. MMIO request from CPU and DMAC masters are
routed there if they are detected to be within [0x08000000 0x1FFFFFFF]
range of the physical memory. In case if an attempted APB transaction
stays with no response for a pre-defined time it will be detected by the
APB-bus Errors Handler Block (EHB), which will raise an interrupt, then
the bus gets freed for a next operation. The APB-bus driver provides the
interrupt handler to detect the erroneous address, update an errors
counter and prints an error message about the faulty address. The counter
and the APB-bus operations timeout can be accessed via corresponding sysfs
nodes. A dedicated sysfs-node can be also used to artificially cause the
bus errors described above. Since APB-bus is a platform bus, it doesn't
provide a way to detect slave devices connected to it, so similarly to the
AXI-bus it's also supposed to be compatible with "simple-bus" driver.

This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4

Note initially the driver was a part of the patchset created to reside in
the kernel soc subsystem. But after a short discussion with Arnd:
https://lkml.org/lkml/2020/3/6/422
we decided to move it here.

New vendor prefix will be added in the framework of the next patchset:
https://lkml.org/lkml/2020/5/6/1047

Changelog v2:
- Assign dual GPL/BSD licenses to the bindings.
- Use single lined copyright headers in the bindings.
- Replace "additionalProperties: false" property with
  "unevaluatedProperties: false" in the bindings.
- Don't use a multi-arg clock phandle reference in DT binding examples.
  Thus remove includes from there.
- Fix some commit message and Kconfig help text spelling.
- Move drivers from soc to the bus subsystem.
- Convert a simple EHB drivers to the Baikal-T1 AXI and APB bus ones.
- Convert APB bus driver to using regmap MMIO API.
- Use syscon regmap to access the AXI-bus erroneous address.
- Add reset line support.
- Add Main Interconnect clock support to the AXI-bus driver.
- Remove probe-status info string printout.
- Discard of_match_ptr() macro utilization.
- Don't print error-message if no platform IRQ found. Just return an error.
- Use generic FIELD_{GET,PREP} macros instead of handwritten ones in the
  AXI-bus driver.

Signed-off-by: Serge Semin <[e-mail]>
Cc: Alexey Malahov <[e-mail]>
Cc: Maxim Kaurkin <[e-mail]>
Cc: Pavel Parkhomenko <[e-mail]>
Cc: Ramil Zaripov <[e-mail]>
Cc: Ekaterina Skachko <[e-mail]>
Cc: Vadim Vlasov <[e-mail]>
Cc: Alexey Kolotnikov <[e-mail]>
Cc: Paul Burton <[e-mail]>
Cc: Ralf Baechle <[e-mail]>
Cc: Tony Lindgren <[e-mail]>
Cc: Tero Kristo <[e-mail]>
Cc: Manivannan Sadhasivam <[e-mail]>
Cc: Jeffrey Hugo <[e-mail]>
Cc: Linus Walleij <[e-mail]>
Cc: Rob Herring <[e-mail]>
Cc: Olof Johansson <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Cc: [e-mail]

Serge Semin (4):
  dt-bindings: bus: Add Baikal-T1 AXI-bus binding
  dt-bindings: bus: Add Baikal-T1 APB-bus binding
  bus: Add Baikal-T1 AXI-bus driver
  bus: Add Baikal-T1 APB-bus driver

 .../bindings/bus/baikal,bt1-apb.yaml          |  90 ++++
 .../bindings/bus/baikal,bt1-axi.yaml          |  95 ++++
 drivers/bus/Kconfig                           |  30 ++
 drivers/bus/Makefile                          |   2 +
 drivers/bus/bt1-apb.c                         | 421 ++++++++++++++++++
 drivers/bus/bt1-axi.c                         | 318 +++++++++++++
 6 files changed, 956 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml
 create mode 100644 Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml
 create mode 100644 drivers/bus/bt1-apb.c
 create mode 100644 drivers/bus/bt1-axi.c