* [PATCH v7 2/2] clk: uniphier: add clock data for UniPhier SoCs
From: Masahiro Yamada @ 2016-09-16 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474011604-12577-1-git-send-email-yamada.masahiro@socionext.com>
Add clock data arrays for all UniPhier SoCs with a binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/clock/uniphier-clock.txt | 134 ++++++++++++++++++
drivers/clk/uniphier/Makefile | 3 +
drivers/clk/uniphier/clk-uniphier-core.c | 91 +++++++++++++
drivers/clk/uniphier/clk-uniphier-mio.c | 101 ++++++++++++++
drivers/clk/uniphier/clk-uniphier-peri.c | 57 ++++++++
drivers/clk/uniphier/clk-uniphier-sys.c | 151 +++++++++++++++++++++
drivers/clk/uniphier/clk-uniphier.h | 13 ++
7 files changed, 550 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/uniphier-clock.txt
create mode 100644 drivers/clk/uniphier/clk-uniphier-mio.c
create mode 100644 drivers/clk/uniphier/clk-uniphier-peri.c
create mode 100644 drivers/clk/uniphier/clk-uniphier-sys.c
diff --git a/Documentation/devicetree/bindings/clock/uniphier-clock.txt b/Documentation/devicetree/bindings/clock/uniphier-clock.txt
new file mode 100644
index 0000000..c7179d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/uniphier-clock.txt
@@ -0,0 +1,134 @@
+UniPhier clock controller
+
+
+System clock
+------------
+
+Required properties:
+- compatible: should be one of the following:
+ "socionext,uniphier-sld3-clock" - for sLD3 SoC.
+ "socionext,uniphier-ld4-clock" - for LD4 SoC.
+ "socionext,uniphier-pro4-clock" - for Pro4 SoC.
+ "socionext,uniphier-sld8-clock" - for sLD8 SoC.
+ "socionext,uniphier-pro5-clock" - for Pro5 SoC.
+ "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC.
+ "socionext,uniphier-ld11-clock" - for LD11 SoC.
+ "socionext,uniphier-ld20-clock" - for LD20 SoC.
+- #clock-cells: should be 1.
+
+Example:
+
+ sysctrl at 61840000 {
+ compatible = "socionext,uniphier-sysctrl",
+ "simple-mfd", "syscon";
+ reg = <0x61840000 0x4000>;
+
+ clock {
+ compatible = "socionext,uniphier-ld20-clock";
+ #clock-cells = <1>;
+ };
+
+ other nodes ...
+ };
+
+Provided clocks:
+
+ 8: ST DMAC
+12: GIO (Giga bit stream I/O)
+14: USB3 ch0 host
+15: USB3 ch1 host
+16: USB3 ch0 PHY0
+17: USB3 ch0 PHY1
+20: USB3 ch1 PHY0
+21: USB3 ch1 PHY1
+
+
+Media I/O (MIO) clock
+---------------------
+
+Required properties:
+- compatible: should be one of the following:
+ "socionext,uniphier-sld3-mio-clock" - for sLD3 SoC.
+ "socionext,uniphier-ld4-mio-clock" - for LD4 SoC.
+ "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC.
+ "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC.
+ "socionext,uniphier-pro5-mio-clock" - for Pro5 SoC.
+ "socionext,uniphier-pxs2-mio-clock" - for PXs2/LD6b SoC.
+ "socionext,uniphier-ld11-mio-clock" - for LD11 SoC.
+ "socionext,uniphier-ld20-mio-clock" - for LD20 SoC.
+- #clock-cells: should be 1.
+
+Example:
+
+ mioctrl at 59810000 {
+ compatible = "socionext,uniphier-mioctrl",
+ "simple-mfd", "syscon";
+ reg = <0x59810000 0x800>;
+
+ clock {
+ compatible = "socionext,uniphier-ld20-mio-clock";
+ #clock-cells = <1>;
+ };
+
+ other nodes ...
+ };
+
+Provided clocks:
+
+ 0: SD ch0 host
+ 1: eMMC host
+ 2: SD ch1 host
+ 7: MIO DMAC
+ 8: USB2 ch0 host
+ 9: USB2 ch1 host
+10: USB2 ch2 host
+11: USB2 ch3 host
+12: USB2 ch0 PHY
+13: USB2 ch1 PHY
+14: USB2 ch2 PHY
+15: USB2 ch3 PHY
+
+
+Peripheral clock
+----------------
+
+Required properties:
+- compatible: should be one of the following:
+ "socionext,uniphier-sld3-peri-clock" - for sLD3 SoC.
+ "socionext,uniphier-ld4-peri-clock" - for LD4 SoC.
+ "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC.
+ "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC.
+ "socionext,uniphier-pro5-peri-clock" - for Pro5 SoC.
+ "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC.
+ "socionext,uniphier-ld11-peri-clock" - for LD11 SoC.
+ "socionext,uniphier-ld20-peri-clock" - for LD20 SoC.
+- #clock-cells: should be 1.
+
+Example:
+
+ perictrl at 59820000 {
+ compatible = "socionext,uniphier-perictrl",
+ "simple-mfd", "syscon";
+ reg = <0x59820000 0x200>;
+
+ clock {
+ compatible = "socionext,uniphier-ld20-peri-clock";
+ #clock-cells = <1>;
+ };
+
+ other nodes ...
+ };
+
+Provided clocks:
+
+ 0: UART ch0
+ 1: UART ch1
+ 2: UART ch2
+ 3: UART ch3
+ 4: I2C ch0
+ 5: I2C ch1
+ 6: I2C ch2
+ 7: I2C ch3
+ 8: I2C ch4
+ 9: I2C ch5
+10: I2C ch6
diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
index 88a28ca..f27b3603 100644
--- a/drivers/clk/uniphier/Makefile
+++ b/drivers/clk/uniphier/Makefile
@@ -3,3 +3,6 @@ obj-y += clk-uniphier-fixed-factor.o
obj-y += clk-uniphier-fixed-rate.o
obj-y += clk-uniphier-gate.o
obj-y += clk-uniphier-mux.o
+obj-y += clk-uniphier-sys.o
+obj-y += clk-uniphier-mio.o
+obj-y += clk-uniphier-peri.o
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
index a6e2a94..5ffb898 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -109,6 +109,97 @@ static int uniphier_clk_remove(struct platform_device *pdev)
}
static const struct of_device_id uniphier_clk_match[] = {
+ /* System clock */
+ {
+ .compatible = "socionext,uniphier-ld4-clock",
+ .data = uniphier_ld4_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro4-clock",
+ .data = uniphier_pro4_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-sld8-clock",
+ .data = uniphier_sld8_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro5-clock",
+ .data = uniphier_pro5_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs2-clock",
+ .data = uniphier_pxs2_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld11-clock",
+ .data = uniphier_ld11_sys_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-clock",
+ .data = uniphier_ld20_sys_clk_data,
+ },
+ /* Media I/O clock */
+ {
+ .compatible = "socionext,uniphier-sld3-mio-clock",
+ .data = uniphier_sld3_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld4-mio-clock",
+ .data = uniphier_sld3_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro4-mio-clock",
+ .data = uniphier_sld3_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-sld8-mio-clock",
+ .data = uniphier_sld3_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro5-mio-clock",
+ .data = uniphier_pro5_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs2-mio-clock",
+ .data = uniphier_pro5_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld11-mio-clock",
+ .data = uniphier_sld3_mio_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-mio-clock",
+ .data = uniphier_pro5_mio_clk_data,
+ },
+ /* Peripheral clock */
+ {
+ .compatible = "socionext,uniphier-ld4-peri-clock",
+ .data = uniphier_ld4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro4-peri-clock",
+ .data = uniphier_pro4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-sld8-peri-clock",
+ .data = uniphier_ld4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro5-peri-clock",
+ .data = uniphier_pro4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs2-peri-clock",
+ .data = uniphier_pro4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld11-peri-clock",
+ .data = uniphier_pro4_peri_clk_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-peri-clock",
+ .data = uniphier_pro4_peri_clk_data,
+ },
{ /* sentinel */ }
};
diff --git a/drivers/clk/uniphier/clk-uniphier-mio.c b/drivers/clk/uniphier/clk-uniphier-mio.c
new file mode 100644
index 0000000..6aa7ec7
--- /dev/null
+++ b/drivers/clk/uniphier/clk-uniphier-mio.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "clk-uniphier.h"
+
+#define UNIPHIER_MIO_CLK_SD_FIXED \
+ UNIPHIER_CLK_FACTOR("sd-44m", -1, "sd-133m", 1, 3), \
+ UNIPHIER_CLK_FACTOR("sd-33m", -1, "sd-200m", 1, 6), \
+ UNIPHIER_CLK_FACTOR("sd-50m", -1, "sd-200m", 1, 4), \
+ UNIPHIER_CLK_FACTOR("sd-67m", -1, "sd-200m", 1, 3), \
+ UNIPHIER_CLK_FACTOR("sd-100m", -1, "sd-200m", 1, 2), \
+ UNIPHIER_CLK_FACTOR("sd-40m", -1, "sd-200m", 1, 5), \
+ UNIPHIER_CLK_FACTOR("sd-25m", -1, "sd-200m", 1, 8), \
+ UNIPHIER_CLK_FACTOR("sd-22m", -1, "sd-133m", 1, 6)
+
+#define UNIPHIER_MIO_CLK_SD(_idx, ch) \
+ { \
+ .name = "sd" #ch "-sel", \
+ .type = UNIPHIER_CLK_TYPE_MUX, \
+ .idx = -1, \
+ .data.mux = { \
+ .parent_names = { \
+ "sd-44m", \
+ "sd-33m", \
+ "sd-50m", \
+ "sd-67m", \
+ "sd-100m", \
+ "sd-40m", \
+ "sd-25m", \
+ "sd-22m", \
+ }, \
+ .num_parents = 8, \
+ .reg = 0x30 + 0x200 * (ch), \
+ .masks = { \
+ 0x00031000, \
+ 0x00031000, \
+ 0x00031000, \
+ 0x00031000, \
+ 0x00001300, \
+ 0x00001300, \
+ 0x00001300, \
+ 0x00001300, \
+ }, \
+ .vals = { \
+ 0x00000000, \
+ 0x00010000, \
+ 0x00020000, \
+ 0x00030000, \
+ 0x00001000, \
+ 0x00001100, \
+ 0x00001200, \
+ 0x00001300, \
+ }, \
+ }, \
+ }, \
+ UNIPHIER_CLK_GATE("sd" #ch, (_idx), "sd" #ch "-sel", 0x20 + 0x200 * (ch), 8)
+
+#define UNIPHIER_MIO_CLK_USB2(idx, ch) \
+ UNIPHIER_CLK_GATE("usb2" #ch, (idx), "usb2", 0x20 + 0x200 * (ch), 28)
+
+#define UNIPHIER_MIO_CLK_USB2_PHY(idx, ch) \
+ UNIPHIER_CLK_GATE("usb2" #ch "-phy", (idx), "usb2", 0x20 + 0x200 * (ch), 29)
+
+#define UNIPHIER_MIO_CLK_DMAC(idx) \
+ UNIPHIER_CLK_GATE("miodmac", (idx), "stdmac", 0x20, 25)
+
+const struct uniphier_clk_data uniphier_sld3_mio_clk_data[] = {
+ UNIPHIER_MIO_CLK_SD_FIXED,
+ UNIPHIER_MIO_CLK_SD(0, 0),
+ UNIPHIER_MIO_CLK_SD(1, 1),
+ UNIPHIER_MIO_CLK_SD(2, 2),
+ UNIPHIER_MIO_CLK_DMAC(7),
+ UNIPHIER_MIO_CLK_USB2(8, 0),
+ UNIPHIER_MIO_CLK_USB2(9, 1),
+ UNIPHIER_MIO_CLK_USB2(10, 2),
+ UNIPHIER_MIO_CLK_USB2(11, 3),
+ UNIPHIER_MIO_CLK_USB2_PHY(12, 0),
+ UNIPHIER_MIO_CLK_USB2_PHY(13, 1),
+ UNIPHIER_MIO_CLK_USB2_PHY(14, 2),
+ UNIPHIER_MIO_CLK_USB2_PHY(15, 3),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_pro5_mio_clk_data[] = {
+ UNIPHIER_MIO_CLK_SD_FIXED,
+ UNIPHIER_MIO_CLK_SD(0, 0),
+ UNIPHIER_MIO_CLK_SD(1, 1),
+ { /* sentinel */ }
+};
diff --git a/drivers/clk/uniphier/clk-uniphier-peri.c b/drivers/clk/uniphier/clk-uniphier-peri.c
new file mode 100644
index 0000000..521c80e
--- /dev/null
+++ b/drivers/clk/uniphier/clk-uniphier-peri.c
@@ -0,0 +1,57 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "clk-uniphier.h"
+
+#define UNIPHIER_PERI_CLK_UART(idx, ch) \
+ UNIPHIER_CLK_GATE("uart" #ch, (idx), "uart", 0x24, 19 + (ch))
+
+#define UNIPHIER_PERI_CLK_I2C_COMMON \
+ UNIPHIER_CLK_GATE("i2c-common", -1, "i2c", 0x20, 1)
+
+#define UNIPHIER_PERI_CLK_I2C(idx, ch) \
+ UNIPHIER_CLK_GATE("i2c" #ch, (idx), "i2c-common", 0x24, 5 + (ch))
+
+#define UNIPHIER_PERI_CLK_FI2C(idx, ch) \
+ UNIPHIER_CLK_GATE("i2c" #ch, (idx), "i2c", 0x24, 24 + (ch))
+
+const struct uniphier_clk_data uniphier_ld4_peri_clk_data[] = {
+ UNIPHIER_PERI_CLK_UART(0, 0),
+ UNIPHIER_PERI_CLK_UART(1, 1),
+ UNIPHIER_PERI_CLK_UART(2, 2),
+ UNIPHIER_PERI_CLK_UART(3, 3),
+ UNIPHIER_PERI_CLK_I2C_COMMON,
+ UNIPHIER_PERI_CLK_I2C(4, 0),
+ UNIPHIER_PERI_CLK_I2C(5, 1),
+ UNIPHIER_PERI_CLK_I2C(6, 2),
+ UNIPHIER_PERI_CLK_I2C(7, 3),
+ UNIPHIER_PERI_CLK_I2C(8, 4),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_pro4_peri_clk_data[] = {
+ UNIPHIER_PERI_CLK_UART(0, 0),
+ UNIPHIER_PERI_CLK_UART(1, 1),
+ UNIPHIER_PERI_CLK_UART(2, 2),
+ UNIPHIER_PERI_CLK_UART(3, 3),
+ UNIPHIER_PERI_CLK_FI2C(4, 0),
+ UNIPHIER_PERI_CLK_FI2C(5, 1),
+ UNIPHIER_PERI_CLK_FI2C(6, 2),
+ UNIPHIER_PERI_CLK_FI2C(7, 3),
+ UNIPHIER_PERI_CLK_FI2C(8, 4),
+ UNIPHIER_PERI_CLK_FI2C(9, 5),
+ UNIPHIER_PERI_CLK_FI2C(10, 6),
+ { /* sentinel */ }
+};
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
new file mode 100644
index 0000000..5d02999
--- /dev/null
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/stddef.h>
+
+#include "clk-uniphier.h"
+
+#define UNIPHIER_SLD3_SYS_CLK_SD \
+ UNIPHIER_CLK_FACTOR("sd-200m", -1, "spll", 1, 8), \
+ UNIPHIER_CLK_FACTOR("sd-133m", -1, "vpll27a", 1, 2)
+
+#define UNIPHIER_PRO5_SYS_CLK_SD \
+ UNIPHIER_CLK_FACTOR("sd-200m", -1, "spll", 1, 12), \
+ UNIPHIER_CLK_FACTOR("sd-133m", -1, "spll", 1, 18)
+
+#define UNIPHIER_LD20_SYS_CLK_SD \
+ UNIPHIER_CLK_FACTOR("sd-200m", -1, "spll", 1, 10), \
+ UNIPHIER_CLK_FACTOR("sd-133m", -1, "spll", 1, 15)
+
+#define UNIPHIER_SLD3_SYS_CLK_STDMAC(idx) \
+ UNIPHIER_CLK_GATE("stdmac", (idx), NULL, 0x2104, 10)
+
+#define UNIPHIER_LD11_SYS_CLK_STDMAC(idx) \
+ UNIPHIER_CLK_GATE("stdmac", (idx), NULL, 0x210c, 8)
+
+#define UNIPHIER_PRO4_SYS_CLK_GIO(idx) \
+ UNIPHIER_CLK_GATE("gio", (idx), NULL, 0x2104, 6)
+
+#define UNIPHIER_PRO4_SYS_CLK_USB3(idx, ch) \
+ UNIPHIER_CLK_GATE("usb3" #ch, (idx), NULL, 0x2104, 16 + (ch))
+
+const struct uniphier_clk_data uniphier_sld3_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 65, 1), /* 1597.44 MHz */
+ UNIPHIER_CLK_FACTOR("upll", -1, "ref", 6000, 512), /* 288 MHz */
+ UNIPHIER_CLK_FACTOR("a2pll", -1, "ref", 24, 1), /* 589.824 MHz */
+ UNIPHIER_CLK_FACTOR("vpll27a", -1, "ref", 5625, 512), /* 270 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "a2pll", 1, 16),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 16),
+ UNIPHIER_SLD3_SYS_CLK_SD,
+ UNIPHIER_CLK_FACTOR("usb2", -1, "upll", 1, 12),
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_ld4_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 65, 1), /* 1597.44 MHz */
+ UNIPHIER_CLK_FACTOR("upll", -1, "ref", 6000, 512), /* 288 MHz */
+ UNIPHIER_CLK_FACTOR("a2pll", -1, "ref", 24, 1), /* 589.824 MHz */
+ UNIPHIER_CLK_FACTOR("vpll27a", -1, "ref", 5625, 512), /* 270 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "a2pll", 1, 16),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 16),
+ UNIPHIER_SLD3_SYS_CLK_SD,
+ UNIPHIER_CLK_FACTOR("usb2", -1, "upll", 1, 12),
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8), /* Ether, HSC, MIO */
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_pro4_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 64, 1), /* 1600 MHz */
+ UNIPHIER_CLK_FACTOR("upll", -1, "ref", 288, 25), /* 288 MHz */
+ UNIPHIER_CLK_FACTOR("a2pll", -1, "upll", 256, 125), /* 589.824 MHz */
+ UNIPHIER_CLK_FACTOR("vpll27a", -1, "ref", 270, 25), /* 270 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "a2pll", 1, 8),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 32),
+ UNIPHIER_SLD3_SYS_CLK_SD,
+ UNIPHIER_CLK_FACTOR("usb2", -1, "upll", 1, 12),
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8), /* HSC, MIO, RLE */
+ UNIPHIER_PRO4_SYS_CLK_GIO(12), /* Ether, SATA, USB3 */
+ UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
+ UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_sld8_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 64, 1), /* 1600 MHz */
+ UNIPHIER_CLK_FACTOR("upll", -1, "ref", 288, 25), /* 288 MHz */
+ UNIPHIER_CLK_FACTOR("vpll27a", -1, "ref", 270, 25), /* 270 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 20),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 16),
+ UNIPHIER_SLD3_SYS_CLK_SD,
+ UNIPHIER_CLK_FACTOR("usb2", -1, "upll", 1, 12),
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8), /* Ether, HSC, MIO */
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_pro5_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 120, 1), /* 2400 MHz */
+ UNIPHIER_CLK_FACTOR("dapll1", -1, "ref", 128, 1), /* 2560 MHz */
+ UNIPHIER_CLK_FACTOR("dapll2", -1, "ref", 144, 125), /* 2949.12 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "dapll2", 1, 40),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 48),
+ UNIPHIER_PRO5_SYS_CLK_SD,
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8), /* HSC */
+ UNIPHIER_PRO4_SYS_CLK_GIO(12), /* PCIe, USB3 */
+ UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
+ UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 96, 1), /* 2400 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 27),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 48),
+ UNIPHIER_PRO5_SYS_CLK_SD,
+ UNIPHIER_SLD3_SYS_CLK_STDMAC(8), /* HSC, RLE */
+ /* GIO is always clock-enabled: no function for 0x2104 bit6 */
+ UNIPHIER_PRO4_SYS_CLK_USB3(14, 0),
+ UNIPHIER_PRO4_SYS_CLK_USB3(15, 1),
+ /* The document mentions 0x2104 bit 18, but not functional */
+ UNIPHIER_CLK_GATE("usb30-phy", 16, NULL, 0x2104, 19),
+ UNIPHIER_CLK_GATE("usb31-phy", 20, NULL, 0x2104, 20),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_ld11_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
+ UNIPHIER_LD11_SYS_CLK_STDMAC(8), /* HSC, MIO */
+ UNIPHIER_CLK_FACTOR("usb2", -1, "ref", 24, 25),
+ { /* sentinel */ }
+};
+
+const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
+ UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
+ UNIPHIER_LD20_SYS_CLK_SD,
+ UNIPHIER_LD11_SYS_CLK_STDMAC(8), /* HSC */
+ /* GIO is always clock-enabled: no function for 0x210c bit5 */
+ /*
+ * clock for USB Link is enabled by the logic "OR" of bit 14 and bit 15.
+ * We do not use bit 15 here.
+ */
+ UNIPHIER_CLK_GATE("usb30", 14, NULL, 0x210c, 14),
+ UNIPHIER_CLK_GATE("usb30-phy0", 16, NULL, 0x210c, 12),
+ UNIPHIER_CLK_GATE("usb30-phy1", 17, NULL, 0x210c, 13),
+ { /* sentinel */ }
+};
diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
index 3e354e9..3ae1840 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -106,4 +106,17 @@ struct clk_hw *uniphier_clk_register_mux(struct device *dev,
const char *name,
const struct uniphier_clk_mux_data *data);
+extern const struct uniphier_clk_data uniphier_sld3_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_ld4_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_pro4_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_sld8_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_pro5_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_ld11_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_ld20_sys_clk_data[];
+extern const struct uniphier_clk_data uniphier_sld3_mio_clk_data[];
+extern const struct uniphier_clk_data uniphier_pro5_mio_clk_data[];
+extern const struct uniphier_clk_data uniphier_ld4_peri_clk_data[];
+extern const struct uniphier_clk_data uniphier_pro4_peri_clk_data[];
+
#endif /* __CLK_UNIPHIER_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH v6 1/2] clk: uniphier: add core support code for UniPhier clock driver
From: Masahiro Yamada @ 2016-09-16 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907003258.GP12510@codeaurora.org>
Hi Stephen,
2016-09-07 9:32 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 09/05, Masahiro Yamada wrote:
>> 2016-08-30 3:22 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
>> > On 08/29, Masahiro Yamada wrote:
>> >> I tried this, but it did not work.
>> >>
>> >> To make dev_get_regmap() work,
>> >> the parent device needs to call dev_regmap_init_mmio() beforehand.
>> >>
>> >>
>> >> Since commit bdb0066df96e74a4002125467ebe459feff1ebef
>> >> (mfd: syscon: Decouple syscon interface from platform devices),
>> >> syscon_probe() is not called for platform devices,
>> >> so that never happens.
>> >>
>> >
>> > Ok. Is the syscon also a simple-mfd?
>> >
>> > It sounds like there's a device for the parent, but we've failed
>> > to attach a regmap to it. Maybe the core DT code should assign
>> > the regmap to the parent device when it creates it so that child
>> > devices don't need to know this detail? It could look for
>> > simple-mfd devices with compatible = "syscon" and then create the
>> > regmap? Here's a totally untested patch for that.
>> >
>>
>>
>> I was not quire sure about this,
>> but maybe worth submitting to DT subsystem?
>>
>> Anyway, I will go with syscon_node_to_regmap() for v7.
>> Of course, I am happy to replace it with dev_get_regmap()
>> when the issue is solved in the mainline.
>>
>
> Ok that's fine. Did my patch fix dev_get_regmap() for you though?
> That would be useful to know so that this patch can be merged in
> parallel to yours.
Sorry for my late reply.
Yup, your patch worked fine!
And, I've posted v7 for my SoC clk driver.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v3] clk: let clk_disable() return immediately if clk is NULL
From: Masahiro Yamada @ 2016-09-16 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <194aebe5-38dd-f43d-fb4d-16ce592a68e8@gmail.com>
Hi Stephen, Michael,
2016-08-26 0:27 GMT+09:00 Florian Fainelli <f.fainelli@gmail.com>:
> On 08/24/2016 10:26 AM, Masahiro Yamada wrote:
>> Many of clk_disable() implementations just return for NULL pointer,
>> but this check is missing from some. Let's make it tree-wide
>> consistent. It will allow clock consumers to call clk_disable()
>> without NULL pointer check.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Acked-by: Greg Ungerer <gerg@uclinux.org>
>> Acked-by: Wan Zongshun <mcuos.com@gmail.com>
>> ---
>>
>> I came back after a long pause.
>> You can see the discussion about the previous version:
>> https://www.linux-mips.org/archives/linux-mips/2016-04/msg00063.html
>>
>>
>> Changes in v3:
>> - Return only when clk is NULL. Do not take care of error pointer.
>>
>> Changes in v2:
>> - Rebase on Linux 4.6-rc1
>>
>> arch/arm/mach-mmp/clock.c | 3 +++
>> arch/arm/mach-w90x900/clock.c | 3 +++
>> arch/blackfin/mach-bf609/clock.c | 3 +++
>> arch/m68k/coldfire/clk.c | 4 ++++
>> arch/mips/bcm63xx/clk.c | 3 +++
>
Gentle ping...
If you are not keen on this,
shall I split it per-arch and send to each arch subsystem?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Will Deacon @ 2016-09-16 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916043218.GA30248@linaro.org>
A Jason appeared!
On Fri, Sep 16, 2016 at 01:32:19PM +0900, AKASHI Takahiro wrote:
> On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
> > I added the patch to kgdb-next after fixing up the context since it no
> > longer applied to the mainline (
> > https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
> > If there is further discussion on the point above, another patch can be
> > added, but it I am assuming this is the way you desire it to work as
> > there are some other architectures that use the same behaviour. I do
> > not presently have any ARM64 hardware to validate this particular
> > change.
> >
> > I also added to the patch a "Cc: linux-stable <stable@vger.kernel.org>"
> > so we can have this appear on some of the older kernels.
>
> Since Will asked me to split this patch into a few, I need some reworks
> to clarify which hunks in the patch are necessary for which version of kernel.
Yes, splitting the patch would be much better for sorting out the stable
backports too. Jason, please can you drop the patch for now? I don't mind
whether the end result goes via arm64 or kgdb, but we should at least both
agree on it first :)
Will
^ permalink raw reply
* [GIT PULL] arm64: X-Gene platforms DTS changes queued for 4.9 - part1
From: Arnd Bergmann @ 2016-09-16 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915112440.GD6718@leverpostej>
On Thursday, September 15, 2016 12:24:40 PM CEST Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 11:15:35AM +0100, Will Deacon wrote:
> > From 436d3a7ad25517433fc8f563f44fdab3c4801666 Mon Sep 17 00:00:00 2001
> > From: Will Deacon <will.deacon@arm.com>
> > Date: Thu, 15 Sep 2016 10:14:41 +0100
> > Subject: [PATCH] MAINTAINERS: Update ARM PMU PROFILING AND DEBUGGING entry
> >
> > There are an increasing number of ARM SoC PMU drivers appearing for
> > things like interconnects, memory controllers and cache controllers.
> > Rather than have these handled on an ad-hoc basis, where SoC maintainers
> > each send their PMU drivers directly to arm-soc, let's take these into
> > drivers/perf/ and send a single pull request to arm-soc instead, much
> > like other subsystems.
> >
> > This patch amends the ARM PMU MAINTAINERS entry to include all of
> > drivers/perf/ (currently just the ARM CPU PMU), changes Mark Rutland
> > from Reviewer to Maintainer, so that he can help with the new tree and
> > adds the device-tree binding to the list of maintained files.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> FWIW:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [RFC PATCH v2 1/5] ARM: hisi: Make 3620 explicit, remove wildcards
From: Arnd Bergmann @ 2016-09-16 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-2-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:01 PM CEST Marty Plummer wrote:
> --- a/arch/arm/mach-hisi/Kconfig
> +++ b/arch/arm/mach-hisi/Kconfig
> @@ -12,8 +12,8 @@ if ARCH_HISI
>
> menu "Hisilicon platform type"
>
> -config ARCH_HI3xxx
> - bool "Hisilicon Hi36xx family"
> +config ARCH_HI3620
> + bool "Hisilicon Hi3620 family"
> depends on ARCH_MULTI_V7
> select CACHE_L2X0
> select HAVE_ARM_SCU if SMP
>
This breaks bisection by removing the ARCH_HI3xxx symbol that
the other drivers still rely on until the entire series is
applied.
I'd suggest introducing a hidden ARCH_HI3xxx symbol like
config ARCH_HI3xxx
bool
config ARCH_HI3620
bool "Hisilicon Hi3620 family"
select ARCH_HI3xxx
...
Arnd
^ permalink raw reply
* [GIT PULL] STi DT update for v4.9, round 3
From: Patrice Chotard @ 2016-09-16 7:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this next batch for v4.9, dedicated for clock improvements
The following changes since commit 443fd7c92f5a000796b02683157d17b2575450e1:
ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card (2016-09-14 13:37:29 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-v4.9-3
for you to fetch changes up to 3a74152ce62e7ec1b8a5604b10e40d2a66d8f43b:
ARM: dts: STiH410: clock configuration to address 720p and 1080p (2016-09-16 09:42:13 +0200)
----------------------------------------------------------------
Clock improvement for video playback
This serie allows to increase video resolutions and make audio
adjustment during a video playback for STiH407 family socs.
----------------------------------------------------------------
Gabriel Fernandez (9):
ARM: dts: STiH4xx: Simplify clock binding of STiH4xx platforms
ARM: dts: STiH407: Enable clock propagation for audio clocks
ARM: dts: STiH410: Enable clock propagation for audio clocks
ARM: dts: STiH418: Enable clock propagation for audio clocks
ARM: dts: STiH407: Enable synchronous clock mode for video clocks
ARM: dts: STiH410: Enable synchronous clock mode for video clocks
ARM: dts: STiH418: Enable synchronous clock mode for video clocks
ARM: dts: STi: STiH407: clock configuration to address 720p and 1080p
ARM: dts: STiH410: clock configuration to address 720p and 1080p
arch/arm/boot/dts/stih407-clock.dtsi | 22 +++++++++++-----------
arch/arm/boot/dts/stih407.dtsi | 16 +++++++++++++---
arch/arm/boot/dts/stih410-clock.dtsi | 20 ++++++++++----------
arch/arm/boot/dts/stih410.dtsi | 16 +++++++++++++---
arch/arm/boot/dts/stih418-clock.dtsi | 20 ++++++++++----------
5 files changed, 57 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH v2 0/5] Cavium ThunderX uncore PMU support
From: Will Deacon @ 2016-09-16 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160704101132.GC1639@arm.com>
Hi Jan,
On Mon, Jul 04, 2016 at 11:11:32AM +0100, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote:
> > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote:
> > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote:
> > > > This patch series provides access to various counters on the ThunderX SOC.
> > > >
> > > > For details of the uncore implementation see patch #1.
> > > >
> > > > Patches #2-5 add the various ThunderX specific PMUs.
> > > >
> > > > As suggested I've put the files under drivers/perf/uncore. I would
> > > > prefer this location over drivers/bus because not all of the uncore
> > > > drivers are bus related.
> > >
> > > What's the status of these patches? Were you planning to send a new
> > > version?
> >
> > I was half-way through with addressing Mark's review comments when
> > got side-tracked.
> >
> > The principle question these patches raised remains open though in my
> > opinion, how to determine the socket a device belongs to.
> >
> > There is no first-class interface to ask a device or the firmware
> > which socket the device lives on.
> >
> > The options I see are:
> > A) Using NUMA node information, depends on CONFIG_NUMA
> > B) Decoding the socket bits of the PCI BAR address
> > C) Using PCI topology information
> >
> > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good
> > solution. B would be easy but looks not very future-proof. So option C
> > is what is left...
>
> Sorry to go full circle on this, but "depends on NUMA" sounds better
> than deriving NUMA topology from PCI to me. The only worry I have is if
> the NUMA information ends up being insufficient in the long-term, and we
> end up with a mixture of the three options above in order to figure out
> the PMU topology.
>
> As long as you're happy that the PMU:NUMA topology remains 1:1, then I
> have no objections. The moment you need extra hacks on the side, we should
> probably drop the NUMA dependency altogether and figure it out some other
> way.
Any news on this series, or did I miss a v3? I was hoping to have this in
for 4.9, but it seems to have stalled :(
Will
^ permalink raw reply
* [PATCH v3 01/17] pinctrl: dt-bindings: samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-09-16 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb9gq0Zez=_NW8XB6YKiJteC3GB12e-Wi9my52b4Q-C7A@mail.gmail.com>
On 09/07/2016 11:18 PM, Linus Walleij wrote:
> On Sun, Sep 4, 2016 at 1:04 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> Hard-coded pinctrl configuration values are scattered through DTS files.
>> The numbers are difficult to decode by human, especially without the
>> datasheet. Additionally the drive strength differs between S3C64xx,
>> S5PV210 and Exynos SoC families increasing the confusion.
>>
>> The header will help making this more readable and maintainable.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Take this with the rest of the changes into ARM SoC.
Thanks!
Applied entire patchset.
Best regards,
Krzysztof
^ permalink raw reply
* [RFC PATCH v2 4/5] ARM: hisi: enable devicetree support for hi3520
From: Arnd Bergmann @ 2016-09-16 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-5-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:04 PM CEST Marty Plummer wrote:
> @@ -24,17 +31,19 @@ config ARCH_HI3620
> Support for Hisilicon Hi36xx SoC family
>
> config ARCH_HIP01
> - bool "Hisilicon HIP01 family"
> - depends on ARCH_MULTI_V7
> - select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if SMP
> - select ARM_GLOBAL_TIMER
> - help
> - Support for Hisilicon HIP01 SoC family
> + bool "Hisilicon HIP01 family"
> + depends on ARCH_MULTI_V7
> + select ARM_GIC
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if SMP
> + select ARM_GLOBAL_TIMER
> + help
> + Support for Hisilicon HIP01 SoC family
>
This change doesn't belong in here.
> @@ -28,6 +30,16 @@
> * spaces wasted since ioremap() may be called multi times for the same
> * IO space.
> */
> +static struct map_desc hi3520_1176_io_desc[] __initdata = {
> + {
> + /* sysctrl */
> + .virtual = HI3520_1176_SYSCTRL_VIRT_BASE,
> + .pfn = __phys_to_pfn(HI3520_1176_SYSCTRL_PHYS_BASE),
> + .length = 0x10000,
> + .type = MT_DEVICE,
> + },
> +};
> +
> static struct map_desc hi3620_io_desc[] __initdata = {
> {
> /* sysctrl */
What do you need this for? I think it would be better to map the
device manually from whichever code uses itby looking it up
in the DT.
Arnd
^ permalink raw reply
* [RFC PATCH v2 5/5] ARM: hisi: add devicetree for hi3520
From: Arnd Bergmann @ 2016-09-16 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-6-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:05 PM CEST Marty Plummer wrote:
> diff --git a/arch/arm/boot/dts/hi3520-1176-dm77a.dts b/arch/arm/boot/dts/hi3520-1176-dm77a.dts
> new file mode 100644
> index 0000000..c87a18e
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3520-1176-dm77a.dts
> @@ -0,0 +1,62 @@
> +/*
> + * Copyright (C) 2016 Marty Plummer <netz.kernel@gmail.com>
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/dts-v1/;
> +#include "hi3520-1176.dtsi"
> +
> +/ {
> + model = "Nightowl zeus-dvr";
> + compatible = "hisilicon,hi3520-1176";
Please add a board specific compatible string in front of the string
for the soc.
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + };
Do you actually have access to all four serial ports on this board?
If not, just add aliases for the ones you see.
> + /* chosen { */
> + /* bootargs = "mem=72M console=ttyAMA0,115200 root=/dev/ram"; */
> + /* stdout-path = "serial0:115200n8"; */
> + /* }; */
I'd leave the stdout-path property in here, but not the bootargs.
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,arm1176jzf-s";
> + reg = <0>;
> + };
> + };
I guess in the long run we will want to support both the ARM926 and
the ARM1176, so maybe split the .dtsi file into two: one for whatever
is common to both cores, and one for the ARM1176 CPU and anything
exlusively used by that.
> +
> + amba {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges;
> +
> + uart0: uart at 20090000 {
The name should be serial at 20090000
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x20090000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 12 4>;
> + status = "disable";
> + };
status="disabled" (with 'd')
> +
> + uart1: uart at 200a0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200a0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 12 4>;
> + };
> +
> + uart2: uart at 200b0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200b0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 13 4>;
> + };
> +
> + uart3: uart at 200c0000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x200c0000 0x1000>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "uartclk", "apb_pclk";
> + interrupts-extended = <&vic0 13 4>;
> + };
Why are these not disabled?
> + gpio0: gpio at 20150000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x20150000 0x1000>;
> + interrupts-extended = <&vic1 6 4>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + clocks = <&uartclk &clk_3m>;
> + clock-names = "apb_pclk";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + status = "disabled";
> + };
This one should probably not be disabled in turn.
> + dual_timer0: dual_timer at 20000000 {
timer at 20000000
> + spi_bus0: spi at 200e0000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x200e0000 0x1000>;
> + interrupts-extended = <&vic0 11 4>;
> + num-cs = <1>;
> + };
> + };
There should be a #address-cells, also you probably want to
disable this if there are no child devices.
> + sysctrl: system-controller at 20050000 {
> + compatible = "hisilicon,hi3520-sysctrl", "syscon";
> + reg = <0x20050000 0x1000>;
> + };
The new compatible string needs to be listed in the sysctrl binding
document.
> +
> + reboot {
> + compatible = "syscon-reboot";
> + regmap = <&sysctrl>;
> + offset = <0x4>;
> + mask = <0xdeadbeef>;
> + };
> +
> + /* gmac0: ethernet at 10090000 { */
> + /* compatible = "hisilicon,hix5hd2-gmac"; */
> + /* reg = <0x10090000 0x1000>,<0x20050000 0x1000>; */
> + /* interrupts-extended = <&vic0 14 4>; */
> + /* clocks = <&clk_3m>; */
> + /* status = "disabled"; */
> + /* }; */
> +
> + usb0: ehci at 100b0000 {
usb at 100b0000
Arnd
^ permalink raw reply
* [RFC PATCH v2 3/5] dmaengine: hi3620: Make hi3620 explicit, remove wildcard
From: Arnd Bergmann @ 2016-09-16 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-4-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:03 PM CEST Marty Plummer wrote:
> Signed-off-by: Marty Plummer <netz.kernel@gmail.com>
> ---
> drivers/dma/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 739f797..74bab9d0 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -279,7 +279,7 @@ config INTEL_MIC_X100_DMA
>
> config K3_DMA
> tristate "Hisilicon K3 DMA support"
> - depends on ARCH_HI3xxx
> + depends on ARCH_HI3620
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
> help
>
This can not be applied until the first patch is merged.
If we leave a ARCH_HI3xxx Kconfig symbol in place indefinitely,
I think it's ok to just leave it the way it is right now
and drop the patch: there are many other drivers for hardware
you don't have and we just leave them disabled in the .config,
so we can do the same here.
Arnd
^ permalink raw reply
* [RFC PATCH v2 2/5] clk: hi3620: Make 3620 explicit, remove wildcard
From: Arnd Bergmann @ 2016-09-16 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915210505.21878-3-netz.kernel@gmail.com>
On Thursday, September 15, 2016 4:05:02 PM CEST Marty Plummer wrote:
> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
> index e169ec7..2edf3b5 100644
> --- a/drivers/clk/hisilicon/Makefile
> +++ b/drivers/clk/hisilicon/Makefile
> @@ -4,7 +4,7 @@
>
> obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
>
> -obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
> +obj-$(CONFIG_ARCH_HI3620) += clk-hi3620.o
> obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
> obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
> obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
I'd suggest instead adding a new Kconfig symbol for the clock driver
the same way we handle hi3519.
Arnd
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Marc Zyngier @ 2016-09-16 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916054917.16930-1-briannorris@chromium.org>
Hi Brian,
On 16/09/16 06:49, Brian Norris wrote:
> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
> for suspend timekeeping"), this driver assumes that the ARM architected
> timer keeps running in suspend. This is not the case for some ARM SoCs,
> depending on the HW state used for system suspend. Let's not assume that
> all SoCs support this, and instead only support this if the device tree
> explicitly tells us it's "always on". In all other cases, just fall back
> to the RTC. This should be relatively harmless.
I'm afraid you're confusing two things:
- the counter, which *must* carry on counting no matter what, as
(quoting the ARM ARM) "The system counter must be implemented in an
always-on power domain"
- the timer, which is allowed to be powered off, and can be tagged with
the "always-on" property to indicate that it is guaranteed to stay up
(which in practice only exists in virtual machines and never on real HW).
If your counter does stop counting when suspended, then this is starting
to either feel like a HW bug, or someone is killing the clock that feeds
this counter when entering suspend.
If this is the former, then we need a separate quirk to indicate the
non-standard behaviour. If it is the latter, don't do it! ;-)
>
> It seems fair to key the system-suspend behavior off the same property
> used for C3STOP, since if the timer doesn't keep context for CPU sleep,
> it likely doesn't for system sleep either.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 57700541f951..e28677a34f02 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -490,7 +490,7 @@ static struct clocksource clocksource_counter = {
> .rating = 400,
> .read = arch_counter_read,
> .mask = CLOCKSOURCE_MASK(56),
> - .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> };
>
> static struct cyclecounter cyclecounter = {
> @@ -526,6 +526,8 @@ static void __init arch_counter_register(unsigned type)
> clocksource_counter.name = "arch_mem_counter";
> }
>
> + if (!arch_timer_c3stop)
> + clocksource_counter.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
> start_count = arch_timer_read_counter();
> clocksource_register_hz(&clocksource_counter, arch_timer_rate);
> cyclecounter.mult = clocksource_counter.mult;
>
Given the above, I don't think this patch is acceptable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Neil Armstrong @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
Add a new list address in the MAINTAINERS file for the Oxnas platform.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 71aa5da..5470e42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1442,6 +1442,7 @@ F: arch/arm/mach-orion5x/ts78xx-*
ARM/OXNAS platform support
M: Neil Armstrong <narmstrong@baylibre.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L: linux-oxnas at lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
F: arch/arm/boot/dts/oxnas*
--
2.7.0
^ permalink raw reply related
* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Lothar Waßmann @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915180605.4aed48d3@bbrezillon>
Hi,
On Thu, 15 Sep 2016 18:06:05 +0200 Boris Brezillon wrote:
> Hi Lothar,
>
> On Fri, 9 Sep 2016 16:44:11 +0200
> Lothar Wa?mann <LW@KARO-electronics.de> wrote:
>
> > commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> > introduced a regression accessing the OOB area from the mxc_nand
> > driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> > functions. They report a bogus oobregion { 64, 7 } which leads to
> > errors accessing bogus data when reading the oob area.
> >
> > Prior to the commit the mtd-oobtest module could be run without any
> > errors. With the offending commit, this test fails with results like:
> > |Running mtd-oobtest
> > |
> > |=================================================
> > |mtd_oobtest: MTD device: 5
> > |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> > |mtd_test: scanning for bad eraseblocks
> > |mtd_test: scanned 4 eraseblocks, 0 are bad
> > |mtd_oobtest: test 1 of 5
> > |mtd_oobtest: writing OOBs of whole device
> > |mtd_oobtest: written up to eraseblock 0
> > |mtd_oobtest: written 4 eraseblocks
> > |mtd_oobtest: verifying all eraseblocks
> > |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> > |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> > |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> > |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> > |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> > |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> > |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> > |mtd_oobtest: error: verify failed at 0x0
> > [...]
> >
> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > ---
> > drivers/mtd/nand/mxc_nand.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > index 5173fad..fdee907 100644
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> > {
> > struct nand_chip *nand_chip = mtd_to_nand(mtd);
> >
> > - if (section > nand_chip->ecc.steps)
> > + if (section >= nand_chip->ecc.steps)
> > return -ERANGE;
>
> Hm, looking at the commit you're pointing to, it seems that this test
> is correct (we have X + 1 free sections, where X is the number of ECC
> steps).
>
You are right. I didn't verify the v1 case (for which I have no HW here
any more).
I'll send a corrected patch.
Lothar Wa?mann
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Daniel Lezcano @ 2016-09-16 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBA81F.2060404@arm.com>
On 16/09/2016 10:06, Marc Zyngier wrote:
> Hi Brian,
>
> On 16/09/16 06:49, Brian Norris wrote:
>> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
>> for suspend timekeeping"), this driver assumes that the ARM architected
>> timer keeps running in suspend. This is not the case for some ARM SoCs,
>> depending on the HW state used for system suspend. Let's not assume that
>> all SoCs support this, and instead only support this if the device tree
>> explicitly tells us it's "always on". In all other cases, just fall back
>> to the RTC. This should be relatively harmless.
>
> I'm afraid you're confusing two things:
> - the counter, which *must* carry on counting no matter what, as
> (quoting the ARM ARM) "The system counter must be implemented in an
> always-on power domain"
> - the timer, which is allowed to be powered off, and can be tagged with
> the "always-on" property to indicate that it is guaranteed to stay up
> (which in practice only exists in virtual machines and never on real HW).
>
> If your counter does stop counting when suspended, then this is starting
> to either feel like a HW bug, or someone is killing the clock that feeds
> this counter when entering suspend.
>
> If this is the former, then we need a separate quirk to indicate the
> non-standard behaviour. If it is the latter, don't do it! ;-)
+1
-- Daniel
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] arm64: tegra: Add missing Smaug revision
From: Alexandre Courbot @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL1qeaF+Zck_p_1d-cNMvoJ8oMn7c65wL21E6LjGVVMA3BY2yA@mail.gmail.com>
Not seeing this patch in -next, can someone pick it?
On Fri, Jul 1, 2016 at 1:15 AM, Andrew Bresticker <abrestic@chromium.org> wrote:
> On Wed, Jun 29, 2016 at 1:52 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> The "google,smaug-rev2" string is missing from the compatible list of
>> Smaug's DT. The differences of rev2 are not relevant at our current
>> level of support and it boots just fine, so add it.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Acked-by: Andrew Bresticker <abrestic@chromium.org>
>
>> ---
>> arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> index 431266a48e9c..82a96bd27bc8 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> @@ -11,7 +11,8 @@
>> compatible = "google,smaug-rev8", "google,smaug-rev7",
>> "google,smaug-rev6", "google,smaug-rev5",
>> "google,smaug-rev4", "google,smaug-rev3",
>> - "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
>> + "google,smaug-rev2", "google,smaug-rev1",
>> + "google,smaug", "nvidia,tegra210";
>>
>> aliases {
>> serial0 = &uarta;
>> --
>> 2.9.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCDDwydB+RP0CZKoAW5Suxotn224ZFVWvt2OGW3gNJR1g@mail.gmail.com>
Hi,
On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> However, the problem with all of the solutions proposed (runtime PM ones
>> included) is that we're forcing a board-specific design issue (2 devices
>> sharing a reset line) into a driver that should not have any
>> board-specific assumptions in it.
>>
>> For example, if this driver is used on another platform where different
>> PHYs have different reset lines, then one of them (the unlucky one who
>> is not probed first) will never get reset. So any form of per-device
>> ref-counting is not a portable solution.
> maybe we should also consider Ben's solution: he played with the USB
> PHY on his Meson8b board. His approach was to have only one USB PHY
> driver instance which exposes two PHYs.
> The downside of this: the driver would have to know the offset of the
> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
> the reset using runtime PM without any hacks.
I think the offset information can come from the devicetree too. The phy can be
modeled something like below.
usb-phys at c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
reg = <0x0 0xc0000000 0x0 0x40>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
resets = <&reset 34>;
usb0_phy: usb_phy at 0 {
#phy-cells = <0>;
reg = <0x0 0x0 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
clock-names = "usb_general", "usb";
status = "disabled";
};
usb1_phy: usb_phy at 20 {
#phy-cells = <0>;
reg = <0x0 0x20 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
clock-names = "usb_general", "usb";
status = "disabled";
};
};
This way the driver will be probed only once (the reset can be done during
probe). The phy driver should scan the dt node and for every sub-node it
invokes phy_create?
Thanks
Kishon
^ permalink raw reply
* [PATCH v2 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b3688bb-8dcb-24d4-8112-a0cc56573e48@ti.com>
On 09/07/2016 10:14 AM, Tomi Valkeinen wrote:
> On 01/09/16 14:49, Krzysztof Kozlowski wrote:
>> The Exynos MIPI driver does not work anymore (it is board file only) so
>> it is removed. Remove also config option.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> ---
>>
>> Changes since v1:
>> 1. New patch.
>> ---
>> arch/arm/configs/exynos_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
>> index 4e484f406419..fea8edef1534 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -168,7 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
>> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
>> CONFIG_DRM_NXP_PTN3460=y
>> CONFIG_DRM_PARADE_PS8622=y
>> -CONFIG_EXYNOS_VIDEO=y
>> CONFIG_EXYNOS_MIPI_DSI=y
>
> EXYNOS_MIPI_DSI too?
Yes, this one too. I'll send a v2. I think these patches can safely go
through different trees (removal of driver through your tree and
defconfig through arm-soc).
Best regards,
Krzysztof
^ permalink raw reply
* v4.8-rc: GSM audio causes trouble
From: Pavel Machek @ 2016-09-16 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915205142.GA6747@amd>
On Thu 2016-09-15 22:51:42, Pavel Machek wrote:
> Hi!
>
> > I was trying to improve GSM call quality, and hit problems in
> > v4.8-rc. Sound only worked for a while, then I tried to kill
> > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > even reboot.
> >
> > I went back to v4.1 (ok, quite far, I see), and problems are gone.
> >
> > Does it work for you? Any ideas what to try... besides bisect?
>
> v4.7 is okay.
>
> v4.8 with
>
> git diff ..mini-v4.7 drivers/hsi/ | git apply
I believe I tried just reverting
9c99e5e51988798af2a687ef9b1716dd79388550 before, but that did not
help.
I guess I'll try with these reverted, next:
pavel at amd:/data/l/linux-n900$ git show
9c99e5e51988798af2a687ef9b1716dd79388550 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
ad60db2f9fe3367e60a21fc0afe19999516f8b27 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
4e552310cdf0c81210b5fc9173f7cf497eeb9feb | git apply -R
pavel at amd:/data/l/linux-n900$ git show
604fdfa45886f04ad6070c1b8266c7f4154bc497 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
d2b8d695c61c4d2864eee900bebc2ced4f425645 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
fa1572d956ee072e965da01d2c46f10d2b67d017 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
62aa292b3eae920a80c2fd0ed0601a70328627f6 | git apply -R
pavel at amd:/data/l/linux-n900$
...seems to be broken already. I guess its time to
bisect... hmm. Tried bisecting, but soundcard does not work
there. Will do it manually...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v3 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474014760-23173-1-git-send-email-k.kozlowski@samsung.com>
The Exynos MIPI driver does not work anymore (it is board file only) so
it is removed. Remove also config options.
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
This does not really depend on patch #1. The driver is dysfunctional and
it does not work so defconfig change can be applied separately.
Changes since v2:
1. Remove also EXYNOS_MIPI_DSI, pointed out by Tomi Valkeinen.
Changes since v1:
1. New patch.
---
arch/arm/configs/exynos_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 4e484f406419..c58f6841f8aa 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -168,8 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
CONFIG_DRM_NXP_PTN3460=y
CONFIG_DRM_PARADE_PS8622=y
-CONFIG_EXYNOS_VIDEO=y
-CONFIG_EXYNOS_MIPI_DSI=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_PWM=y
--
1.9.1
^ permalink raw reply related
* [PATCH 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series will enable unconditional COMPILE_TEST coverage for the
following drivers: omap-dma, edma and ti-dma-crossbar
The series includes fixes noticed when compiling the drivers for x86_64 and
aarch64.
Replaces the patch Vinod sent to enable partial compile testing for omap-dma:
http://www.spinics.net/lists/dmaengine/msg11025.html
Regards,
Peter
---
Peter Ujfalusi (9):
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id
structs
dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
dmaengine: edma: Use correct type for of_find_property() third
parameter
dmaengine: edma: enable COMPILE_TEST
dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP
configs
dmaengine: omap-dma: enable COMPILE_TEST
dmaengine: ti-dma-crossbar: Correct type for of_find_property() third
parameter
dmaengine: ti-dma-crossbar: Use enum for crossbar type
dmaengine: ti-dma-crossbar: enable COMPILE_TEST
drivers/dma/Kconfig | 8 ++++----
drivers/dma/edma.c | 15 ++++++++++-----
drivers/dma/ti-dma-crossbar.c | 12 +++++++-----
include/linux/omap-dma.h | 19 +++++++++++++++++++
4 files changed, 40 insertions(+), 14 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH 1/9] dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id
structures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3d277fa76c1a..c2098a4b4dcf 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -274,11 +274,13 @@ static const struct of_device_id edma_of_ids[] = {
},
{}
};
+MODULE_DEVICE_TABLE(of, edma_of_ids);
static const struct of_device_id edma_tptc_of_ids[] = {
{ .compatible = "ti,edma3-tptc", },
{}
};
+MODULE_DEVICE_TABLE(of, edma_tptc_of_ids);
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
--
2.10.0
^ permalink raw reply related
* [PATCH 2/9] dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
Fixes the following warning when compiling the driver for 64bit
architectures (x86_64 for example):
drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (match && (u32)match->data == EDMA_BINDING_TPCC)
^
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c2098a4b4dcf..4c8818278fcc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -261,8 +261,11 @@ static const struct edmacc_param dummy_paramset = {
.ccnt = 1,
};
-#define EDMA_BINDING_LEGACY 0
-#define EDMA_BINDING_TPCC 1
+enum edma_binding_type {
+ EDMA_BINDING_LEGACY = 0,
+ EDMA_BINDING_TPCC,
+};
+
static const struct of_device_id edma_of_ids[] = {
{
.compatible = "ti,edma3",
@@ -2184,7 +2187,8 @@ static int edma_probe(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(edma_of_ids, node);
- if (match && (u32)match->data == EDMA_BINDING_TPCC)
+ if (match &&
+ (enum edma_binding_type)match->data == EDMA_BINDING_TPCC)
legacy_mode = false;
info = edma_setup_info_from_dt(dev, legacy_mode);
--
2.10.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox