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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please see my response below.

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@xxxxxxxx]
> Sent: Monday, October 29, 2018 11:26 AM
> To: Liming Sun <lsun@xxxxxxxxxxxx>
> Cc: Olof Johansson <olof@xxxxxxxxx>; David Woods
> <dwoods@xxxxxxxxxxxx>; Robin Murphy <robin.murphy@xxxxxxx>; arm-
> soc <arm@xxxxxxxxxx>; DTML <devicetree@xxxxxxxxxxxxxxx>; Linux ARM
> <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxx> 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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux