* [PATCH 2/2] clk: qcom: Add display clock controller driver for SDM845
From: Taniya Das @ 2018-06-04 7:56 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette, robh
Cc: Andy Gross, David Brown, Rajendra Nayak, Amit Nischal,
linux-arm-msm, linux-soc, linux-clk, linux-kernel, devicetree,
Taniya Das
In-Reply-To: <1528098985-3676-1-git-send-email-tdas@codeaurora.org>
Add support for the display clock controller found on SDM845
based devices. This would allow display drivers to probe and
control their clocks.
Signed-off-by: Taniya Das <tdas@codeaurora.org>
---
drivers/clk/qcom/Kconfig | 10 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/dispcc-sdm845.c | 679 +++++++++++++++++++++++++++++++++++++++
3 files changed, 690 insertions(+)
create mode 100644 drivers/clk/qcom/dispcc-sdm845.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index e06e1f8..d9e7e75 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -227,6 +227,16 @@ config SDM_GCC_845
Say Y if you want to use peripheral devices such as UART, SPI,
I2C, USB, UFS, SDDC, PCIe, etc.
+config SDM_DISPCC_845
+ tristate "SDM845 Display Clock Controller"
+ select SDM_GCC_845
+ depends on COMMON_CLK_QCOM
+ help
+ Support for the display clock controller on Qualcomm Technologies, Inc
+ sdm845 devices.
+ Say Y if you want to support display devices and functionality such as
+ splash screen.
+
config SPMI_PMIC_CLKDIV
tristate "SPMI PMIC clkdiv Support"
depends on (COMMON_CLK_QCOM && SPMI) || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 82070e0..96142ff 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -38,4 +38,5 @@ obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
+obj-$(CONFIG_SDM_DISPCC_845) += dispcc-sdm845.o
obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
new file mode 100644
index 0000000..317ab33
--- /dev/null
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -0,0 +1,679 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#include <dt-bindings/clock/qcom,dispcc-sdm845.h>
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_DISP_CC_PLL0_OUT_MAIN,
+ P_DSI0_PHY_PLL_OUT_BYTECLK,
+ P_DSI0_PHY_PLL_OUT_DSICLK,
+ P_DSI1_PHY_PLL_OUT_BYTECLK,
+ P_DSI1_PHY_PLL_OUT_DSICLK,
+ P_GPLL0_OUT_MAIN,
+ P_GPLL0_OUT_MAIN_DIV,
+};
+
+static const struct parent_map disp_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_DSI0_PHY_PLL_OUT_BYTECLK, 1 },
+ { P_DSI1_PHY_PLL_OUT_BYTECLK, 2 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_0[] = {
+ "bi_tcxo",
+ "dsi0_phy_pll_out_byteclk",
+ "dsi1_phy_pll_out_byteclk",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_2[] = {
+ { P_BI_TCXO, 0 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_2[] = {
+ "bi_tcxo",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_3[] = {
+ { P_BI_TCXO, 0 },
+ { P_DISP_CC_PLL0_OUT_MAIN, 1 },
+ { P_GPLL0_OUT_MAIN, 4 },
+ { P_GPLL0_OUT_MAIN_DIV, 5 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_3[] = {
+ "bi_tcxo",
+ "disp_cc_pll0",
+ "gcc_disp_gpll0_clk_src",
+ "gcc_disp_gpll0_div_clk_src",
+ "core_bi_pll_test_se",
+};
+
+static const struct parent_map disp_cc_parent_map_4[] = {
+ { P_BI_TCXO, 0 },
+ { P_DSI0_PHY_PLL_OUT_DSICLK, 1 },
+ { P_DSI1_PHY_PLL_OUT_DSICLK, 2 },
+ { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const disp_cc_parent_names_4[] = {
+ "bi_tcxo",
+ "dsi0_phy_pll_out_dsiclk",
+ "dsi1_phy_pll_out_dsiclk",
+ "core_bi_pll_test_se",
+};
+
+static const struct alpha_pll_config disp_cc_pll0_config = {
+ .l = 0x2c,
+ .alpha = 0xcaaa,
+};
+
+static struct clk_alpha_pll disp_cc_pll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_pll0",
+ .parent_names = (const char *[]){ "bi_tcxo" },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_fabia_ops,
+ },
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_byte0_clk_src = {
+ .cmd_rcgr = 0x20d0,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_0,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte0_clk_src",
+ .parent_names = disp_cc_parent_names_0,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_byte2_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_byte1_clk_src = {
+ .cmd_rcgr = 0x20ec,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_0,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte1_clk_src",
+ .parent_names = disp_cc_parent_names_0,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_byte2_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_esc0_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_esc0_clk_src = {
+ .cmd_rcgr = 0x2108,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_0,
+ .freq_tbl = ftbl_disp_cc_mdss_esc0_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_esc0_clk_src",
+ .parent_names = disp_cc_parent_names_0,
+ .num_parents = 4,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_esc1_clk_src = {
+ .cmd_rcgr = 0x2120,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_0,
+ .freq_tbl = ftbl_disp_cc_mdss_esc0_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_esc1_clk_src",
+ .parent_names = disp_cc_parent_names_0,
+ .num_parents = 4,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_mdp_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(85714286, P_GPLL0_OUT_MAIN, 7, 0, 0),
+ F(100000000, P_GPLL0_OUT_MAIN, 6, 0, 0),
+ F(150000000, P_GPLL0_OUT_MAIN, 4, 0, 0),
+ F(171428571, P_GPLL0_OUT_MAIN, 3.5, 0, 0),
+ F(200000000, P_GPLL0_OUT_MAIN, 3, 0, 0),
+ F(300000000, P_GPLL0_OUT_MAIN, 2, 0, 0),
+ F(344000000, P_DISP_CC_PLL0_OUT_MAIN, 2.5, 0, 0),
+ F(430000000, P_DISP_CC_PLL0_OUT_MAIN, 2, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_mdp_clk_src = {
+ .cmd_rcgr = 0x2088,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_3,
+ .freq_tbl = ftbl_disp_cc_mdss_mdp_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_mdp_clk_src",
+ .parent_names = disp_cc_parent_names_3,
+ .num_parents = 5,
+ .ops = &clk_rcg2_shared_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_pclk0_clk_src = {
+ .cmd_rcgr = 0x2058,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_4,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_pclk0_clk_src",
+ .parent_names = disp_cc_parent_names_4,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_pixel_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_pclk1_clk_src = {
+ .cmd_rcgr = 0x2070,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_4,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_pclk1_clk_src",
+ .parent_names = disp_cc_parent_names_4,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_pixel_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_rot_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(171428571, P_GPLL0_OUT_MAIN, 3.5, 0, 0),
+ F(300000000, P_GPLL0_OUT_MAIN, 2, 0, 0),
+ F(344000000, P_DISP_CC_PLL0_OUT_MAIN, 2.5, 0, 0),
+ F(430000000, P_DISP_CC_PLL0_OUT_MAIN, 2, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_rot_clk_src = {
+ .cmd_rcgr = 0x20a0,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_3,
+ .freq_tbl = ftbl_disp_cc_mdss_rot_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_rot_clk_src",
+ .parent_names = disp_cc_parent_names_3,
+ .num_parents = 5,
+ .ops = &clk_rcg2_shared_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_vsync_clk_src = {
+ .cmd_rcgr = 0x20b8,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_2,
+ .freq_tbl = ftbl_disp_cc_mdss_esc0_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_vsync_clk_src",
+ .parent_names = disp_cc_parent_names_2,
+ .num_parents = 2,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_branch disp_cc_mdss_ahb_clk = {
+ .halt_reg = 0x4004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_ahb_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_axi_clk = {
+ .halt_reg = 0x4008,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4008,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_axi_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_byte0_clk = {
+ .halt_reg = 0x2028,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2028,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte0_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte0_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_regmap_div disp_cc_mdss_byte0_div_clk_src = {
+ .reg = 0x20e8,
+ .shift = 0,
+ .width = 2,
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte0_div_clk_src",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte0_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_GET_RATE_NOCACHE,
+ .ops = &clk_regmap_div_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_byte0_intf_clk = {
+ .halt_reg = 0x202c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x202c,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte0_intf_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte0_div_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_byte1_clk = {
+ .halt_reg = 0x2030,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2030,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte1_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte1_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_regmap_div disp_cc_mdss_byte1_div_clk_src = {
+ .reg = 0x2104,
+ .shift = 0,
+ .width = 2,
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte1_div_clk_src",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte1_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_GET_RATE_NOCACHE,
+ .ops = &clk_regmap_div_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_byte1_intf_clk = {
+ .halt_reg = 0x2034,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2034,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_byte1_intf_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_byte1_div_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_esc0_clk = {
+ .halt_reg = 0x2038,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2038,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_esc0_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_esc0_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_esc1_clk = {
+ .halt_reg = 0x203c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x203c,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_esc1_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_esc1_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_mdp_clk = {
+ .halt_reg = 0x200c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x200c,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_mdp_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_mdp_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_mdp_lut_clk = {
+ .halt_reg = 0x201c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x201c,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_mdp_lut_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_mdp_clk_src",
+ },
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_pclk0_clk = {
+ .halt_reg = 0x2004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_pclk0_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_pclk0_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_pclk1_clk = {
+ .halt_reg = 0x2008,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2008,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_pclk1_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_pclk1_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_rot_clk = {
+ .halt_reg = 0x2014,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2014,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_rot_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_rot_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_rscc_ahb_clk = {
+ .halt_reg = 0x5004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x5004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_rscc_ahb_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_rscc_vsync_clk = {
+ .halt_reg = 0x5008,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x5008,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_rscc_vsync_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_vsync_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_vsync_clk = {
+ .halt_reg = 0x2024,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2024,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_vsync_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_vsync_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct gdsc mdss_gdsc = {
+ .gdscr = 0x3000,
+ .pd = {
+ .name = "mdss_gdsc",
+ },
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags = HW_CTRL | POLL_CFG_GDSCR,
+};
+
+static struct clk_regmap *disp_cc_sdm845_clocks[] = {
+ [DISP_CC_MDSS_AHB_CLK] = &disp_cc_mdss_ahb_clk.clkr,
+ [DISP_CC_MDSS_AXI_CLK] = &disp_cc_mdss_axi_clk.clkr,
+ [DISP_CC_MDSS_BYTE0_CLK] = &disp_cc_mdss_byte0_clk.clkr,
+ [DISP_CC_MDSS_BYTE0_CLK_SRC] = &disp_cc_mdss_byte0_clk_src.clkr,
+ [DISP_CC_MDSS_BYTE0_INTF_CLK] = &disp_cc_mdss_byte0_intf_clk.clkr,
+ [DISP_CC_MDSS_BYTE0_DIV_CLK_SRC] =
+ &disp_cc_mdss_byte0_div_clk_src.clkr,
+ [DISP_CC_MDSS_BYTE1_CLK] = &disp_cc_mdss_byte1_clk.clkr,
+ [DISP_CC_MDSS_BYTE1_CLK_SRC] = &disp_cc_mdss_byte1_clk_src.clkr,
+ [DISP_CC_MDSS_BYTE1_INTF_CLK] = &disp_cc_mdss_byte1_intf_clk.clkr,
+ [DISP_CC_MDSS_BYTE1_DIV_CLK_SRC] =
+ &disp_cc_mdss_byte1_div_clk_src.clkr,
+ [DISP_CC_MDSS_ESC0_CLK] = &disp_cc_mdss_esc0_clk.clkr,
+ [DISP_CC_MDSS_ESC0_CLK_SRC] = &disp_cc_mdss_esc0_clk_src.clkr,
+ [DISP_CC_MDSS_ESC1_CLK] = &disp_cc_mdss_esc1_clk.clkr,
+ [DISP_CC_MDSS_ESC1_CLK_SRC] = &disp_cc_mdss_esc1_clk_src.clkr,
+ [DISP_CC_MDSS_MDP_CLK] = &disp_cc_mdss_mdp_clk.clkr,
+ [DISP_CC_MDSS_MDP_CLK_SRC] = &disp_cc_mdss_mdp_clk_src.clkr,
+ [DISP_CC_MDSS_MDP_LUT_CLK] = &disp_cc_mdss_mdp_lut_clk.clkr,
+ [DISP_CC_MDSS_PCLK0_CLK] = &disp_cc_mdss_pclk0_clk.clkr,
+ [DISP_CC_MDSS_PCLK0_CLK_SRC] = &disp_cc_mdss_pclk0_clk_src.clkr,
+ [DISP_CC_MDSS_PCLK1_CLK] = &disp_cc_mdss_pclk1_clk.clkr,
+ [DISP_CC_MDSS_PCLK1_CLK_SRC] = &disp_cc_mdss_pclk1_clk_src.clkr,
+ [DISP_CC_MDSS_ROT_CLK] = &disp_cc_mdss_rot_clk.clkr,
+ [DISP_CC_MDSS_ROT_CLK_SRC] = &disp_cc_mdss_rot_clk_src.clkr,
+ [DISP_CC_MDSS_RSCC_AHB_CLK] = &disp_cc_mdss_rscc_ahb_clk.clkr,
+ [DISP_CC_MDSS_RSCC_VSYNC_CLK] = &disp_cc_mdss_rscc_vsync_clk.clkr,
+ [DISP_CC_MDSS_VSYNC_CLK] = &disp_cc_mdss_vsync_clk.clkr,
+ [DISP_CC_MDSS_VSYNC_CLK_SRC] = &disp_cc_mdss_vsync_clk_src.clkr,
+ [DISP_CC_PLL0] = &disp_cc_pll0.clkr,
+};
+
+static const struct qcom_reset_map disp_cc_sdm845_resets[] = {
+ [DISP_CC_MDSS_RSCC_BCR] = { 0x5000 },
+};
+
+static struct gdsc *disp_cc_sdm845_gdscs[] = {
+ [MDSS_GDSC] = &mdss_gdsc,
+};
+
+static const struct regmap_config disp_cc_sdm845_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x10000,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc disp_cc_sdm845_desc = {
+ .config = &disp_cc_sdm845_regmap_config,
+ .clks = disp_cc_sdm845_clocks,
+ .num_clks = ARRAY_SIZE(disp_cc_sdm845_clocks),
+ .resets = disp_cc_sdm845_resets,
+ .num_resets = ARRAY_SIZE(disp_cc_sdm845_resets),
+ .gdscs = disp_cc_sdm845_gdscs,
+ .num_gdscs = ARRAY_SIZE(disp_cc_sdm845_gdscs),
+};
+
+static const struct of_device_id disp_cc_sdm845_match_table[] = {
+ { .compatible = "qcom,sdm845-dispcc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, disp_cc_sdm845_match_table);
+
+static int disp_cc_sdm845_probe(struct platform_device *pdev)
+{
+ struct regmap *regmap;
+
+ regmap = qcom_cc_map(pdev, &disp_cc_sdm845_desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ clk_fabia_pll_configure(&disp_cc_pll0, regmap, &disp_cc_pll0_config);
+
+ /* Enable clock gating for DSI and MDP clocks */
+ regmap_update_bits(regmap, 0x8000, 0x7f0, 0x7f0);
+
+ return qcom_cc_really_probe(pdev, &disp_cc_sdm845_desc, regmap);
+}
+
+static struct platform_driver disp_cc_sdm845_driver = {
+ .probe = disp_cc_sdm845_probe,
+ .driver = {
+ .name = "disp_cc-sdm845",
+ .of_match_table = disp_cc_sdm845_match_table,
+ },
+};
+
+static int __init disp_cc_sdm845_init(void)
+{
+ return platform_driver_register(&disp_cc_sdm845_driver);
+}
+subsys_initcall(disp_cc_sdm845_init);
+
+static void __exit disp_cc_sdm845_exit(void)
+{
+ platform_driver_unregister(&disp_cc_sdm845_driver);
+}
+module_exit(disp_cc_sdm845_exit);
+
+MODULE_LICENSE("GPL v2");
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
^ permalink raw reply related
* Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Maxime Ripard @ 2018-06-04 8:13 UTC (permalink / raw)
To: Bob Ham
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180602160313.26763-1-rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5395 bytes --]
Hi,
On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
> This is initial support for the Pengpod 1000 tablet. The display is
> not currently working but the UART, SD card and USB all work fine.
>
> Signed-off-by: Bob Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
> ---
> Changes since v1:
>
> * Added SPDX license identifier
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 234 +++++++++++++++++++++++++++
> 2 files changed, 235 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38543dc..e6e93e7ffc8b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> sun4i-a10-pcduino2.dtb \
> + sun4i-a10-pengpod-1000.dtb \
> sun4i-a10-pov-protab2-ips9.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a10s-auxtek-t003.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> new file mode 100644
> index 000000000000..788163a80f3a
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> @@ -0,0 +1,234 @@
> +/*
> + * Copyright 2015 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> + * Copyright 2017 Robert Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
> + *
> + * SPDX-License-Identifier: (GPL-2.0-or-later or X11)
This should be the very first line.
> + * 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 as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * 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 "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.
And this is redundant with the SPDX header.
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +/ {
> + model = "PengPod 1000";
> + compatible = "pengpod,1000", "allwinner,sun4i-a10";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&bl_en_pin_pengpod1000>;
These two pinctrl property aren't needed.
> + pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
Each step should increase the perceived brightness by roughly 1/Nth, N
being the number of steps. Usually PWM backlights don't work like that.
> +&i2c2 {
> + status = "okay";
> +
> + ft5406ee8: touchscreen@38 {
> + compatible = "edt,edt-ft5406";
> + reg = <0x38>;
> + interrupt-parent = <&pio>;
> + interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&touchscreen_pins>;
You can drop these two pinctrl properties as well
> +&pio {
> + bl_en_pin_pengpod1000: bl_en_pin@0 {
> + pins = "PH7";
> + function = "gpio_out";
> + };
> +
> + touchscreen_pins: touchscreen_pins@0 {
> + pins = "PB13";
> + function = "gpio_out";
> + };
> +
> + usb0_id_detect_pin: usb0_id_detect_pin@0 {
> + pins = "PH4";
> + function = "gpio_in";
> + bias-pull-up;
> + };
> +
> + usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
> + pins = "PH5";
> + function = "gpio_in";
> + bias-pull-down;
> + };
> +};
And all these nodes.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 2/7] clk: at91: add I2S clock mux driver
From: Codrin Ciubotariu @ 2018-06-04 8:20 UTC (permalink / raw)
To: Stephen Boyd, alexandre.belloni, alsa-devel, boris.brezillon,
broonie, devicetree, linux-arm-kernel, linux-clk, linux-kernel,
nicolas.ferre, robh+dt
Cc: Cristian.Birsan
In-Reply-To: <152778039660.144038.4743783065942615925@swboyd.mtv.corp.google.com>
On 31.05.2018 18:26, Stephen Boyd wrote:
> Quoting Codrin Ciubotariu (2018-05-25 05:34:23)
>> This driver is a simple muxing driver that controls the
>> I2S's clock input by using syscon/regmap to change the parrent.
>
> s/parrent/parent/
I will fix it.
>
>> The available inputs can be Peripheral clock and Generated clock.
>
> Why capitalize peripheral and generated?
In DS, at I2S block these clocks appear defined with capital letters...
I will fix it.
>
>>
>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> ---
>> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
>> index 1254bf9..903f23c 100644
>> --- a/arch/arm/mach-at91/Kconfig
>> +++ b/arch/arm/mach-at91/Kconfig
>> @@ -27,6 +27,7 @@ config SOC_SAMA5D2
>> select HAVE_AT91_H32MX
>> select HAVE_AT91_GENERATED_CLK
>> select HAVE_AT91_AUDIO_PLL
>> + select HAVE_AT91_I2S_MUX_CLK
>> select PINCTRL_AT91PIO4
>> help
>> Select this if ou are using one of Microchip's SAMA5D2 family SoC.
>> @@ -129,6 +130,9 @@ config HAVE_AT91_GENERATED_CLK
>> config HAVE_AT91_AUDIO_PLL
>> bool
>>
>> +config HAVE_AT91_I2S_MUX_CLK
>> + bool
>> +
>> config SOC_SAM_V4_V5
>> bool
>>
>
> I guess this is OK.
>
>> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
>> index 082596f..facc169 100644
>> --- a/drivers/clk/at91/Makefile
>> +++ b/drivers/clk/at91/Makefile
>> @@ -13,3 +13,4 @@ obj-$(CONFIG_HAVE_AT91_USB_CLK) += clk-usb.o
>> obj-$(CONFIG_HAVE_AT91_SMD) += clk-smd.o
>> obj-$(CONFIG_HAVE_AT91_H32MX) += clk-h32mx.o
>> obj-$(CONFIG_HAVE_AT91_GENERATED_CLK) += clk-generated.o
>> +obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK) += clk-i2s-mux.o
>> diff --git a/drivers/clk/at91/clk-i2s-mux.c b/drivers/clk/at91/clk-i2s-mux.c
>> new file mode 100644
>> index 0000000..2d56ded
>> --- /dev/null
>> +++ b/drivers/clk/at91/clk-i2s-mux.c
>> @@ -0,0 +1,117 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (C) 2018 Microchip Technology Inc,
>> + * Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> + *
>> + *
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/of.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +
>> +#include <soc/at91/atmel-sfr.h>
>> +
>> +#define I2S_BUS_NR 2
>> +
>> +struct clk_i2s_mux {
>> + struct clk_hw hw;
>> + struct regmap *regmap;
>> + u32 bus_id;
>
> Can be a u8?
I think so, I will cast out_value parameter of of_property_read_u32() to u8.
>
>> +};
>> +
>> +#define to_clk_i2s_mux(hw) container_of(hw, struct clk_i2s_mux, hw)
>> +
>> +static u8 clk_i2s_mux_get_parent(struct clk_hw *hw)
>> +{
>> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
>> + u32 val;
>> +
>> + regmap_read(mux->regmap, AT91_SFR_I2SCLKSEL, &val);
>> +
>> + return (val & BIT(mux->bus_id)) >> mux->bus_id;
>> +}
>> +
>> +static int clk_i2s_mux_set_parent(struct clk_hw *hw, u8 index)
>> +{
>> + struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
>> +
>> + return regmap_update_bits(mux->regmap, AT91_SFR_I2SCLKSEL,
>> + BIT(mux->bus_id), index << mux->bus_id);
>> +}
>> +
>> +const struct clk_ops clk_i2s_mux_ops = {
>
> static?
Yes, I will fix it.
>
>> + .get_parent = clk_i2s_mux_get_parent,
>> + .set_parent = clk_i2s_mux_set_parent,
>> + .determine_rate = __clk_mux_determine_rate,
>> +};
>> +
>> +static struct clk_hw * __init
>> +at91_clk_i2s_mux_register(struct regmap *regmap, const char *name,
>> + const char * const *parent_names,
>> + unsigned int num_parents, u32 bus_id)
>> +{
>> + struct clk_init_data init = {};
>> + struct clk_i2s_mux *i2s_ck;
>> + int ret;
>> +
>> + i2s_ck = kzalloc(sizeof(*i2s_ck), GFP_KERNEL);
>> + if (!i2s_ck)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + init.name = name;
>> + init.ops = &clk_i2s_mux_ops;
>> + init.parent_names = parent_names;
>> + init.num_parents = num_parents;
>> + init.flags = CLK_IGNORE_UNUSED;
>
> Really? Why?
I am thinking that there is no need to gate this clock, since there is
no way to gate this clock in HW.
>
>> +
>> + i2s_ck->hw.init = &init;
>> + i2s_ck->bus_id = bus_id;
>> + i2s_ck->regmap = regmap;
>> +
>> + ret = clk_hw_register(NULL, &i2s_ck->hw);
>> + if (ret) {
>> + kfree(i2s_ck);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + return &i2s_ck->hw;
>> +}
Thank you for your review. I will wait a few more days for more comments
on this series and send a V5 afterwards.
Best regards,
Codrin
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Maxime Ripard @ 2018-06-04 8:49 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Icenowy Zheng, arm-linux
In-Reply-To: <CA+E=qVffecgkCG2V_5ptS9oRxo4XwjpQQhWmf8ywpfF78Yy+7A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4350 bytes --]
On Fri, Jun 01, 2018 at 10:37:29AM -0700, Vasily Khoruzhick wrote:
> On Fri, Jun 1, 2018 at 2:23 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Thu, May 31, 2018 at 11:29:01PM -0700, Vasily Khoruzhick wrote:
> >> From: Icenowy Zheng <icenowy@aosc.xyz>
> >>
> >> Pinebook is a A64-based laptop produced by Pine64, with the following
> >> peripherals:
> >>
> >> USB:
> >> - Two external USB ports (one is directly connected to A64's OTG
> >> controller, the other is under a internal hub connected to the host-only
> >> controller.)
> >> - USB HID keyboard and touchpad connected to the internal hub.
> >> - USB UVC camera connected to the internal hub.
> >>
> >> Power-related:
> >> - A DC IN jack connected to AXP803's DCIN pin.
> >> - A Li-Polymer battery connected to AXP803's battery pins.
> >>
> >> Storage:
> >> - An eMMC by Foresee on the main board (in the product revision of the
> >> main board it's designed to be switchable).
> >> - An external MicroSD card slot.
> >>
> >> Display:
> >> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
> >> - A mini HDMI port.
> >>
> >> Misc:
> >> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
> >> - A headphone jack connected to the SoC's internal codec.
> >> - A debug UART port muxed with headphone jack.
> >>
> >> This commit adds basical support for it.
> >>
> >> [vasily: squashed several commits into one, added simplefb node, added usbphy
> >> to ehci0 and ohci0 nodes]
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> >> ---
> >> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> >> .../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
> >> 2 files changed, 286 insertions(+)
> >> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> >> index 8bebe7da5ed9..a8c6d0c6f2c5 100644
> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> >> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> >> new file mode 100644
> >> index 000000000000..d952db217702
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> >> @@ -0,0 +1,285 @@
> >> +/*
> >> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
> >> + * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
> >> + *
> >> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
> >
> > The SPDX tag should be the first one.
>
> OK, but it's not in number of other dts files, e.g.
> sun50i-a64-teres-i.dts or sun50i-h5-orangepi-zero-plus.dts
I guess we'd have to fix it then
> >> +/* The ANX6345 eDP-bridge is on r_i2c. There is no linux (mainline)
> >> + * driver for this chip at the moment, the bootloader initializes it.
> >> + * However it can be accessed with the i2c-dev driver from user space.
> >> + */
> >
> > The comment format is wrong, and the part after r_i2c, about i2c-dev
> > and the mainline support is not really relevant. The DT describes the
> > hardware, and is used by several different projects that might or
> > might not have i2c-dev, an interface similar, or might have or not a
> > driver for the bridge.
>
> Comment is identical to sun50i-a64-teres-i.dts (which was merged few
> months ago).
> I'll remove everything but first sentence.
We don't notice everything unfortunately. Feel free to fix it in the
TERES-I DTS as well.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Maxime Ripard @ 2018-06-04 8:51 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, arm-linux, Icenowy Zheng
In-Reply-To: <CA+E=qVfH3wWsSdzGn353q0Jf-PQ8cjU-i5osLOV1c4qWVGrR5A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2678 bytes --]
On Fri, Jun 01, 2018 at 10:30:00AM -0700, Vasily Khoruzhick wrote:
> >> ---
> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +++++++++++++++++
> >> 1 file changed, 17 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> index 1b2ef28c42bd..b5e903ccf0ec 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> @@ -46,6 +46,7 @@
> >> #include <dt-bindings/clock/sun8i-r-ccu.h>
> >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> >> #include <dt-bindings/reset/sun50i-a64-ccu.h>
> >> +#include <dt-bindings/reset/sun8i-r-ccu.h>
> >>
> >> / {
> >> interrupt-parent = <&gic>;
> >> @@ -655,6 +656,17 @@
> >> #reset-cells = <1>;
> >> };
> >>
> >> + r_i2c: i2c@1f02400 {
> >> + compatible = "allwinner,sun6i-a31-i2c";
> >
> > You should add an a64 compatible here
>
> We don't have it for regular i2c, why should I add it here?
We miss some of them. Adding for i2c would make sense too.
> >> + reg = <0x01f02400 0x400>;
> >> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> >> + clocks = <&r_ccu CLK_APB0_I2C>;
> >> + resets = <&r_ccu RST_APB0_I2C>;
> >> + status = "disabled";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> +
> >> r_pio: pinctrl@1f02c00 {
> >> compatible = "allwinner,sun50i-a64-r-pinctrl";
> >> reg = <0x01f02c00 0x400>;
> >> @@ -670,6 +682,11 @@
> >> pins = "PL0", "PL1";
> >> function = "s_rsb";
> >> };
> >> +
> >> + r_i2c_pins_a: i2c-a {
> >> + pins = "PL8", "PL9";
> >> + function = "s_i2c";
> >> + };
> >
> > This should be ordered by alphabetical order
>
> OK
>
> > If this is the only muxing option, you can also add it to the i2c DT
> > node.
>
> It's not the only option, but other option conflicts with rsb. Should
> I still add it to i2c DT node?
I guess you can put it there, the muxing will only be enforced if the
device is enabled, and there should be only one of RSB or I2C that
would be.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Maxime Ripard @ 2018-06-04 9:09 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180601173527.18051-2-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
On Fri, Jun 01, 2018 at 11:05:27PM +0530, Jagan Teki wrote:
> Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi WL-WAKE-AP pin connected to gpio PL3
> - 32kHz external oscillator gate clock from RTC
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Applied both, thanks
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 5/5] ARM: dts: imx6qdl: add missing compatible and clock properties for EPIT
From: Clément Péron @ 2018-06-04 9:10 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Colin Didier, linux-arm-kernel, devicetree, linux-kernel,
Daniel Lezcano, Thomas Gleixner, Fabio Estevam, Sascha Hauer,
Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Clément Peron
In-Reply-To: <f71fe02d-23a7-a475-52df-62c17089549b@mentor.com>
Hi Vladimir,
On Thu, 31 May 2018 at 10:54, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
>
> Hi Clément,
>
> On 05/31/2018 11:41 AM, Clément Péron wrote:
> > Hi Vladimir,
> >
> > On Thu, 31 May 2018 at 10:33, Vladimir Zapolskiy
> > <vladimir_zapolskiy@mentor.com> wrote:
> >>
> >> On 05/30/2018 03:03 PM, Clément Péron wrote:
> >>> From: Colin Didier <colin.didier@devialet.com>
> >>>
> >>> Add missing compatible and clock properties for EPIT node.
> >>>
> >>> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> >>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> >>> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> >>> ---
> >>> arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> >>> index c003e62bf290..0feec516847a 100644
> >>> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> >>> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> >>> @@ -844,13 +844,23 @@
> >>> };
> >>>
> >>> epit1: epit@20d0000 { /* EPIT1 */
> >>
> >> epit1: timer@20d0000 { ...
> >>
> >> And /* EPIT1 */ comment can be removed, it is quite clear from the same
> >> line context.
> >>
> >> Formally it is a subject to another patch, but I think this can be
> >> accepted as a part of this one.
> >
> > Should I also update other boards ?
> > I only did it for imx6qdl.dtsi, but the EPIT is present in other boards
> > but i can't test it myself.
> >
>
> Sure, please do it, why not, it is quite a safe modification.
>
> One change per one dtsi file will suffice, and I see that imx25.dtsi
> already contains the requested change, however probably you may
> want to update its compatible = "fsl,imx25-epit" line.
>
> Regarding compatibles for other imx6* SoCs, I think all of them should
> be documented in fsl,imxepit.txt and then added to the correspondent
> dtsi files one per SoC.
Nvidia UART doc did this :
- For other Tegra, must contain '"nvidia,<chip>-uart",
"nvidia,tegra20-uart"' where <chip> is tegra30, tegra114, tegra124,
I will follow this.
>
> And I forgot the outcome of one former discussion with Uwe Kleine-König,
> but if my bad memory serves me, we agreed that i.MX25 was released later
> than i.MX31, so the most generic (the last value in the list) compatible
> should be a compatible with i.MX31 like in
>
> imx25.dtsi:367: compatible = "fsl,imx25-gpt", "fsl,imx31-gpt";
>
> --
> With best wishes,
> Vladimir
Regards,
Clement
^ permalink raw reply
* Re: [PATCH v4 01/10] i3c: Add core I3C infrastructure
From: Przemyslaw Gaj @ 2018-06-04 9:11 UTC (permalink / raw)
To: Boris Brezillon, Wolfram Sang, linux-i2c@vger.kernel.org,
Jonathan Corbet, linux-doc@vger.kernel.org, Greg Kroah-Hartman,
Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vitor Soares
In-Reply-To: <20180330074751.25987-2-boris.brezillon@bootlin.com>
Hi Boris
It looks great, just one comment to DEFSLVS command:
On 6/4/18, 9:32 AM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
+int i3c_master_defslvs_locked(struct i3c_master_controller *master)
+{
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = I3C_BROADCAST_ADDR,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .id = I3C_CCC_DEFSLVS,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ struct i3c_ccc_defslvs *defslvs;
+ struct i3c_ccc_dev_desc *desc;
+ struct i3c_device *i3cdev;
+ struct i2c_device *i2cdev;
+ struct i3c_bus *bus;
+ bool send = false;
+ int ndevs = 0, ret;
+
+ if (!master)
+ return -EINVAL;
+
+ bus = i3c_master_get_bus(master);
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ ndevs++;
+ if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
+ send = true;
+ }
+
+ /* No other master on the bus, skip DEFSLVS. */
+ if (!send)
+ return 0;
+
+ i3c_bus_for_each_i2cdev(bus, i2cdev)
+ ndevs++;
+
+ dest.payload.len = sizeof(*defslvs) +
+ ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
+ defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
+ if (!defslvs)
+ return -ENOMEM;
+
+ dest.payload.data = defslvs;
+
+ defslvs->count = ndevs;
+ defslvs->master.bcr = master->this->info.bcr;
+ defslvs->master.dcr = master->this->info.dcr;
+ defslvs->master.dyn_addr = master->this->info.dyn_addr;
+ defslvs->master.static_addr = I3C_BROADCAST_ADDR;
+
+ desc = defslvs->slaves;
+ i3c_bus_for_each_i2cdev(bus, i2cdev) {
+ desc->lvr = i2cdev->lvr;
+ desc->static_addr = i2cdev->info.addr;
+ desc++;
+ }
+
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ /* Skip the I3C dev representing this master. */
+ if (i3cdev == master->this)
+ continue;
+
+ desc->bcr = i3cdev->info.bcr;
+ desc->dcr = i3cdev->info.dcr;
+ desc->dyn_addr = i3cdev->info.dyn_addr;
+ desc->static_addr = i3cdev->info.static_addr;
+ desc++;
+ }
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ kfree(defslvs);
+
+ return ret;
+}
You should shift all the addresses (dynamic and static) one bit left.
Addresses are stored on bits [7:1], this is described in MIPI spec,
section 5.1.9.3.7 Define List of Slaves (DEFSLVS)
Regards,
Przemyslaw Gaj
^ permalink raw reply
* Re: [PATCH v4 4/5] clocksource: add driver for i.MX EPIT timer
From: Clément Péron @ 2018-06-04 9:21 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Colin Didier, linux-arm-kernel, devicetree, linux-kernel,
Daniel Lezcano, Thomas Gleixner, Fabio Estevam, Sascha Hauer,
Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Clément Peron
In-Reply-To: <677be207-67be-ccbc-8bb3-ab90bf9d05a7@mentor.com>
Hi Vladimir,
On Thu, 31 May 2018 at 10:36, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
>
> Hi Clément,
>
> On 05/30/2018 03:03 PM, Clément Péron wrote:
> > From: Colin Didier <colin.didier@devialet.com>
> >
> > Add driver for NXP's EPIT timer used in i.MX 6 family of SoC.
> >
> > Signed-off-by: Colin Didier <colin.didier@devialet.com>
> > Signed-off-by: Clément Peron <clement.peron@devialet.com>
> > ---
>
> [snip]
>
> > +++ b/drivers/clocksource/timer-imx-epit.c
> > @@ -0,0 +1,281 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * i.MX EPIT Timer
> > + *
> > + * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
> > + * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
> > + * Copyright (C) 2018 Clément Péron <clement.peron@devialet.com>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/clockchips.h>
> > +#include <linux/err.h>
>
> The included header above still can be removed.
Ok.
>
> I have no more comments about the code, I will try to find time to
> test the driver, but please don't take it as a promise.
Regarding the clks, i think the management of the ipg clk in the
driver is useless
has it is already handled by the imx clk driver.
I remove the ipg clk and test it on i.MX6Q.
My test is limited to disabled the GPT and enabled the EPIT in the device-tree
&gpt {
status = "disabled";
};
&epit1 {
status = "okay";
};
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.17.0-rc6 (cperon@cperon-Latitude-7490)
(gcc version 6.4.1 20170707 (Linaro GCC 6.4-2017.08)) #1 SMP PREEMPT
Mon Jun 4 11:13:41 CEST 2018
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: Devialet Aerobase
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] Normal zone: 2048 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 262144 pages, LIFO batch:31
[ 0.000000] random: get_random_bytes called from
start_kernel+0x80/0x398 with crng_init=0
[ 0.000000] percpu: Embedded 16 pages/cpu @(ptrval) s35084 r8192
d22260 u65536
[ 0.000000] pcpu-alloc: s35084 r8192 d22260 u65536 alloc=16*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260096
[ 0.000000] Kernel command line: console=ttymxc0,115200
root=/dev/nfs rw nfsroot=192.168.0.4:/opt/nfsroot,v3,tcp ip=dhcp
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 1029544K/1048576K available (6144K kernel code,
194K rwdata, 1312K rodata, 1024K init, 224K bss, 19032K reserved, 0K
cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.\x00
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000012] sched_clock: 32 bits at 66MHz, resolution 15ns, wraps
every 32537631224ns
[ 0.000032] clocksource: epit: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 28958491609 ns
[ 0.001231] Calibrating delay loop... 1560.57 BogoMIPS (lpj=780288)
[ 0.008161] pid_max: default: 32768 minimum: 301
[ 0.008336] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.008360] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.009042] CPU: Testing write buffer coherency: ok
[ 0.009506] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.014238] Setting up static identity map for 0x10100000 - 0x10100060
[ 0.015207] Hierarchical SRCU implementation.
[ 0.017208] smp: Bringing up secondary CPUs ...
[ 0.029147] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.041146] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.053146] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.053321] smp: Brought up 1 node, 4 CPUs
[ 0.053340] SMP: Total of 4 processors activated (6303.74 BogoMIPS).
[ 0.053349] CPU: All CPU(s) started in SVC mode.
[ 0.054441] devtmpfs: initialized
[ 0.063770] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[ 0.064454] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.064477] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.064742] pinctrl core: initialized pinctrl subsystem
[ 0.066693] NET: Registered protocol family 16
[ 0.068623] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.071654] cpuidle: using governor menu
[ 0.071802] CPU identified as i.MX6Q, silicon rev 1.2
>
> --
> With best wishes,
> Vladimir
^ permalink raw reply
* Re: [PATCH v4 07/10] i3c: master: Add driver for Cadence IP
From: Przemyslaw Gaj @ 2018-06-04 9:24 UTC (permalink / raw)
To: Boris Brezillon, Wolfram Sang, linux-i2c@vger.kernel.org,
Jonathan Corbet, linux-doc@vger.kernel.org, Greg Kroah-Hartman,
Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vitor Soares
In-Reply-To: <20180330074751.25987-8-boris.brezillon@bootlin.com>
Hi Boris,
Few things regarding Cadence IP driver:
On 6/4/18, 9:31 AM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
+static void cdns_i3c_master_handle_ibi(struct cdns_i3c_master *master,
+ u32 ibir)
+{
+ struct cdns_i3c_i2c_dev_data *data;
+ bool data_consumed = false;
+ struct i3c_ibi_slot *slot;
+ u32 id = IBIR_SLVID(ibir);
+ struct i3c_device *dev;
+ int len, i, j;
+ u8 *buf;
+
+ /*
+ * FIXME: maybe we should report the FIFO OVF errors to the upper
+ * layer.
+ */
+ if (id >= master->ibi.num_slots || (ibir & IBIR_ERROR))
+ goto out;
+
+ dev = master->ibi.slots[id];
+ spin_lock(&master->ibi.lock);
+
+ data = i3c_device_get_master_data(dev);
+ slot = i3c_generic_ibi_get_free_slot(data->ibi_pool);
+ if (!slot)
+ goto out_unlock;
+
+ buf = slot->data;
+
+ len = IBIR_XFER_BYTES(ibir);
+ for (i = 0; i < IBIR_XFER_BYTES(ibir); i += 4) {
+ u32 tmp = readl(master->regs + IBI_DATA_FIFO);
+
+ for (j = 0; j < 4 && i + j < dev->ibi->max_payload_len; j++)
+ buf[i + j] = tmp >> (j * 8);
+
+ }
+ slot->len = min_t(unsigned int, IBIR_XFER_BYTES(ibir),
+ dev->ibi->max_payload_len);
+ i3c_master_queue_ibi(dev, slot);
+ data_consumed = true;
+
+out_unlock:
+ spin_unlock(&master->ibi.lock);
+
+out:
+ /* Consume data from the FIFO if it's not been done already. */
+ if (!data_consumed) {
+ for (i = 0; i < IBIR_XFER_BYTES(ibir); i += 4)
+ readl(master->regs + IBI_DATA_FIFO);
+ }
+}
len variable is unneeded.
+static int cdns_i3c_master_probe(struct platform_device *pdev)
+{
+ struct cdns_i3c_master *master;
+ struct resource *res;
+ int ret, irq;
+ u32 val;
+
+ master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
+ if (!master)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ master->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(master->regs))
+ return PTR_ERR(master->regs);
+
+ master->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(master->pclk))
+ return PTR_ERR(master->pclk);
+
+ master->sysclk = devm_clk_get(&pdev->dev, "sysclk");
+ if (IS_ERR(master->pclk))
+ return PTR_ERR(master->pclk);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = clk_prepare_enable(master->pclk);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(master->sysclk);
+ if (ret)
+ goto err_disable_pclk;
+
+ if (readl(master->regs + DEV_ID) != DEV_ID_I3C_MASTER) {
+ ret = -EINVAL;
+ goto err_disable_sysclk;
+ }
+
+ spin_lock_init(&master->xferqueue.lock);
+ INIT_LIST_HEAD(&master->xferqueue.list);
+
+ INIT_WORK(&master->hj_work, cdns_i3c_master_hj);
+ writel(0xffffffff, master->regs + MST_IDR);
+ writel(0xffffffff, master->regs + SLV_IDR);
+ ret = devm_request_irq(&pdev->dev, irq, cdns_i3c_master_interrupt, 0,
+ dev_name(&pdev->dev), master);
+ if (ret)
+ goto err_disable_sysclk;
+
+ platform_set_drvdata(pdev, master);
+
+ val = readl(master->regs + CONF_STATUS0);
+
+ /* Device ID0 is reserved to describe this master. */
+ master->maxdevs = CONF_STATUS0_DEVS_NUM(val);
+ master->free_rr_slots = GENMASK(master->maxdevs, 1);
+
+ val = readl(master->regs + CONF_STATUS1);
+ master->caps.cmdfifodepth = CONF_STATUS1_CMD_DEPTH(val);
+ master->caps.rxfifodepth = CONF_STATUS1_RX_DEPTH(val);
+ master->caps.txfifodepth = CONF_STATUS1_TX_DEPTH(val);
+ master->caps.ibirfifodepth = 16;
IBI fifo depth is hardcoded. You can read this value from CONF_STATUS0 register.
+ master->caps.cmdrfifodepth = 16;
CMDR fifo depth is hardcoded. You can read this value from CONF_STATUS0 register also.
+
+ spin_lock_init(&master->ibi.lock);
+ master->ibi.num_slots = CONF_STATUS1_IBI_HW_RES(val);
+ master->ibi.slots = devm_kzalloc(&pdev->dev,
+ sizeof(*master->ibi.slots) *
+ master->ibi.num_slots,
+ GFP_KERNEL);
+ if (!master->ibi.slots)
+ goto err_disable_sysclk;
+
+ writel(IBIR_THR(1), master->regs + CMD_IBI_THR_CTRL);
+ writel(MST_INT_IBIR_THR, master->regs + MST_IER);
+ writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
+
+ ret = i3c_master_register(&master->base, &pdev->dev,
+ &cdns_i3c_master_ops, false);
+ if (ret)
+ goto err_disable_sysclk;
+
+ return 0;
+
+err_disable_sysclk:
+ clk_disable_unprepare(master->sysclk);
+
+err_disable_pclk:
+ clk_disable_unprepare(master->pclk);
+
+ return ret;
+}
Regards,
Przemyslaw Gaj
^ permalink raw reply
* Re: [PATCH v2 0/2] Add R8A77980/Condor I2C support
From: Simon Horman @ 2018-06-04 9:46 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Magnus Damm, Catalin Marinas,
Will Deacon, linux-renesas-soc, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <2a88f4e9-0a86-8e6f-0ef2-20913dc9431d@cogentembedded.com>
On Thu, May 31, 2018 at 11:18:57PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180529-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
> and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
> the Condor board.
Thanks, applied.
^ permalink raw reply
* RE: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Wen He @ 2018-06-04 9:53 UTC (permalink / raw)
To: Leo Li
Cc: vkoul@kernel.org, dmaengine@vger.kernel.org, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jiafei Pan, Jiaheng Fan
In-Reply-To: <CADRPPNRx2ePL1eteMboAZ7ZvoxrVO1Jn+Koo7TatLQyquymTiQ@mail.gmail.com>
> -----Original Message-----
> From: dmaengine-owner@vger.kernel.org
> [mailto:dmaengine-owner@vger.kernel.org] On Behalf Of Li Yang
> Sent: 2018年5月31日 2:51
> To: Wen He <wen.he_1@nxp.com>
> Cc: vkoul@kernel.org; dmaengine@vger.kernel.org; Rob Herring
> <robh+dt@kernel.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE
> TREE BINDINGS <devicetree@vger.kernel.org>; Jiafei Pan
> <jiafei.pan@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>
> Subject: Re: [v5 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for
> Layerscape SoCs
>
> On Fri, May 25, 2018 at 6:19 AM, Wen He <wen.he_1@nxp.com> wrote:
> > NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel
> > virtuallization by allowing DMA jobs to be enqueued into different
> > command queues.
> >
> > Note that this module depends on NXP DPAA.
> >
> > Signed-off-by: Wen He <wen.he_1@nxp.com>
> > Signed-off-by: Jiaheng Fan <jiaheng.fan@nxp.com>
> > ---
> > change in v5:
> > - Fixed the issues includes:
> > * add error handler which every function
> > * replace word to bit definition
> > * move global variable to struct definition
> > * add some comments to context
> >
> > change in v4:
> > - Fixed the issues that Vinod point out in the mail list.
> >
> > change in v3:
> > - Add 'depends on ARM || ARM64' in file 'drivers/dma/Kconfig'
> >
> > change in v2:
> > - Replace GPL V2 License details by SPDX tags
> > - Replace Freescale by NXP
> > - Reduce and optimize header file references
> > - Replace big_endian by feature in struct fsl_qdma_engine
> > - Replace struct fsl_qdma_format by struct fsl_qdma_ccdf
> > and struct fsl_qdma_csgf
> > - Remove empty line
> > - Replace 'if..else' by macro 'FSL_QDMA_IN/OUT' in function
> > qdma_readl() and qdma_writel()
> > - Remove function fsl_qdma_alloc_chan_resources()
> > - Replace 'prei' by 'pre'
> > - Replace '-1' by '-ENOMEM' in function
> fsl_qdma_pre_request_enqueue_desc()
> > - Fix dma pool allocation need to rolled back in function
> > fsl_qdma_request_enqueue_desc()
> > - Replace function of_property_read_u32_array() by
> device_property_read_u32_array()
> > - Add functions fsl_qdma_cleanup_vchan() and
> fsl_qdma_irq_exit() to ensure
> > irq and tasklets stopped
> > - Replace dts node element 'channels' by 'dma-channels'
> > - Replace function platform_driver_register() by
> > module_platform_driver()
> >
> > drivers/dma/Kconfig | 13 +
> > drivers/dma/Makefile | 1 +
> > drivers/dma/fsl-qdma.c | 1101
> > ++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 1115 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/dma/fsl-qdma.c
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index
> > 6d61cd0..99aff33 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -225,6 +225,19 @@ config FSL_EDMA
> > multiplexing capability for DMA request sources(slot).
> > This module can be found on Freescale Vybrid and LS-1 SoCs.
> >
> > +config FSL_QDMA
> > + tristate "NXP Layerscape qDMA engine support"
> > + depends on ARM || ARM64
> > + select DMA_ENGINE
> > + select DMA_VIRTUAL_CHANNELS
> > + select DMA_ENGINE_RAID
> > + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> > + help
> > + Support the NXP Layerscape qDMA engine with command
> queue and legacy mode.
> > + Channel virtualization is supported through enqueuing of DMA
> jobs to,
> > + or dequeuing DMA jobs from, different work queues.
> > + This module can be found on NXP Layerscape SoCs.
> > +
> > config FSL_RAID
> > tristate "Freescale RAID engine Support"
> > depends on FSL_SOC
> && !ASYNC_TX_ENABLE_CHANNEL_SWITCH diff
> > --git a/drivers/dma/Makefile b/drivers/dma/Makefile index
> > 0f62a4d..93db0fc 100644
> > --- a/drivers/dma/Makefile
> > +++ b/drivers/dma/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
> > obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
> > obj-$(CONFIG_FSL_DMA) += fsldma.o
> > obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
> > +obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o
> > obj-$(CONFIG_FSL_RAID) += fsl_raid.o
> > obj-$(CONFIG_HSU_DMA) += hsu/
> > obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o diff --git
> > a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c new file mode 100644
> > index 0000000..81df812
> > --- /dev/null
> > +++ b/drivers/dma/fsl-qdma.c
> > @@ -0,0 +1,1101 @@
>
> Not a critical issue, but the format of the file header looks a little bit weird to
> me. Would you mind clean it up?
>
Got it , you are right, Thanks.
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright 2018 NXP
>
> I know the SPDX tag is recommended to be the 1st line, but copyright normally
> goes below the file description not above.
>
> > +
>
> No newline needed.
>
> > +/*
> > + * Driver for NXP Layerscape Queue Direct Memory Access Controller
> > + *
> > + * Author:
> > + * Wen He <wen.he_1@nxp.com>
> > + * Jiaheng Fan <jiaheng.fan@nxp.com>
> > + *
>
> No newline needed.
>
> > + */
> > +
>
>
> Regards,
> Leo
All right, but Vinod recommend this kind of writing.
May be we need to discuss with Vinod.
Best Regards,
Wen
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.
> kernel.org%2Fmajordomo-info.html&data=02%7C01%7Cwen.he_1%40nxp.co
> m%7Cc1f3312f4d194cb4cd3708d5c65e562e%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C636633030836265801&sdata=jtehE%2FlHxajqzP7V
> 3gRBbCvEQvo3jMBBqlWOFxp55uA%3D&reserved=0
^ permalink raw reply
* Re: [PATCH V2 13/15] arm: dts: r8a77xx: Add missing OPP properties for CPUs
From: Simon Horman @ 2018-06-04 9:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, biju.das, Magnus Damm, Rob Herring, Mark Rutland,
Vincent Guittot, ionela.voinescu, Daniel Lezcano, chris.redpath,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <c6254ebb1f177468db6b8ac560ffb5a4a0b864f0.1527655562.git.viresh.kumar@linaro.org>
On Wed, May 30, 2018 at 10:16:58AM +0530, Viresh Kumar wrote:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
>
> Add such missing properties.
>
> Fix other missing properties (like, clock latency, voltage tolerance,
> etc) as well to make it all work.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Thanks, I took the liberty of changing the prefix of this patch to
"ARM: dts: r8a77(43|9[013]):" when applying this patch.
^ permalink raw reply
* [PATCH v5 0/4] Reintroduce i.MX EPIT Timer
From: Clément Péron @ 2018-06-04 10:00 UTC (permalink / raw)
To: Colin Didier, linux-arm-kernel, devicetree, linux-kernel
Cc: Daniel Lezcano, Thomas Gleixner, Fabio Estevam,
Vladimir Zapolskiy, Sascha Hauer, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Clément Peron
From: Clément Peron <clement.peron@devialet.com>
As suggested in the commit message we have added the device tree support,
proper bindings and we moved the driver into the correct folder.
Moreover we made some changes like use of relaxed IO accesor,
implement sched_clock, delay_timer and reduce the clockevents min_delta.
Changes since v4:
- removed ipg clk
- change in dt epit to timer
- add introduction in doc
- add all compatibles in doc
- update epit entry for other i.MX device-trees
Changes since v3:
- Clean Kconfig
- Rename imx6q-epit to imx31-epit
- Update doc and bindings
- Indent and fix
Changes since v2 (Thanks Fabio Estevam):
- Removed unused ckil clock
- Add out_iounmap
- Check and handle if clk_prepare_enable failed
- Fix comment typo
Changes since v1 (Thanks Vladimir Zapolskiy):
- Add OF dependency in Kconfig
- Sort header
- Use BIT macro
- Remove useless comments
- Fix incorrect indent
- Fix memory leak
- Add check and handle possible returned error
Clément Peron (2):
ARM: imx: remove inexistant EPIT timer init
dt-bindings: timer: add i.MX EPIT timer binding
Colin Didier (2):
clocksource: add driver for i.MX EPIT timer
ARM: dts: imx: add missing compatible and clock properties for EPIT
.../devicetree/bindings/timer/fsl,imxepit.txt | 21 ++
arch/arm/boot/dts/imx25.dtsi | 8 +-
arch/arm/boot/dts/imx6qdl.dtsi | 10 +-
arch/arm/boot/dts/imx6sl.dtsi | 14 +-
arch/arm/boot/dts/imx6sx.dtsi | 10 +-
arch/arm/boot/dts/imx6ul.dtsi | 10 +-
arch/arm/mach-imx/common.h | 1 -
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-imx-epit.c | 265 ++++++++++++++++++
10 files changed, 338 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
create mode 100644 drivers/clocksource/timer-imx-epit.c
--
2.17.0
^ permalink raw reply
* [PATCH v5 1/4] ARM: imx: remove inexistant EPIT timer init
From: Clément Péron @ 2018-06-04 10:00 UTC (permalink / raw)
To: Colin Didier, linux-arm-kernel, devicetree, linux-kernel
Cc: Rob Herring, Sascha Hauer, Daniel Lezcano, Clément Peron,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
Thomas Gleixner, Vladimir Zapolskiy
In-Reply-To: <20180604100035.19558-1-peron.clem@gmail.com>
From: Clément Peron <clement.peron@devialet.com>
i.MX EPIT timer has been removed but not the init function declaration.
Signed-off-by: Clément Peron <clement.peron@devialet.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/common.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c8d68e918b2f..18aae76fa2da 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -38,7 +38,6 @@ void imx21_soc_init(void);
void imx27_soc_init(void);
void imx31_soc_init(void);
void imx35_soc_init(void);
-void epit_timer_init(void __iomem *base, int irq);
int mx21_clocks_init(unsigned long lref, unsigned long fref);
int mx27_clocks_init(unsigned long fref);
int mx31_clocks_init(unsigned long fref);
--
2.17.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-04 10:00 UTC (permalink / raw)
To: Colin Didier, linux-arm-kernel, devicetree, linux-kernel
Cc: Rob Herring, Sascha Hauer, Daniel Lezcano, Clément Peron,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
Thomas Gleixner, Vladimir Zapolskiy
In-Reply-To: <20180604100035.19558-1-peron.clem@gmail.com>
From: Clément Peron <clement.peron@devialet.com>
Add devicetree binding document for NXP's i.MX SoC specific
EPIT timer driver.
Signed-off-by: Clément Peron <clement.peron@devialet.com>
---
.../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
diff --git a/Documentation/devicetree/bindings/timer/fsl,imxepit.txt b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
new file mode 100644
index 000000000000..de2e6ef68d24
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,imxepit.txt
@@ -0,0 +1,21 @@
+Binding for the i.MX Enhanced Periodic Interrupt Timer (EPIT)
+
+The Enhanced Periodic Interrupt Timer (EPIT) is a 32-bit set-and-forget timer
+that is capable of providing precise interrupts at regular intervals with
+minimal processor intervention.
+
+Required properties:
+- compatible: should be "fsl,<chip>-epit", "fsl,imx31-epit" where <chip> is
+ imx25, imx6qdl, imx6sl, imx6sul or imx6sx.
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- interrupts: Should contain EPIT controller interrupt
+- clocks : The clock provided by the SoC to drive the timer.
+
+Example for i.MX6QDL:
+ epit1: epit@20d0000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
+ reg = <0x020d0000 0x4000>;
+ interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT1>;
+ };
--
2.17.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/4] clocksource: add driver for i.MX EPIT timer
From: Clément Péron @ 2018-06-04 10:00 UTC (permalink / raw)
To: Colin Didier, linux-arm-kernel, devicetree, linux-kernel
Cc: Daniel Lezcano, Thomas Gleixner, Fabio Estevam,
Vladimir Zapolskiy, Sascha Hauer, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Clément Peron
In-Reply-To: <20180604100035.19558-1-peron.clem@gmail.com>
From: Colin Didier <colin.didier@devialet.com>
Add driver for NXP's EPIT timer used in i.MX SoC.
Signed-off-by: Colin Didier <colin.didier@devialet.com>
Signed-off-by: Clément Peron <clement.peron@devialet.com>
---
drivers/clocksource/Kconfig | 11 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-imx-epit.c | 265 +++++++++++++++++++++++++++
3 files changed, 277 insertions(+)
create mode 100644 drivers/clocksource/timer-imx-epit.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 8e8a09755d10..790478afd02c 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -576,6 +576,17 @@ config H8300_TPU
This enables the clocksource for the H8300 platform with the
H8S2678 cpu.
+config CLKSRC_IMX_EPIT
+ bool "Clocksource using i.MX EPIT"
+ depends on CLKDEV_LOOKUP && (ARCH_MXC || COMPILE_TEST)
+ select CLKSRC_MMIO
+ help
+ This enables EPIT support available on some i.MX platforms.
+ Normally you don't have a reason to do so as the EPIT has
+ the same features and uses the same clocks as the GPT.
+ Anyway, on some systems the GPT may be in use for other
+ purposes.
+
config CLKSRC_IMX_GPT
bool "Clocksource using i.MX GPT" if COMPILE_TEST
depends on ARM && CLKDEV_LOOKUP
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 00caf37e52f9..d9426f69ec69 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_INTEGRATOR_AP_TIMER) += timer-integrator-ap.o
obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
+obj-$(CONFIG_CLKSRC_IMX_EPIT) += timer-imx-epit.o
obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
diff --git a/drivers/clocksource/timer-imx-epit.c b/drivers/clocksource/timer-imx-epit.c
new file mode 100644
index 000000000000..15f70e210fad
--- /dev/null
+++ b/drivers/clocksource/timer-imx-epit.c
@@ -0,0 +1,265 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * i.MX EPIT Timer
+ *
+ * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
+ * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
+ * Copyright (C) 2018 Clément Péron <clement.peron@devialet.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#define EPITCR 0x00
+#define EPITSR 0x04
+#define EPITLR 0x08
+#define EPITCMPR 0x0c
+#define EPITCNR 0x10
+
+#define EPITCR_EN BIT(0)
+#define EPITCR_ENMOD BIT(1)
+#define EPITCR_OCIEN BIT(2)
+#define EPITCR_RLD BIT(3)
+#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
+#define EPITCR_SWR BIT(16)
+#define EPITCR_IOVW BIT(17)
+#define EPITCR_DBGEN BIT(18)
+#define EPITCR_WAITEN BIT(19)
+#define EPITCR_RES BIT(20)
+#define EPITCR_STOPEN BIT(21)
+#define EPITCR_OM_DISCON (0 << 22)
+#define EPITCR_OM_TOGGLE (1 << 22)
+#define EPITCR_OM_CLEAR (2 << 22)
+#define EPITCR_OM_SET (3 << 22)
+#define EPITCR_CLKSRC_OFF (0 << 24)
+#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
+#define EPITCR_CLKSRC_REF_HIGH (2 << 24)
+#define EPITCR_CLKSRC_REF_LOW (3 << 24)
+
+#define EPITSR_OCIF BIT(0)
+
+struct epit_timer {
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+ struct clock_event_device ced;
+ struct irqaction act;
+};
+
+static void __iomem *sched_clock_reg;
+
+static inline struct epit_timer *to_epit_timer(struct clock_event_device *ced)
+{
+ return container_of(ced, struct epit_timer, ced);
+}
+
+static inline void epit_irq_disable(struct epit_timer *epittm)
+{
+ u32 val;
+
+ val = readl_relaxed(epittm->base + EPITCR);
+ writel_relaxed(val & ~EPITCR_OCIEN, epittm->base + EPITCR);
+}
+
+static inline void epit_irq_enable(struct epit_timer *epittm)
+{
+ u32 val;
+
+ val = readl_relaxed(epittm->base + EPITCR);
+ writel_relaxed(val | EPITCR_OCIEN, epittm->base + EPITCR);
+}
+
+static void epit_irq_acknowledge(struct epit_timer *epittm)
+{
+ writel_relaxed(EPITSR_OCIF, epittm->base + EPITSR);
+}
+
+static u64 notrace epit_read_sched_clock(void)
+{
+ return ~readl_relaxed(sched_clock_reg);
+}
+
+static int epit_set_next_event(unsigned long cycles,
+ struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long tcmp;
+
+ tcmp = readl_relaxed(epittm->base + EPITCNR) - cycles;
+ writel_relaxed(tcmp, epittm->base + EPITCMPR);
+
+ return 0;
+}
+
+/* Left event sources disabled, no more interrupts appear */
+static int epit_shutdown(struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long flags;
+
+ /*
+ * The timer interrupt generation is disabled at least
+ * for enough time to call epit_set_next_event()
+ */
+ local_irq_save(flags);
+
+ /* Disable interrupt in EPIT module */
+ epit_irq_disable(epittm);
+
+ /* Clear pending interrupt */
+ epit_irq_acknowledge(epittm);
+
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static int epit_set_oneshot(struct clock_event_device *ced)
+{
+ struct epit_timer *epittm = to_epit_timer(ced);
+ unsigned long flags;
+
+ /*
+ * The timer interrupt generation is disabled at least
+ * for enough time to call epit_set_next_event()
+ */
+ local_irq_save(flags);
+
+ /* Disable interrupt in EPIT module */
+ epit_irq_disable(epittm);
+
+ /* Clear pending interrupt, only while switching mode */
+ if (!clockevent_state_oneshot(ced))
+ epit_irq_acknowledge(epittm);
+
+ /*
+ * Do not put overhead of interrupt enable/disable into
+ * epit_set_next_event(), the core has about 4 minutes
+ * to call epit_set_next_event() or shutdown clock after
+ * mode switching
+ */
+ epit_irq_enable(epittm);
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *ced = dev_id;
+ struct epit_timer *epittm = to_epit_timer(ced);
+
+ epit_irq_acknowledge(epittm);
+
+ ced->event_handler(ced);
+
+ return IRQ_HANDLED;
+}
+
+static int __init epit_clocksource_init(struct epit_timer *epittm)
+{
+ unsigned int c = clk_get_rate(epittm->clk);
+
+ sched_clock_reg = epittm->base + EPITCNR;
+ sched_clock_register(epit_read_sched_clock, 32, c);
+
+ return clocksource_mmio_init(epittm->base + EPITCNR, "epit", c, 200, 32,
+ clocksource_mmio_readl_down);
+}
+
+static int __init epit_clockevent_init(struct epit_timer *epittm)
+{
+ struct clock_event_device *ced = &epittm->ced;
+ struct irqaction *act = &epittm->act;
+
+ ced->name = "epit";
+ ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
+ ced->set_state_shutdown = epit_shutdown;
+ ced->tick_resume = epit_shutdown;
+ ced->set_state_oneshot = epit_set_oneshot;
+ ced->set_next_event = epit_set_next_event;
+ ced->rating = 200;
+ ced->cpumask = cpumask_of(0);
+ ced->irq = epittm->irq;
+ clockevents_config_and_register(ced, clk_get_rate(epittm->clk),
+ 0xff, 0xfffffffe);
+
+ act->name = "i.MX EPIT Timer Tick",
+ act->flags = IRQF_TIMER | IRQF_IRQPOLL;
+ act->handler = epit_timer_interrupt;
+ act->dev_id = ced;
+
+ /* Make irqs happen */
+ return setup_irq(epittm->irq, act);
+}
+
+static int __init epit_timer_init(struct device_node *np)
+{
+ struct epit_timer *epittm;
+ int ret;
+
+ epittm = kzalloc(sizeof(*epittm), GFP_KERNEL);
+ if (!epittm)
+ return -ENOMEM;
+
+ epittm->base = of_iomap(np, 0);
+ if (!epittm->base) {
+ ret = -ENXIO;
+ goto out_kfree;
+ }
+
+ epittm->irq = irq_of_parse_and_map(np, 0);
+ if (!epittm->irq) {
+ ret = -EINVAL;
+ goto out_iounmap;
+ }
+
+ /* Get EPIT clock */
+ epittm->clk = of_clk_get(np, 0);
+ if (IS_ERR(epittm->clk)) {
+ pr_err("i.MX EPIT: unable to get clk\n");
+ ret = PTR_ERR(epittm->clk);
+ goto out_iounmap;
+ }
+
+ ret = clk_prepare_enable(epittm->clk);
+ if (ret) {
+ pr_err("i.MX EPIT: unable to prepare+enable clk\n");
+ goto out_iounmap;
+ }
+
+ /* Initialise to a known state (all timers off, and timing reset) */
+ writel_relaxed(0x0, epittm->base + EPITCR);
+ writel_relaxed(0xffffffff, epittm->base + EPITLR);
+ writel_relaxed(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
+ epittm->base + EPITCR);
+
+ ret = epit_clocksource_init(epittm);
+ if (ret) {
+ pr_err("i.MX EPIT: failed to init clocksource\n");
+ goto out_clk_disable;
+ }
+
+ ret = epit_clockevent_init(epittm);
+ if (ret) {
+ pr_err("i.MX EPIT: failed to init clockevent\n");
+ goto out_clk_disable;
+ }
+
+ return 0;
+
+out_clk_disable:
+ clk_disable_unprepare(epittm->clk);
+out_iounmap:
+ iounmap(epittm->base);
+out_kfree:
+ kfree(epittm);
+
+ return ret;
+}
+TIMER_OF_DECLARE(epit_timer, "fsl,imx31-epit", epit_timer_init);
--
2.17.0
^ permalink raw reply related
* [PATCH v5 4/4] ARM: dts: imx: add missing compatible and clock properties for EPIT
From: Clément Péron @ 2018-06-04 10:00 UTC (permalink / raw)
To: Colin Didier, linux-arm-kernel, devicetree, linux-kernel
Cc: Rob Herring, Sascha Hauer, Daniel Lezcano, Clément Peron,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
Thomas Gleixner, Vladimir Zapolskiy
In-Reply-To: <20180604100035.19558-1-peron.clem@gmail.com>
From: Colin Didier <colin.didier@devialet.com>
Add missing compatible and clock properties for EPIT node.
Signed-off-by: Colin Didier <colin.didier@devialet.com>
Signed-off-by: Clément Peron <clement.peron@devialet.com>
---
arch/arm/boot/dts/imx25.dtsi | 8 ++++++--
arch/arm/boot/dts/imx6qdl.dtsi | 10 ++++++++--
arch/arm/boot/dts/imx6sl.dtsi | 14 ++++++++++----
arch/arm/boot/dts/imx6sx.dtsi | 10 ++++++++--
arch/arm/boot/dts/imx6ul.dtsi | 10 ++++++++--
5 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cf70df20b19c..15fd4308dad8 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -396,15 +396,19 @@
};
epit1: timer@53f94000 {
- compatible = "fsl,imx25-epit";
+ compatible = "fsl,imx25-epit", "fsl,imx31-epit";
reg = <0x53f94000 0x4000>;
interrupts = <28>;
+ clocks = <&clks 83>;
+ status = "disabled";
};
epit2: timer@53f98000 {
- compatible = "fsl,imx25-epit";
+ compatible = "fsl,imx25-epit", "fsl,imx31-epit";
reg = <0x53f98000 0x4000>;
interrupts = <27>;
+ clocks = <&clks 84>;
+ status = "disabled";
};
gpio4: gpio@53f9c000 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index c003e62bf290..65c4ee07454c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -843,14 +843,20 @@
};
};
- epit1: epit@20d0000 { /* EPIT1 */
+ epit1: timer@20d0000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit@20d4000 { /* EPIT2 */
+ epit2: timer@20d4000 {
+ compatible = "fsl,imx6qdl-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_EPIT2>;
+ status = "disabled";
};
src: src@20d8000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index ab6a7e2e7e8f..6229bbef7ccc 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -671,14 +671,20 @@
};
};
- epit1: epit@20d0000 {
+ epit1: timer@20d0000 {
+ compatible = "fsl,imx6sl-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
- interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit@20d4000 {
+ epit2: timer@20d4000 {
+ compatible = "fsl,imx6sl-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
- interrupts = <0 57 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SL_CLK_EPIT2>;
+ status = "disabled";
};
src: src@20d8000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205b8db8..2b30559d3270 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -736,14 +736,20 @@
};
};
- epit1: epit@20d0000 {
+ epit1: timer@20d0000 {
+ compatible = "fsl,imx6sx-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SX_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit@20d4000 {
+ epit2: timer@20d4000 {
+ compatible = "fsl,imx6sx-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SX_CLK_EPIT2>;
+ status = "disabled";
};
src: src@20d8000 {
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 1241972b16ba..d5f765da1ee2 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -658,14 +658,20 @@
};
};
- epit1: epit@20d0000 {
+ epit1: timer@20d0000 {
+ compatible = "fsl,imx6ul-epit", "fsl,imx31-epit";
reg = <0x020d0000 0x4000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_EPIT1>;
+ status = "disabled";
};
- epit2: epit@20d4000 {
+ epit2: timer@20d4000 {
+ compatible = "fsl,imx6ul-epit", "fsl,imx31-epit";
reg = <0x020d4000 0x4000>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6UL_CLK_EPIT2>;
+ status = "disabled";
};
src: src@20d8000 {
--
2.17.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 0/9] Add support for SAMA5D2 touchscreen
From: Jonathan Cameron @ 2018-06-04 10:04 UTC (permalink / raw)
To: Eugen Hristev, Jonathan Cameron
Cc: devicetree, alexandre.belloni, robh, linux-iio, dmitry.torokhov,
linux-kernel, ludovic.desroches, linux-input, linux-arm-kernel
In-Reply-To: <45ff713b-7811-22c6-2124-4fbcad59b7e8@microchip.com>
On 4 June 2018 07:15:57 BST, Eugen Hristev <eugen.hristev@microchip.com> wrote:
>
>
>On 22.05.2018 20:57, Jonathan Cameron wrote:
>> On Tue, 22 May 2018 10:52:30 +0300
>> Eugen Hristev <eugen.hristev@microchip.com> wrote:
>>
>>> Hello,
>>>
>>> This patch series is a rework of my previous series named:
>>> [PATCH 00/14] iio: triggers: add consumer support
>>>
>>> This is the version 7 of the series, and addresses the received
>feedback
>>> on the v2 series named:
>>> [PATCH v2 00/10] Add support for SAMA5D2 touchscreen
>>> and the v3 series named
>>> [PATCH v3 00/11] Add support for SAMA5D2 touchscreen
>>> and the v4 series named
>>> [PATCH v4 0/9] Add support for SAMA5D2 touchscreen
>>> and fixes one bug found in series named
>>> [PATCH v5 0/9] Add support for SAMA5D2 touchscreen
>>> and addresses comments in series named
>>> [PATCH v6 0/9] Add support for SAMA5D2 touchscreen
>>>
>>> This series applies on top of fixes-togreg branch of iio.git,
>>> specifically on top of commit:
>>> "f0c8d1f" : iio: adc: at91-sama5d2_adc:
>>> fix channel configuration for differential channels
>>>
>>> Jonathan, if you need me to rebase this on top of testing, let me
>know.
>>>
>>> Changes in previous versions are presented at the end of the cover
>letter below.
>>> Thanks everyone for the feedback. Below is the original v2 cover
>letter:
>>>
>>> In few words, this is the implementation of splitting the
>functionality
>>> of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
>>> support. In order to avoid having a MFD device, two separate
>>> drivers that would work on same register base and split the IRQ,etc,
>>> as advised on the mailing list, I created a consumer driver for the
>>> channels, that will connect to the ADC as described in the device
>tree.
>>>
>>> I have collected feedback from everyone and here is the result:
>>> I have added a new generic resistive touchscreen driver, which acts
>>> as a iio consumer for the given channels and will create an input
>>> device and report the events. It uses a callback buffer to register
>>> to the IIO device and waits for data to be pushed.
>>> Inside the IIO device, I have kept a similar approach with the first
>version
>>> of the series, except that now the driver can take multiple buffers,
>and
>>> will configure the touchscreen part of the hardware device if the
>specific
>>> channels are requested.
>>>
>>> The SAMA5D2 ADC driver registers three new channels: two for the
>>> position on the X and Y axis, and one for the touch pressure.
>>> When channels are requested, it will check if the touchscreen
>channel mask
>>> includes the requested channels (it is possible that the consumer
>driver
>>> will not request pressure for example). If it's the case, it will
>work
>>> in touchscreen mode, and will refuse to do usual analog-digital
>conversion,
>>> because we have a single trigger and the touchscreen needs it.
>>> When the scan mask will include only old channels, the driver will
>function
>>> in the same way as before. If the scan mask somehow is a mix of the
>two (the
>>> masks intersect), the driver will refuse to work whatsoever (cannot
>have both
>>> in the same time).
>>> The driver allows reading raw data for the new channels, if claim
>direct
>>> mode works: no touchscreen driver requested anything. The new
>channels can
>>> act like the old ones. However, when requesting these channels, the
>usual
>>> trigger will not work and will not be enabled. The touchscreen
>channels
>>> require special trigger and irq configuration: pen detect, no pen
>detect
>>> and a periodic trigger to sample the touchscreen position and
>pressure.
>>> If the user attempts to use another trigger while there is a buffer
>>> that already requested the touchscreen channels (thus the trigger),
>the
>>> driver will refuse to comply.
>>>
>>> In order to have defines for the channel numbers, I added a bindings
>include
>>> file that goes on a separate commit :
>>> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific
>consumer info
>>> This should go in the same tree with the following commits :
>>> ARM: dts: at91: sama5d2: add channel cells for ADC device
>>> ARM: dts: at91: sama5d2: Add resistive touch device
>>>
>>> as build will break because these commits depend on the binding one
>>> which creates the included header file.
>>> V5 update: After discussing with Alexandre Belloni on Mailing list,
>the two
>>> DTS patches are to be taken in the next version after bindings reach
>mainline.
>>>
>>> Changes in v7:
>>> - Addressed some feedback from Dmitry, explained in input driver
>patch
>>> changelog.
>>> - Added Acked-by Dmitry.
>>>
>>> Changes in v6:
>>> - Fixed a crash in ADC driver , explained in driver patch
>changelog.
>>> - changed a dev_err to dev_dbg in input driver.
>>> - added Reviewed-by Rob Herring.
>>>
>>> Changes in v5:
>>> - renamed property touchscreen-threshold-pressure to
>touchscreen-min-pressure
>>> - added one return in touchscreen driver
>>>
>>> Changes in v4:
>>> - removed patch for inkern module get/set kref
>>> - addressed feedback on both the ADC and the touchscreen driver.
>each
>>> patch has a history inside the patch file for the specific changes.
>>> - patch that fixes the channel fix
>>> [PATCH v3 01/11] iio: adc: at91-sama5d2_adc:
>>> fix channel configuration for differential channels
>>> was accepted in fixes-togreg branch thus removed from this series.
>>> - added Reviewed-by for the bindings by Rob Herring
>>>
>>> Changes in v3:
>>> - changed input driver name according to feedback and reworked in
>commits
>>> to adapt to binding changes and new name.
>>> - moved channel index fix in at91-sama5d2_adc at the beginning of
>the series
>>> (PATCH 01/11)
>>> - created a new optional binding for the touchscreen as a separate
>commit
>>> and added it to the series :
>>> [PATCH v3 04/11] dt-bindings: input: touchscreen: add pressure
>>> threshold touchscreen property
>>> - changed at91-sama5d2_adc driver patch to address the comments.
>Exact changes
>>> are in the patch file for the driver source file.
>>>
>>> Eugen Hristev (9):
>>> MAINTAINERS: add generic resistive touchscreen adc
>>> iio: Add channel for Position Relative
>>> dt-bindings: input: touchscreen: add minimum pressure touchscreen
>>> property
>>> dt-bindings: input: touchscreen: resistive-adc-touch: create
>bindings
>>> iio: adc: at91-sama5d2_adc: add support for position and pressure
>>> channels
>>> input: touchscreen: resistive-adc-touch: add generic resistive
>ADC
>>> touchscreen
>>> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific
>consumer
>>> info
>>> ARM: dts: at91: sama5d2: add channel cells for ADC device
>>> ARM: dts: at91: sama5d2: Add resistive touch device
>>>
>>> Documentation/ABI/testing/sysfs-bus-iio | 12 +
>>> .../bindings/iio/adc/at91-sama5d2_adc.txt | 9 +
>>> .../input/touchscreen/resistive-adc-touch.txt | 30 +
>>> .../bindings/input/touchscreen/touchscreen.txt | 3 +
>>> MAINTAINERS | 6 +
>>> arch/arm/boot/dts/sama5d2.dtsi | 12 +
>>> drivers/iio/adc/at91-sama5d2_adc.c | 609
>+++++++++++++++++++--
>>> drivers/iio/industrialio-core.c | 1 +
>>> drivers/input/touchscreen/Kconfig | 13 +
>>> drivers/input/touchscreen/Makefile | 1 +
>>> drivers/input/touchscreen/resistive-adc-touch.c | 204 +++++++
>>> include/dt-bindings/iio/adc/at91-sama5d2_adc.h | 16 +
>>> include/uapi/linux/iio/types.h | 1 +
>>> tools/iio/iio_event_monitor.c | 2 +
>>> 14 files changed, 861 insertions(+), 58 deletions(-)
>>> create mode 100644
>Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
>>> create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c
>>> create mode 100644 include/dt-bindings/iio/adc/at91-sama5d2_adc.h
>>>
>>
>> Hi All,
>>
>> I'm happy to take this, but there is a slight issue that we have a
>fix working
>> it's way in which this is dependent on.
>>
>> I'll see if we can get this sorted before the merge window, but we
>may be
>> cutting it fine.
>>
>> Jonathan
>>
>
>Hello Jonathan,
>
>I can see the dependency fix made it to 4.17. What is the plan for this
>
>series? Getting into this merge window ?
Sorry, no. We were to tight on time. Will get it into linux-next in a few weeks, ready for the next merge window.
Jonathan
>
>Thanks,
>Eugen
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v8 2/4] dt-bindings: Add bindings for SPI NAND devices
From: Boris Brezillon @ 2018-06-04 10:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pawel Moll, Ian Campbell, Richard Weinberger, Kumar Gala,
Rob Herring, linux-spi, Marek Vasut, Mark Brown, MTD Maling List,
Miquel Raynal, Brian Norris, David Woodhouse
In-Reply-To: <CAMuHMdWqa4++tdrpWCAsdqjqN26CHB1+eudnCtsP2vcrzmkA_w@mail.gmail.com>
On Fri, 1 Jun 2018 19:40:00 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Boris,
>
> On Fri, Jun 1, 2018 at 7:09 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Fri, 1 Jun 2018 16:42:26 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Fri, Jun 1, 2018 at 3:13 PM, Boris Brezillon
> >> <boris.brezillon@bootlin.com> wrote:
> >> > Add bindings for SPI NAND chips.
>
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> >> > @@ -0,0 +1,27 @@
> >> > +SPI NAND flash
> >> > +
> >> > +Required properties:
> >> > +- compatible: should be "spi-nand"
> >> > +- reg: should encode the chip-select line used to access the NAND chip
> >> > +
> >> > +Optional properties
> >> > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at.
> >> > + This should encode board limitations (i.e. max freq can't
> >> > + be achieved due to crosstalk on IO lines).
> >> > + When unspecified, the driver assumes the chip can run at
> >> > + the max frequency defined in the spec (information
> >> > + extracted chip detection time).
> >>
> >> This is a standard property according to
> >> Documentation/devicetree/bindings/spi/spi-bus.txt. Can't you just refer
> >> to that file, or just omit it, as it applies to all SPI slaves anyway?
> >
> > The thing is, the maximum frequency supported by a SPI NAND is directly
> > encoded in the NAND device ID and can be auto-detected. Why should we
> > define spi-max-frequency in the DT when we can automatically detect
> > this information? The only reason one might want to override
>
> Because that's how we dealt with this traditionally. Or at least I thought so.
> But include/linux/spi/spi.h says:
>
> * @max_speed_hz: Maximum clock rate to be used with this chip
> * (on this board); may be changed by the device's driver.
> * The spi_transfer.speed_hz can override this for each transfer.
>
> and many drivers seem to do so.
>
> > spi-max-frequency is when the board design impose such restrictions,
> > hence the precision I give here.
>
> Which is exactly the meaning of the standard property, isn't it?
>
> So I think it can just be omitted here anyway. If it's present, the SPI
> core will make sure it's taken into account.
>
> >> > +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI.
> >> > + Only encodes the board constraints (i.e. when not all IO
> >> > + signals are routed on the board). Device constraints are
> >> > + extracted when detecting the chip, and controller
> >> > + constraints are exposed by the SPI mem controller. If this
> >> > + property is missing that means no constraint at the board
> >> > + level.
> >> > +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO.
> >> > + Only encodes the board constraints (i.e. when not all IO
> >> > + signals are routed on the board). Device constraints are
> >> > + extracted when detecting the chip, and controller
> >> > + constraints are exposed by the SPI mem controller. If this
> >> > + property is missing that means no constraint at the board
> >> > + level.
> >>
> >> This does not match Documentation/devicetree/bindings/spi/spi-bus.txt,
> >> which says the default is 1.
> >
> > Yes, I know.
> >
> >> As these properties are handled by the SPI core in of_spi_parse_dt, why
> >> would you want to deviate?
> >
> > Because, again, this information can be extracted from the NAND ID, and
> > the only reason we might want to override the information extracted
> > from the NAND ID is when the board design adds extra restrictions
> > (like, only 2 SIO lines wired on the 4 available).
>
> In struct spi_device, this is specified using the SPI_[RT]_X_{DUAL,QUAD}
> bits in the mode field. Documentation says:
>
> * @mode: The spi mode defines how data is clocked out and in.
> * This may be changed by the device's driver.
> * The "active low" default for chipselect mode can be overridden
> * (by specifying SPI_CS_HIGH) as can the "MSB first" default for
> * each word in a transfer (by specifying SPI_LSB_FIRST).
>
> So this may also be specified by the device driver, but it seems no driver
> does so for the dual/quad bits, except for drivers/mtd/spi-nor/nxp-spifi.c
> (for rx only).
>
> But here we do have the generic SPI DT bindings saying the default is 1.
> So personally, I wouldn't go for the option of the least surprise, and
> don't deviate from the generic bindings.
>
> >> Commenting to the question in the cover letter: what would be the
> >> purpose of spi-max-bus-width?
> >
> > Defining how many IO lines are wired on the board design. If this
> > property is missing we would assume all IO lines are wired and the
> > restrictions would be negotiated between the controller and the device
> > without requiring explicit description in the DT.
>
> Which is exactly the meaning of the standard property, except for the
> default of all vs. 1.
>
> I'll have to defer to Mark (broonie) for his opinion about deviating from
> the way this is handled traditionally, and assuming different defaults...
I think I'll drop the extra description on spi-max-frequency and
spi-{rx,tx}-bus-width props for now. Those are anyway not taken into
account by the SPI NAND driver yet.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 01/13] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips
From: Marcel Holtmann @ 2018-06-04 10:17 UTC (permalink / raw)
To: Hans de Goede
Cc: Rob Herring, Johan Hedberg, Martin Blumenstingl, Jeremy Cline,
BlueZ development, linux-serial, linux-acpi, devicetree
In-Reply-To: <0d99e890-b93c-df55-ae43-8fc910778243@redhat.com>
Hi Hans,
>>>>> This adds the documentation for Bluetooth functionality of the Realtek
>>>>> RTL8723BS and RTL8723DS.
>>>>> Both are SDIO wifi chips with an additional Bluetooth module which is
>>>>> connected via UART to the host.
>>>>>
>>>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>>>> Signed-off-by: Jeremy Cline <jeremy@jcline.org>
>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>> ---
>>>>> .../bindings/net/realtek-bluetooth.txt | 41 +++++++++++++++++++
>>>>> 1 file changed, 41 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/net/realtek-bluetooth.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.txt b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
>>>>> new file mode 100644
>>>>> index 000000000000..1491329c4cd1
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
>>>>> @@ -0,0 +1,41 @@
>>>>> +Realtek Bluetooth Chips
>>>>> +-----------------------
>>>>> +
>>>>> +This documents the binding structure and common properties for serial
>>>>> +attached Realtek devices.
>>>>> +
>>>>> +Serial attached Realtek devices shall be a child node of the host UART
>>>>> +device the slave device is attached to. See ../serial/slave-device.txt
>>>>> +for more information
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: should contain one of the following:
>>>>> + * "realtek,rtl8723bs-bluetooth"
>>>>> + * "realtek,rtl8723ds-bluetooth"
>>>>> +
>>>>> +Optional properties:
>>>>> +- realtek,config-data: Bluetooth chipset configuration data which is
>>>>> + needed for communication (it typically contains
>>>>> + board specific settings like the baudrate and
>>>>> + whether flow-control is used).
>>>>> + This is an array of u8 values.
>>>>> +- enable-gpios: GPIO specifier, used to enable/disable the BT module
>>>>> +- reset-gpios: GPIO specifier, used to reset the BT module
>>>>> +
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +&uart {
>>>>> + ...
>>>>> +
>>>>> + bluetooth {
>>>>> + compatible = "realtek,rtl8723bs-bluetooth";
>>>>> + enable-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
>>>>> + reset-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
>>>>> + realtek,config-data = /bits/ 8 <
>>>>> + 0x55 0xab 0x23 0x87 0x29 0x00 0xf4 0x00 0x01 0x01 0xf6 0x00
>>>>> + 0x02 0x81 0x00 0xfa 0x00 0x02 0x12 0x80 0x0c 0x00 0x10 0x02
>>>>> + 0x80 0x92 0x04 0x50 0xc5 0xea 0x19 0xe1 0x1b 0xfd 0xaf 0x5f
>>>>> + 0x01 0xa4 0x0b 0xd9 0x00 0x01 0x0f 0xe4 0x00 0x01 0x08>;
>>>>> + };
>>>>> +};
>>>>
>>>> we actually need to agree on this config-data. As I wrote in an earlier email some time ago, the actual config-data files are just memory portions that will overload the default config area. I wrote tools/rtlfw.c to parse these.
>>>>
>>>> So now I wonder if we can just read the current configuration and run with that when no extra blob is provided. That way it would always work and we might just give the config-data filename here. Mostly this is the for PCM and UART settings anyway.
>>>
>>> I've been thinking about this too and 2 different solutions come to mind.
>>>
>>> Note this is all x86 specific, I think it best to solve this for x86 first
>>> and then we can apply the lessons learned there to ARM/devicetree when
>>> someone comes along who wants to hook-up things on ARM.
>>>
>>> My first idea was to stick with a config blob using the firmware_load
>>> mechanism, but to add a postfix to the filename based on the ACPI
>>> HID (hardware-id) of the serdev device, so in practice this means
>>> we would try to load:
>>>
>>> /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
>>>
>>> On most x86 devices, so far all my testing on a bunch of different
>>> devices has shown that the same config works for all x86 devices
>>> (I took the config from a Chuwi Vi8 tablet which uses 3000000bps
>>> + hardware flowcontrol).
>>>
>>> This way we can put the config in linux-firmware, without it
>>> getting loaded on ARM boards where it might very well be wrong.
>>>
>>>
>>> My second idea is to include a default config inside the driver,
>>> which can be optionally overridden by a file in
>>> /lib/firmware/rtl_bt and/or dt. Combined with module-options to
>>> override the baudrate and flowcontrol setting (and patch the
>>> builtin config accordingly).
>>>
>>>
>>> Your idea to read back the config from the device is also
>>> interesting, but I don't think that will gain us anything because
>>> AFAIK the whole purpose of the board specific config file
>>> bits is that the chip lack eeprom space to store this info,
>>> so we will just always get some generic defaults.
>>>
>>>
>>> I've run your rtlfw tool on a bunch of different config files and
>>> there are a lot of unknown fields, and even of the known fields
>>> I don't think we understand all the bits. So all in all the
>>> config file is a bit of a black box and as such I believe it
>>> would be best to just treat it as such and I personally
>>> prefer my first idea, which is to add a postfix to the
>>> firmware filename request, so on x86 load:
>>>
>>> /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
>>>
>>> And on devicetree we could postfix things with the machine
>>> model string (as returned by of_flat_dt_get_machine_name())
>> If the firmware file is going to depend on the DT, then you might as
>> well just put the data into the DT.
>
> Ok, note we don't need the entire firmware in DT, just a (binary
> format) config file for the firmware. The question is if we are
> going to try and break up the info from the config-file and then
> regenerate it inside the kernel driver. Or if we are just going
> to put the say 60 bytes in DT as an u8 array as the original
> binding proposed by Martin Blumenstingl suggests.
>
> Since we only know the meaning for a couple of the bytes in
> the file, which is typically 40 - 60 bytes big, I think it
> is probably best to just treat it as a blob.
wouldn’t it be still better to then just reference the firmware file or an identifier to build it? Putting the pure binary blob into the DT seems kinda counterproductive and hardware to update. After all it most likely depends on the firmware loaded since it is the config ram space that this changes.
As a note, there are some hints that the config file is required for some firmware since it changes some memory around to make it successful boot.
>> There's a similar issue on QCom Dragonboards. The WiFi (and BT?)
>> firmware files are supposedly board specific, so folks don't want to put
>> them into linux-firmware. But it also seems to be unknown as to which
>> parts are board specific are not.
>
> In my experience with broadcom and now the rtl8723bs the
> actual firmware and the needed config data are separate.
>
> Hmm that is actually no entirely true, for broadcom the
> bluetooth patchram file depends on the clockcrystal freq
> used on the board, so there are 2 versions of it for a
> single chip, 1 for each of the 2 different freqs used.
are you using .hex or .hcd files for Broadcom? The .hex files are pure patchram, while the .hcd can actually contain extra HCI commands. I remember that some .hcd files contain also HCI commands to do extra settings. Maybe we need a tool that shows the details of these files. We have this for nokfw and rtlfw now.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stuebner @ 2018-06-04 10:18 UTC (permalink / raw)
To: Doug Anderson
Cc: Klaus Goger, open list:ARM/Rockchip SoC..., Mark Rutland,
Huibin Hong, Catalin Marinas, Linus Walleij, Will Deacon,
Kever Yang, LKML, Joseph Chen, Romain Perier, Matthias Kaehlcke,
Emil Renner Berthing, Sugar Zhang, Simon Xue, Heinrich Schuchardt,
Brian Norris, Russell King, Ja
In-Reply-To: <CAD=FV=WA44n8MYtGZTQN3r0F86E=xDcdWhQDLDOkyqS=aaCXfQ@mail.gmail.com>
Am Freitag, 15. Dezember 2017, 18:29:02 CEST schrieb Doug Anderson:
> Hi,
>
> On Fri, Dec 15, 2017 at 3:44 AM, Klaus Goger
> <klaus.goger@theobroma-systems.com> wrote:
> > This patch series replaces all the license text in rockchip devicetree
> > files text with a proper SPDX-License-Identifier.
> > It follows the guidelines submitted[1] by Thomas Gleixner that are not
> > yet merged.
> >
> > These series also fixes the issue with contradicting statements in most
> > licenses. The introduction text claims to be GPL or X11[2] but the
> > following verbatim copy of the license is actually a MIT[3] license.
> > The X11 license includes a advertise clause and trademark information
> > related to the X Consortium. As these X Consortium specfic points are
> > irrelevant for us we stick with the actuall license text.
> >
> > [1] https://patchwork.kernel.org/patch/10091607/
> > [2] https://spdx.org/licenses/X11.html
> > [3] https://spdx.org/licenses/MIT.html
> >
> >
> > Klaus Goger (2):
> > arm64: dts: rockchip: use SPDX-License-Identifier
> > ARM: dts: rockchip: use SPDX-License-Identifier
> >
> > arch/arm/boot/dts/rk3036-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3036-kylin.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3036.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3066a-bqcurie2.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-marsboard.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-mk808.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a-rayeager.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3066a.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3188-px3-evb.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3188-radxarock.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3188.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3228-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3229-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3229.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk322x.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb-act8846.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb-rk808.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-evb.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-fennec.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-firefly-beta.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly-reload.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-firefly.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-miqi.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-phycore-rdk.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-phycore-som.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-popmetal.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-r89.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-rock2-som.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3288-rock2-square.dts | 40 +---------------------
> > arch/arm/boot/dts/rk3288-tinker.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-analog-audio.dtsi | 5 +--
> > arch/arm/boot/dts/rk3288-veyron-brain.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-mickey.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-minnie.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-sdmmc.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288-veyron.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rk3288-vyasa.dts | 39 +--------------------
> > arch/arm/boot/dts/rk3288.dtsi | 40 +---------------------
> > arch/arm/boot/dts/rk3xxx.dtsi | 39 +--------------------
> > arch/arm/boot/dts/rv1108-evb.dts | 40 +---------------------
> > arch/arm/boot/dts/rv1108.dtsi | 40 +---------------------
> > arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 39 +--------------------
> > .../arm64/boot/dts/rockchip/rk3368-evb-act8846.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 39 +--------------------
> > .../boot/dts/rockchip/rk3368-orion-r68-meta.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3368.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 39 +--------------------
> > .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 39 +--------------------
> > .../dts/rockchip/rk3399-sapphire-excavator.dts | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi | 39 +--------------------
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 39 +--------------------
> > 69 files changed, 69 insertions(+), 2603 deletions(-)
>
> This is just removing the verbatim license text and adding a link to
> another file with the text? ...and correcting the name of the
> alternate license to be the MIT license... I'm no lawyer, but if
> that's what everyone in the kernel agrees is the way they want it
> going forward then I have no objections to anything I was involved in.
correct.
Documentation/process/license-rules.rst Describes the process of
handling these license identifiers.
There was one criticism in the beginning, that an arbitary third-party
site would hold the binding license texts, but that got resolved by
including LICENSES/preferred/$identifier into the kernel sources itself.
Heiko
^ permalink raw reply
* Re: [PATCH 0/2] Use SPDX-License-Identifier for rockchip devicetree files
From: Heiko Stuebner @ 2018-06-04 10:19 UTC (permalink / raw)
To: Klaus Goger
Cc: linux-rockchip, Romain Perier, Arnd Bergmann, Andre Przywara,
Simon Xue, Liang Chen, Linus Walleij, Rob Herring, Icenowy Zheng,
Shawn Lin, Catalin Marinas, Huibin Hong, David Wu, Finley Xiao,
Jacob Chen, William Wu, Brian Norris, Jaehoon Chung,
Maxime Ripard
In-Reply-To: <20171215114427.32059-1-klaus.goger@theobroma-systems.com>
Am Freitag, 15. Dezember 2017, 12:44:25 CEST schrieb Klaus Goger:
> This patch series replaces all the license text in rockchip devicetree
> files text with a proper SPDX-License-Identifier.
> It follows the guidelines submitted[1] by Thomas Gleixner that are not
> yet merged.
>
> These series also fixes the issue with contradicting statements in most
> licenses. The introduction text claims to be GPL or X11[2] but the
> following verbatim copy of the license is actually a MIT[3] license.
> The X11 license includes a advertise clause and trademark information
> related to the X Consortium. As these X Consortium specfic points are
> irrelevant for us we stick with the actuall license text.
>
> [1] https://patchwork.kernel.org/patch/10091607/
> [2] https://spdx.org/licenses/X11.html
> [3] https://spdx.org/licenses/MIT.html
>
>
> Klaus Goger (2):
> arm64: dts: rockchip: use SPDX-License-Identifier
> ARM: dts: rockchip: use SPDX-License-Identifier
This had now 6 months for anybody concerned about this change to speak
up - with no NACKs received, so I've applied both patches for 4.19
Heiko
^ permalink raw reply
* Re: [PATCH v3 0/8] gnss: add new GNSS subsystem
From: Johan Hovold @ 2018-06-04 10:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Johan Hovold, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Andreas Kemnade, Arnd Bergmann, H . Nikolaus Schaller,
Marcel Holtmann, Sebastian Reichel, Tony Lindgren, linux-kernel,
devicetree
In-Reply-To: <20180601162645.GA30792@amd>
On Fri, Jun 01, 2018 at 06:26:46PM +0200, Pavel Machek wrote:
> Hi!
>
> > > So you have serial line + pm + protocol type. Nothing GNSS specific
> > > really, it would be useful to (for example) say this is modem with AT
> > > commands. Or this is QMI modem.
> >
> > It's a matter of finding the right abstraction level. A user space
> > location service will now have easy access to the class of devices it
> > cares about, without having to go through a list of other random devices
> > which happen to use a similar underlying interface (e.g. a modem or
> > whatever).
>
> udev solves device discovery pretty well; I don't think that's good
> thing to optimize for.
It's about grouping related devices together, devices which share some
common functionality. In this case, providing location data from some
satellite system. I really don't understand how you can find having a
class type named "gnss" for this to be controversial in any way.
> (And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation;
> and yes that makes it _even easier_ for location service to find right
> devices).
As I've already explained, you may not know which protocol is currently
active when the device start and you typically switch from NMEA to a
vendor protocol during runtime (e.g. for configuration or to access raw
GNSS data).
Trying to encode the GNSS protocol in the character-device node name is
just a bad idea.
> > Point is, you can't write a subsystem for everything. If it later turns
> > out some part of the code can be shared internally, fine.
>
> True. But you can pick reasonable name for the subsystem :-).
I find naming a subsystem for GNSS receivers "gnss" to be very
reasonable. ;)
> > > > Finally, the GNSS subsystem is clearly not serial (as in UART) specific
> > > > and works just as fine with I2C, SPI, USB, iomem, rproc or whatever
> > > > interface the GNSS uses.
> > >
> > > Ok, true. It is "we pass tty-like data across". Again, it would be
> > > useful for AT commands, too, and yes, they go over serials and usbs
> > > and more, too.
> >
> > Modems and GNSS devices would have different characteristics for buffers
> > and throughput for starters.
> >
> > The GNSS interface uses a synchronous writes for commands to the
> > receiver, something which may not be appropriate for an outgoing data
> > channel, for example.
>
> Well, these days AT modems really have separate channels for commands
> and data.
>
> > As mentioned in the cover letter, we may eventually want to add support
> > for some kinds of configuration from within the kernel (e.g. protocol
> > and line speed changes).
>
> I believe we'll eventually want "real" GPS drivers, with common
> interface. input was in this situation before...
As we also already discussed, there's nothing preventing you from trying
to move gpsd into the kernel later. I doubt this is something we want,
and it may turn out not to be feasible for other reasons.
And as you already acknowledged, this series does solve a problem we
have today.
> > > > > This will never handle devices like Nokia N900, where GPS is connected
> > > > > over netlink.
> > > >
> > > > Marcel already suggested adding a ugnss interface, which would allow
> > > > feeding GNSS data through the generic GNSS interface from user space for
> > > > use cases where it's not (yet) feasible to implement a kernel
> > > > driver.
> > >
> > > Yes, and ugnss would be at wrong layer for N900. First, lets take a
> > > look at N900 gps driver:
> > > https://github.com/postmarketOS/gps-nokia-n900
> > >
> > > Got it? I'll eventually like to see it in the kernel, but your "GNSS"
> > > subsystem is unsuitable for it, as it does not talk well-known
> > > protocol.
> >
> > Seriously? If you can't be arsed to summarise your use case, why would I
> > bother reading your random user space code?
>
> You are trying to push subsystem to kernel. I believe asking you to do
> little research is not unexpected.
Waving your hands, saying this will never work, and pointing to some 600
lines of user-space code for an old phone isn't an argument. That is, at
best, just you being lazy.
> Anyway, it is trivial binary protocol over packets that are used for
> modem communication. Handling it is like 40? lines of code.
Ok, so I did read the damn thing along with the overview of the N900 GPS
hardware and reverse-engineered protocol (why didn't you point me to
those instead?) and I'm still not sure what the point you're trying to
make is.
The n900 service you link to above, parses phonet data, does some
*floating point* calculations and generates NMEA sentences which it
feeds to a pseudo terminal whose slave side is opened by gpsd.
That NMEA data could just as easily be fed through a different kernel
subsystem, namely gnss instead of tty, where it could be accessed
through a common interface (for now, a raw gnss interface, with some
associated meta data). [ And from what I can tell, ugnss would also
allow you to get rid of some hacks related to finding out when the GNSS
is opened and needs to be powered on. ]
So the ugnss interface looks like it will work for N900 just as it will
for other phones.
> > > I'd like to see "datapipe" devices (what you currently call GNSS) and
> > > "gps" devices, which would have common interface to the userland.
> >
> > You keep talking about this "gps" interface, which based on your
> > earlier comments I assume you mean a NMEA 0183 interface? Again,
> > converting a vendor-specific binary protocol may not be feasible. Please
> > try to be more be specific.
>
> I'm pretty sure we should have one protocol for communicating position
> data to userland. I don't want to go into details at the moment, as
> they are not important at the moment (and we could spend lot of time
> discussing details).
>
> NMEA would not be my first choice, really. I'd propose something very
> similar to existing /dev/input/eventX, but with wider data types.
Fine, you pursue that idea if you want then. I can see many problems
with trying to so, but the point is, this series doesn't prevent you
from doing so.
If you think you'll one day be able to parse and repackage the various
vendor protocols within the kernel, you can consider the raw gnss
interface as an intermediate step (which may continue to exist in
parallel just as say hidraw).
As I've already mentioned, I considered naming the device nodes
/dev/gnssraw0 partly because it would leave /dev/gnss namespace free for
any such future development. I ultimately found that idea to be too
implausible for it to be worth the potential confusion arising from the
fact that "raw" GNSS data is already has an established meaning.
But in the end, this is just name bike shedding.
> > > N900 would not have any datapipe devices, but would have /dev/gps0
> > > exposing common GPS interface.
> > >
> > > Droid4 would have /dev/datapipe0 (usb, AT protocol), /dev/datapipe1
> > > (usb, QMI protocol), /dev/datapipe2 (gsmtty over serial, custom AT
> > > protocol), /dev/datapipe3 (gsmtty over serial, NMEA wrapped in AT
> > > protocol) (and more, it is complex hardware). And if we really wanted,
> > > we'd have /dev/gps0, too, exposing common GPS interface.
> > >
> > > Your devices would have /dev/datapipe0 with sirf or ublox or nmea
> > > protocol. In we really wanted, we'd have /dev/gps0, too, again,
> > > exposing common GPS interface.
> >
> > This does not seem like the right abstraction level and doesn't appear
> > to provide much more than what we currently have with ttys.
>
> I don't see what you are saying here. I've described your proposal but
> replaced /dev/gnss0 with /dev/datapipe0.
You're grouping unrelated devices into a new class with the descriptive
name "datapipe" (sarcasm).
Maybe one day we'll have a QMI subsystem, for example, but until someone
determines what that may end up looking like, I think we should stick
with the character device and tty abstractions we already have.
> > > I believe we really want to use your code for AT commands, too. And we
> > > really should keep GNSS/GPS names for future layer that actually
> > > provides single interface for userland.
> >
> > Specifics, please. What would such an interface look like? I'm pretty
> > sure, we do not want to move every GNSS middleware protocol handler into
> > the kernel.
>
> Maybe we don't want to move _every_ GNSS protocol handler into kernel,
> but I'm pretty sure we need to move _some_ of them there. It is
> certainly best place for Nokia N900's protocol.
>
> And I'm trying to make sure we have suitable names available when that
> happens.
If that's the concern, we could reconsider naming the raw protocol
interface /dev/gnnsraw0 as mentioned above.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: renesas: condor: specify EtherAVB PHY IRQ
From: Simon Horman @ 2018-06-04 10:33 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Magnus Damm, Catalin Marinas,
Will Deacon, linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <21578b79-7ba0-b3a6-ae45-7e9ffbb7c8db@cogentembedded.com>
On Fri, Jun 01, 2018 at 11:45:55PM +0300, Sergei Shtylyov wrote:
> Specify EtherAVB PHY IRQ in the Condor board's device tree, now that
> we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> ===================================================================
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -59,6 +59,8 @@
> phy0: ethernet-phy@0 {
> rxc-skew-ps = <1500>;
> reg = <0>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
I don't see this documented. Perhaps I'm missing something obvious.
Or you have some extra information or newer documentation?
Also, given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
and the following one.
> };
> };
>
>
^ 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