* [PATCH v3 0/3] imx: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
mturquette-rdvid1DuHRBWk0Htik3J/w
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA,
Peter Chen
Hi Shawn,
In this series, it adds support for imx6ull SoC which is a derived SoC
from imx6ul, and imx6ull is pin-to-pin compatible with imx6ul, the
basic functions are tested at imx6ull 14x14 evk, and imx6ul 14x14 evk
is tested too to avoid regression.
Changes for v3:
- Keep imx6ul-14x14-evk.dts unchanging, and let imx6ull-14x14-evk.dts
include it. [Patch 1/3]
Changes for v2:
- Keep imx6ul.dtsi unchanging, and using GPL/X11 dual license
for new dts file. [Patch 1/3]
- Using IMX6ULL prefix for both imx6ull dedicated pin and clock name.
[Patch 1/3, 3/3]
- Delete useless changes for patch 2/3.
- Delete blank line for patch 3/3.
- Using assigned-clocks for imx6ull 14x14 evk. [Patch 1/3, 3/3]
Bai Ping (1):
clk: imx: clk-imx6ul: add clk support for imx6ull
Peter Chen (2):
ARM: imx6ull: add imx6ull support
ARM: imx: mach-imx6ul: add imx6ull support
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 +++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++
arch/arm/mach-imx/mach-imx6ul.c | 1 +
drivers/clk/imx/clk-imx6ul.c | 72 +++++++++++++++++++++++++++-----
include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
7 files changed, 229 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/3] ARM: imx6ull: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: shawnguo, sboyd, mturquette
Cc: linux-arm-kernel, kernel, devicetree, robh+dt, fabio.estevam,
mark.rutland, linux-clk, Peter Chen
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
It is the 10th processor in the well-known imx6 series, and derived
from imx6ul but cost optimized. The more information about imx6ull
can be found at:
http://www.nxp.com/products/microcontrollers-and-processors/
arm-processors/i.mx-applications-processors/i.mx-6-processors
/i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core
:i.MX6ULL
imx6ul.dtsi is the SoC common stuff for both imx6ul and imx6ull;
imx6ul-14x14-evk.dts is the board common stuff for both imx6ul
and imx6ull 14x14 evk. In this patch, for SoC part, the
imx6ull.dtsi includes imx6ul.dtsi; for board part, imx6ull-14x14-evk.dts
includes imx6ul-14x14-evk.dts.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/imx6ull-14x14-evk.dts | 52 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull-pinfunc.h | 56 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6ull.dtsi | 43 +++++++++++++++++++++++++
4 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx6ull-14x14-evk.dts
create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6ull.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3d6e199 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -423,7 +423,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
- imx6ul-tx6ul-mainboard.dtb
+ imx6ul-tx6ul-mainboard.dtb \
+ imx6ull-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
imx7d-colibri-eval-v3.dtb \
diff --git a/arch/arm/boot/dts/imx6ull-14x14-evk.dts b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
new file mode 100644
index 0000000..db5bc07
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-14x14-evk.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul-14x14-evk.dts"
+
+/ {
+ model = "Freescale i.MX6 UlltraLite 14x14 EVK Board";
+ compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6UL_CLK_PLL3_PFD2>;
+ assigned-clock-rates = <320000000>;
+};
diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h
new file mode 100644
index 0000000..580b5c3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull-pinfunc.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DTS_IMX6ULL_PINFUNC_H
+#define __DTS_IMX6ULL_PINFUNC_H
+
+#include "imx6ul-pinfunc.h"
+/*
+ * The pin function ID is a tuple of
+ * <mux_reg conf_reg input_reg mux_mode input_val>
+ */
+#define MX6ULL_PAD_ENET2_RX_DATA0__EPDC_SDDO08 0x00E4 0x0370 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_DATA1__EPDC_SDDO09 0x00E8 0x0374 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_EN__EPDC_SDDO10 0x00EC 0x0378 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA0__EPDC_SDDO11 0x00F0 0x037C 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_DATA1__EPDC_SDDO12 0x00F4 0x0380 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_EN__EPDC_SDDO13 0x00F8 0x0384 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_TX_CLK__EPDC_SDDO14 0x00FC 0x0388 0x0000 0x9 0x0
+#define MX6ULL_PAD_ENET2_RX_ER__EPDC_SDDO15 0x0100 0x038C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_CLK__EPDC_SDCLK 0x0104 0x0390 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_ENABLE__EPDC_SDLE 0x0108 0x0394 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_HSYNC__EPDC_SDOE 0x010C 0x0398 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_VSYNC__EPDC_SDCE0 0x0110 0x039C 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_RESET__EPDC_GDOE 0x0114 0x03A0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA00__EPDC_SDDO00 0x0118 0x03A4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA01__EPDC_SDDO01 0x011C 0x03A8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA02__EPDC_SDDO02 0x0120 0x03AC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA03__EPDC_SDDO03 0x0124 0x03B0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA04__EPDC_SDDO04 0x0128 0x03B4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA05__EPDC_SDDO05 0x012C 0x03B8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA06__EPDC_SDDO06 0x0130 0x03BC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA07__EPDC_SDDO07 0x0134 0x03C0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA14__EPDC_SDSHR 0x0150 0x03DC 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA15__EPDC_GDRL 0x0154 0x03E0 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA16__EPDC_GDCLK 0x0158 0x03E4 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA17__EPDC_GDSP 0x015C 0x03E8 0x0000 0x9 0x0
+#define MX6ULL_PAD_LCD_DATA21__EPDC_SDCE1 0x016C 0x03F8 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_MCLK__ESAI_TX3_RX2 0x01D4 0x0460 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_PIXCLK__ESAI_TX2_RX3 0x01D8 0x0464 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_VSYNC__ESAI_TX4_RX1 0x01DC 0x0468 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_HSYNC__ESAI_TX1 0x01E0 0x046C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA00__ESAI_TX_HF_CLK 0x01E4 0x0470 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA01__ESAI_RX_HF_CLK 0x01E8 0x0474 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA02__ESAI_RX_FS 0x01EC 0x0478 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA03__ESAI_RX_CLK 0x01F0 0x047C 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0
+#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0
+
+#endif /* __DTS_IMX6ULL_PINFUNC_H */
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
new file mode 100644
index 0000000..dee8ab8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ull.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+#include "imx6ull-pinfunc.h"
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] ARM: imx: mach-imx6ul: add imx6ull support
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
mturquette-rdvid1DuHRBWk0Htik3J/w
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, fabio.estevam-3arQi8VN3Tc,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA,
Peter Chen
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
imx6ull is derived SoC from imx6ul.
Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
---
arch/arm/mach-imx/mach-imx6ul.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
index 58a2b88..6cb8a22 100644
--- a/arch/arm/mach-imx/mach-imx6ul.c
+++ b/arch/arm/mach-imx/mach-imx6ul.c
@@ -89,6 +89,7 @@ static void __init imx6ul_init_late(void)
static const char * const imx6ul_dt_compat[] __initconst = {
"fsl,imx6ul",
+ "fsl,imx6ull",
NULL,
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Peter Chen @ 2016-11-14 7:04 UTC (permalink / raw)
To: shawnguo, sboyd, mturquette
Cc: linux-arm-kernel, kernel, devicetree, robh+dt, fabio.estevam,
mark.rutland, linux-clk, Bai Ping, Peng Fan, Peter Chen
In-Reply-To: <1479107062-15365-1-git-send-email-peter.chen@nxp.com>
From: Bai Ping <ping.bai@nxp.com>
imx6ull is the derived SoC from imx6ul
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 | 72 +++++++++++++++++++++++++++-----
include/dt-bindings/clock/imx6ul-clock.h | 15 ++++++-
2 files changed, 75 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index d1d7787..75c35fb 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -64,6 +64,10 @@ 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 +106,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 +253,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[IMX6ULL_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[IMX6ULL_CLK_EPDC_PRE_SEL] = imx_clk_mux("epdc_pre_sel", base + 0x34, 15, 3, epdc_pre_sels, ARRAY_SIZE(epdc_pre_sels));
+ clks[IMX6ULL_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 +298,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[IMX6ULL_CLK_ESAI_PRED] = imx_clk_divider("esai_pred", "esai_sel", base + 0x28, 9, 3);
+ clks[IMX6ULL_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 +324,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[IMX6ULL_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 +341,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 +363,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[IMX6ULL_CLK_ESAI_EXTAL] = imx_clk_gate2_shared("esai_extal", "esai_podf", base + 0x70, 0, &share_count_esai);
+ clks[IMX6ULL_CLK_ESAI_IPG] = imx_clk_gate2_shared("esai_ipg", "ahb", base + 0x70, 0, &share_count_esai);
+ clks[IMX6ULL_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 +380,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[IMX6ULL_CLK_EPDC_ACLK] = imx_clk_gate2("epdc_aclk", "axi", base + 0x74, 4);
+ clks[IMX6ULL_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 +430,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);
@@ -441,7 +488,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[IMX6ULL_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..ee9f1a5 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 IMX6ULL_CLK_ESAI_PRED 225
+#define IMX6ULL_CLK_ESAI_PODF 226
+#define IMX6ULL_CLK_ESAI_EXTAL 227
+#define IMX6ULL_CLK_ESAI_MEM 228
+#define IMX6ULL_CLK_ESAI_IPG 229
+#define IMX6ULL_CLK_DCP_CLK 230
+#define IMX6ULL_CLK_EPDC_PRE_SEL 231
+#define IMX6ULL_CLK_EPDC_SEL 232
+#define IMX6ULL_CLK_EPDC_PODF 233
+#define IMX6ULL_CLK_EPDC_ACLK 234
+#define IMX6ULL_CLK_EPDC_PIX 235
+#define IMX6ULL_CLK_ESAI_SEL 236
+#define IMX6UL_CLK_END 237
#endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] arm64: Add DTS support for FSL's LS1012A SoC
From: Shawn Guo @ 2016-11-14 7:13 UTC (permalink / raw)
To: Harninder Rai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, oss-fOR+EgIDQEHk1uMJSBkQmQ,
Bhaskar Upadhaya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478715118-12848-1-git-send-email-harninder.rai-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 09, 2016 at 11:41:58PM +0530, Harninder Rai wrote:
> Add the device tree support for FSL LS1012A SoC.
Can we have a brief introduction of this SoC in commit log?
> Following levels of DTSI/DTS files have been created for the LS1012A
> SoC family:
>
> - fsl-ls1012a.dtsi:
> DTS-Include file for FSL LS1012A SoC.
>
> - fsl-ls1012a-frdm.dts:
> DTS file for FSL LS1012A FRDM board.
>
> - fsl-ls1012a-qds.dts:
> DTS file for FSL LS1012A QDS board.
>
> - fsl-ls1012a-rdb.dts:
> DTS file for FSL LS1012A RDB board.
>
> Signed-off-by: Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya-3arQi8VN3Tc@public.gmane.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 115 ++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 128 +++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 59 +++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 248 +++++++++++++++++++++
> 5 files changed, 553 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 6602718..39db645 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -1,3 +1,6 @@
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-frdm.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-qds.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1012a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-qds.dtb
It seems that the patch is not generated against mainline kernel. We do
not have fsl-ls1046a-qds.dtb target in mainline kernel.
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> new file mode 100644
> index 0000000..1f2da79
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> @@ -0,0 +1,115 @@
> +/*
> + * Device Tree file for Freescale LS1012A Freedom Board.
> + *
> + * Copyright 2016, Freescale Semiconductor
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +/dts-v1/;
> +
> +#include "fsl-ls1012a.dtsi"
> +
> +/ {
> + model = "LS1012A Freedom Board";
> + compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
> +
> + sys_mclk: clock-mclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + };
> +
> + reg_1p8v: regulator@0 {
Drop the unit-address from node name, and name it like regulator-1p8v.
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Headphone", "Headphone Jack",
> + "Speaker", "Speaker Ext",
> + "Line", "Line In Jack";
> + simple-audio-card,routing =
> + "MIC_IN", "Microphone Jack",
> + "Microphone Jack", "Mic Bias",
> + "LINE_IN", "Line In Jack",
> + "Headphone Jack", "HP_OUT",
> + "Speaker Ext", "LINE_OUT";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&sai2>;
> + frame-master;
> + bitclock-master;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&codec>;
> + frame-master;
> + bitclock-master;
> + system-clock-frequency = <25000000>;
> + };
> + };
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + codec: sgtl5000@a {
> + #sound-dai-cells = <0>;
> + compatible = "fsl,sgtl5000";
> + reg = <0xa>;
> + VDDA-supply = <®_1p8v>;
> + VDDIO-supply = <®_1p8v>;
> + clocks = <&sys_mclk>;
> + };
> +};
> +
> +&duart0 {
Please sort labeled nodes alphabetically.
> + status = "okay";
> +};
> +
> +&sai2 {
> + status = "okay";
> +};
<snip>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> new file mode 100644
> index 0000000..0bf5b64
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> @@ -0,0 +1,248 @@
> +/*
> + * Device Tree Include file for Freescale Layerscape-1012A family SoC.
> + *
> + * Copyright 2016, Freescale Semiconductor
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + compatible = "fsl,ls1012a";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + clocks = <&clockgen 1 0>;
> + #cooling-cells = <2>;
> + };
> + };
> +
> + sysclk: sysclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + clock-output-names = "sysclk";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + /* Physical Secure PPI */
> + interrupts = <1 13 IRQ_TYPE_LEVEL_LOW>,
> + /* Physical Non-Secure PPI */
> + <1 14 IRQ_TYPE_LEVEL_LOW>,
> + /* Virtual PPI */
> + <1 11 IRQ_TYPE_LEVEL_LOW>,
> + /* Hypervisor PPI */
> + <1 10 IRQ_TYPE_LEVEL_LOW>;
The following form should be easier for read.
interrupts = <1 13 IRQ_TYPE_LEVEL_LOW>, /* Physical Secure PPI */
<1 14 IRQ_TYPE_LEVEL_LOW>, /* Physical Non-Secure PPI */
<1 11 IRQ_TYPE_LEVEL_LOW>, /* Virtual PPI */
<1 10 IRQ_TYPE_LEVEL_LOW>; /* Hypervisor PPI */
> + };
> +
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupts = <0 106 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + gic: interrupt-controller@1400000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x0 0x1401000 0 0x1000>, /* GICD */
> + <0x0 0x1402000 0 0x2000>, /* GICC */
> + <0x0 0x1404000 0 0x2000>, /* GICH */
> + <0x0 0x1406000 0 0x2000>; /* GICV */
> + interrupts = <1 9 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + reboot {
> + compatible = "syscon-reboot";
> + regmap = <&dcfg>;
> + offset = <0xb0>;
> + mask = <0x02>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + clockgen: clocking@1ee1000 {
> + compatible = "fsl,ls1012a-clockgen";
> + reg = <0x0 0x1ee1000 0x0 0x1000>;
> + #clock-cells = <2>;
> + clocks = <&sysclk>;
> + };
> +
> + scfg: scfg@1570000 {
> + compatible = "fsl,ls1012a-scfg", "syscon";
> + reg = <0x0 0x1570000 0x0 0x10000>;
> + big-endian;
> + };
Please sort these nodes with unit-address in order of the address.
Shawn
> +
> + dcfg: dcfg@1ee0000 {
> + compatible = "fsl,ls1012a-dcfg",
> + "syscon";
> + reg = <0x0 0x1ee0000 0x0 0x10000>;
> + big-endian;
> + };
> +
> + i2c0: i2c@2180000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2180000 0x0 0x10000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 0>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@2190000 {
> + compatible = "fsl,vf610-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x2190000 0x0 0x10000>;
> + interrupts = <0 57 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 0>;
> + status = "disabled";
> + };
> +
> + duart0: serial@21c0500 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x00 0x21c0500 0x0 0x100>;
> + interrupts = <0 54 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clockgen 4 0>;
> + };
> +
> + duart1: serial@21c0600 {
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x00 0x21c0600 0x0 0x100>;
> + interrupts = <0 54 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clockgen 4 0>;
> + };
> +
> + gpio0: gpio@2300000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2300000 0x0 0x10000>;
> + interrupts = <0 66 IRQ_TYPE_LEVEL_LOW>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio1: gpio@2310000 {
> + compatible = "fsl,qoriq-gpio";
> + reg = <0x0 0x2310000 0x0 0x10000>;
> + interrupts = <0 67 IRQ_TYPE_LEVEL_LOW>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + wdog0: wdog@2ad0000 {
> + compatible = "fsl,ls1012a-wdt",
> + "fsl,imx21-wdt";
> + reg = <0x0 0x2ad0000 0x0 0x10000>;
> + interrupts = <0 83 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 0>;
> + big-endian;
> + };
> +
> + sai1: sai@2b50000 {
> + #sound-dai-cells = <0>;
> + compatible = "fsl,vf610-sai";
> + reg = <0x0 0x2b50000 0x0 0x10000>;
> + interrupts = <0 148 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 3>, <&clockgen 4 3>,
> + <&clockgen 4 3>, <&clockgen 4 3>;
> + clock-names = "bus", "mclk1", "mclk2", "mclk3";
> + dma-names = "tx", "rx";
> + dmas = <&edma0 1 47>,
> + <&edma0 1 46>;
> + status = "disabled";
> + };
> +
> + sai2: sai@2b60000 {
> + #sound-dai-cells = <0>;
> + compatible = "fsl,vf610-sai";
> + reg = <0x0 0x2b60000 0x0 0x10000>;
> + interrupts = <0 149 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 3>, <&clockgen 4 3>,
> + <&clockgen 4 3>, <&clockgen 4 3>;
> + clock-names = "bus", "mclk1", "mclk2", "mclk3";
> + dma-names = "tx", "rx";
> + dmas = <&edma0 1 45>,
> + <&edma0 1 44>;
> + status = "disabled";
> + };
> +
> + edma0: edma@2c00000 {
> + #dma-cells = <2>;
> + compatible = "fsl,vf610-edma";
> + reg = <0x0 0x2c00000 0x0 0x10000>,
> + <0x0 0x2c10000 0x0 0x10000>,
> + <0x0 0x2c20000 0x0 0x10000>;
> + interrupts = <0 103 IRQ_TYPE_LEVEL_LOW>,
> + <0 103 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "edma-tx", "edma-err";
> + dma-channels = <32>;
> + big-endian;
> + clock-names = "dmamux0", "dmamux1";
> + clocks = <&clockgen 4 3>,
> + <&clockgen 4 3>;
> + };
> +
> + sata: sata@3200000 {
> + compatible = "fsl,ls1012a-ahci";
> + reg = <0x0 0x3200000 0x0 0x10000>;
> + interrupts = <0 69 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&clockgen 4 0>;
> + };
> + };
> +};
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6q-cm-fx6: fix fec pinctrl
From: Shawn Guo @ 2016-11-14 7:34 UTC (permalink / raw)
To: christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, grinberg-UTxiZqZC01RS1MOuV/RT9w,
fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <6cd823201b9f4cde8de8eddc910f39ce-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
On Fri, Nov 11, 2016 at 04:59:38PM +0100, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote:
> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>
> According to the schematics of CompuLab's sbc-fx6 baseboard and the
> vendor devicetree GPIO_16 is *not* muxed to ENET_REF_CLK but to SPDIF_IN.
>
> Remove the wrong pinctrl setting.
>
> Fixes: 682d055e6ac5 ("ARM: dts: Add initial support for cm-fx6.")
> Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
Applied both, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Frank Rowand @ 2016-11-14 7:34 UTC (permalink / raw)
To: Hans de Goede, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5827CCC3.90003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Hans, Pantelis,
On 11/12/16 18:15, Frank Rowand wrote:
> On 11/04/16 07:42, Hans de Goede wrote:
>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>
>> Changesets are very powerful, but the lack of a helper API
>> makes using them cumbersome. Introduce a simple copy based
>> API that makes things considerably easier.
>>
>> To wit, adding a property using the raw API.
>>
>> struct property *prop;
>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>> prop->name = kstrdup("compatible");
>> prop->value = kstrdup("foo,bar");
>> prop->length = strlen(prop->value) + 1;
>> of_changeset_add_property(ocs, np, prop);
>>
>> while using the helper API
>>
>> of_changeset_add_property_string(ocs, np, "compatible",
>> "foo,bar");
>>
>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>> -Address review comments from:
>> https://www.spinics.net/lists/kernel/msg2252845.html
>
> That points to the May 9 version 1 patches from Pantelis (as expected),
> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
> seems to have disappeared?
>
> Pantelis then sent a version 2 set of the patches on May 16.
>
> Your version is a modification of the May 9 patches (as would be expected
> of a version 2). It is confusing to have two different version 2 patch
> sets. I don't have any brilliant ideas on how this patch set could have
> been named differently to avoid that confusion.
>
> The point of this little side-track is simply to note the existence of two
> different version 2 series so I won't be confused when I revisit this
> thread in the future.
>
>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>> -Remove (by manual inlining) these 2 static helpers:
>> __of_changeset_add_update_property_u32
>> __of_changeset_add_update_property_bool
>> -Remove the following exported helper method:
>> of_changeset_node_move_to
>
> Not all comments were addressed.
>
> There are some other changes made that are not noted in the changelog.
>
> I am still reading through the patches. I will reply again either with
> a reviewed-by or specific comments when I finish.
Replying here for the entire patchset (there was no patch 0 to reply to).
After reading through the patches, my reply is meta instead of specific
comments about the code.
There are very few users of change sets in tree. I do not see the need to
add these helpers until such users are likely to appear.
I would expect change sets to be _mostly_ used internally by the device tree
overlay framework, not directly by drivers. If change sets are an attractive
technology for drivers, I want to approach that usage very carefully to avoid
inappropriate use, which could be very difficult to reign in after the fact.
Even if helpers should be added, this seems to be an overly complex approach.
If the need for these helpers becomes apparent I can provide review comments
with the specifics about how it appears to be overly complex.
Can you please provide some more insights into the needs driving the desire
to have change set helpers and the expected use cases of them? Please put
your architect's hat on when replying to this question.
-Frank
>
> -Frank
>
>> ---
>> drivers/of/dynamic.c | 428 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/of.h | 135 ++++++++++++++++
>> 2 files changed, 563 insertions(+)
>
> < snip >
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters
From: Anurup M @ 2016-11-14 8:11 UTC (permalink / raw)
To: Mark Rutland
Cc: wangkefeng.wang, gabriele.paoloni, linux-doc, catalin.marinas,
will.deacon, linuxarm, xuwei5, guohanjun, tanxiaojun, f.fainelli,
corbet, krzk, rmk+kernel, devicetree, arnd, john.garry, shyju.pv,
robh+dt, anurup.m, linux-arm-kernel, zhangshaokun, sanil.kumar,
shiju.jose
In-Reply-To: <20161110191058.GE10137@leverpostej>
On Friday 11 November 2016 12:40 AM, Mark Rutland wrote:
> On Thu, Nov 03, 2016 at 01:42:03AM -0400, Anurup M wrote:
>> + do {
>> + /* Get count from individual L3C banks and sum them up */
>> + for (i = 0; i < num_banks; i++) {
>> + total_raw_count += hisi_read_l3c_counter(l3c_hwmod_data,
>> + idx, i);
>> + }
>> + prev_raw_count = local64_read(&hwc->prev_count);
>> +
>> + /*
>> + * As prev_raw_count is updated with average value of
>> + * L3 cache banks, we multiply it by no of banks and
>> + * compute the delta
>> + */
>> + delta = (total_raw_count - (prev_raw_count * num_banks)) &
>> + HISI_MAX_PERIOD;
>> +
>> + local64_add(delta, &event->count);
>> +
>> + /*
>> + * Divide by num of banks to get average count and
>> + * update prev_count with this value
>> + */
>> + avg_raw_count = total_raw_count / num_banks;
>> + } while (local64_cmpxchg(
>> + &hwc->prev_count, prev_raw_count, avg_raw_count) !=
>> + prev_raw_count);
> Please don't aggregate like this; expose separate PMUs instead.
>
> This is racy, and by averaging and multiplying we're making up and/or
> throwing away data.
>
> [...]
I have some concerns or doubts regarding registering each L3 cache bank
as a separate PMU.
1) Each L3 cache PMU has total 22 statistics events. So if registered as
a separate PMU, will it not
create multiple entries (with same event names) in event listing for
multiple PMU's. Is there a way
I can avoid this? or this is acceptable?
Or is it acceptable to register as a single PMU and add a config
parameter in the event listing to
identify the L3 cache bank. ex: event name will appear as
"hisi_l3c2/read_allocate,bank=?/".
And user can choose count from bank 0x01 as -e
"hisi_l3c2/read_allocate,bank=0x01/"
2) The individual count from each L3 cache bank is not meaningful. Only
aggregate count is useful.
Which is the accepted way to handle such counters?
a) Register each PMU instance as in hardware and handle the aggregation
in user space.
b) Register as single PMU, handle aggregation in driver.
>> + event_value = (val -
>> + HISI_HWEVENT_L3C_READ_ALLOCATE);
>> +
>> + /* Select the appropriate Event select register */
>> + if (idx > 3)
>> + reg_offset += 4;
>> +
>> + /* Value to write to event type register */
>> + val = event_value << (8 * idx);
>> +
> Please add helpers for these, and explain *why* the transformations are
> necessary.
Ok. shall add helpers.
>> + /* Find the djtag Identifier of the Unit */
>> + client = l3c_hwmod_data->client;
>> +
>> + /*
>> + * Set the event in L3C_EVENT_TYPEx Register
>> + * for all L3C banks
>> + */
> As above, it seems like you should expose a separate PMU per bank
> instead. That applies for all the other instances where you iterate over
> banks.
>
> [...]
>
>> + for (i = 0; i < l3c_hwmod_data->l3c_hwcfg.num_banks; i++) {
>> + module_id = l3c_hwmod_data->l3c_hwcfg.module_id[i];
>> + cfg_en = l3c_hwmod_data->l3c_hwcfg.bank_cfgen[i];
>> + ret = hisi_djtag_writereg(module_id,
>> + cfg_en,
>> + reg_offset,
>> + value,
>> + client);
>> + if (!ret)
>> + ret = value;
>> + }
> This is impossible to read. Please factor this into helpers such that
> you don't need this amount of indentation.
>
> Please do similarly elsewhere when you see this indentation pattern.
OK.
> [...]
>
>> +static int hisi_l3c_get_event_idx(struct hisi_pmu *pl3c_pmu)
>> +{
>> + struct hisi_l3c_data *l3c_hwmod_data = pl3c_pmu->hwmod_data;
>> + int event_idx;
>> +
>> + event_idx =
>> + find_first_zero_bit(
>> + l3c_hwmod_data->hisi_l3c_event_used_mask,
>> + pl3c_pmu->num_counters);
>> +
>> + if (event_idx == HISI_MAX_CFG_L3C_CNTR)
>> + return -EAGAIN;
>> +
>> + __set_bit(event_idx,
>> + l3c_hwmod_data->hisi_l3c_event_used_mask);
>> +
>> + return event_idx;
>> +}
> Please get rid of the weird hungarian notation (i.e. don't use 'p' as a
> prefix for pointers), and use temporary variables consistently, e.g.
Ok.
> static int hisi_l3c_get_event_idx(struct hisi_pmu *l3c_pmu)
> {
> struct hisi_l3c_data *l3c_hwmod_data = l3c_pmu->hwmod_data;
> unsigned long *used_mask = l3c_hwmod_data->hisi_l3c_event_used_mask;
> int num_counters = pl3c_pmu->num_counters
> int idx;
>
> idx = find_first_zero_bit(used_mask, num_counters);
> if (idx == num_counters)
> return -EAGAIN;
>
> set_bit(idx, used_mask);
>
> return idx;
> }
>
> [...]
>
>> + if (of_property_read_u32(node, "counter-reg",
>> + &pl3c_hwcfg->counter_reg0_off)) {
>> + dev_err(dev, "DT:Couldnot read counter-reg!\n");
>> + return -EINVAL;
>> + }
> Please use spaces in these messages.
>
> Otherwise, my comments on the binding apply here.
>
> [...]
>
>> +static int init_hisi_l3c_data(struct device *dev,
>> + struct hisi_pmu *pl3c_pmu,
>> + struct hisi_djtag_client *client)
>> +{
>> + struct hisi_l3c_data *l3c_hwmod_data = NULL;
>> + int ret;
>> +
>> + l3c_hwmod_data = kzalloc(sizeof(struct hisi_l3c_data),
>> + GFP_KERNEL);
> Use:
>
> l3c_hwmod_data = kzalloc(sizeof(*l3c_hwmod_data, GFP_KERNEL):
>
> [...]
Ok.
>> +static int hisi_pmu_l3c_dev_probe(struct hisi_djtag_client *client)
>> +{
>> + struct hisi_pmu *pl3c_pmu = NULL;
>> + struct device *dev = &client->dev;
>> + int ret;
>> +
>> + pl3c_pmu = hisi_pmu_alloc(dev);
>> + if (IS_ERR(pl3c_pmu))
>> + return PTR_ERR(pl3c_pmu);
> Why use error pointers for this?
>
> hisi_pmu_alloc() only ever returns ERR_PTR(-ENOMEM) if it failed to
> allocate.
>
> It's far simpler to have it pass on NULL there, and here do:
>
> pl3c_pmu = hisi_pmu_alloc(dev);
> if (!pl3c_pmu)
> return -ENOMEM;
>
> Please also s/pl3c_pmu/l3c_pmu/ here, and elsewhere throughout the
> driver. The 'p' only serves to make this harder to read.
>
> [...]
Ok.
>> + /* Register with perf PMU */
>> + pl3c_pmu->pmu = (struct pmu) {
>> + .name = pl3c_pmu->name,
>> + .task_ctx_nr = perf_invalid_context,
>> + .event_init = hisi_uncore_pmu_event_init,
>> + .add = hisi_uncore_pmu_add,
>> + .del = hisi_uncore_pmu_del,
>> + .start = hisi_uncore_pmu_start,
>> + .stop = hisi_uncore_pmu_stop,
>> + .read = hisi_uncore_pmu_read,
>> + };
> Please remove the comment above this.
>
> [...]
Ok.
>> +int hisi_uncore_pmu_event_init(struct perf_event *event)
>> +{
>> + int err;
>> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> This is undefined behaviour. This must be done *after* we check the
> event->pmu->type.
Ok. shall move it after the check.
>> +
>> + if (event->attr.type != event->pmu->type)
>> + return -ENOENT;
>> +
>> + /* we do not support sampling as the counters are all
>> + * shared by all CPU cores in a CPU die(SCCL). Also we
>> + * donot support attach to a task(per-process mode)
>> + */
>> + if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
>> + return -EOPNOTSUPP;
>> +
>> + /* counters do not have these bits */
>> + if (event->attr.exclude_user ||
>> + event->attr.exclude_kernel ||
>> + event->attr.exclude_host ||
>> + event->attr.exclude_guest ||
>> + event->attr.exclude_hv ||
>> + event->attr.exclude_idle)
>> + return -EINVAL;
>> +
>> + if (event->cpu < 0)
>> + return -EINVAL;
>> +
>> + event->cpu = cpumask_first(&phisi_pmu->cpu);
> You should also check the event grouping.
>
> Take a look at what we do in arch/arm/mm/cache-l2x0-pmu.c.
>
> [...]
>
Ok. I got it. Thanks for the reference.
As you had suggested earlier I am thinking to put all these checks to a
common lib function
and every uncore driver can call it.
Where can it be placed in source tree? Please suggest. shall add it.
>> +/*
>> + * Enable counter and set the counter to count
>> + * the event that we're interested in.
>> + */
>> +void hisi_uncore_pmu_enable_event(struct perf_event *event)
>> +{
>> + struct hw_perf_event *hwc = &event->hw;
>> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
>> +
>> + /* Disable the hardware event counting */
>> + if (phisi_pmu->ops->disable_counter)
>> + phisi_pmu->ops->disable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
> Why isn't the counter already disabled?
>
In Hisilicon SoC PMU for L3C, MN etc, the hip05/06/07 chips don't have
support for
stop/start individual counters.
The steps to start counting are
1) Stop counting(global control) in L3 cache AUCTRL register.
2) set event type in the event type register (Event code written to
3) Start counting (global control) in L3 cache AUCTRL register.
>> + /*
>> + * Set event (if destined for Hisilicon SoC counters).
>> + */
>> + if (phisi_pmu->ops->set_evtype)
>> + phisi_pmu->ops->set_evtype(phisi_pmu, GET_CNTR_IDX(hwc),
>> + hwc->config_base);
> Why isn't this done in the pmu::event_add callback?
hisi_uncore_pmu_enable_event is called by pmu::event_add.
The Call flow is pmu::event_add (hisi_uncore_pmu_add) -->
hisi_uncore_pmu_start --> hisi_uncore_pmu_enable_event
>> +
>> + /* Enable the hardware event counting */
>> + if (phisi_pmu->ops->enable_counter)
>> + phisi_pmu->ops->enable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
> This should be the only necessary part of this function.
>
>> +}
>> +
>> +void hisi_pmu_set_event_period(struct perf_event *event)
>> +{
>> + struct hw_perf_event *hwc = &event->hw;
>> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
>> +
>> + /*
>> + * The Hisilicon PMU counters have a period of 2^32. To account for the
>> + * possiblity of extreme interrupt latency we program for a period of
>> + * half that. Hopefully we can handle the interrupt before another 2^31
>> + * events occur and the counter overtakes its previous value.
>> + */
>> + u64 val = 1ULL << 31;
>> +
>> + local64_set(&hwc->prev_count, val);
>> +
>> + /* Write to the hardware event counter */
>> + phisi_pmu->ops->write_counter(phisi_pmu, hwc, val);
>> +}
>> +
>> +void hisi_uncore_pmu_start(struct perf_event *event, int flags)
>> +{
>> + struct hw_perf_event *hwc = &event->hw;
>> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
>> + struct hisi_pmu_hw_events *hw_events;
>> +
>> + hw_events = &phisi_pmu->hw_events;
>> +
>> + if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
>> + return;
>> +
>> + WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
>> + hwc->state = 0;
>> +
>> + if (phisi_pmu->ops->set_event_period)
>> + phisi_pmu->ops->set_event_period(event);
> When will this differ from hisi_pmu_set_event_period() above?
On some chips like hip05 and 06, the counter overflow handling with IRQ
cannot
be supported as the Hisilicon Mbigen V1 driver cannot be upstream. So I
am thinking
to have the counters start with value 0 and handle overflow with a poll
method from
a hrtimer. So this method (hisi_pmu::set_event_period) could be changed
in hisi_uncore(l3c/mn/ddrc).c.
Also for the DDRC PMU, the method (hisi_pmu::set_event_period) override
to handle continous counting.
In DDRC PMU, the initial counter value start from 0.
Please share your comments.
>> + if (flags & PERF_EF_RELOAD) {
>> + u64 prev_raw_count = local64_read(&hwc->prev_count);
>> +
>> + phisi_pmu->ops->write_counter(phisi_pmu, hwc,
>> + (u32)prev_raw_count);
>> + }
> If we always go through hisi_pmu_set_event_period(), this looks
> redundant.
>
>> +
>> + hisi_uncore_pmu_enable_event(event);
> There's no matching disable_event() call in this function, so this looks
> suspicious.
>
The hisi_uncore_pmu_enable_event includes
1) disable counting
2) set event type
3) enable counting
Sorry. I think this lead to confusion.
I shall split then to separate functions
a) disable_counter
b) set_event_type
c) enable_counter
>> + perf_event_update_userpage(event);
>> +}
>> +
>> +void hisi_uncore_pmu_stop(struct perf_event *event, int flags)
>> +{
>> + struct hw_perf_event *hwc = &event->hw;
>> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
>> +
>> + if (hwc->state & PERF_HES_UPTODATE)
>> + return;
> Why?
A mistake. Will remove it.
> [...]
>
>> +int hisi_uncore_common_fwprop_read(struct device *dev,
>> + struct hisi_pmu *phisi_pmu)
>> +{
>> + if (device_property_read_u32(dev, "num-events",
>> + &phisi_pmu->num_events)) {
>> + dev_err(dev, "Cant read num-events from DT!\n");
>> + return -EINVAL;
>> + }
> For consistency with the rest of the driver, and given there is no ACPI
> support, please use the of_property_* API here.
Ok.
Thanks,
Anurup
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v3 5/6] arm64: arch_timer: apci: Introduce a generic aquirk framework for erratum
From: Hanjun Guo @ 2016-11-14 8:12 UTC (permalink / raw)
To: Ding Tianhong, catalin.marinas, will.deacon, marc.zyngier,
mark.rutland, oss, devicetree, shawnguo, stuart.yoder,
linux-arm-kernel, linuxarm, hanjun.guo
In-Reply-To: <1478264794-14652-5-git-send-email-dingtianhong@huawei.com>
On 2016/11/4 21:06, Ding Tianhong wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce a general quirk framework for each timer erratum in ACPI,
> which use the oem information in GTDT table for platform specific erratums.
> The struct gtdt_arch_timer_fixup is introduced to record the oem
> information to match the quirk and handle the erratum.
>
> v3: Introduce a generic aquick framework for erratum in ACPI mode.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> drivers/clocksource/arm_arch_timer.c | 37 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 3d59af1..9bc93e5 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1068,6 +1068,40 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
> arch_timer_mem_init);
>
> #ifdef CONFIG_ACPI
> +struct gtdt_arch_timer_fixup {
> + char oem_id[ACPI_OEM_ID_SIZE];
> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> + u32 oem_revision;
> +
> + /* quirk handler for arch timer erratum */
> + void (*handler)(u32 erratum);
> + u32 erratum;
Hmm, I think we just use
void *context;
and we convert it in the platform specific handler, then this struct
can be reused for other type of quirks.
> +};
> +
> +/* note: this needs to be updated according to the doc of OEM ID
> + * and TABLE ID for different board.
> + */
> +struct gtdt_arch_timer_fixup arch_timer_quirks[] __initdata = {
> +};
> +
> +void __init arch_timer_acpi_quirks_handler(char *oem_id,
> + char *oem_table_id,
> + u32 oem_revision)
> +{
> + struct gtdt_arch_timer_fixup *quirks = arch_timer_quirks;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(arch_timer_quirks); i++, quirks++) {
> + if (!memcmp(quirks->oem_id, oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(quirks->oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE) &&
> + quirks->oem_revision == oem_revision) {
> + if (quirks->handler && quirks->erratum)
> + quirks->handler(quirks->erratum);
> + break;
we can't just break because we have multi quirks for different handlers.
Thanks
Hanjun
^ permalink raw reply
* Re: [PATCH v2 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: kbuild test robot @ 2016-11-14 8:15 UTC (permalink / raw)
Cc: kbuild-all, kishon, heiko, linux-kernel, linux-arm-kernel,
linux-rockchip, devicetree, robh+dt, frank.wang, huangtao,
dianders, briannorris, groeck, wulf
In-Reply-To: <1479106911-16049-3-git-send-email-wulf@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
Hi William,
[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v4.9-rc5 next-20161114]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/William-Wu/phy-rockchip-inno-usb2-correct-clk_ops-callback/20161114-150723
base: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/phy/phy-rockchip-inno-usb2.c: In function 'rockchip_usb2phy_clk480m_prepare':
>> drivers/phy/phy-rockchip-inno-usb2.c:169:3: error: too few arguments to function 'usleep_range'
usleep_range(1200);
^~~~~~~~~~~~
In file included from drivers/phy/phy-rockchip-inno-usb2.c:19:0:
include/linux/delay.h:48:6: note: declared here
void usleep_range(unsigned long min, unsigned long max);
^~~~~~~~~~~~
vim +/usleep_range +169 drivers/phy/phy-rockchip-inno-usb2.c
163 if (!property_enabled(rphy, &rphy->phy_cfg->clkout_ctl)) {
164 ret = property_enable(rphy, &rphy->phy_cfg->clkout_ctl, true);
165 if (ret)
166 return ret;
167
168 /* waitting for the clk become stable */
> 169 usleep_range(1200);
170 }
171
172 return 0;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56817 bytes --]
^ permalink raw reply
* [PATCH V4 1/8] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: DEVICETREE, Guenter Roeck, LINUX-KERNEL, LINUX-WATCHDOG,
Mark Rutland, Rob Herring, Wim Van Sebroeck
Cc: Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT, LINUX-PM,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Zhang Rui
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Add binding information for DA9062 and DA9061 watchdog.
Example bindings for both DA9062 and DA9061 devices are added. For
the DA9061 device, a fallback compatible line is added as a valid
combination of compatible strings.
The original binding for DA9062 (only) used to reside inside the
Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
The da9062-watchdog section was deleted in that file and replaced
with a link to the new DA9061/62 binding information stored in this
patch.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 2/9] to [PATCH V4 1/8]
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V1 02/10] to [PATCH V3 2/9]
- Each compatible line should be a valid combination of compatible
strings, alter DA9061 line to include the fall back compatible string
- Update the commit message to describe this change
- Add information about associated patches from this set without
describing them as being explicitly dependent on this binding
v1 -> v2
- Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated the patch description to be explicit about where parts of
this binding had originally been stored
- A second example for DA9061 is provided to highlight the use of a
fall-back compatible option for the DA9062 watchdog driver
Hi,
No code changes for this version PATCH V4. Added an Ack by Rob Herring
for PATCH V3.
As previously:
For the watchdog case: the DA9062 device driver is compatible with the
DA9061 and for this reason there is minimal change required to the DA9062
watchdog device driver. The example for the DA9061 watchdog shows the
use of a fall-back compatible string.
Other information:
The device driver from this patch set (associated with this binding) is
[PATCH V4 6/8] watchdog: da9061: watchdog driver
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
.../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
new file mode 100644
index 0000000..b935b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
@@ -0,0 +1,23 @@
+* Dialog Semiconductor DA9062/61 Watchdog Timer
+
+Required properties:
+
+- compatible: should be one of the following valid compatible string lines:
+ "dlg,da9061-watchdog", "dlg,da9062-watchdog"
+ "dlg,da9062-watchdog"
+
+Example: DA9062
+
+ pmic0: da9062@58 {
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+ };
+
+Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
+
+ pmic0: da9061@58 {
+ watchdog {
+ compatible = "dlg,da9061-watchdog", "dlg,da9062-watchdog";
+ };
+ };
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 2/8] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Rob Herring, Zhang Rui
Cc: Dmitry Torokhov, Guenter Roeck, LINUX-INPUT, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Lukasz Luba, Mark Brown,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Device tree binding information for DA9062 and DA9061 thermal junction
temperature monitor.
Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
a configurable polling period for over-temperature polling.
This patch also adds two examples, one for DA9062 and one for DA9061. The
DA9061 example uses a fall-back compatible string for the DA9062.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 3/9] to [PATCH V4 2/8]
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V2 03/10] to [PATCH V3 3/9]
- Changes suggested from other component reviews by Rob Herring:
- Each compatible line should be a valid combination of compatible
strings: alter DA9061 line to include the fall back compatible string
and update the commit message accordingly
- Add e-mail information about associated patches from this set without
describing them as being explicitly dependent on this binding
v1 -> v2
- Patch renamed from [PATCH V1 08/10] to [PATCH V2 03/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- A second example for DA9061 is provided to highlight the use of a
fall-back compatible option for the DA9062
Hi,
No code changes for this version PATCH V4. Added an Ack by Rob Herring
for PATCH V3.
As previously:
The device driver from this patch set (associated with this binding) is:
[PATCH V4 7/8] thermal: da9061: TJUNC temperature driver
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
.../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/da9062-thermal.txt b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
new file mode 100644
index 0000000..460ce68
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/da9062-thermal.txt
@@ -0,0 +1,37 @@
+* Dialog DA9062/61 TJUNC Thermal Module
+
+This module is part of the DA9061/DA9062. For more details about entire
+DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
+
+Junction temperature thermal module uses an interrupt signal to identify
+high THERMAL_TRIP_HOT temperatures for the PMIC device.
+
+Required properties:
+
+- compatible: should be one of the following valid compatible string lines:
+ "dlg,da9061-thermal", "dlg,da9062-thermal"
+ "dlg,da9062-thermal"
+
+Optional properties:
+
+- dlg,tjunc-temp-polling-period-ms : Specify the polling period, measured
+ in milliseconds, between thermal zone device update checks.
+
+Example: DA9062
+
+ pmic0: da9062@58 {
+ thermal {
+ compatible = "dlg,da9062-thermal";
+ dlg,tjunc-temp-polling-period-ms = <3000>;
+ };
+ };
+
+Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
+
+ pmic0: da9061@58 {
+ thermal {
+ compatible = "dlg,da9061-thermal", "dlg,da9062-thermal";
+ dlg,tjunc-temp-polling-period-ms = <3000>;
+ };
+ };
+
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 3/8] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: DEVICETREE, LINUX-KERNEL, Mark Rutland, Rob Herring
Cc: Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-INPUT,
LINUX-PM, LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Mark Brown,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Extend existing DA9062 binding information to include the DA9061 PMIC for
MFD core and regulators.
Add a da9062-onkey link to the existing onkey binding file.
Add a da9062-thermal link to the new temperature monitoring binding file.
Delete the da9062-watchdog section and replace it with a link to the new
DA9061/62 binding information file.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- Patch renamed from [PATCH V3 4/9] to [PATCH V4 3/8]
- Remove double newline spacing in text file
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V2 04/10] to [PATCH V3 4/9]
- Ensure binding description concentrates on the device not the
device driver
- Separate the DA9061 and DA9062 sub-device tables to distinguish
the difference between the two devices
- Update the commit message to describe this change
- Add e-mail information about associated patches from this set
without describing them as being explicitly dependent on this
binding
v1 -> v2
- Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
Hi,
Added an Ack from Rob Herring for the PATCH V3 version.
As previously:
Other information:
The device driver from this patch set (associated with this binding) is
- [PATCH V4 4/8] mfd: da9061: MFD core support
and also the following binding file changes:
- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V4 1/8] Binding for watchdog
- [PATCH V4 2/8] Binding for thermal
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
Documentation/devicetree/bindings/mfd/da9062.txt | 49 +++++++++++++++++-------
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
index 38802b5..c0a418c 100644
--- a/Documentation/devicetree/bindings/mfd/da9062.txt
+++ b/Documentation/devicetree/bindings/mfd/da9062.txt
@@ -1,22 +1,39 @@
* Dialog DA9062 Power Management Integrated Circuit (PMIC)
-DA9062 consists of a large and varied group of sub-devices:
+Product information for the DA9062 and DA9061 devices can be found here:
+- http://www.dialog-semiconductor.com/products/da9062
+- http://www.dialog-semiconductor.com/products/da9061
+
+The DA9062 PMIC consists of:
Device Supply Names Description
------ ------------ -----------
da9062-regulator : : LDOs & BUCKs
da9062-rtc : : Real-Time Clock
+da9062-onkey : : On Key
+da9062-watchdog : : Watchdog Timer
+da9062-thermal : : Thermal
+
+The DA9061 PMIC consists of:
+
+Device Supply Names Description
+------ ------------ -----------
+da9062-regulator : : LDOs & BUCKs
+da9062-onkey : : On Key
da9062-watchdog : : Watchdog Timer
+da9062-thermal : : Thermal
======
Required properties:
-- compatible : Should be "dlg,da9062".
+- compatible : Should be
+ "dlg,da9062" for DA9062
+ "dlg,da9061" for DA9061
- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
modified to match the chip's OTP settings).
- interrupt-parent : Specifies the reference to the interrupt controller for
- the DA9062.
+ the DA9062 or DA9061.
- interrupts : IRQ line information.
- interrupt-controller
@@ -25,8 +42,8 @@ further information on IRQ bindings.
Sub-nodes:
-- regulators : This node defines the settings for the LDOs and BUCKs. The
- DA9062 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+ The DA9062 regulators are bound using their names listed below:
buck1 : BUCK_1
buck2 : BUCK_2
@@ -37,19 +54,29 @@ Sub-nodes:
ldo3 : LDO_3
ldo4 : LDO_4
+ The DA9061 regulators are bound using their names listed below:
+
+ buck1 : BUCK_1
+ buck2 : BUCK_2
+ buck3 : BUCK_3
+ ldo1 : LDO_1
+ ldo2 : LDO_2
+ ldo3 : LDO_3
+ ldo4 : LDO_4
+
The component follows the standard regulator framework and the bindings
details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
-
- rtc : This node defines settings required for the Real-Time Clock associated
with the DA9062. There are currently no entries in this binding, however
compatible = "dlg,da9062-rtc" should be added if a node is created.
-- watchdog: This node defines the settings for the watchdog driver associated
- with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
- if a node is created.
+- onkey : See ../input/da9062-onkey.txt
+
+- watchdog: See ../watchdog/da9062-watchdog.txt
+- thermal : See ../thermal/da9062-thermal.txt
Example:
@@ -64,10 +91,6 @@ Example:
compatible = "dlg,da9062-rtc";
};
- watchdog {
- compatible = "dlg,da9062-watchdog";
- };
-
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 5/8] regulator: da9061: BUCK and LDO regulator driver
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: LINUX-KERNEL, Liam Girdwood, Mark Brown
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Lee Jones, Mark Rutland,
Rob Herring, Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <cover.1479111766.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Regulator support for the DA9061 is added into the DA9062 regulator driver.
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].
The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.
Kconfig is updated to reflect support for DA9061 and DA9062 regulators.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.8
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 6/9] to [PATCH V4 5/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 06/10] to [PATCH V3 6/9]
- Added Ack from Mark Brown
v1 -> v2
- Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated header to use DA9061 and DA9062
Hi,
No code changes for this version PATCH V4.
As previously:
These changes depend on a header file provided as part of an earlier
patch [PATCH V4 4/8] from this set. The regulator probe() switches on
the chip_type which uses enum da9062_compatible_types in core.h from this
patch.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 301 +++++++++++++++++++++++++++++++++--
2 files changed, 292 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6c88e31..c4f678fe 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -188,11 +188,11 @@ config REGULATOR_DA9055
will be called da9055-regulator.
config REGULATOR_DA9062
- tristate "Dialog Semiconductor DA9062 regulators"
+ tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
This driver can also be built as a module. If so, the module
will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c
index 0638c8b..931be68 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,5 +1,5 @@
/*
- * da9062-regulator.c - REGULATOR device driver for DA9062
+ * Regulator device driver for DA9061 and DA9062.
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -28,6 +28,17 @@
/* Regulator IDs */
enum {
+ DA9061_ID_BUCK1,
+ DA9061_ID_BUCK2,
+ DA9061_ID_BUCK3,
+ DA9061_ID_LDO1,
+ DA9061_ID_LDO2,
+ DA9061_ID_LDO3,
+ DA9061_ID_LDO4,
+ DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
/* Regulator operations */
-/* Current limits array (in uA) BUCK1 and BUCK3.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_a_limits[] = {
500000, 600000, 700000, 800000, 900000, 1000000, 1100000, 1200000,
1300000, 1400000, 1500000, 1600000, 1700000, 1800000, 1900000, 2000000
};
-/* Current limits array (in uA) for BUCK2.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_b_limits[] = {
1500000, 1600000, 1700000, 1800000, 1900000, 2000000, 2100000, 2200000,
2300000, 2400000, 2500000, 2600000, 2700000, 2800000, 2900000, 3000000
@@ -405,8 +422,254 @@ static const struct regulator_ops da9062_ldo_ops = {
.set_suspend_mode = da9062_ldo_set_suspend_mode,
};
-/* Regulator information */
-static const struct da9062_regulator_info local_regulator_info[] = {
+/* DA9061 Regulator information */
+static const struct da9062_regulator_info local_da9061_regulator_info[] = {
+ {
+ .desc.id = DA9061_ID_BUCK1,
+ .desc.name = "DA9061 BUCK1",
+ .desc.of_match = of_match_ptr("buck1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (300) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1570) - (300))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK1_CONT,
+ .desc.enable_mask = DA9062AA_BUCK1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK1_A,
+ .desc.vsel_mask = DA9062AA_VBUCK1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK1_A,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK1_B,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK1_B,
+ .mode = REG_FIELD(DA9062AA_BUCK1_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK1_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK1_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_C,
+ __builtin_ffs((int)DA9062AA_BUCK1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK2,
+ .desc.name = "DA9061 BUCK2",
+ .desc.of_match = of_match_ptr("buck2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (800) * 1000,
+ .desc.uV_step = (20) * 1000,
+ .desc.n_voltages = ((3340) - (800))/(20) + 1,
+ .current_limits = da9062_buck_b_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_b_limits),
+ .desc.enable_reg = DA9062AA_BUCK3_CONT,
+ .desc.enable_mask = DA9062AA_BUCK3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK3_A,
+ .desc.vsel_mask = DA9062AA_VBUCK3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK3_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK3_B,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK3_B,
+ .mode = REG_FIELD(DA9062AA_BUCK3_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK3_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK3_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK3,
+ .desc.name = "DA9061 BUCK3",
+ .desc.of_match = of_match_ptr("buck3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (530) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1800) - (530))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK4_CONT,
+ .desc.enable_mask = DA9062AA_BUCK4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK4_A,
+ .desc.vsel_mask = DA9062AA_VBUCK4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK4_A,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK4_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK4_B,
+ .mode = REG_FIELD(DA9062AA_BUCK4_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK4_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK4_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO1,
+ .desc.name = "DA9061 LDO1",
+ .desc.of_match = of_match_ptr("ldo1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO1_CONT,
+ .desc.enable_mask = DA9062AA_LDO1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO1_A,
+ .desc.vsel_mask = DA9062AA_VLDO1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO1_A,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO1_B,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO1_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO1_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO2,
+ .desc.name = "DA9061 LDO2",
+ .desc.of_match = of_match_ptr("ldo2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (600))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO2_CONT,
+ .desc.enable_mask = DA9062AA_LDO2_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO2_A,
+ .desc.vsel_mask = DA9062AA_VLDO2_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO2_A,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO2_B,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO2_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO2_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO2_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO2_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO3,
+ .desc.name = "DA9061 LDO3",
+ .desc.of_match = of_match_ptr("ldo3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO3_CONT,
+ .desc.enable_mask = DA9062AA_LDO3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO3_A,
+ .desc.vsel_mask = DA9062AA_VLDO3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO3_A,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO3_B,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO3_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO3_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO4,
+ .desc.name = "DA9061 LDO4",
+ .desc.of_match = of_match_ptr("ldo4"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO4_CONT,
+ .desc.enable_mask = DA9062AA_LDO4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO4_A,
+ .desc.vsel_mask = DA9062AA_VLDO4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO4_A,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO4_B,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO4_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO4_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_ILIM_MASK)) - 1),
+ },
+};
+
+/* DA9062 Regulator information */
+static const struct da9062_regulator_info local_da9062_regulator_info[] = {
{
.desc.id = DA9062_ID_BUCK1,
.desc.name = "DA9062 BUCK1",
@@ -727,17 +990,33 @@ static int da9062_regulator_probe(struct platform_device *pdev)
struct da9062_regulators *regulators;
struct da9062_regulator *regl;
struct regulator_config config = { };
+ const struct da9062_regulator_info *rinfo;
int irq, n, ret;
size_t size;
+ int max_regulators;
+
+ switch (chip->chip_type) {
+ case COMPAT_TYPE_DA9061:
+ max_regulators = DA9061_MAX_REGULATORS;
+ rinfo = local_da9061_regulator_info;
+ break;
+ case COMPAT_TYPE_DA9062:
+ max_regulators = DA9062_MAX_REGULATORS;
+ rinfo = local_da9062_regulator_info;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
/* Allocate memory required by usable regulators */
size = sizeof(struct da9062_regulators) +
- DA9062_MAX_REGULATORS * sizeof(struct da9062_regulator);
+ max_regulators * sizeof(struct da9062_regulator);
regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
if (!regulators)
return -ENOMEM;
- regulators->n_regulators = DA9062_MAX_REGULATORS;
+ regulators->n_regulators = max_regulators;
platform_set_drvdata(pdev, regulators);
n = 0;
@@ -745,7 +1024,7 @@ static int da9062_regulator_probe(struct platform_device *pdev)
/* Initialise regulator structure */
regl = ®ulators->regulator[n];
regl->hw = chip;
- regl->info = &local_regulator_info[n];
+ regl->info = &rinfo[n];
regl->desc = regl->info->desc;
regl->desc.type = REGULATOR_VOLTAGE;
regl->desc.owner = THIS_MODULE;
@@ -836,6 +1115,6 @@ module_exit(da9062_regulator_cleanup);
/* Module information */
MODULE_AUTHOR("S Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>");
-MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062");
+MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062 and DA9061");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da9062-regulators");
--
end-of-patch for PATCH V4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V4 6/8] watchdog: da9062/61: watchdog driver
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: Guenter Roeck, LINUX-KERNEL, LINUX-WATCHDOG, Wim Van Sebroeck
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT,
LINUX-PM, Lee Jones, Liam Girdwood, Mark Brown, Mark Rutland,
Rob Herring, Support Opensource, Zhang Rui
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
The of_device_id match array is added to support "dlg,da9062-watchdog"
as a valid .compatible string. A MODULE_DEVICE_TABLE() macro is added.
This patch assumes the use of a DA9062 fallback compatible string for the
DTS to pick up the DA9062 device driver for use with the DA9061 watchdog
hardware
Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.
Kconfig is updated to reflect support for DA9061/62.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 7/9] to [PATCH V4 6/8]
- Added reviewed by Guenter Roeck
v2 -> v3
- Patch renamed from [PATCH V2 08/10] to [PATCH V3 7/9]
- Removal of match->data and of_match_node search. There is only one
compatible string now. and delete the .data = &da9062_watchdog_info
association in the struct of_device_id compatible table.
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions:
da9062_wdt.ko platform:da9062_watchdog
of:N*T*Cdlg,da9062_watchdogC*
of:N*T*Cdlg,da9062_watchdog
v1 -> v2
- Patch renamed from [PATCH V1 04/10] to [PATCH V2 08/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Removal of the DA9061 compatible entries for this device driver.
- Additional explanation in the patch description for the use of a
fall-back compatible DTS string
Hi,
There are no code changes to this patch compared to the previous
submission in [PATCH V3 7/9]. The differences are in the patch version
rename and Reviewed-by tag.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/watchdog/Kconfig | 4 ++--
drivers/watchdog/da9062_wdt.c | 12 ++++++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 1bffe00..d6b4088 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -104,11 +104,11 @@ config DA9063_WATCHDOG
This driver can be built as a module. The module name is da9063_wdt.
config DA9062_WATCHDOG
- tristate "Dialog DA9062 Watchdog"
+ tristate "Dialog DA9062/61 Watchdog"
depends on MFD_DA9062
select WATCHDOG_CORE
help
- Support for the watchdog in the DA9062 PMIC.
+ Support for the watchdog in the DA9062 and DA9061 PMICs.
This driver can be built as a module. The module name is da9062_wdt.
diff --git a/drivers/watchdog/da9062_wdt.c b/drivers/watchdog/da9062_wdt.c
index 7386111..a02cee6 100644
--- a/drivers/watchdog/da9062_wdt.c
+++ b/drivers/watchdog/da9062_wdt.c
@@ -1,5 +1,5 @@
/*
- * da9062_wdt.c - WDT device driver for DA9062
+ * Watchdog device driver for DA9062 and DA9061 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -188,6 +188,13 @@ static const struct watchdog_ops da9062_watchdog_ops = {
.set_timeout = da9062_wdt_set_timeout,
};
+static const struct of_device_id da9062_compatible_id_table[] = {
+ { .compatible = "dlg,da9062-watchdog", },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_id_table);
+
static int da9062_wdt_probe(struct platform_device *pdev)
{
int ret;
@@ -244,11 +251,12 @@ static struct platform_driver da9062_wdt_driver = {
.remove = da9062_wdt_remove,
.driver = {
.name = "da9062-watchdog",
+ .of_match_table = da9062_compatible_id_table,
},
};
module_platform_driver(da9062_wdt_driver);
MODULE_AUTHOR("S Twiss <stwiss.opensource@diasemi.com>");
-MODULE_DESCRIPTION("WDT device driver for Dialog DA9062");
+MODULE_DESCRIPTION("WDT device driver for Dialog DA9062 and DA9061");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da9062-watchdog");
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 4/8] mfd: da9061: MFD core support
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: LINUX-KERNEL, Lee Jones
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck,
Zhang Rui
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
MFD support for DA9061 is provided as part of the DA9062 device driver.
The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.
The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.
A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.
The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
- Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
them with DEFINE_RES_IRQ_NAMED().
- Removed whitespace
- Reverted change for badly defined mfd_cell da9062_devs of_compatible
string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
v1 -> v2
- Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Fixed typo in the commit message "readble" to "readable"
- Removed the explicit cross-check to decide if there is a conflict
between the device tree compatible string and the hardware definition.
This patch assumes the device tree is correctly written and therefore
removes the need for a hardware/DT sanity check.
- Removed extra semicolon in drivers/mfd/da9062-core.c:877
- Re-write compatible entries into numerical order
Lee,
Changes as described in the version history above.
As previously:
This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 424 +++++++++++++++++++++++++++++++++--
include/linux/mfd/da9062/core.h | 27 ++-
include/linux/mfd/da9062/registers.h | 2 +
4 files changed, 439 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..533798a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -236,13 +236,14 @@ config MFD_DA9055
called "da9055"
config MFD_DA9062
- tristate "Dialog Semiconductor DA9062 PMIC Support"
+ tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
This includes the I2C driver and core APIs.
Additional drivers must be enabled in order to use the functionality
of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..4b5f70f 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,5 +1,5 @@
/*
- * Core, IRQ and I2C device driver for DA9062 PMIC
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -30,6 +30,70 @@
#define DA9062_REG_EVENT_B_OFFSET 1
#define DA9062_REG_EVENT_C_OFFSET 2
+static struct regmap_irq da9061_irqs[] = {
+ /* EVENT A */
+ [DA9061_IRQ_ONKEY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_NONKEY_MASK,
+ },
+ [DA9061_IRQ_WDG_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_WDG_WARN_MASK,
+ },
+ [DA9061_IRQ_SEQ_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_SEQ_RDY_MASK,
+ },
+ /* EVENT B */
+ [DA9061_IRQ_TEMP] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_TEMP_MASK,
+ },
+ [DA9061_IRQ_LDO_LIM] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_LDO_LIM_MASK,
+ },
+ [DA9061_IRQ_DVC_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_DVC_RDY_MASK,
+ },
+ [DA9061_IRQ_VDD_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_VDD_WARN_MASK,
+ },
+ /* EVENT C */
+ [DA9061_IRQ_GPI0] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI0_MASK,
+ },
+ [DA9061_IRQ_GPI1] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI1_MASK,
+ },
+ [DA9061_IRQ_GPI2] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI2_MASK,
+ },
+ [DA9061_IRQ_GPI3] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI3_MASK,
+ },
+ [DA9061_IRQ_GPI4] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI4_MASK,
+ },
+};
+
+static struct regmap_irq_chip da9061_irq_chip = {
+ .name = "da9061-irq",
+ .irqs = da9061_irqs,
+ .num_irqs = DA9061_NUM_IRQ,
+ .num_regs = 3,
+ .status_base = DA9062AA_EVENT_A,
+ .mask_base = DA9062AA_IRQ_MASK_A,
+ .ack_base = DA9062AA_EVENT_A,
+};
+
static struct regmap_irq da9062_irqs[] = {
/* EVENT A */
[DA9062_IRQ_ONKEY] = {
@@ -102,6 +166,57 @@ static struct regmap_irq_chip da9062_irq_chip = {
.ack_base = DA9062AA_EVENT_A,
};
+static struct resource da9061_core_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_VDD_WARN, "VDD_WARN"),
+};
+
+static struct resource da9061_regulators_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_LDO_LIM, "LDO_LIM"),
+};
+
+static struct resource da9061_thermal_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_TEMP, "THERMAL"),
+};
+
+static struct resource da9061_wdt_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_WDG_WARN, "WD_WARN"),
+};
+
+static struct resource da9061_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_ONKEY, "ONKEY"),
+};
+
+static const struct mfd_cell da9061_devs[] = {
+ {
+ .name = "da9061-core",
+ .num_resources = ARRAY_SIZE(da9061_core_resources),
+ .resources = da9061_core_resources,
+ },
+ {
+ .name = "da9062-regulators",
+ .num_resources = ARRAY_SIZE(da9061_regulators_resources),
+ .resources = da9061_regulators_resources,
+ },
+ {
+ .name = "da9061-watchdog",
+ .num_resources = ARRAY_SIZE(da9061_wdt_resources),
+ .resources = da9061_wdt_resources,
+ .of_compatible = "dlg,da9061-watchdog",
+ },
+ {
+ .name = "da9061-thermal",
+ .num_resources = ARRAY_SIZE(da9061_thermal_resources),
+ .resources = da9061_thermal_resources,
+ .of_compatible = "dlg,da9061-thermal",
+ },
+ {
+ .name = "da9061-onkey",
+ .num_resources = ARRAY_SIZE(da9061_onkey_resources),
+ .resources = da9061_onkey_resources,
+ .of_compatible = "dlg,da9061-onkey",
+ },
+};
+
static struct resource da9062_core_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
};
@@ -200,7 +315,8 @@ static int da9062_clear_fault_log(struct da9062 *chip)
static int da9062_get_device_type(struct da9062 *chip)
{
- int device_id, variant_id, variant_mrc;
+ int device_id, variant_id, variant_mrc, variant_vrc;
+ char *type;
int ret;
ret = regmap_read(chip->regmap, DA9062AA_DEVICE_ID, &device_id);
@@ -219,9 +335,23 @@ static int da9062_get_device_type(struct da9062 *chip)
return -EIO;
}
+ variant_vrc = (variant_id & DA9062AA_VRC_MASK) >> DA9062AA_VRC_SHIFT;
+
+ switch (variant_vrc) {
+ case DA9062_PMIC_VARIANT_VRC_DA9061:
+ type = "DA9061";
+ break;
+ case DA9062_PMIC_VARIANT_VRC_DA9062:
+ type = "DA9062";
+ break;
+ default:
+ type = "Unknown";
+ break;
+ }
+
dev_info(chip->dev,
- "Device detected (device-ID: 0x%02X, var-ID: 0x%02X)\n",
- device_id, variant_id);
+ "Device detected (device-ID: 0x%02X, var-ID: 0x%02X, %s)\n",
+ device_id, variant_id, type);
variant_mrc = (variant_id & DA9062AA_MRC_MASK) >> DA9062AA_MRC_SHIFT;
@@ -234,6 +364,234 @@ static int da9062_get_device_type(struct da9062 *chip)
return ret;
}
+static const struct regmap_range da9061_aa_readable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_INTERFACE,
+ .range_max = DA9062AA_CONFIG_E,
+ }, {
+ .range_min = DA9062AA_CONFIG_G,
+ .range_max = DA9062AA_CONFIG_K,
+ }, {
+ .range_min = DA9062AA_CONFIG_M,
+ .range_max = DA9062AA_CONFIG_M,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ }, {
+ .range_min = DA9062AA_DEVICE_ID,
+ .range_max = DA9062AA_CONFIG_ID,
+ },
+};
+
+static const struct regmap_range da9061_aa_writeable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_PAGE_CON,
+ }, {
+ .range_min = DA9062AA_FAULT_LOG,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ },
+};
+
+static const struct regmap_range da9061_aa_volatile_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_CONTROL_B,
+ }, {
+ .range_min = DA9062AA_CONTROL_E,
+ .range_max = DA9062AA_CONTROL_F,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_SEQ,
+ },
+};
+
+static const struct regmap_access_table da9061_aa_readable_table = {
+ .yes_ranges = da9061_aa_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_readable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_writeable_table = {
+ .yes_ranges = da9061_aa_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_writeable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_volatile_table = {
+ .yes_ranges = da9061_aa_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_volatile_ranges),
+};
+
+static const struct regmap_range_cfg da9061_range_cfg[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_CONFIG_ID,
+ .selector_reg = DA9062AA_PAGE_CON,
+ .selector_mask = 1 << DA9062_I2C_PAGE_SEL_SHIFT,
+ .selector_shift = DA9062_I2C_PAGE_SEL_SHIFT,
+ .window_start = 0,
+ .window_len = 256,
+ }
+};
+
+static struct regmap_config da9061_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .ranges = da9061_range_cfg,
+ .num_ranges = ARRAY_SIZE(da9061_range_cfg),
+ .max_register = DA9062AA_CONFIG_ID,
+ .cache_type = REGCACHE_RBTREE,
+ .rd_table = &da9061_aa_readable_table,
+ .wr_table = &da9061_aa_writeable_table,
+ .volatile_table = &da9061_aa_volatile_table,
+};
+
static const struct regmap_range da9062_aa_readable_ranges[] = {
{
.range_min = DA9062AA_PAGE_CON,
@@ -456,17 +814,38 @@ static struct regmap_config da9062_regmap_config = {
.volatile_table = &da9062_aa_volatile_table,
};
+static const struct of_device_id da9062_dt_ids[] = {
+ { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061, },
+ { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da9062_dt_ids);
+
static int da9062_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct da9062 *chip;
+ const struct of_device_id *match;
unsigned int irq_base;
+ const struct mfd_cell *cell;
+ const struct regmap_irq_chip *irq_chip;
+ const struct regmap_config *config;
+ int cell_num;
int ret;
chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
+ if (i2c->dev.of_node) {
+ match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
+ if (!match)
+ return -EINVAL;
+
+ chip->chip_type = (int)match->data;
+ } else
+ chip->chip_type = id->driver_data;
+
i2c_set_clientdata(i2c, chip);
chip->dev = &i2c->dev;
@@ -475,7 +854,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
return -EINVAL;
}
- chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+ switch (chip->chip_type) {
+ case(COMPAT_TYPE_DA9061):
+ cell = da9061_devs;
+ cell_num = ARRAY_SIZE(da9061_devs);
+ irq_chip = &da9061_irq_chip;
+ config = &da9061_regmap_config;
+ break;
+ case(COMPAT_TYPE_DA9062):
+ cell = da9062_devs;
+ cell_num = ARRAY_SIZE(da9062_devs);
+ irq_chip = &da9062_irq_chip;
+ config = &da9062_regmap_config;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
+
+ chip->regmap = devm_regmap_init_i2c(i2c, config);
if (IS_ERR(chip->regmap)) {
ret = PTR_ERR(chip->regmap);
dev_err(chip->dev, "Failed to allocate register map: %d\n",
@@ -493,7 +890,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
- -1, &da9062_irq_chip,
+ -1, irq_chip,
&chip->regmap_irq);
if (ret) {
dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
@@ -503,8 +900,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
- ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
- ARRAY_SIZE(da9062_devs), NULL, irq_base,
+ ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
+ cell_num, NULL, irq_base,
NULL);
if (ret) {
dev_err(chip->dev, "Cannot register child devices\n");
@@ -526,17 +923,12 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id da9062_i2c_id[] = {
- { "da9062", 0 },
+ { "da9061", COMPAT_TYPE_DA9061 },
+ { "da9062", COMPAT_TYPE_DA9062 },
{ },
};
MODULE_DEVICE_TABLE(i2c, da9062_i2c_id);
-static const struct of_device_id da9062_dt_ids[] = {
- { .compatible = "dlg,da9062", },
- { }
-};
-MODULE_DEVICE_TABLE(of, da9062_dt_ids);
-
static struct i2c_driver da9062_i2c_driver = {
.driver = {
.name = "da9062",
@@ -549,6 +941,6 @@ static struct i2c_driver da9062_i2c_driver = {
module_i2c_driver(da9062_i2c_driver);
-MODULE_DESCRIPTION("Core device driver for Dialog DA9062");
+MODULE_DESCRIPTION("Core device driver for Dialog DA9061 and DA9062");
MODULE_AUTHOR("Steve Twiss <stwiss.opensource@diasemi.com>");
MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/da9062/core.h b/include/linux/mfd/da9062/core.h
index 376ba84..199c524 100644
--- a/include/linux/mfd/da9062/core.h
+++ b/include/linux/mfd/da9062/core.h
@@ -18,7 +18,31 @@
#include <linux/interrupt.h>
#include <linux/mfd/da9062/registers.h>
-/* Interrupts */
+enum da9062_compatible_types {
+ COMPAT_TYPE_DA9061 = 1,
+ COMPAT_TYPE_DA9062,
+};
+
+enum da9061_irqs {
+ /* IRQ A */
+ DA9061_IRQ_ONKEY,
+ DA9061_IRQ_WDG_WARN,
+ DA9061_IRQ_SEQ_RDY,
+ /* IRQ B*/
+ DA9061_IRQ_TEMP,
+ DA9061_IRQ_LDO_LIM,
+ DA9061_IRQ_DVC_RDY,
+ DA9061_IRQ_VDD_WARN,
+ /* IRQ C */
+ DA9061_IRQ_GPI0,
+ DA9061_IRQ_GPI1,
+ DA9061_IRQ_GPI2,
+ DA9061_IRQ_GPI3,
+ DA9061_IRQ_GPI4,
+
+ DA9061_NUM_IRQ,
+};
+
enum da9062_irqs {
/* IRQ A */
DA9062_IRQ_ONKEY,
@@ -45,6 +69,7 @@ struct da9062 {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irq;
+ enum da9062_compatible_types chip_type;
};
#endif /* __MFD_DA9062_CORE_H__ */
diff --git a/include/linux/mfd/da9062/registers.h b/include/linux/mfd/da9062/registers.h
index 97790d1..4457fdc 100644
--- a/include/linux/mfd/da9062/registers.h
+++ b/include/linux/mfd/da9062/registers.h
@@ -18,6 +18,8 @@
#define DA9062_PMIC_DEVICE_ID 0x62
#define DA9062_PMIC_VARIANT_MRC_AA 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9061 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9062 0x02
#define DA9062_I2C_PAGE_SEL_SHIFT 1
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 8/8] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, Mark Rutland,
Rob Herring, Wim Van Sebroeck, Zhang Rui
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Hi,
Dialog Semiconductor support would like to add to the MAINTAINERS search
terms. This update will allow us to follow files for device tree bindings
and source code relating to input onkey drivers, chip thermal monitoring
and watchdog timers.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 9/9] to [PATCH V4 8/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 10/10] to [PATCH V3 9/9]
v1 -> v2
- NO CODE CHANGE
Hi,
This patch depends on acceptance of the following from this patch set:
- [PATCH V4 7/8] PMIC temperature monitoring
and also from the following binding file changes:
- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V4 1/8] Binding for watchdog
- [PATCH V4 2/8] Binding for thermal
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f593300..a7fd809 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3752,7 +3752,10 @@ W: http://www.dialog-semiconductor.com/products
S: Supported
F: Documentation/hwmon/da90??
F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
F: Documentation/devicetree/bindings/regulator/da92*.txt
+F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
F: Documentation/devicetree/bindings/sound/da[79]*.txt
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
@@ -3767,6 +3770,7 @@ F: drivers/power/da9052-battery.c
F: drivers/power/da91??-*.c
F: drivers/regulator/da903x.c
F: drivers/regulator/da9???-regulator.[ch]
+F: drivers/thermal/da90??-thermal.c
F: drivers/rtc/rtc-da90??.c
F: drivers/video/backlight/da90??_bl.c
F: drivers/watchdog/da90??_wdt.c
--
end-of-patch for PATCH V4
^ permalink raw reply related
* [PATCH V4 0/8] da9061: DA9061 driver submission
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG, Lee Jones,
Liam Girdwood, Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Steve Twiss, Wim Van Sebroeck, Zhang Rui
Cc: Support Opensource
From: Steve Twiss <stwiss.opensource@diasemi.com>
This patch set adds support for the Dialog DA9061 Power Management IC.
Support is made by altering the existing DA9062 device driver, where
appropriate.
In this patch set the following is provided:
[PATCH V4 1/8] Binding for watchdog
[PATCH V4 2/8] Binding for thermal supervisor
[PATCH V4 3/8] Binding for MFD and regulators
[PATCH V4 4/8] MFD core support
[PATCH V4 5/8] BUCKs and LDOs
[PATCH V4 6/8] Watchdog
[PATCH V4 7/8] PMIC temperature monitoring
[PATCH V4 8/8] MAINTAINERS update
Some previous patches from this set have been applied already:
Onkey binding -- https://lkml.org/lkml/2016/11/8/958
Onkey driver -- https://lkml.org/lkml/2016/10/26/1169
This patch applies against linux-next and v4.8
Thank you,
Steve Twiss, Dialog Semiconductor Ltd.
Steve Twiss (8):
Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
Documentation: devicetree: thermal: da9062/61 TJUNC temperature
binding
Documentation: devicetree: mfd: da9062/61 MFD binding
mfd: da9061: MFD core support
regulator: da9061: BUCK and LDO regulator driver
watchdog: da9062/61: watchdog driver
thermal: da9062/61: Thermal junction temperature monitoring driver
MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search
terms
Documentation/devicetree/bindings/mfd/da9062.txt | 49 ++-
.../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++
.../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++
MAINTAINERS | 4 +
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 424 ++++++++++++++++++++-
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 301 ++++++++++++++-
drivers/thermal/Kconfig | 10 +
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 300 +++++++++++++++
drivers/watchdog/Kconfig | 4 +-
drivers/watchdog/da9062_wdt.c | 12 +-
include/linux/mfd/da9062/core.h | 27 +-
include/linux/mfd/da9062/registers.h | 2 +
15 files changed, 1154 insertions(+), 49 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
create mode 100644 drivers/thermal/da9062-thermal.c
--
end-of-patch for PATCH V4
^ permalink raw reply
* [PATCH V4 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2016-11-14 8:22 UTC (permalink / raw)
To: Eduardo Valentin, LINUX-KERNEL, LINUX-PM, Zhang Rui
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Lukasz Luba, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck
In-Reply-To: <cover.1479111766.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
If the PMIC's internal junction temperature rises above TEMP_WARN (125
degC) an interrupt is issued. This TEMP_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.
The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).
This first level of temperature supervision is intended for non-invasive
temperature control, where the necessary measures for cooling the system
down are left to the host software.
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.8
v3 -> v4
- Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
- Reordering of cancel_delayed_work_sync() in remove function
- dev_warn() message for out-of-range polling period requests
- Explanatory comment for expected values defined for
DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
MIN_POLLING_MS_PERIOD
v2 -> v3
- Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
v1 -> v2
- Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- List the header files in alphabetical order
- Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
copyright "GNU Public License v2 or later" option in the header
comment for this file. See the allowed identifiers in the file
include/linux/module.h +170
- Remove notify function "da9062_thermal_notify" function.
- MODULE_AUTHOR() macros removes Company Name and just gives Name in
accordance with include/linux/module.h +200
- Remove the compatible "dlg,da9061-thermal" option in the of_device_id
struct table. This patch now assumes the use of a DA9062 fallback
compatible string in the DTS when using the DA9061 thermal component
of the DA9061 device.
- Re-ordered some assignments earlier in the probe() for thermal->hw,
thermal->polling_period, thermal->mode, thermal->dev
- Added further information in the patch description to explain the use
of the device driver's built-in work-queue.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 300 +++++++++++++++++++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 drivers/thermal/da9062-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 2d702ca..da58e54 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -272,6 +272,16 @@ config DB8500_CPUFREQ_COOLING
bound cpufreq cooling device turns active to set CPU frequency low to
cool down the CPU.
+config DA9062_THERMAL
+ tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+ depends on MFD_DA9062
+ depends on OF
+ help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 10b07c1..0a2b3f2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE) += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
new file mode 100644
index 0000000..942ca4d
--- /dev/null
+++ b/drivers/thermal/da9062-thermal.c
@@ -0,0 +1,300 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2016 Dialog Semiconductor Ltd.
+ *
+ * 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/errno.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+#include <linux/workqueue.h>
+
+#include <linux/mfd/da9062/core.h>
+#include <linux/mfd/da9062/registers.h>
+
+/* Minimum, maximum and default polling millisecond periods are provided
+ * here as an example. It is expected that any final implementation to also
+ * include a notify() function and modification of these settings to match
+ * the required application.
+ */
+#define DA9062_DEFAULT_POLLING_MS_PERIOD 3000
+#define DA9062_MAX_POLLING_MS_PERIOD 10000
+#define DA9062_MIN_POLLING_MS_PERIOD 1000
+
+#define DA9062_MILLI_CELSIUS(t) ((t)*1000)
+
+struct da9062_thermal_config {
+ const char *name;
+};
+
+struct da9062_thermal {
+ struct da9062 *hw;
+ struct delayed_work work;
+ struct thermal_zone_device *zone;
+ enum thermal_device_mode mode;
+ unsigned int polling_period;
+ struct mutex lock;
+ int temperature;
+ int irq;
+ const struct da9062_thermal_config *config;
+ struct device *dev;
+};
+
+static void da9062_thermal_poll_on(struct work_struct *work)
+{
+ struct da9062_thermal *thermal = container_of(work,
+ struct da9062_thermal,
+ work.work);
+ unsigned int val;
+ int ret;
+
+ /* clear E_TEMP */
+ ret = regmap_write(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ DA9062AA_E_TEMP_MASK);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot clear the TJUNC temperature status\n");
+ goto err_enable_irq;
+ }
+
+ /* Now read E_TEMP again: it is acting like a status bit.
+ * If over-temperature, then this status will be true.
+ * If not over-temperature, this status will be false.
+ */
+ ret = regmap_read(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ &val);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot check the TJUNC temperature status\n");
+ goto err_enable_irq;
+ } else {
+ if (val & DA9062AA_E_TEMP_MASK) {
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(125);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone);
+
+ schedule_delayed_work(&thermal->work,
+ msecs_to_jiffies(thermal->polling_period));
+ return;
+ } else {
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(0);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone);
+ }
+ }
+
+err_enable_irq:
+ enable_irq(thermal->irq);
+}
+
+static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
+{
+ struct da9062_thermal *thermal = data;
+
+ disable_irq_nosync(thermal->irq);
+ schedule_delayed_work(&thermal->work, 0);
+
+ return IRQ_HANDLED;
+}
+
+static int da9062_thermal_get_mode(struct thermal_zone_device *z,
+ enum thermal_device_mode *mode)
+{
+ struct da9062_thermal *thermal = z->devdata;
+ *mode = thermal->mode;
+ return 0;
+}
+
+static int da9062_thermal_get_trip_type(struct thermal_zone_device *z,
+ int trip,
+ enum thermal_trip_type *type)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *type = THERMAL_TRIP_HOT;
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_trip_temp(struct thermal_zone_device *z,
+ int trip,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *temp = DA9062_MILLI_CELSIUS(125);
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_temp(struct thermal_zone_device *z,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ mutex_lock(&thermal->lock);
+ *temp = thermal->temperature;
+ mutex_unlock(&thermal->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops da9062_thermal_ops = {
+ .get_temp = da9062_thermal_get_temp,
+ .get_mode = da9062_thermal_get_mode,
+ .get_trip_type = da9062_thermal_get_trip_type,
+ .get_trip_temp = da9062_thermal_get_trip_temp,
+};
+
+static const struct da9062_thermal_config da9062_config = {
+ .name = "da9062-thermal",
+};
+
+static const struct of_device_id da9062_compatible_reg_id_table[] = {
+ { .compatible = "dlg,da9062-thermal", .data = &da9062_config },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_reg_id_table);
+
+static int da9062_thermal_probe(struct platform_device *pdev)
+{
+ struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
+ struct da9062_thermal *thermal;
+ unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ const struct of_device_id *match;
+ int ret = 0;
+
+ match = of_match_node(da9062_compatible_reg_id_table,
+ pdev->dev.of_node);
+ if (!match)
+ return -ENXIO;
+
+ if (pdev->dev.of_node) {
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "dlg,tjunc-temp-polling-period-ms",
+ &pp_tmp)) {
+ if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
+ pp_tmp > DA9062_MAX_POLLING_MS_PERIOD) {
+ dev_warn(&pdev->dev,
+ "Out-of-range polling period %d ms\n",
+ pp_tmp);
+ pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ }
+ }
+
+ dev_dbg(&pdev->dev,
+ "TJUNC temp polling period set at %d ms\n",
+ pp_tmp);
+ }
+
+ thermal = devm_kzalloc(&pdev->dev, sizeof(struct da9062_thermal),
+ GFP_KERNEL);
+ if (!thermal) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ thermal->config = match->data;
+ thermal->hw = chip;
+ thermal->polling_period = pp_tmp;
+ thermal->mode = THERMAL_DEVICE_ENABLED;
+ thermal->dev = &pdev->dev;
+
+ INIT_DELAYED_WORK(&thermal->work, da9062_thermal_poll_on);
+ mutex_init(&thermal->lock);
+
+ thermal->zone = thermal_zone_device_register(thermal->config->name,
+ 1, 0, thermal,
+ &da9062_thermal_ops, NULL, 0,
+ 0);
+ if (IS_ERR(thermal->zone)) {
+ dev_err(&pdev->dev, "Cannot register thermal zone device\n");
+ ret = PTR_ERR(thermal->zone);
+ goto err;
+ }
+
+ ret = platform_get_irq_byname(pdev, "THERMAL");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get platform IRQ.\n");
+ goto err_zone;
+ }
+ thermal->irq = ret;
+
+ ret = request_threaded_irq(thermal->irq, NULL,
+ da9062_thermal_irq_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ "THERMAL", thermal);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to request thermal device IRQ.\n");
+ goto err_zone;
+ }
+
+ platform_set_drvdata(pdev, thermal);
+ return 0;
+
+err_zone:
+ thermal_zone_device_unregister(thermal->zone);
+err:
+ return ret;
+}
+
+static int da9062_thermal_remove(struct platform_device *pdev)
+{
+ struct da9062_thermal *thermal = platform_get_drvdata(pdev);
+
+ free_irq(thermal->irq, thermal);
+ cancel_delayed_work_sync(&thermal->work);
+ thermal_zone_device_unregister(thermal->zone);
+ return 0;
+}
+
+static struct platform_driver da9062_thermal_driver = {
+ .probe = da9062_thermal_probe,
+ .remove = da9062_thermal_remove,
+ .driver = {
+ .name = "da9062-thermal",
+ .of_match_table = da9062_compatible_reg_id_table,
+ },
+};
+
+module_platform_driver(da9062_thermal_driver);
+
+MODULE_AUTHOR("Steve Twiss");
+MODULE_DESCRIPTION("Thermal TJUNC device driver for Dialog DA9062 and DA9061");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:da9062-thermal");
--
end-of-patch for PATCH V4
^ permalink raw reply related
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-14 8:26 UTC (permalink / raw)
To: liviu.dudau@arm.com
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <20161111181606.GN10219@e106497-lin.cambridge.arm.com>
Hi Liviu
> -----Original Message-----
> From: liviu.dudau@arm.com [mailto:liviu.dudau@arm.com]
> Sent: 11 November 2016 18:16
> To: Gabriele Paoloni
> Cc: Arnd Bergmann; linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> mark.rutland@arm.com; devicetree@vger.kernel.org;
> lorenzo.pieralisi@arm.com; minyard@acm.org; linux-pci@vger.kernel.org;
> benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> catalin.marinas@arm.com; olof@lixom.net; bhelgaas@googl e.com;
> zhichang.yuan02@gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Fri, Nov 11, 2016 at 03:53:53PM +0000, Gabriele Paoloni wrote:
> > Hi Liviu
>
> Hi Gabriele,
>
> >
> > > -----Original Message-----
> > > From: liviu.dudau@arm.com [mailto:liviu.dudau@arm.com]
> > > Sent: 11 November 2016 14:46
> > > To: Gabriele Paoloni
> > > Cc: Arnd Bergmann; linux-arm-kernel@lists.infradead.org;
> Yuanzhichang;
> > > mark.rutland@arm.com; devicetree@vger.kernel.org;
> > > lorenzo.pieralisi@arm.com; minyard@acm.org; linux-
> pci@vger.kernel.org;
> > > benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> > > kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> > > robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> > > catalin.marinas@arm.com; olof@lixom.net; bhelgaas@googl e.com;
> > > zhichang.yuan02@gmail.com
> > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > Hip06
> > >
> > > On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > > > Hi Arnd
> > > >
> > > > > -----Original Message-----
> > > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > > Sent: 10 November 2016 16:07
> > > > > To: Gabriele Paoloni
> > > > > Cc: linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> > > > > mark.rutland@arm.com; devicetree@vger.kernel.org;
> > > > > lorenzo.pieralisi@arm.com; minyard@acm.org; linux-
> > > pci@vger.kernel.org;
> > > > > benh@kernel.crashing.org; John Garry; will.deacon@arm.com;
> linux-
> > > > > kernel@vger.kernel.org; xuwei (O); Linuxarm;
> zourongrong@gmail.com;
> > > > > robh+dt@kernel.org; kantyzc@163.com; linux-
> serial@vger.kernel.org;
> > > > > catalin.marinas@arm.com; olof@lixom.net; liviu.dudau@arm.com;
> > > > > bhelgaas@googl e.com; zhichang.yuan02@gmail.com
> > > > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver
> implementation on
> > > > > Hip06
> > > > >
> > > > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> > > wrote:
> > > > > >
> > > > > > Where should we get the range from? For LPC we know that it
> is
> > > going
> > > > > > Work on anything that is not used by PCI I/O space, and this
> is
> > > > > > why we use [0, PCIBIOS_MIN_IO]
> > > > >
> > > > > It should be allocated the same way we allocate PCI config
> space
> > > > > segments. This is currently done with the io_range list in
> > > > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > > > if necessary. Based on what others commented here, I'd rather
> > > > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > > > than larger.
> > >
> > > Gabriele,
> > >
> > > >
> > > > I am not sure this would make sense...
> > > >
> > > > IMHO all the mechanism around io_range_list is needed to provide
> the
> > > > "mapping" between I/O tokens and physical CPU addresses.
> > > >
> > > > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> > > >
> > > > As you know the I/O memory accessors operate on whatever
> > > > __of_address_to_resource sets into the resource (start, end).
> > > >
> > > > With this special device in place we cannot know if a resource is
> > > > assigned with an I/O token or a physical address, unless we
> forbid
> > > > the I/O tokens to be in a specific range.
> > > >
> > > > So this is why we are changing the offsets of all the functions
> > > > handling io_range_list (to make sure that a range is forbidden to
> > > > the tokens and is available to the physical addresses).
> > > >
> > > > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > > > because this is the maximum physical I/O range that a non PCI
> device
> > > > can operate on and because we believe this does not impose much
> > > > restriction on the available I/O token range; that now is
> > > > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > > > So we believe that the chosen forbidden range can accommodate
> > > > any special ISA bus device with no much constraint on the rest
> > > > of I/O tokens...
> > >
> > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> you
> > > actually need another variable for "reserving" an area in the I/O
> space
> > > that can be used for physical addresses rather than I/O tokens.
> > >
> > > The one good example for using PCIBIOS_MIN_IO is when your
> > > platform/architecture
> > > does not support legacy ISA operations *at all*. In that case
> someone
> > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> range
> > > so that it doesn't get used. With Zhichang's patch you now start
> > > forcing
> > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> >
> > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> used
> > by PCI controllers only...
>
> Nope, that is not what it means. It means that PCI devices can see I/O
> addresses
> on the bus that start from 0. There never was any usage for non-PCI
> controllers
So I am a bit confused...
From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
I thought that was the reason why for most architectures we have
PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
usually use [0, PCIBIOS_MIN_IO - 1] )
For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
they are not fully compliant or they cannot fully support an ISA
controller...?
As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
to allow special ISA controllers to use that range with special
accessors.
Having a variable threshold would make life much more difficult
as there would be a probe dependency between the PCI controller and
the special ISA one (PCI to wait for the special ISA device to be
probed and set the right threshold value from DT or ACPI table).
Instead using PCIBIOS_MIN_IO is easier and should not impose much
constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
the PCI controller for I/O tokens...
Thanks
Gab
> when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> what
> I think is not the right thing (and not enough anyway).
>
> > so if you have a special bus device using
> > an I/O range in this case should be a PCI controller...
>
> That has always been the case. It is this series that wants to
> introduce the
> new meaning.
>
> > i.e. I would
> > expect it to fall back into the case of I/O tokens redirection rather
> than
> > physical addresses redirection (as mentioned below from my previous
> reply).
> > What do you think?
>
> I think you have looked too much at the code *with* Zhichang's patches
> applied.
> Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> apply
> the patches. It is all about PCI addresses and there is no notion of
> non-PCI
> busses using PCI framework. Only platforms and architectures that try
> to work
> around some legacy standards (ISA) or HW restrictions.
>
> Best regards,
> Liviu
>
> >
> > Thanks
> >
> > Gab
> >
> >
> > >
> > > For the general case you also have to bear in mind that
> PCIBIOS_MIN_IO
> > > could
> > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> it
> > > makes
> > > sense to add a new #define that should only be defined by those
> > > architectures/
> > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> region
> > > where I/O tokens can't be generated for.
> > >
> > > Best regards,
> > > Liviu
> > >
> > > >
> > > > >
> > > > > > > Your current version has
> > > > > > >
> > > > > > > if (arm64_extio_ops->pfout)
> > > \
> > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > >devpara,\
> > > > > > > addr, value, sizeof(type));
> > > \
> > > > > > >
> > > > > > > Instead, just subtract the start of the range from the
> logical
> > > > > > > port number to transform it back into a bus-local port
> number:
> > > > > >
> > > > > > These accessors do not operate on IO tokens:
> > > > > >
> > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> addr)
> > > > > > addr is not going to be an I/O token; in fact patch 2/3
> imposes
> > > that
> > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > PCIBIOS_MIN_IO
> > > > > > we have free physical addresses that the accessors can
> operate
> > > on.
> > > > >
> > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> refer
> > > to
> > > > > the logical I/O tokens, the purpose of that macro is really
> meant
> > > > > for allocating PCI I/O port numbers within the address space of
> > > > > one bus.
> > > >
> > > > As I mentioned above, special devices operate on CPU addresses
> > > directly,
> > > > not I/O tokens. For them there is no way to distinguish....
> > > >
> > > > >
> > > > > Note that it's equally likely that whichever next platform
> needs
> > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > space,
> > > > > and that will use it on addresses registered to a PCI host
> bridge.
> > > >
> > > > Ok so here you are talking about a platform that has got an I/O
> range
> > > > under the PCI host controller, right?
> > > > And this I/O range cannot be directly memory mapped but needs
> special
> > > > redirections for the I/O tokens, right?
> > > >
> > > > In this scenario registering the I/O ranges with the forbidden
> range
> > > > implemented by the current patch would still allow to redirect
> I/O
> > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > >
> > > > So effectively the special PCI host controller
> > > > 1) knows the physical range that needs special redirection
> > > > 2) register such range
> > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > special accessors
> > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> 3)
> > > >
> > > > So to be honest I think this patch can fit well both with
> > > > special PCI controllers that need I/O tokens redirection and with
> > > > special non-PCI controllers that need non-PCI I/O physical
> > > > address redirection...
> > > >
> > > > Thanks (and sorry for the long reply but I didn't know how
> > > > to make the explanation shorter :) )
> > > >
> > > > Gab
> > > >
> > > > >
> > > > > If we separate the two steps:
> > > > >
> > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > b) register a set of helpers for redirecting logical I/O
> > > > > port to a helper function
> > > > >
> > > > > then I think the code will get cleaner and more flexible.
> > > > > It should actually then be able to replace the powerpc
> > > > > specific implementation.
> > > > >
> > > > > Arnd
> > >
> > > --
> > > ====================
> > > | I would like to |
> > > | fix the world, |
> > > | but they're not |
> > > | giving me the |
> > > \ source code! /
> > > ---------------
> > > ¯\_(ツ)_/¯
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v5 0/3] Add clockevet for timer-nps driver to NPS400 SoC
From: Daniel Lezcano @ 2016-11-14 8:28 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
s/clockevet/clockevent/
Reply-To:
In-Reply-To: <1479021872-14237-1-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Sun, Nov 13, 2016 at 09:24:29AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Change log
> ---
> V4 --> V5
> Apply several comments made by Daneil Lezcano:
s/Daneil/Daniel/
Noam,
I know it is patch 0/3, but each time you send a change there are new typos.
Sending new versions as fast as possible without double checking the changes
won't make them merged sooner.
Nobody is perfect but clearly you don't read your patch before sending and
that does not make me confident about the code changes.
In the future, take some minutes to double-check and re-read your changes.
Thanks.
-- Daniel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 2/3] clocksource: update "fn" at CLOCKSOURCE_OF_DECLARE() of nps400 timer
From: Daniel Lezcano @ 2016-11-14 8:43 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479021872-14237-3-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Sun, Nov 13, 2016 at 09:24:31AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> nps_setup_clocksource() should take node as only argument i.e.:
> replace
> int __init nps_setup_clocksource(struct device_node *node, struct clk *clk)
> with
> int __init nps_setup_clocksource(struct device_node *node)
because ...
> This is also serve as preperation for next patch which adds support
s/This is also/This also/
s/preperation/preparation/
> for clockevents to nps400.
> Specifically we add new function nps_get_timer_clk() to serve clocksource
> and later clockevent registration.
>
> Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> drivers/clocksource/timer-nps.c | 63 +++++++++++++++++++++++----------------
> 1 files changed, 37 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index 70c149a..eeef9e9 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -46,7 +46,33 @@
> /* This array is per cluster of CPUs (Each NPS400 cluster got 256 CPUs) */
> static void *nps_msu_reg_low_addr[NPS_CLUSTER_NUM] __read_mostly;
>
> -static unsigned long nps_timer_rate;
> +static int __init nps_get_timer_clk(struct device_node *node,
> + unsigned long *timer_freq,
> + struct clk **clk)
> +{
> + int ret;
> +
> + *clk = of_clk_get(node, 0);
> + if (IS_ERR(*clk)) {
> + pr_err("timer missing clk");
> + return PTR_ERR(*clk);
> + }
> +
> + ret = clk_prepare_enable(*clk);
> + if (ret) {
> + pr_err("Couldn't enable parent clk\n");
> + return ret;
> + }
> +
> + *timer_freq = clk_get_rate(*clk);
> + if (!(*timer_freq)) {
> + pr_err("Couldn't get clk rate\n");
> + clk_disable_unprepare(*clk);
> + return 1;
s/return 1/return -EINVAL/
What about clk_put() ?
> + }
> +
> + return 0;
> +}
>
> static cycle_t nps_clksrc_read(struct clocksource *clksrc)
> {
> @@ -55,26 +81,24 @@ static cycle_t nps_clksrc_read(struct clocksource *clksrc)
> return (cycle_t)ioread32be(nps_msu_reg_low_addr[cluster]);
> }
>
> -static int __init nps_setup_clocksource(struct device_node *node,
> - struct clk *clk)
> +static int __init nps_setup_clocksource(struct device_node *node)
> {
> int ret, cluster;
> + struct clk *clk;
> + unsigned long nps_timer1_freq;
> +
>
> for (cluster = 0; cluster < NPS_CLUSTER_NUM; cluster++)
> nps_msu_reg_low_addr[cluster] =
> nps_host_reg((cluster << NPS_CLUSTER_OFFSET),
> - NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
> + NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
>
> - ret = clk_prepare_enable(clk);
> - if (ret) {
> - pr_err("Couldn't enable parent clock\n");
> + ret = nps_get_timer_clk(node, &nps_timer1_freq, &clk);
> + if (ret)
> return ret;
> - }
>
> - nps_timer_rate = clk_get_rate(clk);
> -
> - ret = clocksource_mmio_init(nps_msu_reg_low_addr, "EZnps-tick",
> - nps_timer_rate, 301, 32, nps_clksrc_read);
> + ret = clocksource_mmio_init(nps_msu_reg_low_addr, "nps-tick",
> + nps_timer1_freq, 300, 32, nps_clksrc_read);
> if (ret) {
> pr_err("Couldn't register clock source.\n");
> clk_disable_unprepare(clk);
> @@ -83,18 +107,5 @@ static int __init nps_setup_clocksource(struct device_node *node,
> return ret;
> }
>
> -static int __init nps_timer_init(struct device_node *node)
> -{
> - struct clk *clk;
> -
> - clk = of_clk_get(node, 0);
> - if (IS_ERR(clk)) {
> - pr_err("Can't get timer clock.\n");
> - return PTR_ERR(clk);
> - }
> -
> - return nps_setup_clocksource(node, clk);
> -}
> -
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> - nps_timer_init);
> + nps_setup_clocksource);
> --
> 1.7.1
>
--
<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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Jyri Sarha @ 2016-11-14 8:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <12424154.kJqhEf2pOz@avalon>
On 11/03/16 19:46, Laurent Pinchart wrote:
>> +Required properties:
>> > + - compatible: "ti,tfp410"
> The device is an I2C slave, it should have a reg property. Given that the chip
> can be used without being controlled through I2C, the reg property should be
> optional. You should document this clearly, and explain how the DT node can be
> instantiated as a child of an I2C controller when the I2C interface is used,
> or in other parts of the device tree otherwise.
>
Shouldn't I have two different compatible strings if want to make both
platform driver probe and i2c client probe to work?
Or can it be done with single compatible string? Would you know of an
example of such a driver?
Cheers,
Jyri
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/3] ARM: sunxi: add support for H2+ SoC
From: Maxime Ripard @ 2016-11-14 8:54 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Jonathan Corbet, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161111164654.15273-1-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]
Hi,
On Sat, Nov 12, 2016 at 12:46:52AM +0800, Icenowy Zheng wrote:
> Allwinner H2+ is a quad-core Cortex-A7 SoC.
>
> It is very like H3, that they share the same SoC ID (0x1680), and H3
> memory maps as well as drivers works well on the SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Documentation/arm/sunxi/README | 4 ++++
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd02433..1fe4d99c 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -63,6 +63,10 @@ SunXi family
> + User Manual
> http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
>
> + - Allwinner H2+ (sun8i)
> + + No document available now, but is known to be working properly with
> + H3 drivers and memory map.
> +
> - Allwinner H3 (sun8i)
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a..0c0f277 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -13,5 +13,6 @@ using one of the following compatible strings:
> allwinner,sun8i-a33
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> + allwinner,sun8i-h2plus
That's a nitpick, but I'd prefer to have sun8i-h2-plus.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: sunxi: add Allwinner H2+ dtsi
From: Maxime Ripard @ 2016-11-14 8:55 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Jonathan Corbet, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161111164654.15273-2-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Sat, Nov 12, 2016 at 12:46:53AM +0800, Icenowy Zheng wrote:
> Allwinner H2+ is a SoC so similar with H3 that H3 drivers and memory map
> is known to work well on H2+, with both BSP kernel/firmware or the
> mainline ones.
>
> So add a dtsi file which only include the H3 dtsi only, so we can add
> H2+-specified nodes in the dtsi file when we find any software
> difference between H2+ and H3.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
I don't think we need that patch at all. You can do it just like we
did for the R8 and R16, just include the H3 DTSI in your board. We'll
create it if we need it at some point.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox