ACPI support is added in the fsl-mc driver. Driver will parse
MC DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71 ++++++++++++++++++++++++++++-
include/linux/acpi_iort.h | 5 ++
7 files changed, 174 insertions(+), 20 deletions(-)
@@ -638,7 +639,7 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)return-EINVAL;error=fsl_mc_find_msi_domain(parent_dev,-&mc_msi_domain);+&mc_msi_domain,mc_dev);if(error<0){dev_warn(&mc_dev->dev,"WARNING: MC bus without interrupt support\n");
From: Marc Zyngier <maz@kernel.org> Date: 2020-01-28 10:58:34
On 2020-01-28 08:08, Makarand Pawagi wrote:
ACPI support is added in the fsl-mc driver. Driver will parse
MC DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
++++++++++++++++++++++++++++-
include/linux/acpi_iort.h | 5 ++
7 files changed, 174 insertions(+), 20 deletions(-)
A general comment when you do this kind of work:
Do not write a single patch that impacts at least three different
subsystems. As it is, it is unmergeable.
Now the real question is *WHY* we need this kind of monstruosity?
ACPI deals with PCI, not with exotic busses and whatnot. If you want
to be creative, DT is your space. ACPI is designed to be plain and
boring, and that's how we like it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2020-01-28 11:09:28
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted hunk
ACPI support is added in the fsl-mc driver. Driver will parse
MC DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71 ++++++++++++++++++++++++++++-
include/linux/acpi_iort.h | 5 ++
7 files changed, 174 insertions(+), 20 deletions(-)
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and related kernel code which goes totally against what ACPI is meant
for on ARM64 systems, so there is no upstream pathway for this code
I am afraid.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref]; Laurentiu
Tudor [off-list ref]; Ioana Ciornei [off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson [off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT) and
related kernel code which goes totally against what ACPI is meant for on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT layer is
That iort_get_device_domain() only deals with PCI bus (DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do that
if we do not add this function because there are no other suitable APIs exported
by IORT layer to do the job.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2020-01-31 11:06:21
On Fri, Jan 31, 2020 at 10:35:48AM +0000, Makarand Pawagi wrote:
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref]; Laurentiu
Tudor [off-list ref]; Ioana Ciornei [off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson [off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT) and
related kernel code which goes totally against what ACPI is meant for on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is
associated with the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be
possible to do that if we do not add this function because there are
no other suitable APIs exported by IORT layer to do the job.
And that's by design.
I don't know what the FSL bus is and I don't want to know, what
I am telling you is that the ACPI code in the mainline is sufficient
to support SBSA compliant HW and that's what we support with ACPI
on ARM64.
We won't hack the kernel (and ACPI tables) up to boot with ACPI on
non-compliant platforms, I don't know how I can be any clearer than
that.
All is needed to configure the (platform dev/PCI->IOMMU->ITS) chain is
in the ACPI/IORT specifications and again, that's by design, adding
DSDT objects and hacking the kernel to make it work "like DT" won't
cut it, you are solving the wrong problem here, boot this platform
with a device tree, it is a problem that has been solved a long time
ago and it is supported in the mainline kernel.
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Zyngier <maz@kernel.org> Date: 2020-01-31 11:06:56
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
You have decided to have exotic hardware, and sidestep all the
standardization
efforts. This is your right. But you can't have your cake and eat it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Jon Nettleton <hidden> Date: 2020-01-31 12:29:09
On Fri, Jan 31, 2020 at 1:02 PM Ard Biesheuvel
[off-list ref] wrote:
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
You beat me to it, but thanks for the clarification Ard. No where in
the SBSA spec that I have read does it state that only PCIe devices
are supported by the SMMU. It uses PCIe devices as an example, but
the SMMU section is very generic in term and only says "devices".
I feel the SBSA omission of SerDes best practices is an oversight in
the standard and something that probably needs to be revisited.
Forcing high speed networking interfaces to be hung off a bus just for
the sake of having a "standard" PCIe interface seems like a step
backward in this regard. I would much rather have the Spec include a
common standard that could be exposed in a consistent manner. But
this is a conversation for a different place.
I will work with NXP and find a better way to implement this.
-Jon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2020-01-31 12:48:53
On 2020-01-31 12:28 pm, Jon Nettleton wrote:
On Fri, Jan 31, 2020 at 1:02 PM Ard Biesheuvel
[off-list ref] wrote:
quoted
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
You beat me to it, but thanks for the clarification Ard. No where in
the SBSA spec that I have read does it state that only PCIe devices
are supported by the SMMU. It uses PCIe devices as an example, but
the SMMU section is very generic in term and only says "devices".
I feel the SBSA omission of SerDes best practices is an oversight in
the standard and something that probably needs to be revisited.
Forcing high speed networking interfaces to be hung off a bus just for
the sake of having a "standard" PCIe interface seems like a step
backward in this regard. I would much rather have the Spec include a
common standard that could be exposed in a consistent manner. But
this is a conversation for a different place.
Just to clarify further, it's not about serdes or high-speed networking
per se - describing a fixed-function network adapter as a named
component is entirely within scope. The issue is when the hardware is
merely a pool of accelerator components that can be dynamically
configured at runtime into something that looks like one or more
'virtual' network adapters - there is no standard interface for *that*
for SBSA to consider.
Robin.
I will work with NXP and find a better way to implement this.
-Jon
From: Jon Nettleton <hidden> Date: 2020-01-31 13:12:07
On Fri, Jan 31, 2020 at 1:48 PM Robin Murphy [off-list ref] wrote:
On 2020-01-31 12:28 pm, Jon Nettleton wrote:
quoted
On Fri, Jan 31, 2020 at 1:02 PM Ard Biesheuvel
[off-list ref] wrote:
quoted
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
You beat me to it, but thanks for the clarification Ard. No where in
the SBSA spec that I have read does it state that only PCIe devices
are supported by the SMMU. It uses PCIe devices as an example, but
the SMMU section is very generic in term and only says "devices".
I feel the SBSA omission of SerDes best practices is an oversight in
the standard and something that probably needs to be revisited.
Forcing high speed networking interfaces to be hung off a bus just for
the sake of having a "standard" PCIe interface seems like a step
backward in this regard. I would much rather have the Spec include a
common standard that could be exposed in a consistent manner. But
this is a conversation for a different place.
Just to clarify further, it's not about serdes or high-speed networking
per se - describing a fixed-function network adapter as a named
component is entirely within scope. The issue is when the hardware is
merely a pool of accelerator components that can be dynamically
configured at runtime into something that looks like one or more
'virtual' network adapters - there is no standard interface for *that*
for SBSA to consider.
Robin.
quoted
I will work with NXP and find a better way to implement this.
-Jon
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity. For instance if this were an accelerator block on a
PCIe card then we wouldn't be having this discussion, even if it did
run a firmware and have a third party driver that exposed virtual
network interfaces.
-Jon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, 31 Jan 2020 at 14:12, Jon Nettleton [off-list ref] wrote:
On Fri, Jan 31, 2020 at 1:48 PM Robin Murphy [off-list ref] wrote:
quoted
On 2020-01-31 12:28 pm, Jon Nettleton wrote:
quoted
On Fri, Jan 31, 2020 at 1:02 PM Ard Biesheuvel
[off-list ref] wrote:
quoted
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
You beat me to it, but thanks for the clarification Ard. No where in
the SBSA spec that I have read does it state that only PCIe devices
are supported by the SMMU. It uses PCIe devices as an example, but
the SMMU section is very generic in term and only says "devices".
I feel the SBSA omission of SerDes best practices is an oversight in
the standard and something that probably needs to be revisited.
Forcing high speed networking interfaces to be hung off a bus just for
the sake of having a "standard" PCIe interface seems like a step
backward in this regard. I would much rather have the Spec include a
common standard that could be exposed in a consistent manner. But
this is a conversation for a different place.
Just to clarify further, it's not about serdes or high-speed networking
per se - describing a fixed-function network adapter as a named
component is entirely within scope. The issue is when the hardware is
merely a pool of accelerator components that can be dynamically
configured at runtime into something that looks like one or more
'virtual' network adapters - there is no standard interface for *that*
for SBSA to consider.
Robin.
quoted
I will work with NXP and find a better way to implement this.
-Jon
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity. For instance if this were an accelerator block on a
PCIe card then we wouldn't be having this discussion, even if it did
run a firmware and have a third party driver that exposed virtual
network interfaces.
Again, on an ACPI system, it is the firmware's job to abstract away
from these platform details. Firmware can perform logical hotplug and
hot unplug of virtual devices, and hide the discovery and
initalization of those pluggable gadgets from the OS. If the
configuration changes, one virtual device appears and another one
disappears, and the firmware can signal such a change to the OS.
What is needed here is for people to really buy into the ACPI
paradigm, rather than treat it as MS flavored DT, where every little
soc detail is decribed to, and therefore managed by the OS. As we
know, there are substantial scalability issues around DT, which is why
ACPI aims to provide a higher level of abstraction, with more runtime
firmware to iron out the wrinkles.
In general, simply inventing ACPI _HIDs for every DT node that
describes a given platform, and adding ACPI probe support to the
existing drivers literally gives you the worst of both worlds, and in
this case [where we are getting into interrupt and DMA routing], it is
not even feasible to begin with.
So I'd suggest approaching this from the opposite direction: don't
look at the existing DT description and existing drivers, but look at
what ACPI supports today, and how the hardware can be made to look
like that through the use of firmware magic.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2020-01-31 13:39:22
On 2020-01-31 1:11 pm, Jon Nettleton wrote:
On Fri, Jan 31, 2020 at 1:48 PM Robin Murphy [off-list ref] wrote:
quoted
On 2020-01-31 12:28 pm, Jon Nettleton wrote:
quoted
On Fri, Jan 31, 2020 at 1:02 PM Ard Biesheuvel
[off-list ref] wrote:
quoted
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu
Tudor [off-list ref]; Ioana Ciornei
[off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref];
Pankaj Bansal [off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT
table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table by
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct device
*dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to a
+device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */ struct
+irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle, DOMAIN_BUS_FSL_MC_MSI);
+}
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://developer.arm.com/architectures/platform-design/server-systems
Deviating from those requires butchering ACPI specifications (ie IORT)
and
related kernel code which goes totally against what ACPI is meant for
on ARM64
systems, so there is no upstream pathway for this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is
That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is associated
with
the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not be possible to do
that
if we do not add this function because there are no other suitable APIs
exported
by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is
that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
You beat me to it, but thanks for the clarification Ard. No where in
the SBSA spec that I have read does it state that only PCIe devices
are supported by the SMMU. It uses PCIe devices as an example, but
the SMMU section is very generic in term and only says "devices".
I feel the SBSA omission of SerDes best practices is an oversight in
the standard and something that probably needs to be revisited.
Forcing high speed networking interfaces to be hung off a bus just for
the sake of having a "standard" PCIe interface seems like a step
backward in this regard. I would much rather have the Spec include a
common standard that could be exposed in a consistent manner. But
this is a conversation for a different place.
Just to clarify further, it's not about serdes or high-speed networking
per se - describing a fixed-function network adapter as a named
component is entirely within scope. The issue is when the hardware is
merely a pool of accelerator components that can be dynamically
configured at runtime into something that looks like one or more
'virtual' network adapters - there is no standard interface for *that*
for SBSA to consider.
Robin.
quoted
I will work with NXP and find a better way to implement this.
-Jon
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity.
Apologies - I was under the impression that SFP and friends were a
physical-layer thing and that a MAC in the SoC would still be fixed such
that its DMA and interrupt configuration could be statically described
regardless of what transceiver was plugged in (even if some
configurations might not use every interrupt/stream ID/etc.) If that
isn't the case I shall go and educate myself further.
For instance if this were an accelerator block on a
PCIe card then we wouldn't be having this discussion, even if it did
run a firmware and have a third party driver that exposed virtual
network interfaces.
Right, because in that case the interrupts and DMA have to travel
through the PCIe layer, and thus generic code only needs to worry about
things from the point of the PCI host bridge. That's rather the point of
having an industry-standard interface.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2020-01-31 14:29:38
quoted
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity.
Apologies - I was under the impression that SFP and friends were a
physical-layer thing and that a MAC in the SoC would still be fixed such
that its DMA and interrupt configuration could be statically described
regardless of what transceiver was plugged in (even if some configurations
might not use every interrupt/stream ID/etc.) If that isn't the case I shall
go and educate myself further.
Hi Robin
It gets interesting with QSFP cages. The Q is quad, there are 4 SERDES
lanes. You can use them for 1x 40G link, or you can split them into 4x
10G links. So you either need one MAC or 4 MACs connecting to the
cage, and this can change on the fly when a modules is ejected and
replaced with another module. There are only one set of control pins
for i2c, loss of signal, TX disable, module inserted. So where the
interrupt/stream ID/etc are mapped needs some flexibility.
There is also to some degree a conflict with hiding all this inside
firmware. This is complex stuff. It is much better to have one core
implementing in Linux plus some per hardware driver support, than
having X firmware blobs, generally closed source, each with there own
bugs which nobody can fix.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2020-01-31 14:47:47
On Fri, Jan 31, 2020 at 03:29:06PM +0100, Andrew Lunn wrote:
quoted
quoted
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity.
Apologies - I was under the impression that SFP and friends were a
physical-layer thing and that a MAC in the SoC would still be fixed such
that its DMA and interrupt configuration could be statically described
regardless of what transceiver was plugged in (even if some configurations
might not use every interrupt/stream ID/etc.) If that isn't the case I shall
go and educate myself further.
It gets interesting with QSFP cages. The Q is quad, there are 4 SERDES
lanes. You can use them for 1x 40G link, or you can split them into 4x
10G links. So you either need one MAC or 4 MACs connecting to the
cage, and this can change on the fly when a modules is ejected and
replaced with another module. There are only one set of control pins
for i2c, loss of signal, TX disable, module inserted. So where the
interrupt/stream ID/etc are mapped needs some flexibility.
There is also to some degree a conflict with hiding all this inside
firmware. This is complex stuff. It is much better to have one core
implementing in Linux plus some per hardware driver support, than
having X firmware blobs, generally closed source, each with there own
bugs which nobody can fix.
Devicetree to the rescue!
Entertaining the use of ACPI without any firmware abstraction for this
hardware really feels like a square peg / round hole situation, so I'm
assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who
is it and can you tell them to bog off?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2020-01-31 15:09:51
Devicetree to the rescue!
Yes, exactly. We have good, standardised descriptions for most of this
in device tree. And phylink can handle SFP and SFP+. Nobody has worked
on QSFP yet, since phylink has mostly been pushed by the embedded
world and 40G is not yet popular in the embedded world.
Entertaining the use of ACPI without any firmware abstraction for this
hardware really feels like a square peg / round hole situation, so I'm
assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who
is it and can you tell them to bog off?
The issues here is that SFPs are appearing in more and more server
systems, replacing plain old copper Ethernet. If the boxes use off the
shelf Mellanox or Intel PCIe cards, it is not an issue. But silicon
vendors are integrating this into the SoC in the ARM way of doing
things, memory mapped, spread over a number of controllers, not a
single PCIe device.
Maybe we need hybrid systems. Plain, old, simple, boring things like
CPUs, serial ports, SATA, PCIe busses are described in ACPI. Complex
interesting things are in DT. The hard thing is the interface between
the two. DT having a phandle to an ACPI object, e.g a GPIO, interrupt
or an i2c bus.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Jon Nettleton <hidden> Date: 2020-01-31 15:15:34
On Fri, Jan 31, 2020 at 4:09 PM Andrew Lunn [off-list ref] wrote:
quoted
Devicetree to the rescue!
Yes, exactly. We have good, standardised descriptions for most of this
in device tree. And phylink can handle SFP and SFP+. Nobody has worked
on QSFP yet, since phylink has mostly been pushed by the embedded
world and 40G is not yet popular in the embedded world.
quoted
Entertaining the use of ACPI without any firmware abstraction for this
hardware really feels like a square peg / round hole situation, so I'm
assuming somebody's telling you that you need it "FOAR ENTAPRYZE". Who
is it and can you tell them to bog off?
The issues here is that SFPs are appearing in more and more server
systems, replacing plain old copper Ethernet. If the boxes use off the
shelf Mellanox or Intel PCIe cards, it is not an issue. But silicon
vendors are integrating this into the SoC in the ARM way of doing
things, memory mapped, spread over a number of controllers, not a
single PCIe device.
Maybe we need hybrid systems. Plain, old, simple, boring things like
CPUs, serial ports, SATA, PCIe busses are described in ACPI. Complex
interesting things are in DT. The hard thing is the interface between
the two. DT having a phandle to an ACPI object, e.g a GPIO, interrupt
or an i2c bus.
Andrew
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2020-01-31 15:15:38
On Fri, Jan 31, 2020 at 03:29:06PM +0100, Andrew Lunn wrote:
quoted
quoted
But by design SFP, SFP+, and QSFP cages are not fixed function network
adapters. They are physical and logical devices that can adapt to
what is plugged into them. How the devices are exposed should be
irrelevant to this conversation it is about the underlying
connectivity.
Apologies - I was under the impression that SFP and friends were a
physical-layer thing and that a MAC in the SoC would still be fixed such
that its DMA and interrupt configuration could be statically described
regardless of what transceiver was plugged in (even if some configurations
might not use every interrupt/stream ID/etc.) If that isn't the case I shall
go and educate myself further.
Hi Robin
It gets interesting with QSFP cages. The Q is quad, there are 4 SERDES
lanes. You can use them for 1x 40G link, or you can split them into 4x
10G links. So you either need one MAC or 4 MACs connecting to the
cage, and this can change on the fly when a modules is ejected and
replaced with another module.
I think it's even more complicated than that. If you have a QSFP+
fiber module, that can be connected to four fibers which can either
go to another QSFP+ module, or four separate SFP+ modules.
That means it's a manual configuration decision whether to operate
the QSFP+ module as a single 40G link, or as four separate 10G links.
There are only one set of control pins
for i2c, loss of signal, TX disable, module inserted. So where the
interrupt/stream ID/etc are mapped needs some flexibility.
QSFP changes the way the modules are controlled; gone are many of the
hardware signals, replaced by registers in the I2C space. The
remaining hardware signals are:
ModSelL module select (to enable the I2C bus)
ResetL module reset
SCL/SDA I2C bus
ModPrsL module present
IntL interrupt (but not too useful from what I can see!)
LPMode low power mode (can be overriden via the I2C bus)
There is also to some degree a conflict with hiding all this inside
firmware. This is complex stuff. It is much better to have one core
implementing in Linux plus some per hardware driver support, than
having X firmware blobs, generally closed source, each with there own
bugs which nobody can fix.
QSFP and SFP support is not really part of the DPAA2 firmware.
I have some prototype implementation for driving the QSFP+ cage, but
I haven't yet worked out how to sensible deal with the "is it 4x 10G
or 1x 40G" issue you mention above, and how to interface the QSFP+
driver sensibly with one or four network drivers.
I've been concentrating more on the SFP/SFP+ problem on the Honeycomb
board which is what most people will have, working out how to sensibly
drive the hardware so that our existing SFP support in the kernel can
work sensibly. In the last couple of days, I've managed to get
something together which works, switching between 1000base-X and SGMII
on this hardware, using some of the patches I've already pointed to
over the last few weeks. This hardware falls into the "split PCS and
MAC" problem space, so it's relevent to many people - and it's
important that we don't rush into a solution that works for one
implementation and not everyone. This is why I haven't responded to
Jose's proposal - I'm still working out what is required for others,
but what I can say is that it isn't what Jose has proposed. I had
asked Jose to hold off, but he's understandably eager to solve the
problem in front of him at the expense of everyone else.
What I've found is that any attempt to split the current
"phylink_mac_ops" interface between the PCS and MAC blocks results, as
I suspected, in mvneta and mvpp2 suffering very badly; the hardware
does not split along those functional blocks at all well.
My current state of play for this is in my "cex7" branch, pushed out
earlier today. It's a bit hacky right now, and there's various issues
that need to be solved, but it is functional with the right board boot
configuration (basically the DPC file, which is one of the configs for
the MC firmware.)
I'm planning to look at what's required for the faster speeds; there's
other PCS PHYs on this platform that support the other speeds (10G, 25G,
40G, 100G) accessed via Clause 45 cycles.
As for the DSA issue you've raised with DSA links, I don't see any
obvious solution for that - the whole "if no fixed-link is specified,
default to the highest speed" is a real problem; the conversion of DSA
to phylink for the CPU and DSA ports did not take account of that.
phylink has _zero_ information in that case to know how the link should
be configured - there is no PHY, there is no fixed-link specification,
there is absolutely nothing. So it's no surprise when phylink tries to
configure speed=0 duplex=half pause=off on these interfaces when they're
brought up. I notice that this work was contributed by NXP - and in my
mind illustrates that they did not think about what they were doing
there either. They certainly never ran phylink with debugging on and
considered whether the phylink_mac_config() calls contained sensible
information. Did they even have all the information necessary to work
out what was required - I doubt it very much. Did they realise that the
fixed-link specification was optional, did they realise that there
could be a PHY on these links, and did they consider what the behaviour
would be in those cases? And now we have something of a headache
trying to work out how to solve this - one thing is certain, whatever
the fix is, it isn't going to be nice to be backported to stable trees.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2020-01-31 15:40:01
On Fri, Jan 31, 2020 at 04:09:29PM +0100, Andrew Lunn wrote:
quoted
Devicetree to the rescue!
Yes, exactly. We have good, standardised descriptions for most of this
in device tree. And phylink can handle SFP and SFP+. Nobody has worked
on QSFP yet, since phylink has mostly been pushed by the embedded
world and 40G is not yet popular in the embedded world.
That's incorrect (if you read my previous reply.) It shouldn't come
as any surprise that I have some experimental QSFP code.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Jakub Kicinski <kuba@kernel.org> Date: 2020-01-31 15:40:54
On Fri, 31 Jan 2020 15:15:00 +0000, Russell King - ARM Linux admin
wrote:
I have some prototype implementation for driving the QSFP+ cage, but
I haven't yet worked out how to sensible deal with the "is it 4x 10G
or 1x 40G" issue you mention above, and how to interface the QSFP+
driver sensibly with one or four network drivers.
I'm pretty sure you know this but just FWIW - vendors who do it in FW
write the current config down in NVM so it doesn't get affected by
reboots and use devlink port splitting to change it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
That is interesting, but you need to be careful with it.
Top of rack switches are very different beasts to the majority of
switches supported by Linux, which are SOHO. TOR switches have a lot
of firmware running on them doing most of the work. A typical SOHO
switch with a Linux kernel driver has very little firmware, Linux
really is driving it, not just asking it to do things.
Also, TOR switches typically have a binary blob running in userspace,
meaning different information is probably required compared to kernel
driver.
There may be useful information here, but please take it with a big
pinch of salt. And make sure you have the appropriate networking
people involved in any specification work you do.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2020-02-01 11:49:53
On Fri, Jan 31, 2020 at 07:40:50AM -0800, Jakub Kicinski wrote:
On Fri, 31 Jan 2020 15:15:00 +0000, Russell King - ARM Linux admin
wrote:
quoted
I have some prototype implementation for driving the QSFP+ cage, but
I haven't yet worked out how to sensible deal with the "is it 4x 10G
or 1x 40G" issue you mention above, and how to interface the QSFP+
driver sensibly with one or four network drivers.
I'm pretty sure you know this but just FWIW - vendors who do it in FW
write the current config down in NVM so it doesn't get affected by
reboots and use devlink port splitting to change it.
+Jiri
I wasn't aware of devlink port splitting, so thanks for that. However,
it could do with some better documentation - there's nothing on it
afaics in the Documentation subdirectory, and "man devlink-port"
doesn't give much away either:
devlink port split - split devlink port into more
DEV/PORT_INDEX - specifies the devlink port to operate on.
count COUNT
number of ports to split to.
It's the "into more" that's not clear - presumably more ports, and
presumably each port is a network device, but this isn't explained.
I think what this is trying to say is that, if we have a QSFP+ cage
with 4 serdes lines running at 10G, and they are initially treated as
a single 40G ethernet:
devlink port split device/1 count 4
will then give us four 10G network devices, and:
devlink port unsplit device/1
will recombine them back to a single 40G network device.
What if someone decides to do:
devlink port split device/1 count 2
what do we end up with? Presumably two network devices running with
two serdes lanes each (if supported by the hardware). At that point
can they then do:
devlink port split device/2 count 2
and end up with one network device with two 10G serdes lanes, and two
network devices each with one 10G serdes lane, or can port splitting
only be used on the "master" device/port ?
Unfortunately, I don't think I have any network devices that support
this so I can't experiment to find out how this should work; yes, I
have a Mellanox card, but it supports a single 10G SFP+, and therefore
does not support port splitting.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Jakub Kicinski <kuba@kernel.org> Date: 2020-02-01 17:36:24
On Sat, 1 Feb 2020 11:49:19 +0000, Russell King - ARM Linux admin wrote:
What if someone decides to do:
devlink port split device/1 count 2
what do we end up with? Presumably two network devices running with
two serdes lanes each (if supported by the hardware). At that point
can they then do:
devlink port split device/2 count 2
and end up with one network device with two 10G serdes lanes, and two
network devices each with one 10G serdes lane,
I think all your guesses are correct, it's a pretty straight forward
API, but it's also pretty thin, and some of the logic is in FW, so
there isn't much in a way of a standard on how things should behave :S
or can port splitting only be used on the "master" device/port ?
I think both mlxsw and the NFP rejects re-split/further splitting.
Ports have to be unsplit first. So there is only one device for
splitting, and unsplitting can be done on any of the sub-devices.
Unfortunately, I don't think I have any network devices that support
this so I can't experiment to find out how this should work; yes, I
have a Mellanox card, but it supports a single 10G SFP+, and therefore
does not support port splitting.
I think you'd need a mlxsw or an nfp to play with this.
Maybe Jiri can clarify further :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: Ard Biesheuvel <redacted>
Sent: Friday, January 31, 2020 5:32 PM
To: Marc Zyngier <maz@kernel.org>
Cc: Makarand Pawagi <redacted>; Calvin Johnson
[off-list ref]; stuyoder@gmail.com; nleeder@codeaurora.org;
Ioana Ciornei [off-list ref]; Cristi Sovaiala
[off-list ref]; Hanjun Guo [off-list ref]; Will
Deacon [off-list ref]; Lorenzo Pieralisi [off-list ref];
Pankaj Bansal [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List [off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref]; Paul
Yang [off-list ref]; [off-list ref]
[off-list ref]; Rafael J. Wysocki [off-list ref]; Linux Kernel
Mailing List [off-list ref]; Shameerali Kolothum Thodi
[off-list ref]; Sudeep Holla
[off-list ref]; Robin Murphy [off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-arm- kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk; jon@solid-run.com; Cristi Sovaiala
[off-list ref]; Laurentiu Tudor
[off-list ref]; Ioana Ciornei [off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref]; Pankaj Bansal [off-list ref];
guohanjun@huawei.com; sudeep.holla@arm.com; rjw@rjwysocki.net;
lenb@kernel.org; stuyoder@gmail.com; tglx@linutronix.de;
jason@lakedaemon.net; maz@kernel.org;
shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC
DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct
device *dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to
+a device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */
+struct irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle,
+DOMAIN_BUS_FSL_MC_MSI); }
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
eveloper.arm.com%2Farchitectures%2Fplatform-design%2Fserver-systems
50769265&sdata=C7nCty8%2BVeuq6VhcEUXCwiAinN01rCfe12NRVnXJCIY%
3D
quoted
quoted
quoted
&reserved=0
Deviating from those requires butchering ACPI specifications (ie
IORT) and related kernel code which goes totally against what ACPI
is meant for on ARM64 systems, so there is no upstream pathway for
this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is
associated with the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not
be possible to do that if we do not add this function because there
are no other suitable APIs exported by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
I am replying to old message in this conversation, because the discussion got sidetracked from IORT
table to SFP/QSFP/devlink stuff from this point onwards, which is not related to IORT.
I will only focus on representing the MC device in IORT and using the same in linux.
As Ard said:
"IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer."
We can represent MC bus as named component in IORT table and use platform MSIs.
The only caveat is that with current implementation of platform MSIs, the Input id of a device is not considered.
https://elixir.bootlin.com/linux/latest/source/drivers/irqchip/irq-gic-v3-its-platform-msi.c#L50https://elixir.bootlin.com/linux/latest/source/drivers/acpi/arm64/iort.c#L464
While, IORT spec doesn't specify any such limitation.
we can easily update iort.c to remove this limitation.
But, I am not sure how the input id would be passed from platform MSI GIC layer to IORT.
Most obviously, the input id should be supplied by dev itself.
Any thoughts?
If we go by this path, I think we can remove special handling for fsl-mc for of* cases altogether.
https://elixir.bootlin.com/linux/latest/source/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
Regards,
Pankaj Bansal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2020-02-14 16:21:26
On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
[...]
quoted
Why should the device know about its own ID? That's a bus/interconnect thing.
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still expected to be passed to parse IORT table.
Named components use an array of single mappings (as in entries with
single mapping flag set) - Input ID is irrelevant.
Not sure what your named component is though and what you want to do
with it, the fact that IORT allows mapping for named components do
not necessarily mean that it can describe what your system really is,
on that you need to elaborate for us to be able to help.
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2020-02-14 16:30:00
On 14/02/2020 3:58 pm, Pankaj Bansal wrote:
[...]
quoted
I don't understand what you mean. Platform MSI using IORT uses the DevID of
end-points. How could the ITS could work without specifying a DevID?
See for example how the SMMUv3 driver uses platform MSI.
DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ?
No, from the IORT perspective, the input for the ID mappings belonging
to a root complex is the PCI requester ID. The (ITS) DevID is the
ultimate *output* of a root complex mapping.
Whilst you can indeed represent the MC as a black-box Named Component
with an ID mapping range not using the "single mapping" flag, that means
your input IDs come from some device-specific domain beyond the scope of
IORT. That's why you can't easily get away from your special bus
integration code.
quoted
quoted
While, IORT spec doesn't specify any such limitation.
we can easily update iort.c to remove this limitation.
But, I am not sure how the input id would be passed from platform MSI
GIC layer to IORT.
Most obviously, the input id should be supplied by dev itself.
Why should the device know about its own ID? That's a bus/interconnect thing.
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still expected to be passed to parse IORT table.
...except for single mappings, where the input ID is ignored and the
output ID is the "source", which is exactly what iort_node_get_id()
deals with for devices represented in IORT. With what you're talking
about, "the device" is *not* represented in IORT, but is something
beyond the MC 'bridge'. Now it probably is technically possible to
handle that somehow, but it's definitely not something that the existing
code was ever designed to anticipate.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Friday, February 14, 2020 9:50 PM
To: Pankaj Bansal <redacted>
Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
[off-list ref]; Makarand Pawagi [off-list ref];
Calvin Johnson [off-list ref]; stuyoder@gmail.com;
nleeder@codeaurora.org; Ioana Ciornei [off-list ref]; Cristi
Sovaiala [off-list ref]; Hanjun Guo [off-list ref];
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List [off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref]; Paul
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List [off-list ref];
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
[...]
quoted
quoted
Why should the device know about its own ID? That's a bus/interconnect
thing.
quoted
quoted
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still
expected to be passed to parse IORT table.
Named components use an array of single mappings (as in entries with single
mapping flag set) - Input ID is irrelevant.
Not sure what your named component is though and what you want to do with
it, the fact that IORT allows mapping for named components do not necessarily
mean that it can describe what your system really is, on that you need to
elaborate for us to be able to help.
Details about MC bus can be read from here:
https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
From: Lorenzo Pieralisi <hidden> Date: 2020-02-14 17:50:03
On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote:
[...]
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Friday, February 14, 2020 9:50 PM
To: Pankaj Bansal <redacted>
Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
[off-list ref]; Makarand Pawagi [off-list ref];
Calvin Johnson [off-list ref]; stuyoder@gmail.com;
nleeder@codeaurora.org; Ioana Ciornei [off-list ref]; Cristi
Sovaiala [off-list ref]; Hanjun Guo [off-list ref];
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List [off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref]; Paul
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List [off-list ref];
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Side note: would you mind removing the email headers (as above) in your
replies please ?
quoted
On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
[...]
quoted
quoted
Why should the device know about its own ID? That's a bus/interconnect
thing.
quoted
quoted
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still
expected to be passed to parse IORT table.
Named components use an array of single mappings (as in entries with single
mapping flag set) - Input ID is irrelevant.
Not sure what your named component is though and what you want to do with
it, the fact that IORT allows mapping for named components do not necessarily
mean that it can describe what your system really is, on that you need to
elaborate for us to be able to help.
Details about MC bus can be read from here:
https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
So are you asking me if that's OK ? Or there is something you can't
describe with IORT ?
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
I *think* you have a specific API to allocate MSIs for MC devices:
fsl_mc_msi_domain_alloc_irqs()
which hook into the IRQ domain created in the file above that handles
the cascading to an ITS domain, correct ?
Thanks,
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-----Original Message-----
From: Marc Zyngier <maz@kernel.org>
Sent: Friday, February 14, 2020 9:24 PM
To: Pankaj Bansal <redacted>
Cc: Ard Biesheuvel <redacted>; Lorenzo Pieralisi
[off-list ref]; Makarand Pawagi [off-list ref];
Calvin Johnson [off-list ref]; stuyoder@gmail.com;
nleeder@codeaurora.org; Ioana Ciornei [off-list ref]; Cristi
Sovaiala [off-list ref]; Hanjun Guo [off-list ref];
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List [off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref]; Paul
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List [off-list ref];
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
On 2020-02-14 15:05, Pankaj Bansal wrote:
quoted
quoted
-----Original Message-----
From: Ard Biesheuvel <redacted>
Sent: Friday, January 31, 2020 5:32 PM
To: Marc Zyngier <maz@kernel.org>
Cc: Makarand Pawagi <redacted>; Calvin Johnson
[off-list ref]; stuyoder@gmail.com; nleeder@codeaurora.org;
Ioana Ciornei [off-list ref]; Cristi Sovaiala
[off-list ref]; Hanjun Guo [off-list ref]; Will
Deacon [off-list ref]; Lorenzo Pieralisi
[off-list ref]; Pankaj Bansal [off-list ref];
jon@solid-run.com; Russell King [off-list ref]; ACPI Devel
Maling List [off-list ref]; Len Brown
[off-list ref]; Jason Cooper [off-list ref]; Andy Wang
[off-list ref]; Varun Sethi [off-list ref]; Thomas Gleixner
[off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor
[off-list ref]; Paul Yang [off-list ref];
[off-list ref] [off-list ref]; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List
[off-list ref]; Shameerali Kolothum Thodi
[off-list ref]; Sudeep Holla
[off-list ref]; Robin Murphy [off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for
fsl-mc
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-arm- kernel@lists.infradead.org;
linux-acpi@vger.kernel.org; linux@armlinux.org.uk;
jon@solid-run.com; Cristi Sovaiala [off-list ref];
Laurentiu Tudor [off-list ref]; Ioana Ciornei
[off-list ref]; Varun Sethi [off-list ref]; Calvin
Johnson [off-list ref]; Pankaj Bansal
[off-list ref]; guohanjun@huawei.com;
sudeep.holla@arm.com; rjw@rjwysocki.net; lenb@kernel.org;
stuyoder@gmail.com; tglx@linutronix.de; jason@lakedaemon.net;
maz@kernel.org; shameerali.kolothum.thodi@huawei.com;
will@kernel.org; robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for
fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse
MC DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT
table by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
NAK
I am not willing to take platform specific code in the generic
IORT layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
2Fd
eveloper.arm.com%2Farchitectures%2Fplatform-design%2Fserver-syst
ems
&reserved=0
Deviating from those requires butchering ACPI specifications (ie
IORT) and related kernel code which goes totally against what
ACPI is meant for on ARM64 systems, so there is no upstream
pathway for this code I am afraid.
Reason of adding this platform specific function in the generic
IORT layer is That iort_get_device_domain() only deals with PCI
bus (DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is
associated with the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will
not be possible to do that if we do not add this function because
there are no other suitable APIs exported by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself
are saying is that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this
advantage, and ACPI gives you no benefit over DT at all.
I am replying to old message in this conversation, because the
discussion got sidetracked from IORT table to SFP/QSFP/devlink stuff
from this point onwards, which is not related to IORT.
I will only focus on representing the MC device in IORT and using the
same in linux.
As Ard said:
"IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer."
We can represent MC bus as named component in IORT table and use
platform MSIs.
The only caveat is that with current implementation of platform MSIs,
the Input id of a device is not considered.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
ir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Firqchip%2Firq-gic
-v3-its-platform-
I don't understand what you mean. Platform MSI using IORT uses the DevID of
end-points. How could the ITS could work without specifying a DevID?
See for example how the SMMUv3 driver uses platform MSI.
DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ?
quoted
While, IORT spec doesn't specify any such limitation.
we can easily update iort.c to remove this limitation.
But, I am not sure how the input id would be passed from platform MSI
GIC layer to IORT.
Most obviously, the input id should be supplied by dev itself.
Why should the device know about its own ID? That's a bus/interconnect thing.
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still expected to be passed to parse IORT table.
quoted
Any thoughts?
I think that in this thread, we have been fairly explicit about what our train of
though was.
M.
--
Jazz is not dead. It just smells funny...
From: Marc Zyngier <maz@kernel.org> Date: 2020-02-14 18:08:04
On 2020-02-14 15:05, Pankaj Bansal wrote:
quoted
-----Original Message-----
From: Ard Biesheuvel <redacted>
Sent: Friday, January 31, 2020 5:32 PM
To: Marc Zyngier <maz@kernel.org>
Cc: Makarand Pawagi <redacted>; Calvin Johnson
[off-list ref]; stuyoder@gmail.com; nleeder@codeaurora.org;
Ioana Ciornei [off-list ref]; Cristi Sovaiala
[off-list ref]; Hanjun Guo [off-list ref]; Will
Deacon [off-list ref]; Lorenzo Pieralisi
[off-list ref];
Pankaj Bansal [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List
[off-list ref];
Len Brown [off-list ref]; Jason Cooper [off-list ref]; Andy
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor
[off-list ref]; Paul
Yang [off-list ref]; [off-list ref]
[off-list ref]; Rafael J. Wysocki [off-list ref]; Linux
Kernel
Mailing List [off-list ref]; Shameerali Kolothum Thodi
[off-list ref]; Sudeep Holla
[off-list ref]; Robin Murphy [off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for
fsl-mc
On Fri, 31 Jan 2020 at 12:06, Marc Zyngier [off-list ref] wrote:
quoted
On 2020-01-31 10:35, Makarand Pawagi wrote:
quoted
quoted
-----Original Message-----
From: Lorenzo Pieralisi <redacted>
Sent: Tuesday, January 28, 2020 4:39 PM
To: Makarand Pawagi <redacted>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-arm- kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
linux@armlinux.org.uk; jon@solid-run.com; Cristi Sovaiala
[off-list ref]; Laurentiu Tudor
[off-list ref]; Ioana Ciornei [off-list ref];
Varun Sethi [off-list ref]; Calvin Johnson
[off-list ref]; Pankaj Bansal [off-list ref];
guohanjun@huawei.com; sudeep.holla@arm.com; rjw@rjwysocki.net;
lenb@kernel.org; stuyoder@gmail.com; tglx@linutronix.de;
jason@lakedaemon.net; maz@kernel.org;
shameerali.kolothum.thodi@huawei.com; will@kernel.org;
robin.murphy@arm.com; nleeder@codeaurora.org
Subject: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Caution: EXT Email
On Tue, Jan 28, 2020 at 01:38:45PM +0530, Makarand Pawagi wrote:
quoted
ACPI support is added in the fsl-mc driver. Driver will parse MC
DSDT table to extract memory and other resorces.
Interrupt (GIC ITS) information will be extracted from MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table will be parsed to configure DMA.
Signed-off-by: Makarand Pawagi <redacted>
---
drivers/acpi/arm64/iort.c | 53 +++++++++++++++++++++
drivers/bus/fsl-mc/dprc-driver.c | 3 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 48 +++++++++++++------
drivers/bus/fsl-mc/fsl-mc-msi.c | 10 +++-
drivers/bus/fsl-mc/fsl-mc-private.h | 4 +-
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 71
@@ -622,6 +623,29 @@ static int iort_dev_find_its_id(struct
device *dev, u32 req_id, }
/**
+ * iort_get_fsl_mc_device_domain() - Find MSI domain related to
+a device
+ * @dev: The device.
+ * @mc_icid: ICID for the fsl_mc device.
+ *
+ * Returns: the MSI domain for this device, NULL otherwise */
+struct irq_domain *iort_get_fsl_mc_device_domain(struct device *dev,
+ u32 mc_icid) {
+ struct fwnode_handle *handle;
+ int its_id;
+
+ if (iort_dev_find_its_id(dev, mc_icid, 0, &its_id))
+ return NULL;
+
+ handle = iort_find_domain_token(its_id);
+ if (!handle)
+ return NULL;
+
+ return irq_find_matching_fwnode(handle,
+DOMAIN_BUS_FSL_MC_MSI); }
NAK
I am not willing to take platform specific code in the generic IORT
layer.
ACPI on ARM64 works on platforms that comply with SBSA/SBBR
guidelines:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd
eveloper.arm.com%2Farchitectures%2Fplatform-design%2Fserver-systems
50769265&sdata=C7nCty8%2BVeuq6VhcEUXCwiAinN01rCfe12NRVnXJCIY%
3D
quoted
quoted
quoted
&reserved=0
Deviating from those requires butchering ACPI specifications (ie
IORT) and related kernel code which goes totally against what ACPI
is meant for on ARM64 systems, so there is no upstream pathway for
this code I am afraid.
Reason of adding this platform specific function in the generic IORT
layer is That iort_get_device_domain() only deals with PCI bus
(DOMAIN_BUS_PCI_MSI).
fsl-mc objects when probed, need to find irq_domain which is
associated with the fsl-mc bus (DOMAIN_BUS_FSL_MC_MSI). It will not
be possible to do that if we do not add this function because there
are no other suitable APIs exported by IORT layer to do the job.
I think we all understood the patch. What both Lorenzo and myself are
saying is that we do not want non-PCI support in IORT.
IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer.
So it may be possible to hide your exotic bus from the OS entirely,
and make the firmware instantiate a DSDT with device objects and
associated IORT nodes that describe whatever lives on that bus as
named components.
That way, you will not have to change the OS at all, so your hardware
will not only be supported in linux v5.7+, it will also be supported
by OSes that commercial distro vendors are shipping today. *That* is
the whole point of using ACPI.
If you are going to bother and modify the OS, you lose this advantage,
and ACPI gives you no benefit over DT at all.
I am replying to old message in this conversation, because the
discussion got sidetracked from IORT
table to SFP/QSFP/devlink stuff from this point onwards, which is not
related to IORT.
I will only focus on representing the MC device in IORT and using the
same in linux.
As Ard said:
"IORT supports platform devices (aka named components) as well, and
there is some support for platform MSIs in the GIC layer."
We can represent MC bus as named component in IORT table and use
platform MSIs.
The only caveat is that with current implementation of platform MSIs,
the Input id of a device is not considered.
https://elixir.bootlin.com/linux/latest/source/drivers/irqchip/irq-gic-v3-its-platform-msi.c#L50https://elixir.bootlin.com/linux/latest/source/drivers/acpi/arm64/iort.c#L464
I don't understand what you mean. Platform MSI using IORT uses the DevID
of end-points. How could the ITS could work without specifying a DevID?
See for example how the SMMUv3 driver uses platform MSI.
While, IORT spec doesn't specify any such limitation.
we can easily update iort.c to remove this limitation.
But, I am not sure how the input id would be passed from platform MSI
GIC layer to IORT.
Most obviously, the input id should be supplied by dev itself.
Why should the device know about its own ID? That's a bus/interconnect
thing. And nothing should be passed *to* IORT. IORT is the source.
Any thoughts?
I think that in this thread, we have been fairly explicit about what our
train of though was.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List <linux-
acpi@vger.kernel.org>;
quoted
quoted
Len Brown [off-list ref]; Jason Cooper [off-list ref];
Andy
quoted
quoted
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref];
Paul
quoted
quoted
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>;
quoted
quoted
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Side note: would you mind removing the email headers (as above) in your
replies please ?
quoted
quoted
On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
[...]
quoted
quoted
Why should the device know about its own ID? That's a bus/interconnect
thing.
quoted
quoted
And nothing should be passed *to* IORT. IORT is the source.
IORT is translation between Input IDs <-> Output IDs. The Input ID is still
expected to be passed to parse IORT table.
Named components use an array of single mappings (as in entries with single
mapping flag set) - Input ID is irrelevant.
Not sure what your named component is though and what you want to do
with
quoted
quoted
it, the fact that IORT allows mapping for named components do not
necessarily
quoted
quoted
mean that it can describe what your system really is, on that you need to
elaborate for us to be able to help.
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can
dynamically create/destroy these devices.
quoted
Now, we want to represent this BUS (not individual devices connected to bus)
in IORT table.
quoted
The only possible way right now we see is that we describe it as Named
components having a pool of ID mappings.
quoted
As and when devices are created and attached to bus, we sift through this pool
to correctly determine the output ID for the device.
quoted
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
So are you asking me if that's OK ? Or there is something you can't
describe with IORT ?
I am asking if that would be acceptable?
i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag)
and then we use the Platform MSI framework for all children devices of MC bus.
Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer.
And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id.
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
Yes. It's being done for all DT systems having ITS node.
The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c
I *think* you have a specific API to allocate MSIs for MC devices:
fsl_mc_msi_domain_alloc_irqs()
which hook into the IRQ domain created in the file above that handles
the cascading to an ITS domain, correct ?
Will Deacon [off-list ref]; jon@solid-run.com; Russell King
[off-list ref]; ACPI Devel Maling List <linux-
acpi@vger.kernel.org>;
quoted
quoted
Len Brown [off-list ref]; Jason Cooper [off-list ref];
Andy
quoted
quoted
Wang [off-list ref]; Varun Sethi [off-list ref]; Thomas
Gleixner [off-list ref]; linux-arm-kernel <linux-arm-
kernel@lists.infradead.org>; Laurentiu Tudor [off-list ref];
Paul
quoted
quoted
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>;
quoted
quoted
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Side note: would you mind removing the email headers (as above) in your
replies please ?
Read the question above please.
[...]
quoted
quoted
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can
dynamically create/destroy these devices.
quoted
Now, we want to represent this BUS (not individual devices connected to bus)
in IORT table.
quoted
The only possible way right now we see is that we describe it as Named
components having a pool of ID mappings.
quoted
As and when devices are created and attached to bus, we sift through this pool
to correctly determine the output ID for the device.
quoted
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
So are you asking me if that's OK ? Or there is something you can't
describe with IORT ?
I am asking if that would be acceptable?
i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag)
and then we use the Platform MSI framework for all children devices of MC bus.
Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer.
How is this solved in DT ? You don't seem to need any DT binding on top
of the msi-parent property, which is equivalent to IORT single mappings
AFAICS so I would like to understand the whole DT flow (so that I
understand how this FSL bus works) before commenting any further.
And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id.
quoted
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
Yes. It's being done for all DT systems having ITS node.
This does not seem correct to me, I will let Marc comment on
the matter.
The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c
From: Marc Zyngier <maz@kernel.org> Date: 2020-02-17 15:35:05
On 2020-02-17 15:25, Lorenzo Pieralisi wrote:
On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote:
Hi Lorenzo,
[...]
quoted
quoted
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
Yes. It's being done for all DT systems having ITS node.
This does not seem correct to me, I will let Marc comment on
the matter.
Unfortunately, there isn't a very good way to avoid that ATM,
other than defering the registration of the irqdomain until
we know that a particular bus (for example a PCIe RC) is registered.
I started working on that at some point, and ended up nowhere because
no bus (PCI, FSL, or anything else) really give us the right information
when it is actually required (when a device starts claiming interrupts).
I *think* we could try a defer it until a bus root is found, and that
this bus has a topological link to an ITS. probably invasive though,
as you would need a set of "MSI providers" for each available irqchip
node.
In short, messy. But I'd be happy to revive this and have a look again.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Lorenzo Pieralisi <hidden> Date: 2020-02-17 16:26:46
On Mon, Feb 17, 2020 at 03:35:01PM +0000, Marc Zyngier wrote:
On 2020-02-17 15:25, Lorenzo Pieralisi wrote:
quoted
On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote:
Hi Lorenzo,
[...]
quoted
quoted
quoted
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
Yes. It's being done for all DT systems having ITS node.
This does not seem correct to me, I will let Marc comment on
the matter.
Unfortunately, there isn't a very good way to avoid that ATM,
other than defering the registration of the irqdomain until
we know that a particular bus (for example a PCIe RC) is registered.
I started working on that at some point, and ended up nowhere because
no bus (PCI, FSL, or anything else) really give us the right information
when it is actually required (when a device starts claiming interrupts).
I *think* we could try a defer it until a bus root is found, and that
this bus has a topological link to an ITS. probably invasive though,
as you would need a set of "MSI providers" for each available irqchip
node.
Yes I see, it is not trivial - I just raised the point while reading the
code to understand how the IRQ domain structures are connected in the DT
bootstrap case, I don't think that's an urgent issue to solve, just
noticed and reported it to make sure you are aware.
Thanks !
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Yang [off-list ref]; netdev@vger.kernel.org; Rafael J. Wysocki
[off-list ref]; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>;
quoted
quoted
Shameerali Kolothum Thodi [off-list ref];
Sudeep Holla [off-list ref]; Robin Murphy
[off-list ref]
Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Side note: would you mind removing the email headers (as above) in your
replies please ?
Read the question above please.
[...]
quoted
quoted
quoted
As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can
dynamically create/destroy these devices.
quoted
Now, we want to represent this BUS (not individual devices connected to
bus)
quoted
quoted
in IORT table.
quoted
The only possible way right now we see is that we describe it as Named
components having a pool of ID mappings.
quoted
As and when devices are created and attached to bus, we sift through this
pool
quoted
quoted
to correctly determine the output ID for the device.
quoted
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.
So are you asking me if that's OK ? Or there is something you can't
describe with IORT ?
I am asking if that would be acceptable?
i.e. we represent MC bus as Named component is IORT table with a pool of IDs
(without single ID mapping flag)
quoted
and then we use the Platform MSI framework for all children devices of MC
bus.
quoted
Note that it would require the Platform MSI layer to correctly pass an input id
for a platform device to IORT layer.
How is this solved in DT ? You don't seem to need any DT binding on top
of the msi-parent property, which is equivalent to IORT single mappings
AFAICS so I would like to understand the whole DT flow (so that I
understand how this FSL bus works) before commenting any further.
In DT case, we create the domain DOMAIN_BUS_FSL_MC_MSI for MC bus and it's children.
And then when MC child device is created, we search the "msi-parent" property from the MC
DT node and get the ITS associated with MC bus. Then we search DOMAIN_BUS_FSL_MC_MSI
on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for that domain.
This is exactly what we tried to do initially with ACPI. But the searching DOMAIN_BUS_FSL_MC_MSI
associated to an ITS, is something that is part of drivers/acpi/arm64/iort.c.
(similar to DOMAIN_BUS_PLATFORM_MSI and DOMAIN_BUS_PCI_MSI)
quoted
And IORT layer ought to retrieve the output id based on single ID mapping flag
as well as input id.
quoted
quoted
Side note: can you explain to me please how the MSI allocation flow
and kernel data structures/drivers are modeled in DT ? I had a quick
look at:
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
and to start with, does that code imply that we create a
DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ?
Yes. It's being done for all DT systems having ITS node.
This does not seem correct to me, I will let Marc comment on
the matter.
quoted
The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c