Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3] ARM: imx: mach-imx6ul: add imx6ull support
From: Peter Chen @ 2016-11-01  3:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477969343-19887-1-git-send-email-peter.chen@nxp.com>

imx6ull is derived SoC from imx6ul.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 arch/arm/mach-imx/mach-imx6ul.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
index 58a2b88..0b24630 100644
--- a/arch/arm/mach-imx/mach-imx6ul.c
+++ b/arch/arm/mach-imx/mach-imx6ul.c
@@ -89,10 +89,11 @@ static void __init imx6ul_init_late(void)
 
 static const char * const imx6ul_dt_compat[] __initconst = {
 	"fsl,imx6ul",
+	"fsl,imx6ull",
 	NULL,
 };
 
-DT_MACHINE_START(IMX6UL, "Freescale i.MX6 Ultralite (Device Tree)")
+DT_MACHINE_START(IMX6UL, "Freescale i.MX6 UltraLite (Device Tree)")
 	.init_irq	= imx6ul_init_irq,
 	.init_machine	= imx6ul_init_machine,
 	.init_late	= imx6ul_init_late,
-- 
2.7.4

^ permalink raw reply related

* [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Peter Chen @ 2016-11-01  3:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477969343-19887-1-git-send-email-peter.chen@nxp.com>

From: Bai Ping <ping.bai@nxp.com>

imx6ull is the derived SoC from imx6ul

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
 drivers/clk/imx/clk-imx6ul.c             | 74 +++++++++++++++++++++++++++-----
 include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
 2 files changed, 77 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index d1d7787..ceb99a7 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -64,6 +64,11 @@ static const char *perclk_sels[] = { "ipg", "osc", };
 static const char *lcdif_sels[] = { "lcdif_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
 static const char *csi_sels[] = { "osc", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
 static const char *sim_sels[] = { "sim_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
+/* epdc_pre_sels, epdc_sels, esai_sels only exists on i.MX6ULL */
+static const char *epdc_pre_sels[] = { "pll2_bus", "pll3_usb_otg", "pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd2_508m", };
+static const char *esai_sels[] = { "pll4_audio_div", "pll3_pfd2_508m", "pll5_video_div", "pll3_usb_otg", };
+static const char *epdc_sels[] = { "epdc_podf", "ipp_di0", "ipp_di1", "ldb_di0", "ldb_di1", };
+
 
 static struct clk *clks[IMX6UL_CLK_END];
 static struct clk_onecell_data clk_data;
@@ -102,6 +107,17 @@ static u32 share_count_audio;
 static u32 share_count_sai1;
 static u32 share_count_sai2;
 static u32 share_count_sai3;
+static u32 share_count_esai;
+
+static inline int clk_on_imx6ul(void)
+{
+	return of_machine_is_compatible("fsl,imx6ul");
+}
+
+static inline int clk_on_imx6ull(void)
+{
+	return of_machine_is_compatible("fsl,imx6ull");
+}
 
 static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 {
@@ -238,12 +254,19 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_QSPI1_SEL]	  = imx_clk_mux("qspi1_sel",    base + 0x1c, 7,  3, qspi1_sels, ARRAY_SIZE(qspi1_sels));
 	clks[IMX6UL_CLK_PERCLK_SEL]	  = imx_clk_mux("perclk_sel",	base + 0x1c, 6,  1, perclk_sels, ARRAY_SIZE(perclk_sels));
 	clks[IMX6UL_CLK_CAN_SEL]	  = imx_clk_mux("can_sel",	base + 0x20, 8,  2, can_sels, ARRAY_SIZE(can_sels));
+	if (clk_on_imx6ull())
+		clks[IMX6UL_CLK_ESAI_SEL]	  = imx_clk_mux("esai_sel",	base + 0x20, 19, 2, esai_sels, ARRAY_SIZE(esai_sels));
 	clks[IMX6UL_CLK_UART_SEL]	  = imx_clk_mux("uart_sel",	base + 0x24, 6,  1, uart_sels, ARRAY_SIZE(uart_sels));
 	clks[IMX6UL_CLK_ENFC_SEL]	  = imx_clk_mux("enfc_sel",	base + 0x2c, 15, 3, enfc_sels, ARRAY_SIZE(enfc_sels));
 	clks[IMX6UL_CLK_LDB_DI0_SEL]	  = imx_clk_mux("ldb_di0_sel",	base + 0x2c, 9,  3, ldb_di0_sels, ARRAY_SIZE(ldb_di0_sels));
 	clks[IMX6UL_CLK_SPDIF_SEL]	  = imx_clk_mux("spdif_sel",	base + 0x30, 20, 2, spdif_sels, ARRAY_SIZE(spdif_sels));
-	clks[IMX6UL_CLK_SIM_PRE_SEL]	  = imx_clk_mux("sim_pre_sel",	base + 0x34, 15, 3, sim_pre_sels, ARRAY_SIZE(sim_pre_sels));
-	clks[IMX6UL_CLK_SIM_SEL]	  = imx_clk_mux("sim_sel",	base + 0x34, 9, 3, sim_sels, ARRAY_SIZE(sim_sels));
+	if (clk_on_imx6ul()) {
+		clks[IMX6UL_CLK_SIM_PRE_SEL] 	  = imx_clk_mux("sim_pre_sel",	base + 0x34, 15, 3, sim_pre_sels, ARRAY_SIZE(sim_pre_sels));
+		clks[IMX6UL_CLK_SIM_SEL]	  = imx_clk_mux("sim_sel", 	base + 0x34, 9, 3, sim_sels, ARRAY_SIZE(sim_sels));
+	} else if (clk_on_imx6ull()) {
+		clks[IMX6UL_CLK_EPDC_PRE_SEL]	  = imx_clk_mux("epdc_pre_sel",	base + 0x34, 15, 3, epdc_pre_sels, ARRAY_SIZE(epdc_pre_sels));
+		clks[IMX6UL_CLK_EPDC_SEL]	  = imx_clk_mux("epdc_sel",	base + 0x34, 9, 3, epdc_sels, ARRAY_SIZE(epdc_sels));
+	}
 	clks[IMX6UL_CLK_ECSPI_SEL]	  = imx_clk_mux("ecspi_sel",	base + 0x38, 18, 1, ecspi_sels, ARRAY_SIZE(ecspi_sels));
 	clks[IMX6UL_CLK_LCDIF_PRE_SEL]	  = imx_clk_mux("lcdif_pre_sel", base + 0x38, 15, 3, lcdif_pre_sels, ARRAY_SIZE(lcdif_pre_sels));
 	clks[IMX6UL_CLK_LCDIF_SEL]	  = imx_clk_mux("lcdif_sel",	base + 0x38, 9, 3, lcdif_sels, ARRAY_SIZE(lcdif_sels));
@@ -276,6 +299,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_SAI3_PODF]	= imx_clk_divider("sai3_podf",	   "sai3_pred",		base + 0x28, 16, 6);
 	clks[IMX6UL_CLK_SAI1_PRED]	= imx_clk_divider("sai1_pred",	   "sai1_sel",		base + 0x28, 6,	 3);
 	clks[IMX6UL_CLK_SAI1_PODF]	= imx_clk_divider("sai1_podf",	   "sai1_pred",		base + 0x28, 0,	 6);
+	if (clk_on_imx6ull()) {
+		clks[IMX6UL_CLK_ESAI_PRED]	= imx_clk_divider("esai_pred",     "esai_sel",		base + 0x28, 9,  3);
+		clks[IMX6UL_CLK_ESAI_PODF]	= imx_clk_divider("esai_podf",     "esai_pred",		base + 0x28, 25, 3);
+	}
 	clks[IMX6UL_CLK_ENFC_PRED]	= imx_clk_divider("enfc_pred",	   "enfc_sel",		base + 0x2c, 18, 3);
 	clks[IMX6UL_CLK_ENFC_PODF]	= imx_clk_divider("enfc_podf",	   "enfc_pred",		base + 0x2c, 21, 6);
 	clks[IMX6UL_CLK_SAI2_PRED]	= imx_clk_divider("sai2_pred",	   "sai2_sel",		base + 0x2c, 6,	 3);
@@ -298,9 +325,15 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_APBHDMA]	= imx_clk_gate2("apbh_dma",	"bch_podf",	base + 0x68,	4);
 	clks[IMX6UL_CLK_ASRC_IPG]	= imx_clk_gate2_shared("asrc_ipg",	"ahb",	base + 0x68,	6, &share_count_asrc);
 	clks[IMX6UL_CLK_ASRC_MEM]	= imx_clk_gate2_shared("asrc_mem",	"ahb",	base + 0x68,	6, &share_count_asrc);
-	clks[IMX6UL_CLK_CAAM_MEM]	= imx_clk_gate2("caam_mem",	"ahb",		base + 0x68,	8);
-	clks[IMX6UL_CLK_CAAM_ACLK]	= imx_clk_gate2("caam_aclk",	"ahb",		base + 0x68,	10);
-	clks[IMX6UL_CLK_CAAM_IPG]	= imx_clk_gate2("caam_ipg",	"ipg",		base + 0x68,	12);
+	if (clk_on_imx6ul()) {
+		clks[IMX6UL_CLK_CAAM_MEM]	= imx_clk_gate2("caam_mem",	"ahb",		base + 0x68,	8);
+		clks[IMX6UL_CLK_CAAM_ACLK]	= imx_clk_gate2("caam_aclk",	"ahb",		base + 0x68,	10);
+		clks[IMX6UL_CLK_CAAM_IPG]	= imx_clk_gate2("caam_ipg",	"ipg",		base + 0x68,	12);
+	} else if (clk_on_imx6ull()) {
+		clks[IMX6UL_CLK_DCP_CLK]	= imx_clk_gate2("dcp",		"ahb",		base + 0x68,	10);
+		clks[IMX6UL_CLK_ENET]		= imx_clk_gate2("enet",		"ipg",		base + 0x68,	12);
+		clks[IMX6UL_CLK_ENET_AHB]	= imx_clk_gate2("enet_ahb",	"ahb",		base + 0x68,	12);
+	}
 	clks[IMX6UL_CLK_CAN1_IPG]	= imx_clk_gate2("can1_ipg",	"ipg",		base + 0x68,	14);
 	clks[IMX6UL_CLK_CAN1_SERIAL]	= imx_clk_gate2("can1_serial",	"can_podf",	base + 0x68,	16);
 	clks[IMX6UL_CLK_CAN2_IPG]	= imx_clk_gate2("can2_ipg",	"ipg",		base + 0x68,	18);
@@ -309,7 +342,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_GPT2_SERIAL]	= imx_clk_gate2("gpt2_serial",	"perclk",	base + 0x68,	26);
 	clks[IMX6UL_CLK_UART2_IPG]	= imx_clk_gate2("uart2_ipg",	"ipg",		base + 0x68,	28);
 	clks[IMX6UL_CLK_UART2_SERIAL]	= imx_clk_gate2("uart2_serial",	"uart_podf",	base + 0x68,	28);
-	clks[IMX6UL_CLK_AIPSTZ3]	= imx_clk_gate2("aips_tz3",	"ahb",		base + 0x68,	30);
+	if (clk_on_imx6ul())
+		clks[IMX6UL_CLK_AIPSTZ3]	= imx_clk_gate2("aips_tz3",	"ahb",		base + 0x68,	30);
+	else if (clk_on_imx6ull())
+		clks[IMX6UL_CLK_AIPSTZ3]	= imx_clk_gate2("aips_tz3",	"ahb",		 base + 0x80,	18);
 
 	/* CCGR1 */
 	clks[IMX6UL_CLK_ECSPI1]		= imx_clk_gate2("ecspi1",	"ecspi_podf",	base + 0x6c,	0);
@@ -328,6 +364,11 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_UART4_SERIAL]	= imx_clk_gate2("uart4_serail",	"uart_podf",	base + 0x6c,	24);
 
 	/* CCGR2 */
+	if (clk_on_imx6ull()) {
+		clks[IMX6UL_CLK_ESAI_EXTAL]	= imx_clk_gate2_shared("esai_extal",	"esai_podf",	base + 0x70,	0, &share_count_esai);
+		clks[IMX6UL_CLK_ESAI_IPG]	= imx_clk_gate2_shared("esai_ipg",	"ahb",		base + 0x70,	0, &share_count_esai);
+		clks[IMX6UL_CLK_ESAI_MEM]	= imx_clk_gate2_shared("esai_mem",	"ahb",		base + 0x70,	0, &share_count_esai);
+	}
 	clks[IMX6UL_CLK_CSI]		= imx_clk_gate2("csi",		"csi_podf",		base + 0x70,	2);
 	clks[IMX6UL_CLK_I2C1]		= imx_clk_gate2("i2c1",		"perclk",	base + 0x70,	6);
 	clks[IMX6UL_CLK_I2C2]		= imx_clk_gate2("i2c2",		"perclk",	base + 0x70,	8);
@@ -340,8 +381,13 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	/* CCGR3 */
 	clks[IMX6UL_CLK_UART5_IPG]	= imx_clk_gate2("uart5_ipg",	"ipg",		base + 0x74,	2);
 	clks[IMX6UL_CLK_UART5_SERIAL]	= imx_clk_gate2("uart5_serial",	"uart_podf",	base + 0x74,	2);
-	clks[IMX6UL_CLK_ENET]		= imx_clk_gate2("enet",		"ipg",		base + 0x74,	4);
-	clks[IMX6UL_CLK_ENET_AHB]	= imx_clk_gate2("enet_ahb",	"ahb",		base + 0x74,	4);
+	if (clk_on_imx6ul()) {
+		clks[IMX6UL_CLK_ENET]		= imx_clk_gate2("enet",		"ipg",		base + 0x74,	4);
+		clks[IMX6UL_CLK_ENET_AHB]	= imx_clk_gate2("enet_ahb",	"ahb",		base + 0x74,	4);
+	} else if (clk_on_imx6ull()) {
+		clks[IMX6UL_CLK_EPDC_ACLK]	= imx_clk_gate2("epdc_aclk",	"axi",		base + 0x74,	4);
+		clks[IMX6UL_CLK_EPDC_PIX]	= imx_clk_gate2("epdc_pix",	"epdc_podf",	base + 0x74,	4);
+	}
 	clks[IMX6UL_CLK_UART6_IPG]	= imx_clk_gate2("uart6_ipg",	"ipg",		base + 0x74,	6);
 	clks[IMX6UL_CLK_UART6_SERIAL]	= imx_clk_gate2("uart6_serial",	"uart_podf",	base + 0x74,	6);
 	clks[IMX6UL_CLK_LCDIF_PIX]	= imx_clk_gate2("lcdif_pix",	"lcdif_podf",	base + 0x74,	10);
@@ -385,8 +431,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_USBOH3]		= imx_clk_gate2("usboh3",	"ipg",		 base + 0x80,	0);
 	clks[IMX6UL_CLK_USDHC1]		= imx_clk_gate2("usdhc1",	"usdhc1_podf",	 base + 0x80,	2);
 	clks[IMX6UL_CLK_USDHC2]		= imx_clk_gate2("usdhc2",	"usdhc2_podf",	 base + 0x80,	4);
-	clks[IMX6UL_CLK_SIM1]		= imx_clk_gate2("sim1",		"sim_sel",	 base + 0x80,	6);
-	clks[IMX6UL_CLK_SIM2]		= imx_clk_gate2("sim2",		"sim_sel",	 base + 0x80,	8);
+	if (clk_on_imx6ul()) {
+		clks[IMX6UL_CLK_SIM1]		= imx_clk_gate2("sim1",		"sim_sel",	 base + 0x80,	6);
+		clks[IMX6UL_CLK_SIM2]		= imx_clk_gate2("sim2",		"sim_sel",	 base + 0x80,	8);
+	}
 	clks[IMX6UL_CLK_EIM]		= imx_clk_gate2("eim",		"eim_slow_podf", base + 0x80,	10);
 	clks[IMX6UL_CLK_PWM8]		= imx_clk_gate2("pwm8",		"perclk",	 base + 0x80,	16);
 	clks[IMX6UL_CLK_UART8_IPG]	= imx_clk_gate2("uart8_ipg",	"ipg",		 base + 0x80,	14);
@@ -430,6 +478,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clk_set_rate(clks[IMX6UL_CLK_ENET_REF], 50000000);
 	clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 50000000);
 	clk_set_rate(clks[IMX6UL_CLK_CSI], 24000000);
+	clk_set_rate(clks[IMX6UL_CLK_PLL3_PFD2], 320000000);
 
 	/* keep all the clks on just for bringup */
 	for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
@@ -441,7 +490,10 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	}
 
 	clk_set_parent(clks[IMX6UL_CLK_CAN_SEL], clks[IMX6UL_CLK_PLL3_60M]);
-	clk_set_parent(clks[IMX6UL_CLK_SIM_PRE_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);
+	if (clk_on_imx6ul())
+		clk_set_parent(clks[IMX6UL_CLK_SIM_PRE_SEL], clks[IMX6UL_CLK_PLL3_USB_OTG]);
+	else if (clk_on_imx6ull())
+		clk_set_parent(clks[IMX6UL_CLK_EPDC_PRE_SEL], clks[IMX6UL_CLK_PLL3_PFD2]);
 
 	clk_set_parent(clks[IMX6UL_CLK_ENFC_SEL], clks[IMX6UL_CLK_PLL2_PFD2]);
 }
diff --git a/include/dt-bindings/clock/imx6ul-clock.h b/include/dt-bindings/clock/imx6ul-clock.h
index fd8aee8..563fd5b 100644
--- a/include/dt-bindings/clock/imx6ul-clock.h
+++ b/include/dt-bindings/clock/imx6ul-clock.h
@@ -236,6 +236,19 @@
 #define IMX6UL_CLK_PLL3_120M		223
 #define IMX6UL_CLK_KPP			224
 
-#define IMX6UL_CLK_END			225
+/* For i.MX6ULL */
+#define IMX6UL_CLK_ESAI_PRED		225
+#define IMX6UL_CLK_ESAI_PODF		226
+#define IMX6UL_CLK_ESAI_EXTAL		227
+#define IMX6UL_CLK_ESAI_MEM		228
+#define IMX6UL_CLK_ESAI_IPG		229
+#define IMX6UL_CLK_DCP_CLK		230
+#define IMX6UL_CLK_EPDC_PRE_SEL		231
+#define IMX6UL_CLK_EPDC_SEL		232
+#define IMX6UL_CLK_EPDC_PODF		233
+#define IMX6UL_CLK_EPDC_ACLK		234
+#define IMX6UL_CLK_EPDC_PIX		235
+#define IMX6UL_CLK_ESAI_SEL		236
+#define IMX6UL_CLK_END			237
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
-- 
2.7.4

^ permalink raw reply related

* [PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399
From: Xing Zheng @ 2016-11-01  3:22 UTC (permalink / raw)
  To: linux-arm-kernel

Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
the refdiv == 6, it will increase the lock time, and it is not an optimal
configuration.

Please let's fix them for the lock time and jitter are lower:
800 MHz:
- FVCO == 2.4 GHz, revdiv == 1.
1 GHz:
- FVCO == 3 GHz, revdiv == 1.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3399.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index a5a3f41..28aff45 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -77,7 +77,7 @@ static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
 	RK3036_PLL_RATE(1104000000, 1, 46, 1, 1, 1, 0),
 	RK3036_PLL_RATE(1100000000, 12, 550, 1, 1, 1, 0),
 	RK3036_PLL_RATE(1008000000, 1, 84, 2, 1, 1, 0),
-	RK3036_PLL_RATE(1000000000, 6, 500, 2, 1, 1, 0),
+	RK3036_PLL_RATE(1000000000, 1, 125, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 984000000, 1, 82, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 960000000, 1, 80, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 936000000, 1, 78, 2, 1, 1, 0),
@@ -87,7 +87,7 @@ static struct rockchip_pll_rate_table rk3399_pll_rates[] = {
 	RK3036_PLL_RATE( 864000000, 1, 72, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 840000000, 1, 70, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 816000000, 1, 68, 2, 1, 1, 0),
-	RK3036_PLL_RATE( 800000000, 6, 400, 2, 1, 1, 0),
+	RK3036_PLL_RATE( 800000000, 1, 100, 3, 1, 1, 0),
 	RK3036_PLL_RATE( 700000000, 6, 350, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 696000000, 1, 58, 2, 1, 1, 0),
 	RK3036_PLL_RATE( 676000000, 3, 169, 2, 1, 1, 0),
-- 
2.7.4

^ permalink raw reply related

* [PATCH 1/4] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Rafael J. Wysocki @ 2016-11-01  4:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477409199-52182-2-git-send-email-lina.iyer@linaro.org>

On Tuesday, October 25, 2016 08:26:36 AM Lina Iyer wrote:
> Update documentation to reflect the changes made to support IRQ safe PM
> domains.
> 
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>

This one is in my tree already.

Thanks,
Rafael

^ permalink raw reply

* S5PV210 boot problem
From: Nasser @ 2016-11-01  5:34 UTC (permalink / raw)
  To: linux-arm-kernel

Dear friends, I have problem booting my custom HW (around s5pv210 SoC) 
using the latest stable kernel release (v4.8.5). Of course this is the first DT
based kernel I'm trying to boot with in this HW. I chose s5pv210_defconfig and 
by checking CONFIG_ARM_APPENDED_DTB, appended the DTB (s5pv210-smdkv210.dtb) at the end of zImage.

The boot loader is based on the old u-boot v1.3.4.
Due to some problems with kernel decompression, I revert 
1fdc08abfa26f30fcef0ce1333e9ac6f80350f30 ARM: decompressor: avoid speculative prefetch from non-RAM areas 
for a successful boot on every new kernel and it worked till now (for non-DT
kernels)

Boot log messages is attached. There are some problems with clock
settings and obviously "Division by zero in kernel".
Can anybody shed some light on the possible issue(s)?

## Transferring control to Linux (at address 20008000) ...

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.8.5-00001-gbbbb0ab (smart at smart-ThinkPad-T410) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #5 PREEMPT Mon Oct 36
CPU: ARMv7 Processor [412fc082] revision 2 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: YIC System SMDKV210 based on S5PV210
debug: ignoring loglevel setting.
bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat 80517730, node_mem_map bf7f8000
  Normal zone: 2048 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 262144 pages, LIFO batch:31
CPU: All CPU(s) started in SVC mode.
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: console=ttySAC0,115200n8 root=/dev/mmcblk0p1 rw rootwait ignore_loglevel earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034972K/1048576K available (2048K kernel code, 95K rwdata, 700K rodata, 1024K init, 208K bss, 13604K reserved, 0K cma-reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xc0800000 - 0xff800000   (1008 MB)
    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
    modules : 0x7f000000 - 0x80000000   (  16 MB)
      .text : 0x80008000 - 0x80300000   (3040 kB)
      .init : 0x80400000 - 0x80500000   (1024 kB)
      .data : 0x80500000 - 0x80517e40   (  96 kB)
       .bss : 0x80517e40 - 0x8054bfec   ( 209 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 32.
NR_IRQS:16 nr_irqs:16 16
VIC @c0800000: id 0x00041192, vendor 0x41
VIC @c0802000: id 0x00041192, vendor 0x41
VIC @c0804000: id 0x00041192, vendor 0x41
VIC @c0806000: id 0x00041192, vendor 0x41
S5PV210 clocks: mout_apll = 0, mout_mpll = 0
        mout_epll = 0, mout_vpll = 0
Division by zero in kernel.
CPU: 0 PID: 0 Comm: swapper Not tainted 4.8.5-00001-gbbbb0ab #5
Hardware name: Samsung S5PC110/S5PV210-based board
[<8010c1ac>] (unwind_backtrace) from [<8010a084>] (show_stack+0x10/0x14)
[<8010a084>] (show_stack) from [<8024a07c>] (Ldiv0+0x8/0x14)
[<8024a07c>] (Ldiv0) from [<8015c6f0>] (clockevents_config+0x24/0x7c)
[<8015c6f0>] (clockevents_config) from [<8015c75c>] (clockevents_config_and_register+0x14/0x20)
[<8015c75c>] (clockevents_config_and_register) from [<80416d6c>] (_samsung_pwm_clocksource_init+0x124/0x264)
[<80416d6c>] (_samsung_pwm_clocksource_init) from [<80416fc4>] (samsung_pwm_alloc+0x118/0x13c)
[<80416fc4>] (samsung_pwm_alloc) from [<80416be0>] (clocksource_probe+0x44/0xac)
[<80416be0>] (clocksource_probe) from [<80400af0>] (start_kernel+0x224/0x388)
[<80400af0>] (start_kernel) from [<20008078>] (0x20008078)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:44 cev_delta2ns+0x130/0x14c
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.8.5-00001-gbbbb0ab #5
Hardware name: Samsung S5PC110/S5PV210-based board
[<8010c1ac>] (unwind_backtrace) from [<8010a084>] (show_stack+0x10/0x14)
[<8010a084>] (show_stack) from [<801158f4>] (__warn+0xd4/0xfc)
[<801158f4>] (__warn) from [<8011593c>] (warn_slowpath_null+0x20/0x28)
[<8011593c>] (warn_slowpath_null) from [<8015bfec>] (cev_delta2ns+0x130/0x14c)
[<8015bfec>] (cev_delta2ns) from [<8015c728>] (clockevents_config+0x5c/0x7c)
[<8015c728>] (clockevents_config) from [<8015c75c>] (clockevents_config_and_register+0x14/0x20)
[<8015c75c>] (clockevents_config_and_register) from [<80416d6c>] (_samsung_pwm_clocksource_init+0x124/0x264)
[<80416d6c>] (_samsung_pwm_clocksource_init) from [<80416fc4>] (samsung_pwm_alloc+0x118/0x13c)
[<80416fc4>] (samsung_pwm_alloc) from [<80416be0>] (clocksource_probe+0x44/0xac)
[<80416be0>] (clocksource_probe) from [<80400af0>] (start_kernel+0x224/0x388)
[<80400af0>] (start_kernel) from [<20008078>] (0x20008078)
---[ end trace 0000000000000000 ]---
Division by zero in kernel.
CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.8.5-00001-gbbbb0ab #5
Hardware name: Samsung S5PC110/S5PV210-based board
[<8010c1ac>] (unwind_backtrace) from [<8010a084>] (show_stack+0x10/0x14)
[<8010a084>] (show_stack) from [<80249588>] (Ldiv0_64+0x8/0x18)
[<80249588>] (Ldiv0_64) from [<80159bac>] (clocks_calc_mult_shift+0x11c/0x124)
[<80159bac>] (clocks_calc_mult_shift) from [<8040abe8>] (sched_clock_register+0x5c/0x1fc)
[<8040abe8>] (sched_clock_register) from [<80416e40>] (_samsung_pwm_clocksource_init+0x1f8/0x264)
[<80416e40>] (_samsung_pwm_clocksource_init) from [<80416fc4>] (samsung_pwm_alloc+0x118/0x13c)
[<80416fc4>] (samsung_pwm_alloc) from [<80416be0>] (clocksource_probe+0x44/0xac)
[<80416be0>] (clocksource_probe) from [<80400af0>] (start_kernel+0x224/0x388)
[<80400af0>] (start_kernel) from [<20008078>] (0x20008078)
Division by zero in kernel.
CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.8.5-00001-gbbbb0ab #5
Hardware name: Samsung S5PC110/S5PV210-based board
[<8010c1ac>] (unwind_backtrace) from [<8010a084>] (show_stack+0x10/0x14)
[<8010a084>] (show_stack) from [<80249588>] (Ldiv0_64+0x8/0x18)
[<80249588>] (Ldiv0_64) from [<80159c68>] (clocks_calc_max_nsecs+0x24/0x78)
[<80159c68>] (clocks_calc_max_nsecs) from [<8040ac44>] (sched_clock_register+0xb8/0x1fc)
[<8040ac44>] (sched_clock_register) from [<80416e40>] (_samsung_pwm_clocksource_init+0x1f8/0x264)
[<80416e40>] (_samsung_pwm_clocksource_init) from [<80416fc4>] (samsung_pwm_alloc+0x118/0x13c)
[<80416fc4>] (samsung_pwm_alloc) from [<80416be0>] (clocksource_probe+0x44/0xac)
[<80416be0>] (clocksource_probe) from [<80400af0>] (start_kernel+0x224/0x388)
[<80400af0>] (start_kernel) from [<20008078>] (0x20008078)
sched_clock: 32 bits at 0 Hz, resolution 0ns, wraps every 0ns
Division by zero in kernel.
CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.8.5-00001-gbbbb0ab #5
Hardware name: Samsung S5PC110/S5PV210-based board
[<8010c1ac>] (unwind_backtrace) from [<8010a084>] (show_stack+0x10/0x14)
[<8010a084>] (show_stack) from [<80249588>] (Ldiv0_64+0x8/0x18)
[<80249588>] (Ldiv0_64) from [<80159c68>] (clocks_calc_max_nsecs+0x24/0x78)
[<80159c68>] (clocks_calc_max_nsecs) from [<80159e58>] (__clocksource_update_freq_scale+0x19c/0x2b8)
[<80159e58>] (__clocksource_update_freq_scale) from [<80159f80>] (__clocksource_register_scale+0xc/0x48)
[<80159f80>] (__clocksource_register_scale) from [<80416fc4>] (samsung_pwm_alloc+0x118/0x13c)
[<80416fc4>] (samsung_pwm_alloc) from [<80416be0>] (clocksource_probe+0x44/0xac)
[<80416be0>] (clocksource_probe) from [<80400af0>] (start_kernel+0x224/0x388)
[<80400af0>] (start_kernel) from [<20008078>] (0x20008078)
clocksource: samsung_clocksource_timer: mask: 0xffffffff max_cycles: 0x0, max_idle_ns: 0 ns
Console: colour dummy device 80x30
Calibrating delay loop...

----- End forwarded message -----

^ permalink raw reply

* [PATCH] ASoC: sun4i-codec: Enable bus clock after getting GPIO
From: Chen-Yu Tsai @ 2016-11-01  6:31 UTC (permalink / raw)
  To: linux-arm-kernel

In the current probe function the GPIO is acquired after the codec's
bus clock is enabled. However if it fails to acquire the GPIO due to
a deferred probe, it does not disable the bus clock before bailing out.
This would result in the clock being enabled multiple times.

Move the code that enables the bus clock after the part that gets the
GPIO, maintaining a separation between resource acquisition and device
enablement in the probe function.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 sound/soc/sunxi/sun4i-codec.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a60707761abf..56ed9472e89f 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -829,12 +829,6 @@ static int sun4i_codec_probe(struct platform_device *pdev)
 		return PTR_ERR(scodec->clk_module);
 	}
 
-	/* Enable the bus clock */
-	if (clk_prepare_enable(scodec->clk_apb)) {
-		dev_err(&pdev->dev, "Failed to enable the APB clock\n");
-		return -EINVAL;
-	}
-
 	scodec->gpio_pa = devm_gpiod_get_optional(&pdev->dev, "allwinner,pa",
 						  GPIOD_OUT_LOW);
 	if (IS_ERR(scodec->gpio_pa)) {
@@ -844,6 +838,12 @@ static int sun4i_codec_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	/* Enable the bus clock */
+	if (clk_prepare_enable(scodec->clk_apb)) {
+		dev_err(&pdev->dev, "Failed to enable the APB clock\n");
+		return -EINVAL;
+	}
+
 	/* DMA configuration for TX FIFO */
 	scodec->playback_dma_data.addr = res->start + SUN4I_CODEC_DAC_TXDATA;
 	scodec->playback_dma_data.maxburst = 4;
-- 
2.10.1

^ permalink raw reply related

* [PATCH] fpga zynq: Check the bitstream for validity
From: Michal Simek @ 2016-11-01  6:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161031162327.GA28817@obsidianresearch.com>

Hi Jason,

On 31.10.2016 17:23, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 05:09:26PM -0700, Moritz Fischer wrote:
>> It's not a single command but rather a sequence of steps we take to
>> create an image that works (using write_cfgmem instead of write_binfile)
> 
> Ah, and it relies on newer Vivado features too.. Never had a use for
> write_cfgmem before, and wouldn't have thought it did this.
> 
> I always do these transform externally and we tack our own header onto
> the bitfile as well..
> 
>>> So, the question still remains, should the driver require the header
>>> be stripped (eg the sync word is the first 4 bytes), or should it
>>> search the first bit for an aligned sync word?
>>
>> So currently we don't require it to be stripped, changing it so it does
>> require stripping would break people's setups that already use the
>> current implementation.
> 
> Considering there is a way to produce an acceptable bitfile via
> write_cfgmem I think we should stick with that and allow the header to
> be present, otherwise all users need yet another tool.
> 
> I'll send another patch when I get back from the plumbers conference.
> 
>>> Either requirement is acceptable to the hardware. My patch does the
>>> former, I suspect you need the later?
>>
>> For my usecases I could deal with either way, looking at backwards
>> compat the latter one would be preferential I supose ...
> 
> Well, there are no in-kernel users, and no uapi, so it isn't such a
> big deal. I'm actually surprised this got merged without users ..

There were several things in this whole thread.

Regarding BIT and BIN format. This support is in vivado for a long time
and it is up2you what you want to support. We have removed that BIT
support and not doing any swap by saying only BIN format is supported.

If driver check header and if it is not valid you should just error out.
If header is fine driver can program it.

Regarding what you need to do in Vivado to get your bitstream right is
completely out of this thread and TBH I don't know it too.

Thanks,
Michal

^ permalink raw reply

* [PATCH] serial: sirf: Simplify a test
From: Christophe JAILLET @ 2016-11-01  7:03 UTC (permalink / raw)
  To: linux-arm-kernel

'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the test
can be simplified to be more consistent.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 drivers/tty/serial/sirfsoc_uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index b186c9c4f850..666ca3156961 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -609,7 +609,7 @@ static void sirfsoc_uart_start_next_rx_dma(struct uart_port *port)
 		sirfport->rx_dma_items.dma_addr, SIRFSOC_RX_DMA_BUF_SIZE,
 		SIRFSOC_RX_DMA_BUF_SIZE / 2,
 		DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
-	if (IS_ERR_OR_NULL(sirfport->rx_dma_items.desc)) {
+	if (!sirfport->rx_dma_items.desc) {
 		dev_err(port->dev, "DMA slave single fail\n");
 		return;
 	}
-- 
2.9.3

^ permalink raw reply related

* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Songjun Wu @ 2016-11-01  8:08 UTC (permalink / raw)
  To: linux-arm-kernel

Release the filehandle in 'isc_open' if it's not the only filehandle
opened for the associated video_device.

Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
---

 drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index 8e25d3f..5e08404 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -926,21 +926,21 @@ static int isc_open(struct file *file)
 	if (ret < 0)
 		goto unlock;
 
-	if (!v4l2_fh_is_singular_file(file))
-		goto unlock;
+	ret = !v4l2_fh_is_singular_file(file);
+	if (ret)
+		goto fh_rel;
 
 	ret = v4l2_subdev_call(sd, core, s_power, 1);
-	if (ret < 0 && ret != -ENOIOCTLCMD) {
-		v4l2_fh_release(file);
-		goto unlock;
-	}
+	if (ret < 0 && ret != -ENOIOCTLCMD)
+		goto fh_rel;
 
 	ret = isc_set_fmt(isc, &isc->fmt);
-	if (ret) {
+	if (ret)
 		v4l2_subdev_call(sd, core, s_power, 0);
-		v4l2_fh_release(file);
-	}
 
+fh_rel:
+	if (ret)
+		v4l2_fh_release(file);
 unlock:
 	mutex_unlock(&isc->lock);
 	return ret;
-- 
2.7.4

^ permalink raw reply related

* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Michael Zoran @ 2016-11-01  8:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1795308650.27171.9a53158f-312d-40ce-80ce-8bf792d8db34.open-xchange@email.1und1.de>

On Mon, 2016-10-31 at 21:34 +0100, Stefan Wahren wrote:
> I inspired by this issue [1] i build up a slightly modified setup
> with a
> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and
> 5 Prolific
> PL2303 USB to serial convertors. I modified the usb_test for dwc2
> [2], which
> only tries to open all ttyUSB devices one after the other.?
> 
> Unfortunately the complete system stuck after opening the first
> ttyUSB device (
> heartbeat LED stop blinking, no reaction to debug UART). The only way
> to
> reanimate the system is to powerdown the USB hub with the USB to
> serial
> convertors.
> 
> [1] - https://github.com/raspberrypi/linux/issues/1692
> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b27
> 9dbaa
> 
> pi at raspberrypi:~$ lsusb -t
> /:??Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> ????|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> ????????|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class,
> Driver=smsc95xx,
> 480M
> ????????|__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> ????????????|__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> ????????????|__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> ????????????????|__ Port 2: Dev 14, If 0, Class=Vendor Specific
> Class,
> Driver=pl2303, 12M
> ????????????????|__ Port 3: Dev 16, If 0, Class=Vendor Specific
> Class,
> Driver=pl2303, 12M
> ????????????|__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> ????????????|__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> 

Since I didn't see a response, I'll go ahead and add my two cents. 
Hopefully nobody minds me chiming in here.

I see these kinds of issues with USB on the RPI all the time. 
Typically, it's just the USB that breaks down not a hang in the CPU.

The issue is that I think the USB controller in the RPI chipset was
designed for the cellphone/set top box market.  In those markets, the
USB port is only used to connect to one device at a time.  For example,
with a cell phone you might connect it to a PC to transfer data.  On a
set top box, you might plug in a USB flash drive with video to play.

The RPI doesn't have a proper USB controller like you find in a PC. 
Instead it has a fixed number of hardware slots(I think the number is
between 5-7) that are used for pending transfers. Once the slots are
full, very little can be done.  And because USB 2.0 is based on
polling, the connected USB devices are constantly polled even if
nothing is happening.

The DWC_OTG driver works a bit better even though it's not perfect. 
That driver makes an attempt to schedule USB activity and send it to
the hardware a bit at a time just like a PC USB controller does. 
Unfortunatly, to get the precision required on some of the lower end
RPIs, it's necessary to use FIQ which is somewhat outside the Linux
driver model.

Although I don't completely agree that FIQ is necessary on the high end
RPIs with multiple cores.   In fact, I have a few local modifications
to the interrupt controller driver to round robin dispatch IRQs between
core to get more concurrency at the expense of more CPU cache misses. I
think this reduces the need for FIQ, but some other disagree...

  

^ permalink raw reply

* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Shawn Guo @ 2016-11-01  8:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>

On Mon, Sep 26, 2016 at 03:03:39AM +0300, Vladimir Zapolskiy wrote:
> Vladimir Zapolskiy (4):
>   ARM: dts: imx31: fix clock control module interrupts description
>   ARM: dts: imx31: move CCM device node to AIPS2 bus devices
>   clk: imx31: fix rewritten input argument of mx31_clocks_init()
>   ARM: clk: imx31: properly init clocks for machines with DT

Applied all, thanks.

^ permalink raw reply

* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Hans Verkuil @ 2016-11-01  8:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477987726-4257-1-git-send-email-songjun.wu@microchip.com>

On 01/11/16 09:08, Songjun Wu wrote:
> Release the filehandle in 'isc_open' if it's not the only filehandle
> opened for the associated video_device.

What's wrong with that? You should always be able to open the device
multiple times. v4l2-compliance will fail after this patch. I'm not sure
what you intended to do here, but this patch is wrong.

Regards,

	Hans

>
> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> ---
>
>  drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index 8e25d3f..5e08404 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -926,21 +926,21 @@ static int isc_open(struct file *file)
>  	if (ret < 0)
>  		goto unlock;
>
> -	if (!v4l2_fh_is_singular_file(file))
> -		goto unlock;
> +	ret = !v4l2_fh_is_singular_file(file);
> +	if (ret)
> +		goto fh_rel;
>
>  	ret = v4l2_subdev_call(sd, core, s_power, 1);
> -	if (ret < 0 && ret != -ENOIOCTLCMD) {
> -		v4l2_fh_release(file);
> -		goto unlock;
> -	}
> +	if (ret < 0 && ret != -ENOIOCTLCMD)
> +		goto fh_rel;
>
>  	ret = isc_set_fmt(isc, &isc->fmt);
> -	if (ret) {
> +	if (ret)
>  		v4l2_subdev_call(sd, core, s_power, 0);
> -		v4l2_fh_release(file);
> -	}
>
> +fh_rel:
> +	if (ret)
> +		v4l2_fh_release(file);
>  unlock:
>  	mutex_unlock(&isc->lock);
>  	return ret;
>

^ permalink raw reply

* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Wu, Songjun @ 2016-11-01  9:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <c90098d4-4d53-d2e1-2d3e-e38e7d548f45@xs4all.nl>

Sorry, my mistake, the device should be able to opened multiple times.
It's a wrong patch.

On 11/1/2016 16:52, Hans Verkuil wrote:
> On 01/11/16 09:08, Songjun Wu wrote:
>> Release the filehandle in 'isc_open' if it's not the only filehandle
>> opened for the associated video_device.
>
> What's wrong with that? You should always be able to open the device
> multiple times. v4l2-compliance will fail after this patch. I'm not sure
> what you intended to do here, but this patch is wrong.
>
> Regards,
>
>     Hans
>
>>
>> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
>> ---
>>
>>  drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/platform/atmel/atmel-isc.c
>> b/drivers/media/platform/atmel/atmel-isc.c
>> index 8e25d3f..5e08404 100644
>> --- a/drivers/media/platform/atmel/atmel-isc.c
>> +++ b/drivers/media/platform/atmel/atmel-isc.c
>> @@ -926,21 +926,21 @@ static int isc_open(struct file *file)
>>      if (ret < 0)
>>          goto unlock;
>>
>> -    if (!v4l2_fh_is_singular_file(file))
>> -        goto unlock;
>> +    ret = !v4l2_fh_is_singular_file(file);
>> +    if (ret)
>> +        goto fh_rel;
>>
>>      ret = v4l2_subdev_call(sd, core, s_power, 1);
>> -    if (ret < 0 && ret != -ENOIOCTLCMD) {
>> -        v4l2_fh_release(file);
>> -        goto unlock;
>> -    }
>> +    if (ret < 0 && ret != -ENOIOCTLCMD)
>> +        goto fh_rel;
>>
>>      ret = isc_set_fmt(isc, &isc->fmt);
>> -    if (ret) {
>> +    if (ret)
>>          v4l2_subdev_call(sd, core, s_power, 0);
>> -        v4l2_fh_release(file);
>> -    }
>>
>> +fh_rel:
>> +    if (ret)
>> +        v4l2_fh_release(file);
>>  unlock:
>>      mutex_unlock(&isc->lock);
>>      return ret;
>>

^ permalink raw reply

* [PATCH v2] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-11-01  9:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477650470-19104-1-git-send-email-marc.zyngier@arm.com>

On Fri, Oct 28, 2016 at 11:27:50AM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
> 
> Let's consider the following scenario:
> 
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
> 
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
> 
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
> 
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Fixed comments, added Mark's RB.
> 
>  arch/arm/include/asm/kvm_host.h   | 11 ++++++++++-
>  arch/arm/include/asm/kvm_hyp.h    |  1 +
>  arch/arm/kvm/arm.c                | 35 ++++++++++++++++++++++++++++++++++-
>  arch/arm/kvm/hyp/switch.c         |  9 +++++++++
>  arch/arm64/include/asm/kvm_host.h | 11 ++++++++++-
>  arch/arm64/kvm/hyp/switch.c       |  8 ++++++++
>  6 files changed, 72 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..7290de6 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,9 @@ struct kvm_arch {
>  	/* VTTBR value associated with below pgd and vmid */
>  	u64    vttbr;
>  
> +	/* The last vcpu id that ran on each physical CPU */
> +	int __percpu *last_vcpu_ran;
> +
>  	/* Timer */
>  	struct arch_timer_kvm	timer;
>  
> @@ -174,6 +177,13 @@ struct kvm_vcpu_arch {
>  	/* vcpu power-off state */
>  	bool power_off;
>  
> +	/*
> +	 * Local TLBs potentially contain conflicting entries from
> +	 * another vCPU within this VMID. All entries for this VMID must
> +	 * be invalidated from (local) TLBs before we run this vCPU.
> +	 */
> +	bool tlb_vmid_stale;
> +
>  	 /* Don't run the guest (internal implementation need) */
>  	bool pause;
>  
> @@ -292,7 +302,6 @@ struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
>  static inline void kvm_arch_hardware_unsetup(void) {}
>  static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>  static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
>  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>  
>  static inline void kvm_arm_init_debug(void) {}
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 343135e..5850890 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -71,6 +71,7 @@
>  #define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
>  #define ATS1CPR		__ACCESS_CP15(c7, 0, c8, 0)
>  #define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL		__ACCESS_CP15(c8, 0, c7, 0)
>  #define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
>  #define PRRR		__ACCESS_CP15(c10, 0, c2, 0)
>  #define NMRR		__ACCESS_CP15(c10, 0, c2, 1)
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 08bb84f..e0d93cd 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
>   */
>  int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  {
> -	int ret = 0;
> +	int ret, cpu;
>  
>  	if (type)
>  		return -EINVAL;
>  
> +	kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> +	if (!kvm->arch.last_vcpu_ran)
> +		return -ENOMEM;
> +
> +	for_each_possible_cpu(cpu)
> +		*per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
> +
>  	ret = kvm_alloc_stage2_pgd(kvm);
>  	if (ret)
>  		goto out_fail_alloc;
> @@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  out_free_stage2_pgd:
>  	kvm_free_stage2_pgd(kvm);
>  out_fail_alloc:
> +	free_percpu(kvm->arch.last_vcpu_ran);
> +	kvm->arch.last_vcpu_ran = NULL;
>  	return ret;
>  }
>  
> @@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>  {
>  	int i;
>  
> +	free_percpu(kvm->arch.last_vcpu_ran);
> +	kvm->arch.last_vcpu_ran = NULL;
> +
>  	for (i = 0; i < KVM_MAX_VCPUS; ++i) {
>  		if (kvm->vcpus[i]) {
>  			kvm_arch_vcpu_free(kvm->vcpus[i]);
> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>  	return 0;
>  }
>  
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{

why is calling this from here sufficient?

You only get a notification from preempt notifiers if you were preempted
while running (or rather while the vcpu was loaded).  I think this needs
to go in kvm_arch_vcpu_load, but be aware that the vcpu_load gets called
for other vcpu ioctls and doesn't necessarily imply that the vcpu will
actually run, which is also the case for the sched_in notification, btw.
The worst that will happen in that case is a bit of extra TLB
invalidation, so sticking with kvm_arch_vcpu_load is probably fine.

> +	int *last_ran;
> +
> +	last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> +	/*
> +	 * We might get preempted before the vCPU actually runs, but
> +	 * this is fine. Our TLBI stays pending until we actually make
> +	 * it to __activate_vm, so we won't miss a TLBI. If another
> +	 * vCPU gets scheduled, it will see our vcpu_id in last_ran,
> +	 * and pend a TLBI for itself.
> +	 */
> +	if (*last_ran != vcpu->vcpu_id) {
> +		if (*last_ran != -1)
> +			vcpu->arch.tlb_vmid_stale = true;
> +
> +		*last_ran = vcpu->vcpu_id;
> +	}
> +}
> +
>  void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>  {
>  	vcpu->cpu = cpu;
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 92678b7..a411762 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>  	write_sysreg(kvm->arch.vttbr, VTTBR);
> +	if (vcpu->arch.tlb_vmid_stale) {
> +		/* Force vttbr to be written */
> +		isb();
> +		/* Local invalidate only for this VMID */
> +		write_sysreg(0, TLBIALL);
> +		dsb(nsh);
> +		vcpu->arch.tlb_vmid_stale = false;
> +	}
> +

why not call this directly when you notice it via kvm_call_hyp as
opposed to adding another conditional in the critical path?

>  	write_sysreg(vcpu->arch.midr, VPIDR);
>  }
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bd94e67..0f62829 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -62,6 +62,9 @@ struct kvm_arch {
>  	/* VTTBR value associated with above pgd and vmid */
>  	u64    vttbr;
>  
> +	/* The last vcpu id that ran on each physical CPU */
> +	int __percpu *last_vcpu_ran;
> +
>  	/* The maximum number of vCPUs depends on the used GIC model */
>  	int max_vcpus;
>  
> @@ -252,6 +255,13 @@ struct kvm_vcpu_arch {
>  	/* vcpu power-off state */
>  	bool power_off;
>  
> +	/*
> +	 * Local TLBs potentially contain conflicting entries from
> +	 * another vCPU within this VMID. All entries for this VMID must
> +	 * be invalidated from (local) TLBs before we run this vCPU.
> +	 */
> +	bool tlb_vmid_stale;
> +
>  	/* Don't run the guest (internal implementation need) */
>  	bool pause;
>  
> @@ -368,7 +378,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
>  static inline void kvm_arch_hardware_unsetup(void) {}
>  static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>  static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
>  static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>  
>  void kvm_arm_init_debug(void);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 83037cd..99d0f33 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>  	write_sysreg(kvm->arch.vttbr, vttbr_el2);
> +	if (vcpu->arch.tlb_vmid_stale) {
> +		/* Force vttbr_el2 to be written */
> +		isb();
> +		/* Local invalidate only for this VMID */
> +		asm volatile("tlbi vmalle1" : : );
> +		dsb(nsh);
> +		vcpu->arch.tlb_vmid_stale = false;
> +	}
>  }
>  
>  static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> -- 
> 2.1.4
> 

Thanks,
-Christoffer

^ permalink raw reply

* [PATCH] ARM: dts: r8a7794: remove Z clock
From: Simon Horman @ 2016-11-01  9:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2289596.xFBEUD1OgK@wasted.cogentembedded.com>

On Sun, Oct 30, 2016 at 12:31:27AM +0300, Sergei Shtylyov wrote:
> R8A7794 doesn't have Cortex-A15 CPUs, thus there's no Z clock...
> 
> Fixes: 0dce5454d5c2 ("ARM: shmobile: Initial r8a7794 SoC device tree")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
> The patch is against the 'master' branch of Simon Horman's 'renesas.git' repo.

Thanks, I have queued this up.

^ permalink raw reply

* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Russell King - ARM Linux @ 2016-11-01  9:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <847975190.29034.38a9c7fa-bdf8-4732-ac8b-cf15c21e3ce8.open-xchange@email.1und1.de>

On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> [  366.696043] INFO: task ext4lazyinit:70 blocked for more than 120 seconds.
> [  366.703046]       Not tainted 4.9.0-rc1 #7
> [  366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> [  366.715161] ext4lazyinit    D c05aa6ac     0    70      2 0x00000000

This looks like a very different problem - I guess one for ext4 people.

> [  366.721713] [<c05aa6ac>] (__schedule) from [<c05aafb8>] (schedule+0x3c/0xbc)
> [  366.728972] [<c05aafb8>] (schedule) from [<c05aee38>]
> (schedule_timeout+0x23c/0x3d8)
> [  366.736917] [<c05aee38>] (schedule_timeout) from [<c05aa398>]
> (io_schedule_timeout+0xb8/0x13c)
> [  366.745721] [<c05aa398>] (io_schedule_timeout) from [<c05ab9d8>]
> (T.1434+0xac/0x12c)
> [  366.753671] [<c05ab9d8>] (T.1434) from [<c02c7668>]
> (submit_bio_wait+0x50/0x68)
> [  366.761078] [<c02c7668>] (submit_bio_wait) from [<c02d9a58>]
> (blkdev_issue_zeroout+0x174/0x1ec)
> [  366.769984] [<c02d9a58>] (blkdev_issue_zeroout) from [<c0196e4c>]
> (ext4_init_inode_table+0x1ac/0x3b0)
> [  366.779410] [<c0196e4c>] (ext4_init_inode_table) from [<c01ba770>]
> (ext4_lazyinit_thread+0x280/0x398)
> [  366.788803] [<c01ba770>] (ext4_lazyinit_thread) from [<c003bce4>]
> (kthread+0xc4/0xe0)
> [  366.796828] [<c003bce4>] (kthread) from [<c000a34c>]
> (ret_from_fork+0x14/0x28)
> [  366.804200]
> [  366.804200] Showing all locks held in the system:
> [  366.810465] 2 locks held by khungtaskd/10:
> [  366.814707]  #0: [  366.816500]  (
> rcu_read_lock[  366.819360] ){......}
> , at: [  366.822236] [<c0093a10>] watchdog+0xb4/0x61c
> [  366.826656]  #1: [  366.828450]  (
> tasklist_lock[  366.831312] ){.+.+..}
> , at: [  366.834320] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
> [  366.839701] 4 locks held by ext4lazyinit/70:
> [  366.844107]  #0: [  366.845897]  (
> &type->s_umount_key[  366.849280] #22
> ){++++++}[  366.851866] , at:
> [  366.854044] [<c01ba5c4>] ext4_lazyinit_thread+0xd4/0x398
> [  366.859400]  #1: [  366.861178]  (
> sb_writers[  366.863897] #3
> ){.+.+.+}[  366.866412] , at:
> [  366.868475] [<c01ba5dc>] ext4_lazyinit_thread+0xec/0x398
> [  366.873925]  #2: [  366.875716]  (
> jbd2_handle[  366.878405] ){++++..}
> , at: [  366.881292] [<c01f661c>] start_this_handle+0xec/0x404
> [  366.886492]  #3: [  366.888284]  (
> &meta_group_info[i]->alloc_sem[  366.892620] ){++++..}
> , at: [  366.895624] [<c0196d58>] ext4_init_inode_table+0xb8/0x3b0
> [  366.901093] 4 locks held by bash/385:
> [  366.904895]  #0: [  366.906686]  (
> sb_writers[  366.909288] #4
> ){.+.+.+}[  366.911787] , at:
> [  366.913972] [<c011f7d4>] vfs_write+0x194/0x1a4
> [  366.918456]  #1: [  366.920234]  (
> &of->mutex[  366.922824] ){+.+.+.}
> , at: [  366.925940] [<c019029c>] kernfs_fop_write+0xc0/0x1d0
> [  366.930942]  #2: [  366.932714]  (
> s_active[  366.935265] #43
> ){.+.+.+}[  366.937864] , at:
> [  366.939927] [<c01902a4>] kernfs_fop_write+0xc8/0x1d0
> [  366.945029]  #3: [  366.946818]  (
> pm_mutex[  366.949242] ){+.+.+.}
> , at: [  366.952111] [<c005b7e4>] pm_suspend+0x90/0x81c
> [  366.956697]
> [  366.958229] =============================================

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support
From: James Liao @ 2016-11-01  9:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161031180647.GR16026@codeaurora.org>

Hi Stephen,

On Mon, 2016-10-31 at 11:06 -0700, Stephen Boyd wrote:
> On 10/31, James Liao wrote:
> > On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > > On 10/21, Erin Lo wrote:
> > > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct mtk_composite *mcs,
> > > >  			clk_data->clks[mc->id] = clk;
> > > >  	}
> > > >  }
> > > > +
> > > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > > +			int num, void __iomem *base, spinlock_t *lock,
> > > > +				struct clk_onecell_data *clk_data)
> > > > +{
> > > > +	struct clk *clk;
> > > > +	int i;
> > > > +
> > > > +	for (i = 0; i <  num; i++) {
> > > > +		const struct mtk_clk_divider *mcd = &mcds[i];
> > > > +
> > > > +		if (clk_data && !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> > > 
> > > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
> > 
> > Why NULL is a valid clk?
> 
> Perhaps at some point we'll want to return a NULL pointer to
> clk_get() callers so that they can handle things like optional
> clocks easily without having any storage requirements. I don't
> know if we'll ever do that, but that's just a possibility.
> 
> > 
> > clk_data is designed for multiple initialization from different clock
> > types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> > clocks to avoid duplicated clock registration. Here I assume a clock
> > pointer with error code or NULL to be an invalid (not initialized)
> > clock.
> > 
> 
> Ok. Would it be possible to initialize the array with all error
> pointers? That would make things less error prone, but it

Yes. Current mtk_alloc_clk_data() implementation init all elements with
ERR_PTR(-ENOENT). 

> probably doesn't matter at all anyway because this is done during
> registration time. IS_ERR_OR_NULL makes me take a second look
> each time, because it's usually wrong.

I see. Although currently all Mediatek clk drivers use
mtk_alloc_clk_data() to allocate clk_data, I would like to keep the
flexibility to support zero-initialized clk_data such as a static
structure. So I prefer to treat a NULL pointer as an uninitialized
clock.


Best regards,

James

^ permalink raw reply

* [PATCH v2] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-11-01  9:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477944264-18637-1-git-send-email-david@lechnology.com>

On Tuesday 01 November 2016 01:34 AM, David Lechner wrote:
> This fixes pwm name matching for DA850 familiy devices. When using device
> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
> same name, which caused errors when trying to register the devices.
> 
> We cannot have multiple entries for the same clock in in da850_clks[], so
> we have added child clocks to the EHRPWM and ECAP LPSC clocks so that each
> PWM device will have its own clock for proper name matching.
> 
> Signed-off-by: David Lechner <david@lechnology.com>

This looks good to me. Thanks!

I have added it to my fixes branch for further testing before sending
upstream.

Thanks,
Sekhar

^ permalink raw reply

* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Russell King - ARM Linux @ 2016-11-01  9:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477943593.30971.3.camel@crowfest.net>

On Mon, Oct 31, 2016 at 12:53:13PM -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> > The comment is easy to change.
> > 
> > I don't have the log available ATM, but if I remember the DMA API's
> > bugcheck the first time that are used.??
> > 
> > I think this was a policy decision or something because the
> > information
> > should be available in the dma-ranges.
> > 
> > If it's important, I can setup a test again without the change and e-
> > mail the logs.
> > 
> > If you look at the DWC2 driver you will see that it also sets this
> > mask.
> 
> OK, I'm begging to understand this.  It appears the architecture
> specific paths are very different.
> 
> In arm the mask and coherent is set to DMA_BIT_MASK(32) in mm/dma-
> mapping.c the first time the dma APIs are used.

I'm not sure where you get that from, this is absolutely not the case.

>  On arm64, it appears
> this variable is uninitialized and will contain random crude.
> 
> Like I said, I don't know if this is a policy decision or if it just
> slipped through the cracks.
> 
> arch/arm/mm/dma-mapping.c(Note the call to get_coherent_dma_mask(dev))
> 
> static u64 get_coherent_dma_mask(struct device *dev)
> {
> 	u64 mask = (u64)DMA_BIT_MASK(32);
> 
> 	if (dev) {
> 		mask = dev->coherent_dma_mask;
> 
> 		/*
> 		?* Sanity check the DMA mask - it must be non-zero, and
> 		?* must be able to be satisfied by a DMA allocation.
> 		?*/
> 		if (mask == 0) {
> 			dev_warn(dev, "coherent DMA mask is unset\n");
> 			return 0;

If the mask is unset (iow, zero) this function returns zero.  There
is no "the first time" here anywhere - dev->coherent_dma_mask remains
at zero and doesn't change as a result of calling this path.

> 		}
> 
> 		if (!__dma_supported(dev, mask, true))
> 			return 0;
> 	}
> 
> 	return mask;
> }
> 
> static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t
> *handle,
> 			?gfp_t gfp, pgprot_t prot, bool is_coherent,
> 			?unsigned long attrs, const void *caller)
> {
> 	u64 mask = get_coherent_dma_mask(dev);
> 	struct page *page = NULL;
> 	void *addr;
> 	bool allowblock, cma;
> 	struct arm_dma_buffer *buf;
> 	struct arm_dma_alloc_args args = {
> 		.dev = dev,
> 		.size = PAGE_ALIGN(size),
> 		.gfp = gfp,
> 		.prot = prot,
> 		.caller = caller,
> 		.want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) ==
> 0),
> 		.coherent_flag = is_coherent ? COHERENT : NORMAL,
> 	};

which then causes:

        if (!mask)
                return NULL;

this function to return NULL, hence failing the request.  Rightfully
so, because we don't know what an acceptable allocation for the device
would be, as the device is effectively saying "I support 0 bits of DMA
address."

Now, firstly, the driver is required to call one of:

	dma_set_mask_and_coherent()
	dma_set_coherent_mask()

if it is to use coherent DMA - see Documentation/DMA-API-HOWTO.txt.
However, the bus code should already have setup a default mask in both
dev->dma_mask and the coherent DMA mask if DMA is possible, which
normally will be the 32-bit mask.

As explained in the document, if the device and driver supports 64-bit
addressing, and wants to make use of it, it must successfully negotiate
with the kernel before using it, which includes making calls to change
the DMA masks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Russell King - ARM Linux @ 2016-11-01  9:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <85443ee1-9981-c7e8-fe88-a3aac48c3e80@codeaurora.org>

On Mon, Oct 31, 2016 at 04:36:33PM -0600, Baicar, Tyler wrote:
> Hello Russell,
> 
> On 10/31/2016 4:02 AM, Russell King - ARM Linux wrote:
> >The subject line on this patch is misleading - it's not only ARM64
> >specific...
> Thank you for the feedback!
> 
> I only put ARM64 in the subject line because this patch only really adds
> guest SEA support for the ARM64 KVM code. The ARM code had to be edited
> since both the ARM and ARM64 KVM code use arch/arm/kvm/mmu.c. I can change
> the subject line to "arm/arm64: KVM: add guest SEA support" if you think
> that is better.

Yes please, I almost skipped over it while catching up because it didn't
say "arm", it was only that I'd happened to read the cover message that
I'd spotted arch/arm in the diffstat, and then had to go digging for the
changes to review.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH] ARM: shmobile: r8a7779/marzen: Add board part number to DT bindings
From: Simon Horman @ 2016-11-01  9:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477921384-1812-1-git-send-email-geert+renesas@glider.be>

On Mon, Oct 31, 2016 at 02:43:04PM +0100, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Thanks, I have queued this up.

^ permalink raw reply

* [RFC PATCH v2 3/5] ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
From: Sergei Shtylyov @ 2016-11-01  9:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477932987-27871-4-git-send-email-narmstrong@baylibre.com>

Hello.

On 10/31/2016 7:56 PM, Neil Armstrong wrote:

> Add Ethernet node with Internal PHY selection for the Amlogic GXL SoCs
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index d1bf381..71670c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -47,6 +47,24 @@
>
>  / {
>  	compatible = "amlogic,meson-gxl";
> +
> +

    No need for these empty lines.

> +};
> +
> +&ethmac {
> +	reg = <0x0 0xc9410000 0x0 0x10000
> +	       0x0 0xc8834540 0x0 0x4>;
> +
> +	clocks = <&clkc CLKID_ETH>,
> +		 <&clkc CLKID_FCLK_DIV2>,
> +		 <&clkc CLKID_MPLL2>;
> +	clock-names = "stmmaceth", "clkin0", "clkin1";
> +
> +	mdio0: mdio0 {

    Should be "mdio0: mdio {" in oprder to comply woth the DT spec.

> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "snps,dwmac-mdio";
> +	};
>  };
>
>  &aobus {
[...]

MBR, Sergei

^ permalink raw reply

* [PATCH] ARM: OMAP2+: avoid NULL pointer dereference
From: Nicolae Rosia @ 2016-11-01  9:49 UTC (permalink / raw)
  To: linux-arm-kernel

For OMAP4, volt_data is set in omap44xx_voltagedomains_init.
If the SoC is neither OMAP443X or OMAP446X, we end up with a
NULL in volt_data which causes a kernel oops.
This is the case when booting OMAP4470.

Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
 arch/arm/mach-omap2/voltage.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index cba8cad..cd15dbd 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -87,6 +87,12 @@ int voltdm_scale(struct voltagedomain *voltdm,
 		return -ENODATA;
 	}
 
+	if (!voltdm->volt_data) {
+		pr_err("%s: No voltage data defined for vdd_%s\n",
+			__func__, voltdm->name);
+		return -ENODATA;
+	}
+
 	/* Adjust voltage to the exact voltage from the OPP table */
 	for (i = 0; voltdm->volt_data[i].volt_nominal != 0; i++) {
 		if (voltdm->volt_data[i].volt_nominal >= target_volt) {
-- 
2.5.5

^ permalink raw reply related

* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: Sekhar Nori @ 2016-11-01  9:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477946841-16126-2-git-send-email-david@lechnology.com>

Hi David,

On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
> for the USB PHY that is part of this range of registers.
> 
> Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
> the the USB PHY driver.
> 
> Signed-off-by: David Lechner <david@lechnology.com>

For future, please do not combine device-tree addition and other C code into a 
single patch. I have applied this patch while splitting it into two as 
attached.

Thanks,
Sekhar

---8<---
From: David Lechner <david@lechnology.com>
Date: Mon, 31 Oct 2016 15:47:19 -0500
Subject: [PATCH] ARM: dts: da850: Add cfgchip syscon node

Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
for the USB PHY that is part of this range of registers.

Signed-off-by: David Lechner <david@lechnology.com>
[nsekhar at ti.com: drop OF_DEV_AUXDATA() addition]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
 arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4c836133a183..2534aab851e1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -209,6 +209,16 @@
 			};
 
 		};
+		cfgchip: chip-controller at 1417c {
+			compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+			reg = <0x1417c 0x14>;
+
+			usb_phy: usb-phy {
+				compatible = "ti,da830-usb-phy";
+				#phy-cells = <1>;
+				status = "disabled";
+			};
+		};
 		edma0: edma at 0 {
 			compatible = "ti,edma3-tpcc";
 			/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
-- 
2.9.0

---8<---
From: David Lechner <david@lechnology.com>
Date: Mon, 31 Oct 2016 15:47:19 -0500
Subject: [PATCH] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for USB phy

Add OF_DEV_AUXDATA() entry for USB phy. This is required for
so that clock lookup will work for the USB PHY driver.

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 0e45cbd57273..5e67618180a7 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
 	OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci", NULL),
 	OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
+	OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
 	{}
 };
 
-- 
2.9.0

^ permalink raw reply related

* [PATCH v8 2/3] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-11-01  9:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477946841-16126-3-git-send-email-david@lechnology.com>

On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
> 
> This also removes the #if IS_ENABLED(CONFIG_USB_MUSB_HDRC) around the musb
> declaration and renames the musb platform device so that we can reference
> it from the usb20 clock even if the musb device is not used.
> 
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>

Applied to v4.10/soc

Thanks,
Sekhar

^ 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