* Re: [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Wolfram Sang @ 2019-09-24 18:57 UTC (permalink / raw)
To: Ray Jui
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
Shivaraj Shetty, Rayagonda Kokatanur, linux-kernel, Icarus Chau,
Rob Herring, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <5ab79d0e-eb54-8fe1-1ca3-e763a17c6426@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 435 bytes --]
> In my opinion, it's probably better to continue to support master_xfer in
> our driver (with obvious limitations), in order to allow i2ctransfer (or any
> apps that use I2C RDWR) to continue to work.
>
> What do you think?
Yes, don't break it for users. We should have paid more attention to it
in the beginning. But, while not ideal, it is not such a big deal to
keep it like this.
Thanks for your investigations!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 4/5] dt-bindings: display: imx: add bindings for DCSS
From: Rob Herring @ 2019-09-24 18:53 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: devicetree, Philipp Zabel, Shawn Guo, Sascha Hauer,
linux-kernel@vger.kernel.org, dri-devel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, Guido Günther,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Lucas Stach
In-Reply-To: <1569248002-2485-5-git-send-email-laurentiu.palcu@nxp.com>
On Mon, Sep 23, 2019 at 9:14 AM Laurentiu Palcu <laurentiu.palcu@nxp.com> wrote:
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
> ---
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 86 ++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
Fails to build with 'make dt_binding_check':
https://patchwork.ozlabs.org/patch/1166073/
_______________________________________________
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 v1] firmware: meson_sm: use %*ph to print small buffer
From: Kevin Hilman @ 2019-09-24 18:48 UTC (permalink / raw)
To: Andy Shevchenko, Neil Armstrong, linux-arm-kernel, linux-amlogic
Cc: Andy Shevchenko
In-Reply-To: <20190904174835.77370-1-andriy.shevchenko@linux.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> Use %*ph format to print small buffer as hex string.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Queued for v5.5,
Thanks,
Kevin
_______________________________________________
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 v2 0/4] Rework secure-monitor driver
From: Kevin Hilman @ 2019-09-24 18:45 UTC (permalink / raw)
To: Carlo Caione, srinivas.kandagatla, narmstrong, robh+dt, tglx,
jbrunet, linux-arm-kernel, linux-amlogic, devicetree
Cc: Carlo Caione
In-Reply-To: <20190731082339.20163-1-ccaione@baylibre.com>
Carlo Caione <ccaione@baylibre.com> writes:
> The secure-monitor driver is currently in really bad shape, not my
> proudest piece of code (thanks Jerome for pointing that out ;). I tried
> to rework it a bit to make it a bit more tolerable.
>
> I needed to change a bit the APIs and consequently adapt the only user
> we have, that is the nvmem/efuses driver. To not break bisectability I
> added one single commit to change both the drivers.
>
> The remaining commits are cosmetic and DTS/docs fixes.
>
> Changelog:
> - Changed patches order to not break bisect
> - Removed non-functional changes (PATCH 1/5) of the nvmem driver
> - Fix gxbb/gxl DTS
>
> Carlo Caione (4):
> firmware: meson_sm: Mark chip struct as static const
> nvmem: meson-efuse: bindings: Add secure-monitor phandle
> arm64: dts: meson: Link nvmem and secure-monitor nodes
> firmware: meson_sm: Rework driver as a proper platform driver
Queued for v5.5,
Thanks,
Kevin
_______________________________________________
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/11] of: simplify of_dma_config()'s arguments
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci,
Greg Kroah-Hartman, Rafael J. Wysocki, Rafał Miłecki,
Sinan Kaya, Andy Gross, Lucas Stach, Russell King,
Christian Gmeiner, Maxime Ripard, Chen-Yu Tsai,
Oleksandr Andrushchenko, Thierry Reding, Stanimir Varbanov,
Kyungmin Park, Kamil Debski, Jeongtae Park, Andrzej Hajda,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini
Cc: freedreno, f.fainelli, Daniel Vetter, David Airlie, Sean Paul,
Rob Clark, Vinod Koul, mbrugger, wahrenst, james.quinlan,
Dan Williams, Mauro Carvalho Chehab, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
The widespread use case for of_dma_config() highlights a redundant
argument. Most callers provide both 'dev' and 'dev->of_node'. The rest
of users use it to copy some device's DMA configuration into a device
not represented in DT.
In order to simplify the common use case, and make code a little more
explicit, create of_dma_config_copy() which will take another device's
DT node as an argument and simplify of_dma_config() by removing one of
it's redundant arguments.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/base/platform.c | 2 +-
drivers/bcma/main.c | 2 +-
drivers/dma/qcom/hidma_mgmt.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
drivers/gpu/host1x/bus.c | 2 +-
drivers/media/platform/qcom/venus/firmware.c | 2 +-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 +-
drivers/of/device.c | 30 ++++++++++++++++++--
drivers/xen/gntdev.c | 2 +-
include/linux/of_device.h | 12 ++++++--
13 files changed, 48 insertions(+), 16 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b6c6c7d97d5b..4e252028aee9 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1221,7 +1221,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
if (dev->of_node) {
- ret = of_dma_configure(dev, dev->of_node, true);
+ ret = of_dma_configure(dev, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
ret = acpi_dma_configure(dev, attr);
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 6535614a7dc1..4c7e8b35525c 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
core->irq = bcma_of_get_irq(parent, core, 0);
- of_dma_configure(&core->dev, node, false);
+ of_dma_configure(&core->dev, false);
}
unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 806ca02c52d7..4ea901537902 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -388,7 +388,7 @@ static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
goto out;
}
new_pdev->dev.of_node = child;
- of_dma_configure(&new_pdev->dev, child, true);
+ of_dma_configure(&new_pdev->dev, true);
/*
* It is assumed that calling of_msi_configure is safe on
* platforms with or without MSI support.
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 1f9c01be40d7..1375f41593ef 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -706,7 +706,7 @@ static int __init etnaviv_init(void)
* device as the GPU we found. This assumes that all Vivante
* GPUs in the system share the same DMA constraints.
*/
- of_dma_configure(&pdev->dev, np, true);
+ of_dma_configure_copy(&pdev->dev, np, true);
ret = platform_device_add(pdev);
if (ret) {
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 85f14feafdec..825fcdc72bd9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1268,7 +1268,7 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
gmu->dev = &pdev->dev;
- of_dma_configure(gmu->dev, node, true);
+ of_dma_configure(gmu->dev, true);
/* Fow now, don't do anything fancy until we get our feet under us */
gmu->idle_level = GMU_IDLE_STATE_ACTIVE;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4e29f4fe4a05..97dd5d31e38d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -802,7 +802,7 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
* for us, and DRM doesn't do per-device allocation either, so
* we would need to fix DRM first...
*/
- ret = of_dma_configure(drm->dev, dev->of_node, true);
+ ret = of_dma_configure_copy(drm->dev, dev->of_node, true);
if (ret)
return ret;
} else {
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b/drivers/gpu/drm/xen/xen_drm_front.c
index ba1828acd8c9..fa0bfd6517fa 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -726,7 +726,7 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
* node to set default DMA ops.
*/
dev->coherent_dma_mask = DMA_BIT_MASK(32);
- ret = of_dma_configure(dev, NULL, true);
+ ret = of_dma_configure(dev, true);
if (ret < 0) {
DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
return ret;
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 2fdc04383a60..4eb531906e4a 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -337,7 +337,7 @@ static int host1x_device_uevent(struct device *dev,
static int host1x_dma_configure(struct device *dev)
{
- return of_dma_configure(dev, dev->of_node, true);
+ return of_dma_configure(dev, true);
}
static const struct dev_pm_ops host1x_device_pm_ops = {
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index d3d1748a7ef6..82f433218d99 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -238,7 +238,7 @@ int venus_firmware_init(struct venus_core *core)
pdev->dev.of_node = np;
- ret = of_dma_configure(&pdev->dev, np, true);
+ ret = of_dma_configure(&pdev->dev, true);
if (ret) {
dev_err(core->dev, "dma configure fail\n");
goto err_unregister;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index b776f83e395e..ad33e7a655aa 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1095,7 +1095,7 @@ static struct device *s5p_mfc_alloc_memdev(struct device *dev,
* to be treated as valid DMA masters we need a bit of a hack to force
* them to inherit the MFC node's DMA configuration.
*/
- of_dma_configure(child, dev->of_node, true);
+ of_dma_configure_copy(child, dev->of_node, true);
if (device_add(child) == 0) {
ret = of_reserved_mem_device_init_by_idx(child, dev->of_node,
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1d0b1127d05e..66726a2499d3 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -75,19 +75,18 @@ int of_device_add(struct platform_device *ofdev)
/**
* of_dma_configure - Setup DMA configuration
* @dev: Device to apply DMA configuration
- * @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.
*
* Try to get devices's DMA configuration from DT and update it
* accordingly.
*/
-int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
+int of_dma_configure(struct device *dev, bool force_dma)
{
struct device_node *dma_parent;
int ret;
- dma_parent = __of_get_dma_parent(np);
+ dma_parent = __of_get_dma_parent(dev->of_node);
ret = of_dma_configure_parent(dev, dma_parent, force_dma);
of_node_put(dma_parent);
@@ -95,6 +94,31 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
}
EXPORT_SYMBOL_GPL(of_dma_configure);
+/**
+ * of_dma_configure_copy - Setup DMA configuration based on another device's DT
+ * node
+ * @dev: Device to apply DMA configuration
+ * @np: Device node to copy the configuration from
+ * @force_dma: Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described by firmware.
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ */
+int of_dma_configure_copy(struct device *dev, struct device_node *np,
+ bool force_dma)
+{
+ struct device_node *dma_parent;
+ int ret;
+
+ dma_parent = __of_get_dma_parent(np);
+ ret = of_dma_configure_parent(dev, dma_parent, force_dma);
+ of_node_put(dma_parent);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_configure_copy);
+
/**
* of_dma_configure_parent - Setup DMA configuration based on a parent bus'
* DT node
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a446a7221e13..115e39f9f67a 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -632,7 +632,7 @@ static int gntdev_open(struct inode *inode, struct file *flip)
* Fix this by calling of_dma_configure() with a NULL node to set
* default DMA ops.
*/
- of_dma_configure(priv->dma_dev, NULL, true);
+ of_dma_configure(priv->dma_dev, true);
#endif
pr_debug("priv %p\n", priv);
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 8f319b8c9deb..b05a86fd35a4 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,7 +55,9 @@ 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, struct devce_node *np, bool force_dma);
+int of_dma_configure(struct device *dev, bool force_dma);
+int of_dma_configure_copy(struct device *dev, struct device_node *np,
+ bool force_dma);
int of_dma_configure_parent(struct device *dev, struct device_node *parent,
bool force_dma);
#else /* CONFIG_OF */
@@ -107,12 +109,18 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
}
static inline int of_dma_configure(struct device *dev,
- struct device_node *np,
bool force_dma)
{
return 0;
}
+static inline int of_dma_configure_copy(struct device *dev,
+ struct device_node *np,
+ bool force_dma)
+{
+ return 0;
+}
+
static inline int of_dma_configure_parent(struct device *dev,
struct device_node *parent,
bool force_dma)
--
2.23.0
_______________________________________________
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/11] of: device: introduce of_dma_configure_parent()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci,
Stuart Yoder, Laurentiu Tudor, Thierry Reding, Bjorn Helgaas
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
Devices not represented in DT, placed behind a bus that autodetects
them, pass of_dma_configure() their bus' DT node. This misses that bus'
'dma-ranges' property as the function's implementation expects the DT
node to be one of a device.
Create of_dma_configure_parent() which takes the given DT node as the
device's underlying bus and parses it accordingly.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +-
drivers/gpu/host1x/bus.c | 2 +-
drivers/of/device.c | 30 ++++++++++++++++++++++++++++--
drivers/pci/pci-driver.c | 3 ++-
include/linux/of_device.h | 13 ++++++++++---
5 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5c9bf2e06552..217e64119497 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -134,7 +134,7 @@ 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(dev, dma_dev->of_node, 0);
+ return of_dma_configure_parent(dev, dma_dev->of_node, false);
}
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 742aa9ff21b8..2fdc04383a60 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -442,7 +442,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = &host1x_bus_type;
device->dev.parent = host1x->dev;
- of_dma_configure(&device->dev, host1x->dev->of_node, true);
+ of_dma_configure_parent(&device->dev, host1x->dev->of_node, true);
device->dev.dma_parms = &device->dma_parms;
dma_set_max_seg_size(&device->dev, SZ_4M);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 018c52688546..1d0b1127d05e 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -83,6 +83,31 @@ int of_device_add(struct platform_device *ofdev)
* accordingly.
*/
int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
+{
+ struct device_node *dma_parent;
+ int ret;
+
+ dma_parent = __of_get_dma_parent(np);
+ ret = of_dma_configure_parent(dev, dma_parent, force_dma);
+ of_node_put(dma_parent);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_configure);
+
+/**
+ * of_dma_configure_parent - Setup DMA configuration based on a parent bus'
+ * DT node
+ * @dev: Device to apply DMA configuration
+ * @parent: Parent bus device node
+ * @force_dma: Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described by firmware.
+ *
+ * Try to get devices's DMA configuration from parent bus' DT and update it
+ * accordingly.
+ */
+int of_dma_configure_parent(struct device *dev, struct device_node *parent,
+ bool force_dma)
{
u64 dma_addr, paddr, size = 0;
int ret;
@@ -91,8 +116,9 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask;
- ret = of_dma_get_range(__of_get_dma_parent(np), &dma_addr,
- &paddr, &size);
+ dev_dbg(dev, "starting at %pOF\n", parent);
+
+ ret = of_dma_get_range(parent, &dma_addr, &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index a8124e47bf6e..25073d68a0f6 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1628,7 +1628,8 @@ static int pci_dma_configure(struct device *dev)
if (IS_ENABLED(CONFIG_OF) && bridge->parent &&
bridge->parent->of_node) {
- ret = of_dma_configure(dev, bridge->parent->of_node, true);
+ ret = of_dma_configure_parent(dev, bridge->parent->of_node,
+ true);
} else if (has_acpi_companion(bridge)) {
struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 8d31e39dd564..8f319b8c9deb 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,9 +55,9 @@ 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,
- struct device_node *np,
- bool force_dma);
+int of_dma_configure(struct device *dev, struct devce_node *np, bool force_dma);
+int of_dma_configure_parent(struct device *dev, struct device_node *parent,
+ bool force_dma);
#else /* CONFIG_OF */
static inline int of_driver_match_device(struct device *dev,
@@ -112,6 +112,13 @@ static inline int of_dma_configure(struct device *dev,
{
return 0;
}
+
+static inline int of_dma_configure_parent(struct device *dev,
+ struct device_node *parent,
+ bool force_dma)
+{
+ return 0;
+}
#endif /* CONFIG_OF */
#endif /* _LINUX_OF_DEVICE_H */
--
2.23.0
_______________________________________________
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/11] of: device: remove comment in of_dma_configure()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
It's not longer advised to use notifiers in order to setup custom DMA
ops.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/device.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 267b509df517..018c52688546 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -81,10 +81,6 @@ int of_device_add(struct platform_device *ofdev)
*
* Try to get devices's DMA configuration from DT and update it
* accordingly.
- *
- * If platform code needs to use its own special DMA configuration, it
- * 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)
{
--
2.23.0
_______________________________________________
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/11] dts: arm64: layerscape: add dma-ranges property to pcie nodes
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci,
Shawn Guo, Li Yang
Cc: Mark Rutland, f.fainelli, mbrugger, wahrenst, james.quinlan,
robin.murphy, Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
The bus behind the board's PCIe core has DMA addressing limitations. Add
an empty 'dma-ranges' property on all PCIe bus descriptions to inform
the OF core that a translation is due further down the line.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index fd6036b7865c..2c41cfc66bb9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -640,6 +640,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ dma-ranges;
num-viewport = <6>;
bus-range = <0x0 0xff>;
msi-parent = <&its>;
@@ -661,6 +662,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ dma-ranges;
num-viewport = <6>;
bus-range = <0x0 0xff>;
msi-parent = <&its>;
@@ -682,6 +684,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ dma-ranges;
num-viewport = <256>;
bus-range = <0x0 0xff>;
msi-parent = <&its>;
@@ -703,6 +706,7 @@
#size-cells = <2>;
device_type = "pci";
dma-coherent;
+ dma-ranges;
num-viewport = <6>;
bus-range = <0x0 0xff>;
msi-parent = <&its>;
--
2.23.0
_______________________________________________
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/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci,
Shawn Guo, Li Yang
Cc: Mark Rutland, f.fainelli, mbrugger, wahrenst, james.quinlan,
robin.murphy, Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
which acts a bus in this regard. So far it maked all devices as
dma-coherent but no dma-ranges recommendation is made.
The truth is that the underlying interconnect has DMA constraints, so
add an empty dma-ranges in qoriq-mc's node in order for DT's DMA
configuration code to get the DMA constraints from it.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index c676d0771762..f0d0b6145b72 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -698,6 +698,7 @@
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
iommu-map = <0 &smmu 0 0>; /* This is fixed-up by u-boot */
+ dma-ranges;
dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 7a0be8eaa84a..fd6036b7865c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -340,6 +340,7 @@
<0x00000000 0x08340000 0 0x40000>; /* MC control reg */
msi-parent = <&its>;
iommu-map = <0 &smmu 0 0>; /* This is fixed-up by u-boot */
+ dma-ranges;
dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 408e0ecdce6a..3735bb139cb2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -868,6 +868,7 @@
msi-parent = <&its>;
/* iommu-map property is fixed up by u-boot */
iommu-map = <0 &smmu 0 0>;
+ dma-ranges;
dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
--
2.23.0
_______________________________________________
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/11] of: address: use parent OF node in of_dma_get_range()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
Some devices don't have their own OF node, and are stuck passing their
bus node. Adapt the function for this use case.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/address.c | 33 +++++++++++++++------------------
drivers/of/device.c | 3 ++-
include/linux/of_address.h | 8 ++++----
3 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 53666063e938..b7b864b0ac75 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -914,30 +914,21 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device_node *parent, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
- struct device_node *node = of_node_get(np);
+ struct device_node *node = of_node_get(parent);
const __be32 *ranges = NULL;
int naddr, nsize, pna;
int ret = 0;
u64 dmaaddr;
- if (!node)
- return -EINVAL;
-
while (1) {
- struct device_node *parent;
+ struct device_node *tmp;
int len;
- naddr = of_n_addr_cells(node);
- nsize = of_n_size_cells(node);
-
- parent = __of_get_dma_parent(node);
- of_node_put(node);
-
- node = parent;
- if (!node)
- break;
+ naddr = __of_n_addr_cells_parent(node);
+ nsize = __of_n_size_cells_parent(node);
ranges = of_get_property(node, "dma-ranges", &len);
@@ -951,10 +942,16 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
*/
if (!ranges)
break;
+
+ tmp = __of_get_dma_parent(node);
+ of_node_put(node);
+ node = tmp;
+ if (!node)
+ break;
}
if (!ranges) {
- pr_debug("no dma-ranges found for node(%pOF)\n", np);
+ pr_debug("no dma-ranges found for node(%pOF)\n", node);
ret = -ENODEV;
goto out;
}
@@ -967,10 +964,10 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
* size : nsize cells
*/
dmaaddr = of_read_number(ranges, naddr);
- *paddr = of_translate_dma_address(np, ranges);
+ *paddr = of_translate_dma_address_parent(parent, ranges);
if (*paddr == OF_BAD_ADDR) {
pr_err("translation of DMA address(%pad) to CPU address failed node(%pOF)\n",
- dma_addr, np);
+ dma_addr, parent);
ret = -EINVAL;
goto out;
}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index da8158392010..267b509df517 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -95,7 +95,8 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(__of_get_dma_parent(np), &dma_addr,
+ &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 30e40fb6936b..aa1ce0cb59a1 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -55,8 +55,8 @@ extern int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
extern struct of_pci_range *of_pci_range_parser_one(
struct of_pci_range_parser *parser,
struct of_pci_range *range);
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device_node *parent, u64 *dma_addr,
+ u64 *paddr, u64 *size);
extern bool of_dma_is_coherent(struct device_node *np);
#else /* CONFIG_OF_ADDRESS */
static inline void __iomem *of_io_request_and_map(struct device_node *device,
@@ -104,8 +104,8 @@ static inline struct of_pci_range *of_pci_range_parser_one(
return NULL;
}
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size)
+static inline int of_dma_get_range(struct device_node *parent, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
return -ENODEV;
}
--
2.23.0
_______________________________________________
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/11] of: expose __of_get_dma_parent() to OF subsystem
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
The function was only available locally to of/address.c, make it
available to the OF subsystem.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/address.c | 18 ------------------
drivers/of/base.c | 25 +++++++++++++++++++++++++
drivers/of/of_private.h | 2 ++
3 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index c9eb4ebcc2e9..53666063e938 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -681,24 +681,6 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
}
EXPORT_SYMBOL(of_translate_address);
-static struct device_node *__of_get_dma_parent(const struct device_node *np)
-{
- struct of_phandle_args args;
- int ret, index;
-
- index = of_property_match_string(np, "interconnect-names", "dma-mem");
- if (index < 0)
- return of_get_parent(np);
-
- ret = of_parse_phandle_with_args(np, "interconnects",
- "#interconnect-cells",
- index, &args);
- if (ret < 0)
- return of_get_parent(np);
-
- return of_node_get(args.np);
-}
-
static u64 of_translate_dma_address_parent(struct device_node *parent,
const __be32 *in_addr)
{
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 94f83051910c..ec161e6b5222 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -716,6 +716,31 @@ struct device_node *of_get_parent(const struct device_node *node)
}
EXPORT_SYMBOL(of_get_parent);
+/**
+ * __of_get_dma_parent - Get a node's dma parent if any
+ * @node: Node to get dma parent
+ *
+ * Returns a node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ */
+struct device_node *__of_get_dma_parent(const struct device_node *np)
+{
+ struct of_phandle_args args;
+ int ret, index;
+
+ index = of_property_match_string(np, "interconnect-names", "dma-mem");
+ if (index < 0)
+ return of_get_parent(np);
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+ "#interconnect-cells",
+ index, &args);
+ if (ret < 0)
+ return of_get_parent(np);
+
+ return of_node_get(args.np);
+}
+
/**
* of_get_next_parent - Iterate to a node's parent
* @node: Node to get parent of
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index b528304be244..63bb16cc454c 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -42,6 +42,8 @@ extern struct kset *of_kset;
int __of_n_addr_cells_parent(struct device_node *parent);
int __of_n_size_cells_parent(struct device_node *parent);
+struct device_node *__of_get_dma_parent(const struct device_node *np);
+
#if defined(CONFIG_OF_DYNAMIC)
extern int of_property_notify(int action, struct device_node *np,
struct property *prop, struct property *old_prop);
--
2.23.0
_______________________________________________
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/11] of: address: introduce of_translate_dma_address_parent()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
Some devices might not have a DT node of their own, but might still need
to translate DMA addresses based on their bus DT node.
Update of_translate_dma_address() to only depend on the parent DT node.
Rename it to of_translate_dma_address_parent(). The later will be still
available as a wrapper around the new function.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/address.c | 60 ++++++++++++++++++++++++++------------------
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 9c1e638fa8ea..c9eb4ebcc2e9 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -570,33 +570,32 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
* device that had registered logical PIO mapping, and the return code is
* relative to that node.
*/
-static u64 __of_translate_address(struct device_node *dev,
- struct device_node *(*get_parent)(const struct device_node *),
- const __be32 *in_addr, const char *rprop,
- struct device_node **host)
+static u64 __of_translate_address_parent(struct device_node *parent,
+ struct device_node *(*get_parent)
+ (const struct device_node *),
+ const __be32 *in_addr,
+ const char *rprop,
+ struct device_node **host)
{
- struct device_node *parent = NULL;
+ struct device_node *dev = NULL;
struct of_bus *bus, *pbus;
__be32 addr[OF_MAX_ADDR_CELLS];
int na, ns, pna, pns;
u64 result = OF_BAD_ADDR;
- pr_debug("** translation for device %pOF **\n", dev);
-
- /* Increase refcount at current level */
- of_node_get(dev);
-
*host = NULL;
- /* Get parent & match bus type */
- parent = get_parent(dev);
- if (parent == NULL)
+
+ if (!parent)
goto bail;
+
+ /* Increase refcount at current level and match bus type */
+ of_node_get(parent);
bus = of_match_bus(parent);
/* Count address cells & copy address locally */
bus->count_cells(parent, &na, &ns);
if (!OF_CHECK_COUNTS(na, ns)) {
- pr_debug("Bad cell count for %pOF\n", dev);
+ pr_debug("Bad cell count for %pOF\n", parent);
goto bail;
}
memcpy(addr, in_addr, na * 4);
@@ -610,9 +609,8 @@ static u64 __of_translate_address(struct device_node *dev,
struct logic_pio_hwaddr *iorange;
/* Switch to parent bus */
- of_node_put(dev);
dev = parent;
- parent = get_parent(dev);
+ parent = get_parent(parent);
/* If root, we have finished */
if (parent == NULL) {
@@ -650,6 +648,8 @@ static u64 __of_translate_address(struct device_node *dev,
break;
/* Complete the move up one level */
+ of_node_put(dev);
+ dev = parent;
na = pna;
ns = pns;
bus = pbus;
@@ -668,8 +668,10 @@ u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
struct device_node *host;
u64 ret;
- ret = __of_translate_address(dev, of_get_parent,
- in_addr, "ranges", &host);
+ pr_debug("** translation for device %pOF **\n", dev);
+
+ ret = __of_translate_address_parent(dev->parent, of_get_parent,
+ in_addr, "ranges", &host);
if (host) {
of_node_put(host);
return OF_BAD_ADDR;
@@ -697,14 +699,14 @@ static struct device_node *__of_get_dma_parent(const struct device_node *np)
return of_node_get(args.np);
}
-u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
+static u64 of_translate_dma_address_parent(struct device_node *parent,
+ const __be32 *in_addr)
{
struct device_node *host;
u64 ret;
- ret = __of_translate_address(dev, __of_get_dma_parent,
- in_addr, "dma-ranges", &host);
-
+ ret = __of_translate_address_parent(parent, __of_get_dma_parent, in_addr,
+ "dma-ranges", &host);
if (host) {
of_node_put(host);
return OF_BAD_ADDR;
@@ -712,6 +714,14 @@ u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
return ret;
}
+
+u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
+{
+ pr_debug("** translation for device %pOF **\n", dev);
+
+ return of_translate_dma_address_parent(__of_get_dma_parent(dev->parent),
+ in_addr);
+}
EXPORT_SYMBOL(of_translate_dma_address);
const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
@@ -759,8 +769,10 @@ static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr,
unsigned long port;
struct device_node *host;
- taddr = __of_translate_address(dev, of_get_parent,
- in_addr, "ranges", &host);
+ pr_debug("** translation for device %pOF **\n", dev);
+
+ taddr = __of_translate_address_parent(dev->parent, of_get_parent,
+ in_addr, "ranges", &host);
if (host) {
/* host-specific port access */
port = logic_pio_trans_hwaddr(&host->fwnode, taddr, size);
--
2.23.0
_______________________________________________
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/11] of: address: use parent DT node in bus->count_cells()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
The function provides the cell sizes for a specific bus type. Instead of
passing it the device DT node sitting on top of that bus we directly
pass its parent which is the actual node the function will start looking
from.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/address.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 0f898756199d..9c1e638fa8ea 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -14,6 +14,8 @@
#include <linux/slab.h>
#include <linux/string.h>
+#include "of_private.h"
+
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
#define OF_CHECK_ADDR_COUNT(na) ((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)
@@ -42,7 +44,7 @@ struct of_bus {
const char *name;
const char *addresses;
int (*match)(struct device_node *parent);
- void (*count_cells)(struct device_node *child,
+ void (*count_cells)(struct device_node *parent,
int *addrc, int *sizec);
u64 (*map)(__be32 *addr, const __be32 *range,
int na, int ns, int pna);
@@ -54,13 +56,13 @@ struct of_bus {
* Default translator (generic bus)
*/
-static void of_bus_default_count_cells(struct device_node *dev,
+static void of_bus_default_count_cells(struct device_node *parent,
int *addrc, int *sizec)
{
if (addrc)
- *addrc = of_n_addr_cells(dev);
+ *addrc = __of_n_addr_cells_parent(parent);
if (sizec)
- *sizec = of_n_size_cells(dev);
+ *sizec = __of_n_size_cells_parent(parent);
}
static u64 of_bus_default_map(__be32 *addr, const __be32 *range,
@@ -192,7 +194,7 @@ const __be32 *of_get_pci_address(struct device_node *dev, int bar_no, u64 *size,
of_node_put(parent);
return NULL;
}
- bus->count_cells(dev, &na, &ns);
+ bus->count_cells(parent, &na, &ns);
of_node_put(parent);
if (!OF_CHECK_ADDR_COUNT(na))
return NULL;
@@ -592,7 +594,7 @@ static u64 __of_translate_address(struct device_node *dev,
bus = of_match_bus(parent);
/* Count address cells & copy address locally */
- bus->count_cells(dev, &na, &ns);
+ bus->count_cells(parent, &na, &ns);
if (!OF_CHECK_COUNTS(na, ns)) {
pr_debug("Bad cell count for %pOF\n", dev);
goto bail;
@@ -634,7 +636,7 @@ static u64 __of_translate_address(struct device_node *dev,
/* Get new parent bus and counts */
pbus = of_match_bus(parent);
- pbus->count_cells(dev, &pna, &pns);
+ pbus->count_cells(parent, &pna, &pns);
if (!OF_CHECK_COUNTS(pna, pns)) {
pr_err("Bad cell count for %pOF\n", dev);
break;
@@ -726,7 +728,7 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
if (parent == NULL)
return NULL;
bus = of_match_bus(parent);
- bus->count_cells(dev, &na, &ns);
+ bus->count_cells(parent, &na, &ns);
of_node_put(parent);
if (!OF_CHECK_ADDR_COUNT(na))
return NULL;
--
2.23.0
_______________________________________________
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/11] of: base: introduce __of_n_*_cells_parent()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
Master PCI devices might not appear in the device tree, yet they still
need to get the underlying cells properties in order to calculate the
bus DMA constraints. This conflicts with of_n_*_cells() as it's designed
under the assumption it'll receive a device OF node.
Create __of_n_*_cells_parent() in order to deal with this limitation.
For now, it'll only be available privately to OF code.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/base.c | 44 +++++++++++++++++++++++++++++------------
drivers/of/of_private.h | 3 +++
2 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 1d667eb730e1..94f83051910c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -86,34 +86,52 @@ static bool __of_node_is_type(const struct device_node *np, const char *type)
return np && match && type && !strcmp(match, type);
}
-int of_n_addr_cells(struct device_node *np)
+int __of_n_addr_cells_parent(struct device_node *parent)
{
u32 cells;
- do {
- if (np->parent)
- np = np->parent;
- if (!of_property_read_u32(np, "#address-cells", &cells))
+ while (parent) {
+ if (!of_property_read_u32(parent, "#address-cells", &cells))
return cells;
- } while (np->parent);
+
+ parent = parent->parent;
+ }
+
/* No #address-cells property for the root node */
return OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
}
+
+int of_n_addr_cells(struct device_node *np)
+{
+ if (np->parent)
+ np = np->parent;
+
+ return __of_n_addr_cells_parent(np);
+}
EXPORT_SYMBOL(of_n_addr_cells);
-int of_n_size_cells(struct device_node *np)
+int __of_n_size_cells_parent(struct device_node *parent)
{
u32 cells;
- do {
- if (np->parent)
- np = np->parent;
- if (!of_property_read_u32(np, "#size-cells", &cells))
+ while (parent) {
+ if (!of_property_read_u32(parent, "#size-cells", &cells))
return cells;
- } while (np->parent);
- /* No #size-cells property for the root node */
+
+ parent = parent->parent;
+ }
+
+ /* No #address-cells property for the root node */
return OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
}
+
+int of_n_size_cells(struct device_node *np)
+{
+ if (np->parent)
+ np = np->parent;
+
+ return __of_n_size_cells_parent(np);
+}
EXPORT_SYMBOL(of_n_size_cells);
#ifdef CONFIG_NUMA
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 24786818e32e..b528304be244 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -39,6 +39,9 @@ extern struct mutex of_mutex;
extern struct list_head aliases_lookup;
extern struct kset *of_kset;
+int __of_n_addr_cells_parent(struct device_node *parent);
+int __of_n_size_cells_parent(struct device_node *parent);
+
#if defined(CONFIG_OF_DYNAMIC)
extern int of_property_notify(int action, struct device_node *np,
struct property *prop, struct property *old_prop);
--
2.23.0
_______________________________________________
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/11] of: Fix DMA configuration for non-DT masters
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, freedreno, mbrugger, wahrenst, james.quinlan,
Dan Williams, robin.murphy, Nicolas Saenz Julienne
Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.
This is due to the fact that of_dma_configure() assumes it's receiving a
DT node representing the device being configured, as opposed to the PCIe
bridge node we currently pass. This causes the code to directly jump
into PCI's parent node when checking for 'dma-ranges' and misses
whatever was set there.
To address this I create a new API in OF - inspired from Robin Murphys
original proposal[2] - which accepts a bus DT node as it's input in
order to configure a device's DMA constraints. The changes go deep into
of/address.c's implementation, as a device being having a DT node
assumption was pretty strong.
On top of this work, I also cleaned up of_dma_configure() removing its
redundant arguments and creating an alternative function for the special cases
not applicable to either the above case or the default usage.
IMO the resulting functions are more explicit. They will probably
surface some hacky usages that can be properly fixed as I show with the
DT fixes on the Layerscape platform.
This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
on a Seattle AMD board.
Regards,
Nicolas
[1] https://patchwork.kernel.org/patch/9650345/#20294961
[2] https://patchwork.kernel.org/patch/9650345/
---
Nicolas Saenz Julienne (11):
of: address: clean-up unused variable in of_dma_get_range()
of: base: introduce __of_n_*_cells_parent()
of: address: use parent DT node in bus->count_cells()
of: address: introduce of_translate_dma_address_parent()
of: expose __of_get_dma_parent() to OF subsystem
of: address: use parent OF node in of_dma_get_range()
dts: arm64: layerscape: add dma-ranges property to qoric-mc node
dts: arm64: layerscape: add dma-ranges property to pcie nodes
of: device: remove comment in of_dma_configure()
of: device: introduce of_dma_configure_parent()
of: simplify of_dma_config()'s arguments
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 +
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 5 +
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 1 +
drivers/base/platform.c | 2 +-
drivers/bcma/main.c | 2 +-
drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +-
drivers/dma/qcom/hidma_mgmt.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
drivers/gpu/host1x/bus.c | 4 +-
drivers/media/platform/qcom/venus/firmware.c | 2 +-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 +-
drivers/of/address.c | 136 +++++++++---------
drivers/of/base.c | 69 +++++++--
drivers/of/device.c | 59 +++++++-
drivers/of/of_private.h | 5 +
drivers/pci/pci-driver.c | 3 +-
drivers/xen/gntdev.c | 2 +-
include/linux/of_address.h | 8 +-
include/linux/of_device.h | 23 ++-
22 files changed, 223 insertions(+), 113 deletions(-)
--
2.23.0
_______________________________________________
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/11] of: address: clean-up unused variable in of_dma_get_range()
From: Nicolas Saenz Julienne @ 2019-09-24 18:12 UTC (permalink / raw)
To: robh+dt, devicetree, frowand.list, linux-arm-kernel,
linux-wireless, linux-kernel, linux-arm-msm, dmaengine, etnaviv,
dri-devel, xen-devel, linux-tegra, linux-media, linux-pci
Cc: f.fainelli, mbrugger, wahrenst, james.quinlan, robin.murphy,
Nicolas Saenz Julienne
In-Reply-To: <20190924181244.7159-1-nsaenzjulienne@suse.de>
'len' in of_dma_get_range() is used to check the 'dma-ranges' property
length. After the fact, some calculations are run on the variable to be
then left unused.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/of/address.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 978427a9d5e6..0f898756199d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -922,7 +922,7 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
- int len, naddr, nsize, pna;
+ int naddr, nsize, pna;
int ret = 0;
u64 dmaaddr;
@@ -931,6 +931,7 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
while (1) {
struct device_node *parent;
+ int len;
naddr = of_n_addr_cells(node);
nsize = of_n_size_cells(node);
@@ -962,8 +963,6 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
goto out;
}
- len /= sizeof(u32);
-
pna = of_n_addr_cells(node);
/* dma-ranges format:
--
2.23.0
_______________________________________________
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 3/3] arm64: dts: mark lx2160a esdhc controllers dma coherent
From: Robin Murphy @ 2019-09-24 18:04 UTC (permalink / raw)
To: Leo Li, Ulf Hansson, Russell King
Cc: Mark Rutland, DTML, dann frazier, Will Deacon, Nicolin Chen,
Rob Herring, Y.b. Lu, Shawn Guo, Christoph Hellwig, Linux ARM
In-Reply-To: <AM0PR04MB66766AC0807A85B3E5428E028F840@AM0PR04MB6676.eurprd04.prod.outlook.com>
On 24/09/2019 04:41, Leo Li wrote:
>
>
>> -----Original Message-----
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>> Sent: Monday, September 23, 2019 4:27 PM
>> To: Russell King <rmk+kernel@armlinux.org.uk>
>> Cc: Robin Murphy <robin.murphy@arm.com>; dann frazier
>> <dann.frazier@canonical.com>; Will Deacon <will.deacon@arm.com>;
>> Nicolin Chen <nicoleotsuka@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>;
>> Christoph Hellwig <hch@lst.de>; Mark Rutland <mark.rutland@arm.com>;
>> DTML <devicetree@vger.kernel.org>; Leo Li <leoyang.li@nxp.com>; Rob
>> Herring <robh+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Linux
>> ARM <linux-arm-kernel@lists.infradead.org>
>> Subject: Re: [PATCH 3/3] arm64: dts: mark lx2160a esdhc controllers dma
>> coherent
>>
>> On Sun, 22 Sep 2019 at 12:29, Russell King <rmk+kernel@armlinux.org.uk>
>> wrote:
>>>
>>> The LX2160A esdhc controllers are setup by the driver to be DMA
>>> coherent, but without marking them as such in DT, Linux thinks they
>>> are not. This can lead to random sporadic DMA errors, even to the
>>> extent of preventing boot, such as:
>>>
>>> mmc0: ADMA error
>>> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
>>> mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
>>> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
>>> mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
>>> mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
>>> mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
>>> mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000040d8
>>> mmc0: sdhci: Timeout: 0x00000003 | Int stat: 0x00000001
>>> mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
>>> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
>>> mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
>>> mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
>>> mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
>>> mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
>>> mmc0: sdhci: Host ctl2: 0x00000000
>>> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
>>> mmc0: sdhci: ============================================
>>> mmc0: error -5 whilst initialising SD card
>>>
>>> These are caused by the device's descriptor fetch hitting
>>> speculatively loaded CPU cache lines that the CPU does not see through
>>> the normal, non-cacheable DMA coherent mapping that it uses for
>>> non-coherent devices.
>>>
>>> DT and the device must agree wrt whether the device is DMA coherent or
>>> not.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>
>> As I am picking up patch1 and patch2 from this series, I can also help out and
>> pick up this one, if that is okay by people?
>
> There is some concern recently from linux-next maintainer about this causing potential conflicts. https://lkml.org/lkml/2019/9/15/225
In principle, it should be fine for #2 and #3 to go via separate trees -
#3 aligns the DT with the existing behaviour of the driver, while #2
will make the driver behave correctly whichever state the DT is in.
Robin.
_______________________________________________
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] drm/meson: fix max mode_config height/width
From: Jeykumar Sankaran @ 2019-09-24 17:28 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, dri-devel, Linux ARM, Daniel Vetter,
Linux Kernel Mailing List
In-Reply-To: <5dbd6337-7e08-f3f7-6d4a-d6bcaddfd3be@baylibre.com>
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332881@baylibre.com/T/#u
On 2018-10-05 01:19, Neil Armstrong wrote:
> On 05/10/2018 09:58, Daniel Vetter wrote:
>> On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
>> <narmstrong@baylibre.com> wrote:
>>>
>
> [...]
>
>>> OK, won't this be enough ?
>>> --- a/include/drm/drm_mode_config.h
>>> +++ b/include/drm/drm_mode_config.h
>>> @@ -333,6 +333,8 @@ struct drm_mode_config_funcs {
>>> * @min_height: minimum fb pixel height on this device
>>> * @max_width: maximum fb pixel width on this device
>>> * @max_height: maximum fb pixel height on this device
>>> + * @max_fb_width: maximum fb buffer width if differs from max_width
>>> + * @max_fb_height: maximum fb buffer height if differs from
>>> max_height
>>> * @funcs: core driver provided mode setting functions
>>> * @fb_base: base address of the framebuffer
>>> * @poll_enabled: track polling support for this device
>>> @@ -508,6 +510,7 @@ struct drm_mode_config {
>>>
>>> int min_width, min_height;
>>> int max_width, max_height;
>>> + int max_fb_width, max_fb_height;
>>> const struct drm_mode_config_funcs *funcs;
>>> resource_size_t fb_base;
>>>
>>> --- a/drivers/gpu/drm/drm_framebuffer.c
>>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>>> @@ -283,14 +283,20 @@ drm_internal_framebuffer_create(struct
>>> drm_device *dev,
>>> return ERR_PTR(-EINVAL);
>>> }
>>>
>>> - if ((config->min_width > r->width) || (r->width >
>>> config->max_width)) {
>>> + if ((config->min_width > r->width) ||
>>> + (!config->max_fb_width && r->width > config->max_width)
>>> ||
>>> + (config->max_fb_width && r->width >
>>> config->max_fb_width)) {
>>> DRM_DEBUG_KMS("bad framebuffer width %d, should be >=
>>> %d && <= %d\n",
>>> - r->width, config->min_width,
>>> config->max_width);
>>> + r->width, config->min_width,
>>> config->max_fb_width ?
>>> + config->max_fb_width : config->max_width);
>>> return ERR_PTR(-EINVAL);
>>> }
>>> - if ((config->min_height > r->height) || (r->height >
>>> config->max_height)) {
>>> + if ((config->min_height > r->height) ||
>>> + (!config->max_fb_height && r->height >
>>> config->max_height) ||
>>> + (config->max_fb_height && r->height >
>>> config->max_fb_height)) {
>>> DRM_DEBUG_KMS("bad framebuffer height %d, should be
>>> >= %d && <= %d\n",
>>> - r->height, config->min_height,
>>> config->max_height);
>>> + r->height, config->min_height,
>>> config->max_fb_height ?
>>> + config->max_fb_height :
>>> config->max_height);
>>> return ERR_PTR(-EINVAL);
>>> }
>>>
>>> and in the driver :
>>>
>>> + drm->mode_config.max_width = 4096;
>>> + drm->mode_config.max_height = 3840;
>>> + drm->mode_config.max_fb_width = 16384;
>>> + drm->mode_config.max_fb_height = 8192;
>>>
>>> With this I leave the mode filtering intact.
>>
>> Not enough. See
>> https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#c.drm_connector_helper_funcs
>> and scroll down to mode_valid. You need to filter modes both in the
>> detect paths, and the atomic_check paths.
>>
>> Detect is explicitly filtered out, but atomic_check was only
>> implicitly filtered, through the max fb size checks. Ok, you could
>> light up a mode that's bigger than max fb, but in practice, no
>> userspace ever did that.
Daniel, MSM and few other vendor hardware have upscale blocks where the
driver can expose fb sizes smaller than
the mode resolution and use h/w upscaling to fill the screen. This would
optimize the fetch bandwidth.
But with your code we're missing crucial
>> validation now, and userspace could fall over that. What I think we
>> need is to add mode filter against mode_config.max_width/height in
>> drm_atomic_helper_check_modeset(). Probably best to stuff that into
>> the mode_valid() function.
>
Agreed! Since the above patch from Niel is taking care of cases where
max/min fb values
are not set, by checking against the original max/min values, can we
separate out this
core change from the driver level mode_valid changes? If Niel couldn't
find the time, I can
repost the above change.
Thanks and Regards,
Jeykumar S.
> Ok I understood now, thanks for pointer, I'll try to add this.
>
> Neil
>
>>
>> Cheers, Daniel
>>>
>>> Neil
>>>
>>>
>>>> -Daniel
>>>>
>>>>>
>>>>> Neil
>>>>>
>>>>>>
>>>>>> Bunch of igt to make sure we're not missing anything would be
>>>>>> sweet on
>>>>>> top, e.g. e.g. trying to set a mode over the limit and making sure
>>>>>> it
>>>>>> fails.
>>>>>>
>>>>>> Cheers, Daniel
>>>>>>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/meson/meson_drv.c | 4 ++--
>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>>>>>>> b/drivers/gpu/drm/meson/meson_drv.c
>>>>>>> index d344312..2e29968 100644
>>>>>>> --- a/drivers/gpu/drm/meson/meson_drv.c
>>>>>>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>>>>>>> @@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct
>>>>>>> device *dev, bool has_components)
>>>>>>> goto free_drm;
>>>>>>>
>>>>>>> drm_mode_config_init(drm);
>>>>>>> - drm->mode_config.max_width = 3840;
>>>>>>> - drm->mode_config.max_height = 2160;
>>>>>>> + drm->mode_config.max_width = 16384;
>>>>>>> + drm->mode_config.max_height = 8192;
>>>>>>> drm->mode_config.funcs = &meson_mode_config_funcs;
>>>>>>>
>>>>>>> /* Hardware Initialization */
>>>>>>> --
>>>>>>> 2.7.4
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dri-devel mailing list
>>>>>>> dri-devel@lists.freedesktop.org
>>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>>
>>>>
>>>
>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jeykumar S
_______________________________________________
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 v10 0/6] mm / virtio: Provide support for unused page reporting
From: David Hildenbrand @ 2019-09-24 17:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Michal Hocko, linux-mm, Alexander Duyck, Andrea Arcangeli,
virtio-dev, Konrad Rzeszutek Wilk, Matthew Wilcox, Wang, Wei W,
Vlastimil Babka, Rik van Riel, Dan Williams, lcapitulino,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Mel Gorman
In-Reply-To: <CAKgT0UedoNBk3cp64SpCzXJqjtqBWZQSB7QzF7R_jhTDXbzNPg@mail.gmail.com>
On 24.09.19 19:07, Alexander Duyck wrote:
> On Tue, Sep 24, 2019 at 8:32 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 24.09.19 16:23, Michal Hocko wrote:
>>> On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
>>> [...]
>>>> In order to try and keep the time needed to find a non-reported page to
>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>>>> by the get_unreported_pages iterator to determine at what point it should
>>>> resume searching for non-reported pages. In order to guarantee pages do
>>>> not get past the scan I have modified add_to_free_list_tail so that it
>>>> will not insert pages behind the reported_boundary.
>>>>
>>>> If another process needs to perform a massive manipulation of the free
>>>> list, such as compaction, it can either reset a given individual boundary
>>>> which will push the boundary back to the list_head, or it can clear the
>>>> bit indicating the zone is actively processing which will result in the
>>>> reporting process resetting all of the boundaries for a given zone.
>>>
>>> Is this any different from the previous version? The last review
>>> feedback (both from me and Mel) was that we are not happy to have an
>>> externally imposed constrains on how the page allocator is supposed to
>>> maintain its free lists.
>>>
>>> If this is really the only way to go forward then I would like to hear
>>> very convincing arguments about other approaches not being feasible.
>>
>> Adding to what Alexander said, I don't consider the other approaches
>> (especially the bitmap-based approach Nitesh is currently working on)
>> infeasible. There might be more rough edges (e.g., sparse zones) and
>> eventually sometimes a little more work to be done, but definitely
>> feasible. Incorporating stuff into the buddy might make some tasks
>> (e.g., identify free pages) more efficient.
>>
>> I still somewhat like the idea of capturing hints of free pages (in
>> whatever data structure) and then going over the hints, seeing if the
>> pages are still free. Then only temporarily isolating the still-free
>> pages, reporting them, and un-isolating them after they were reported. I
>> like the idea that the pages are not fake-allocated but only temporarily
>> blocked. That works nicely e.g., with the movable zone (contain only
>> movable data).
>
> One other change in this patch set is that I split the headers so that
> there is an internal header that resides in the mm tree and an
> external one that provides the page reporting device structure and the
> register/unregister functions. All that virtio-balloon knows is that
> it is registering a notifier and will be called with scatter gather
> lists for memory that is not currently in use by the kernel. It has no
> visibility into the internal free_areas or the current state of the
> buddy allocator. Rather than having two blocks that are both trying to
> maintain that state, I have consolidated it all into the buddy
> allocator with page reporting.
>
>> But anyhow, after decades of people working on free page
>> hinting/reporting, I am happy with anything that gets accepted upstream :D
>
> Agreed. After working on this for 9 months I would be happy to get
> something upstream that addresses this.
IBM upstreamed their proprietary solution - 45e576b1c3d0 ("S390] guest
page hinting light") - in 2008.
Rik has presented a generic approach in 2011 (!)
https://www.linux-kvm.org/images/f/ff/2011-forum-memory-overcommit.pdf
I think Nitesh has been working on this (initially as an Intern) since
Mid 2017.
So yeah, this stuff has quite some history :)
>
> - Alex
>
--
Thanks,
David / dhildenb
_______________________________________________
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 v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Ray Jui @ 2019-09-24 17:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
Shivaraj Shetty, Rayagonda Kokatanur, linux-kernel, Icarus Chau,
Rob Herring, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <20190904213745.GG23608@ninjato>
Hi Wolfram,
On 9/4/19 2:37 PM, Wolfram Sang wrote:
>
>> I think you are right that the controller does not seem to support
>> additional I2C features in addition to SMBUS.
>>
>> However, my concern of switching to the smbus_xfer API is:
>>
>> 1) Some customers might have used I2C_RDWR based API from i2cdev. Changing
>> from master_xfer to smbus_xfer may break the existing applications that are
>> already developed.
>
> Well, given that you add new quirks in the original patch here, you are
> kind of breaking it already. Most transfers which are not SMBus-alike
> transfers would now be rejected. For SMBus-alike transfers which are
> sent via I2C_RDWR (which is ugly), I have to think about it.
>
>> 2) The sound subsystem I2C regmap based implementation seems to be using
>> i2c_ based API instead of smbus_ based API. Does this mean this will also
>> break most of the audio codec drivers with I2C regmap API based usage?
>
> I don't think so. If you check regmap_get_i2c_bus() then it checks the
> adapter functionality and chooses the best transfer option then. I may
> be missing something but I would wonder if the sound system does
> something special and different.
>
We did more investigation on this.
First of all, like you said, there's no concern on regmap based API, the
smbus_xfer only based approach should just work.
Secondly, for most i2ctools like i2cget, i2cset, i2cdump, there's no
concern either, given that they already use I2C_SMBUS based IOCTL.
However, for i2ctransfer or any customer applications that use I2C_RDWR
IOCTL, i2c_transfer (master_xfer) is the only supported function. And we
can confirm we do have at least one customer using i2ctransfer for
EEPROM access on their system, e.g., i2ctransfer 1 w2@0x50 0x00 0x00 r64.
In my opinion, it's probably better to continue to support master_xfer
in our driver (with obvious limitations), in order to allow i2ctransfer
(or any apps that use I2C RDWR) to continue to work.
What do you think?
Regards,
Ray
_______________________________________________
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 v2] arm64: use generic free_initrd_mem()
From: kbuild test robot @ 2019-09-24 17:18 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mark Rutland, Anshuman Khandual, Catalin Marinas, linux-kernel,
Mike Rapoport, kbuild-all, Laura Abbott, Will Deacon,
linux-arm-kernel
In-Reply-To: <1569323928-10154-1-git-send-email-rppt@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
Hi Mike,
I love your patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Mike-Rapoport/arm64-use-generic-free_initrd_mem/20190924-220328
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
init/initramfs.c: In function 'free_initrd_mem':
>> init/initramfs.c:536:2: error: implicit declaration of function 'memblock_free'; did you mean 'ptlock_free'? [-Werror=implicit-function-declaration]
memblock_free(__virt_to_phys(start), end - start);
^~~~~~~~~~~~~
ptlock_free
>> init/initramfs.c:536:16: error: implicit declaration of function '__virt_to_phys'; did you mean 'virt_to_phys'? [-Werror=implicit-function-declaration]
memblock_free(__virt_to_phys(start), end - start);
^~~~~~~~~~~~~~
virt_to_phys
cc1: some warnings being treated as errors
vim +536 init/initramfs.c
529
530 void __weak free_initrd_mem(unsigned long start, unsigned long end)
531 {
532 free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
533 "initrd");
534
535 #ifdef CONFIG_ARCH_KEEP_MEMBLOCK
> 536 memblock_free(__virt_to_phys(start), end - start);
537 #endif
538 }
539
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62287 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v1] seccomp: simplify secure_computing()
From: Andy Lutomirski @ 2019-09-24 17:11 UTC (permalink / raw)
To: Christian Brauner
Cc: linux-s390, Will Drewry, Kees Cook, Parisc List, X86 ML, linux-um,
LKML, Oleg Nesterov, Borislav Petkov, Andrew Lutomirski,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190924064420.6353-1-christian.brauner@ubuntu.com>
On Mon, Sep 23, 2019 at 11:44 PM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> Afaict, the struct seccomp_data argument to secure_computing() is unused
> by all current callers. So let's remove it.
> The argument was added in [1]. It was added because having the arch
> supply the syscall arguments used to be faster than having it done by
> secure_computing() (cf. Andy's comment in [2]). This is not true anymore
> though.
>
> /* References */
> [1]: 2f275de5d1ed ("seccomp: Add a seccomp_data parameter secure_computing()")
> [2]: https://lore.kernel.org/r/CALCETrU_fs_At-hTpr231kpaAd0z7xJN4ku-DvzhRU6cvcJA_w@mail.gmail.com
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Will Drewry <wad@chromium.org>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-parisc@vger.kernel.org
> Cc: linux-s390@vger.kernel.org
> Cc: linux-um@lists.infradead.org
> Cc: x86@kernel.org
Acked-by: Andy Lutomirski <luto@kernel.org>
_______________________________________________
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 v10 0/6] mm / virtio: Provide support for unused page reporting
From: Alexander Duyck @ 2019-09-24 17:07 UTC (permalink / raw)
To: David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Michal Hocko, linux-mm, Alexander Duyck, Andrea Arcangeli,
virtio-dev, Konrad Rzeszutek Wilk, Matthew Wilcox, Wang, Wei W,
Vlastimil Babka, Rik van Riel, Dan Williams, lcapitulino,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Mel Gorman
In-Reply-To: <d2a7acdd-3bb9-05c9-42d0-70a500801cd6@redhat.com>
On Tue, Sep 24, 2019 at 8:32 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 24.09.19 16:23, Michal Hocko wrote:
> > On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
> > [...]
> >> In order to try and keep the time needed to find a non-reported page to
> >> a minimum we maintain a "reported_boundary" pointer. This pointer is used
> >> by the get_unreported_pages iterator to determine at what point it should
> >> resume searching for non-reported pages. In order to guarantee pages do
> >> not get past the scan I have modified add_to_free_list_tail so that it
> >> will not insert pages behind the reported_boundary.
> >>
> >> If another process needs to perform a massive manipulation of the free
> >> list, such as compaction, it can either reset a given individual boundary
> >> which will push the boundary back to the list_head, or it can clear the
> >> bit indicating the zone is actively processing which will result in the
> >> reporting process resetting all of the boundaries for a given zone.
> >
> > Is this any different from the previous version? The last review
> > feedback (both from me and Mel) was that we are not happy to have an
> > externally imposed constrains on how the page allocator is supposed to
> > maintain its free lists.
> >
> > If this is really the only way to go forward then I would like to hear
> > very convincing arguments about other approaches not being feasible.
>
> Adding to what Alexander said, I don't consider the other approaches
> (especially the bitmap-based approach Nitesh is currently working on)
> infeasible. There might be more rough edges (e.g., sparse zones) and
> eventually sometimes a little more work to be done, but definitely
> feasible. Incorporating stuff into the buddy might make some tasks
> (e.g., identify free pages) more efficient.
>
> I still somewhat like the idea of capturing hints of free pages (in
> whatever data structure) and then going over the hints, seeing if the
> pages are still free. Then only temporarily isolating the still-free
> pages, reporting them, and un-isolating them after they were reported. I
> like the idea that the pages are not fake-allocated but only temporarily
> blocked. That works nicely e.g., with the movable zone (contain only
> movable data).
One other change in this patch set is that I split the headers so that
there is an internal header that resides in the mm tree and an
external one that provides the page reporting device structure and the
register/unregister functions. All that virtio-balloon knows is that
it is registering a notifier and will be called with scatter gather
lists for memory that is not currently in use by the kernel. It has no
visibility into the internal free_areas or the current state of the
buddy allocator. Rather than having two blocks that are both trying to
maintain that state, I have consolidated it all into the buddy
allocator with page reporting.
> But anyhow, after decades of people working on free page
> hinting/reporting, I am happy with anything that gets accepted upstream :D
Agreed. After working on this for 9 months I would be happy to get
something upstream that addresses this.
- 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 4/6] PCI: mobiveil: Add workaround for unsupported request error
From: Russell King - ARM Linux admin @ 2019-09-24 16:49 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, devicetree, lorenzo.pieralisi, linux-pci,
Zhiqiang.Hou, linux-kernel, leoyang.li, Minghuan.Lian, robh+dt,
linux-arm-kernel, bhelgaas, andrew.murray, kishon, shawnguo,
mingkai.hu
In-Reply-To: <20190916021742.22844-5-xiaowei.bao@nxp.com>
On Mon, Sep 16, 2019 at 10:17:40AM +0800, Xiaowei Bao wrote:
> Errata: unsupported request error on inbound posted write
> transaction, PCIe controller reports advisory error instead
> of uncorrectable error message to RC.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c | 13 +++++++++++++
> drivers/pci/controller/mobiveil/pcie-mobiveil.h | 4 ++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> index 7bfec51..5bc9ed7 100644
> --- a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> +++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> @@ -49,6 +49,19 @@ static void ls_pcie_g4_ep_init(struct mobiveil_pcie_ep *ep)
> struct mobiveil_pcie *mv_pci = to_mobiveil_pcie_from_ep(ep);
> int win_idx;
> u8 bar;
> + u32 val;
> +
> + /*
> + * Errata: unsupported request error on inbound posted write
> + * transaction, PCIe controller reports advisory error instead
> + * of uncorrectable error message to RC.
> + * workaround: set the bit20(unsupported_request_Error_severity) with
> + * value 1 in uncorrectable_Error_Severity_Register, make the
> + * unsupported request error generate the fatal error.
> + */
> + val = csr_readl(mv_pci, CFG_UNCORRECTABLE_ERROR_SEVERITY);
> + val |= 1 << UNSUPPORTED_REQUEST_ERROR_SHIFT;
BIT(UNSUPPORTED_REQUEST_ERROR_SHIFT) ?
> + csr_writel(mv_pci, val, CFG_UNCORRECTABLE_ERROR_SEVERITY);
>
> ep->bar_num = PCIE_LX2_BAR_NUM;
>
> diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> index 7308fa4..a40707e 100644
> --- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> +++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> @@ -123,6 +123,10 @@
> #define GPEX_BAR_SIZE_UDW 0x4DC
> #define GPEX_BAR_SELECT 0x4E0
>
> +#define CFG_UNCORRECTABLE_ERROR_SEVERITY 0x10c
> +#define UNSUPPORTED_REQUEST_ERROR_SHIFT 20
> +#define CFG_UNCORRECTABLE_ERROR_MASK 0x108
> +
> /* starting offset of INTX bits in status register */
> #define PAB_INTX_START 5
>
> --
> 2.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] PCI: mobiveil: Add PCIe Gen4 EP driver for NXP Layerscape SoCs
From: Russell King - ARM Linux admin @ 2019-09-24 16:38 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, devicetree, lorenzo.pieralisi, linux-pci,
Zhiqiang.Hou, linux-kernel, leoyang.li, Minghuan.Lian, robh+dt,
linux-arm-kernel, bhelgaas, andrew.murray, kishon, shawnguo,
mingkai.hu
In-Reply-To: <20190916021742.22844-4-xiaowei.bao@nxp.com>
On Mon, Sep 16, 2019 at 10:17:39AM +0800, Xiaowei Bao wrote:
> This PCIe controller is based on the Mobiveil GPEX IP, it work in EP
> mode if select this config opteration.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> MAINTAINERS | 2 +
> drivers/pci/controller/mobiveil/Kconfig | 17 ++-
> drivers/pci/controller/mobiveil/Makefile | 1 +
> .../controller/mobiveil/pcie-layerscape-gen4-ep.c | 156 +++++++++++++++++++++
> 4 files changed, 173 insertions(+), 3 deletions(-)
> create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b997056..0858b54 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12363,11 +12363,13 @@ F: drivers/pci/controller/dwc/*layerscape*
>
> PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
> M: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> +M: Xiaowei Bao <xiaowei.bao@nxp.com>
> L: linux-pci@vger.kernel.org
> L: linux-arm-kernel@lists.infradead.org
> S: Maintained
> F: Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
> F: drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c
> +F: drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
>
> PCI DRIVER FOR GENERIC OF HOSTS
> M: Will Deacon <will@kernel.org>
> diff --git a/drivers/pci/controller/mobiveil/Kconfig b/drivers/pci/controller/mobiveil/Kconfig
> index 2054950..0696b6e 100644
> --- a/drivers/pci/controller/mobiveil/Kconfig
> +++ b/drivers/pci/controller/mobiveil/Kconfig
> @@ -27,13 +27,24 @@ config PCIE_MOBIVEIL_PLAT
> for address translation and it is a PCIe Gen4 IP.
>
> config PCIE_LAYERSCAPE_GEN4
> - bool "Freescale Layerscape PCIe Gen4 controller"
> + bool "Freescale Layerscpe PCIe Gen4 controller in RC mode"
> depends on PCI
> depends on OF && (ARM64 || ARCH_LAYERSCAPE)
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIE_MOBIVEIL_HOST
> help
> Say Y here if you want PCIe Gen4 controller support on
> - Layerscape SoCs. The PCIe controller can work in RC or
> - EP mode according to RCW[HOST_AGT_PEX] setting.
> + Layerscape SoCs. And the PCIe controller work in RC mode
> + by setting the RCW[HOST_AGT_PEX] to 0.
> +
> +config PCIE_LAYERSCAPE_GEN4_EP
> + bool "Freescale Layerscpe PCIe Gen4 controller in EP mode"
> + depends on PCI
> + depends on OF && (ARM64 || ARCH_LAYERSCAPE)
> + depends on PCI_ENDPOINT
> + select PCIE_MOBIVEIL_EP
> + help
> + Say Y here if you want PCIe Gen4 controller support on
> + Layerscape SoCs. And the PCIe controller work in EP mode
> + by setting the RCW[HOST_AGT_PEX] to 1.
> endmenu
> diff --git a/drivers/pci/controller/mobiveil/Makefile b/drivers/pci/controller/mobiveil/Makefile
> index 686d41f..6f54856 100644
> --- a/drivers/pci/controller/mobiveil/Makefile
> +++ b/drivers/pci/controller/mobiveil/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
> obj-$(CONFIG_PCIE_MOBIVEIL_EP) += pcie-mobiveil-ep.o
> obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
> obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
> +obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4_EP) += pcie-layerscape-gen4-ep.o
> diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> new file mode 100644
> index 0000000..7bfec51
> --- /dev/null
> +++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c
> @@ -0,0 +1,156 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe controller EP driver for Freescale Layerscape SoCs
> + *
> + * Copyright (C) 2019 NXP Semiconductor.
> + *
> + * Author: Xiaowei Bao <xiaowei.bao@nxp.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_address.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +
> +#include "pcie-mobiveil.h"
> +
> +#define PCIE_LX2_BAR_NUM 4
> +
> +#define to_ls_pcie_g4_ep(x) dev_get_drvdata((x)->dev)
> +
> +struct ls_pcie_g4_ep {
> + struct mobiveil_pcie *mv_pci;
> +};
> +
> +static const struct of_device_id ls_pcie_g4_ep_of_match[] = {
> + { .compatible = "fsl,lx2160a-pcie-ep",},
> + { },
> +};
> +
> +static const struct pci_epc_features ls_pcie_g4_epc_features = {
> + .linkup_notifier = false,
> + .msi_capable = true,
> + .msix_capable = true,
> + .reserved_bar = (1 << BAR_4) | (1 << BAR_5),
BIT(BAR_4) | BIT(BAR_5) ?
> +};
> +
> +static const struct pci_epc_features*
> +ls_pcie_g4_ep_get_features(struct mobiveil_pcie_ep *ep)
> +{
> + return &ls_pcie_g4_epc_features;
> +}
> +
> +static void ls_pcie_g4_ep_init(struct mobiveil_pcie_ep *ep)
> +{
> + struct mobiveil_pcie *mv_pci = to_mobiveil_pcie_from_ep(ep);
> + int win_idx;
> + u8 bar;
> +
> + ep->bar_num = PCIE_LX2_BAR_NUM;
> +
> + for (bar = BAR_0; bar < ep->epc->max_functions * ep->bar_num; bar++)
> + mobiveil_pcie_ep_reset_bar(mv_pci, bar);
> +
> + for (win_idx = 0; win_idx < ep->apio_wins; win_idx++)
> + mobiveil_pcie_disable_ob_win(mv_pci, win_idx);
> +}
> +
> +static int ls_pcie_g4_ep_raise_irq(struct mobiveil_pcie_ep *ep, u8 func_no,
> + enum pci_epc_irq_type type,
> + u16 interrupt_num)
> +{
> + struct mobiveil_pcie *mv_pci = to_mobiveil_pcie_from_ep(ep);
> +
> + switch (type) {
> + case PCI_EPC_IRQ_LEGACY:
> + return mobiveil_pcie_ep_raise_legacy_irq(ep, func_no);
> + case PCI_EPC_IRQ_MSI:
> + return mobiveil_pcie_ep_raise_msi_irq(ep, func_no,
> + interrupt_num);
> + case PCI_EPC_IRQ_MSIX:
> + return mobiveil_pcie_ep_raise_msix_irq(ep, func_no,
> + interrupt_num);
> + default:
> + dev_err(&mv_pci->pdev->dev, "UNKNOWN IRQ type\n");
> + }
> +
> + return 0;
> +}
> +
> +static const struct mobiveil_pcie_ep_ops pcie_ep_ops = {
> + .ep_init = ls_pcie_g4_ep_init,
> + .raise_irq = ls_pcie_g4_ep_raise_irq,
> + .get_features = ls_pcie_g4_ep_get_features,
> +};
> +
> +static int __init ls_pcie_gen4_add_pcie_ep(struct ls_pcie_g4_ep *ls_ep,
> + struct platform_device *pdev)
> +{
> + struct mobiveil_pcie *mv_pci = ls_ep->mv_pci;
> + struct device *dev = &pdev->dev;
> + struct mobiveil_pcie_ep *ep;
> + struct resource *res;
> + int ret;
> +
> + ep = &mv_pci->ep;
> + ep->ops = &pcie_ep_ops;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
> + if (!res)
> + return -EINVAL;
> +
> + ep->phys_base = res->start;
> + ep->addr_size = resource_size(res);
> +
> + ret = mobiveil_pcie_ep_init(ep);
> + if (ret) {
> + dev_err(dev, "failed to initialize layerscape endpoint\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init ls_pcie_g4_ep_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mobiveil_pcie *mv_pci;
> + struct ls_pcie_g4_ep *ls_ep;
> + struct resource *res;
> + int ret;
> +
> + ls_ep = devm_kzalloc(dev, sizeof(*ls_ep), GFP_KERNEL);
> + if (!ls_ep)
> + return -ENOMEM;
> +
> + mv_pci = devm_kzalloc(dev, sizeof(*mv_pci), GFP_KERNEL);
> + if (!mv_pci)
> + return -ENOMEM;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + mv_pci->csr_axi_slave_base = devm_pci_remap_cfg_resource(dev, res);
> + if (IS_ERR(mv_pci->csr_axi_slave_base))
> + return PTR_ERR(mv_pci->csr_axi_slave_base);
> +
> + mv_pci->pdev = pdev;
> + ls_ep->mv_pci = mv_pci;
> +
> + platform_set_drvdata(pdev, ls_ep);
> +
> + ret = ls_pcie_gen4_add_pcie_ep(ls_ep, pdev);
> +
> + return ret;
> +}
> +
> +static struct platform_driver ls_pcie_g4_ep_driver = {
> + .driver = {
> + .name = "layerscape-pcie-gen4-ep",
> + .of_match_table = ls_pcie_g4_ep_of_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +builtin_platform_driver_probe(ls_pcie_g4_ep_driver, ls_pcie_g4_ep_probe);
> --
> 2.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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