* [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Artur Świgoń @ 2019-09-19 14:22 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pm, dri-devel
Cc: Artur Świgoń, b.zolnierkie, sw0312.kim, krzk, inki.dae,
cw00.choi, myungjoo.ham, leonard.crestez, georgi.djakov,
m.szyprowski
In-Reply-To: <20190919142236.4071-1-a.swigon@samsung.com>
From: Artur Świgoń <a.swigon@partner.samsung.com>
This patch adds interconnect functionality to the exynos-bus devfreq
driver.
The SoC topology is a graph (or, more specifically, a tree) and most of
its edges are taken from the devfreq parent-child hierarchy (cf.
Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
unspecified relative probing order, -EPROBE_DEFER may be propagated to
guarantee that a child is probed before its parent.
Each bus is now an interconnect provider and an interconnect node as well
(cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
itself as a node. Node IDs are not hardcoded but rather assigned at
runtime, in probing order (subject to the above-mentioned exception
regarding relative order). This approach allows for using this driver with
various Exynos SoCs.
Frequencies requested via the interconnect API for a given node are
propagated to devfreq using dev_pm_qos_update_request(). Please note that
it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
interconnect API functions are no-op.
Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
---
drivers/devfreq/exynos-bus.c | 153 +++++++++++++++++++++++++++++++++++
1 file changed, 153 insertions(+)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 8d44810cac69..e0232202720d 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -14,14 +14,19 @@
#include <linux/devfreq-event.h>
#include <linux/device.h>
#include <linux/export.h>
+#include <linux/idr.h>
+#include <linux/interconnect-provider.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
+#include <linux/pm_qos.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#define DEFAULT_SATURATION_RATIO 40
+#define icc_units_to_khz(x) ((x) / 8)
+
struct exynos_bus {
struct device *dev;
@@ -35,6 +40,12 @@ struct exynos_bus {
struct opp_table *opp_table;
struct clk *clk;
unsigned int ratio;
+
+ /* One provider per bus, one node per provider */
+ struct icc_provider provider;
+ struct icc_node *node;
+
+ struct dev_pm_qos_request qos_req;
};
/*
@@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
exynos_bus_ops_edev(disable_edev);
exynos_bus_ops_edev(set_event);
+static int exynos_bus_next_id(void)
+{
+ static DEFINE_IDA(exynos_bus_icc_ida);
+
+ return ida_alloc(&exynos_bus_icc_ida, GFP_KERNEL);
+}
+
static int exynos_bus_get_event(struct exynos_bus *bus,
struct devfreq_event_data *edata)
{
@@ -171,6 +189,38 @@ static void exynos_bus_passive_exit(struct device *dev)
clk_disable_unprepare(bus->clk);
}
+static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
+ s32 src_freq = icc_units_to_khz(src->avg_bw);
+ s32 dst_freq = icc_units_to_khz(dst->avg_bw);
+
+ dev_pm_qos_update_request(&src_bus->qos_req, src_freq);
+ dev_pm_qos_update_request(&dst_bus->qos_req, dst_freq);
+
+ return 0;
+}
+
+static int exynos_bus_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
+ u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
+{
+ *agg_avg += avg_bw;
+ *agg_peak = max(*agg_peak, peak_bw);
+
+ return 0;
+}
+
+static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
+ void *data)
+{
+ struct exynos_bus *bus = data;
+
+ if (spec->np != bus->dev->of_node)
+ return ERR_PTR(-EINVAL);
+
+ return bus->node;
+}
+
static int exynos_bus_parent_parse_of(struct device_node *np,
struct exynos_bus *bus)
{
@@ -366,6 +416,101 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
return 0;
}
+static int exynos_bus_icc_connect(struct exynos_bus *bus)
+{
+ struct device_node *np = bus->dev->of_node;
+ struct devfreq *parent_devfreq;
+ struct icc_node *parent_node = NULL;
+ struct of_phandle_args args;
+ int ret = 0;
+
+ parent_devfreq = devfreq_get_devfreq_by_phandle(bus->dev, 0);
+ if (!IS_ERR(parent_devfreq)) {
+ struct exynos_bus *parent_bus;
+
+ parent_bus = dev_get_drvdata(parent_devfreq->dev.parent);
+ parent_node = parent_bus->node;
+ } else {
+ /* Look for parent in DT */
+ int num = of_count_phandle_with_args(np, "parent",
+ "#interconnect-cells");
+ if (num != 1)
+ goto out; /* 'parent' is optional */
+
+ ret = of_parse_phandle_with_args(np, "parent",
+ "#interconnect-cells",
+ 0, &args);
+ if (ret < 0)
+ goto out;
+
+ of_node_put(args.np);
+
+ parent_node = of_icc_get_from_provider(&args);
+ if (IS_ERR(parent_node)) {
+ /* May be -EPROBE_DEFER */
+ ret = PTR_ERR(parent_node);
+ goto out;
+ }
+ }
+
+ ret = icc_link_create(bus->node, parent_node->id);
+
+out:
+ return ret;
+}
+
+static int exynos_bus_icc_init(struct exynos_bus *bus)
+{
+ struct device *dev = bus->dev;
+ struct icc_provider *provider = &bus->provider;
+ struct icc_node *node;
+ int id, ret;
+
+ /* Initialize the interconnect provider */
+ provider->set = exynos_bus_icc_set;
+ provider->aggregate = exynos_bus_icc_aggregate;
+ provider->xlate = exynos_bus_icc_xlate;
+ provider->dev = dev;
+ provider->data = bus;
+
+ ret = icc_provider_add(provider);
+ if (ret < 0)
+ goto out;
+
+ ret = id = exynos_bus_next_id();
+ if (ret < 0)
+ goto err_node;
+
+ node = icc_node_create(id);
+ if (IS_ERR(node)) {
+ ret = PTR_ERR(node);
+ goto err_node;
+ }
+
+ bus->node = node;
+ node->name = dev->of_node->name;
+ node->data = bus;
+ icc_node_add(node, provider);
+
+ ret = exynos_bus_icc_connect(bus);
+ if (ret < 0)
+ goto err_connect;
+
+ ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, &bus->qos_req,
+ DEV_PM_QOS_MIN_FREQUENCY, 0);
+
+out:
+ return ret;
+
+err_connect:
+ icc_node_del(node);
+ icc_node_destroy(id);
+err_node:
+ icc_provider_del(provider);
+
+ return ret;
+}
+
static int exynos_bus_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -415,6 +560,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
if (ret < 0)
goto err;
+ /*
+ * Initialize interconnect provider. A return value of -ENOTSUPP means
+ * that CONFIG_INTERCONNECT is disabled.
+ */
+ ret = exynos_bus_icc_init(bus);
+ if (ret < 0 && ret != -ENOTSUPP)
+ goto err;
+
max_state = bus->devfreq->profile->max_state;
min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
--
2.17.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
* [RFC PATCH v2 10/11] arm: dts: exynos: Add interconnects to Exynos4412 mixer
From: Artur Świgoń @ 2019-09-19 14:22 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pm, dri-devel
Cc: Artur Świgoń, b.zolnierkie, sw0312.kim, krzk, inki.dae,
cw00.choi, myungjoo.ham, leonard.crestez, georgi.djakov,
m.szyprowski
In-Reply-To: <20190919142236.4071-1-a.swigon@samsung.com>
From: Artur Świgoń <a.swigon@partner.samsung.com>
This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a NULL name simply
returns the right path.
Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
---
arch/arm/boot/dts/exynos4412.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index a70a671acacd..faaec6c40412 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -789,6 +789,7 @@
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
<&clock CLK_SCLK_HDMI>, <&clock CLK_VP>;
+ interconnects = <&bus_display &bus_dmc>;
};
&pmu {
--
2.17.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
* [RFC PATCH v2 11/11] drm: exynos: mixer: Add interconnect support
From: Artur Świgoń @ 2019-09-19 14:22 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
linux-pm, dri-devel
Cc: Artur Świgoń, b.zolnierkie, sw0312.kim, krzk, inki.dae,
cw00.choi, myungjoo.ham, leonard.crestez, georgi.djakov,
Marek Szyprowski
In-Reply-To: <20190919142236.4071-1-a.swigon@samsung.com>
From: Marek Szyprowski <m.szyprowski@samsung.com>
This patch adds interconnect support to exynos-mixer. Please note that the
mixer works the same as before when CONFIG_INTERCONNECT is 'n'.
Co-developed-by: Artur Świgoń <a.swigon@partner.samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
---
drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++++++++++++++++++++++++--
1 file changed, 66 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 7b24338fad3c..a44f3284b071 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -13,6 +13,7 @@
#include <linux/component.h>
#include <linux/delay.h>
#include <linux/i2c.h>
+#include <linux/interconnect.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/kernel.h>
@@ -97,6 +98,7 @@ struct mixer_context {
struct exynos_drm_crtc *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
unsigned long flags;
+ struct icc_path *soc_path;
int irq;
void __iomem *mixer_regs;
@@ -931,6 +933,40 @@ static void mixer_disable_vblank(struct exynos_drm_crtc *crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
}
+static void mixer_set_memory_bandwidth(struct exynos_drm_crtc *crtc)
+{
+ struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
+ struct mixer_context *ctx = crtc->ctx;
+ unsigned long bw, bandwidth = 0;
+ int i, j, sub;
+
+ if (!ctx->soc_path)
+ return;
+
+ for (i = 0; i < MIXER_WIN_NR; i++) {
+ struct drm_plane *plane = &ctx->planes[i].base;
+ const struct drm_format_info *format;
+
+ if (plane->state && plane->state->crtc && plane->state->fb) {
+ format = plane->state->fb->format;
+ bw = mode->hdisplay * mode->vdisplay *
+ drm_mode_vrefresh(mode);
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ bw /= 2;
+ for (j = 0; j < format->num_planes; j++) {
+ sub = j ? (format->vsub * format->hsub) : 1;
+ bandwidth += format->cpp[j] * bw / sub;
+ }
+ }
+ }
+
+ /* add 20% safety margin */
+ bandwidth = bandwidth / 4 * 5;
+
+ dev_dbg(ctx->dev, "exynos-mixer: safe bandwidth %ld Bps\n", bandwidth);
+ icc_set_bw(ctx->soc_path, Bps_to_icc(bandwidth), 0);
+}
+
static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
@@ -982,6 +1018,7 @@ static void mixer_atomic_flush(struct exynos_drm_crtc *crtc)
if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;
+ mixer_set_memory_bandwidth(crtc);
mixer_enable_sync(mixer_ctx);
exynos_crtc_handle_event(crtc);
}
@@ -1029,6 +1066,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, &ctx->planes[i]);
+ mixer_set_memory_bandwidth(crtc);
exynos_drm_pipe_clk_enable(crtc, false);
pm_runtime_put(ctx->dev);
@@ -1220,12 +1258,22 @@ static int mixer_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
const struct mixer_drv_data *drv;
struct mixer_context *ctx;
+ struct icc_path *path;
int ret;
+ /*
+ * Returns NULL if CONFIG_INTERCONNECT is disabled.
+ * May return ERR_PTR(-EPROBE_DEFER).
+ */
+ path = of_icc_get(dev, NULL);
+ if (IS_ERR(path))
+ return PTR_ERR(path);
+
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
DRM_DEV_ERROR(dev, "failed to alloc mixer context.\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
drv = of_device_get_match_data(dev);
@@ -1233,6 +1281,7 @@ static int mixer_probe(struct platform_device *pdev)
ctx->pdev = pdev;
ctx->dev = dev;
ctx->mxr_ver = drv->version;
+ ctx->soc_path = path;
if (drv->is_vp_enabled)
__set_bit(MXR_BIT_VP_ENABLED, &ctx->flags);
@@ -1242,17 +1291,29 @@ static int mixer_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
ret = component_add(&pdev->dev, &mixer_component_ops);
- if (!ret)
- pm_runtime_enable(dev);
+ if (ret < 0)
+ goto err;
+
+ pm_runtime_enable(dev);
+
+ return 0;
+
+err:
+ icc_put(path);
return ret;
}
static int mixer_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct mixer_context *ctx = dev_get_drvdata(dev);
- component_del(&pdev->dev, &mixer_component_ops);
+ pm_runtime_disable(dev);
+
+ component_del(dev, &mixer_component_ops);
+
+ icc_put(ctx->soc_path);
return 0;
}
--
2.17.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] ARM: aspeed: ast2500 is ARMv6K
From: Arnd Bergmann @ 2019-09-19 14:26 UTC (permalink / raw)
To: Joel Stanley
Cc: Andrew Jeffery, linux-aspeed, linux-arm-kernel, Arnd Bergmann,
linux-kernel
Linux supports both the original ARMv6 level (early ARM1136) and ARMv6K
(later ARM1136, ARM1176 and ARM11mpcore).
ast2500 falls into the second categoy, being based on arm1176jzf-s.
This is enabled by default when using ARCH_MULTI_V6, so we should
not 'select CPU_V6'.
Removing this will lead to more efficient use of atomic instructions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-aspeed/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
index a293137f5814..163931a03136 100644
--- a/arch/arm/mach-aspeed/Kconfig
+++ b/arch/arm/mach-aspeed/Kconfig
@@ -26,7 +26,6 @@ config MACH_ASPEED_G4
config MACH_ASPEED_G5
bool "Aspeed SoC 5th Generation"
depends on ARCH_MULTI_V6
- select CPU_V6
select PINCTRL_ASPEED_G5 if !CC_IS_CLANG
select FTTMR010_TIMER
help
--
2.20.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 v4 1/3] dmaengine: imx-sdma: fix buffer ownership
From: Philipp Puschmann @ 2019-09-19 14:29 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
In-Reply-To: <20190919142942.12469-1-philipp.puschmann@emlix.com>
BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the
buffer, when 0 ARM owns it. When processing the buffers in
sdma_update_channel_loop the ownership of the currently processed
buffer was set to SDMA again before running the callback function of
the buffer and while the sdma script may be running in parallel. So
there was the possibility to get the buffer overwritten by SDMA before
it has been processed by kernel leading to kind of random errors in the
upper layers, e.g. bluetooth.
Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
Changelog v4:
- fixed the fixes tag
Changelog v3:
- use correct dma_wmb() instead of dma_wb()
- add fixes tag
Changelog v2:
- add dma_wb()
drivers/dma/imx-sdma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 9ba74ab7e912..e029a2443cfc 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
*/
desc->chn_real_count = bd->mode.count;
- bd->mode.status |= BD_DONE;
bd->mode.count = desc->period_len;
desc->buf_ptail = desc->buf_tail;
desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
@@ -817,6 +816,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
spin_lock(&sdmac->vc.lock);
+ dma_wmb();
+ bd->mode.status |= BD_DONE;
+
if (error)
sdmac->status = old_status;
}
--
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 v4 0/3] Fix UART DMA freezes for i.MX SOCs
From: Philipp Puschmann @ 2019-09-19 14:29 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
For some years and since many kernel versions there are reports that
RX UART DMA channel stops working at one point. So far the usual
workaround was to disable RX DMA. This patches fix the underlying
problem.
When a running sdma script does not find any usable destination buffer
to put its data into it just leads to stopping the channel being
scheduled again. As solution we manually retrigger the sdma script for
this channel and by this dissolve the freeze.
While this seems to work fine so far, it may come to buffer overruns
when the channel - even temporary - is stopped. This case has to be
addressed by device drivers by increasing the number of DMA periods.
This patch series was tested with the current kernel and backported to
kernel 4.15 with a special use case using a WL1837MOD via UART and
provoking the hanging of UART RX DMA within seconds after starting a
test application. It resulted in well known
"Bluetooth: hci0: command 0x0408 tx timeout"
errors and complete stop of UART data reception. Our Bluetooth traffic
consists of many independent small packets, mostly only a few bytes,
causing high usage of periods.
Changelog v4:
- fixed the fixes tags
Changelog v3:
- fixes typo in dma_wmb
- add fixes tags
Changelog v2:
- adapt title (this patches are not only for i.MX6)
- improve some comments and patch descriptions
- add a dma_wb() around BD_DONE flag
- add Reviewed-by tags
- split off "serial: imx: adapt rx buffer and dma periods"
Philipp Puschmann (3):
dmaengine: imx-sdma: fix buffer ownership
dmaengine: imx-sdma: fix dma freezes
dmaengine: imx-sdma: drop redundant variable
drivers/dma/imx-sdma.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 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 v4 2/3] dmaengine: imx-sdma: fix dma freezes
From: Philipp Puschmann @ 2019-09-19 14:29 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
In-Reply-To: <20190919142942.12469-1-philipp.puschmann@emlix.com>
For some years and since many kernel versions there are reports that the
RX UART SDMA channel stops working at some point. The workaround was to
disable DMA for RX. This commit tries to fix the problem itself.
Due to its license i wasn't able to debug the sdma script itself but it
somehow leads to blocking the scheduling of the channel script when a
running sdma script does not find any free descriptor in the ring to put
its data into.
If we detect such a potential case we manually restart the channel.
As sdmac->desc is constant we can move desc out of the loop.
Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changelog v4:
- fixed the fixes tag
Changelog v3:
- use correct dma_wmb() instead of dma_wb()
- add fixes tag
Changelog v2:
- clarify comment and commit description
drivers/dma/imx-sdma.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e029a2443cfc..a32b5962630e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
- int error = 0;
- enum dma_status old_status = sdmac->status;
+ struct sdma_desc *desc = sdmac->desc;
+ int error = 0, cnt = 0;
+ enum dma_status old_status = sdmac->status;
/*
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (sdmac->desc) {
- struct sdma_desc *desc = sdmac->desc;
+ while (desc) {
bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
+ cnt++;
+
if (bd->mode.status & BD_RROR) {
bd->mode.status &= ~BD_RROR;
sdmac->status = DMA_ERROR;
@@ -822,6 +824,17 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
if (error)
sdmac->status = old_status;
}
+
+ /* In some situations it may happen that the sdma does not found any
+ * usable descriptor in the ring to put data into. The channel is
+ * stopped then. While there is no specific error condition we can
+ * check for, a necessary condition is that all available buffers for
+ * the current channel have been written to by the sdma script. In
+ * this case and after we have made the buffers available again,
+ * we restart the channel.
+ */
+ if (cnt >= desc->num_bd)
+ sdma_enable_channel(sdmac->sdma, sdmac->channel);
}
static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
--
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 v4 3/3] dmaengine: imx-sdma: drop redundant variable
From: Philipp Puschmann @ 2019-09-19 14:29 UTC (permalink / raw)
To: linux-kernel
Cc: fugang.duan, Philipp Puschmann, festevam, s.hauer, vkoul,
linux-imx, kernel, dan.j.williams, yibin.gong, shawnguo,
dmaengine, linux-arm-kernel, l.stach
In-Reply-To: <20190919142942.12469-1-philipp.puschmann@emlix.com>
In sdma_prep_dma_cyclic buf is redundant. Drop it.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changelog v3,v4:
- no changes
Changelog v2:
- add Reviewed-by tag
drivers/dma/imx-sdma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a32b5962630e..17961451941a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1544,7 +1544,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int i = 0, buf = 0;
+ int i;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1565,7 +1565,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
goto err_bd_out;
}
- while (buf < buf_len) {
+ for (i = 0; i < num_periods; i++) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1592,9 +1592,6 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
bd->mode.status = param;
dma_addr += period_len;
- buf += period_len;
-
- i++;
}
return vchan_tx_prep(&sdmac->vc, &desc->vd, flags);
--
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 v1 2/9] mfd: wm8994: Add support for MCLKn clock control
From: Charles Keepax @ 2019-09-19 14:31 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, lgirdwood, Krzysztof Kozlowski, robh+dt,
Sylwester Nawrocki, linux-arm-kernel, m.szyprowski
In-Reply-To: <20190919125020.GJ3642@sirena.co.uk>
On Thu, Sep 19, 2019 at 01:50:20PM +0100, Mark Brown wrote:
> On Thu, Sep 19, 2019 at 09:59:24AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 18, 2019 at 12:46:27PM +0200, Sylwester Nawrocki wrote:
> > > The WM1811/WM8994/WM8958 audio CODEC DT bindings specify two optional
> > > clocks: "MCLK1", "MCLK2". Add code for getting those clocks in the MFD
> > > part of the wm8994 driver so they can be further handled in the audio
> > > CODEC part.
>
> > I think these are needed only for the codec so how about getting them in
> > codec's probe?
>
> Yeah. IIRC when these were added a machine driver was grabbing them. I
> don't think that machine driver ever made it's way upstream though.
If you mean for the Arizona stuff, the machine driver using that
was sound/soc/samsung/tm2_wm5110.c. Sylwester upstreamed it along
with the patches.
I think on wm8994 the clocks probably are only needed by the
audio part of the driver, so probably can be moved in there,
although as a disclaimer I have done a lot less with parts
of that era. However on Arizona the clocking is needed from
various parts of the driver so couldn't be moved exclusively
to the codec driver.
Thanks,
Charles
_______________________________________________
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/1] sched/rt: avoid contend with CFS task
From: Vincent Guittot @ 2019-09-19 14:32 UTC (permalink / raw)
To: Qais Yousef
Cc: wsd_upstream, Peter Zijlstra, linux-kernel, Jing-Ting Wu,
linux-mediatek, Matthias Brugger, Valentin Schneider, LAK
In-Reply-To: <20190919142315.vmrrpvljpspqpurp@e107158-lin.cambridge.arm.com>
On Thu, 19 Sep 2019 at 16:23, Qais Yousef <qais.yousef@arm.com> wrote:
>
> On 09/19/19 14:27, Vincent Guittot wrote:
> > > > > But for requirement of performance, I think it is better to differentiate between idle CPU and CPU has CFS task.
> > > > >
> > > > > For example, we use rt-app to evaluate runnable time on non-patched environment.
> > > > > There are (NR_CPUS-1) heavy CFS tasks and 1 RT Task. When a CFS task is running, the RT task wakes up and choose the same CPU.
> > > > > The CFS task will be preempted and keep runnable until it is migrated to another cpu by load balance.
> > > > > But load balance is not triggered immediately, it will be triggered until timer tick hits with some condition satisfied(ex. rq->next_balance).
> > > >
> > > > Yes you will have to wait for the next tick that will trigger an idle
> > > > load balance because you have an idle cpu and 2 runnable tack (1 RT +
> > > > 1CFS) on the same CPU. But you should not wait for more than 1 tick
> > > >
> > > > The current load_balance doesn't handle correctly the situation of 1
> > > > CFS and 1 RT task on same CPU while 1 CPU is idle. There is a rework
> > > > of the load_balance that is under review on the mailing list that
> > > > fixes this problem and your CFS task should migrate to the idle CPU
> > > > faster than now
> > > >
> > >
> > > Period load balance should be triggered when current jiffies is behind
> > > rq->next_balance, but rq->next_balance is not often exactly the same
> > > with next tick.
> > > If cpu_busy, interval = sd->balance_interval * sd->busy_factor, and
> >
> > But if there is an idle CPU on the system, the next idle load balance
> > should apply shortly because the busy_factor is not used for this CPU
> > which is not busy.
> > In this case, the next_balance interval is sd_weight which is probably
> > 4ms at cluster level and 8ms at system level in your case. This means
> > between 1 and 2 ticks
>
> But if the CFS task we're preempting was latency sensitive - this 1 or 2 tick
> is too late of a recovery.
>
> So while it's good we recover, but a preventative approach would be useful too.
> Just saying :-) I'm still not sure if this is the best longer term approach.
like using a rt task ?
>
> --
> Qais Yousef
_______________________________________________
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 4/9] ASoC: wm8994: Add support for MCLKn clock gating
From: Charles Keepax @ 2019-09-19 14:33 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, lgirdwood, krzk, robh+dt, broonie, linux-arm-kernel,
m.szyprowski
In-Reply-To: <717b3f94-1a24-a407-398f-6a476cf7ff69@samsung.com>
On Thu, Sep 19, 2019 at 01:58:35PM +0200, Sylwester Nawrocki wrote:
> On 9/18/19 16:31, Charles Keepax wrote:
> >> @@ -2315,6 +2396,8 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
> >>
> >> active_dereference(component);
> >> }
> >> + if (mclk)
> >> + clk_disable_unprepare(mclk);
> >
> > I don't think this works in the case of changing active FLLs.
> > The driver looks like it allows changing the FLL configuration
> > whilst the FLL is already active in which case it you would have
> > two wm8994_set_fll calls enabling the FLL but only a single one
> > disabling it. Resulting in the FLL being off but the MCLK being
> > left enabled.
>
> Indeed I missed this scenario, or rather assumed it won't be used.
> But since the driver allows reconfiguring active FLLs we should make
> sure such use case remains properly supported.
>
> What I came up so far as a fix is reading current FLL refclk source and
> if FLL was enabled with that source disabling refclk, before we change FLL
> configuration to new one. So we have clk_disable_unprepare(MCLK) more
> closely following FLL enable bit changes. I have tested it and it seems
> to work - something like below. Do you think it makes sense?
>
Yeah I think that looks good, it is very similar to what we did
on Arizona and I haven't found any problems with that yet :-)
Thanks,
Charles
_______________________________________________
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 2/9] mfd: wm8994: Add support for MCLKn clock control
From: Mark Brown @ 2019-09-19 14:33 UTC (permalink / raw)
To: Charles Keepax
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, lgirdwood, Krzysztof Kozlowski, robh+dt,
Sylwester Nawrocki, linux-arm-kernel, m.szyprowski
In-Reply-To: <20190919143116.GL10204@ediswmail.ad.cirrus.com>
[-- Attachment #1.1: Type: text/plain, Size: 870 bytes --]
On Thu, Sep 19, 2019 at 02:31:16PM +0000, Charles Keepax wrote:
> On Thu, Sep 19, 2019 at 01:50:20PM +0100, Mark Brown wrote:
> > Yeah. IIRC when these were added a machine driver was grabbing them. I
> > don't think that machine driver ever made it's way upstream though.
> If you mean for the Arizona stuff, the machine driver using that
> was sound/soc/samsung/tm2_wm5110.c. Sylwester upstreamed it along
> with the patches.
No, there was a WM8994 thing before that.
> I think on wm8994 the clocks probably are only needed by the
> audio part of the driver, so probably can be moved in there,
> although as a disclaimer I have done a lot less with parts
> of that era. However on Arizona the clocking is needed from
> various parts of the driver so couldn't be moved exclusively
> to the codec driver.
Yes, they're only needed by the audio part of the driver.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 17/23] mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()
From: Vignesh Raghavendra @ 2019-09-19 14:33 UTC (permalink / raw)
To: Tudor.Ambarus, boris.brezillon, marek.vasut, miquel.raynal,
richard, linux-mtd
Cc: linux-aspeed, andrew, linux-kernel, vz, linux-mediatek, joel,
matthias.bgg, computersforpeace, dwmw2, linux-arm-kernel
In-Reply-To: <20190917155426.7432-18-tudor.ambarus@microchip.com>
Hi Tudor
[...]
On 17-Sep-19 9:25 PM, Tudor.Ambarus@microchip.com wrote:
> +static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8 status_new,
> + u8 mask)
> +{
> + int ret;
> + u8 *sr_cr = nor->bouncebuf;
> + u8 cr_written;
> +
> + /* Make sure we don't overwrite the contents of Status Register 2. */
> + if (!(nor->flags & SNOR_F_NO_READ_CR)) {
Assuming SNOR_F_NO_READ_CR is not set...
> + ret = spi_nor_read_cr(nor, &sr_cr[1]);
> + if (ret)
> + return ret;
> + } else if (nor->flash.quad_enable) {
> + /*
> + * If the Status Register 2 Read command (35h) is not
> + * supported, we should at least be sure we don't
> + * change the value of the SR2 Quad Enable bit.
> + *
> + * We can safely assume that when the Quad Enable method is
> + * set, the value of the QE bit is one, as a consequence of the
> + * nor->flash.quad_enable() call.
> + *
> + * We can safely assume that the Quad Enable bit is present in
> + * the Status Register 2 at BIT(1). According to the JESD216
> + * revB standard, BFPT DWORDS[15], bits 22:20, the 16-bit
> + * Write Status (01h) command is available just for the cases
> + * in which the QE bit is described in SR2 at BIT(1).
> + */
> + sr_cr[1] = CR_QUAD_EN_SPAN;
> + } else {
> + sr_cr[1] = 0;
> + }
> +
CR_QUAD_EN_SPAN will not be in sr_cr[1] when we reach here. So code
won't enable quad mode.
> + sr_cr[0] = status_new;
> +
> + ret = spi_nor_write_sr(nor, sr_cr, 2);
> + if (ret)
> + return ret;
> +
> + cr_written = sr_cr[1];
> +
> + ret = spi_nor_read_sr(nor, &sr_cr[0]);
> + if (ret)
> + return ret;
> +
> + if ((sr_cr[0] & mask) != (status_new & mask)) {
> + dev_err(nor->dev, "Read back test failed\n");
> + return -EIO;
> + }
> +
> + if (nor->flags & SNOR_F_NO_READ_CR)
> + return 0;
> +
> + ret = spi_nor_read_cr(nor, &sr_cr[1]);
> + if (ret)
> + return ret;
> +
> + if (cr_written != sr_cr[1]) {
> + dev_err(nor->dev, "Read back test failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
Regards
Vignesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64 iommu groups issue
From: John Garry @ 2019-09-19 14:35 UTC (permalink / raw)
To: Robin Murphy, Marc Zyngier, Will Deacon, Lorenzo Pieralisi,
Sudeep Holla, Guohanjun (Hanjun Guo)
Cc: linux-kernel@vger.kernel.org, Alex Williamson, Shameer Kolothum,
Linuxarm, iommu, Bjorn Helgaas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4768c541-ebf4-61d5-0c5e-77dee83f8f94@arm.com>
On 19/09/2019 14:25, Robin Murphy wrote:
>> When the port eventually probes it gets a new, separate group.
>>
>> This all seems to be as the built-in module init ordering is as
>> follows: pcieport drv, smmu drv, mlx5 drv
>>
>> I notice that if I build the mlx5 drv as a ko and insert after boot,
>> all functions + pcieport are in the same group:
>>
>> [ 11.530046] hisi_sas_v2_hw HISI0162:01: Adding to iommu group 0
>> [ 17.301093] hns_dsaf HISI00B2:00: Adding to iommu group 1
>> [ 18.743600] ehci-platform PNP0D20:00: Adding to iommu group 2
>> [ 20.212284] pcieport 0002:f8:00.0: Adding to iommu group 3
>> [ 20.356303] pcieport 0004:88:00.0: Adding to iommu group 4
>> [ 20.493337] pcieport 0005:78:00.0: Adding to iommu group 5
>> [ 20.702999] pcieport 000a:10:00.0: Adding to iommu group 6
>> [ 20.859183] pcieport 000c:20:00.0: Adding to iommu group 7
>> [ 20.996140] pcieport 000d:30:00.0: Adding to iommu group 8
>> [ 21.152637] serial 0002:f9:00.0: Adding to iommu group 3
>> [ 21.346991] serial 0002:f9:00.1: Adding to iommu group 3
>> [ 100.754306] mlx5_core 000a:11:00.0: Adding to iommu group 6
>> [ 101.420156] mlx5_core 000a:11:00.1: Adding to iommu group 6
>> [ 292.481714] mlx5_core 000a:11:00.2: Adding to iommu group 6
>> [ 293.281061] mlx5_core 000a:11:00.3: Adding to iommu group 6
>>
>> This does seem like a problem for arm64 platforms which don't support
>> ACS, yet enable an SMMU. Maybe also a problem even if they do support
>> ACS.
>>
>> Opinion?
>
Hi Robin,
> Yeah, this is less than ideal.
For sure. Our production D05 boards don't ship with the SMMU enabled in
BIOS, but it would be slightly concerning in this regard if they did.
> One way to bodge it might be to make
> pci_device_group() also walk downwards to see if any non-ACS-isolated
> children already have a group, rather than assuming that groups get
> allocated in hierarchical order, but that's far from ideal.
Agree.
My own workaround was to hack the mentioned iort code to defer the PF
probe if the parent port had also yet to probe.
>
> The underlying issue is that, for historical reasons, OF/IORT-based
> IOMMU drivers have ended up with group allocation being tied to endpoint
> driver probing via the dma_configure() mechanism (long story short,
> driver probe is the only thing which can be delayed in order to wait for
> a specific IOMMU instance to be ready).However, in the meantime, the
> IOMMU API internals have evolved sufficiently that I think there's a way
> to really put things right - I have the spark of an idea which I'll try
> to sketch out ASAP...
>
OK, great.
Thanks,
John
> 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 1/1] sched/rt: avoid contend with CFS task
From: Vincent Guittot @ 2019-09-19 14:37 UTC (permalink / raw)
To: Qais Yousef
Cc: wsd_upstream, Peter Zijlstra, linux-kernel, Jing-Ting Wu,
linux-mediatek, Matthias Brugger, Valentin Schneider, LAK
In-Reply-To: <CAKfTPtA9-JLxs+DdLYjBQ6VfVGNxm++QYYi1wy-xS6o==EAPNw@mail.gmail.com>
On Thu, 19 Sep 2019 at 16:32, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Thu, 19 Sep 2019 at 16:23, Qais Yousef <qais.yousef@arm.com> wrote:
> >
> > On 09/19/19 14:27, Vincent Guittot wrote:
> > > > > > But for requirement of performance, I think it is better to differentiate between idle CPU and CPU has CFS task.
> > > > > >
> > > > > > For example, we use rt-app to evaluate runnable time on non-patched environment.
> > > > > > There are (NR_CPUS-1) heavy CFS tasks and 1 RT Task. When a CFS task is running, the RT task wakes up and choose the same CPU.
> > > > > > The CFS task will be preempted and keep runnable until it is migrated to another cpu by load balance.
> > > > > > But load balance is not triggered immediately, it will be triggered until timer tick hits with some condition satisfied(ex. rq->next_balance).
> > > > >
> > > > > Yes you will have to wait for the next tick that will trigger an idle
> > > > > load balance because you have an idle cpu and 2 runnable tack (1 RT +
> > > > > 1CFS) on the same CPU. But you should not wait for more than 1 tick
> > > > >
> > > > > The current load_balance doesn't handle correctly the situation of 1
> > > > > CFS and 1 RT task on same CPU while 1 CPU is idle. There is a rework
> > > > > of the load_balance that is under review on the mailing list that
> > > > > fixes this problem and your CFS task should migrate to the idle CPU
> > > > > faster than now
> > > > >
> > > >
> > > > Period load balance should be triggered when current jiffies is behind
> > > > rq->next_balance, but rq->next_balance is not often exactly the same
> > > > with next tick.
> > > > If cpu_busy, interval = sd->balance_interval * sd->busy_factor, and
> > >
> > > But if there is an idle CPU on the system, the next idle load balance
> > > should apply shortly because the busy_factor is not used for this CPU
> > > which is not busy.
> > > In this case, the next_balance interval is sd_weight which is probably
> > > 4ms at cluster level and 8ms at system level in your case. This means
> > > between 1 and 2 ticks
> >
> > But if the CFS task we're preempting was latency sensitive - this 1 or 2 tick
> > is too late of a recovery.
> >
> > So while it's good we recover, but a preventative approach would be useful too.
> > Just saying :-) I'm still not sure if this is the best longer term approach.
>
> like using a rt task ?
I mean, RT task should select a sub optimal CPU because of CFS
If you want to favor CFS compared to RT it's probably because your
task should be RT too
>
> >
> > --
> > Qais Yousef
_______________________________________________
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 00/23] mtd: spi-nor: Quad Enable and (un)lock methods
From: Vignesh Raghavendra @ 2019-09-19 14:37 UTC (permalink / raw)
To: Tudor.Ambarus, boris.brezillon, marek.vasut, miquel.raynal,
richard, linux-mtd
Cc: linux-aspeed, andrew, linux-kernel, vz, linux-mediatek, joel,
matthias.bgg, computersforpeace, dwmw2, linux-arm-kernel
In-Reply-To: <20190917155426.7432-1-tudor.ambarus@microchip.com>
Hi,
On 17-Sep-19 9:24 PM, Tudor.Ambarus@microchip.com wrote:
> From: Tudor Ambarus <tudor.ambarus@microchip.com>
>
[...]
> Tudor Ambarus (23):
> mtd: spi-nor: hisi-sfc: Drop nor->erase NULL assignment
> mtd: spi-nor: Introduce 'struct spi_nor_controller_ops'
> mtd: spi-nor: cadence-quadspi: Fix cqspi_command_read() definition
> mtd: spi-nor: Rename nor->params to nor->flash
> mtd: spi-nor: Rework read_sr()
> mtd: spi-nor: Rework read_fsr()
> mtd: spi-nor: Rework read_cr()
> mtd: spi-nor: Rework write_enable/disable()
> mtd: spi-nor: Fix retlen handling in sst_write()
> mtd: spi-nor: Rework write_sr()
> mtd: spi-nor: Rework spi_nor_read/write_sr2()
> mtd: spi-nor: Report error in spi_nor_xread_sr()
> mtd: spi-nor: Void return type for spi_nor_clear_sr/fsr()
> mtd: spi-nor: Drop duplicated new line
> mtd: spi-nor: Drop spansion_quad_enable()
> mtd: spi-nor: Fix errno on quad_enable methods
> mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()
> mtd: spi-nor: Rework macronix_quad_enable()
> mtd: spi-nor: Rework spansion(_no)_read_cr_quad_enable()
> mtd: spi-nor: Update sr2_bit7_quad_enable()
> mtd: spi-nor: Rework the disabling of block write protection
> mtd: spi-nor: Add Global Block Unlock support
> mtd: spi-nor: Unlock global block protection on sst26vf064b
With whole series applied, I see:
drivers/mtd/spi-nor/spi-nor.c:520: warning: Function parameter or member 'cr' not described in 'spi_nor_read_cr'
drivers/mtd/spi-nor/spi-nor.c:520: warning: Excess function parameter 'fsr' description in 'spi_nor_read_cr'
drivers/mtd/spi-nor/spi-nor.c:742: warning: Function parameter or member 'len' not described in 'spi_nor_write_sr'
drivers/mtd/spi-nor/spi-nor.c:889: warning: Function parameter or member 'status_new' not described in 'spi_nor_write_sr1_and_check'
drivers/mtd/spi-nor/spi-nor.c:889: warning: Function parameter or member 'mask' not described in 'spi_nor_write_sr1_and_check'
drivers/mtd/spi-nor/spi-nor.c:923: warning: Function parameter or member 'status_new' not described in 'spi_nor_write_16bit_sr_and_check'
drivers/mtd/spi-nor/spi-nor.c:923: warning: Function parameter or member 'mask' not described in 'spi_nor_write_16bit_sr_and_check'
drivers/mtd/spi-nor/spi-nor.c:997: warning: Function parameter or member 'status_new' not described in 'spi_nor_write_sr_and_check'
drivers/mtd/spi-nor/spi-nor.c:997: warning: Function parameter or member 'mask' not described in 'spi_nor_write_sr_and_check'
Could you please fix up docs next time around?
Regards
Vignesh
>
> drivers/mtd/spi-nor/aspeed-smc.c | 23 +-
> drivers/mtd/spi-nor/cadence-quadspi.c | 54 +-
> drivers/mtd/spi-nor/hisi-sfc.c | 23 +-
> drivers/mtd/spi-nor/intel-spi.c | 24 +-
> drivers/mtd/spi-nor/mtk-quadspi.c | 25 +-
> drivers/mtd/spi-nor/nxp-spifi.c | 23 +-
> drivers/mtd/spi-nor/spi-nor.c | 1697 ++++++++++++++++++---------------
> include/linux/mtd/spi-nor.h | 75 +-
> 8 files changed, 1050 insertions(+), 894 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] serial: imx: adapt rx buffer and dma periods
From: Philipp Puschmann @ 2019-09-19 14:51 UTC (permalink / raw)
To: linux-kernel
Cc: festevam, fugang.duan, linux-serial, gregkh, s.hauer,
u.kleine-koenig, linux-imx, kernel, jslaby, Philipp Puschmann,
yibin.gong, shawnguo, linux-arm-kernel, l.stach
Using only 4 DMA periods for UART RX is very few if we have a high
frequency of small transfers - like in our case using Bluetooth with
many small packets via UART - causing many dma transfers but in each
only filling a fraction of a single buffer. Such a case may lead to
the situation that DMA RX transfer is triggered but no free buffer is
available. When this happens dma channel ist stopped - with the patch
"dmaengine: imx-sdma: fix dma freezes" temporarily only - with the
possible consequences that:
with disabled hw flow control:
If enough data is incoming on UART port the RX FIFO runs over and
characters will be lost. What then happens depends on upper layer.
with enabled hw flow control:
If enough data is incoming on UART port the RX FIFO reaches a level
where CTS is deasserted and remote device sending the data stops.
If it fails to stop timely the i.MX' RX FIFO may run over and data
get lost. Otherwise it's internal TX buffer may getting filled to
a point where it runs over and data is again lost. It depends on
the remote device how this case is handled and if it is recoverable.
Obviously we want to avoid having no free buffers available. So we
decrease the size of the buffers and increase their number and the
total buffer size.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changelog v3:
- enhance description
Changelog v2:
- split this patch from series "Fix UART DMA freezes for iMX6"
- add Reviewed-by tag
drivers/tty/serial/imx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 87c58f9f6390..51dc19833eab 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct timer_list *t)
}
}
-#define RX_BUF_SIZE (PAGE_SIZE)
-
/*
* There are two kinds of RX DMA interrupts(such as in the MX6Q):
* [1] the RX DMA buffer is full.
@@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void *data)
}
/* RX DMA buffer periods */
-#define RX_DMA_PERIODS 4
+#define RX_DMA_PERIODS 16
+#define RX_BUF_SIZE (PAGE_SIZE / 4)
static int imx_uart_start_rx_dma(struct imx_port *sport)
{
--
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/8] iommu/arm-smmu-v3: Support platform SSID
From: Jean-Philippe Brucker @ 2019-09-19 14:51 UTC (permalink / raw)
To: Auger Eric
Cc: mark.rutland, devicetree, jacob.jun.pan, robin.murphy, joro,
linux-kernel, iommu, robh+dt, will, linux-arm-kernel
In-Reply-To: <63d4a71a-8e3f-f663-34bc-6647971b7e4b@redhat.com>
Hi Eric,
Sorry for the delay. I'll see if I can resend this for v5.5, although I
can't do much testing at the moment.
On Mon, Jul 08, 2019 at 09:58:22AM +0200, Auger Eric wrote:
> Hi Jean,
>
> On 6/10/19 8:47 PM, Jean-Philippe Brucker wrote:
> > For platform devices that support SubstreamID (SSID), firmware provides
> > the number of supported SSID bits. Restrict it to what the SMMU supports
> > and cache it into master->ssid_bits.
> The commit message may give the impression the master's ssid_bits field
> only is used for platform devices.
Ok maybe I should add that this field will be used for PCI PASID as
well.
> > @@ -2097,6 +2098,16 @@ static int arm_smmu_add_device(struct device *dev)
> > }
> > }
> >
> > + master->ssid_bits = min(smmu->ssid_bits, fwspec->num_pasid_bits);
> In case the device is a PCI device, what is the value taken by
> fwspec->num_pasid_bits?
It would be zero, as firmware only specifies a value for platform
devices. For a PCI device, patch 8/8 fills master->ssid_bits from the
PCIe PASID capability.
> > + /*
> > + * If the SMMU doesn't support 2-stage CD, limit the linear
> > + * tables to a reasonable number of contexts, let's say
> > + * 64kB / sizeof(ctx_desc) = 1024 = 2^10
> ctx_desc is 26B so 11bits would be OK
This refers to the size of the hardware context descriptor, not struct
arm_smmu_ctx_desc. Next version moves this to a define and makes it
clearer.
Thanks,
Jean
_______________________________________________
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 v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-19 14:57 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Catalin Marinas, linux-mm, Punit Agrawal,
Will Deacon, Alex Van Brunt, Jia He, Marc Zyngier,
Anshuman Khandual, Matthew Wilcox, Jun Yao, Kaly Xin,
Ralph Campbell, Suzuki Poulose, Jérôme Glisse,
Thomas Gleixner, linux-arm-kernel, linux-kernel, James Morse,
Andrew Morton, Robin Murphy, Kirill A. Shutemov
In-Reply-To: <bebe97e1-b1fe-7f36-91c0-7d412f093560@gmail.com>
On Thu, Sep 19, 2019 at 10:16:34AM +0800, Jia He wrote:
> Hi Kirill
>
> [On behalf of justin.he@arm.com because some mails are filted...]
>
> On 2019/9/18 22:00, Kirill A. Shutemov wrote:
> > On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> > > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> > > will be a double page fault in __copy_from_user_inatomic of cow_user_page.
> > >
> > > Below call trace is from arm64 do_page_fault for debugging purpose
> > > [ 110.016195] Call trace:
> > > [ 110.016826] do_page_fault+0x5a4/0x690
> > > [ 110.017812] do_mem_abort+0x50/0xb0
> > > [ 110.018726] el1_da+0x20/0xc4
> > > [ 110.019492] __arch_copy_from_user+0x180/0x280
> > > [ 110.020646] do_wp_page+0xb0/0x860
> > > [ 110.021517] __handle_mm_fault+0x994/0x1338
> > > [ 110.022606] handle_mm_fault+0xe8/0x180
> > > [ 110.023584] do_page_fault+0x240/0x690
> > > [ 110.024535] do_mem_abort+0x50/0xb0
> > > [ 110.025423] el0_da+0x20/0x24
> > >
> > > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> > > [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
> > >
> > > As told by Catalin: "On arm64 without hardware Access Flag, copying from
> > > user will fail because the pte is old and cannot be marked young. So we
> > > always end up with zeroed page after fork() + CoW for pfn mappings. we
> > > don't always have a hardware-managed access flag on arm64."
> > >
> > > This patch fix it by calling pte_mkyoung. Also, the parameter is
> > > changed because vmf should be passed to cow_user_page()
> > >
> > > [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> > >
> > > Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> > > Signed-off-by: Jia He <justin.he@arm.com>
> > > ---
> > > mm/memory.c | 35 ++++++++++++++++++++++++++++++-----
> > > 1 file changed, 30 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index e2bb51b6242e..d2c130a5883b 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > > 2;
> > > #endif
> > > +#ifndef arch_faults_on_old_pte
> > > +static inline bool arch_faults_on_old_pte(void)
> > > +{
> > > + return false;
> > > +}
> > > +#endif
> > > +
> > > static int __init disable_randmaps(char *s)
> > > {
> > > randomize_va_space = 0;
> > > @@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
> > > return same;
> > > }
> > > -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> > > +static inline void cow_user_page(struct page *dst, struct page *src,
> > > + struct vm_fault *vmf)
> > > {
> > > + struct vm_area_struct *vma = vmf->vma;
> > > + unsigned long addr = vmf->address;
> > > +
> > > debug_dma_assert_idle(src);
> > > /*
> > > @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> > > */
> > > if (unlikely(!src)) {
> > > void *kaddr = kmap_atomic(dst);
> > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> > > + pte_t entry;
> > > /*
> > > * This really shouldn't fail, because the page is there
> > > * in the page tables. But it might just be unreadable,
> > > * in which case we just give up and fill the result with
> > > - * zeroes.
> > > + * zeroes. On architectures with software "accessed" bits,
> > > + * we would take a double page fault here, so mark it
> > > + * accessed here.
> > > */
> > > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> > > + spin_lock(vmf->ptl);
> > > + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> > > + entry = pte_mkyoung(vmf->orig_pte);
> > > + if (ptep_set_access_flags(vma, addr,
> > > + vmf->pte, entry, 0))
> > > + update_mmu_cache(vma, addr, vmf->pte);
> > > + }
> > I don't follow.
> >
> > So if pte has changed under you, you don't set the accessed bit, but never
> > the less copy from the user.
> >
> > What makes you think it will not trigger the same problem?
> >
> > I think we need to make cow_user_page() fail in this case and caller --
> > wp_page_copy() -- return zero. If the fault was solved by other thread, we
> > are fine. If not userspace would re-fault on the same address and we will
> > handle the fault from the second attempt.
>
> Thanks for the pointing. How about make cow_user_page() be returned
>
> VM_FAULT_RETRY? Then in do_page_fault(), it can retry the page fault?
No. VM_FAULT_RETRY has different semantics: we have to drop mmap_sem(), so
let's try to take it again and handle the fault. In this case the more
likely scenario is that other thread has already handled the fault and we
don't need to do anything. If it's not the case, the fault will be
triggered again on the same address.
--
Kirill A. Shutemov
_______________________________________________
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/8] iommu/arm-smmu-v3: Add support for Substream IDs
From: Jean-Philippe Brucker @ 2019-09-19 14:57 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, devicetree, jacob.jun.pan, joro, linux-kernel,
eric.auger, iommu, robh+dt, robin.murphy, linux-arm-kernel
In-Reply-To: <20190626180025.g4clm6qnbbna65de@willie-the-truck>
On Wed, Jun 26, 2019 at 07:00:26PM +0100, Will Deacon wrote:
> On Mon, Jun 10, 2019 at 07:47:10PM +0100, Jean-Philippe Brucker wrote:
> > In all stream table entries, we set S1DSS=SSID0 mode, making translations
> > without an SSID use context descriptor 0. Although it would be possible by
> > setting S1DSS=BYPASS, we don't currently support SSID when user selects
> > iommu.passthrough.
>
> I don't understand your comment here: iommu.passthrough works just as it did
> before, right, since we set bypass in the STE config field so S1DSS is not
> relevant?
What isn't supported is bypassing translation *only* for transactions
without SSID, and using context descriptors for anything with SSID. I
don't know if such a mode would be useful, but I can drop that sentence
to avoid confusion.
> I also notice that SSID0 causes transactions with SSID==0 to
> abort. Is a PASID of 0 reserved, so this doesn't matter?
Yes, we never allocate PASID 0.
>
> > @@ -1062,33 +1143,90 @@ static u64 arm_smmu_cpu_tcr_to_cd(u64 tcr)
> > return val;
> > }
> >
> > -static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu,
> > - struct arm_smmu_s1_cfg *cfg)
> > +static int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain,
> > + int ssid, struct arm_smmu_ctx_desc *cd)
> > {
> > u64 val;
> > + bool cd_live;
> > + struct arm_smmu_device *smmu = smmu_domain->smmu;
> > + __le64 *cdptr = arm_smmu_get_cd_ptr(&smmu_domain->s1_cfg, ssid);
> >
> > /*
> > - * We don't need to issue any invalidation here, as we'll invalidate
> > - * the STE when installing the new entry anyway.
> > + * This function handles the following cases:
> > + *
> > + * (1) Install primary CD, for normal DMA traffic (SSID = 0).
> > + * (2) Install a secondary CD, for SID+SSID traffic.
> > + * (3) Update ASID of a CD. Atomically write the first 64 bits of the
> > + * CD, then invalidate the old entry and mappings.
> > + * (4) Remove a secondary CD.
> > */
> > - val = arm_smmu_cpu_tcr_to_cd(cfg->cd.tcr) |
> > +
> > + if (!cdptr)
> > + return -ENOMEM;
> > +
> > + val = le64_to_cpu(cdptr[0]);
> > + cd_live = !!(val & CTXDESC_CD_0_V);
> > +
> > + if (!cd) { /* (4) */
> > + cdptr[0] = 0;
>
> Should we be using WRITE_ONCE here? (although I notice we don't seem to
> bother for STEs either...)
Yes, I think it makes sense
Thanks,
Jean
_______________________________________________
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 v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-19 15:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, linux-mm, Punit Agrawal, Will Deacon,
Alex Van Brunt, Jia He, Marc Zyngier, Anshuman Khandual,
Matthew Wilcox, Jun Yao, Kaly Xin, hejianet, Ralph Campbell,
Suzuki Poulose, Jérôme Glisse, Thomas Gleixner,
linux-arm-kernel, linux-kernel, James Morse, Andrew Morton,
Robin Murphy, Kirill A. Shutemov
In-Reply-To: <20190918180029.GB20601@iMac.local>
On Wed, Sep 18, 2019 at 07:00:30PM +0100, Catalin Marinas wrote:
> On Wed, Sep 18, 2019 at 05:00:27PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> > > @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> > > */
> > > if (unlikely(!src)) {
> > > void *kaddr = kmap_atomic(dst);
> > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> > > + pte_t entry;
> > >
> > > /*
> > > * This really shouldn't fail, because the page is there
> > > * in the page tables. But it might just be unreadable,
> > > * in which case we just give up and fill the result with
> > > - * zeroes.
> > > + * zeroes. On architectures with software "accessed" bits,
> > > + * we would take a double page fault here, so mark it
> > > + * accessed here.
> > > */
> > > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> > > + spin_lock(vmf->ptl);
> > > + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> > > + entry = pte_mkyoung(vmf->orig_pte);
> > > + if (ptep_set_access_flags(vma, addr,
> > > + vmf->pte, entry, 0))
> > > + update_mmu_cache(vma, addr, vmf->pte);
> > > + }
> >
> > I don't follow.
> >
> > So if pte has changed under you, you don't set the accessed bit, but never
> > the less copy from the user.
> >
> > What makes you think it will not trigger the same problem?
> >
> > I think we need to make cow_user_page() fail in this case and caller --
> > wp_page_copy() -- return zero. If the fault was solved by other thread, we
> > are fine. If not userspace would re-fault on the same address and we will
> > handle the fault from the second attempt.
>
> It would be nice to clarify the semantics of this function and do as
> you suggest but the current comment is slightly confusing:
>
> /*
> * If the source page was a PFN mapping, we don't have
> * a "struct page" for it. We do a best-effort copy by
> * just copying from the original user address. If that
> * fails, we just zero-fill it. Live with it.
> */
>
> Would any user-space rely on getting a zero-filled page here instead of
> a recursive fault?
I don't see the point in zero-filled page in this case. SIGBUS sounds like
more appropriate response, no?
--
Kirill A. Shutemov
_______________________________________________
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] arm64: dts: freescale: add initial support for colibri imx8x
From: Oleksandr Suvorov @ 2019-09-19 15:00 UTC (permalink / raw)
To: Marcel Ziswiler
Cc: Aisheng Dong, devicetree, Sascha Hauer, Pramod Kumar,
Marcel Ziswiler, Shawn Guo, Bhaskar Upadhaya, Jon Nettleton,
linux-kernel, Li Yang, Rob Herring, Vabhav Sharma, NXP Linux Team,
Pengutronix Kernel Team, Manivannan Sadhasivam, Mark Rutland,
Fabio Estevam, Richard Hu, linux-arm-kernel, Lucas Stach
In-Reply-To: <20190916130427.20413-1-marcel@ziswiler.com>
On Mon, Sep 16, 2019 at 4:11 PM Marcel Ziswiler <marcel@ziswiler.com> wrote:
>
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> This patch adds the device tree to support Toradex Colibri iMX8X a
> computer on module which can be used on different carrier boards.
>
> The module consists of a NXP i.MX 8X family SoC (either i.MX 8DualX or
> 8QuadXPlus), a PF8100 PMIC, a FastEthernet PHY, 1 or 2 GB of LPDDR4
> RAM, some level shifters, a Micron eMMC, a USB hub, an AD7879 resistive
> touch controller, a SGTL5000 audio codec and on-module CSI as well as
> DSI-LVDS FFC receptacles plus an optional Bluetooth/Wi-Fi module.
>
> Anything that is not self-contained on the module is disabled by
> default.
>
> The device tree for the Colibri Evaluation Board includes the module's
> device tree and enables the supported peripherals of the carrier board
> (the Colibri Evaluation Board supports almost all of them).
>
> So far there is no display or USB functionality supported at all but
> basic console UART, eMMC and Ethernet functionality work fine.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
>
> ---
>
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../dts/freescale/imx8qxp-colibri-eval-v3.dts | 15 +
> .../freescale/imx8qxp-colibri-eval-v3.dtsi | 62 ++
> .../boot/dts/freescale/imx8qxp-colibri.dtsi | 592 ++++++++++++++++++
> 4 files changed, 670 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 93fce8f0c66d..bd3764e52cfd 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -31,4 +31,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-eval-v3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
> new file mode 100644
> index 000000000000..85fc800c348f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8qxp-colibri.dtsi"
> +#include "imx8qxp-colibri-eval-v3.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX8QXP/DX on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri-imx8qxp-eval-v3",
> + "toradex,colibri-imx8qxp", "fsl,imx8qxp";
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
> new file mode 100644
> index 000000000000..f5e4f380755c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
> @@ -0,0 +1,62 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex
> + */
> +
> +#include "dt-bindings/input/linux-event-codes.h"
> +
> +/ {
> + aliases {
> + rtc0 = &rtc_i2c;
> + rtc1 = &rtc;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpiokeys>;
> +
> + power {
> + label = "Wake-Up";
> + gpios = <&lsio_gpio3 10 GPIO_ACTIVE_HIGH>;
> + linux,code = <KEY_WAKEUP>;
> + debounce-interval = <10>;
> + gpio-key,wakeup;
> + };
> + };
> +};
> +
> +/* Colibri Ethernet */
> +&fec1 {
> + status = "okay";
> +};
> +
> +&adma_i2c1 {
> + status = "okay";
> +
> + /* M41T0M6 real time clock on carrier board */
> + rtc_i2c: rtc@68 {
> + compatible = "st,m41t0";
> + reg = <0x68>;
> + };
> +};
> +
> +/* Colibri UART_B */
> +&adma_lpuart0 {
> + status= "okay";
> +};
> +
> +/* Colibri UART_C */
> +&adma_lpuart2 {
> + status= "okay";
> +};
> +
> +/* Colibri UART_A */
> +&adma_lpuart3 {
> + status= "okay";
> +};
> +
> +/* Colibri SDCard */
> +&usdhc2 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
> new file mode 100644
> index 000000000000..efdc332d082e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
> @@ -0,0 +1,592 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex
> + */
> +
> +#include "imx8qxp.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX8QXP/DX Module";
> + compatible = "toradex,colibri-imx8x", "fsl,imx8qxp";
> +
> + chosen {
> + stdout-path = &adma_lpuart3;
> + };
> +
> + reg_module_3v3: regulator-module-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "+V3.3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +};
> +
> +/* Colibri Ethernet */
> +&fec1 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_fec1>;
> + pinctrl-1 = <&pinctrl_fec1_sleep>;
> + phy-mode = "rmii";
> + phy-handle = <ðphy0>;
> + fsl,magic-packet;
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@2 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + max-speed = <100>;
> + reg = <2>;
> + };
> + };
> +};
> +
> +/* On-module I2C */
> +&adma_i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c0>, <&pinctrl_sgtl5000_usb_clk>;
> + status = "okay";
> +
> + /* Touch controller */
> + ad7879@2c {
> + compatible = "adi,ad7879-1";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ad7879_int>;
> + reg = <0x2c>;
> + interrupt-parent = <&lsio_gpio3>;
> + interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
> + touchscreen-max-pressure = <4096>;
> + adi,resistance-plate-x = <120>;
> + adi,first-conversion-delay = /bits/ 8 <3>;
> + adi,acquisition-time = /bits/ 8 <1>;
> + adi,median-filter-size = /bits/ 8 <2>;
> + adi,averaging = /bits/ 8 <1>;
> + adi,conversion-interval = /bits/ 8 <255>;
> + };
> +};
> +
> +/* Colibri I2C */
> +&adma_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog0>, <&pinctrl_hog1>, <&pinctrl_ext_io0>;
> +
> + colibri-imx8qxp {
> + /* On-module touch pen-down interrupt */
> + pinctrl_ad7879_int: ad7879-int {
> + fsl,pins = <
> + IMX8QXP_MIPI_CSI0_I2C0_SCL_LSIO_GPIO3_IO05 0x21
> + >;
> + };
> +
> + /* Colibri Analogue Inputs */
> + pinctrl_adc0: adc0grp {
> + fsl,pins = <
> + IMX8QXP_ADC_IN0_ADMA_ADC_IN0 0x60 /* SODIMM 8 */
> + IMX8QXP_ADC_IN1_ADMA_ADC_IN1 0x60 /* SODIMM 6 */
> + IMX8QXP_ADC_IN4_ADMA_ADC_IN4 0x60 /* SODIMM 4 */
> + IMX8QXP_ADC_IN5_ADMA_ADC_IN5 0x60 /* SODIMM 2 */
> + >;
> + };
> +
> + pinctrl_can_int: can-int-grp {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_DQS_LSIO_GPIO3_IO13 0x40 /* SODIMM 73 */
> + >;
> + };
> +
> + pinctrl_csi_ctl: csictlgrp {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_SS0_B_LSIO_GPIO3_IO14 0x20 /* SODIMM 77 */
> + IMX8QXP_QSPI0A_SS1_B_LSIO_GPIO3_IO15 0x20 /* SODIMM 89 */
> + >;
> + };
> +
> + pinctrl_gpiokeys: gpiokeysgrp {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_DATA1_LSIO_GPIO3_IO10 0x20 /* SODIMM 45 */
> + >;
> + };
> +
> + /* Colibri UART_B */
> + pinctrl_lpuart0: lpuart0grp {
> + fsl,pins = <
> + IMX8QXP_UART0_RX_ADMA_UART0_RX 0x06000020 /* SODIMM 36 */
> + IMX8QXP_UART0_TX_ADMA_UART0_TX 0x06000020 /* SODIMM 38 */
> + IMX8QXP_FLEXCAN0_RX_ADMA_UART0_RTS_B 0x06000020 /* SODIMM 34 */
> + IMX8QXP_FLEXCAN0_TX_ADMA_UART0_CTS_B 0x06000020 /* SODIMM 32 */
> + >;
> + };
> +
> + /* Colibri UART_C */
> + pinctrl_lpuart2: lpuart2grp {
> + fsl,pins = <
> + IMX8QXP_UART2_RX_ADMA_UART2_RX 0x06000020 /* SODIMM 19 */
> + IMX8QXP_UART2_TX_ADMA_UART2_TX 0x06000020 /* SODIMM 21 */
> + >;
> + };
> +
> + /* Colibri UART_A */
> + pinctrl_lpuart3: lpuart3grp {
> + fsl,pins = <
> + IMX8QXP_FLEXCAN2_RX_ADMA_UART3_RX 0x06000020 /* SODIMM 33 */
> + IMX8QXP_FLEXCAN2_TX_ADMA_UART3_TX 0x06000020 /* SODIMM 35 */
> + >;
> + };
> +
> + /* Colibri UART_A Control */
> + pinctrl_lpuart3_ctrl: lpuart3ctrlgrp {
> + fsl,pins = <
> + IMX8QXP_MIPI_DSI1_GPIO0_01_LSIO_GPIO2_IO00 0x20 /* SODIMM 23 */
> + IMX8QXP_SAI1_RXD_LSIO_GPIO0_IO29 0x20 /* SODIMM 25 */
> + IMX8QXP_SAI1_RXC_LSIO_GPIO0_IO30 0x20 /* SODIMM 27 */
> + IMX8QXP_CSI_RESET_LSIO_GPIO3_IO03 0x20 /* SODIMM 29 */
> + IMX8QXP_USDHC1_CD_B_LSIO_GPIO4_IO22 0x20 /* SODIMM 31 */
> + IMX8QXP_CSI_EN_LSIO_GPIO3_IO02 0x20 /* SODIMM 37 */
> + >;
> + };
> +
> + /* Colibri Ethernet: On-module 100Mbps PHY Micrel KSZ8041 */
> + pinctrl_fec1: fec1grp {
> + fsl,pins = <
> + IMX8QXP_ENET0_MDC_CONN_ENET0_MDC 0x06000020
> + IMX8QXP_ENET0_MDIO_CONN_ENET0_MDIO 0x06000020
> + IMX8QXP_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x61
> + IMX8QXP_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT 0x06000061
> + IMX8QXP_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x61
> + IMX8QXP_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x61
> + IMX8QXP_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x61
> + IMX8QXP_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x61
> + IMX8QXP_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x61
> + IMX8QXP_ENET0_RGMII_RXD2_CONN_ENET0_RMII_RX_ER 0x61
> + >;
> + };
> +
> + pinctrl_fec1_sleep: fec1-sleep-grp {
> + fsl,pins = <
> + IMX8QXP_ENET0_MDC_LSIO_GPIO5_IO11 0x06000041
> + IMX8QXP_ENET0_MDIO_LSIO_GPIO5_IO10 0x06000041
> + IMX8QXP_ENET0_RGMII_TX_CTL_LSIO_GPIO4_IO30 0x41
> + IMX8QXP_ENET0_RGMII_TXC_LSIO_GPIO4_IO29 0x41
> + IMX8QXP_ENET0_RGMII_TXD0_LSIO_GPIO4_IO31 0x41
> + IMX8QXP_ENET0_RGMII_TXD1_LSIO_GPIO5_IO00 0x41
> + IMX8QXP_ENET0_RGMII_RX_CTL_LSIO_GPIO5_IO04 0x41
> + IMX8QXP_ENET0_RGMII_RXD0_LSIO_GPIO5_IO05 0x41
> + IMX8QXP_ENET0_RGMII_RXD1_LSIO_GPIO5_IO06 0x41
> + IMX8QXP_ENET0_RGMII_RXD2_LSIO_GPIO5_IO07 0x41
> + >;
> + };
> +
> + /* Colibri LCD Back-Light GPIO */
> + pinctrl_gpio_bl_on: gpio-bl-on {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_DATA3_LSIO_GPIO3_IO12 0x60 /* SODIMM 71 */
> + >;
> + };
> +
> + pinctrl_hog0: hog0grp {
> + fsl,pins = <
> + IMX8QXP_ENET0_RGMII_TXD3_LSIO_GPIO5_IO02 0x06000020 /* SODIMM 65 */
> + IMX8QXP_CSI_D07_CI_PI_D09 0x61 /* SODIMM 65 */
> + IMX8QXP_QSPI0A_DATA2_LSIO_GPIO3_IO11 0x20 /* SODIMM 69 */
> + IMX8QXP_SAI0_TXC_LSIO_GPIO0_IO26 0x20 /* SODIMM 79 */
> + IMX8QXP_CSI_D02_CI_PI_D04 0x61 /* SODIMM 79 */
> + IMX8QXP_ENET0_RGMII_RXC_LSIO_GPIO5_IO03 0x06000020 /* SODIMM 85 */
> + IMX8QXP_CSI_D06_CI_PI_D08 0x61 /* SODIMM 85 */
> + IMX8QXP_QSPI0B_SCLK_LSIO_GPIO3_IO17 0x20 /* SODIMM 95 */
> + IMX8QXP_SAI0_RXD_LSIO_GPIO0_IO27 0x20 /* SODIMM 97 */
> + IMX8QXP_CSI_D03_CI_PI_D05 0x61 /* SODIMM 97 */
> + IMX8QXP_QSPI0B_DATA0_LSIO_GPIO3_IO18 0x20 /* SODIMM 99 */
> + IMX8QXP_SAI0_TXFS_LSIO_GPIO0_IO28 0x20 /* SODIMM 101 */
> + IMX8QXP_CSI_D00_CI_PI_D02 0x61 /* SODIMM 101 */
> + IMX8QXP_SAI0_TXD_LSIO_GPIO0_IO25 0x20 /* SODIMM 103 */
> + IMX8QXP_CSI_D01_CI_PI_D03 0x61 /* SODIMM 103 */
> + IMX8QXP_QSPI0B_DATA1_LSIO_GPIO3_IO19 0x20 /* SODIMM 105 */
> + IMX8QXP_QSPI0B_DATA2_LSIO_GPIO3_IO20 0x20 /* SODIMM 107 */
> + IMX8QXP_USB_SS3_TC2_LSIO_GPIO4_IO05 0x20 /* SODIMM 127 */
> + IMX8QXP_USB_SS3_TC3_LSIO_GPIO4_IO06 0x20 /* SODIMM 131 */
> + IMX8QXP_USB_SS3_TC1_LSIO_GPIO4_IO04 0x20 /* SODIMM 133 */
> + IMX8QXP_CSI_PCLK_LSIO_GPIO3_IO00 0x20 /* SODIMM 96 */
> + IMX8QXP_QSPI0B_DATA3_LSIO_GPIO3_IO21 0x20 /* SODIMM 98 */
> + IMX8QXP_SAI1_RXFS_LSIO_GPIO0_IO31 0x20 /* SODIMM 100 */
> + IMX8QXP_QSPI0B_DQS_LSIO_GPIO3_IO22 0x20 /* SODIMM 102 */
> + IMX8QXP_QSPI0B_SS0_B_LSIO_GPIO3_IO23 0x20 /* SODIMM 104 */
> + IMX8QXP_QSPI0B_SS1_B_LSIO_GPIO3_IO24 0x20 /* SODIMM 106 */
> + >;
> + };
> +
> + pinctrl_hog1: hog1grp {
> + fsl,pins = <
> + IMX8QXP_CSI_MCLK_LSIO_GPIO3_IO01 0x20 /* SODIMM 75 */
> + IMX8QXP_QSPI0A_SCLK_LSIO_GPIO3_IO16 0x20 /* SODIMM 93 */
> + >;
> + };
> +
> + /*
> + * This pin is used in the SCFW as a UART. Using it from
> + * Linux would require rewritting the SCFW board file.
> + */
> + pinctrl_hog_scfw: hogscfwgrp {
> + fsl,pins = <
> + IMX8QXP_SCU_GPIO0_00_LSIO_GPIO2_IO03 0x20 /* SODIMM 144 */
> + >;
> + };
> +
> + /* On Module I2C */
> + pinctrl_i2c0: i2c0grp {
> + fsl,pins = <
> + IMX8QXP_MIPI_CSI0_GPIO0_00_ADMA_I2C0_SCL 0x06000021
> + IMX8QXP_MIPI_CSI0_GPIO0_01_ADMA_I2C0_SDA 0x06000021
> + >;
> + };
> +
> + /* Colibri I2C */
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + IMX8QXP_MIPI_DSI0_GPIO0_00_ADMA_I2C1_SCL 0x06000021 /* SODIMM 196 */
> + IMX8QXP_MIPI_DSI0_GPIO0_01_ADMA_I2C1_SDA 0x06000021 /* SODIMM 194 */
> + >;
> + };
> +
> + /* Colibri optional CAN on UART_B RTS/CTS */
> + pinctrl_flexcan1: flexcan0grp {
> + fsl,pins = <
> + IMX8QXP_FLEXCAN0_TX_ADMA_FLEXCAN0_TX 0x21 /* SODIMM 32 */
> + IMX8QXP_FLEXCAN0_RX_ADMA_FLEXCAN0_RX 0x21 /* SODIMM 34 */
> + >;
> + };
> +
> + /* Colibri optional CAN on PS2 */
> + pinctrl_flexcan2: flexcan1grp {
> + fsl,pins = <
> + IMX8QXP_FLEXCAN1_TX_ADMA_FLEXCAN1_TX 0x21 /* SODIMM 55 */
> + IMX8QXP_FLEXCAN1_RX_ADMA_FLEXCAN1_RX 0x21 /* SODIMM 63 */
> + >;
> + };
> +
> + /* On module wifi module */
> + pinctrl_pcieb: pciebgrp {
> + fsl,pins = <
> + IMX8QXP_PCIE_CTRL0_CLKREQ_B_LSIO_GPIO4_IO01 0x04000061 /* SODIMM 178 */
> + IMX8QXP_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO02 0x04000061 /* SODIMM 94 */
> + IMX8QXP_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO00 0x60 /* SODIMM 81 */
> + >;
> + };
> +
> + /* Colibri PWM_A */
> + pinctrl_pwm_a: pwma {
> + /* both pins are connected together, reserve the unused CSI_D05 */
> + fsl,pins = <
> + IMX8QXP_CSI_D05_CI_PI_D07 0x61 /* SODIMM 59 */
> + IMX8QXP_SPI0_CS1_ADMA_LCD_PWM0_OUT 0x60 /* SODIMM 59 */
> + >;
> + };
> +
> + /* Colibri PWM_B */
> + pinctrl_pwm_b: pwmb {
> + fsl,pins = <
> + IMX8QXP_UART1_TX_LSIO_PWM0_OUT 0x60 /* SODIMM 28 */
> + >;
> + };
> +
> + /* Colibri PWM_C */
> + pinctrl_pwm_c: pwmc {
> + fsl,pins = <
> + IMX8QXP_UART1_RX_LSIO_PWM1_OUT 0x60 /* SODIMM 30 */
> + >;
> + };
> +
> + /* Colibri PWM_D */
> + pinctrl_pwm_d: pwmd {
> + /* both pins are connected together, reserve the unused CSI_D04 */
> + fsl,pins = <
> + IMX8QXP_CSI_D04_CI_PI_D06 0x61 /* SODIMM 67 */
> + IMX8QXP_UART1_RTS_B_LSIO_PWM2_OUT 0x60 /* SODIMM 67 */
> + >;
> + };
> +
> + /* On-module I2S */
> + pinctrl_sai0: sai0grp {
> + fsl,pins = <
> + IMX8QXP_SPI0_SDI_ADMA_SAI0_TXD 0x06000040
> + IMX8QXP_SPI0_CS0_ADMA_SAI0_RXD 0x06000040
> + IMX8QXP_SPI0_SCK_ADMA_SAI0_TXC 0x06000040
> + IMX8QXP_SPI0_SDO_ADMA_SAI0_TXFS 0x06000040
> + >;
> + };
> +
> + /* Colibri Audio Analogue Microphone GND */
> + pinctrl_sgtl5000: sgtl5000 {
> + fsl,pins = <
> + /* MIC GND EN */
> + IMX8QXP_MIPI_CSI0_I2C0_SDA_LSIO_GPIO3_IO06 0x41
> + >;
> + };
> +
> + /* On-module SGTL5000 clock */
> + pinctrl_sgtl5000_usb_clk: sgtl5000-usb-clk {
> + fsl,pins = <
> + IMX8QXP_ADC_IN3_ADMA_ACM_MCLK_OUT0 0x21
> + >;
> + };
> +
> + /* On-module USB interrupt */
> + pinctrl_usb3503a: usb3503a-grp {
> + fsl,pins = <
> + IMX8QXP_MIPI_CSI0_MCLK_OUT_LSIO_GPIO3_IO04 0x61
> + >;
> + };
> +
> + /* Colibri USB Client Cable Detect */
> + pinctrl_usbc_det: usbc-det {
> + fsl,pins = <
> + IMX8QXP_ENET0_REFCLK_125M_25M_LSIO_GPIO5_IO09 0x06000040 /* SODIMM 137 */
> + >;
> + };
> +
> + pinctrl_ext_io0: ext-io0 {
> + fsl,pins = <
> + IMX8QXP_ENET0_RGMII_RXD3_LSIO_GPIO5_IO08 0x06000040 /* SODIMM 135 */
> + >;
> + };
> +
> + /* Colibri Parallel RGB LCD Interface */
> + pinctrl_lcdif: lcdif-pins {
> + fsl,pins = <
> + IMX8QXP_MCLK_OUT0_ADMA_LCDIF_CLK 0x60 /* SODIMM 56 */
> + IMX8QXP_SPI3_CS0_ADMA_LCDIF_HSYNC 0x60 /* SODIMM 68 */
> + IMX8QXP_MCLK_IN0_ADMA_LCDIF_VSYNC 0x60 /* SODIMM 82 */
> + IMX8QXP_MCLK_IN1_ADMA_LCDIF_EN 0x60 /* SODIMM 44 */
> + IMX8QXP_USDHC1_RESET_B_LSIO_GPIO4_IO19 0x60 /* SODIMM 44 */
> + IMX8QXP_ESAI0_FSR_ADMA_LCDIF_D00 0x60 /* SODIMM 76 */
> + IMX8QXP_USDHC1_WP_LSIO_GPIO4_IO21 0x60 /* SODIMM 76 */
> + IMX8QXP_ESAI0_FST_ADMA_LCDIF_D01 0x60 /* SODIMM 70 */
> + IMX8QXP_ESAI0_SCKR_ADMA_LCDIF_D02 0x60 /* SODIMM 60 */
> + IMX8QXP_ESAI0_SCKT_ADMA_LCDIF_D03 0x60 /* SODIMM 58 */
> + IMX8QXP_ESAI0_TX0_ADMA_LCDIF_D04 0x60 /* SODIMM 78 */
> + IMX8QXP_ESAI0_TX1_ADMA_LCDIF_D05 0x60 /* SODIMM 72 */
> + IMX8QXP_ESAI0_TX2_RX3_ADMA_LCDIF_D06 0x60 /* SODIMM 80 */
> + IMX8QXP_ESAI0_TX3_RX2_ADMA_LCDIF_D07 0x60 /* SODIMM 46 */
> + IMX8QXP_ESAI0_TX4_RX1_ADMA_LCDIF_D08 0x60 /* SODIMM 62 */
> + IMX8QXP_ESAI0_TX5_RX0_ADMA_LCDIF_D09 0x60 /* SODIMM 48 */
> + IMX8QXP_SPDIF0_RX_ADMA_LCDIF_D10 0x60 /* SODIMM 74 */
> + IMX8QXP_SPDIF0_TX_ADMA_LCDIF_D11 0x60 /* SODIMM 50 */
> + IMX8QXP_SPDIF0_EXT_CLK_ADMA_LCDIF_D12 0x60 /* SODIMM 52 */
> + IMX8QXP_SPI3_SCK_ADMA_LCDIF_D13 0x60 /* SODIMM 54 */
> + IMX8QXP_SPI3_SDO_ADMA_LCDIF_D14 0x60 /* SODIMM 66 */
> + IMX8QXP_SPI3_SDI_ADMA_LCDIF_D15 0x60 /* SODIMM 64 */
> + IMX8QXP_SPI3_CS1_ADMA_LCDIF_D16 0x60 /* SODIMM 57 */
> + IMX8QXP_ENET0_RGMII_TXD2_LSIO_GPIO5_IO01 0x60 /* SODIMM 57 */
> + IMX8QXP_UART1_CTS_B_ADMA_LCDIF_D17 0x60 /* SODIMM 61 */
> + >;
> + };
> +
> + /* USB Host Power Enable */
> + pinctrl_usbh1_reg: usbh1-reg {
> + fsl,pins = <
> + IMX8QXP_USB_SS3_TC0_LSIO_GPIO4_IO03 0x06000040 /* SODIMM 129 */
> + >;
> + };
> +
> + /* On-module eMMC */
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
> + IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
> + IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
> + IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
> + IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
> + IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
> + IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
> + IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
> + IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
> + IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
> + IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
> + >;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
> + fsl,pins = <
> + IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
> + IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
> + IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
> + IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
> + IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
> + IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
> + IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
> + IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
> + IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
> + IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
> + IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
> + IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
> + IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
> + IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
> + IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
> + IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
> + IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
> + IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
> + IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
> + IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
> + IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
> + IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
> + >;
> + };
> +
> + /* Colibri SDCard CardDetect */
> + pinctrl_usdhc2_gpio: usdhc2gpiogrp {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_DATA0_LSIO_GPIO3_IO09 0x06000021 /* SODIMM 43 */
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio_sleep: usdhc2gpioslpgrp {
> + fsl,pins = <
> + IMX8QXP_QSPI0A_DATA0_LSIO_GPIO3_IO09 0x60 /* SODIMM 43 */
> + >;
> + };
> +
> + /* Colibri SDCard */
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
> + IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
> + IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
> + IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
> + IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
> + IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
> + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
> + >;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> + fsl,pins = <
> + IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
> + IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
> + IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
> + IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
> + IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
> + IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
> + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
> + >;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> + fsl,pins = <
> + IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
> + IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
> + IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
> + IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
> + IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
> + IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
> + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
> + >;
> + };
> +
> + pinctrl_usdhc2_sleep: usdhc2slpgrp {
> + fsl,pins = <
> + IMX8QXP_USDHC1_CLK_LSIO_GPIO4_IO23 0x60 /* SODIMM 47 */
> + IMX8QXP_USDHC1_CMD_LSIO_GPIO4_IO24 0x60 /* SODIMM 190 */
> + IMX8QXP_USDHC1_DATA0_LSIO_GPIO4_IO25 0x60 /* SODIMM 192 */
> + IMX8QXP_USDHC1_DATA1_LSIO_GPIO4_IO26 0x60 /* SODIMM 49 */
> + IMX8QXP_USDHC1_DATA2_LSIO_GPIO4_IO27 0x60 /* SODIMM 51 */
> + IMX8QXP_USDHC1_DATA3_LSIO_GPIO4_IO28 0x60 /* SODIMM 53 */
> + IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
> + >;
> + };
> +
> + /* MIPI DSI I2C accessible on SODIMM (X1) and FFC (X2) */
> + pinctrl_i2c0_mipi_lvds0: mipi_lvds0_i2c0_grp {
> + fsl,pins = <
> + IMX8QXP_MIPI_DSI0_I2C0_SCL_MIPI_DSI0_I2C0_SCL 0xc6000020 /* SODIMM 140 */
> + IMX8QXP_MIPI_DSI0_I2C0_SDA_MIPI_DSI0_I2C0_SDA 0xc6000020 /* SODIMM 142 */
> + >;
> + };
> +
> + /* MIPI CSI I2C accessible on SODIMM (X1) and FFC (X3) */
> + pinctrl_i2c0_mipi_lvds1: mipi_lvds1_i2c0_grp {
> + fsl,pins = <
> + IMX8QXP_MIPI_DSI1_I2C0_SCL_MIPI_DSI1_I2C0_SCL 0xc6000020 /* SODIMM 186 */
> + IMX8QXP_MIPI_DSI1_I2C0_SDA_MIPI_DSI1_I2C0_SDA 0xc6000020 /* SODIMM 188 */
> + >;
> + };
> +
> + /* Colibri SPI */
> + pinctrl_lpspi2: lpspi2 {
> + fsl,pins = <
> + IMX8QXP_SPI2_CS0_LSIO_GPIO1_IO00 0x21 /* SODIMM 86 */
> + IMX8QXP_SPI2_SDO_ADMA_SPI2_SDO 0x06000040 /* SODIMM 92 */
> + IMX8QXP_SPI2_SDI_ADMA_SPI2_SDI 0x06000040 /* SODIMM 90 */
> + IMX8QXP_SPI2_SCK_ADMA_SPI2_SCK 0x06000040 /* SODIMM 88 */
> + >;
> + };
> +
> + pinctrl_wifi: wifigrp {
> + fsl,pins = <
> + IMX8QXP_SCU_BOOT_MODE3_SCU_DSC_RTC_CLOCK_OUTPUT_32K 0x20
> + >;
> + };
> + };
> +};
> +
> +/* Colibri UART_B */
> +&adma_lpuart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart0>;
> +};
> +
> +/* Colibri UART_C */
> +&adma_lpuart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart2>;
> +};
> +
> +/* Colibri UART_A */
> +&adma_lpuart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart3>, <&pinctrl_lpuart3_ctrl>;
> +};
> +
> +/* On-module eMMC */
> +&usdhc1 {
> + bus-width = <8>;
> + non-removable;
> + no-sd;
> + no-sdio;
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + status = "okay";
> +};
> +
> +/* Colibri SDCard */
> +&usdhc2 {
> + bus-width = <4>;
> + cd-gpios = <&lsio_gpio3 9 GPIO_ACTIVE_LOW>;
> + vmmc-supply = <®_module_3v3>;
> + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> + pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> + pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
> + disable-wp;
> +};
> --
> 2.21.0
>
--
Best regards
Oleksandr Suvorov
cryosay@gmail.com
_______________________________________________
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/8] iommu/arm-smmu-v3: Add support for Substream IDs
From: Jean-Philippe Brucker @ 2019-09-19 15:01 UTC (permalink / raw)
To: Auger Eric
Cc: mark.rutland, devicetree, jacob.jun.pan, Jean-Philippe Brucker,
robin.murphy, joro, linux-kernel, iommu, robh+dt, will,
linux-arm-kernel
In-Reply-To: <af286d72-97d7-d106-40a8-edfcbe563c98@redhat.com>
On Mon, Jul 08, 2019 at 05:31:53PM +0200, Auger Eric wrote:
> Hi Jean,
>
> On 6/10/19 8:47 PM, Jean-Philippe Brucker wrote:
> > /*
> > - * We don't need to issue any invalidation here, as we'll invalidate
> > - * the STE when installing the new entry anyway.
> > + * This function handles the following cases:
> > + *
> > + * (1) Install primary CD, for normal DMA traffic (SSID = 0).
> > + * (2) Install a secondary CD, for SID+SSID traffic.
> > + * (3) Update ASID of a CD. Atomically write the first 64 bits of the
> > + * CD, then invalidate the old entry and mappings.
> Can you explain when (3) does occur?
When sharing a process context with devices (SVA), we write in that
context descriptor the ASID allocated by the arch ASID allocator for
that process. But that ASID might already have been allocated locally by
the SMMU driver for a private context. As there is a single ASID space
per SMMU for both private and shared ASIDs, we reallocated the private
ASID and update it here. See
https://lore.kernel.org/linux-iommu/20180511190641.23008-25-jean-philippe.brucker@arm.com/
> > + * (4) Remove a secondary CD.
> > */
> > - val = arm_smmu_cpu_tcr_to_cd(cfg->cd.tcr) |
> > +
> > + if (!cdptr)
> > + return -ENOMEM;
> Is that relevant? arm_smmu_get_cd_ptr() does not test ssid is within the
> cfg->s1cdmax range and always return smthg != NULL AFAIU.
It might return NULL with patch 5/8, when we can't allocate a 2nd-level
table. I can move the check over to that patch.
> > + ret = arm_smmu_write_ctx_desc(smmu_domain, 0, &smmu_domain->s1_cfg.cd);
> cfg.cd
Right.
Thanks,
Jean
_______________________________________________
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 v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Justin He (Arm Technology China) @ 2019-09-19 15:02 UTC (permalink / raw)
To: Kirill A. Shutemov, Jia He
Cc: Mark Rutland, Kaly Xin (Arm Technology China), Ralph Campbell,
Andrew Morton, Suzuki Poulose, Catalin Marinas, Anshuman Khandual,
linux-kernel@vger.kernel.org, Matthew Wilcox, Jun Yao,
linux-mm@kvack.org, Jérôme Glisse, James Morse,
linux-arm-kernel@lists.infradead.org, Punit Agrawal, Marc Zyngier,
Thomas Gleixner, Will Deacon, Alex Van Brunt, Kirill A. Shutemov,
Robin Murphy
In-Reply-To: <20190919145742.ooamzlmcfqjobcx6@box>
Hi Kirill
Thanks for the detailed explanation.
--
Cheers,
Justin (Jia He)
> -----Original Message-----
> From: Kirill A. Shutemov <kirill@shutemov.name>
> Sent: 2019年9月19日 22:58
> To: Jia He <hejianet@gmail.com>
> Cc: Justin He (Arm Technology China) <Justin.He@arm.com>; Catalin
> Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>; Mark
> Rutland <Mark.Rutland@arm.com>; James Morse
> <James.Morse@arm.com>; Marc Zyngier <maz@kernel.org>; Matthew
> Wilcox <willy@infradead.org>; Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org; Suzuki Poulose
> <Suzuki.Poulose@arm.com>; Punit Agrawal <punitagrawal@gmail.com>;
> Anshuman Khandual <Anshuman.Khandual@arm.com>; Jun Yao
> <yaojun8558363@gmail.com>; Alex Van Brunt <avanbrunt@nvidia.com>;
> Robin Murphy <Robin.Murphy@arm.com>; Thomas Gleixner
> <tglx@linutronix.de>; Andrew Morton <akpm@linux-foundation.org>;
> Jérôme Glisse <jglisse@redhat.com>; Ralph Campbell
> <rcampbell@nvidia.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>
> Subject: Re: [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF is
> cleared
>
> On Thu, Sep 19, 2019 at 10:16:34AM +0800, Jia He wrote:
> > Hi Kirill
> >
> > [On behalf of justin.he@arm.com because some mails are filted...]
> >
> > On 2019/9/18 22:00, Kirill A. Shutemov wrote:
> > > On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> > > > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64
> guest, there
> > > > will be a double page fault in __copy_from_user_inatomic of
> cow_user_page.
> > > >
> > > > Below call trace is from arm64 do_page_fault for debugging purpose
> > > > [ 110.016195] Call trace:
> > > > [ 110.016826] do_page_fault+0x5a4/0x690
> > > > [ 110.017812] do_mem_abort+0x50/0xb0
> > > > [ 110.018726] el1_da+0x20/0xc4
> > > > [ 110.019492] __arch_copy_from_user+0x180/0x280
> > > > [ 110.020646] do_wp_page+0xb0/0x860
> > > > [ 110.021517] __handle_mm_fault+0x994/0x1338
> > > > [ 110.022606] handle_mm_fault+0xe8/0x180
> > > > [ 110.023584] do_page_fault+0x240/0x690
> > > > [ 110.024535] do_mem_abort+0x50/0xb0
> > > > [ 110.025423] el0_da+0x20/0x24
> > > >
> > > > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> > > > [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003,
> pmd=000000023d4b3003, pte=360000298607bd3
> > > >
> > > > As told by Catalin: "On arm64 without hardware Access Flag, copying
> from
> > > > user will fail because the pte is old and cannot be marked young. So
> we
> > > > always end up with zeroed page after fork() + CoW for pfn mappings.
> we
> > > > don't always have a hardware-managed access flag on arm64."
> > > >
> > > > This patch fix it by calling pte_mkyoung. Also, the parameter is
> > > > changed because vmf should be passed to cow_user_page()
> > > >
> > > > [1]
> https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> > > >
> > > > Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> > > > Signed-off-by: Jia He <justin.he@arm.com>
> > > > ---
> > > > mm/memory.c | 35 ++++++++++++++++++++++++++++++-----
> > > > 1 file changed, 30 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/mm/memory.c b/mm/memory.c
> > > > index e2bb51b6242e..d2c130a5883b 100644
> > > > --- a/mm/memory.c
> > > > +++ b/mm/memory.c
> > > > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > > > 2;
> > > > #endif
> > > > +#ifndef arch_faults_on_old_pte
> > > > +static inline bool arch_faults_on_old_pte(void)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > > > +
> > > > static int __init disable_randmaps(char *s)
> > > > {
> > > > randomize_va_space = 0;
> > > > @@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct
> mm_struct *mm, pmd_t *pmd,
> > > > return same;
> > > > }
> > > > -static inline void cow_user_page(struct page *dst, struct page *src,
> unsigned long va, struct vm_area_struct *vma)
> > > > +static inline void cow_user_page(struct page *dst, struct page *src,
> > > > + struct vm_fault *vmf)
> > > > {
> > > > + struct vm_area_struct *vma = vmf->vma;
> > > > + unsigned long addr = vmf->address;
> > > > +
> > > > debug_dma_assert_idle(src);
> > > > /*
> > > > @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct
> page *dst, struct page *src, unsigned lo
> > > > */
> > > > if (unlikely(!src)) {
> > > > void *kaddr = kmap_atomic(dst);
> > > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > > + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> > > > + pte_t entry;
> > > > /*
> > > > * This really shouldn't fail, because the page is there
> > > > * in the page tables. But it might just be unreadable,
> > > > * in which case we just give up and fill the result with
> > > > - * zeroes.
> > > > + * zeroes. On architectures with software "accessed" bits,
> > > > + * we would take a double page fault here, so mark it
> > > > + * accessed here.
> > > > */
> > > > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte))
> {
> > > > + spin_lock(vmf->ptl);
> > > > + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> > > > + entry = pte_mkyoung(vmf->orig_pte);
> > > > + if (ptep_set_access_flags(vma, addr,
> > > > + vmf->pte, entry, 0))
> > > > + update_mmu_cache(vma, addr, vmf-
> >pte);
> > > > + }
> > > I don't follow.
> > >
> > > So if pte has changed under you, you don't set the accessed bit, but
> never
> > > the less copy from the user.
> > >
> > > What makes you think it will not trigger the same problem?
> > >
> > > I think we need to make cow_user_page() fail in this case and caller --
> > > wp_page_copy() -- return zero. If the fault was solved by other thread,
> we
> > > are fine. If not userspace would re-fault on the same address and we
> will
> > > handle the fault from the second attempt.
> >
> > Thanks for the pointing. How about make cow_user_page() be returned
> >
> > VM_FAULT_RETRY? Then in do_page_fault(), it can retry the page fault?
>
> No. VM_FAULT_RETRY has different semantics: we have to drop
> mmap_sem(), so
> let's try to take it again and handle the fault. In this case the more
> likely scenario is that other thread has already handled the fault and we
> don't need to do anything. If it's not the case, the fault will be
> triggered again on the same address.
>
> --
> Kirill A. Shutemov
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
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] i2c: at91: Send bus clear command if SCL or SDA is down
From: kbouhara @ 2019-09-19 15:06 UTC (permalink / raw)
To: Codrin Ciubotariu, linux-i2c, linux-arm-kernel, linux-kernel
Cc: ludovic.desroches, alexandre.belloni, wsa
In-Reply-To: <20190911095854.5141-1-codrin.ciubotariu@microchip.com>
On 9/11/19 11:58 AM, Codrin Ciubotariu wrote:
> After a transfer timeout, some faulty I2C slave devices might hold down
> the SCL or the SDA pins. We can generate a bus clear command, hoping that
> the slave might release the pins.
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> drivers/i2c/busses/i2c-at91-master.c | 20 ++++++++++++++++++++
> drivers/i2c/busses/i2c-at91.h | 6 +++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
> index a3fcc35ffd3b..5f544a16db96 100644
> --- a/drivers/i2c/busses/i2c-at91-master.c
> +++ b/drivers/i2c/busses/i2c-at91-master.c
> @@ -599,6 +599,26 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
> at91_twi_write(dev, AT91_TWI_CR,
> AT91_TWI_THRCLR | AT91_TWI_LOCKCLR);
> }
> +
> + /*
> + * After timeout, some faulty I2C slave devices might hold SCL/SDA down;
> + * we can send a bus clear command, hoping that the pins will be
> + * released
> + */
> + if (!(dev->transfer_status & AT91_TWI_SDA) ||
> + !(dev->transfer_status & AT91_TWI_SCL)) {
> + dev_dbg(dev->dev,
> + "SDA/SCL are down; sending bus clear command\n");
> + if (dev->use_alt_cmd) {
> + unsigned int acr;
> +
> + acr = at91_twi_read(dev, AT91_TWI_ACR);
> + acr &= ~AT91_TWI_ACR_DATAL_MASK;
> + at91_twi_write(dev, AT91_TWI_ACR, acr);
> + }
> + at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_CLEAR);
This bit is not documented on SoCs before SAMA5D2/D4, this write
shouldn't be done unconditionally.
--
Kamel Bouhara, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
_______________________________________________
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