Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/1] sched/rt: avoid contend with CFS task
From: Jing-Ting Wu @ 2019-08-29  3:15 UTC (permalink / raw)
  To: Peter Zijlstra, Matthias Brugger
  Cc: linux-arm-kernel, Jing-Ting Wu, linux-mediatek, linux-kernel,
	wsd_upstream

At original linux design, RT & CFS scheduler are independent.
Current RT task placement policy will select the first cpu in
lowest_mask, even if the first CPU is running a CFS task.
This may put RT task to a running cpu and let CFS task runnable.

So we select idle cpu in lowest_mask first to avoid preempting
CFS task.

Signed-off-by: Jing-Ting Wu <jing-ting.wu@mediatek.com>
---
 kernel/sched/rt.c |   42 +++++++++++++++++-------------------------
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index a532558..626ca27 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1388,7 +1388,6 @@ static void yield_task_rt(struct rq *rq)
 static int
 select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags)
 {
-	struct task_struct *curr;
 	struct rq *rq;
 
 	/* For anything but wake ups, just return the task_cpu */
@@ -1398,33 +1397,15 @@ static void yield_task_rt(struct rq *rq)
 	rq = cpu_rq(cpu);
 
 	rcu_read_lock();
-	curr = READ_ONCE(rq->curr); /* unlocked access */
 
 	/*
-	 * If the current task on @p's runqueue is an RT task, then
-	 * try to see if we can wake this RT task up on another
-	 * runqueue. Otherwise simply start this RT task
-	 * on its current runqueue.
-	 *
-	 * We want to avoid overloading runqueues. If the woken
-	 * task is a higher priority, then it will stay on this CPU
-	 * and the lower prio task should be moved to another CPU.
-	 * Even though this will probably make the lower prio task
-	 * lose its cache, we do not want to bounce a higher task
-	 * around just because it gave up its CPU, perhaps for a
-	 * lock?
-	 *
-	 * For equal prio tasks, we just let the scheduler sort it out.
-	 *
-	 * Otherwise, just let it ride on the affined RQ and the
-	 * post-schedule router will push the preempted task away
-	 *
-	 * This test is optimistic, if we get it wrong the load-balancer
-	 * will have to sort it out.
+	 * If the task p is allowed to put more than one CPU or
+	 * it is not allowed to put on this CPU.
+	 * Let p use find_lowest_rq to choose other idle CPU first,
+	 * instead of choose this cpu and preempt curr cfs task.
 	 */
-	if (curr && unlikely(rt_task(curr)) &&
-	    (curr->nr_cpus_allowed < 2 ||
-	     curr->prio <= p->prio)) {
+	if ((p->nr_cpus_allowed > 1) ||
+	    (!cpumask_test_cpu(cpu, p->cpus_ptr))) {
 		int target = find_lowest_rq(p);
 
 		/*
@@ -1648,6 +1629,7 @@ static int find_lowest_rq(struct task_struct *task)
 	struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
 	int this_cpu = smp_processor_id();
 	int cpu      = task_cpu(task);
+	int i;
 
 	/* Make sure the mask is initialized first */
 	if (unlikely(!lowest_mask))
@@ -1659,6 +1641,16 @@ static int find_lowest_rq(struct task_struct *task)
 	if (!cpupri_find(&task_rq(task)->rd->cpupri, task, lowest_mask))
 		return -1; /* No targets found */
 
+	/* Choose previous cpu if it is idle and it fits lowest_mask */
+	if (cpumask_test_cpu(cpu, lowest_mask) && idle_cpu(cpu))
+		return cpu;
+
+	/* Choose idle_cpu among lowest_mask */
+	for_each_cpu(i, lowest_mask) {
+		if (idle_cpu(i))
+			return i;
+	}
+
 	/*
 	 * At this point we have built a mask of CPUs representing the
 	 * lowest priority tasks in the system.  Now we want to elect
-- 
1.7.9.5


_______________________________________________
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 netdev] net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
From: Chen-Yu Tsai @ 2019-08-29  3:17 UTC (permalink / raw)
  To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
	Heiko Stuebner
  Cc: linux-rockchip, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
	netdev

From: Chen-Yu Tsai <wens@csie.org>

The devicetree binding lists the phy phy as optional. As such, the
driver should not bail out if it can't find a regulator. Instead it
should just skip the remaining regulator related code and continue
on normally.

Skip the remainder of phy_power_on() if a regulator supply isn't
available. This also gets rid of the bogus return code.

Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---

On a separate note, maybe we should add this file to the Rockchip
entry in MAINTAINERS?

---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 4644b2aeeba1..e2e469c37a4d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1194,10 +1194,8 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
 	int ret;
 	struct device *dev = &bsp_priv->pdev->dev;
 
-	if (!ldo) {
-		dev_err(dev, "no regulator found\n");
-		return -1;
-	}
+	if (!ldo)
+		return 0;
 
 	if (enable) {
 		ret = regulator_enable(ldo);
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* RE: [PATCH v2 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
From: Yoshihiro Shimoda @ 2019-08-29  4:14 UTC (permalink / raw)
  To: Geert Uytterhoeven, Magnus Damm
  Cc: linux-renesas-soc@vger.kernel.org, Simon Horman,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>

Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Wednesday, August 28, 2019 8:36 PM
> 
> 	Hi all,
> 
> Recent R-Car Gen3 SoCs added an External Request Mask Register to the
> System Controller (SYSC).  This register allows to mask external power
> requests for CPU or 3DG domains, to prevent conflicts between powering
> off CPU cores or the 3D Graphics Engine, and changing the state of
> another power domain through SYSC, which could lead to CPG state machine
> lock-ups.
> 
> This patch series starts making use of this register.  Note that the
> register is optional, and that its location and contents are
> SoC-specific.
> 
> This was inspired by a patch in the BSP by Dien Pham
> <dien.pham.ry@renesas.com>.
> 
> Note that the issue fixed cannot happen in the upstream kernel, as
> upstream has no support for graphics acceleration yet.  SoCs lacking the
> External Request Mask Register may need a different mitigation in the
> future.
> 
> Changes compared to v1[1]:
>   - Improve description of cover letter and first patch.
> 
> Changes compared to RFC[2]:
>   - Rebased.
> 
> This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
> V3M, and E3 (only the last 3 have this register!), and regression-tested
> on R-Car Gen2.
> 
> This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.

I also boot-tested on R-Car H3 ES3.0 and M3-W ES3.0.
And I reviewed all patches, so:

Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>

Best regards,
Yoshihiro Shimoda


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] [RFC] i2c: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29  4:29 UTC (permalink / raw)
  To: Wolfram Sang, Oleksij Rempel
  Cc: Jani Nikula, Petr Mladek, Sergey Senozhatsky, Jonathan Corbet,
	Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
	Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
	Fabio Estevam, linux-arm-kernel, linux-i2c

I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied

	dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);

emits

	... can't enable I2C clock, ret=EIO

if ret is -EIO. Petr Mladek (i.e. one of the printk maintainers) had
concerns if this would be well received and worth the effort. He asked
to present it to a few subsystems. So for now, this patch converting the
i2c-imx driver shouldn't be applied yet but it would be great to get
some feedback about if you think that being able to easily printk (for
example) "EIO" instead of "-5" is a good idea. Would it help you? Do you
think it helps your users?

Thanks
Uwe

[1] https://lkml.org/lkml/2019/8/27/1456
---
 drivers/i2c/busses/i2c-imx.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 15f6cde6452f..359e911cb891 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -289,7 +289,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
 	if (IS_ERR(dma->chan_tx)) {
 		ret = PTR_ERR(dma->chan_tx);
 		if (ret != -ENODEV && ret != -EPROBE_DEFER)
-			dev_err(dev, "can't request DMA tx channel (%d)\n", ret);
+			dev_err(dev, "can't request DMA tx channel (%dE)\n", ret);
 		goto fail_al;
 	}
 
@@ -300,7 +300,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
 	dma_sconfig.direction = DMA_MEM_TO_DEV;
 	ret = dmaengine_slave_config(dma->chan_tx, &dma_sconfig);
 	if (ret < 0) {
-		dev_err(dev, "can't configure tx channel (%d)\n", ret);
+		dev_err(dev, "can't configure tx channel (%dE)\n", ret);
 		goto fail_tx;
 	}
 
@@ -308,7 +308,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
 	if (IS_ERR(dma->chan_rx)) {
 		ret = PTR_ERR(dma->chan_rx);
 		if (ret != -ENODEV && ret != -EPROBE_DEFER)
-			dev_err(dev, "can't request DMA rx channel (%d)\n", ret);
+			dev_err(dev, "can't request DMA rx channel (%dE)\n", ret);
 		goto fail_tx;
 	}
 
@@ -319,7 +319,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
 	dma_sconfig.direction = DMA_DEV_TO_MEM;
 	ret = dmaengine_slave_config(dma->chan_rx, &dma_sconfig);
 	if (ret < 0) {
-		dev_err(dev, "can't configure rx channel (%d)\n", ret);
+		dev_err(dev, "can't configure rx channel (%dE)\n", ret);
 		goto fail_rx;
 	}
 
@@ -964,7 +964,7 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
 	pm_runtime_put_autosuspend(i2c_imx->adapter.dev.parent);
 
 out:
-	dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %d\n", __func__,
+	dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %dE\n", __func__,
 		(result < 0) ? "error" : "success msg",
 			(result < 0) ? result : num);
 	return (result < 0) ? result : num;
@@ -1100,7 +1100,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
 
 	ret = clk_prepare_enable(i2c_imx->clk);
 	if (ret) {
-		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
+		dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);
 		return ret;
 	}
 
@@ -1108,7 +1108,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	ret = devm_request_irq(&pdev->dev, irq, i2c_imx_isr, IRQF_SHARED,
 				pdev->name, i2c_imx);
 	if (ret) {
-		dev_err(&pdev->dev, "can't claim irq %d\n", irq);
+		dev_err(&pdev->dev, "can't claim irq %dE\n", irq);
 		goto clk_disable;
 	}
 
@@ -1230,7 +1230,7 @@ static int __maybe_unused i2c_imx_runtime_resume(struct device *dev)
 
 	ret = clk_enable(i2c_imx->clk);
 	if (ret)
-		dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
+		dev_err(dev, "can't enable I2C clock, ret=%dE\n", ret);
 
 	return ret;
 }
-- 
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] drm: dw-hdmi-i2s: enable audio clock in audio_startup
From: Cheng-Yi Chiang @ 2019-08-29  4:29 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, tzungbi, zhengxing, kuninori.morimoto.gx, a.hajda,
	airlied, jeffy.chen, dianders, dri-devel, cain.cai,
	linux-rockchip, eddie.cai, Laurent.pinchart, daniel,
	enric.balletbo, dgreid, sam, linux-arm-kernel, cychiang

In the designware databook, the sequence of enabling audio clock and
setting format is not clearly specified.
Currently, audio clock is enabled in the end of hw_param ops after
setting format.

On some monitors, there is a possibility that audio does not come out.
Fix this by enabling audio clock in audio_startup ops
before hw_param ops setting format.

Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 5cbb71a866d5..08b4adbb1ddc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -69,6 +69,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
 	hdmi_write(audio, conf0, HDMI_AUD_CONF0);
 	hdmi_write(audio, conf1, HDMI_AUD_CONF1);
 
+	return 0;
+}
+
+static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data)
+{
+	struct dw_hdmi_i2s_audio_data *audio = data;
+	struct dw_hdmi *hdmi = audio->hdmi;
+
 	dw_hdmi_audio_enable(hdmi);
 
 	return 0;
@@ -105,6 +113,7 @@ static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
 }
 
 static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
+	.audio_startup = dw_hdmi_i2s_audio_startup,
 	.hw_params	= dw_hdmi_i2s_hw_params,
 	.audio_shutdown	= dw_hdmi_i2s_audio_shutdown,
 	.get_dai_id	= dw_hdmi_i2s_get_dai_id,
-- 
2.23.0.187.g17f5b7556c-goog


_______________________________________________
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] [RFC] tty/serial: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29  4:37 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Jiri Slaby
  Cc: Jani Nikula, Petr Mladek, linux-serial, Jonathan Corbet,
	Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
	Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
	Fabio Estevam, linux-arm-kernel, Sergey Senozhatsky

I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied

	dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);

emits

	... failed to get ipg clk: EPROBE_DEFER

if ret is -EPROBE_DEFER. Petr Mladek (i.e. one of the printk
maintainers) had concerns if this would be well received and worth the
effort. He asked to present it to a few subsystems. So for now, this
patch converting the imx UART driver shouldn't be applied yet but it
would be great to get some feedback about if you think that being able
to easily printk (for example) "EIO" instead of "-5" is a good idea.
Would it help you? Do you think it helps your users?

Thanks
Uwe

[1] https://lkml.org/lkml/2019/8/27/1456
---
 drivers/tty/serial/imx.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 57d6e6ba556e..a3dbb9378e8b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2143,7 +2143,7 @@ static int imx_uart_probe_dt(struct imx_port *sport,
 
 	ret = of_alias_get_id(np, "serial");
 	if (ret < 0) {
-		dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+		dev_err(&pdev->dev, "failed to get alias id, error %dE\n", ret);
 		return ret;
 	}
 	sport->port.line = ret;
@@ -2236,14 +2236,14 @@ static int imx_uart_probe(struct platform_device *pdev)
 	sport->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
 	if (IS_ERR(sport->clk_ipg)) {
 		ret = PTR_ERR(sport->clk_ipg);
-		dev_err(&pdev->dev, "failed to get ipg clk: %d\n", ret);
+		dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
 		return ret;
 	}
 
 	sport->clk_per = devm_clk_get(&pdev->dev, "per");
 	if (IS_ERR(sport->clk_per)) {
 		ret = PTR_ERR(sport->clk_per);
-		dev_err(&pdev->dev, "failed to get per clk: %d\n", ret);
+		dev_err(&pdev->dev, "failed to get per clk: %dE\n", ret);
 		return ret;
 	}
 
@@ -2252,7 +2252,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 	/* For register access, we only need to enable the ipg clock. */
 	ret = clk_prepare_enable(sport->clk_ipg);
 	if (ret) {
-		dev_err(&pdev->dev, "failed to enable per clk: %d\n", ret);
+		dev_err(&pdev->dev, "failed to enable per clk: %dE\n", ret);
 		return ret;
 	}
 
@@ -2330,7 +2330,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_rxint, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
-			dev_err(&pdev->dev, "failed to request rx irq: %d\n",
+			dev_err(&pdev->dev, "failed to request rx irq: %dE\n",
 				ret);
 			return ret;
 		}
@@ -2338,7 +2338,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
-			dev_err(&pdev->dev, "failed to request tx irq: %d\n",
+			dev_err(&pdev->dev, "failed to request tx irq: %dE\n",
 				ret);
 			return ret;
 		}
@@ -2346,7 +2346,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
-			dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+			dev_err(&pdev->dev, "failed to request rts irq: %dE\n",
 				ret);
 			return ret;
 		}
@@ -2354,7 +2354,7 @@ static int imx_uart_probe(struct platform_device *pdev)
 		ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
 				       dev_name(&pdev->dev), sport);
 		if (ret) {
-			dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
+			dev_err(&pdev->dev, "failed to request irq: %dE\n", ret);
 			return ret;
 		}
 	}
-- 
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 0/2] Add fixes to iProc GPIO driver
From: Srinath Mannam @ 2019-08-29  4:52 UTC (permalink / raw)
  To: Linus Walleij, Ray Jui, Scott Branden
  Cc: Srinath Mannam, bcm-kernel-feedback-list, linux-kernel,
	linux-arm-kernel

This patch series adds the following fixes to the iProc GPIO driver
 - Fix Warning message given for shared irqchip data structure
 - Fix pinconfig of pull-up/down and drive strength for AON/CRMU GPIOs

This patch set is based on Linux-5.2-rc4.

Changes from v1:
  - Add Fixes tags in both patches

Li Jin (1):
  gpio: iproc-gpio: Fix incorrect pinconf configurations

Rayagonda Kokatanur (1):
  gpio: iproc-gpio: Handle interrupts for multiple instances

 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 117 +++++++++++++++++++++++--------
 1 file changed, 88 insertions(+), 29 deletions(-)

-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 1/2] gpio: iproc-gpio: Fix incorrect pinconf configurations
From: Srinath Mannam @ 2019-08-29  4:52 UTC (permalink / raw)
  To: Linus Walleij, Ray Jui, Scott Branden
  Cc: Li Jin, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>

From: Li Jin <li.jin@broadcom.com>

Fix drive strength for AON/CRMU controller; fix pull-up/down setting
for CCM/CDRU controller.

Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Li Jin <li.jin@broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 96 +++++++++++++++++++++++++-------
 1 file changed, 77 insertions(+), 19 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..20b9864 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -54,8 +54,12 @@
 /* drive strength control for ASIU GPIO */
 #define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
 
-/* drive strength control for CCM/CRMU (AON) GPIO */
-#define IPROC_GPIO_DRV0_CTRL_OFFSET  0x00
+/* pinconf for CCM GPIO */
+#define IPROC_GPIO_PULL_DN_OFFSET   0x10
+#define IPROC_GPIO_PULL_UP_OFFSET   0x14
+
+/* pinconf for CRMU(aon) GPIO and CCM GPIO*/
+#define IPROC_GPIO_DRV_CTRL_OFFSET  0x00
 
 #define GPIO_BANK_SIZE 0x200
 #define NGPIOS_PER_BANK 32
@@ -76,6 +80,12 @@ enum iproc_pinconf_param {
 	IPROC_PINCON_MAX,
 };
 
+enum iproc_pinconf_ctrl_type {
+	IOCTRL_TYPE_AON = 1,
+	IOCTRL_TYPE_CDRU,
+	IOCTRL_TYPE_INVALID,
+};
+
 /*
  * Iproc GPIO core
  *
@@ -100,6 +110,7 @@ struct iproc_gpio {
 
 	void __iomem *base;
 	void __iomem *io_ctrl;
+	enum iproc_pinconf_ctrl_type io_ctrl_type;
 
 	raw_spinlock_t lock;
 
@@ -461,20 +472,44 @@ static const struct pinctrl_ops iproc_pctrl_ops = {
 static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
 				bool disable, bool pull_up)
 {
+	void __iomem *base;
 	unsigned long flags;
+	unsigned int shift;
+	u32 val_1, val_2;
 
 	raw_spin_lock_irqsave(&chip->lock, flags);
-
-	if (disable) {
-		iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, false);
+	if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+		base = chip->io_ctrl;
+		shift = IPROC_GPIO_SHIFT(gpio);
+
+		val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET);
+		val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET);
+		if (disable) {
+			/* no pull-up or pull-down */
+			val_1 &= ~BIT(shift);
+			val_2 &= ~BIT(shift);
+		} else if (pull_up) {
+			val_1 |= BIT(shift);
+			val_2 &= ~BIT(shift);
+		} else {
+			val_1 &= ~BIT(shift);
+			val_2 |= BIT(shift);
+		}
+		writel(val_1, base + IPROC_GPIO_PULL_UP_OFFSET);
+		writel(val_2, base + IPROC_GPIO_PULL_DN_OFFSET);
 	} else {
-		iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
-			       pull_up);
-		iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, true);
+		if (disable) {
+			iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+				      false);
+		} else {
+			iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
+				      pull_up);
+			iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+				      true);
+		}
 	}
 
 	raw_spin_unlock_irqrestore(&chip->lock, flags);
-
 	dev_dbg(chip->dev, "gpio:%u set pullup:%d\n", gpio, pull_up);
 
 	return 0;
@@ -483,14 +518,35 @@ static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
 static void iproc_gpio_get_pull(struct iproc_gpio *chip, unsigned gpio,
 				 bool *disable, bool *pull_up)
 {
+	void __iomem *base;
 	unsigned long flags;
+	unsigned int shift;
+	u32 val_1, val_2;
 
 	raw_spin_lock_irqsave(&chip->lock, flags);
-	*disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
-	*pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+	if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+		base = chip->io_ctrl;
+		shift = IPROC_GPIO_SHIFT(gpio);
+
+		val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET) & BIT(shift);
+		val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET) & BIT(shift);
+
+		*pull_up = val_1 ? true : false;
+		*disable = (val_1 | val_2) ? false : true;
+
+	} else {
+		*disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
+		*pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+	}
 	raw_spin_unlock_irqrestore(&chip->lock, flags);
 }
 
+#define DRV_STRENGTH_OFFSET(gpio, bit, type)  ((type) == IOCTRL_TYPE_AON ? \
+	((2 - (bit)) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+	((type) == IOCTRL_TYPE_CDRU) ? \
+	((bit) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+	((bit) * 4 + IPROC_GPIO_REG(gpio, IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET)))
+
 static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
 				    unsigned strength)
 {
@@ -505,11 +561,8 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
 
 	if (chip->io_ctrl) {
 		base = chip->io_ctrl;
-		offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
 	} else {
 		base = chip->base;
-		offset = IPROC_GPIO_REG(gpio,
-					 IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
 	}
 
 	shift = IPROC_GPIO_SHIFT(gpio);
@@ -520,11 +573,11 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
 	raw_spin_lock_irqsave(&chip->lock, flags);
 	strength = (strength / 2) - 1;
 	for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+		offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
 		val = readl(base + offset);
 		val &= ~BIT(shift);
 		val |= ((strength >> i) & 0x1) << shift;
 		writel(val, base + offset);
-		offset += 4;
 	}
 	raw_spin_unlock_irqrestore(&chip->lock, flags);
 
@@ -541,11 +594,8 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
 
 	if (chip->io_ctrl) {
 		base = chip->io_ctrl;
-		offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
 	} else {
 		base = chip->base;
-		offset = IPROC_GPIO_REG(gpio,
-					 IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
 	}
 
 	shift = IPROC_GPIO_SHIFT(gpio);
@@ -553,10 +603,10 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
 	raw_spin_lock_irqsave(&chip->lock, flags);
 	*strength = 0;
 	for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+		offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
 		val = readl(base + offset) & BIT(shift);
 		val >>= shift;
 		*strength += (val << i);
-		offset += 4;
 	}
 
 	/* convert to mA */
@@ -734,6 +784,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
 	u32 ngpios, pinconf_disable_mask = 0;
 	int irq, ret;
 	bool no_pinconf = false;
+	enum iproc_pinconf_ctrl_type io_ctrl_type = IOCTRL_TYPE_INVALID;
 
 	/* NSP does not support drive strength config */
 	if (of_device_is_compatible(dev->of_node, "brcm,iproc-nsp-gpio"))
@@ -764,8 +815,15 @@ static int iproc_gpio_probe(struct platform_device *pdev)
 			dev_err(dev, "unable to map I/O memory\n");
 			return PTR_ERR(chip->io_ctrl);
 		}
+		if (of_device_is_compatible(dev->of_node,
+					    "brcm,cygnus-ccm-gpio"))
+			io_ctrl_type = IOCTRL_TYPE_CDRU;
+		else
+			io_ctrl_type = IOCTRL_TYPE_AON;
 	}
 
+	chip->io_ctrl_type = io_ctrl_type;
+
 	if (of_property_read_u32(dev->of_node, "ngpios", &ngpios)) {
 		dev_err(&pdev->dev, "missing ngpios DT property\n");
 		return -ENODEV;
-- 
2.7.4


_______________________________________________
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 2/2] gpio: iproc-gpio: Handle interrupts for multiple instances
From: Srinath Mannam @ 2019-08-29  4:52 UTC (permalink / raw)
  To: Linus Walleij, Ray Jui, Scott Branden
  Cc: Rayagonda Kokatanur, bcm-kernel-feedback-list, linux-kernel,
	linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>

From: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>

When multiple instance of iproc-gpio chips are present, a fix up
message[1] is printed during the probe of second and later instances.

This issue is because driver sharing same irq_chip data structure
among multiple instances of driver.

Fix this by allocating irq_chip data structure per instance of
iproc-gpio.

[1] fix up message addressed by this patch
[  7.862208] gpio gpiochip2: (689d0000.gpio): detected irqchip that
   is shared with multiple gpiochips: please fix the driver.

Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index 20b9864..8729f47 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -114,6 +114,7 @@ struct iproc_gpio {
 
 	raw_spinlock_t lock;
 
+	struct irq_chip irqchip;
 	struct gpio_chip gc;
 	unsigned num_banks;
 
@@ -302,14 +303,6 @@ static int iproc_gpio_irq_set_type(struct irq_data *d, unsigned int type)
 	return 0;
 }
 
-static struct irq_chip iproc_gpio_irq_chip = {
-	.name = "bcm-iproc-gpio",
-	.irq_ack = iproc_gpio_irq_ack,
-	.irq_mask = iproc_gpio_irq_mask,
-	.irq_unmask = iproc_gpio_irq_unmask,
-	.irq_set_type = iproc_gpio_irq_set_type,
-};
-
 /*
  * Request the Iproc IOMUX pinmux controller to mux individual pins to GPIO
  */
@@ -875,14 +868,22 @@ static int iproc_gpio_probe(struct platform_device *pdev)
 	/* optional GPIO interrupt support */
 	irq = platform_get_irq(pdev, 0);
 	if (irq) {
-		ret = gpiochip_irqchip_add(gc, &iproc_gpio_irq_chip, 0,
+		chip->irqchip.name = "bcm-iproc-gpio";
+		chip->irqchip.irq_ack = iproc_gpio_irq_ack;
+		chip->irqchip.irq_mask = iproc_gpio_irq_mask;
+		chip->irqchip.irq_unmask = iproc_gpio_irq_unmask;
+		chip->irqchip.irq_set_type = iproc_gpio_irq_set_type;
+		chip->irqchip.irq_enable = iproc_gpio_irq_unmask;
+		chip->irqchip.irq_disable = iproc_gpio_irq_mask;
+
+		ret = gpiochip_irqchip_add(gc, &chip->irqchip, 0,
 					   handle_simple_irq, IRQ_TYPE_NONE);
 		if (ret) {
 			dev_err(dev, "no GPIO irqchip\n");
 			goto err_rm_gpiochip;
 		}
 
-		gpiochip_set_chained_irqchip(gc, &iproc_gpio_irq_chip, irq,
+		gpiochip_set_chained_irqchip(gc, &chip->irqchip, irq,
 					     iproc_gpio_irq_handler);
 	}
 
-- 
2.7.4


_______________________________________________
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 v2 07/10] PCI: layerscape: Modify the MSIX to the doorbell way
From: Kishon Vijay Abraham I @ 2019-08-29  5:13 UTC (permalink / raw)
  To: Andrew Murray, Xiaowei Bao, gustavo.pimentel@synopsys.com
  Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
	arnd@arndb.de, devicetree@vger.kernel.org,
	gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
	M.h. Lian, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org, jingoohan1@gmail.com,
	bhelgaas@google.com, shawnguo@kernel.org, Mingkai Hu
In-Reply-To: <20190827132504.GL14582@e119886-lin.cambridge.arm.com>

Gustavo,

On 27/08/19 6:55 PM, Andrew Murray wrote:
> On Sat, Aug 24, 2019 at 12:08:40AM +0000, Xiaowei Bao wrote:
>>
>>
>>> -----Original Message-----
>>> From: Andrew Murray <andrew.murray@arm.com>
>>> Sent: 2019年8月23日 21:58
>>> To: Xiaowei Bao <xiaowei.bao@nxp.com>
>>> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
>>> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
>>> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
>>> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
>>> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
>>> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
>>> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
>>> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [PATCH v2 07/10] PCI: layerscape: Modify the MSIX to the
>>> doorbell way
>>>
>>> On Thu, Aug 22, 2019 at 07:22:39PM +0800, Xiaowei Bao wrote:
>>>> The layerscape platform use the doorbell way to trigger MSIX interrupt
>>>> in EP mode.
>>>>
>>>
>>> I have no problems with this patch, however...
>>>
>>> Are you able to add to this message a reason for why you are making this
>>> change? Did dw_pcie_ep_raise_msix_irq not work when func_no != 0? Or did
>>> it work yet dw_pcie_ep_raise_msix_irq_doorbell is more efficient?
>>
>> The fact is that, this driver is verified in ls1046a platform of NXP before, and ls1046a don't
>> support MSIX feature, so I set the msix_capable of pci_epc_features struct is false,
>> but in other platform, e.g. ls1088a, it support the MSIX feature, I verified the MSIX
>> feature in ls1088a, it is not OK, so I changed to another way. Thanks.
> 
> Right, so the existing pci-layerscape-ep.c driver never supported MSIX yet it
> erroneously had a switch case statement to call dw_pcie_ep_raise_msix_irq which
> would never get used.
> 
> Now that we're adding a platform with MSIX support the existing
> dw_pcie_ep_raise_msix_irq doesn't work (for this platform) so we are adding a
> different method.

Gustavo, can you confirm dw_pcie_ep_raise_msix_irq() works for designware as it
didn't work for both me and Xiaowei?

Thanks
Kishon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v7 13/13] arm64: dts: Add power controller device node of MT8183
From: CK Hu @ 2019-08-29  5:15 UTC (permalink / raw)
  To: Weiyi Lu
  Cc: Rob Herring, Nicolas Boichat, srv_heupstream, James Liao,
	linux-kernel, Fan Chen, linux-mediatek, linux-arm-kernel,
	Matthias Brugger, Yong Wu
In-Reply-To: <1566983506-26598-14-git-send-email-weiyi.lu@mediatek.com>

Hi, Weiyi:

On Wed, 2019-08-28 at 17:11 +0800, Weiyi Lu wrote:
> Add power controller node and smi-common node for MT8183
> In scpsys node, it contains clocks and regmapping of
> infracfg and smi-common for bus protection.
> 
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c2749c4..66aaa07 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -8,6 +8,7 @@
>  #include <dt-bindings/clock/mt8183-clk.h>
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/power/mt8183-power.h>
>  #include "mt8183-pinfunc.h"
>  
>  / {
> @@ -238,6 +239,62 @@
>  			#interrupt-cells = <2>;
>  		};
>  
> +		scpsys: syscon@10006000 {
> +			compatible = "mediatek,mt8183-scpsys", "syscon";
> +			#power-domain-cells = <1>;
> +			reg = <0 0x10006000 0 0x1000>;
> +			clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
> +				 <&infracfg CLK_INFRA_AUDIO>,
> +				 <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
> +				 <&topckgen CLK_TOP_MUX_MFG>,
> +				 <&topckgen CLK_TOP_MUX_MM>,
> +				 <&topckgen CLK_TOP_MUX_CAM>,
> +				 <&topckgen CLK_TOP_MUX_IMG>,
> +				 <&topckgen CLK_TOP_MUX_IPU_IF>,
> +				 <&topckgen CLK_TOP_MUX_DSP>,
> +				 <&topckgen CLK_TOP_MUX_DSP1>,
> +				 <&topckgen CLK_TOP_MUX_DSP2>,
> +				 <&mmsys CLK_MM_SMI_COMMON>,
> +				 <&mmsys CLK_MM_SMI_LARB0>,
> +				 <&mmsys CLK_MM_SMI_LARB1>,
> +				 <&mmsys CLK_MM_GALS_COMM0>,
> +				 <&mmsys CLK_MM_GALS_COMM1>,
> +				 <&mmsys CLK_MM_GALS_CCU2MM>,
> +				 <&mmsys CLK_MM_GALS_IPU12MM>,
> +				 <&mmsys CLK_MM_GALS_IMG2MM>,
> +				 <&mmsys CLK_MM_GALS_CAM2MM>,
> +				 <&mmsys CLK_MM_GALS_IPU2MM>,

Just mention the discussion in [1], we need to confirm this is hardware
limitation or not.

[1] https://patchwork.kernel.org/patch/11005731/

Regards,
CK

> +				 <&imgsys CLK_IMG_LARB5>,
> +				 <&imgsys CLK_IMG_LARB2>,
> +				 <&camsys CLK_CAM_LARB6>,
> +				 <&camsys CLK_CAM_LARB3>,
> +				 <&camsys CLK_CAM_SENINF>,
> +				 <&camsys CLK_CAM_CAMSV0>,
> +				 <&camsys CLK_CAM_CAMSV1>,
> +				 <&camsys CLK_CAM_CAMSV2>,
> +				 <&camsys CLK_CAM_CCU>,
> +				 <&ipu_conn CLK_IPU_CONN_IPU>,
> +				 <&ipu_conn CLK_IPU_CONN_AHB>,
> +				 <&ipu_conn CLK_IPU_CONN_AXI>,
> +				 <&ipu_conn CLK_IPU_CONN_ISP>,
> +				 <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
> +				 <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
> +			clock-names = "audio", "audio1", "audio2",
> +				      "mfg", "mm", "cam",
> +				      "isp", "vpu", "vpu1",
> +				      "vpu2", "vpu3", "mm-0",
> +				      "mm-1", "mm-2", "mm-3",
> +				      "mm-4", "mm-5", "mm-6",
> +				      "mm-7", "mm-8", "mm-9",
> +				      "isp-0", "isp-1", "cam-0",
> +				      "cam-1", "cam-2", "cam-3",
> +				      "cam-4", "cam-5", "cam-6",
> +				      "vpu-0", "vpu-1", "vpu-2",
> +				      "vpu-3", "vpu-4", "vpu-5";
> +			infracfg = <&infracfg>;
> +			smi_comm = <&smi_common>;
> +		};
> +
>  		apmixedsys: syscon@1000c000 {
>  			compatible = "mediatek,mt8183-apmixedsys", "syscon";
>  			reg = <0 0x1000c000 0 0x1000>;
> @@ -396,6 +453,11 @@
>  			#clock-cells = <1>;
>  		};
>  
> +		smi_common: smi@14019000 {
> +			compatible = "mediatek,mt8183-smi-common", "syscon";
> +			reg = <0 0x14019000 0 0x1000>;
> +		};
> +
>  		imgsys: syscon@15020000 {
>  			compatible = "mediatek,mt8183-imgsys", "syscon";
>  			reg = <0 0x15020000 0 0x1000>;



_______________________________________________
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 v5 09/10] rtc: mt6397: fix alarm register overwrite
From: Hsin-hsiung Wang @ 2019-08-29  5:34 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
	devicetree, Greg Kroah-Hartman, Ran Bi, Sean Wang, Liam Girdwood,
	Rob Herring, linux-kernel, Richard Fontana, Mark Brown,
	linux-mediatek, Kate Stewart, Thomas Gleixner, Eddie Huang,
	Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <bf8435a7-db97-5ed8-bccc-9d197396aeb6@gmail.com>

Hi Matthias,

On Fri, 2019-08-23 at 17:35 +0200, Matthias Brugger wrote:
> 
> On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> > From: Ran Bi <ran.bi@mediatek.com>
> > 
> > Alarm registers high byte was reserved for other functions.
> > This add mask in alarm registers operation functions.
> > This also fix error condition in interrupt handler.
> > 
> > Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
> > 
> > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Signed-off-by: Ran Bi <ran.bi@mediatek.com>
> 
> Misses your Signed-off-by.
> 

I will add it in the next patch, thanks.

> Regards,
> Matthias
> 
> > ---
> >  drivers/rtc/rtc-mt6397.c | 47 +++++++++++++++++++++++++++++++++--------------
> >  1 file changed, 33 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> > index b46ed4d..828def7 100644
> > --- a/drivers/rtc/rtc-mt6397.c
> > +++ b/drivers/rtc/rtc-mt6397.c
> > @@ -47,6 +47,14 @@
> >  
> >  #define RTC_AL_SEC		0x0018
> >  
> > +#define RTC_AL_SEC_MASK		0x003f
> > +#define RTC_AL_MIN_MASK		0x003f
> > +#define RTC_AL_HOU_MASK		0x001f
> > +#define RTC_AL_DOM_MASK		0x001f
> > +#define RTC_AL_DOW_MASK		0x0007
> > +#define RTC_AL_MTH_MASK		0x000f
> > +#define RTC_AL_YEA_MASK		0x007f
> > +
> >  #define RTC_PDN2		0x002e
> >  #define RTC_PDN2_PWRON_ALARM	BIT(4)
> >  
> > @@ -103,7 +111,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
> >  		irqen = irqsta & ~RTC_IRQ_EN_AL;
> >  		mutex_lock(&rtc->lock);
> >  		if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> > -				 irqen) < 0)
> > +				 irqen) == 0)
> >  			mtk_rtc_write_trigger(rtc);
> >  		mutex_unlock(&rtc->lock);
> >  
> > @@ -225,12 +233,12 @@ static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> >  	alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> >  	mutex_unlock(&rtc->lock);
> >  
> > -	tm->tm_sec = data[RTC_OFFSET_SEC];
> > -	tm->tm_min = data[RTC_OFFSET_MIN];
> > -	tm->tm_hour = data[RTC_OFFSET_HOUR];
> > -	tm->tm_mday = data[RTC_OFFSET_DOM];
> > -	tm->tm_mon = data[RTC_OFFSET_MTH];
> > -	tm->tm_year = data[RTC_OFFSET_YEAR];
> > +	tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> > +	tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> > +	tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> > +	tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> > +	tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> > +	tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
> >  
> >  	tm->tm_year += RTC_MIN_YEAR_OFFSET;
> >  	tm->tm_mon--;
> > @@ -251,14 +259,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> >  	tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> >  	tm->tm_mon++;
> >  
> > -	data[RTC_OFFSET_SEC] = tm->tm_sec;
> > -	data[RTC_OFFSET_MIN] = tm->tm_min;
> > -	data[RTC_OFFSET_HOUR] = tm->tm_hour;
> > -	data[RTC_OFFSET_DOM] = tm->tm_mday;
> > -	data[RTC_OFFSET_MTH] = tm->tm_mon;
> > -	data[RTC_OFFSET_YEAR] = tm->tm_year;
> > -
> >  	mutex_lock(&rtc->lock);
> > +	ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> > +			       data, RTC_OFFSET_COUNT);
> > +	if (ret < 0)
> > +		goto exit;
> > +
> > +	data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> > +				(tm->tm_sec & RTC_AL_SEC_MASK));
> > +	data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> > +				(tm->tm_min & RTC_AL_MIN_MASK));
> > +	data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK)) |
> > +				(tm->tm_hour & RTC_AL_HOU_MASK));
> > +	data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> > +				(tm->tm_mday & RTC_AL_DOM_MASK));
> > +	data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> > +				(tm->tm_mon & RTC_AL_MTH_MASK));
> > +	data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK)) |
> > +				(tm->tm_year & RTC_AL_YEA_MASK));
> > +
> >  	if (alm->enabled) {
> >  		ret = regmap_bulk_write(rtc->regmap,
> >  					rtc->addr_base + RTC_AL_SEC,
> > 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek



_______________________________________________
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 2/2] clk: imx: disable i.mx7ulp composite clock during initialization
From: Anson Huang @ 2019-08-29  5:52 UTC (permalink / raw)
  To: Stephen Boyd, festevam@gmail.com, gustavo@embeddedor.com,
	kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	mturquette@baylibre.com, s.hauer@pengutronix.de,
	shawnguo@kernel.org, Aisheng Dong
  Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB3916F96CD6F3E874204E6972F5D50@DB3PR0402MB3916.eurprd04.prod.outlook.com>

Hi, Stephen

> Subject: RE: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during
> initialization
> 
> Hi, Stephen
> 	I think we should resume this thread, without this patch, mainline
> kernel boot up will cause mmc timeout all the time. If it is NOT good to
> disabling those peripheral devices' clock in i.MX7ULP's clock driver, then we
> have to change the core framework to disable clock explicitly if the
> CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE is present, most likely it will
> impact other platforms I think, so the most safe way is just to do it inside our
> i.MX7ULP composite clock driver. What do you think?

What is your opinion on this?

Thanks,
Anson

> 
> Thanks,
> Anson
> 
> > Hi, Stephen
> >
> > > Quoting Anson Huang (2019-04-24 22:19:12)
> > > > i.MX7ULP peripheral clock ONLY allow parent/rate to be changed
> > > > with clock gated, however, during clock tree initialization, the
> > > > peripheral clock could be enabled by bootloader, but the prepare
> > > > count in clock tree is still zero, so clock core driver will allow
> > > > parent/rate changed even with
> > CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE
> > >
> > > That's a bug. Can you send a patch to fix the core framework code to
> > > fail an assigned rate or parent change if those flags are set? Or is
> > > that because the core doesn't respect these flags when they're
> > > buried in the middle of the clk tree and some rate or parent change
> > > comes in and affects the middle of the tree that has the flag set on it?
> >
> > If changing the core framework code to return fail for clk parent/rate
> > assignment, that means clk assignment in DT will NOT work for
> > i.MX7ULP, then all the clk rate/parent settings will be done in
> > driver? That will lead to more issues/changes.
> >
> > It is just because core framework ONLY checks the prepare_count and
> > CLK_SET_PARENT_GATE flag to determine if the parent switch is allowed,
> > however, during clock tree initialization, the prepare_count is always
> > 0 but the HW status could be enabled actually, so the core framework
> > will allow the parent switch while HW status does NOT allow the parent
> > switch, so core framework will treat the parent switch successfully but HW
> is actually NOT.
> >
> > I think we can treat it as platform specific issue, if bootloader can
> > guarantee all peripheral clocks are disabled before jumping to kernel,
> > then there will be no issue, but we can NOT assume that, so I have to
> > find some place in early kernel phase to disable those peripheral clocks.
> >
> > >
> > > > set, but the change will fail due to HW NOT allow parent/rate
> > > > change with clock enabled. It will cause clock HW status mismatch
> > > > with clock tree info and lead to function issue. Below is an example:
> > > >
> > > > usdhc0's pcc clock value is 0xC5000000 during kernel boot up, it
> > > > means
> > > > usdhc0 clock is enabled, its parent is APLL_PFD1. In DT file, the
> > > > usdhc0 clock settings are as below:
> > > >
> > > > assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC0>;
> > > > assigned-clock-parents =
> > > > <&scg1 IMX7ULP_CLK_NIC1_DIV>;
> > > >
> > > > when kernel boot up, the clock tree info is as below, but the
> > > > usdhc0 PCC register is still 0xC5000000, which means its parent is
> > > > still from APLL_PFD1, which is incorrect and cause usdhc0 NOT work.
> > > >
> > > > nic1_clk       2        2        0   176000000          0     0  50000
> > > >     usdhc0       0        0        0   176000000          0     0  50000
> > > >
> > > > After making sure the peripheral clock is disabled during clock
> > > > tree initialization, the usdhc0 is working, and this change is
> > > > necessary for all i.MX7ULP peripheral clocks.
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > > ---
> > > >  drivers/clk/imx/clk-composite-7ulp.c | 13 +++++++++++++
> > > >  1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-composite-7ulp.c
> > > > b/drivers/clk/imx/clk-composite-7ulp.c
> > > > index 060f860..1a05411 100644
> > > > --- a/drivers/clk/imx/clk-composite-7ulp.c
> > > > +++ b/drivers/clk/imx/clk-composite-7ulp.c
> > > > @@ -32,6 +32,7 @@ struct clk_hw *imx7ulp_clk_composite(const char
> > > *name,
> > > >         struct clk_gate *gate = NULL;
> > > >         struct clk_mux *mux = NULL;
> > > >         struct clk_hw *hw;
> > > > +       u32 val;
> > > >
> > > >         if (mux_present) {
> > > >                 mux = kzalloc(sizeof(*mux), GFP_KERNEL); @@ -70,6
> > > > +71,18 @@ struct clk_hw *imx7ulp_clk_composite(const char *name,
> > > >                 gate_hw = &gate->hw;
> > > >                 gate->reg = reg;
> > > >                 gate->bit_idx = PCG_CGC_SHIFT;
> > > > +               /*
> > > > +                * make sure clock is gated during clock tree initialization,
> > > > +                * the HW ONLY allow clock parent/rate changed
> > > > + with clock
> > gated,
> > > > +                * during clock tree initialization, clocks could be enabled
> > > > +                * by bootloader, so the HW status will mismatch with clock
> tree
> > > > +                * prepare count, then clock core driver will allow parent/rate
> > > > +                * change since the prepare count is zero, but HW actually
> > > > +                * prevent the parent/rate change due to the clock is enabled.
> > > > +                */
> > >
> > > Is it OK to forcibly gate the clk like this at init time? If so, why
> > > can't we force the clk off when we change the rate and then restore
> > > the on state after changing the rate? That would be more "robust"
> > > than doing it once here. Plus then we could remove the
> > > CLK_SET_RATE_GATE
> > flag.
> >
> > Yes, it is ONLY for composite clocks which are for peripheral clocks,
> > ONLY earlycon could be impacted but we can add
> > imx_register_uart_clocks() call to make earlycon also work.
> >
> > Forcing the clk off and restore them ON for rate/parent change will
> > need to change common composite clock ops, currently i.MX7ULP all use
> > common ops, so unless i.MX7ULP implements composite clock ops, and the
> > change will be very significant.
> >
> > Thanks,
> > Anson
> >
> > >
> > > > +               val = readl_relaxed(reg);
> > > > +               val &= ~(1 << PCG_CGC_SHIFT);
> > > > +               writel_relaxed(val, reg);
> > > >         }
> > > >
_______________________________________________
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 v5 07/10] regulator: mt6358: Add support for MT6358 regulator
From: Hsin-hsiung Wang @ 2019-08-29  6:09 UTC (permalink / raw)
  To: Mark Brown
  Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
	devicetree, Greg Kroah-Hartman, Sean Wang, Liam Girdwood,
	linux-kernel, Richard Fontana, Rob Herring, linux-mediatek,
	linux-arm-kernel, Matthias Brugger, Thomas Gleixner, Eddie Huang,
	Lee Jones, Kate Stewart, linux-rtc
In-Reply-To: <20190828104555.GE4298@sirena.co.uk>

Hi Mark,

On Wed, 2019-08-28 at 11:45 +0100, Mark Brown wrote:
> On Fri, Aug 23, 2019 at 11:45:28AM +0800, Hsin-Hsiung Wang wrote:
> > The MT6358 is a regulator found on boards based on MediaTek MT8183 and
> > probably other SoCs. It is a so called pmic and connects as a slave to
> > SoC using SPI, wrapped inside the pmic-wrapper.
> 
> This looks good - since there was only one small issue with the example
> in the binding document I'll apply both patches, please send a followup
> fixing the binding document.

Thanks for your comment.
I will update the binding document in the next patch.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-08-29  6:23 UTC (permalink / raw)
  To: Robin Gong, Leonard Crestez
  Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VE1PR04MB663818AE90C9997DC340250989A30@VE1PR04MB6638.eurprd04.prod.outlook.com>

On 8/28/19 4:05 PM, Robin Gong wrote:
> Could you help check if below commit in your side?
> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
> Author: Lucas Stach<l.stach@pengutronix.de>
> Date:   Tue Nov 6 03:40:28 2018 +0000

yes, it's in.

Also the 2 follow-up commits of Lucas Stach: 
9063f5a99ea76f85935e3e453422d15e7be89b9e and 
374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.

And that are the last commits on drivers/dma/imx-sdma.c for my 
4.19.x+fslc branch. But I have already tried 5.1.x+fslc, and it also got 
stuck.

Kind regards,

Jürgen

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: Aw: Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Hsin-hsiung Wang @ 2019-08-29  6:24 UTC (permalink / raw)
  To: Frank Wunderlich, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
	devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
	Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
	linux-mediatek, Kate Stewart, "René van Dorst",
	Thomas Gleixner, Eddie Huang, Lee Jones, linux-arm-kernel,
	linux-rtc
In-Reply-To: <trinity-a57f08bb-e30e-4e74-911c-c40e335d00da-1566580580817@3c-app-gmx-bs75>

Hi Frank/Matthias,

On Fri, 2019-08-23 at 19:16 +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 23. August 2019 um 17:42 Uhr
> > Von: "Matthias Brugger" <matthias.bgg@gmail.com>
> 
> > I suppose that's because 3/10 has code that should be in 2/10 and for some
> > reason 3/10 was not pushed for linux-next inclusion. Although it has the same
> > Acked-for-mfd-by tag.
> >
> > @Frank, can you test if adding 3/10 to your code base fixes the issue?
> 
> adding part 3 [1] seems to fix the issue too
> 
> [    4.960051] mt6323-regulator mt6323-regulator: Chip ID = 0x2023
> 
> thanks
> 
> [1] https://patchwork.kernel.org/patch/11110509/
Thanks for your comments.
The root cause seems I didn't split the code well.
I will fix it in the next version.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ARM: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer
From: Nathan Chancellor @ 2019-08-29  6:26 UTC (permalink / raw)
  To: Russell King
  Cc: Arnd Bergmann, Nick Desaulniers, linux-kernel, Stefan Agner,
	clang-built-linux, Matthias Kaehlcke, Nathan Chancellor,
	linux-arm-kernel

Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
with clang:

arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
softirq.c:(.text+0x504): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
softirq.c:(.text+0x58c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
softirq.c:(.text+0x6c8): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
softirq.c:(.text+0x75c): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
softirq.c:(.text+0x840): undefined reference to `mcount'
arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more undefined references to `mcount' follow

clang can emit a working mcount symbol, __gnu_mcount_nc, when
'-meabi gnu' is passed to it. Until r369147 in LLVM, this was
broken and caused the kernel not to boot because the calling
convention was not correct. Now that it is fixed, add this to
the command line when clang is 10.0.0 or newer so everything
works properly.

Link: https://github.com/ClangBuiltLinux/linux/issues/35
Link: https://bugs.llvm.org/show_bug.cgi?id=33845
Link: https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
 arch/arm/Makefile | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..7b5a26a866fc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -112,6 +112,12 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
 CFLAGS_ABI	+=-funwind-tables
 endif
 
+ifeq ($(CONFIG_CC_IS_CLANG),y)
+ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 100000; echo $$?),0)
+CFLAGS_ABI	+=-meabi gnu
+endif
+endif
+
 # Accept old syntax despite ".syntax unified"
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
 
-- 
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: [arm:for-next 13/25] include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
From: Leo Yan @ 2019-08-29  6:43 UTC (permalink / raw)
  To: kbuild test robot; +Cc: Russell King, Will Deacon, kbuild-all, linux-arm-kernel
In-Reply-To: <201908290809.FsnDYulr%lkp@intel.com>

Hi Russell,

On Thu, Aug 29, 2019 at 08:49:16AM +0800, kbuild test robot wrote:
> tree:   git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
> head:   d0d54dc04e37be14a9e51d9a2e431f302948e99d
> commit: 566c290c6498b2fdc04a54556c4e8747f0298c7b [13/25] ARM: 8899/1: arm/arm64: Add support for function error injection
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout 566c290c6498b2fdc04a54556c4e8747f0298c7b
>         # save the attached .config to linux build tree
>         GCC_VERSION=7.4.0 make.cross ARCH=arm 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
> 
> All errors (new ones prefixed by >>):
> 
>    In file included from include/linux/module.h:22:0,
>                     from drivers/pps/pps.c:11:
> >> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
>     #include <asm/error-injection.h>
>              ^~~~~~~~~~~~~~~~~~~~~~~
>    compilation terminated.

This building error is caused by there have a dependent patch:
error-injection: Consolidate override function definition
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/error-injection&id=45880f7b7b19e043ce0aaa4cb7d05369425c82fa

This patch has been picked up by Will in one of arm64's next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/error-injection

I don't know what's the best practice for the dependency between
two branches, if need me to follow up anything, please let me know.

Thanks,
Leo.

> vim +7 include/linux/error-injection.h
> 
> 540adea3809f61 Masami Hiramatsu 2018-01-13  6  
> 540adea3809f61 Masami Hiramatsu 2018-01-13 @7  #include <asm/error-injection.h>
> 540adea3809f61 Masami Hiramatsu 2018-01-13  8  
> 
> :::::: The code at line 7 was first introduced by commit
> :::::: 540adea3809f61115d2a1ea4ed6e627613452ba1 error-injection: Separate error-injection from kprobe
> 
> :::::: TO: Masami Hiramatsu <mhiramat@kernel.org>
> :::::: CC: Alexei Starovoitov <ast@kernel.org>
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 3/3] arm: Add support for function error injection
From: Russell King - ARM Linux admin @ 2019-08-29  6:57 UTC (permalink / raw)
  To: Leo Yan
  Cc: Song Liu, Benjamin Herrenschmidt, Alexei Starovoitov,
	Oleg Nesterov, Paul Mackerras, H. Peter Anvin, Will Deacon,
	linux-arch, Daniel Borkmann, Michael Ellerman, x86,
	clang-built-linux, Ingo Molnar, Catalin Marinas, Yonghong Song,
	Naveen N. Rao, Arnd Bergmann, Borislav Petkov, Thomas Gleixner,
	linux-arm-kernel, netdev, linux-kernel, Masami Hiramatsu, bpf,
	linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190819091808.GB5599@leoy-ThinkPad-X240s>

I'm sorry, I can't apply this, it produces loads of:

include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory

Since your patch 1 has been merged by the ARM64 people, I can't take
it until next cycle.

On Mon, Aug 19, 2019 at 05:18:08PM +0800, Leo Yan wrote:
> Hi Russell,
> 
> On Tue, Aug 06, 2019 at 06:00:15PM +0800, Leo Yan wrote:
> > This patch implements arm specific functions regs_set_return_value() and
> > override_function_with_return() to support function error injection.
> > 
> > In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
> > so can override the probed function return.
> 
> Gentle ping ...  Could you review this patch?
> 
> Thanks,
> Leo.
> 
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> >  arch/arm/Kconfig              |  1 +
> >  arch/arm/include/asm/ptrace.h |  5 +++++
> >  arch/arm/lib/Makefile         |  2 ++
> >  arch/arm/lib/error-inject.c   | 19 +++++++++++++++++++
> >  4 files changed, 27 insertions(+)
> >  create mode 100644 arch/arm/lib/error-inject.c
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 33b00579beff..2d3d44a037f6 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -77,6 +77,7 @@ config ARM
> >  	select HAVE_EXIT_THREAD
> >  	select HAVE_FAST_GUP if ARM_LPAE
> >  	select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > +	select HAVE_FUNCTION_ERROR_INJECTION if !THUMB2_KERNEL
> >  	select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> >  	select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> >  	select HAVE_GCC_PLUGINS
> > diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> > index 91d6b7856be4..3b41f37b361a 100644
> > --- a/arch/arm/include/asm/ptrace.h
> > +++ b/arch/arm/include/asm/ptrace.h
> > @@ -89,6 +89,11 @@ static inline long regs_return_value(struct pt_regs *regs)
> >  	return regs->ARM_r0;
> >  }
> >  
> > +static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> > +{
> > +	regs->ARM_r0 = rc;
> > +}
> > +
> >  #define instruction_pointer(regs)	(regs)->ARM_pc
> >  
> >  #ifdef CONFIG_THUMB2_KERNEL
> > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> > index b25c54585048..8f56484a7156 100644
> > --- a/arch/arm/lib/Makefile
> > +++ b/arch/arm/lib/Makefile
> > @@ -42,3 +42,5 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> >    CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
> >    obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
> >  endif
> > +
> > +obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
> > diff --git a/arch/arm/lib/error-inject.c b/arch/arm/lib/error-inject.c
> > new file mode 100644
> > index 000000000000..2d696dc94893
> > --- /dev/null
> > +++ b/arch/arm/lib/error-inject.c
> > @@ -0,0 +1,19 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include <linux/error-injection.h>
> > +#include <linux/kprobes.h>
> > +
> > +void override_function_with_return(struct pt_regs *regs)
> > +{
> > +	/*
> > +	 * 'regs' represents the state on entry of a predefined function in
> > +	 * the kernel/module and which is captured on a kprobe.
> > +	 *
> > +	 * 'regs->ARM_lr' contains the the link register for the probed
> > +	 * function, when kprobe returns back from exception it will override
> > +	 * the end of probed function and directly return to the predefined
> > +	 * function's caller.
> > +	 */
> > +	instruction_pointer_set(regs, regs->ARM_lr);
> > +}
> > +NOKPROBE_SYMBOL(override_function_with_return);
> > -- 
> > 2.17.1
> > 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Matthias Brugger @ 2019-08-29  7:03 UTC (permalink / raw)
  To: David Miller
  Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
	opensource, linux-mediatek, john, sr, linux-arm-kernel
In-Reply-To: <20190828.125658.1743313522645522716.davem@davemloft.net>



On 28/08/2019 21:56, David Miller wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> Date: Wed, 28 Aug 2019 11:29:45 +0200
> 
>> Thanks for taking this patch. For the next time, please make sure that dts[i]
>> patches are independent from the binding description, as dts[i] should go
>> through my tree. No problem for this round, just saying for the future.
> 
> That's not always possible nor reasonable, to be quite honest.
> 

Right now no case comes to my mind. What would be a case where this is not
reasonable or possible?

Regards,
Matthias

_______________________________________________
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/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Jorge Ramirez @ 2019-08-29  7:03 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: mark.rutland, robh, jackp, kishon, gregkh, linux-usb,
	khasim.mohammed, linux-kernel, swboyd, devicetree, linux-arm-msm,
	andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <20190223165218.GB572@tuxbook-pro>

On 2/23/19 17:52, Bjorn Andersson wrote:
> On Thu 07 Feb 03:17 PST 2019, Jorge Ramirez-Ortiz wrote:
> 
>> Binding description for Qualcomm's Synopsys 1.0.0 SuperSpeed phy
>> controller embedded in QCS404.
>>
>> Based on Sriharsha Allenki's <sallenki@codeaurora.org> original
>> definitions.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
>> ---
>>  .../bindings/phy/qcom,snps-usb-ssphy.txt      | 79 +++++++++++++++++++
>>  1 file changed, 79 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt b/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>> new file mode 100644
>> index 000000000000..354e6f9cef62
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>> @@ -0,0 +1,79 @@
>> +Qualcomm Synopsys 1.0.0 SS phy controller
>> +===========================================
>> +
>> +Qualcomm 1.0.0 SS phy controller supports SuperSpeed USB connectivity on
>> +some Qualcomm platforms.
>> +
>> +Required properties:
>> +
>> +- compatible:
>> +    Value type: <string>
>> +    Definition: Should contain "qcom,snps-usb-ssphy".
> 
> Per Rob's request make this:
> 
> Should contain "qcom,qcs404-snps-usb-ssphy" and "qcom,snps-usb-ssphy"

ok

> 
> You can then leave the driver matching on qcom,snps-usb-ssphy for now
> and if we ever find this to be incompatible with other platforms we can
> make the driver match on the platform-specific compatible.

ok

> 
>> +
>> +- reg:
>> +    Value type: <prop-encoded-array>
>> +    Definition: USB PHY base address and length of the register map.
>> +
>> +- #phy-cells:
>> +    Value type: <u32>
>> +    Definition: Should be 0. See phy/phy-bindings.txt for details.
>> +
>> +- clocks:
>> +    Value type: <prop-encoded-array>
>> +    Definition: See clock-bindings.txt section "consumers". List of
>> +		 three clock specifiers for reference, phy core and
>> +		 pipe clocks.
>> +
>> +- clock-names:
>> +    Value type: <string>
>> +    Definition: Names of the clocks in 1-1 correspondence with the "clocks"
>> +		 property. Must contain "ref", "phy" and "pipe".
>> +
>> +- vdd-supply:
>> +    Value type: <phandle>
>> +    Definition: phandle to the regulator VDD supply node.
>> +
>> +- vdda1p8-supply:
>> +    Value type: <phandle>
>> +    Definition: phandle to the regulator 1.8V supply node.
>> +
>> +Optional properties:
>> +
>> +- resets:
>> +    Value type: <prop-encoded-array>
>> +    Definition: See reset.txt section "consumers". Specifiers for COM and
>> +		 PHY resets.
>> +
>> +- reset-names:
>> +    Value type: <string>
>> +    Definition: Names of the resets in 1-1 correspondence with the "resets"
>> +		 property. Must contain "com" and "phy" if the property is
>> +		 specified.
>> +
>> +Required child nodes:
>> +
>> +- usb connector node as defined in bindings/connector/usb-connector.txt
>> +  containing the property vbus-supply.
>> +
>> +Example:
>> +
>> +usb3_phy: usb3-phy@78000 {
>> +	compatible = "qcom,snps-usb-ssphy";
>> +	reg = <0x78000 0x400>;
>> +	#phy-cells = <0>;
>> +	clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
>> +		 <&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
>> +		 <&gcc GCC_USB3_PHY_PIPE_CLK>;
>> +	clock-names = "ref", "phy", "pipe";
>> +	resets = <&gcc GCC_USB3_PHY_BCR>,
>> +		 <&gcc GCC_USB3PHY_PHY_BCR>;
>> +	reset-names = "com", "phy";
>> +	vdd-supply = <&vreg_l3_1p05>;
>> +	vdda1p8-supply = <&vreg_l5_1p8>;
>> +	usb3_c_connector: usb3-c-connector {
> 
> The USB-C connector is attached both to the HS and SS PHYs, so I think
> you should represent this external to this node and use of_graph to
> query it.

but AFAICS we wont be able to retrieve the vbux-supply from an external
node (that interface does not exist).

rob, do you have a suggestion?

> 
> So the connector should look similar to example 2 in
> connector/usb-connector.txt.
> 
> Regards,
> Bjorn
> 
>> +		compatible = "usb-c-connector";
>> +		label = "USB-C";
>> +		type = "micro";
>> +		vbus-supply = <&usb3_vbus_reg>;
>> +	};
>> +};
>> -- 
>> 2.20.1
>>
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-29  7:06 UTC (permalink / raw)
  To: Steven Rostedt, Ingo Molnar, Russell King
  Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823182239.20f9a656@xhacker.debian>

Hi Russell,

On Fri, 23 Aug 2019 18:22:39 +0800 Jisheng Zhang wrote:

> Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
> removed the old mcount support, but forget to remove these three
> declarations. This patch removes them.

May I put this patch into your patch system?

thanks

> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> 
> Changes since v2:
>   - really remove mcount() declaration too. I made a mistake when sending out v2
> 
> Changes since v1:
>   - remove mcount() declaration too
> 
>  arch/arm/include/asm/ftrace.h | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index 18b0197f2384..48ec1d0337da 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -11,7 +11,6 @@
>  #define MCOUNT_INSN_SIZE	4 /* sizeof mcount call */
>  
>  #ifndef __ASSEMBLY__
> -extern void mcount(void);
>  extern void __gnu_mcount_nc(void);
>  
>  #ifdef CONFIG_DYNAMIC_FTRACE
> @@ -23,9 +22,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
>  	/* With Thumb-2, the recorded addresses have the lsb set */
>  	return addr & ~1;
>  }
> -
> -extern void ftrace_caller_old(void);
> -extern void ftrace_call_old(void);
>  #endif
>  
>  #endif


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH pinctrl/fixes] pinctrl: aspeed: Fix spurious mux failures on the AST2500
From: Andrew Jeffery @ 2019-08-29  7:17 UTC (permalink / raw)
  To: linux-gpio
  Cc: linux-aspeed, Andrew Jeffery, linus.walleij, linux-kernel, joel,
	openbmc, linux-arm-kernel, John Wang

Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
was determined to be a partial fix to the problem of acquiring the LPC
Host Controller and GFX regmaps: The AST2500 pin controller may need to
fetch syscon regmaps during expression evaluation as well as when
setting mux state. For example, this case is hit by attempting to export
pins exposing the LPC Host Controller as GPIOs.

An optional eval() hook is added to the Aspeed pinmux operation struct
and called from aspeed_sig_expr_eval() if the pointer is set by the
SoC-specific driver. This enables the AST2500 to perform the custom
action of acquiring its regmap dependencies as required.

John Wang tested the fix on an Inspur FP5280G2 machine (AST2500-based)
where the issue was found, and I've booted the fix on Witherspoon
(AST2500) and Palmetto (AST2400) machines, and poked at relevant pins
under QEMU by forcing mux configurations via devmem before exporting
GPIOs to exercise the driver.

Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers")
Fixes: 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
Reported-by: John Wang <wangzqbj@inspur.com>
Tested-by: John Wang <wangzqbj@inspur.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

---
Hi Linus,

The timing of merging the AST2600 (g6) driver and 674fa8daa8c9 ("pinctrl:
aspeed-g5: Delay acquisition of regmaps") caused a bit of a rough spot a
few weeks back. This fix doesn't cause any such disruption - I've
developed it on top of pinctrl/fixes and back-merged the result into
pinctrl/devel to test for build breakage (via CONFIG_COMPILE_TEST to
enable all of the g4, g5 and g6 drivers). All three ASPEED pinctrl
drivers built successfully, so it should be enough to simply take this
patch through pinctrl/fixes and leave pinctrl/devel as is for the 5.4
merge window.
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 30 +++++++++++++++++++++-
 drivers/pinctrl/aspeed/pinmux-aspeed.c     |  7 +++--
 drivers/pinctrl/aspeed/pinmux-aspeed.h     |  7 ++---
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index ba6438ac4d72..ff84d1afd229 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2552,7 +2552,7 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
 			if (IS_ERR(map))
 				return map;
 		} else
-			map = ERR_PTR(-ENODEV);
+			return ERR_PTR(-ENODEV);
 
 		ctx->maps[ASPEED_IP_LPC] = map;
 		dev_dbg(ctx->dev, "Acquired LPC regmap");
@@ -2562,6 +2562,33 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
 	return ERR_PTR(-EINVAL);
 }
 
+static int aspeed_g5_sig_expr_eval(struct aspeed_pinmux_data *ctx,
+				   const struct aspeed_sig_expr *expr,
+				   bool enabled)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < expr->ndescs; i++) {
+		const struct aspeed_sig_desc *desc = &expr->descs[i];
+		struct regmap *map;
+
+		map = aspeed_g5_acquire_regmap(ctx, desc->ip);
+		if (IS_ERR(map)) {
+			dev_err(ctx->dev,
+				"Failed to acquire regmap for IP block %d\n",
+				desc->ip);
+			return PTR_ERR(map);
+		}
+
+		ret = aspeed_sig_desc_eval(desc, enabled, ctx->maps[desc->ip]);
+		if (ret <= 0)
+			return ret;
+	}
+
+	return 1;
+}
+
 /**
  * Configure a pin's signal by applying an expression's descriptor state for
  * all descriptors in the expression.
@@ -2647,6 +2674,7 @@ static int aspeed_g5_sig_expr_set(struct aspeed_pinmux_data *ctx,
 }
 
 static const struct aspeed_pinmux_ops aspeed_g5_ops = {
+	.eval = aspeed_g5_sig_expr_eval,
 	.set = aspeed_g5_sig_expr_set,
 };
 
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.c b/drivers/pinctrl/aspeed/pinmux-aspeed.c
index 839c01b7953f..57305ca838a7 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.c
@@ -78,11 +78,14 @@ int aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
  * neither the enabled nor disabled state. Thus we must explicitly test for
  * either condition as required.
  */
-int aspeed_sig_expr_eval(const struct aspeed_pinmux_data *ctx,
+int aspeed_sig_expr_eval(struct aspeed_pinmux_data *ctx,
 			 const struct aspeed_sig_expr *expr, bool enabled)
 {
+	int ret;
 	int i;
-	int ret;
+
+	if (ctx->ops->eval)
+		return ctx->ops->eval(ctx, expr, enabled);
 
 	for (i = 0; i < expr->ndescs; i++) {
 		const struct aspeed_sig_desc *desc = &expr->descs[i];
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index 52d299b59ce2..db3457c86f48 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -702,6 +702,8 @@ struct aspeed_pin_function {
 struct aspeed_pinmux_data;
 
 struct aspeed_pinmux_ops {
+	int (*eval)(struct aspeed_pinmux_data *ctx,
+		    const struct aspeed_sig_expr *expr, bool enabled);
 	int (*set)(struct aspeed_pinmux_data *ctx,
 		   const struct aspeed_sig_expr *expr, bool enabled);
 };
@@ -722,9 +724,8 @@ struct aspeed_pinmux_data {
 int aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc, bool enabled,
 			 struct regmap *map);
 
-int aspeed_sig_expr_eval(const struct aspeed_pinmux_data *ctx,
-			 const struct aspeed_sig_expr *expr,
-			 bool enabled);
+int aspeed_sig_expr_eval(struct aspeed_pinmux_data *ctx,
+			 const struct aspeed_sig_expr *expr, bool enabled);
 
 static inline int aspeed_sig_expr_set(struct aspeed_pinmux_data *ctx,
 				      const struct aspeed_sig_expr *expr,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v6 14/14] arm64: dts: Add power controller device node of MT8183
From: Matthias Brugger @ 2019-08-29  7:19 UTC (permalink / raw)
  To: CK Hu, Weiyi Lu
  Cc: Rob Herring, Nicolas Boichat, srv_heupstream, James Liao,
	linux-kernel, Fan Chen, linux-mediatek, linux-arm-kernel, Yong Wu
In-Reply-To: <1561971461.12937.8.camel@mtksdaap41>



On 01/07/2019 10:57, CK Hu wrote:
> Hi, Weiyi:
> 
> On Thu, 2019-06-20 at 10:38 +0800, Weiyi Lu wrote:
>> Add power controller node and smi-common node for MT8183
>> In scpsys node, it contains clocks and regmapping of
>> infracfg and smi-common for bus protection.
>>
>> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
>> ---
>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
>>  1 file changed, 62 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> index 08274bf..75c4881 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> @@ -8,6 +8,7 @@
>>  #include <dt-bindings/clock/mt8183-clk.h>
>>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>>  #include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/power/mt8183-power.h>
>>  
>>  / {
>>  	compatible = "mediatek,mt8183";
>> @@ -196,6 +197,62 @@
>>  			#clock-cells = <1>;
>>  		};
>>  
>> +		scpsys: syscon@10006000 {
>> +			compatible = "mediatek,mt8183-scpsys", "syscon";
>> +			#power-domain-cells = <1>;
>> +			reg = <0 0x10006000 0 0x1000>;
>> +			clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
>> +				 <&infracfg CLK_INFRA_AUDIO>,
>> +				 <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
>> +				 <&topckgen CLK_TOP_MUX_MFG>,
>> +				 <&topckgen CLK_TOP_MUX_MM>,
>> +				 <&topckgen CLK_TOP_MUX_CAM>,
>> +				 <&topckgen CLK_TOP_MUX_IMG>,
>> +				 <&topckgen CLK_TOP_MUX_IPU_IF>,
>> +				 <&topckgen CLK_TOP_MUX_DSP>,
>> +				 <&topckgen CLK_TOP_MUX_DSP1>,
>> +				 <&topckgen CLK_TOP_MUX_DSP2>,
>> +				 <&mmsys CLK_MM_SMI_COMMON>,
>> +				 <&mmsys CLK_MM_SMI_LARB0>,
>> +				 <&mmsys CLK_MM_SMI_LARB1>,
>> +				 <&mmsys CLK_MM_GALS_COMM0>,
>> +				 <&mmsys CLK_MM_GALS_COMM1>,
>> +				 <&mmsys CLK_MM_GALS_CCU2MM>,
>> +				 <&mmsys CLK_MM_GALS_IPU12MM>,
>> +				 <&mmsys CLK_MM_GALS_IMG2MM>,
>> +				 <&mmsys CLK_MM_GALS_CAM2MM>,
>> +				 <&mmsys CLK_MM_GALS_IPU2MM>,
> 
> Up to now, MT8183 mmsys has the same resource with another device node:
> 
> 		mmsys: syscon@14000000 {
> 			compatible = "mediatek,mt8183-mmsys", "syscon";
> 			reg = <0 0x14000000 0 0x1000>;
> 			#clock-cells = <1>;
> 		};
> 
> 		display_components: dispsys@14000000 {
> 			compatible = "mediatek,mt8183-display";
> 			reg = <0 0x14000000 0 0x1000>;
> 			power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> 		};
> 
> I think this two node should be merge into one node, so I've try to
> merge them:
> 
> 		mmsys: syscon@14000000 {
> 			compatible = "mediatek,mt8183-mmsys", "syscon";
> 			reg = <0 0x14000000 0 0x1000>;
> 			power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> 			#clock-cells = <1>;
> 		};
> 
> But I got a kernel panic when boot,
> 
> [    3.458523] Unable to handle kernel paging request at virtual address
> fffffffffffffdfb
> [    3.466999] Mem abort info:
> [    3.470116]   ESR = 0x96000005
> [    3.473268]   Exception class = DABT (current EL), IL = 32 bits
> [    3.479375]   SET = 0, FnV = 0
> [    3.482530]   EA = 0, S1PTW = 0
> [    3.485785] Data abort info:
> [    3.488831]   ISV = 0, ISS = 0x00000005
> [    3.493067]   CM = 0, WnR = 0
> [    3.496229] swapper pgtable: 4k pages, 39-bit VAs, pgdp =
> 000000004f8fa26d
> [    3.503214] [fffffffffffffdfb] pgd=0000000000000000,
> pud=0000000000000000
> [    3.510408] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> [    3.515974] Modules linked in:
> [    3.519023] Process kworker/0:3 (pid: 106, stack limit =
> 0x00000000281d0651)
> [    3.526066] CPU: 0 PID: 106 Comm: kworker/0:3 Tainted: G        W
> 4.19.43 #208
> [    3.533974] Hardware name: MediaTek kukui rev1 board (DT)
> [    3.539374] Workqueue: events deferred_probe_work_func
> [    3.544507] pstate: 20000005 (nzCv daif -PAN -UAO)
> [    3.549294] pc : clk_prepare+0x18/0x40
> [    3.553038] lr : scpsys_clk_enable+0x40/0xb4
> [    3.557299] sp : ffffff800855b9e0
> [    3.560606] x29: ffffff800855b9f0 x28: ffffff93e1e5f594
> [    3.565911] x27: 000000000000000f x26: ffffff93e1e5e9b8
> [    3.571217] x25: 000000003b9aca00 x24: ffffff800858530c
> [    3.576522] x23: ffffffffffffffff x22: fffffffffffffdfb
> [    3.581827] x21: 000000000000000a x20: ffffffccb89aafc8
> [    3.587132] x19: fffffffffffffdfb x18: 00005a5c77082016
> [    3.592438] x17: 0000000000000400 x16: 0000000000000001
> [    3.597743] x15: 0000000000000009 x14: ffffff93e271c908
> [    3.603048] x13: 0000000000000b22 x12: 0000000000000008
> [    3.608353] x11: 0000000001d063de x10: 0000000000000008
> [    3.613659] x9 : 00000000ffffffed x8 : 0000000000000000
> [    3.618964] x7 : 736d6c2dff7224fe x6 : 0000008000000000
> [    3.624269] x5 : 0000000000000000 x4 : 0000000080000000
> [    3.629575] x3 : 002f6d6e74000000 x2 : 0000000000000000
> [    3.634880] x1 : 000000000000000a x0 : fffffffffffffdfb
> [    3.640185] Call trace:
> [    3.642625]  clk_prepare+0x18/0x40
> [    3.646019]  scpsys_clk_enable+0x40/0xb4
> [    3.649935]  scpsys_power_on+0x13c/0x304
> [    3.653850]  scpsys_probe+0xe0/0x5fc
> [    3.657419]  platform_drv_probe+0x80/0xb0
> [    3.661420]  really_probe+0x114/0x28c
> [    3.665075]  driver_probe_device+0x64/0xfc
> [    3.669164]  __device_attach_driver+0xb8/0xd0
> [    3.673513]  bus_for_each_drv+0x88/0xd0
> [    3.677341]  __device_attach+0xac/0x130
> [    3.681169]  device_initial_probe+0x20/0x2c
> [    3.685344]  bus_probe_device+0x34/0x90
> [    3.689172]  deferred_probe_work_func+0x74/0xac
> [    3.693698]  process_one_work+0x210/0x420
> [    3.697700]  worker_thread+0x278/0x3e4
> [    3.701443]  kthread+0x11c/0x12c
> [    3.704665]  ret_from_fork+0x10/0x18
> 
> I'm not really understand what happen, but scpsys and mmsys point to
> each other in MT8183. Why these two node point to each other in MT8183?
> If this is really hardware limitation, we need to solve this in driver.
> If this is not a hardware limitation, I would like to re-organize device
> tree to prevent this problem.
> 

How do you register the clocks?
We would need to have a solution as proposed in:
https://patchwork.kernel.org/cover/10686345/

CK Hu, as far as I remember you wanted to look into it. If you don't have time,
I can give it a try next week. Right now I have a bit of free time to work on that.

Regards,
Matthias

> Regards,
> CK
> 
> 
>> +				 <&imgsys CLK_IMG_LARB5>,
>> +				 <&imgsys CLK_IMG_LARB2>,
>> +				 <&camsys CLK_CAM_LARB6>,
>> +				 <&camsys CLK_CAM_LARB3>,
>> +				 <&camsys CLK_CAM_SENINF>,
>> +				 <&camsys CLK_CAM_CAMSV0>,
>> +				 <&camsys CLK_CAM_CAMSV1>,
>> +				 <&camsys CLK_CAM_CAMSV2>,
>> +				 <&camsys CLK_CAM_CCU>,
>> +				 <&ipu_conn CLK_IPU_CONN_IPU>,
>> +				 <&ipu_conn CLK_IPU_CONN_AHB>,
>> +				 <&ipu_conn CLK_IPU_CONN_AXI>,
>> +				 <&ipu_conn CLK_IPU_CONN_ISP>,
>> +				 <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
>> +				 <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
>> +			clock-names = "audio", "audio1", "audio2",
>> +				      "mfg", "mm", "cam",
>> +				      "isp", "vpu", "vpu1",
>> +				      "vpu2", "vpu3", "mm-0",
>> +				      "mm-1", "mm-2", "mm-3",
>> +				      "mm-4", "mm-5", "mm-6",
>> +				      "mm-7", "mm-8", "mm-9",
>> +				      "isp-0", "isp-1", "cam-0",
>> +				      "cam-1", "cam-2", "cam-3",
>> +				      "cam-4", "cam-5", "cam-6",
>> +				      "vpu-0", "vpu-1", "vpu-2",
>> +				      "vpu-3", "vpu-4", "vpu-5";
>> +			infracfg = <&infracfg>;
>> +			smi_comm = <&smi_common>;
>> +		};
>> +
>>  		apmixedsys: syscon@1000c000 {
>>  			compatible = "mediatek,mt8183-apmixedsys", "syscon";
>>  			reg = <0 0x1000c000 0 0x1000>;
>> @@ -260,6 +317,11 @@
>>  			#clock-cells = <1>;
>>  		};
>>  
>> +		smi_common: smi@14019000 {
>> +			compatible = "mediatek,mt8183-smi-common", "syscon";
>> +			reg = <0 0x14019000 0 0x1000>;
>> +		};
>> +
>>  		imgsys: syscon@15020000 {
>>  			compatible = "mediatek,mt8183-imgsys", "syscon";
>>  			reg = <0 0x15020000 0 0x1000>;
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [EXT] [PATCH v3 0/2] drm: bridge: Add NWL MIPI DSI host controller support
From: Guido Günther @ 2019-08-29  7:22 UTC (permalink / raw)
  To: Robert Chiras
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	jernej.skrabec@siol.net, kernel@pengutronix.de, sam@ravnborg.org,
	narmstrong@baylibre.com, airlied@linux.ie, festevam@gmail.com,
	s.hauer@pengutronix.de, jonas@kwiboo.se,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	a.hajda@samsung.com, robh+dt@kernel.org, arnd@arndb.de,
	dl-linux-imx, daniel@ffwll.ch, shawnguo@kernel.org,
	lee.jones@linaro.org, linux-arm-kernel@lists.infradead.org,
	Laurent.pinchart@ideasonboard.com
In-Reply-To: <1567002587.3209.122.camel@nxp.com>

Hi,
On Wed, Aug 28, 2019 at 02:29:48PM +0000, Robert Chiras wrote:
> Hi Guido,
> 
> I tested this on my setup and it works. My DSI panel is a little bit
> different and it doesn't work with this as-is, but I added some
> improvements on top of this, in order to be able to setup the clocks.
> The changes I made can arrive on top of this as improvements, of
> course, since it will allow this driver to dinamically set the
> video_pll clock for any kind of mode.
> 
> So, for the whole patch-set, you can add:
> Tested-by: Robert Chiras <robert.chiras@nxp.com>
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>

Added for v4, thanks!
 -- Guido

> 
> Best regards,
> Robert
> 
> On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found
> > on i.MX8
> > SoCs.
> > 
> > It adds support for the i.MX8MQ but the same IP core can also be
> > found on e.g.
> > i.MX8QXP. I added the necessary hooks to support other imx8 variants
> > but since
> > I only have imx8mq boards to test I omitted the platform data for
> > other SoCs.
> > 
> > The code is based on NXPs BSP so I added Robert Chiras as
> > Co-authored-by. Robert, if this looks sane could you add your
> > Signed-off-by:?
> > 
> > The most notable changes over the BSP driver are
> >  - Calculate HS mode timing from phy_configure_opts_mipi_dphy
> >  - Perform all clock setup via DT
> >  - Merge nwl-imx and nwl drivers
> >  - Add B0 silion revision quirk
> >  - become a bridge driver to hook into mxsfb (from what I read[0]
> > DCSS, which
> >    also can drive the nwl on the imx8mq will likely not become part
> > of
> >    imx-display-subsystem so it makes sense to make it drive a bridge
> > for dsi as
> >    well).
> >  - Use panel_bridge to attach the panel
> >  - Use multiplex framework instead of accessing syscon directly
> > 
> > This has been tested on a Librem 5 devkit using mxsfb with Robert's
> > patches[1]
> > and the rocktech-jh057n00900 panel driver on next-20190821. The DCSS
> > can later
> > on also act as input source too.
> > 
> > Changes from v2:
> > - Per review comments by Rob Herring
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > August%2F230448.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> > 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C637020674654566414&amp;sdata=JdvAdCPGq2CTsW%2BgXgnAVltWMIfdCDQn
> > dXSLYpnjEH8%3D&amp;reserved=0
> >   - bindings:
> >     - Simplify by restricting to fsl,imx8mq-nwl-dsi
> >     - document reset lines
> >     - add port@{0,1}
> >     - use a real compatible string for the panel
> >     - resets are required
> > - Per review comments by Arnd Bergmann
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > August%2F230868.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> > 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C637020674654566414&amp;sdata=LyJpZjQjMCe5zUdvK8CD8ETucLPxx621gW
> > xtpAr8DM4%3D&amp;reserved=0
> >   - Don't access iomuxc_gpr regs directly. This allows us to drop the
> >     first patch in the series with the iomuxc_gpr field defines.
> > - Per review comments by Laurent Pinchart
> >     - Fix wording in bindings
> > - Add mux-controls to bindings
> > - Don't print error message on dphy probe deferal
> > 
> > Changes from v1:
> > - Per review comments by Sam Ravnborg
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228130.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&amp;sdata=AU2gzIwrbCdIBZenPWWYYX%2BgdX53zc2%2B
> > SQhZbuN%2FWpU%3D&amp;reserved=0
> >   - Change binding docs to YAML
> >   - build: Don't always visit imx-nwl/
> >   - build: Add header-test-y
> >   - Sort headers according to DRM convention
> >   - Use drm_display_mode instead of videmode
> > - Per review comments by Fabio Estevam
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228299.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&amp;sdata=6kpIZ6iNAQ13fMXU6sqENLwy%2FdIWL6ef8j
> > gyas7I0CQ%3D&amp;reserved=0
> >   - Don't restrict build to ARCH_MXC
> >   - Drop unused includes
> >   - Drop unreachable code in imx_nwl_dsi_bridge_mode_fixup()
> >   - Drop remaining calls of dev_err() and use DRM_DEV_ERR()
> >     consistently.
> >   - Use devm_platform_ioremap_resource()
> >   - Drop devm_free_irq() in probe() error path
> >   - Use single line comments where sufficient
> >   - Use <linux/time64.h> instead of defining USEC_PER_SEC
> >   - Make input source select imx8 specific
> >   - Drop <asm/unaligned.h> inclusion (after removal of
> > get_unaligned_le32)
> >   - Drop all EXPORT_SYMBOL_GPL() for functions used in the same
> > module
> >     but different source files.
> >   - Drop nwl_dsi_enable_{rx,tx}_clock() by invoking
> > clk_prepare_enable()
> >     directly
> >   - Remove pointless comment
> > - Laurent Pinchart
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228313.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&amp;sdata=tDlVGeET1CPMH9W%2FqmnePNR51vNaTKD%2F
> > iFOoR9%2FmESc%3D&amp;reserved=0
> >   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228308.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&amp;sdata=NsLGAL8%2BcOC0ZZxxeoGe7VxQCgqSBEN4G3
> > WVGOeZpCo%3D&amp;reserved=0
> >   - Drop (on iMX8MQ) unused csr regmap
> >   - Use NWL_MAX_PLATFORM_CLOCKS everywhere
> >   - Drop get_unaligned_le32() usage
> >   - remove duplicate 'for the' in binding docs
> >   - Don't include unused <linux/clk-provider.h>
> >   - Don't include unused <linux/component.h>
> >   - Drop dpms_mode for tracking state, trust the drm layer on that
> >   - Use pm_runtime_put() instead of pm_runtime_put_sync()
> >   - Don't overwrite encoder type
> >   - Make imx_nwl_platform_data const
> >   - Use the reset controller API instead of open coding that platform
> > specific
> >     part
> >   - Use <linux/bitfield.h> intead of making up our own defines
> >   - name mipi_dsi_transfer less generic: nwl_dsi_transfer
> >   - ensure clean in .remove by calling mipi_dsi_host_unregister.
> >   - prefix constants by NWL_DSI_
> >   - properly format transfer_direction enum
> >   - simplify platform clock handling
> >   - Don't modify state in mode_fixup() and use mode_set() instead
> >   - Drop bridge detach(), already handle by nwl_dsi_host_detach()
> >   - Drop USE_*_QUIRK() macros
> > - Drop (for now) unused clock defnitions. 'pixel' and 'bypass' clock
> > will be
> >   used for i.MX8 SoCs but since they're unused atm drop the
> > definitions - but
> >   keep the logic to enable/disable several clocks in place since we
> > know we'll
> >   need it in the future.
> > 
> > Changes from v0:
> > - Add quirk for IMQ8MQ silicon B0 revision to not mess with the
> >   system reset controller on power down since enable() won't work
> >   otherwise.
> > - Drop devm_free_irq() handled by the device driver core
> > - Disable tx esc clock after the phy power down to unbreak
> >   disable/enable (unblank/blank)
> > - Add ports to dt binding docs
> > - Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
> >   phy_mipi_dphy_get_default_config
> > - Select DRM_MIPI_DSI
> > - Include drm_print.h to fix build on next-20190408
> > - Drop some debugging messages
> > - Newline terminate all DRM_ printouts
> > - Turn component driver into a drm bridge
> > 
> > [0]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > May%2F219484.html&amp;data=02%7C01%7Crobert.chiras%40nxp.com%7C757201
> > f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> > %7C637020674654566414&amp;sdata=4IVjhLy3a2XxZ4jYwDFD23D%2BvwAVAEj44hY
> > fvvp8OpQ%3D&amp;reserved=0
> > [1]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Fpatchwork.freedesktop.org%2Fseries%2F62822%2F&amp;data=02%7C01%7Cro
> > bert.chiras%40nxp.com%7C757201f9aaa54653580e08d726edb290%7C686ea1d3bc
> > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637020674654566414&amp;sdata=GueUBOc
> > baGjWtWcMYBplL6ki2UbgaFPkQHg%2F6eReiYg%3D&amp;reserved=0
> > 
> > To: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
> > Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>
> > , Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.
> > de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <
> > festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Andrzej
> > Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>
> > , Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman
> > <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@siol.net>, Lee
> > Jones <lee.jones@linaro.org>, Guido Günther <agx@sigxcpu.org>, dri-de
> > vel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kern
> > el@lists.infradead.org, linux-kernel@vger.kernel.org, Robert Chiras <
> > robert.chiras@nxp.com>, Sam Ravnborg <sam@ravnborg.org>, Fabio
> > Estevam <festevam@gmail.com>, Arnd Bergmann <arnd@arndb.de>
> > 
> > 
> > Guido Günther (2):
> >   dt-bindings: display/bridge: Add binding for NWL mipi dsi host
> >     controller
> >   drm/bridge: Add NWL MIPI DSI host controller support
> > 
> >  .../bindings/display/bridge/nwl-dsi.yaml      | 155 ++++
> >  drivers/gpu/drm/bridge/Kconfig                |   2 +
> >  drivers/gpu/drm/bridge/Makefile               |   1 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Kconfig        |  16 +
> >  drivers/gpu/drm/bridge/nwl-dsi/Makefile       |   4 +
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c      | 501 +++++++++++++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h      |  65 ++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c      | 700
> > ++++++++++++++++++
> >  drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h      | 112 +++
> >  9 files changed, 1556 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> >  create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> > 
> > --
> > 2.20.1
> > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox