diff mbox series

[v4,2/4] arm64: Add Mellanox BlueField SoC config option

Message ID 1540403734-137721-2-git-send-email-lsun@mellanox.com (mailing list archive)
State New, archived
Headers show
Series [v4,1/4] soc: Add TmFifo driver for Mellanox BlueField Soc | expand

Commit Message

Liming Sun Oct. 24, 2018, 5:55 p.m. UTC 
This commit introduces config option for Mellanox BlueField SoC,
which can be used to build the SoC specific drivers, and enables
it by default in configs/defconfig.

Reviewed-by: David Woods <dwoods@mellanox.com>
Signed-off-by: Liming Sun <lsun@mellanox.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 arch/arm64/configs/defconfig | 1 +
 2 files changed, 7 insertions(+)

Comments

Arnd Bergmann Oct. 25, 2018, 3:38 p.m. UTC | #1 
On 10/24/18, Liming Sun <lsun@mellanox.com> wrote:
> This commit introduces config option for Mellanox BlueField SoC,
> which can be used to build the SoC specific drivers, and enables
> it by default in configs/defconfig.
>
> Reviewed-by: David Woods <dwoods@mellanox.com>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> ---
>  arch/arm64/Kconfig.platforms | 6 ++++++
>  arch/arm64/configs/defconfig | 1 +
>  2 files changed, 7 insertions(+)

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

I'm sorry for missing your series in the past. We should definitely merge
the platform support soon. Do you also have device tree files for reference
systems or even production hardware?

I need to have a separate look at the fifo driver.

Unfortunately, you have sent these patches during the merge window,
which is the time during which we don't pick up new work. Let's plan
to pick these up after 4.20-rc1, and please resend to arm@kernel.org
if we manage to forget about it again.

      Arnd
Liming Sun Oct. 26, 2018, 7:18 p.m. UTC | #2 
Thanks Arnd for the comments!  Please see my response inline.

- Liming

> -----Original Message-----
> From: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] On
> Behalf Of Arnd Bergmann
> Sent: Thursday, October 25, 2018 11:38 AM
> To: Liming Sun <lsun@mellanox.com>
> Cc: Olof Johansson <olof@lixom.net>; David Woods
> <dwoods@mellanox.com>; Robin Murphy <robin.murphy@arm.com>; arm-
> soc <arm@kernel.org>; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 2/4] arm64: Add Mellanox BlueField SoC config option
> 
> On 10/24/18, Liming Sun <lsun@mellanox.com> wrote:
> > This commit introduces config option for Mellanox BlueField SoC,
> > which can be used to build the SoC specific drivers, and enables
> > it by default in configs/defconfig.
> >
> > Reviewed-by: David Woods <dwoods@mellanox.com>
> > Signed-off-by: Liming Sun <lsun@mellanox.com>
> > ---
> >  arch/arm64/Kconfig.platforms | 6 ++++++
> >  arch/arm64/configs/defconfig | 1 +
> >  2 files changed, 7 insertions(+)
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> I'm sorry for missing your series in the past. We should definitely merge
> the platform support soon. Do you also have device tree files for reference
> systems or even production hardware?

We have obsoleted the device tree, and mainly support ACPI now
on Reference/Production HW. Below is the TMFIFO definition in the ACPI
DSDT table.

    // RShim TMFIFO
    Device(RSH0) {
      Name(_HID, "MLNXBF01")
      Name(_UID, Zero)
      Name(_CCA, 1)
      Name(_CRS, ResourceTemplate() {
        Memory32Fixed(ReadWrite, 0x00800a20, 0x00000018)
        Memory32Fixed(ReadWrite, 0x00800a40, 0x00000018)
        Interrupt(ResourceConsumer, Edge, ActiveHigh, Exclusive)
          { BF1_RSH0_TM_HTT_LWM_INT,
            BF1_RSH0_TM_HTT_HWM_INT,
            BF1_RSH0_TM_TTH_LWM_INT,
            BF1_RSH0_TM_TTH_HWM_INT
          }
      })
    }

The full ACPI implementation can be found in the 1.0 release:
http://www.mellanox.com/downloads/BlueField/BlueField-1.0.0.10521/BlueField-1.0.0.10521.tar.xz
Inside this tarball, we can see the "src/edk2/" directory which has the edk2 patch file including all the ACPI implementation.

> 
> I need to have a separate look at the fifo driver.
> 
> Unfortunately, you have sent these patches during the merge window,
> which is the time during which we don't pick up new work. Let's plan
> to pick these up after 4.20-rc1, and please resend to arm@kernel.org
> if we manage to forget about it again.
> 
>       Arnd

Thanks for the information. I'll resend it to make sure not to miss the date.
Arnd Bergmann Oct. 26, 2018, 7:32 p.m. UTC | #3 
On Fri, Oct 26, 2018 at 9:18 PM Liming Sun <lsun@mellanox.com> wrote:
> > -----Original Message-----
> > From: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] On
> > Behalf Of Arnd Bergmann
> > Sent: Thursday, October 25, 2018 11:38 AM
> > To: Liming Sun <lsun@mellanox.com>
> > Cc: Olof Johansson <olof@lixom.net>; David Woods
> > <dwoods@mellanox.com>; Robin Murphy <robin.murphy@arm.com>; arm-
> > soc <arm@kernel.org>; devicetree@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org
> > Subject: Re: [PATCH v4 2/4] arm64: Add Mellanox BlueField SoC config option
> >
> > On 10/24/18, Liming Sun <lsun@mellanox.com> wrote:
> > > This commit introduces config option for Mellanox BlueField SoC,
> > > which can be used to build the SoC specific drivers, and enables
> > > it by default in configs/defconfig.
> > >
> > > Reviewed-by: David Woods <dwoods@mellanox.com>
> > > Signed-off-by: Liming Sun <lsun@mellanox.com>
> > > ---
> > >  arch/arm64/Kconfig.platforms | 6 ++++++
> > >  arch/arm64/configs/defconfig | 1 +
> > >  2 files changed, 7 insertions(+)
> >
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> >
> > I'm sorry for missing your series in the past. We should definitely merge
> > the platform support soon. Do you also have device tree files for reference
> > systems or even production hardware?
>
> We have obsoleted the device tree, and mainly support ACPI now
> on Reference/Production HW. Below is the TMFIFO definition in the ACPI
> DSDT table.
>
>     // RShim TMFIFO
>     Device(RSH0) {
>       Name(_HID, "MLNXBF01")
>       Name(_UID, Zero)
>       Name(_CCA, 1)
>       Name(_CRS, ResourceTemplate() {
>         Memory32Fixed(ReadWrite, 0x00800a20, 0x00000018)
>         Memory32Fixed(ReadWrite, 0x00800a40, 0x00000018)
>         Interrupt(ResourceConsumer, Edge, ActiveHigh, Exclusive)
>           { BF1_RSH0_TM_HTT_LWM_INT,
>             BF1_RSH0_TM_HTT_HWM_INT,
>             BF1_RSH0_TM_TTH_LWM_INT,
>             BF1_RSH0_TM_TTH_HWM_INT
>           }
>       })
>     }
>
> The full ACPI implementation can be found in the 1.0 release:
> http://www.mellanox.com/downloads/BlueField/BlueField-1.0.0.10521/BlueField-1.0.0.10521.tar.xz
> Inside this tarball, we can see the "src/edk2/" directory which has the edk2 patch file including all the ACPI implementation.

It would be nice if you could still include the dts sources in the submission.
Since this is not a classic server hardware, DT is probably more suitable
here, and there are likely use cases that won't work with ACPI, so it's
good to have a starting point for your users if they need to override
the ACPI tables with a DT, or build systems with a simpler boot loader.

       Arnd
Liming Sun Oct. 29, 2018, 2:58 p.m. UTC | #4 
Thanks! Please see response inline.

- Liming

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Friday, October 26, 2018 3:32 PM
> To: Liming Sun <lsun@mellanox.com>
> Cc: Olof Johansson <olof@lixom.net>; David Woods
> <dwoods@mellanox.com>; Robin Murphy <robin.murphy@arm.com>; arm-
> soc <arm@kernel.org>; DTML <devicetree@vger.kernel.org>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: [PATCH v4 2/4] arm64: Add Mellanox BlueField SoC config option
> 
> On Fri, Oct 26, 2018 at 9:18 PM Liming Sun <lsun@mellanox.com> wrote:
> > > -----Original Message-----
> > > From: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] On
> > > Behalf Of Arnd Bergmann
> > > Sent: Thursday, October 25, 2018 11:38 AM
> > > To: Liming Sun <lsun@mellanox.com>
> > > Cc: Olof Johansson <olof@lixom.net>; David Woods
> > > <dwoods@mellanox.com>; Robin Murphy <robin.murphy@arm.com>;
> arm-
> > > soc <arm@kernel.org>; devicetree@vger.kernel.org; linux-arm-
> > > kernel@lists.infradead.org
> > > Subject: Re: [PATCH v4 2/4] arm64: Add Mellanox BlueField SoC config
> option
> > >
> > > On 10/24/18, Liming Sun <lsun@mellanox.com> wrote:
> > > > This commit introduces config option for Mellanox BlueField SoC,
> > > > which can be used to build the SoC specific drivers, and enables
> > > > it by default in configs/defconfig.
> > > >
> > > > Reviewed-by: David Woods <dwoods@mellanox.com>
> > > > Signed-off-by: Liming Sun <lsun@mellanox.com>
> > > > ---
> > > >  arch/arm64/Kconfig.platforms | 6 ++++++
> > > >  arch/arm64/configs/defconfig | 1 +
> > > >  2 files changed, 7 insertions(+)
> > >
> > > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > I'm sorry for missing your series in the past. We should definitely merge
> > > the platform support soon. Do you also have device tree files for
> reference
> > > systems or even production hardware?
> >
> > We have obsoleted the device tree, and mainly support ACPI now
> > on Reference/Production HW. Below is the TMFIFO definition in the ACPI
> > DSDT table.
> >
> >     // RShim TMFIFO
> >     Device(RSH0) {
> >       Name(_HID, "MLNXBF01")
> >       Name(_UID, Zero)
> >       Name(_CCA, 1)
> >       Name(_CRS, ResourceTemplate() {
> >         Memory32Fixed(ReadWrite, 0x00800a20, 0x00000018)
> >         Memory32Fixed(ReadWrite, 0x00800a40, 0x00000018)
> >         Interrupt(ResourceConsumer, Edge, ActiveHigh, Exclusive)
> >           { BF1_RSH0_TM_HTT_LWM_INT,
> >             BF1_RSH0_TM_HTT_HWM_INT,
> >             BF1_RSH0_TM_TTH_LWM_INT,
> >             BF1_RSH0_TM_TTH_HWM_INT
> >           }
> >       })
> >     }
> >
> > The full ACPI implementation can be found in the 1.0 release:
> > http://www.mellanox.com/downloads/BlueField/BlueField-
> 1.0.0.10521/BlueField-1.0.0.10521.tar.xz
> > Inside this tarball, we can see the "src/edk2/" directory which has the edk2
> patch file including all the ACPI implementation.
> 
> It would be nice if you could still include the dts sources in the submission.
> Since this is not a classic server hardware, DT is probably more suitable
> here, and there are likely use cases that won't work with ACPI, so it's
> good to have a starting point for your users if they need to override
> the ACPI tables with a DT, or build systems with a simpler boot loader.

Sure, I'll keep this DT change for reference. A little explanation that
Mellanox BlueField SOC could be PCIe NIC or standalone device (server)  form which
can do PXE boot, CentOS installation even on the NIC, etc. The same software/driver 
works on both.  DT seems not working well for some requirement/features like 
NVDIMM (which requires ACPI DSM).  That's why we switched to ACPI though
DT support is preserved.

> 
>        Arnd
Arnd Bergmann Oct. 29, 2018, 3:26 p.m. UTC | #5 
On Mon, Oct 29, 2018 at 3:58 PM Liming Sun <lsun@mellanox.com> wrote:
> > It would be nice if you could still include the dts sources in the submission.
> > Since this is not a classic server hardware, DT is probably more suitable
> > here, and there are likely use cases that won't work with ACPI, so it's
> > good to have a starting point for your users if they need to override
> > the ACPI tables with a DT, or build systems with a simpler boot loader.
>
> Sure, I'll keep this DT change for reference. A little explanation that
> Mellanox BlueField SOC could be PCIe NIC or standalone device (server)  form which
> can do PXE boot, CentOS installation even on the NIC, etc. The same software/driver
> works on both.

Ok, good.

>  DT seems not working well for some requirement/features like
> NVDIMM (which requires ACPI DSM).  That's why we switched to ACPI though
> DT support is preserved.

This is probably something we need to look at separately, I'm sure we will want
to use NVDIMM with DT based systems in the future. Can you explain what
the DSM is used for here? Is this something that could be done in software
in the NVDIMM hardware specific driver?

       Arnd
Liming Sun Oct. 29, 2018, 4:09 p.m. UTC | #6 
Please see my response below.

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Monday, October 29, 2018 11:26 AM
> To: Liming Sun <lsun@mellanox.com>
> Cc: Olof Johansson <olof@lixom.net>; David Woods
> <dwoods@mellanox.com>; Robin Murphy <robin.murphy@arm.com>; arm-
> soc <arm@kernel.org>; DTML <devicetree@vger.kernel.org>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>
> Subject: Re: [PATCH v4 2/4] arm64: Add Mellanox BlueField SoC config option
> 
> On Mon, Oct 29, 2018 at 3:58 PM Liming Sun <lsun@mellanox.com> wrote:
> > > It would be nice if you could still include the dts sources in the submission.
> > > Since this is not a classic server hardware, DT is probably more suitable
> > > here, and there are likely use cases that won't work with ACPI, so it's
> > > good to have a starting point for your users if they need to override
> > > the ACPI tables with a DT, or build systems with a simpler boot loader.
> >
> > Sure, I'll keep this DT change for reference. A little explanation that
> > Mellanox BlueField SOC could be PCIe NIC or standalone device (server)
> form which
> > can do PXE boot, CentOS installation even on the NIC, etc. The same
> software/driver
> > works on both.
> 
> Ok, good.
> 
> >  DT seems not working well for some requirement/features like
> > NVDIMM (which requires ACPI DSM).  That's why we switched to ACPI
> though
> > DT support is preserved.
> 
> This is probably something we need to look at separately, I'm sure we will
> want
> to use NVDIMM with DT based systems in the future. Can you explain what
> the DSM is used for here? Is this something that could be done in software
> in the NVDIMM hardware specific driver?

The DSM is kind of running logic instead of configuration which is provided by 
system firmware. It's defined in the UEFI spec and supported by Linux. In the
NVDIMM case here, it's used to do Address Range Scrub (ARS), I2C access (such as
reading the DIMM SPD information), runtime health check, etc. 

DSM is kind of requirement by NVDIMM, such as
https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/-dsm-interface-for-byte-addressable-energy-backed-function-class--function-interface-1-

By following the ACPI DSM definitions, there is no extra drivers needed in 
Linux due to the existing ACPI framework.  Since it's 'standard' APIs in UEFI, 
it has potential to support other OS other than Linux.

Hardware specific driver might be able to do some of the functionality, or
even 'simulate' some of the ACPI implementation or APIs. I guess it might need 
a framework for it which I haven't thought a lot of details yet :)

> 
>        Arnd
diff mbox series

Patch

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac3..aeb67c2 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -110,6 +110,12 @@  config ARCH_MESON
 	help
 	  This enables support for the Amlogic S905 SoCs.
 
+config ARCH_MLNX_BLUEFIELD
+	bool "Mellanox BlueField SoC Family"
+	select SOC_MLNX
+	help
+	  This enables support for the Mellanox BlueField SoC.
+
 config ARCH_MVEBU
 	bool "Marvell EBU SoC Family"
 	select ARMADA_AP806_SYSCON
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f9a186f..508cb9d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -43,6 +43,7 @@  CONFIG_ARCH_LG1K=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MESON=y
+CONFIG_ARCH_MLNX_BLUEFIELD=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_ROCKCHIP=y