* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Will Deacon @ 2020-05-21 13:04 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, John Garry, Joakim Zhang,
linux-kernel@vger.kernel.org, NXP Linux Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJfQ0PFy5mmwSG4aM91ghq5xiAEPR2YZOymws+BfGa+uA@mail.gmail.com>
On Wed, May 20, 2020 at 09:23:41AM -0600, Rob Herring wrote:
> On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > > + struct device_attribute *attr,
> > > > + char *page)
> > > > +{
> > > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > > +
> > > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> > >
> > > Why do we need yet another way to identify the SoC from userspace?
> >
> > I also really dislike this. What's the preferred way to identify the SoC
> > from userspace?
>
> /proc/cpuinfo? ;)
The *SoC*!
> For an non-firmware specific case, I'd say soc_device should be. I'd
> guess ACPI systems don't use it and for them it's dmidecode typically.
> The other problem I have with soc_device is it is optional.
John -- what do you think about using soc_device to expose this information,
with ACPI systems using DMI data instead?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Gilad Ben-Yossef @ 2020-05-21 13:01 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Stephan Mueller, Eric Biggers, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <CAMj1kXGNqo=d-hgK=0zBZCoJYgSxxhhm=Jdk2gAGXPo1-KSCgA@mail.gmail.com>
Hi Ard,
Thank you for looping me in.
On Wed, May 20, 2020 at 10:09 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 20 May 2020 at 09:01, Stephan Mueller <smueller@chronox.de> wrote:
> >
> > Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > On Wed, 20 May 2020 at 08:47, Stephan Mueller <smueller@chronox.de> wrote:
> ...
> > > > The state of all block chaining modes we currently have is defined with
> > > > the
> > > > IV. That is the reason why I mentioned it can be implemented stateless
> > > > when I am able to get the IV output from the previous operation.
> > >
> > > But it is simply the same as the penultimate block of ciphertext. So
> > > you can simply capture it after encrypt, or before decrypt. There is
> > > really no need to rely on the CTS transformation to pass it back to
> > > you via the buffer that is only specified to provide an input to the
> > > CTS transform.
> >
> > Let me recheck that as I am not fully sure on that one. But if it can be
> > handled that way, it would make life easier.
>
> Please refer to patch 2. The .iv_out test vectors were all simply
> copied from the appropriate offset into the associated .ctext member.
Not surprisingly since to the best of my understanding this behaviour
is not strictly specified, ccree currently fails the IV output check
with the 2nd version of the patch.
If I understand you correctly, the expected output IV is simply the
next to last block of the ciphertext?
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 11/12] bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Sudeep Holla, Catalin Marinas, Will Deacon, linux-pci,
Joerg Roedel, Hanjun Guo, Rafael J. Wysocki, Makarand Pawagi,
linux-acpi, iommu, Rob Herring, Marc Zyngier, Diana Craciun,
Bjorn Helgaas, Robin Murphy, Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
From: Diana Craciun <diana.craciun@oss.nxp.com>
The DPRC driver is not taking into account the msi-map property
and assumes that the icid is the same as the stream ID. Although
this assumption is correct, generalize the code to include a
translation between icid and streamID.
Furthermore do not just copy the MSI domain from parent (for child
containers), but use the information provided by the msi-map property.
If the msi-map property is missing from the device tree retain the old
behaviour for backward compatibility ie the child DPRC objects
inherit the MSI domain from the parent.
Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
---
drivers/bus/fsl-mc/dprc-driver.c | 31 ++++++---------------
drivers/bus/fsl-mc/fsl-mc-bus.c | 4 +--
drivers/bus/fsl-mc/fsl-mc-msi.c | 31 +++++++++++++--------
drivers/bus/fsl-mc/fsl-mc-private.h | 6 ++--
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 15 +++++++++-
5 files changed, 47 insertions(+), 40 deletions(-)
diff --git a/drivers/bus/fsl-mc/dprc-driver.c b/drivers/bus/fsl-mc/dprc-driver.c
index c8b1c3842c1a..189bff2115a8 100644
--- a/drivers/bus/fsl-mc/dprc-driver.c
+++ b/drivers/bus/fsl-mc/dprc-driver.c
@@ -592,6 +592,7 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
bool mc_io_created = false;
bool msi_domain_set = false;
u16 major_ver, minor_ver;
+ struct irq_domain *mc_msi_domain;
if (!is_fsl_mc_bus_dprc(mc_dev))
return -EINVAL;
@@ -621,31 +622,15 @@ static int dprc_probe(struct fsl_mc_device *mc_dev)
return error;
mc_io_created = true;
+ }
- /*
- * Inherit parent MSI domain:
- */
- dev_set_msi_domain(&mc_dev->dev,
- dev_get_msi_domain(parent_dev));
- msi_domain_set = true;
+ mc_msi_domain = fsl_mc_find_msi_domain(&mc_dev->dev);
+ if (!mc_msi_domain) {
+ dev_warn(&mc_dev->dev,
+ "WARNING: MC bus without interrupt support\n");
} else {
- /*
- * This is a root DPRC
- */
- struct irq_domain *mc_msi_domain;
-
- if (dev_is_fsl_mc(parent_dev))
- return -EINVAL;
-
- error = fsl_mc_find_msi_domain(parent_dev,
- &mc_msi_domain);
- if (error < 0) {
- dev_warn(&mc_dev->dev,
- "WARNING: MC bus without interrupt support\n");
- } else {
- dev_set_msi_domain(&mc_dev->dev, mc_msi_domain);
- msi_domain_set = true;
- }
+ dev_set_msi_domain(&mc_dev->dev, mc_msi_domain);
+ msi_domain_set = true;
}
error = dprc_open(mc_dev->mc_io, 0, mc_dev->obj_desc.id,
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 8ead3f0238f2..824ff77bbe86 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -370,8 +370,8 @@ EXPORT_SYMBOL_GPL(fsl_mc_get_version);
/**
* fsl_mc_get_root_dprc - function to traverse to the root dprc
*/
-static void fsl_mc_get_root_dprc(struct device *dev,
- struct device **root_dprc_dev)
+void fsl_mc_get_root_dprc(struct device *dev,
+ struct device **root_dprc_dev)
{
if (!dev) {
*root_dprc_dev = NULL;
diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
index 8b9c66d7c4ff..e7bbff445a83 100644
--- a/drivers/bus/fsl-mc/fsl-mc-msi.c
+++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
@@ -177,23 +177,30 @@ struct irq_domain *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
return domain;
}
-int fsl_mc_find_msi_domain(struct device *mc_platform_dev,
- struct irq_domain **mc_msi_domain)
+struct irq_domain *fsl_mc_find_msi_domain(struct device *dev)
{
- struct irq_domain *msi_domain;
- struct device_node *mc_of_node = mc_platform_dev->of_node;
+ struct irq_domain *msi_domain = NULL;
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
- msi_domain = of_msi_get_domain(mc_platform_dev, mc_of_node,
- DOMAIN_BUS_FSL_MC_MSI);
- if (!msi_domain) {
- pr_err("Unable to find fsl-mc MSI domain for %pOF\n",
- mc_of_node);
+ msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
+ DOMAIN_BUS_FSL_MC_MSI);
- return -ENOENT;
+ /*
+ * if the msi-map property is missing assume that all the
+ * child containers inherit the domain from the parent
+ */
+ if (!msi_domain) {
+ struct device *root_dprc_dev;
+ struct device *bus_dev;
+
+ fsl_mc_get_root_dprc(dev, &root_dprc_dev);
+ bus_dev = root_dprc_dev->parent;
+ msi_domain = of_msi_get_domain(bus_dev,
+ bus_dev->of_node,
+ DOMAIN_BUS_FSL_MC_MSI);
}
- *mc_msi_domain = msi_domain;
- return 0;
+ return msi_domain;
}
static void fsl_mc_msi_free_descs(struct device *dev)
diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h b/drivers/bus/fsl-mc/fsl-mc-private.h
index 21ca8c756ee7..7a46a12eb747 100644
--- a/drivers/bus/fsl-mc/fsl-mc-private.h
+++ b/drivers/bus/fsl-mc/fsl-mc-private.h
@@ -595,8 +595,7 @@ int fsl_mc_msi_domain_alloc_irqs(struct device *dev,
void fsl_mc_msi_domain_free_irqs(struct device *dev);
-int fsl_mc_find_msi_domain(struct device *mc_platform_dev,
- struct irq_domain **mc_msi_domain);
+struct irq_domain *fsl_mc_find_msi_domain(struct device *dev);
int fsl_mc_populate_irq_pool(struct fsl_mc_bus *mc_bus,
unsigned int irq_count);
@@ -613,6 +612,9 @@ void fsl_destroy_mc_io(struct fsl_mc_io *mc_io);
bool fsl_mc_is_root_dprc(struct device *dev);
+void fsl_mc_get_root_dprc(struct device *dev,
+ struct device **root_dprc_dev);
+
struct fsl_mc_device *fsl_mc_device_lookup(struct fsl_mc_obj_desc *obj_desc,
struct fsl_mc_device *mc_bus_dev);
diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
index 606efa64adff..a5c8d577e424 100644
--- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
@@ -23,6 +23,18 @@ static struct irq_chip its_msi_irq_chip = {
.irq_set_affinity = msi_domain_set_affinity
};
+static u32 fsl_mc_msi_domain_get_msi_id(struct irq_domain *domain,
+ struct fsl_mc_device *mc_dev)
+{
+ struct device_node *of_node;
+ u32 out_id;
+
+ of_node = irq_domain_get_of_node(domain);
+ out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
+
+ return out_id;
+}
+
static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
struct device *dev,
int nvec, msi_alloc_info_t *info)
@@ -43,7 +55,8 @@ static int its_fsl_mc_msi_prepare(struct irq_domain *msi_domain,
* NOTE: This device id corresponds to the IOMMU stream ID
* associated with the DPRC object (ICID).
*/
- info->scratchpad[0].ul = mc_bus_dev->icid;
+ info->scratchpad[0].ul = fsl_mc_msi_domain_get_msi_id(msi_domain,
+ mc_bus_dev);
msi_info = msi_get_domain_info(msi_domain->parent);
/* Allocate at least 32 MSIs, and always as a power of 2 */
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Sudeep Holla, Catalin Marinas, Will Deacon, linux-pci,
Joerg Roedel, Hanjun Guo, Rafael J. Wysocki, iommu, linux-acpi,
Makarand Pawagi, Rob Herring, Marc Zyngier, Diana Craciun,
Bjorn Helgaas, Robin Murphy, Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
From: Diana Craciun <diana.craciun@oss.nxp.com>
Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
extract memory and other resources.
Interrupt (GIC ITS) information is extracted from the MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table is parsed to configure DMA.
Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 73 +++++++++++++++-----
drivers/bus/fsl-mc/fsl-mc-msi.c | 37 +++++-----
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 75 ++++++++++++++++++++-
3 files changed, 150 insertions(+), 35 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 824ff77bbe86..324d49d6df89 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -18,6 +18,8 @@
#include <linux/bitops.h>
#include <linux/msi.h>
#include <linux/dma-mapping.h>
+#include <linux/acpi.h>
+#include <linux/iommu.h>
#include "fsl-mc-private.h"
@@ -38,6 +40,7 @@ struct fsl_mc {
struct fsl_mc_device *root_mc_bus_dev;
u8 num_translation_ranges;
struct fsl_mc_addr_translation_range *translation_ranges;
+ void *fsl_mc_regs;
};
/**
@@ -56,6 +59,10 @@ struct fsl_mc_addr_translation_range {
phys_addr_t start_phys_addr;
};
+#define FSL_MC_FAPR 0x28
+#define MC_FAPR_PL BIT(18)
+#define MC_FAPR_BMT BIT(17)
+
/**
* fsl_mc_bus_match - device to driver matching callback
* @dev: the fsl-mc device to match against
@@ -124,7 +131,10 @@ static int fsl_mc_dma_configure(struct device *dev)
while (dev_is_fsl_mc(dma_dev))
dma_dev = dma_dev->parent;
- return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
+ if (dev_of_node(dma_dev))
+ return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
+
+ return acpi_dma_configure_id(dev, DEV_DMA_COHERENT, &input_id);
}
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
@@ -865,8 +875,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
struct fsl_mc_io *mc_io = NULL;
int container_id;
phys_addr_t mc_portal_phys_addr;
- u32 mc_portal_size;
- struct resource res;
+ u32 mc_portal_size, mc_stream_id;
+ struct resource *plat_res;
+
+ if (!iommu_present(&fsl_mc_bus_type))
+ return -EPROBE_DEFER;
mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
if (!mc)
@@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mc);
+ plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res);
+ if (IS_ERR(mc->fsl_mc_regs))
+ return PTR_ERR(mc->fsl_mc_regs);
+
+ if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) {
+ mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
+ /*
+ * HW ORs the PL and BMT bit, places the result in bit 15 of
+ * the StreamID and ORs in the ICID. Calculate it accordingly.
+ */
+ mc_stream_id = (mc_stream_id & 0xffff) |
+ ((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ?
+ 0x4000 : 0);
+ error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
+ &mc_stream_id);
+ if (error)
+ dev_warn(&pdev->dev, "failed to configure dma: %d.\n",
+ error);
+ }
+
/*
* Get physical address of MC portal for the root DPRC:
*/
- error = of_address_to_resource(pdev->dev.of_node, 0, &res);
- if (error < 0) {
- dev_err(&pdev->dev,
- "of_address_to_resource() failed for %pOF\n",
- pdev->dev.of_node);
- return error;
- }
-
- mc_portal_phys_addr = res.start;
- mc_portal_size = resource_size(&res);
+ plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mc_portal_phys_addr = plat_res->start;
+ mc_portal_size = resource_size(plat_res);
error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr,
mc_portal_size, NULL,
FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, &mc_io);
@@ -903,11 +930,13 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n",
mc_version.major, mc_version.minor, mc_version.revision);
- error = get_mc_addr_translation_ranges(&pdev->dev,
- &mc->translation_ranges,
- &mc->num_translation_ranges);
- if (error < 0)
- goto error_cleanup_mc_io;
+ if (dev_of_node(&pdev->dev)) {
+ error = get_mc_addr_translation_ranges(&pdev->dev,
+ &mc->translation_ranges,
+ &mc->num_translation_ranges);
+ if (error < 0)
+ goto error_cleanup_mc_io;
+ }
error = dprc_get_container_id(mc_io, 0, &container_id);
if (error < 0) {
@@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
goto error_cleanup_mc_io;
mc->root_mc_bus_dev = mc_bus_dev;
+ mc_bus_dev->dev.fwnode = pdev->dev.fwnode;
return 0;
error_cleanup_mc_io:
@@ -967,11 +997,18 @@ static const struct of_device_id fsl_mc_bus_match_table[] = {
MODULE_DEVICE_TABLE(of, fsl_mc_bus_match_table);
+static const struct acpi_device_id fsl_mc_bus_acpi_match_table[] = {
+ {"NXP0008", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, fsl_mc_bus_acpi_match_table);
+
static struct platform_driver fsl_mc_bus_driver = {
.driver = {
.name = "fsl_mc_bus",
.pm = NULL,
.of_match_table = fsl_mc_bus_match_table,
+ .acpi_match_table = fsl_mc_bus_acpi_match_table,
},
.probe = fsl_mc_bus_probe,
.remove = fsl_mc_bus_remove,
diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
index e7bbff445a83..8edadf05cbb7 100644
--- a/drivers/bus/fsl-mc/fsl-mc-msi.c
+++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
@@ -13,6 +13,7 @@
#include <linux/irq.h>
#include <linux/irqdomain.h>
#include <linux/msi.h>
+#include <linux/acpi_iort.h>
#include "fsl-mc-private.h"
@@ -179,25 +180,31 @@ struct irq_domain *fsl_mc_msi_create_irq_domain(struct fwnode_handle *fwnode,
struct irq_domain *fsl_mc_find_msi_domain(struct device *dev)
{
- struct irq_domain *msi_domain = NULL;
+ struct device *root_dprc_dev;
+ struct device *bus_dev;
+ struct irq_domain *msi_domain;
struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
- msi_domain = of_msi_map_get_device_domain(dev, mc_dev->icid,
+ fsl_mc_get_root_dprc(dev, &root_dprc_dev);
+ bus_dev = root_dprc_dev->parent;
+
+ if (bus_dev->of_node) {
+ msi_domain = of_msi_map_get_device_domain(dev,
+ mc_dev->icid,
DOMAIN_BUS_FSL_MC_MSI);
- /*
- * if the msi-map property is missing assume that all the
- * child containers inherit the domain from the parent
- */
- if (!msi_domain) {
- struct device *root_dprc_dev;
- struct device *bus_dev;
-
- fsl_mc_get_root_dprc(dev, &root_dprc_dev);
- bus_dev = root_dprc_dev->parent;
- msi_domain = of_msi_get_domain(bus_dev,
- bus_dev->of_node,
- DOMAIN_BUS_FSL_MC_MSI);
+ /*
+ * if the msi-map property is missing assume that all the
+ * child containers inherit the domain from the parent
+ */
+ if (!msi_domain)
+
+ msi_domain = of_msi_get_domain(bus_dev,
+ bus_dev->of_node,
+ DOMAIN_BUS_FSL_MC_MSI);
+ } else {
+ msi_domain = iort_get_device_domain(dev, mc_dev->icid,
+ DOMAIN_BUS_FSL_MC_MSI);
}
return msi_domain;
diff --git a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
index a5c8d577e424..b8b948fb6b2d 100644
--- a/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
@@ -7,6 +7,8 @@
*
*/
+#include <linux/acpi.h>
+#include <linux/acpi_iort.h>
#include <linux/of_device.h>
#include <linux/of_address.h>
#include <linux/irq.h>
@@ -30,7 +32,8 @@ static u32 fsl_mc_msi_domain_get_msi_id(struct irq_domain *domain,
u32 out_id;
of_node = irq_domain_get_of_node(domain);
- out_id = of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid);
+ out_id = of_node ? of_msi_map_id(&mc_dev->dev, of_node, mc_dev->icid) :
+ iort_msi_map_id(&mc_dev->dev, mc_dev->icid);
return out_id;
}
@@ -79,7 +82,67 @@ static const struct of_device_id its_device_id[] = {
{},
};
-static int __init its_fsl_mc_msi_init(void)
+static int __init its_fsl_mc_msi_init_one(struct fwnode_handle *handle,
+ const char *name)
+{
+ struct irq_domain *parent;
+ struct irq_domain *mc_msi_domain;
+
+ parent = irq_find_matching_fwnode(handle, DOMAIN_BUS_NEXUS);
+ if (!parent || !msi_get_domain_info(parent)) {
+ pr_err("%s: Unable to locate ITS domain\n", name);
+ return -ENXIO;
+ }
+
+ mc_msi_domain = fsl_mc_msi_create_irq_domain(handle,
+ &its_fsl_mc_msi_domain_info,
+ parent);
+ if (!mc_msi_domain)
+ pr_err("ACPIF: unable to create fsl-mc domain\n");
+
+ pr_info("fsl-mc MSI: domain created\n");
+
+ return 0;
+}
+
+static int __init
+its_fsl_mc_msi_parse_madt(union acpi_subtable_headers *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_translator *its_entry;
+ struct fwnode_handle *dom_handle;
+ const char *node_name;
+ int err = -ENXIO;
+
+ its_entry = (struct acpi_madt_generic_translator *)header;
+ node_name = kasprintf(GFP_KERNEL, "ITS@0x%lx",
+ (long)its_entry->base_address);
+
+ dom_handle = iort_find_domain_token(its_entry->translation_id);
+ if (!dom_handle) {
+ pr_err("%s: Unable to locate ITS domain handle\n", node_name);
+ goto out;
+ }
+
+ err = its_fsl_mc_msi_init_one(dom_handle, node_name);
+ if (!err)
+ pr_info("fsl-mc MSI: %s domain created\n", node_name);
+
+out:
+ kfree(node_name);
+ return err;
+}
+
+
+static int __init its_fsl_mc_acpi_msi_init(void)
+{
+ acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
+ its_fsl_mc_msi_parse_madt, 0);
+
+ return 0;
+}
+
+static int __init its_fsl_mc_of_msi_init(void)
{
struct device_node *np;
struct irq_domain *parent;
@@ -113,4 +176,12 @@ static int __init its_fsl_mc_msi_init(void)
return 0;
}
+static int __init its_fsl_mc_msi_init(void)
+{
+ its_fsl_mc_of_msi_init();
+ its_fsl_mc_acpi_msi_init();
+
+ return 0;
+}
+
early_initcall(its_fsl_mc_msi_init);
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Catalin Marinas, Will Deacon, linux-pci, Joerg Roedel,
Sudeep Holla, Rafael J. Wysocki, Makarand Pawagi, linux-acpi,
iommu, Rob Herring, Marc Zyngier, Hanjun Guo, Bjorn Helgaas,
Robin Murphy, Diana Craciun, Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.
Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
msi-map property.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 +++++++++++++++++--
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 9134e9bcca56..b0813b2d0493 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit value called an ICID
the requester.
The generic 'iommus' property is insufficient to describe the relationship
-between ICIDs and IOMMUs, so an iommu-map property is used to define
-the set of possible ICIDs under a root DPRC and how they map to
-an IOMMU.
+between ICIDs and IOMMUs, so the iommu-map and msi-map properties are used
+to define the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU and a GIC ITS respectively.
For generic IOMMU bindings, see
Documentation/devicetree/bindings/iommu/iommu.txt.
@@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
For arm-smmu binding, see:
Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
+For GICv3 and GIC ITS bindings, see:
+Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
+
Required properties:
- compatible
@@ -119,6 +122,15 @@ Optional properties:
associated with the listed IOMMU, with the iommu-specifier
(i - icid-base + iommu-base).
+- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
+ data.
+
+ The property is an arbitrary number of tuples of
+ (icid-base,iommu,iommu-base,length).
+
+ Any ICID in the interval [icid-base, icid-base + length) is
+ associated with the listed GIC ITS, with the iommu-specifier
+ (i - icid-base + iommu-base).
Example:
smmu: iommu@5000000 {
@@ -128,6 +140,16 @@ Example:
...
};
+ gic: interrupt-controller@6000000 {
+ compatible = "arm,gic-v3";
+ ...
+ its: gic-its@6020000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ ...
+ };
+ };
+
fsl_mc: fsl-mc@80c000000 {
compatible = "fsl,qoriq-mc";
reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
@@ -135,6 +157,8 @@ Example:
msi-parent = <&its>;
/* define map for ICIDs 23-64 */
iommu-map = <23 &smmu 23 41>;
+ /* define msi map for ICIDs 23-64 */
+ msi-map = <23 &its 23 41>;
#address-cells = <3>;
#size-cells = <1>;
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/12] of/irq: Make of_msi_map_rid() PCI bus agnostic
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
Marc Zyngier, Joerg Roedel, Hanjun Guo, Rafael J. Wysocki,
Makarand Pawagi, Sudeep Holla, linux-acpi, iommu, Rob Herring,
linux-pci, Bjorn Helgaas, Robin Murphy, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
There is nothing PCI bus specific in the of_msi_map_rid()
implementation other than the requester ID tag for the input
ID space. Rename requester ID to a more generic ID so that
the translation code can be used by all busses that require
input/output ID translations.
Leave a wrapper function of_msi_map_rid() in place to keep
existing PCI code mapping requester ID syntactically unchanged.
No functional change intended.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
---
drivers/of/irq.c | 28 ++++++++++++++--------------
include/linux/of_irq.h | 14 ++++++++++++--
2 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 48a40326984f..25d17b8a1a1a 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -576,43 +576,43 @@ void __init of_irq_init(const struct of_device_id *matches)
}
}
-static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
- u32 rid_in)
+static u32 __of_msi_map_id(struct device *dev, struct device_node **np,
+ u32 id_in)
{
struct device *parent_dev;
- u32 rid_out = rid_in;
+ u32 id_out = id_in;
/*
* Walk up the device parent links looking for one with a
* "msi-map" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
- if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
- "msi-map-mask", np, &rid_out))
+ if (!of_map_id(parent_dev->of_node, id_in, "msi-map",
+ "msi-map-mask", np, &id_out))
break;
- return rid_out;
+ return id_out;
}
/**
- * of_msi_map_rid - Map a MSI requester ID for a device.
+ * of_msi_map_id - Map a MSI ID for a device.
* @dev: device for which the mapping is to be done.
* @msi_np: device node of the expected msi controller.
- * @rid_in: unmapped MSI requester ID for the device.
+ * @id_in: unmapped MSI ID for the device.
*
* Walk up the device hierarchy looking for devices with a "msi-map"
- * property. If found, apply the mapping to @rid_in.
+ * property. If found, apply the mapping to @id_in.
*
- * Returns the mapped MSI requester ID.
+ * Returns the mapped MSI ID.
*/
-u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
+u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in)
{
- return __of_msi_map_rid(dev, &msi_np, rid_in);
+ return __of_msi_map_id(dev, &msi_np, id_in);
}
/**
* of_msi_map_get_device_domain - Use msi-map to find the relevant MSI domain
* @dev: device for which the mapping is to be done.
- * @rid: Requester ID for the device.
+ * @id: Device ID.
* @bus_token: Bus token
*
* Walk up the device hierarchy looking for devices with a "msi-map"
@@ -625,7 +625,7 @@ struct irq_domain *of_msi_map_get_device_domain(struct device *dev, u32 id,
{
struct device_node *np = NULL;
- __of_msi_map_rid(dev, &np, id);
+ __of_msi_map_id(dev, &np, id);
return irq_find_matching_host(np, bus_token);
}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 7142a3722758..cf9cb1e545ce 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -55,7 +55,12 @@ extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
u32 id,
u32 bus_token);
extern void of_msi_configure(struct device *dev, struct device_node *np);
-u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
+u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in);
+static inline u32 of_msi_map_rid(struct device *dev,
+ struct device_node *msi_np, u32 rid_in)
+{
+ return of_msi_map_id(dev, msi_np, rid_in);
+}
#else
static inline int of_irq_count(struct device_node *dev)
{
@@ -93,10 +98,15 @@ static inline struct irq_domain *of_msi_map_get_device_domain(struct device *dev
static inline void of_msi_configure(struct device *dev, struct device_node *np)
{
}
+static inline u32 of_msi_map_id(struct device *dev,
+ struct device_node *msi_np, u32 id_in)
+{
+ return id_in;
+}
static inline u32 of_msi_map_rid(struct device *dev,
struct device_node *msi_np, u32 rid_in)
{
- return rid_in;
+ return of_msi_map_id(dev, msi_np, rid_in);
}
#endif
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 08/12] of/irq: make of_msi_map_get_device_domain() bus agnostic
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
Rafael J. Wysocki, Marc Zyngier, Joerg Roedel, Hanjun Guo,
linux-pci, Makarand Pawagi, Sudeep Holla, linux-acpi, iommu,
Rob Herring, Diana Craciun, Bjorn Helgaas, Robin Murphy,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
From: Diana Craciun <diana.craciun@oss.nxp.com>
of_msi_map_get_device_domain() is PCI specific but it need not be and
can be easily changed to be bus agnostic in order to be used by other
busses by adding an IRQ domain bus token as an input parameter.
Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
---
drivers/of/irq.c | 8 +++++---
drivers/pci/msi.c | 2 +-
include/linux/of_irq.h | 5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a296eaf52a5b..48a40326984f 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -613,18 +613,20 @@ u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
* of_msi_map_get_device_domain - Use msi-map to find the relevant MSI domain
* @dev: device for which the mapping is to be done.
* @rid: Requester ID for the device.
+ * @bus_token: Bus token
*
* Walk up the device hierarchy looking for devices with a "msi-map"
* property.
*
* Returns: the MSI domain for this device (or NULL on failure)
*/
-struct irq_domain *of_msi_map_get_device_domain(struct device *dev, u32 rid)
+struct irq_domain *of_msi_map_get_device_domain(struct device *dev, u32 id,
+ u32 bus_token)
{
struct device_node *np = NULL;
- __of_msi_map_rid(dev, &np, rid);
- return irq_find_matching_host(np, DOMAIN_BUS_PCI_MSI);
+ __of_msi_map_rid(dev, &np, id);
+ return irq_find_matching_host(np, bus_token);
}
/**
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 74a91f52ecc0..9532e1d12d3f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1556,7 +1556,7 @@ struct irq_domain *pci_msi_get_device_domain(struct pci_dev *pdev)
u32 rid = pci_dev_id(pdev);
pci_for_each_dma_alias(pdev, get_msi_id_cb, &rid);
- dom = of_msi_map_get_device_domain(&pdev->dev, rid);
+ dom = of_msi_map_get_device_domain(&pdev->dev, rid, DOMAIN_BUS_PCI_MSI);
if (!dom)
dom = iort_get_device_domain(&pdev->dev, rid,
DOMAIN_BUS_PCI_MSI);
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 1214cabb2247..7142a3722758 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -52,7 +52,8 @@ extern struct irq_domain *of_msi_get_domain(struct device *dev,
struct device_node *np,
enum irq_domain_bus_token token);
extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
- u32 rid);
+ u32 id,
+ u32 bus_token);
extern void of_msi_configure(struct device *dev, struct device_node *np);
u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
#else
@@ -85,7 +86,7 @@ static inline struct irq_domain *of_msi_get_domain(struct device *dev,
return NULL;
}
static inline struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
- u32 rid)
+ u32 id, u32 bus_token)
{
return NULL;
}
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/12] of/device: Add input id to of_dma_configure()
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
linux-pci, Joerg Roedel, Sudeep Holla, Rafael J. Wysocki,
Makarand Pawagi, linux-acpi, iommu, Rob Herring, Marc Zyngier,
Hanjun Guo, Bjorn Helgaas, Robin Murphy, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
Devices sitting on proprietary busses have a device ID space that
is owned by the respective bus and related firmware bindings. In order
to let the generic OF layer handle the input translations to
an IOMMU id, for such busses the current of_dma_configure() interface
should be extended in order to allow the bus layer to provide the
device input id parameter - that is retrieved/assigned in bus
specific code and firmware.
Augment of_dma_configure() to add an optional input_id parameter,
leaving current functionality unchanged.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 4 ++-
drivers/iommu/of_iommu.c | 53 +++++++++++++++++++++------------
drivers/of/device.c | 8 +++--
include/linux/of_device.h | 16 ++++++++--
include/linux/of_iommu.h | 6 ++--
5 files changed, 60 insertions(+), 27 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 40526da5c6a6..8ead3f0238f2 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -118,11 +118,13 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
static int fsl_mc_dma_configure(struct device *dev)
{
struct device *dma_dev = dev;
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+ u32 input_id = mc_dev->icid;
while (dev_is_fsl_mc(dma_dev))
dma_dev = dma_dev->parent;
- return of_dma_configure(dev, dma_dev->of_node, 0);
+ return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
}
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index ad96b87137d6..4516d5bf6cc9 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -139,25 +139,53 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
return err;
}
-static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
- struct device_node *master_np)
+static int of_iommu_configure_dev_id(struct device_node *master_np,
+ struct device *dev,
+ const u32 *id)
{
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_map_id(master_np, mc_dev->icid, "iommu-map",
+ err = of_map_id(master_np, *id, "iommu-map",
"iommu-map-mask", &iommu_spec.np,
iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
- err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+ err = of_iommu_xlate(dev, &iommu_spec);
of_node_put(iommu_spec.np);
return err;
}
+static int of_iommu_configure_dev(struct device_node *master_np,
+ struct device *dev)
+{
+ struct of_phandle_args iommu_spec;
+ int err = NO_IOMMU, idx = 0;
+
+ while (!of_parse_phandle_with_args(master_np, "iommus",
+ "#iommu-cells",
+ idx, &iommu_spec)) {
+ err = of_iommu_xlate(dev, &iommu_spec);
+ of_node_put(iommu_spec.np);
+ idx++;
+ if (err)
+ break;
+ }
+
+ return err;
+}
+
+static int of_iommu_configure_device(struct device_node *master_np,
+ struct device *dev, const u32 *id)
+{
+ return (id) ? of_iommu_configure_dev_id(master_np, dev, id) :
+ of_iommu_configure_dev(master_np, dev);
+}
+
const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np)
+ struct device_node *master_np,
+ const u32 *id)
{
const struct iommu_ops *ops = NULL;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
@@ -188,21 +216,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
pci_request_acs();
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, &info);
- } else if (dev_is_fsl_mc(dev)) {
- err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
- struct of_phandle_args iommu_spec;
- int idx = 0;
-
- while (!of_parse_phandle_with_args(master_np, "iommus",
- "#iommu-cells",
- idx, &iommu_spec)) {
- err = of_iommu_xlate(dev, &iommu_spec);
- of_node_put(iommu_spec.np);
- idx++;
- if (err)
- break;
- }
+ err = of_iommu_configure_device(master_np, dev, id);
fwspec = dev_iommu_fwspec_get(dev);
if (!err && fwspec)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..b439c1e05434 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -78,6 +78,7 @@ int of_device_add(struct platform_device *ofdev)
* @np: Pointer to OF node having DMA configuration
* @force_dma: Whether device is to be set up by of_dma_configure() even if
* DMA capability is not explicitly described by firmware.
+ * @id: Optional const pointer value input id
*
* Try to get devices's DMA configuration from DT and update it
* accordingly.
@@ -86,7 +87,8 @@ int of_device_add(struct platform_device *ofdev)
* can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
* to fix up DMA configuration.
*/
-int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
+int of_dma_configure_id(struct device *dev, struct device_node *np,
+ bool force_dma, const u32 *id)
{
u64 dma_addr, paddr, size = 0;
int ret;
@@ -160,7 +162,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
- iommu = of_iommu_configure(dev, np);
+ iommu = of_iommu_configure(dev, np, id);
if (PTR_ERR(iommu) == -EPROBE_DEFER)
return -EPROBE_DEFER;
@@ -171,7 +173,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
return 0;
}
-EXPORT_SYMBOL_GPL(of_dma_configure);
+EXPORT_SYMBOL_GPL(of_dma_configure_id);
int of_device_register(struct platform_device *pdev)
{
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 8d31e39dd564..07ca187fc5e4 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,9 +55,15 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
return of_node_get(cpu_dev->of_node);
}
-int of_dma_configure(struct device *dev,
+int of_dma_configure_id(struct device *dev,
struct device_node *np,
- bool force_dma);
+ bool force_dma, const u32 *id);
+static inline int of_dma_configure(struct device *dev,
+ struct device_node *np,
+ bool force_dma)
+{
+ return of_dma_configure_id(dev, np, force_dma, NULL);
+}
#else /* CONFIG_OF */
static inline int of_driver_match_device(struct device *dev,
@@ -106,6 +112,12 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
return NULL;
}
+static inline int of_dma_configure_id(struct device *dev,
+ struct device_node *np,
+ bool force_dma)
+{
+ return 0;
+}
static inline int of_dma_configure(struct device *dev,
struct device_node *np,
bool force_dma)
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index f3d40dd7bb66..16f4b3e87f20 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -13,7 +13,8 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
size_t *size);
extern const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np);
+ struct device_node *master_np,
+ const u32 *id);
#else
@@ -25,7 +26,8 @@ static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
}
static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np)
+ struct device_node *master_np,
+ const u32 *id)
{
return NULL;
}
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/12] of/iommu: Make of_map_rid() PCI agnostic
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Catalin Marinas, Will Deacon,
Marc Zyngier, Joerg Roedel, Hanjun Guo, Rafael J. Wysocki,
Makarand Pawagi, Sudeep Holla, linux-acpi, iommu, Rob Herring,
linux-pci, Bjorn Helgaas, Robin Murphy, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
There is nothing PCI specific (other than the RID - requester ID)
in the of_map_rid() implementation, so the same function can be
reused for input/output IDs mapping for other busses just as well.
Rename the RID instances/names to a generic "id" tag and provide
an of_map_rid() wrapper function so that we can leave the existing
(and legitimate) callers unchanged.
No functionality change intended.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
---
drivers/iommu/of_iommu.c | 2 +-
drivers/of/base.c | 42 ++++++++++++++++++++--------------------
include/linux/of.h | 17 +++++++++++++++-
3 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 20738aacac89..ad96b87137d6 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -145,7 +145,7 @@ static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+ err = of_map_id(master_np, mc_dev->icid, "iommu-map",
"iommu-map-mask", &iommu_spec.np,
iommu_spec.args);
if (err)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ae03b1218b06..e000e17bd602 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2201,15 +2201,15 @@ int of_find_last_cache_level(unsigned int cpu)
}
/**
- * of_map_rid - Translate a requester ID through a downstream mapping.
+ * of_map_id - Translate a requester ID through a downstream mapping.
* @np: root complex device node.
- * @rid: device requester ID to map.
+ * @id: device ID to map.
* @map_name: property name of the map to use.
* @map_mask_name: optional property name of the mask to use.
* @target: optional pointer to a target device node.
* @id_out: optional pointer to receive the translated ID.
*
- * Given a device requester ID, look up the appropriate implementation-defined
+ * Given a device ID, look up the appropriate implementation-defined
* platform ID and/or the target device which receives transactions on that
* ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
* @id_out may be NULL if only the other is required. If @target points to
@@ -2219,11 +2219,11 @@ int of_find_last_cache_level(unsigned int cpu)
*
* Return: 0 on success or a standard error code on failure.
*/
-int of_map_rid(struct device_node *np, u32 rid,
+int of_map_id(struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out)
{
- u32 map_mask, masked_rid;
+ u32 map_mask, masked_id;
int map_len;
const __be32 *map = NULL;
@@ -2235,7 +2235,7 @@ int of_map_rid(struct device_node *np, u32 rid,
if (target)
return -ENODEV;
/* Otherwise, no map implies no translation */
- *id_out = rid;
+ *id_out = id;
return 0;
}
@@ -2255,22 +2255,22 @@ int of_map_rid(struct device_node *np, u32 rid,
if (map_mask_name)
of_property_read_u32(np, map_mask_name, &map_mask);
- masked_rid = map_mask & rid;
+ masked_id = map_mask & id;
for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
struct device_node *phandle_node;
- u32 rid_base = be32_to_cpup(map + 0);
+ u32 id_base = be32_to_cpup(map + 0);
u32 phandle = be32_to_cpup(map + 1);
u32 out_base = be32_to_cpup(map + 2);
- u32 rid_len = be32_to_cpup(map + 3);
+ u32 id_len = be32_to_cpup(map + 3);
- if (rid_base & ~map_mask) {
- pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+ if (id_base & ~map_mask) {
+ pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n",
np, map_name, map_name,
- map_mask, rid_base);
+ map_mask, id_base);
return -EFAULT;
}
- if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+ if (masked_id < id_base || masked_id >= id_base + id_len)
continue;
phandle_node = of_find_node_by_phandle(phandle);
@@ -2288,20 +2288,20 @@ int of_map_rid(struct device_node *np, u32 rid,
}
if (id_out)
- *id_out = masked_rid - rid_base + out_base;
+ *id_out = masked_id - id_base + out_base;
- pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
- np, map_name, map_mask, rid_base, out_base,
- rid_len, rid, masked_rid - rid_base + out_base);
+ pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
+ np, map_name, map_mask, id_base, out_base,
+ id_len, id, masked_id - id_base + out_base);
return 0;
}
- pr_info("%pOF: no %s translation for rid 0x%x on %pOF\n", np, map_name,
- rid, target && *target ? *target : NULL);
+ pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
+ id, target && *target ? *target : NULL);
/* Bypasses translation */
if (id_out)
- *id_out = rid;
+ *id_out = id;
return 0;
}
-EXPORT_SYMBOL_GPL(of_map_rid);
+EXPORT_SYMBOL_GPL(of_map_id);
diff --git a/include/linux/of.h b/include/linux/of.h
index c669c0a4732f..b7934566a1aa 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -554,10 +554,18 @@ bool of_console_check(struct device_node *dn, char *name, int index);
extern int of_cpu_node_to_id(struct device_node *np);
-int of_map_rid(struct device_node *np, u32 rid,
+int of_map_id(struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out);
+static inline int of_map_rid(struct device_node *np, u32 rid,
+ const char *map_name,
+ const char *map_mask_name,
+ struct device_node **target, u32 *id_out)
+{
+ return of_map_id(np, rid, map_name, map_mask_name, target, id_out);
+}
+
#else /* CONFIG_OF */
static inline void of_core_init(void)
@@ -978,6 +986,13 @@ static inline int of_cpu_node_to_id(struct device_node *np)
return -ENODEV;
}
+static inline int of_map_id(struct device_node *np, u32 id,
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
static inline int of_map_rid(struct device_node *np, u32 rid,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out)
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/12] ACPI/IORT: Add an input ID to acpi_dma_configure()
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Marc Zyngier, Makarand Pawagi,
linux-pci, Catalin Marinas, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Robin Murphy, linux-acpi, iommu, Rob Herring,
Sudeep Holla, Bjorn Helgaas, Will Deacon, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
Some HW devices are created as child devices of proprietary busses,
that have a bus specific policy definining how the child devices
wires representing the devices ID are translated into IOMMU and
IRQ controllers device IDs.
Current IORT code provides translations for:
- PCI devices, where the device ID is well identified at bus level
as the requester ID (RID)
- Platform devices that are endpoint devices where the device ID is
retrieved from the ACPI object IORT mappings (Named components single
mappings). A platform device is represented in IORT as a named
component node
For devices that are child devices of proprietary busses the IORT
firmware represents the bus node as a named component node in IORT
and it is up to that named component node to define in/out bus
specific ID translations for the bus child devices that are
allocated and created in a bus specific manner.
In order to make IORT ID translations available for proprietary
bus child devices, the current ACPI (and IORT) code must be
augmented to provide an additional ID parameter to acpi_dma_configure()
representing the child devices input ID. This ID is bus specific
and it is retrieved in bus specific code.
By adding an ID parameter to acpi_dma_configure(), the IORT
code can map the child device ID to an IOMMU stream id through
the IORT named component representing the bus in/out ID mappings.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 59 +++++++++++++++++++++++++++++----------
drivers/acpi/scan.c | 8 ++++--
include/acpi/acpi_bus.h | 9 ++++--
include/linux/acpi.h | 7 +++++
include/linux/acpi_iort.h | 7 +++--
5 files changed, 67 insertions(+), 23 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index ae9e1089d954..270c1a0cdeff 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1004,19 +1004,54 @@ static void iort_named_component_init(struct device *dev,
nc->node_flags);
}
+static int iort_nc_iommu_map(struct device *dev, struct acpi_iort_node *node)
+{
+ struct acpi_iort_node *parent;
+ int err = -ENODEV, i = 0;
+ u32 streamid = 0;
+
+ do {
+
+ parent = iort_node_map_platform_id(node, &streamid,
+ IORT_IOMMU_TYPE,
+ i++);
+
+ if (parent)
+ err = iort_iommu_xlate(dev, parent, streamid);
+ } while (parent && !err);
+
+ return err;
+}
+
+static int iort_nc_iommu_map_id(struct device *dev,
+ struct acpi_iort_node *node,
+ const u32 *in_id)
+{
+ struct acpi_iort_node *parent;
+ u32 streamid;
+
+ parent = iort_node_map_id(node, *in_id, &streamid, IORT_IOMMU_TYPE);
+ if (parent)
+ return iort_iommu_xlate(dev, parent, streamid);
+
+ return -ENODEV;
+}
+
+
/**
- * iort_iommu_configure - Set-up IOMMU configuration for a device.
+ * iort_iommu_configure_id - Set-up IOMMU configuration for a device.
*
* @dev: device to configure
+ * @id_in: optional input id const value pointer
*
* Returns: iommu_ops pointer on configuration success
* NULL on configuration failure
*/
-const struct iommu_ops *iort_iommu_configure(struct device *dev)
+const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
+ const u32 *id_in)
{
- struct acpi_iort_node *node, *parent;
+ struct acpi_iort_node *node;
const struct iommu_ops *ops;
- u32 streamid = 0;
int err = -ENODEV;
/*
@@ -1045,21 +1080,13 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
if (fwspec && iort_pci_rc_supports_ats(node))
fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS;
} else {
- int i = 0;
-
node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
iort_match_node_callback, dev);
if (!node)
return NULL;
- do {
- parent = iort_node_map_platform_id(node, &streamid,
- IORT_IOMMU_TYPE,
- i++);
-
- if (parent)
- err = iort_iommu_xlate(dev, parent, streamid);
- } while (parent && !err);
+ err = id_in ? iort_nc_iommu_map_id(dev, node, id_in) :
+ iort_nc_iommu_map(dev, node);
if (!err)
iort_named_component_init(dev, node);
@@ -1084,6 +1111,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
return ops;
}
+
#else
static inline const struct iommu_ops *iort_fwspec_iommu_ops(struct device *dev)
{ return NULL; }
@@ -1092,7 +1120,8 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
{ return 0; }
int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
{ return 0; }
-const struct iommu_ops *iort_iommu_configure(struct device *dev)
+const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
+ const u32 *input_id)
{ return NULL; }
#endif
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6d3448895382..f252d65ee227 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1448,8 +1448,10 @@ int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
* acpi_dma_configure - Set-up DMA configuration for the device.
* @dev: The pointer to the device
* @attr: device dma attributes
+ * @input_id: input device id const value pointer
*/
-int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
+int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
+ const u32 *input_id)
{
const struct iommu_ops *iommu;
u64 dma_addr = 0, size = 0;
@@ -1461,7 +1463,7 @@ int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
iort_dma_setup(dev, &dma_addr, &size);
- iommu = iort_iommu_configure(dev);
+ iommu = iort_iommu_configure_id(dev, input_id);
if (PTR_ERR(iommu) == -EPROBE_DEFER)
return -EPROBE_DEFER;
@@ -1470,7 +1472,7 @@ int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
return 0;
}
-EXPORT_SYMBOL_GPL(acpi_dma_configure);
+EXPORT_SYMBOL_GPL(acpi_dma_configure_id);
static void acpi_init_coherency(struct acpi_device *adev)
{
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index a92bea7184a8..79eb4b9c86f2 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -587,8 +587,13 @@ bool acpi_dma_supported(struct acpi_device *adev);
enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
u64 *size);
-int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
-
+int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
+ const u32 *input_id);
+static inline int acpi_dma_configure(struct device *dev,
+ enum dev_dma_attr attr)
+{
+ return acpi_dma_configure_id(dev, attr, NULL);
+}
struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
u64 address, bool check_children);
int acpi_is_root_bridge(acpi_handle);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d661cd0ee64d..6d2c47489d90 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -905,6 +905,13 @@ static inline int acpi_dma_configure(struct device *dev,
return 0;
}
+static inline int acpi_dma_configure_id(struct device *dev,
+ enum dev_dma_attr attr,
+ const u32 *input_id)
+{
+ return 0;
+}
+
#define ACPI_PTR(_ptr) (NULL)
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8c71f92b92ef..cb9f079a7358 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,7 +39,8 @@ void acpi_configure_pmsi_domain(struct device *dev);
int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
/* IOMMU interface */
void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
-const struct iommu_ops *iort_iommu_configure(struct device *dev);
+const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
+ const u32 *id_in);
int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
#else
static inline void acpi_iort_init(void) { }
@@ -56,8 +57,8 @@ static inline void acpi_configure_pmsi_domain(struct device *dev) { }
/* IOMMU interface */
static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
u64 *size) { }
-static inline const struct iommu_ops *iort_iommu_configure(
- struct device *dev)
+static inline const struct iommu_ops *iort_iommu_configure_id(
+ struct device *dev, const u32 *id_in)
{ return NULL; }
static inline
int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/12] ACPI/IORT: Remove useless PCI bus walk
From: Lorenzo Pieralisi @ 2020-05-21 13:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Marc Zyngier, Makarand Pawagi,
linux-pci, Catalin Marinas, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Robin Murphy, linux-acpi, iommu, Rob Herring,
Sudeep Holla, Bjorn Helgaas, Will Deacon, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
The PCI bus domain number (used in the iort_match_node_callback() -
pci_domain_nr() call) is cascaded through the PCI bus hierarchy at PCI
bus enumeration time, therefore there is no need in iort_find_dev_node()
to walk the PCI bus upwards to grab the root bus to be passed to
iort_scan_node(), the device->bus PCI bus pointer will do.
Remove this useless code.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index f346a785e0b5..ae9e1089d954 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -575,10 +575,7 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
iort_match_node_callback, dev);
}
- /* Find a PCI root bus */
pbus = to_pci_dev(dev)->bus;
- while (!pci_is_root_bus(pbus))
- pbus = pbus->parent;
return iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
iort_match_node_callback, &pbus->dev);
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/12] ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
From: Lorenzo Pieralisi @ 2020-05-21 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Marc Zyngier, Makarand Pawagi,
linux-pci, Catalin Marinas, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Robin Murphy, linux-acpi, iommu, Rob Herring,
Sudeep Holla, Bjorn Helgaas, Will Deacon, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
There is nothing PCI specific in iort_msi_map_rid(). Make it
a generic function, iort_msi_map_id() and provide a stub
for iort_msi_map_rid() on top of it to keep current users
unchanged.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 12 ++++++------
include/linux/acpi_iort.h | 12 ++++++++++--
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 8f2a961c1364..f346a785e0b5 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -585,22 +585,22 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
}
/**
- * iort_msi_map_rid() - Map a MSI requester ID for a device
+ * iort_msi_map_id() - Map a MSI input ID for a device
* @dev: The device for which the mapping is to be done.
- * @req_id: The device requester ID.
+ * @input_id: The device input ID.
*
- * Returns: mapped MSI RID on success, input requester ID otherwise
+ * Returns: mapped MSI ID on success, input ID otherwise
*/
-u32 iort_msi_map_rid(struct device *dev, u32 req_id)
+u32 iort_msi_map_id(struct device *dev, u32 input_id)
{
struct acpi_iort_node *node;
u32 dev_id;
node = iort_find_dev_node(dev);
if (!node)
- return req_id;
+ return input_id;
- iort_node_map_id(node, req_id, &dev_id, IORT_MSI_TYPE);
+ iort_node_map_id(node, input_id, &dev_id, IORT_MSI_TYPE);
return dev_id;
}
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 08ec6bd2297f..8c71f92b92ef 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -28,7 +28,11 @@ void iort_deregister_domain_token(int trans_id);
struct fwnode_handle *iort_find_domain_token(int trans_id);
#ifdef CONFIG_ACPI_IORT
void acpi_iort_init(void);
-u32 iort_msi_map_rid(struct device *dev, u32 req_id);
+u32 iort_msi_map_id(struct device *dev, u32 id);
+static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
+{
+ return iort_msi_map_id(dev, req_id);
+}
struct irq_domain *iort_get_device_domain(struct device *dev, u32 id,
enum irq_domain_bus_token bus_token);
void acpi_configure_pmsi_domain(struct device *dev);
@@ -39,8 +43,12 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev);
int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
#else
static inline void acpi_iort_init(void) { }
+static inline u32 iort_msi_map_id(struct device *dev, u32 id)
+{ return id; }
static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
-{ return req_id; }
+{
+ return iort_msi_map_id(dev, req_id);
+}
static inline struct irq_domain *iort_get_device_domain(
struct device *dev, u32 id, enum irq_domain_bus_token bus_token)
{ return NULL; }
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/12] ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
From: Lorenzo Pieralisi @ 2020-05-21 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marc Zyngier, Lorenzo Pieralisi, devicetree, linux-pci,
Catalin Marinas, Joerg Roedel, Hanjun Guo, Rafael J. Wysocki,
Robin Murphy, linux-acpi, iommu, Rob Herring, Sudeep Holla,
Bjorn Helgaas, Diana Craciun, Will Deacon, Makarand Pawagi,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq_domain_bus_token input to it.
Make it PCI agnostic by also renaming the requestor ID input
to a more generic ID name.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Marc Zyngier <maz@kernel.org>
---
drivers/acpi/arm64/iort.c | 14 +++++++-------
drivers/pci/msi.c | 3 ++-
include/linux/acpi_iort.h | 7 ++++---
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 7cfd77b5e6e8..8f2a961c1364 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -567,7 +567,6 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev)
node = iort_get_iort_node(dev->fwnode);
if (node)
return node;
-
/*
* if not, then it should be a platform device defined in
* DSDT/SSDT (with Named Component node in IORT)
@@ -658,13 +657,13 @@ static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
- * @req_id: Device's requester ID
+ * @id: Device's ID
* @idx: Index of the ITS identifier list.
* @its_id: ITS identifier.
*
* Returns: 0 on success, appropriate error value otherwise
*/
-static int iort_dev_find_its_id(struct device *dev, u32 req_id,
+static int iort_dev_find_its_id(struct device *dev, u32 id,
unsigned int idx, int *its_id)
{
struct acpi_iort_its_group *its;
@@ -674,7 +673,7 @@ static int iort_dev_find_its_id(struct device *dev, u32 req_id,
if (!node)
return -ENXIO;
- node = iort_node_map_id(node, req_id, NULL, IORT_MSI_TYPE);
+ node = iort_node_map_id(node, id, NULL, IORT_MSI_TYPE);
if (!node)
return -ENXIO;
@@ -697,19 +696,20 @@ static int iort_dev_find_its_id(struct device *dev, u32 req_id,
*
* Returns: the MSI domain for this device, NULL otherwise
*/
-struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
+struct irq_domain *iort_get_device_domain(struct device *dev, u32 id,
+ enum irq_domain_bus_token bus_token)
{
struct fwnode_handle *handle;
int its_id;
- if (iort_dev_find_its_id(dev, req_id, 0, &its_id))
+ if (iort_dev_find_its_id(dev, id, 0, &its_id))
return NULL;
handle = iort_find_domain_token(its_id);
if (!handle)
return NULL;
- return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
+ return irq_find_matching_fwnode(handle, bus_token);
}
static void iort_set_device_domain(struct device *dev,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 6b43a5455c7a..74a91f52ecc0 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1558,7 +1558,8 @@ struct irq_domain *pci_msi_get_device_domain(struct pci_dev *pdev)
pci_for_each_dma_alias(pdev, get_msi_id_cb, &rid);
dom = of_msi_map_get_device_domain(&pdev->dev, rid);
if (!dom)
- dom = iort_get_device_domain(&pdev->dev, rid);
+ dom = iort_get_device_domain(&pdev->dev, rid,
+ DOMAIN_BUS_PCI_MSI);
return dom;
}
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8e7e2ec37f1b..08ec6bd2297f 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -29,7 +29,8 @@ struct fwnode_handle *iort_find_domain_token(int trans_id);
#ifdef CONFIG_ACPI_IORT
void acpi_iort_init(void);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
-struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
+struct irq_domain *iort_get_device_domain(struct device *dev, u32 id,
+ enum irq_domain_bus_token bus_token);
void acpi_configure_pmsi_domain(struct device *dev);
int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
/* IOMMU interface */
@@ -40,8 +41,8 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
static inline void acpi_iort_init(void) { }
static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
{ return req_id; }
-static inline struct irq_domain *iort_get_device_domain(struct device *dev,
- u32 req_id)
+static inline struct irq_domain *iort_get_device_domain(
+ struct device *dev, u32 id, enum irq_domain_bus_token bus_token)
{ return NULL; }
static inline void acpi_configure_pmsi_domain(struct device *dev) { }
/* IOMMU interface */
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/12] ACPI/OF: Upgrade MSI/IOMMU ID mapping APIs
From: Lorenzo Pieralisi @ 2020-05-21 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marc Zyngier, Lorenzo Pieralisi, Will Deacon, devicetree,
linux-pci, Catalin Marinas, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Makarand Pawagi, linux-acpi, iommu,
Rob Herring, Sudeep Holla, Bjorn Helgaas, Robin Murphy,
Diana Craciun, Laurentiu Tudor
Firmware bindings provided in the ACPI IORT table[1] and device tree
bindings define rules to carry out input/output ID mappings - ie
retrieving an IOMMU/MSI controller input ID for a device with a given
ID.
At the moment these firmware bindings are used exclusively for PCI
devices and their requester ID to IOMMU/MSI id mapping but there is
nothing PCI specific in the ACPI and devicetree bindings that prevent
the firmware and kernel from using the firmware bindings to traslate
device IDs for any bus that requires its devices to carry out
input/output id translations.
The Freescale FSL bus is an example whereby the input/output ID
translation kernel code put in place for PCI can be reused for devices
attached to the bus that are not PCI devices.
This series updates the kernel code to make the MSI/IOMMU input/output
ID translation PCI agnostic and apply the resulting changes to the
device ID space provided by the Freescale FSL bus.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf
Cc: Rob Herring <robh+dt@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Joerg Roedel <joro@8bytes.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Diana Craciun (3):
of/irq: make of_msi_map_get_device_domain() bus agnostic
bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver
bus: fsl-mc: Add ACPI support for fsl-mc
Laurentiu Tudor (1):
dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
Lorenzo Pieralisi (8):
ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for
NC
ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
ACPI/IORT: Remove useless PCI bus walk
ACPI/IORT: Add an input ID to acpi_dma_configure()
of/iommu: Make of_map_rid() PCI agnostic
of/device: Add input id to of_dma_configure()
of/irq: Make of_msi_map_rid() PCI bus agnostic
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 ++++-
drivers/acpi/arm64/iort.c | 108 ++++++++++++------
drivers/acpi/scan.c | 8 +-
drivers/bus/fsl-mc/dprc-driver.c | 31 ++---
drivers/bus/fsl-mc/fsl-mc-bus.c | 79 +++++++++----
drivers/bus/fsl-mc/fsl-mc-msi.c | 36 ++++--
drivers/bus/fsl-mc/fsl-mc-private.h | 6 +-
drivers/iommu/of_iommu.c | 53 ++++++---
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 88 +++++++++++++-
drivers/of/base.c | 42 +++----
drivers/of/device.c | 8 +-
drivers/of/irq.c | 34 +++---
drivers/pci/msi.c | 5 +-
include/acpi/acpi_bus.h | 9 +-
include/linux/acpi.h | 7 ++
include/linux/acpi_iort.h | 26 +++--
include/linux/of.h | 17 ++-
include/linux/of_device.h | 16 ++-
include/linux/of_iommu.h | 6 +-
include/linux/of_irq.h | 19 ++-
20 files changed, 451 insertions(+), 177 deletions(-)
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 01/12] ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for NC
From: Lorenzo Pieralisi @ 2020-05-21 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Marc Zyngier, Makarand Pawagi,
linux-pci, Catalin Marinas, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, Robin Murphy, linux-acpi, iommu, Rob Herring,
Sudeep Holla, Bjorn Helgaas, Will Deacon, Diana Craciun,
Laurentiu Tudor
In-Reply-To: <20200521130008.8266-1-lorenzo.pieralisi@arm.com>
When the iort_match_node_callback is invoked for a named component
the match should be executed upon a device with an ACPI companion.
For devices with no ACPI companion set-up the ACPI device tree must be
walked in order to find the first parent node with a companion set and
check the parent node against the named component entry to check whether
there is a match and therefore an IORT node describing the in/out ID
translation for the device has been found.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
drivers/acpi/arm64/iort.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 7d04424189df..7cfd77b5e6e8 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -264,15 +264,31 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER, NULL };
- struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
+ struct acpi_device *adev;
struct acpi_iort_named_component *ncomp;
+ struct device *nc_dev = dev;
+
+ /*
+ * Walk the device tree to find a device with an
+ * ACPI companion; there is no point in scanning
+ * IORT for a device matching a named component if
+ * the device does not have an ACPI companion to
+ * start with.
+ */
+ do {
+ adev = ACPI_COMPANION(nc_dev);
+ if (adev)
+ break;
+
+ nc_dev = nc_dev->parent;
+ } while (nc_dev);
if (!adev)
goto out;
status = acpi_get_name(adev->handle, ACPI_FULL_PATHNAME, &buf);
if (ACPI_FAILURE(status)) {
- dev_warn(dev, "Can't get device full path name\n");
+ dev_warn(nc_dev, "Can't get device full path name\n");
goto out;
}
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 05/19] mtd: spi-nor: add support for DTR protocol
From: Pratyush Yadav @ 2020-05-21 12:52 UTC (permalink / raw)
To: masonccyang
Cc: Alexandre Belloni, Vignesh Raghavendra, Tudor Ambarus,
Richard Weinberger, Mark Brown, Sekhar Nori, linux-kernel,
linux-spi, Ludovic Desroches, Boris Brezillon, linux-mediatek,
Miquel Raynal, Matthias Brugger, linux-mtd, linux-arm-kernel
In-Reply-To: <OF6C754784.29BF11CD-ON4825856F.0032D83F-4825856F.0033A4F1@mxic.com.tw>
Hi,
On 21/05/20 05:24PM, masonccyang@mxic.com.tw wrote:
>
> Hi Pratyush,
>
>
> > @@ -311,6 +313,7 @@ struct flash_info {
> > * BP3 is bit 6 of status register.
> > * Must be used with SPI_NOR_4BIT_BP.
> > */
> > +#define SPI_NOR_OCTAL_DTR_READ BIT(19) /* Flash supports octal DTR
> Read. */
>
> #define SPI_NOR_OCTAL_DTR_RDWR BIT(19) /* Support Octal DTR Read & Write
> */
This flag only enables SNOR_HWCAPS_READ_8_8_8_DTR. It does not affect
SNOR_HWCAPS_PP_8_8_8_DTR. So it shouldn't be called RDWR.
> more precisely and clearly ?
>
> thanks,
> Mason
>
--
Regards,
Pratyush Yadav
Texas Instruments India
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4,0/7] Add Mediatek thermal dirver and dtsi
From: Matthias Brugger @ 2020-05-21 12:51 UTC (permalink / raw)
To: Michael Kao, Zhang Rui, Eduardo Valentin, Daniel Lezcano,
Rob Herring, Mark Rutland, hsinyi, linux-pm, srv_heupstream
Cc: devicetree, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20200323121537.22697-1-michael.kao@mediatek.com>
Hi Michael,
On 23/03/2020 13:15, Michael Kao wrote:
> This patchset supports for MT8183 chip to mtk_thermal.c.
> Add thermal zone of all the thermal sensor in SoC for
> another get temperatrue. They don't need to thermal throttle.
> And we bind coolers for thermal zone nodes of cpu_thermal.
>
> Rebase to kernel-5.6-rc1.
>
> Update content:
>
> [1/7]
> - Squash thermal zone settings in the dtsi from [v3,5/8]
> arm64: dts: mt8183: Increase polling frequency for CPU thermal zone
>
> - Remove the property of interrupts and mediatek,hw-reset-temp
>
> [2/7]
> - Correct commit message
>
> [4/7]
> - Change the target temperature to the 80C and change the commit message
>
> [6/7]
> - Adjust newline alignment
>
> - Fix the judgement on the return value of registering thermal zone
>
> This patch series base on these patches [1].
>
> [v7,3/3] PM / AVS: SVS: Introduce SVS engine (https://patchwork.kernel.org/patch/11439829/)
>
> Matthias Kaehlcke (1):
> arm64: dts: mt8183: Configure CPU cooling
>
> Michael Kao (6):
> arm64: dts: mt8183: add thermal zone node
> arm64: dts: mt8183: add dynamic power coefficients
> arm64: dts: mt8183: Add #cooling-cells to CPU nodes
> thermal: mediatek: mt8183: fix bank number settings
Do I understand correctly that we need to fix the bank number before we can add
the device tree changes. And that the last two patches are enhancements for the
driver but needed to get a working version?
Regards,
Matthias
> thermal: mediatek: add another get_temp ops for thermal sensors
> thermal: mediatek: use spinlock to protect PTPCORESEL
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 156 +++++++++++++++++++++++
> drivers/thermal/mtk_thermal.c | 88 +++++++++++--
> 2 files changed, 231 insertions(+), 13 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/7] add support USB for MT8183
From: Matthias Brugger @ 2020-05-21 12:41 UTC (permalink / raw)
To: Chunfeng Yun, Greg Kroah-Hartman
Cc: Mark Rutland, devicetree, Mathias Nyman, linux-usb, linux-kernel,
Rob Herring, linux-mediatek, linux-arm-kernel
In-Reply-To: <1567562067.7317.52.camel@mhfsdcap03>
Hi Chungfeng,
On 04/09/2019 03:54, Chunfeng Yun wrote:
> Hi Greg,
>
>
> Please don't try to pick up this series, the dependent ones are still
> under public review, I'll fix build warning and send out new version
> after the dependent ones are applied
> Sorry for inconvenience
>
I think the pmic driver is upstream now and show up in linux-next soon.
I propose to rebase the series and send it again.
Regards,
Matthias
> Thanks
>
> On Fri, 2019-08-30 at 15:40 +0800, Chunfeng Yun wrote:
>> This series support USB DRD controller and enable it's remote
>> wakeup functoin for MT8183, they depend on the following
>> series patches:
>>
>> 1. this series add support MT6358 PMIC
>> [v5,01/10] mfd: mt6397: clean up code
>> https://patchwork.kernel.org/patch/11110487/
>>
>> 2. this series add support pericfg syscon
>> [v2,1/2] dt-bindings: clock: mediatek: add pericfg for MT8183
>> https://patchwork.kernel.org/patch/11118183/
>>
>> 3. add property mediatek,discth for tphy
>> [06/11] phy: phy-mtk-tphy: add a property for disconnect threshold
>> https://patchwork.kernel.org/patch/11110695/
>>
>> v3 changes:
>> 1. changes micros define
>> 2. remove #reset-cell
>> 3. update dependent series
>>
>> v2 changes:
>> add patch [7/7]
>>
>> Chunfeng Yun (7):
>> dt-bindings: usb: mtu3: support USB wakeup for MT8183
>> dt-bindings: usb: mtk-xhci: support USB wakeup for MT8183
>> usb: mtu3: support ip-sleep wakeup for MT8183
>> usb: mtk-xhci: support ip-sleep wakeup for MT8183
>> arm64: dts: mt8183: add usb and phy nodes
>> arm64: dts: mt8183: enable USB remote wakeup
>> arm64: dts: mt8183: tune disconnect threshold of u2phy
>>
>> .../bindings/usb/mediatek,mtk-xhci.txt | 1 +
>> .../devicetree/bindings/usb/mediatek,mtu3.txt | 1 +
>> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 23 +++++++
>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 63 +++++++++++++++++++
>> drivers/usb/host/xhci-mtk.c | 14 ++++-
>> drivers/usb/mtu3/mtu3_host.c | 14 ++++-
>> 6 files changed, 114 insertions(+), 2 deletions(-)
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Eric W. Biederman @ 2020-05-21 12:35 UTC (permalink / raw)
To: Peter Collingbourne
Cc: Andrey Konovalov, Kevin Brodsky, Oleg Nesterov, Kostya Serebryany,
Linux ARM, Catalin Marinas, Vincenzo Frascino, Will Deacon,
Dave Martin, Evgenii Stepanov, Richard Henderson
In-Reply-To: <CAMn1gO7VWBcbMvqNeyBdfpO71kfhrZbHwkOC0JeSX13_HUMmWA@mail.gmail.com>
Peter Collingbourne <pcc@google.com> writes:
> On Wed, May 20, 2020 at 2:26 AM Dave Martin <Dave.Martin@arm.com> wrote:
>>
>> On Wed, May 20, 2020 at 09:55:03AM +0100, Will Deacon wrote:
>> > On Tue, May 19, 2020 at 03:00:12PM -0700, Peter Collingbourne wrote:
>> > > On Mon, May 18, 2020 at 2:53 AM Dave Martin <Dave.Martin@arm.com> wrote:
>> > > > On Thu, May 14, 2020 at 05:58:21PM -0700, Peter Collingbourne wrote:
>> > > > > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
>> > > > > index baa88dc02e5c..5867f2fdbe64 100644
>> > > > > --- a/arch/arm64/kernel/signal.c
>> > > > > +++ b/arch/arm64/kernel/signal.c
>> > > > > @@ -648,6 +648,7 @@ static int setup_sigframe(struct
>> > > > > rt_sigframe_user_layout *user,
>> > > > > __put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
>> > > > > __put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
>> > > > > __put_user_error(current->thread.fault_code,
>> > > > > &esr_ctx->esr, err);
>> > > > > + current->thread.fault_code = 0;
>> > > >
>> > > > Perhaps, but we'd need to be careful. For example, can we run out of
>> > > > user stack before this and deliver a SIGSEGV, but with the old
>> > > > fault_code still set? Then we'd emit the old fault code with the
>> > > > new "can't deliver signal" signal, which doesn't make sense.
>> > > >
>> > > > Stuff may also go wrong with signal prioritisation.
>> > > >
>> > > > If a higher-priority signal (say SIGINT) comes in after a data abort
>> > > > enters the kernel but before the resulting SIGSEGV is dequeued for
>> > > > delivery, wouldn't we deliver SIGINT first, with the bogus fault code?
>> > > > With your change we'd then have cleared the fault code by the time we
>> > > > deliver the SIGSEGV it actually relates to, if I've understood right.
>> > > >
>> > > > Today, I think we just attach that fault code to every signal that's
>> > > > delivered until something overwrites or resets it, which means that
>> > > > a signal that needs fault_code gets it, at the expense of attaching
>> > > > it to a bunch of other random signals too.
>> > > >
>> > > >
>> > > > Checking the signal number and si_code might help us to know what we
>> > > > should be doing with fault_code. We need to have sure userspace can't
>> > > > trick us with a non kernel generated signal here. It would also be
>> > > > necessary to check how PTRACE_SETSIGINFO interacts with this.
>> > >
>> > > With these possible interactions in mind I think we should store the
>> > > fault code and fault address in kernel_siginfo instead of
>> > > thread_struct (and clear these fields when we receive a siginfo from
>> > > userspace, i.e. in copy_siginfo_from_user which is used by
>> > > ptrace(PTRACE_SETSIGINFO) among other places). That way, the
>> > > information is clearly associated with the signal itself and not the
>> > > thread, so we don't need to worry about our signal being delivered out
>> > > of order.
>> >
>> > Hmm, I can't see a way to do that that isn't horribly invasive in the core
>> > signal code. Can you?
>
> I think I've come up with a way that doesn't seem to be too invasive.
> See patch #1 of the series that I'm about to send out.
>
>> > But generally, I agree: the per-thread handling of fault_address and
>> > fault_code appears to be quite broken in the face of signal prioritisation
>> > and signals that don't correspond directly to hardware trap. It would be
>> > nice to have some tests for this...
>> >
>> > If we want to pile on more bodges, perhaps we could stash the signal number
>> > to which the fault_{address,code} relate, and then check that at delivery
>> > and clear on a match. I hate it.
>>
>> I agree with Daniel's suggestion in principle, but I was also concerned
>> about whether it would be too invasive elsewhere.
>>
>> Question though: does the core code take special care to make sure that
>> a force_sig cannot be outprioritised by a regular signal? If so,
>> perhaps we get away with it. I ask this, because the same same issue
>> may be hitting other arches otherwise.
>
> Not as far as I can tell. There does appear to be prioritisation for
> synchronous signals [1] but as far as I can tell nothing to
> distinguish one of these signals from one with the same signal number
> sent from userspace (e.g. via kill(2)).
The si_code will differ between signals generated between userspace
and signals generated by the kernel.
We do allow a little bit of ptrace and sending to yourself to spoof
kernel generated signals, for reasons of debugging and process migration
where an existing process needs to be reconstructed. But the defenses
should be strong enough you can assume that we reliably distinguish
between a signal from userspace and a signal from the kernel.
I don't fully follow what you are doing but this feels like the
kind of case where a new si_code has been defined as well as additional
fields in siginfo.
In your patchset I really hate that you were going back to
force_sig_info, and filling out struct siginfo by hand. That is an
error prone pattern, and I have fixed enough bugs in the kernel to prove
that.
I take exception to the idea that including the full address might break
userspace. That means typically means someone has been too lazy to look
and see what userspace is doing. When that userspace that might break
is the same userspace you are changing the kernel to serve that makes me
nervous. AKA the userspace that cares about this signal and how it is
represented in siginfo.
A fix of one instance of SIGILL should not be included with a patch that
does something else, and really should come before everything else if
possible.
If this information really belongs in struct siginfo (as it sounds like)
please actually put the information in siginfo, and let userspace look
in siginfo to find it. struct siginfo is a union with plenty of space,
and plenty of si_codes.
If this applies to multiple cases then it might be trickier but please
dig into the details, don't toss things into sigcontext just because
you can't figure out a clean design for reporting this.
Eric
> Peter
>
> [1] https://github.com/torvalds/linux/blob/b85051e755b0e9d6dd8f17ef1da083851b83287d/kernel/signal.c#L222
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: mt8183: Add gce setting in display node
From: Matthias Brugger @ 2020-05-21 12:38 UTC (permalink / raw)
To: Bibby Hsieh
Cc: drinkcat, Yongqiang Niu, srv_heupstream, David Airlie,
Daniel Vetter, linux-kernel, dri-devel, tfiga, CK Hu,
Thierry Reding, linux-mediatek, Philipp Zabel, YT Shen,
linux-arm-kernel
In-Reply-To: <1590058033.29894.2.camel@mtksdaap41>
On 21/05/2020 12:47, Bibby Hsieh wrote:
> On Thu, 2020-05-21 at 12:10 +0200, Matthias Brugger wrote:
>> On 14/02/2020 11:06, Matthias Brugger wrote:
>>>
>>>
>>> On 14/02/2020 05:49, Bibby Hsieh wrote:
>>>> In order to use GCE function, we need add some information
>>>> into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
>>>>
>>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>>>> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
>>>> ---
>>>
>>> For the next time please provide some context on which patches this are based
>>> on. Bet below the '---' with a link.
>>>
>>> For this time, on which patch/series is this based? :)
>>
>> Bibby can you please help and rebase the patch against my for-next branch [1].
>> I'm then happy to queue it. Not sure if we can make it for v5.8 as we are really
>> late, but we could try :)
>
> Hi, Matthias,
>
> NP, but this patch[1] is depends on another patch [2].
> Should I rebase them together into your for-next branch?
>
I see and [2] one depends on the scpsys driver.
Then maybe better wait until we have the scpsys driver accepted.
Regards,
Matthias
> [1] https://patchwork.kernel.org/patch/11385863/
> [2] https://patchwork.kernel.org/patch/11316277/
>
> Bibby
>
>>
>> Thanks!
>> Matthias
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next
>>
>>>
>>> Thanks,
>>> Matthias
>>>
>>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16 ++++++++++++++++
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>>> index be4428c92f35..8b522b039a37 100644
>>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>>> @@ -9,6 +9,7 @@
>>>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> #include <dt-bindings/interrupt-controller/irq.h>
>>>> #include <dt-bindings/power/mt8183-power.h>
>>>> +#include <dt-bindings/gce/mt8183-gce.h>
>>>> #include "mt8183-pinfunc.h"
>>>>
>>>> / {
>>>> @@ -664,6 +665,9 @@
>>>> reg = <0 0x14000000 0 0x1000>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> #clock-cells = <1>;
>>>> + mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST>,
>>>> + <&gce 1 CMDQ_THR_PRIO_HIGHEST>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
>>>> };
>>>>
>>>> ovl0: ovl@14008000 {
>>>> @@ -672,6 +676,7 @@
>>>> interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_OVL0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x8000 0x1000>;
>>>> };
>>>>
>>>> ovl_2l0: ovl@14009000 {
>>>> @@ -680,6 +685,7 @@
>>>> interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>;
>>>> };
>>>>
>>>> ovl_2l1: ovl@1400a000 {
>>>> @@ -688,6 +694,7 @@
>>>> interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xa000 0x1000>;
>>>> };
>>>>
>>>> rdma0: rdma@1400b000 {
>>>> @@ -697,6 +704,7 @@
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_RDMA0>;
>>>> mediatek,rdma_fifo_size = <5120>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xb000 0x1000>;
>>>> };
>>>>
>>>> rdma1: rdma@1400c000 {
>>>> @@ -706,6 +714,7 @@
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_RDMA1>;
>>>> mediatek,rdma_fifo_size = <2048>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>;
>>>> };
>>>>
>>>> color0: color@1400e000 {
>>>> @@ -715,6 +724,7 @@
>>>> interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_COLOR0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>;
>>>> };
>>>>
>>>> ccorr0: ccorr@1400f000 {
>>>> @@ -723,6 +733,7 @@
>>>> interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_CCORR0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>;
>>>> };
>>>>
>>>> aal0: aal@14010000 {
>>>> @@ -732,6 +743,7 @@
>>>> interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_AAL0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0 0x1000>;
>>>> };
>>>>
>>>> gamma0: gamma@14011000 {
>>>> @@ -741,6 +753,7 @@
>>>> interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>;
>>>> };
>>>>
>>>> dither0: dither@14012000 {
>>>> @@ -749,6 +762,7 @@
>>>> interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> clocks = <&mmsys CLK_MM_DISP_DITHER0>;
>>>> + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>;
>>>> };
>>>>
>>>> mutex: mutex@14016000 {
>>>> @@ -756,6 +770,8 @@
>>>> reg = <0 0x14016000 0 0x1000>;
>>>> interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
>>>> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
>>>> + mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
>>>> + <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
>>>> };
>>>>
>>>> smi_common: smi@14019000 {
>>>>
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] arm64: perf: Add support for Perf NMI interrupts
From: Alexandru Elisei @ 2020-05-21 12:36 UTC (permalink / raw)
To: Song Bao Hua (Barry Song), Mark Rutland, Lecopzer Chen
Cc: Sumit Garg, Jian-Lin Chen, Will Deacon,
alexander.shishkin@linux.intel.com, Catalin Marinas,
yj.chiang@mediatek.com, Linux Kernel Mailing List,
acme@kernel.org, Linuxarm, Peter Zijlstra, mingo@redhat.com,
linux-mediatek@lists.infradead.org, linux-arm-kernel,
matthias.bgg@gmail.com, namhyung@kernel.org, jolsa@redhat.com,
julien.thierry.kdev@gmail.com
In-Reply-To: <B926444035E5E2439431908E3842AFD24B2728@DGGEMI525-MBS.china.huawei.com>
Hi,
On 5/21/20 4:00 AM, Song Bao Hua (Barry Song) wrote:
>
>> -----Original Message-----
>> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infradead.org]
>> On Behalf Of Alexandru Elisei
>> Sent: Wednesday, May 20, 2020 10:31 PM>
>> Hi,
>>
>> On 5/18/20 12:17 PM, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On 5/18/20 11:45 AM, Mark Rutland wrote:
>>>> Hi all,
>>>>
>>>> On Mon, May 18, 2020 at 02:26:00PM +0800, Lecopzer Chen wrote:
>>>>> HI Sumit,
>>>>>
>>>>> Thanks for your information.
>>>>>
>>>>> I've already implemented IPI (same as you did [1], little difference
>>>>> in detail), hardlockup detector and perf in last year(2019) for
>>>>> debuggability.
>>>>> And now we tend to upstream to reduce kernel maintaining effort.
>>>>> I'm glad if someone in ARM can do this work :)
>>>>>
>>>>> Hi Julien,
>>>>>
>>>>> Does any Arm maintainers can proceed this action?
>>>> Alexandru (Cc'd) has been rebasing and reworking Julien's patches,
>>>> which is my preferred approach.
>>>>
>>>> I understand that's not quite ready for posting since he's
>>>> investigating some of the nastier subtleties (e.g. mutual exclusion
>>>> with the NMI), but maybe we can put the work-in-progress patches
>>>> somewhere in the mean time.
>>>>
>>>> Alexandru, do you have an idea of what needs to be done, and/or when
>>>> you expect you could post that?
>>> I'm currently working on rebasing the patches on top of 5.7-rc5, when
>>> I have something usable I'll post a link (should be a couple of days).
>>> After that I will address the review comments, and I plan to do a
>>> thorough testing because I'm not 100% confident that some of the
>>> assumptions around the locks that were removed are correct. My guess is
>> this will take a few weeks.
>>
>> Pushed a WIP branch on linux-arm.org [1]:
>>
>> git clone -b WIP-pmu-nmi git://linux-arm.org/linux-ae
>>
>> Practically untested, I only did perf record on a defconfig kernel running on the
>> model.
>>
>> [1]
>> http://www.linux-arm.org/git?p=linux-ae.git;a=shortlog;h=refs/heads/WIP-pm
>> u-nmi
> Fortunately, it does work. I used this tree to perf annotate arm_smmu_cmdq_issue_cmdlist() which
> is completely disabling IRQ. Luckily, it reports correct data. Before that, it reported all time was spent by
> the code which enabled IRQ .
That's good news that it works for you, thanks for letting me know.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-21 12:33 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521120308.GR1551@shell.armlinux.org.uk>
On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> > (resendig for the correct address and with mailing list cc'ed, sorry for
> > the noise)
> >
> > Hi,
> >
> > Following the discussion at [1], I'm resending the patches that enable
> > memory model selection in menuconfig and such.
> >
> > These patches do not change the way the configuration is generated from the
> > defconfigs and they do not change explicit selection of SPARSEMEM for
> > platforms that have "select ARCH_ENABLE_SPARSEMEM".
> >
> > The mere change is that when a user runs an interactive configuration they
> > will be allowed to select between FLATMEM and SPARSMEM, which is not the
> > case today.
> >
> > There is indeed some awkwardness in, e.g. removal of
> > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> > mm/Kconfig imposes.
> >
> > For example, below is the diffs of the configurations generated with
> > 'make rpc_defconfig' and 'make defconfig':
> >
> > $ diff -s old/rpc_defconfig new/rpc_defconfig
> > Files old/rpc_defconfig and new/rpc_defconfig are identical
> >
> > $ diff -u old/defconfig new/defconfig
> > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300
> > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300
> > @@ -674,6 +674,9 @@
> > CONFIG_AEABI=y
> > # CONFIG_OABI_COMPAT is not set
> > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > +CONFIG_ARCH_FLATMEM_ENABLE=y
> > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > CONFIG_HAVE_ARCH_PFN_VALID=y
> > CONFIG_HIGHMEM=y
> > CONFIG_HIGHPTE=y
> > @@ -1061,6 +1064,9 @@
> > #
> > # Memory Management options
> > #
> > +CONFIG_SELECT_MEMORY_MODEL=y
> > +CONFIG_FLATMEM_MANUAL=y
> > +# CONFIG_SPARSEMEM_MANUAL is not set
> > CONFIG_FLATMEM=y
> > CONFIG_FLAT_NODE_MEM_MAP=y
> > CONFIG_ARCH_KEEP_MEMBLOCK=y
>
> Right, but the question is whether we want to offer flatmem for rpc.
> It isn't allowed today, and so far no one has said why it's a
> desirable change to make.
With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter)
ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being
enabled and since any of these machines explicitly selects
ARCH_SPARSEMEM_ENABLE, the only available memory model would be
SPARSEMEM.
I played a bit with menuconfig and if any of the platforms requiring
sparsemem is selected, the menu allowing the user to choose the memory
model disappears.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] arm64: dts: rockchip: fix dmas dma-names for rk3308 i2s node
From: Johan Jonker @ 2020-05-21 12:28 UTC (permalink / raw)
To: Robin Murphy, heiko
Cc: devicetree, kever.yang, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel, wxt
In-Reply-To: <543270ad-dd11-2bd4-8959-e898834c19e5@arm.com>
Hi Robin, Kever, Caesar,
On 5/21/20 1:48 PM, Robin Murphy wrote:
> On 2020-05-20 07:48, Johan Jonker wrote:
>> One of the current rk3308 'i2s' nodes has a different dma layout
>> with only 1 item. Table 9-2 DMAC1 Request Mapping Table shows that
>> there 2 dma sources available, so fix the dmas and dma-names
>> for the rk3308 'i2s' node.
>>
>> 10 I2S/PCM_2CH_1 tx High level
>> 11 I2S/PCM_2CH_1 rx High level
>
> ...however table 1-5 in the same manual (at least that I could find)
> says request 10 is reserved. Does that mean it was intended to be wired
> up for this, but ended up broken for some reason?
>
> Do you have hardware to confirm whether this works reliably or not?
No, I don't.
A description for 3308 was added to rockchip-i2s.yaml with only rx by
myself.
It would be nice if someone could test, confirm or give a hint.
Could someone from Rockchip(Kever, Caesar) explain the 'Reserved' in
Table 1-5 ?
Table 1-5 RK3308 DMAC1 hardware request connection list
10 Reserved High level
11 I2S_2CH_1 rx High level
>
> Robin.
>
>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3308.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
>> index ac7f69407..79c1dd1fe 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
>> @@ -564,8 +564,8 @@
>> interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cru SCLK_I2S1_2CH>, <&cru HCLK_I2S1_2CH>;
>> clock-names = "i2s_clk", "i2s_hclk";
>> - dmas = <&dmac1 11>;
>> - dma-names = "rx";
>> + dmas = <&dmac1 10>, <&dmac1 11>;
>> + dma-names = "tx", "rx";
>> resets = <&cru SRST_I2S1_2CH_M>, <&cru SRST_I2S1_2CH_H>;
>> reset-names = "reset-m", "reset-h";
>> status = "disabled";
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/4] PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits" property
From: Kishon Vijay Abraham I @ 2020-05-21 12:13 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Lorenzo Pieralisi, PCI, linux-kernel@vger.kernel.org,
Tom Joseph, Bjorn Helgaas, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <162447e2-ac3b-9523-d404-130b93e0860e@ti.com>
Rob,
On 5/21/2020 9:00 AM, Kishon Vijay Abraham I wrote:
> Hi Rob,
>
> On 5/19/2020 10:41 PM, Rob Herring wrote:
>> On Fri, May 8, 2020 at 7:07 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>
>>> Cadence PCIe core driver (host mode) uses "cdns,no-bar-match-nbits"
>>> property to configure the number of bits passed through from PCIe
>>> address to internal address in Inbound Address Translation register.
>>> This only used the NO MATCH BAR.
>>>
>>> However standard PCI dt-binding already defines "dma-ranges" to
>>> describe the address ranges accessible by PCIe controller. Add support
>>> in Cadence PCIe host driver to parse dma-ranges and configure the
>>> inbound regions for BAR0, BAR1 and NO MATCH BAR. Cadence IP specifies
>>> maximum size for BAR0 as 256GB, maximum size for BAR1 as 2 GB, so if
>>> the dma-ranges specifies a size larger than the maximum allowed, the
>>> driver will split and configure the BARs.
>>
>> Would be useful to know what your dma-ranges contains now.
>>
>>
>>> Legacy device tree binding compatibility is maintained by retaining
>>> support for "cdns,no-bar-match-nbits".
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> .../controller/cadence/pcie-cadence-host.c | 141 ++++++++++++++++--
>>> drivers/pci/controller/cadence/pcie-cadence.h | 17 ++-
>>> 2 files changed, 141 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> index 6ecebb79057a..2485ecd8434d 100644
>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
>>> @@ -11,6 +11,12 @@
>>>
>>> #include "pcie-cadence.h"
>>>
>>> +static u64 cdns_rp_bar_max_size[] = {
>>> + [RP_BAR0] = _ULL(128 * SZ_2G),
>>> + [RP_BAR1] = SZ_2G,
>>> + [RP_NO_BAR] = SZ_64T,
>>> +};
>>> +
>>> void __iomem *cdns_pci_map_bus(struct pci_bus *bus, unsigned int devfn,
>>> int where)
>>> {
>>> @@ -106,6 +112,117 @@ static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)
>>> return 0;
>>> }
>>>
>>> +static void cdns_pcie_host_bar_ib_config(struct cdns_pcie_rc *rc,
>>> + enum cdns_pcie_rp_bar bar,
>>> + u64 cpu_addr, u32 aperture)
>>> +{
>>> + struct cdns_pcie *pcie = &rc->pcie;
>>> + u32 addr0, addr1;
>>> +
>>> + addr0 = CDNS_PCIE_AT_IB_RP_BAR_ADDR0_NBITS(aperture) |
>>> + (lower_32_bits(cpu_addr) & GENMASK(31, 8));
>>> + addr1 = upper_32_bits(cpu_addr);
>>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR0(bar), addr0);
>>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR1(bar), addr1);
>>> +}
>>> +
>>> +static int cdns_pcie_host_bar_config(struct cdns_pcie_rc *rc,
>>> + struct resource_entry *entry,
>>> + enum cdns_pcie_rp_bar *index)
>>> +{
>>> + u64 cpu_addr, pci_addr, size, winsize;
>>> + struct cdns_pcie *pcie = &rc->pcie;
>>> + struct device *dev = pcie->dev;
>>> + enum cdns_pcie_rp_bar bar;
>>> + unsigned long flags;
>>> + u32 aperture;
>>> + u32 value;
>>> +
>>> + cpu_addr = entry->res->start;
>>> + flags = entry->res->flags;
>>> + pci_addr = entry->res->start - entry->offset;
>>> + size = resource_size(entry->res);
>>> + bar = *index;
>>> +
>>> + if (entry->offset) {
>>> + dev_err(dev, "Cannot map PCI addr: %llx to CPU addr: %llx\n",
>>> + pci_addr, cpu_addr);
>>
>> Would be a bit more clear to say PCI addr must equal CPU addr.
>>
>>> + return -EINVAL;
>>> + }
>>> +
>>> + value = cdns_pcie_readl(pcie, CDNS_PCIE_LM_RC_BAR_CFG);
>>> + while (size > 0) {
>>> + if (bar > RP_NO_BAR) {
>>> + dev_err(dev, "Failed to map inbound regions!\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + winsize = size;
>>> + if (size > cdns_rp_bar_max_size[bar])
>>> + winsize = cdns_rp_bar_max_size[bar];
>>> +
>>> + aperture = ilog2(winsize);
>>> +
>>> + cdns_pcie_host_bar_ib_config(rc, bar, cpu_addr, aperture);
>>> +
>>> + if (bar == RP_NO_BAR)
>>> + break;
>>> +
>>> + if (winsize + cpu_addr >= SZ_4G) {
>>> + if (!(flags & IORESOURCE_PREFETCH))
>>> + value |= LM_RC_BAR_CFG_CTRL_MEM_64BITS(bar);
>>> + value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_64BITS(bar);
>>> + } else {
>>> + if (!(flags & IORESOURCE_PREFETCH))
>>> + value |= LM_RC_BAR_CFG_CTRL_MEM_32BITS(bar);
>>> + value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_32BITS(bar);
>>> + }
>>> +
>>> + value |= LM_RC_BAR_CFG_APERTURE(bar, aperture);
>>> +
>>> + size -= winsize;
>>> + cpu_addr += winsize;
>>> + bar++;
>>> + }
>>> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_RC_BAR_CFG, value);
>>> + *index = bar;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int cdns_pcie_host_map_dma_ranges(struct cdns_pcie_rc *rc)
>>> +{
>>> + enum cdns_pcie_rp_bar bar = RP_BAR0;
>>> + struct cdns_pcie *pcie = &rc->pcie;
>>> + struct device *dev = pcie->dev;
>>> + struct device_node *np = dev->of_node;
>>> + struct pci_host_bridge *bridge;
>>> + struct resource_entry *entry;
>>> + u32 no_bar_nbits = 32;
>>> + int err;
>>> +
>>> + bridge = pci_host_bridge_from_priv(rc);
>>> + if (!bridge)
>>> + return -ENOMEM;
>>> +
>>> + if (list_empty(&bridge->dma_ranges)) {
>>> + of_property_read_u32(np, "cdns,no-bar-match-nbits",
>>> + &no_bar_nbits);
>>> + cdns_pcie_host_bar_ib_config(rc, RP_NO_BAR, 0x0, no_bar_nbits);
>>> + return 0;
>>> + }
>>> +
>>> + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
>>> + err = cdns_pcie_host_bar_config(rc, entry, &bar);
>>
>> Seems like this should have some better logic to pick which BAR to
>> use. Something like find the biggest region and then find the smallest
>> BAR that it fits in. Then get the next biggest...
>
> Okay, I'll change this something like for each region, find the smallest BAR
> that it fits in and if there is no BAR big enough to hold the region, split the
> region to see if can be fitted using multiple BARs. I don't see the purpose of
> finding the biggest region first since at all times we'll only use the smallest
> BAR to fit.
Nevermind, I realized finding the biggest region is useful. I have sent a patch
adding support for that.
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Russell King - ARM Linux admin @ 2020-05-21 12:03 UTC (permalink / raw)
To: Mike Rapoport
Cc: Florian Fainelli, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Doug Berger, Gregory Fong, linux-arm-kernel
In-Reply-To: <20200521081825.1348844-1-rppt@linux.ibm.com>
On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote:
> (resendig for the correct address and with mailing list cc'ed, sorry for
> the noise)
>
> Hi,
>
> Following the discussion at [1], I'm resending the patches that enable
> memory model selection in menuconfig and such.
>
> These patches do not change the way the configuration is generated from the
> defconfigs and they do not change explicit selection of SPARSEMEM for
> platforms that have "select ARCH_ENABLE_SPARSEMEM".
>
> The mere change is that when a user runs an interactive configuration they
> will be allowed to select between FLATMEM and SPARSMEM, which is not the
> case today.
>
> There is indeed some awkwardness in, e.g. removal of
> ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in
> mm/Kconfig imposes.
>
> For example, below is the diffs of the configurations generated with
> 'make rpc_defconfig' and 'make defconfig':
>
> $ diff -s old/rpc_defconfig new/rpc_defconfig
> Files old/rpc_defconfig and new/rpc_defconfig are identical
>
> $ diff -u old/defconfig new/defconfig
> --- old/defconfig 2020-05-20 17:51:01.832649705 +0300
> +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300
> @@ -674,6 +674,9 @@
> CONFIG_AEABI=y
> # CONFIG_OABI_COMPAT is not set
> CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> +CONFIG_ARCH_FLATMEM_ENABLE=y
> +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_HAVE_ARCH_PFN_VALID=y
> CONFIG_HIGHMEM=y
> CONFIG_HIGHPTE=y
> @@ -1061,6 +1064,9 @@
> #
> # Memory Management options
> #
> +CONFIG_SELECT_MEMORY_MODEL=y
> +CONFIG_FLATMEM_MANUAL=y
> +# CONFIG_SPARSEMEM_MANUAL is not set
> CONFIG_FLATMEM=y
> CONFIG_FLAT_NODE_MEM_MAP=y
> CONFIG_ARCH_KEEP_MEMBLOCK=y
Right, but the question is whether we want to offer flatmem for rpc.
It isn't allowed today, and so far no one has said why it's a
desirable change to make.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox