* [RFC PATCH 2/3] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-11-25 16:03 UTC (permalink / raw)
To: airlied, khilman, carlo
Cc: Neil Armstrong, dri-devel, linux-amlogic, linux-arm-kernel,
linux-kernel, victor.wan, jerry.cao, Xing.Xu, devicetree
In-Reply-To: <1480089791-12517-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 46 ++++++++++++++++++++++
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 4 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 ++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 12 ++++++
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 4 ++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 8 ++++
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 4 ++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++
8 files changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..bcc1d1f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -153,6 +153,27 @@
};
};
+ venc_cvbs: venc-cvbs {
+ compatible = "amlogic,meson-gx-venc-cvbs";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ enc_cvbs_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ venc_cvbs_in_vpu: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vpu_out_venc_cvbs>;
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -356,5 +377,30 @@
status = "disabled";
};
};
+
+ vpu: vpu@d0100000 {
+ compatible = "amlogic,meson-gx-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "base", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vpu_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vpu_out_venc_cvbs: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&venc_cvbs_in_vpu>;
+ };
+ };
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..a55d1cf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -229,3 +229,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&venc_cvbs {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 5e5e2de..3c09bd1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -266,3 +266,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&venc_cvbs {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..99ff37c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -506,3 +506,15 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&venc_cvbs {
+ status = "okay";
+};
+
+&venc_cvbs {
+ compatible = "amlogic,meson-gxbb-venc-cvbs", "amlogic,meson-gx-venc-cvbs";
+};
+
+&vpu {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..2a9b46f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -203,3 +203,7 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&venc_cvbs {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 3af54dc..98b8118 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -299,3 +299,11 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&venc_cvbs {
+ compatible = "amlogic,meson-gxl-venc-cvbs", "amlogic,meson-gx-venc-cvbs";
+};
+
+&vpu {
+ compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..1ae2451 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -167,3 +167,7 @@
max-speed = <1000>;
};
};
+
+&venc_cvbs {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..7bf2d6e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -112,3 +112,12 @@
};
};
};
+
+
+&venc_cvbs {
+ compatible = "amlogic,meson-gxm-venc-cvbs", "amlogic,meson-gx-venc-cvbs";
+};
+
+&vpu {
+ compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
+};
--
1.9.1
^ permalink raw reply related
* Re: Question regarding clocks in the DW-HDMI DT bindings
From: Laurent Pinchart @ 2016-11-25 15:56 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree@vger.kernel.org, Mike Turquette, Stephen Boyd,
DRI mailing list, nickey.yang, Andy Yan, Vladimir Zapolskiy
In-Reply-To: <CAOMZO5CJTu7jzCb-iVLe2wt8VjyzWq-oYaC2Jw34V8SgaqrGkw@mail.gmail.com>
Hi Fabio,
On Friday 25 Nov 2016 13:29:37 Fabio Estevam wrote:
> On Fri, Nov 25, 2016 at 1:22 PM, Laurent Pinchart wrote:
> >> I got the clock name from I.MX6Q TRM, I also checked the name again
> >> with Rockchip IC design team now, hope to get some new information soon.
> >
> > Thank you. While at it, could you ask them which version of the DW HDMI IP
> > used in the SoC ?
>
> DW HDMI IP used in Rockchip is:
> dwhdmi-rockchip ff980000.hdmi: Detected HDMI controller 0x20:0xa:0xa0:0xc1
>
> as shown at
> https://storage.kernelci.org/mainline/v4.9-rc6-157-g16ae16c6e561/arm-multi_
> v7_defconfig/lab-collabora/boot-rk3288-rock2-square_rootfs:nfs.html
>
> DW HDMI IP used on mx6q is:
> dwhdmi-imx 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
Thank you for the information. This is what I get on the Renesas R-Car H3.
rcar-dw-hdmi fead0000.hdmi0: Detected HDMI controller 0x20:0x1a:0xa0:0xc1
rcar-dw-hdmi feae0000.hdmi1: Detected HDMI controller 0x20:0x1a:0xa0:0xc1
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v4 6/6] clk: qcom: ipq4019: Add the cpu clock frequency change notifier
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross, david.brown, mturquette, sboyd
Cc: robh+dt, mark.rutland, varada, pradeepb, snlakshm, linux-arm-msm,
linux-soc, linux-clk, linux-kernel, devicetree, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu@codeaurora.org>
The current driver code gives the crash or gets hang while switching
the CPU frequency some time. The APSS CPU Clock divider is not glitch
free so it the APPS clock need to be switched for stable clock during
the change.
This patch adds the frequency change notifier for APSS CPU clock. It
changes the parent of this clock to stable PLL FEPLL500 when it gets
for PRE_RATE_CHANGE event. This event will be generated before actual
clock set operations. The clock set operation will again change its
corresponding parent by getting the same from frequency table.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 45 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index eeafca2..94df10d 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -22,6 +22,7 @@
#include <linux/reset-controller.h>
#include <linux/math64.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <dt-bindings/clock/qcom,gcc-ipq4019.h>
@@ -1736,13 +1737,55 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
};
MODULE_DEVICE_TABLE(of, gcc_ipq4019_match_table);
+/* Contains index for safe clock during APSS freq change */
+static int gcc_ipq4019_cpu_safe_parent;
+static int
+gcc_ipq4019_cpu_clk_notifier_fn(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ int err = 0;
+
+ if (action == PRE_RATE_CHANGE)
+ err = clk_rcg2_ops.set_parent(&apps_clk_src.clkr.hw,
+ gcc_ipq4019_cpu_safe_parent);
+
+ return notifier_from_errno(err);
+}
+
+static struct notifier_block gcc_ipq4019_cpu_clk_notifier = {
+ .notifier_call = gcc_ipq4019_cpu_clk_notifier_fn,
+};
+
static int gcc_ipq4019_probe(struct platform_device *pdev)
{
- return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
+ int err;
+
+ err = qcom_cc_probe(pdev, &gcc_ipq4019_desc);
+ if (err)
+ return err;
+
+ gcc_ipq4019_cpu_safe_parent = qcom_find_src_index(&apps_clk_src.clkr.hw,
+ apps_clk_src.parent_map,
+ P_FEPLL500);
+ if (gcc_ipq4019_cpu_safe_parent < 0)
+ err = gcc_ipq4019_cpu_safe_parent;
+
+ if (!err)
+ err = clk_notifier_register(apps_clk_src.clkr.hw.clk,
+ &gcc_ipq4019_cpu_clk_notifier);
+
+ return err;
+}
+
+static int gcc_ipq4019_remove(struct platform_device *pdev)
+{
+ return clk_notifier_unregister(apps_clk_src.clkr.hw.clk,
+ &gcc_ipq4019_cpu_clk_notifier);
}
static struct platform_driver gcc_ipq4019_driver = {
.probe = gcc_ipq4019_probe,
+ .remove = gcc_ipq4019_remove,
.driver = {
.name = "qcom,gcc-ipq4019",
.of_match_table = gcc_ipq4019_match_table,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v4 5/6] clk: qcom: ipq4019: Add all the frequencies for apss cpu
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
varada-sgV2jX0FEOL9JmXXK+q4OQ, pradeepb-sgV2jX0FEOL9JmXXK+q4OQ,
snlakshm-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
The APSS CPU clock does not contain all the frequencies in its
frequency table so this patch adds the same.
Signed-off-by: Abhishek Sahu <absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 320750c..eeafca2 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -569,10 +569,20 @@ struct clk_fepll {
};
static const struct freq_tbl ftbl_gcc_apps_clk[] = {
- F(48000000, P_XO, 1, 0, 0),
+ F(48000000, P_XO, 1, 0, 0),
F(200000000, P_FEPLL200, 1, 0, 0),
+ F(384000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(413000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(448000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(488000000, P_DDRPLLAPSS, 1, 0, 0),
F(500000000, P_FEPLL500, 1, 0, 0),
- F(626000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(512000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(537000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(565000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(597000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(632000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(672000000, P_DDRPLLAPSS, 1, 0, 0),
+ F(716000000, P_DDRPLLAPSS, 1, 0, 0),
{ }
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 4/6] clk: qcom: ipq4019: correct sdcc frequency and parent name
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross, david.brown, mturquette, sboyd
Cc: robh+dt, mark.rutland, varada, pradeepb, snlakshm, linux-arm-msm,
linux-soc, linux-clk, linux-kernel, devicetree, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu@codeaurora.org>
1. The parent for sdcc clock is sdccpll.
2. The frequency value was wrong so modified the same.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 40187ae..320750c 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -124,7 +124,7 @@ struct clk_fepll {
static const char * const gcc_xo_sdcc1_500[] = {
"xo",
- "ddrpll",
+ "ddrpllsdcc",
"fepll500",
};
@@ -550,7 +550,7 @@ struct clk_fepll {
F(25000000, P_FEPLL500, 1, 1, 20),
F(50000000, P_FEPLL500, 1, 1, 10),
F(100000000, P_FEPLL500, 1, 1, 5),
- F(193000000, P_DDRPLL, 1, 0, 0),
+ F(192000000, P_DDRPLL, 1, 0, 0),
{ }
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v4 3/6] clk: qcom: ipq4019: Add the nodes for pcnoc
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross, david.brown, mturquette, sboyd
Cc: robh+dt, mark.rutland, varada, pradeepb, snlakshm, linux-arm-msm,
linux-soc, linux-clk, linux-kernel, devicetree, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu@codeaurora.org>
The current ipq4019 clock driver does not have the node for
PCNOC so this patch adds and registers the PCNOC clock nodes.
This PCNOC clock is critical and should not be turned off so
setting CRITICAL flag also.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 39 ++++++++++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-ipq4019.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index 000c224..40187ae 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -1521,6 +1521,43 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
.pll_vco = &gcc_fepll_vco,
};
+static const struct freq_tbl ftbl_gcc_pcnoc_ahb_clk[] = {
+ F(48000000, P_XO, 1, 0, 0),
+ F(100000000, P_FEPLL200, 2, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 gcc_pcnoc_ahb_clk_src = {
+ .cmd_rcgr = 0x21024,
+ .hid_width = 5,
+ .parent_map = gcc_xo_200_500_map,
+ .freq_tbl = ftbl_gcc_pcnoc_ahb_clk,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gcc_pcnoc_ahb_clk_src",
+ .parent_names = gcc_xo_200_500,
+ .num_parents = 3,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_branch pcnoc_clk_src = {
+ .halt_reg = 0x21030,
+ .clkr = {
+ .enable_reg = 0x21030,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "pcnoc_clk_src",
+ .parent_names = (const char *[]){
+ "gcc_pcnoc_ahb_clk_src",
+ },
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ .flags = CLK_SET_RATE_PARENT |
+ CLK_IS_CRITICAL,
+ },
+ },
+};
+
static struct clk_regmap *gcc_ipq4019_clocks[] = {
[AUDIO_CLK_SRC] = &audio_clk_src.clkr,
[BLSP1_QUP1_I2C_APPS_CLK_SRC] = &blsp1_qup1_i2c_apps_clk_src.clkr,
@@ -1589,6 +1626,8 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
[GCC_FEPLL_WCSS2G_CLK] = &gcc_fepllwcss2g_clk.cdiv.clkr,
[GCC_FEPLL_WCSS5G_CLK] = &gcc_fepllwcss5g_clk.cdiv.clkr,
[GCC_APSS_CPU_PLLDIV_CLK] = &gcc_apss_cpu_plldiv_clk.cdiv.clkr,
+ [GCC_PCNOC_AHB_CLK_SRC] = &gcc_pcnoc_ahb_clk_src.clkr,
+ [GCC_PCNOC_AHB_CLK] = &pcnoc_clk_src.clkr,
};
static const struct qcom_reset_map gcc_ipq4019_resets[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
index c629b2b..7e8a7be 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
@@ -91,6 +91,7 @@
#define GCC_FEPLL_WCSS2G_CLK 72
#define GCC_FEPLL_WCSS5G_CLK 73
#define GCC_APSS_CPU_PLLDIV_CLK 74
+#define GCC_PCNOC_AHB_CLK_SRC 75
#define WIFI0_CPU_INIT_RESET 0
#define WIFI0_RADIO_SRIF_RESET 1
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v4 2/6] clk: qcom: ipq4019: Add the apss cpu pll divider clock node
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
varada-sgV2jX0FEOL9JmXXK+q4OQ, pradeepb-sgV2jX0FEOL9JmXXK+q4OQ,
snlakshm-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
The current ipq4019 clock driver does not have support for all
the frequency supported by APSS CPU. APSS CPU frequency is
provided with APSS CPU PLL divider which divides down the VCO
frequency. This divider is nonlinear and specific to IPQ4019
so the standard divider code cannot be used for this.
Signed-off-by: Abhishek Sahu <absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 132 +++++++++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-ipq4019.h | 1 +
2 files changed, 133 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index fa922fd..000c224 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -21,6 +21,7 @@
#include <linux/regmap.h>
#include <linux/reset-controller.h>
#include <linux/math64.h>
+#include <linux/delay.h>
#include <dt-bindings/clock/qcom,gcc-ipq4019.h>
@@ -585,6 +586,7 @@ struct clk_fepll {
.parent_names = gcc_xo_ddr_500_200,
.num_parents = 4,
.ops = &clk_rcg2_ops,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -1235,6 +1237,135 @@ static u64 clk_fepll_vco_calc_rate(struct clk_fepll *pll_div,
.reg = 0x2f020,
};
+/*
+ * Round rate function for APSS CPU PLL Clock divider.
+ * It looks up the frequency table and returns the next higher frequency
+ * supported in hardware.
+ */
+static long clk_cpu_div_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *p_rate)
+{
+ struct clk_fepll *pll = to_clk_fepll(hw);
+ struct clk_hw *p_hw;
+ const struct freq_tbl *f;
+
+ f = qcom_find_freq(pll->freq_tbl, rate);
+ if (!f)
+ return -EINVAL;
+
+ p_hw = clk_hw_get_parent_by_index(hw, f->src);
+ *p_rate = clk_hw_get_rate(p_hw);
+
+ return f->freq;
+};
+
+/*
+ * Clock set rate function for APSS CPU PLL Clock divider.
+ * It looks up the frequency table and updates the PLL divider to corresponding
+ * divider value.
+ */
+static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_fepll *pll = to_clk_fepll(hw);
+ const struct freq_tbl *f;
+ u32 mask;
+ int ret;
+
+ f = qcom_find_freq(pll->freq_tbl, rate);
+ if (!f)
+ return -EINVAL;
+
+ mask = (BIT(pll->cdiv.width) - 1) << pll->cdiv.shift;
+ ret = regmap_update_bits(pll->cdiv.clkr.regmap,
+ pll->cdiv.reg, mask,
+ f->pre_div << pll->cdiv.shift);
+ /*
+ * There is no status bit which can be checked for successful CPU
+ * divider update operation so using delay for the same.
+ */
+ udelay(1);
+
+ return 0;
+};
+
+/*
+ * Clock frequency calculation function for APSS CPU PLL Clock divider.
+ * This clock divider is nonlinear so this function calculates the actual
+ * divider and returns the output frequency by dividing VCO Frequency
+ * with this actual divider value.
+ */
+static unsigned long
+clk_cpu_div_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_fepll *pll = to_clk_fepll(hw);
+ u32 cdiv, pre_div;
+ u64 rate;
+
+ regmap_read(pll->cdiv.clkr.regmap, pll->cdiv.reg, &cdiv);
+ cdiv = (cdiv >> pll->cdiv.shift) & (BIT(pll->cdiv.width) - 1);
+
+ /*
+ * Some dividers have value in 0.5 fraction so multiply both VCO
+ * frequency(parent_rate) and pre_div with 2 to make integer
+ * calculation.
+ */
+ if (cdiv > 10)
+ pre_div = (cdiv + 1) * 2;
+ else
+ pre_div = cdiv + 12;
+
+ rate = clk_fepll_vco_calc_rate(pll, parent_rate) * 2;
+ do_div(rate, pre_div);
+
+ return rate;
+};
+
+static const struct clk_ops clk_regmap_cpu_div_ops = {
+ .round_rate = clk_cpu_div_round_rate,
+ .set_rate = clk_cpu_div_set_rate,
+ .recalc_rate = clk_cpu_div_recalc_rate,
+};
+
+static const struct freq_tbl ftbl_apss_ddr_pll[] = {
+ { 384000000, P_XO, 0xd, 0, 0 },
+ { 413000000, P_XO, 0xc, 0, 0 },
+ { 448000000, P_XO, 0xb, 0, 0 },
+ { 488000000, P_XO, 0xa, 0, 0 },
+ { 512000000, P_XO, 0x9, 0, 0 },
+ { 537000000, P_XO, 0x8, 0, 0 },
+ { 565000000, P_XO, 0x7, 0, 0 },
+ { 597000000, P_XO, 0x6, 0, 0 },
+ { 632000000, P_XO, 0x5, 0, 0 },
+ { 672000000, P_XO, 0x4, 0, 0 },
+ { 716000000, P_XO, 0x3, 0, 0 },
+ { 768000000, P_XO, 0x2, 0, 0 },
+ { 823000000, P_XO, 0x1, 0, 0 },
+ { 896000000, P_XO, 0x0, 0, 0 },
+ { }
+};
+
+static struct clk_fepll gcc_apss_cpu_plldiv_clk = {
+ .cdiv.reg = 0x2e020,
+ .cdiv.shift = 4,
+ .cdiv.width = 4,
+ .cdiv.clkr = {
+ .enable_reg = 0x2e000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ddrpllapss",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_regmap_cpu_div_ops,
+ },
+ },
+ .freq_tbl = ftbl_apss_ddr_pll,
+ .pll_vco = &gcc_apss_ddrpll_vco,
+};
+
/* Calculates the rate for PLL divider.
* If the divider value is not fixed then it gets the actual divider value
* from divider table. Then, it calculate the clock rate by dividing the
@@ -1457,6 +1588,7 @@ static u64 clk_fepll_vco_calc_rate(struct clk_fepll *pll_div,
[GCC_FEPLL500_CLK] = &gcc_fepll500_clk.cdiv.clkr,
[GCC_FEPLL_WCSS2G_CLK] = &gcc_fepllwcss2g_clk.cdiv.clkr,
[GCC_FEPLL_WCSS5G_CLK] = &gcc_fepllwcss5g_clk.cdiv.clkr,
+ [GCC_APSS_CPU_PLLDIV_CLK] = &gcc_apss_cpu_plldiv_clk.cdiv.clkr,
};
static const struct qcom_reset_map gcc_ipq4019_resets[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
index a906d46..c629b2b 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
@@ -90,6 +90,7 @@
#define GCC_FEPLL500_CLK 71
#define GCC_FEPLL_WCSS2G_CLK 72
#define GCC_FEPLL_WCSS5G_CLK 73
+#define GCC_APSS_CPU_PLLDIV_CLK 74
#define WIFI0_CPU_INIT_RESET 0
#define WIFI0_RADIO_SRIF_RESET 1
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/6] clk: qcom: ipq4019: remove fixed clocks and add pll clocks
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross, david.brown, mturquette, sboyd
Cc: robh+dt, mark.rutland, varada, pradeepb, snlakshm, linux-arm-msm,
linux-soc, linux-clk, linux-kernel, devicetree, Abhishek Sahu
In-Reply-To: <1480088493-4590-1-git-send-email-absahu@codeaurora.org>
The current ipq4019 clock driver registered the PLL clocks and
dividers as fixed clock. These fixed clock needs to be removed
from driver probe function and same need to be registered with
clock framework. These PLL clocks should be programmed only
once and the same are being programmed already by the boot
loader so the set rate operation is not required for these
clocks. Only the rate can be calculated by clock operations
in clock driver file so this patch adds the same.
The PLL takes the reference clock from XO and generates the
intermediate VCO frequency. This VCO frequency will be divided
down by different PLL internal dividers. Some of the PLL
internal dividers are fixed while other are programmable.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
drivers/clk/qcom/gcc-ipq4019.c | 254 +++++++++++++++++++++++++--
include/dt-bindings/clock/qcom,gcc-ipq4019.h | 9 +
2 files changed, 252 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
index b593065..fa922fd 100644
--- a/drivers/clk/qcom/gcc-ipq4019.c
+++ b/drivers/clk/qcom/gcc-ipq4019.c
@@ -20,6 +20,7 @@
#include <linux/clk-provider.h>
#include <linux/regmap.h>
#include <linux/reset-controller.h>
+#include <linux/math64.h>
#include <dt-bindings/clock/qcom,gcc-ipq4019.h>
@@ -28,6 +29,13 @@
#include "clk-rcg.h"
#include "clk-branch.h"
#include "reset.h"
+#include "clk-regmap-divider.h"
+
+#define to_clk_regmap_div(_hw) container_of(to_clk_regmap(_hw),\
+ struct clk_regmap_div, clkr)
+
+#define to_clk_fepll(_hw) container_of(to_clk_regmap_div(_hw),\
+ struct clk_fepll, cdiv)
enum {
P_XO,
@@ -40,6 +48,41 @@ enum {
P_DDRPLLAPSS,
};
+/*
+ * struct clk_fepll_vco - vco feedback divider corresponds for FEPLL clocks
+ * @fdbkdiv_shift: lowest bit for FDBKDIV
+ * @fdbkdiv_width: number of bits in FDBKDIV
+ * @refclkdiv_shift: lowest bit for REFCLKDIV
+ * @refclkdiv_width: number of bits in REFCLKDIV
+ * @reg: PLL_DIV register address
+ */
+struct clk_fepll_vco {
+ u32 fdbkdiv_shift;
+ u32 fdbkdiv_width;
+ u32 refclkdiv_shift;
+ u32 refclkdiv_width;
+ u32 reg;
+};
+
+/*
+ * struct clk_fepll - clk divider corresponds to FEPLL clocks
+ * @fixed_div: fixed divider value if divider is fixed
+ * @parent_map: map from software's parent index to hardware's src_sel field
+ * @cdiv: divider values for PLL_DIV
+ * @pll_vco: vco feedback divider
+ * @div_table: mapping for actual divider value to register divider value
+ * in case of non fixed divider
+ * @freq_tbl: frequency table
+ */
+struct clk_fepll {
+ u32 fixed_div;
+ const u8 *parent_map;
+ struct clk_regmap_div cdiv;
+ const struct clk_fepll_vco *pll_vco;
+ const struct clk_div_table *div_table;
+ const struct freq_tbl *freq_tbl;
+};
+
static struct parent_map gcc_xo_200_500_map[] = {
{ P_XO, 0 },
{ P_FEPLL200, 1 },
@@ -1155,6 +1198,198 @@ enum {
},
};
+/* Calculates the VCO rate for FEPLL. */
+static u64 clk_fepll_vco_calc_rate(struct clk_fepll *pll_div,
+ unsigned long parent_rate)
+{
+ const struct clk_fepll_vco *pll_vco = pll_div->pll_vco;
+ u32 fdbkdiv, refclkdiv, cdiv;
+ u64 vco;
+
+ regmap_read(pll_div->cdiv.clkr.regmap, pll_vco->reg, &cdiv);
+ refclkdiv = (cdiv >> pll_vco->refclkdiv_shift) &
+ (BIT(pll_vco->refclkdiv_width) - 1);
+ fdbkdiv = (cdiv >> pll_vco->fdbkdiv_shift) &
+ (BIT(pll_vco->fdbkdiv_width) - 1);
+
+ vco = parent_rate / refclkdiv;
+ vco *= 2;
+ vco *= fdbkdiv;
+
+ return vco;
+}
+
+static const struct clk_fepll_vco gcc_apss_ddrpll_vco = {
+ .fdbkdiv_shift = 16,
+ .fdbkdiv_width = 8,
+ .refclkdiv_shift = 24,
+ .refclkdiv_width = 5,
+ .reg = 0x2e020,
+};
+
+static const struct clk_fepll_vco gcc_fepll_vco = {
+ .fdbkdiv_shift = 16,
+ .fdbkdiv_width = 8,
+ .refclkdiv_shift = 24,
+ .refclkdiv_width = 5,
+ .reg = 0x2f020,
+};
+
+/* Calculates the rate for PLL divider.
+ * If the divider value is not fixed then it gets the actual divider value
+ * from divider table. Then, it calculate the clock rate by dividing the
+ * parent rate with actual divider value.
+ */
+static unsigned long
+clk_regmap_clk_div_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_fepll *pll = to_clk_fepll(hw);
+ u32 cdiv, pre_div = 1;
+ u64 rate;
+ const struct clk_div_table *clkt;
+
+ if (pll->fixed_div) {
+ pre_div = pll->fixed_div;
+ } else {
+ regmap_read(pll->cdiv.clkr.regmap, pll->cdiv.reg, &cdiv);
+ cdiv = (cdiv >> pll->cdiv.shift) & (BIT(pll->cdiv.width) - 1);
+
+ for (clkt = pll->div_table; clkt->div; clkt++) {
+ if (clkt->val == cdiv)
+ pre_div = clkt->div;
+ }
+ }
+
+ rate = clk_fepll_vco_calc_rate(pll, parent_rate);
+ do_div(rate, pre_div);
+
+ return rate;
+};
+
+static const struct clk_ops clk_fepll_div_ops = {
+ .recalc_rate = clk_regmap_clk_div_recalc_rate,
+};
+
+static struct clk_fepll gcc_apss_sdcc_clk = {
+ .fixed_div = 28,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "ddrpllsdcc",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .pll_vco = &gcc_apss_ddrpll_vco,
+};
+
+static struct clk_fepll gcc_fepll125_clk = {
+ .fixed_div = 32,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepll125",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .pll_vco = &gcc_fepll_vco,
+};
+
+static struct clk_fepll gcc_fepll125dly_clk = {
+ .fixed_div = 32,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepll125dly",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .pll_vco = &gcc_fepll_vco,
+};
+
+static struct clk_fepll gcc_fepll200_clk = {
+ .fixed_div = 20,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepll200",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .pll_vco = &gcc_fepll_vco,
+};
+
+static struct clk_fepll gcc_fepll500_clk = {
+ .fixed_div = 8,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepll500",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .pll_vco = &gcc_fepll_vco,
+};
+
+static const struct clk_div_table fepllwcss_clk_div_table[] = {
+ { 0, 15 },
+ { 1, 16 },
+ { 2, 18 },
+ { 3, 20 },
+ { },
+};
+
+static struct clk_fepll gcc_fepllwcss2g_clk = {
+ .cdiv.reg = 0x2f020,
+ .cdiv.shift = 8,
+ .cdiv.width = 2,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepllwcss2g",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .div_table = fepllwcss_clk_div_table,
+ .pll_vco = &gcc_fepll_vco,
+};
+
+static struct clk_fepll gcc_fepllwcss5g_clk = {
+ .cdiv.reg = 0x2f020,
+ .cdiv.shift = 12,
+ .cdiv.width = 2,
+ .cdiv.clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "fepllwcss5g",
+ .parent_names = (const char *[]){
+ "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_fepll_div_ops,
+ },
+ },
+ .div_table = fepllwcss_clk_div_table,
+ .pll_vco = &gcc_fepll_vco,
+};
+
static struct clk_regmap *gcc_ipq4019_clocks[] = {
[AUDIO_CLK_SRC] = &audio_clk_src.clkr,
[BLSP1_QUP1_I2C_APPS_CLK_SRC] = &blsp1_qup1_i2c_apps_clk_src.clkr,
@@ -1215,6 +1450,13 @@ enum {
[GCC_WCSS5G_CLK] = &gcc_wcss5g_clk.clkr,
[GCC_WCSS5G_REF_CLK] = &gcc_wcss5g_ref_clk.clkr,
[GCC_WCSS5G_RTC_CLK] = &gcc_wcss5g_rtc_clk.clkr,
+ [GCC_SDCC_PLLDIV_CLK] = &gcc_apss_sdcc_clk.cdiv.clkr,
+ [GCC_FEPLL125_CLK] = &gcc_fepll125_clk.cdiv.clkr,
+ [GCC_FEPLL125DLY_CLK] = &gcc_fepll125dly_clk.cdiv.clkr,
+ [GCC_FEPLL200_CLK] = &gcc_fepll200_clk.cdiv.clkr,
+ [GCC_FEPLL500_CLK] = &gcc_fepll500_clk.cdiv.clkr,
+ [GCC_FEPLL_WCSS2G_CLK] = &gcc_fepllwcss2g_clk.cdiv.clkr,
+ [GCC_FEPLL_WCSS5G_CLK] = &gcc_fepllwcss5g_clk.cdiv.clkr,
};
static const struct qcom_reset_map gcc_ipq4019_resets[] = {
@@ -1295,7 +1537,7 @@ enum {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = 0x2dfff,
+ .max_register = 0x2ffff,
.fast_io = true,
};
@@ -1315,16 +1557,6 @@ enum {
static int gcc_ipq4019_probe(struct platform_device *pdev)
{
- struct device *dev = &pdev->dev;
-
- clk_register_fixed_rate(dev, "fepll125", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "fepll125dly", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "fepllwcss2g", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "fepllwcss5g", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "fepll200", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "fepll500", "xo", 0, 200000000);
- clk_register_fixed_rate(dev, "ddrpllapss", "xo", 0, 666000000);
-
return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
}
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
index 6240e5b..a906d46 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
@@ -81,6 +81,15 @@
#define GCC_WCSS5G_CLK 62
#define GCC_WCSS5G_REF_CLK 63
#define GCC_WCSS5G_RTC_CLK 64
+#define GCC_APSS_DDRPLL_VCO 65
+#define GCC_SDCC_PLLDIV_CLK 66
+#define GCC_FEPLL_VCO 67
+#define GCC_FEPLL125_CLK 68
+#define GCC_FEPLL125DLY_CLK 69
+#define GCC_FEPLL200_CLK 70
+#define GCC_FEPLL500_CLK 71
+#define GCC_FEPLL_WCSS2G_CLK 72
+#define GCC_FEPLL_WCSS5G_CLK 73
#define WIFI0_CPU_INIT_RESET 0
#define WIFI0_RADIO_SRIF_RESET 1
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v4 0/6] Patches for QCOM IPQ4019 clock driver
From: Abhishek Sahu @ 2016-11-25 15:41 UTC (permalink / raw)
To: andy.gross, david.brown, mturquette, sboyd
Cc: robh+dt, mark.rutland, varada, pradeepb, snlakshm, linux-arm-msm,
linux-soc, linux-clk, linux-kernel, devicetree, Abhishek Sahu
These patches are related to Qualcomm IPQ4019 GCC (Global Clock
Controller) driver code mainly adding the nodes for clock marked
as fixed in current IPQ4019 clock driver and support for multiple
CPU frequencies.
[V4]
1. Addressed the review comments given in v3 patches.
2. Removed the intermediate VCO clocks and make VCO as
part of final divider clock.
3. Changed some variable and structure names.
4. Removed intermediate frequency change patch and merged
in the main patch itself.
5. Added the APSS CPU frequency change notifier patch
6. Removed i2c node frequency table which is already reviewed.
[V3]
1. Addressed the review comments given in v2 patches.
2. Replaced the do_div with normal division.
3. Marked the PCNOC node as critical.
4. Modified the frequency values for the recent change done
in IPQ4019 bootloader.
5. Changed the i2c node frequency table for 19.05 MHz clock.
[V2]
1. Removed the fixed clock references and add the same as clock nodes
with recalc_rate operation.
Abhishek Sahu (6):
clk: qcom: ipq4019: remove fixed clocks and add pll clocks
clk: qcom: ipq4019: Add the apss cpu pll divider clock node
clk: qcom: ipq4019: Add the nodes for pcnoc
clk: qcom: ipq4019: correct sdcc frequency and parent name
clk: qcom: ipq4019: Add all the frequencies for apss cpu
clk: qcom: ipq4019: Add the cpu clock frequency change notifier
drivers/clk/qcom/gcc-ipq4019.c | 484 ++++++++++++++++++++++++++-
include/dt-bindings/clock/qcom,gcc-ipq4019.h | 11 +
2 files changed, 481 insertions(+), 14 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Bartosz Golaszewski @ 2016-11-25 15:37 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
It has been determined that the maximum resolution supported correctly
by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
constraints we must filter out higher modes.
Specify the max-bandwidth property for the display node for
da850-based boards.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8e30d9b..9b7c444 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -452,6 +452,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-bandwidth = <28800000>;
status = "disabled";
ports {
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: Question regarding clocks in the DW-HDMI DT bindings
From: Fabio Estevam @ 2016-11-25 15:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andy Yan, Vladimir Zapolskiy, DRI mailing list,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mike Turquette, Stephen Boyd, nickey.yang-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <2404891.arL9itCrmb@avalon>
On Fri, Nov 25, 2016 at 1:22 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
>> I got the clock name from I.MX6Q TRM, I also checked the name again
>> with Rockchip IC design team now, hope to get some new information soon.
>
> Thank you. While at it, could you ask them which version of the DW HDMI IP
> used in the SoC ?
DW HDMI IP used in Rockchip is:
dwhdmi-rockchip ff980000.hdmi: Detected HDMI controller 0x20:0xa:0xa0:0xc1
as shown at https://storage.kernelci.org/mainline/v4.9-rc6-157-g16ae16c6e561/arm-multi_v7_defconfig/lab-collabora/boot-rk3288-rock2-square_rootfs:nfs.html
DW HDMI IP used on mx6q is:
dwhdmi-imx 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: sx150x: add support for sx1501, sx1504, sx1505 and sx1507
From: Neil Armstrong @ 2016-11-25 15:24 UTC (permalink / raw)
To: Linus Walleij, Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Andrey Smirnov,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdZb5Tsbet994UNhQfPw3bojtisU0CC-RWw4DBuK79HzLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/25/2016 02:45 PM, Linus Walleij wrote:
> On Thu, Nov 24, 2016 at 9:45 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>
>> Untested, register offsets carefully copied from datasheets.
>>
>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>
> Why not. Nice to support all of them.
>
> Patch applied, fixing the typ you mentioned in the follow
> up in the process.
>
> Yours,
> Linus Walleij
>
Thanks peter,
Semtech should definitely provide some samples to test these variants !
I had a very hard time to find a (cheap) breakout board for one of these chips...
But it's better than nothing to have them supported by the kernel even if some bug may appear.
Neil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Question regarding clocks in the DW-HDMI DT bindings
From: Laurent Pinchart @ 2016-11-25 15:22 UTC (permalink / raw)
To: Andy Yan
Cc: devicetree, Mike Turquette, Stephen Boyd, DRI mailing list,
nickey.yang, Vladimir Zapolskiy
In-Reply-To: <0bd7dab3-b51c-2c88-dacf-24ba588349bc@rock-chips.com>
Hi Andy,
On Friday 25 Nov 2016 10:56:53 Andy Yan wrote:
> On 2016年11月25日 07:26, Laurent Pinchart wrote:
> > On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote:
> >> On 11/25/2016 12:07 AM, Fabio Estevam wrote:
> >>> On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart wrote:
> >>>> Hi Andy,
> >>>>
> >>>> As the author of the DW-HDMI DT bindings this question is addressed to
> >>>> you, but information from anyone is more than welcome.
> >>>>
> >>>> The DT bindings specify two clocks named "iahb" and "isfr" but don't
> >>>> describe them. While I assume that the "isfr" clock corresponds to the
> >>>> "isfrclk" input signal of the DW HDMI, there is no "iahb" clock
> >>>> described in the IP core datasheet.
> >>>
> >>> i.MX6Q has a DW-HDMI IP block.
> >>>
> >>> The names in the devicetree binding matches the ones listed at the
> >>> i.MX6Q Reference Manual - Table 33-1. HDMI Clocks
> >>
> >> correct, for your convenience the table is copied below:
> >>
> >> Clock name | Clock Root | Description
> >> -----------+--------------------+---------------------------------------
> >> iahbclk | ahb_clk_root | Bus clock
> >> icecclk | ckil_sync_clk_root | CEC low-frequency clock (32kHZ)
> >> ihclk | ahb_clk_root | Module clock
> >> isfrclk | video_27m_clk_root | Internal SFR clock (video clock
> >> 27MHz)
> >>
> >> Here AHB stands for ARM Advanced High-performance Bus.
> >
> > That's what I suspected. I believe the "iahb" name is wrong, as the DW
> > HDMI TX IP core clearly documents the bus clock as being called
> > "iapbclk". We could rename that in the DT bindings (with compatibility
> > code in the driver to keep supporting the old name) but it might not be
> > worth it. The bindings should however document that the "iahb" clock is
> > the IP core's "iapbclk" bus clock.
>
> I got the clock name from I.MX6Q TRM, I also checked the name again
> with Rockchip IC design team now, hope to get some new information soon.
Thank you. While at it, could you ask them which version of the DW HDMI IP
used in the SoC ?
> > Another question I have about the bus clock (CC'ing the devicetree mailing
> > list as well as the clock maintainers) is whether it should be made
> > optional. The clock is obviously mandatory from a hardware point of view
> > (given that APB is a synchronous bus and thus requires a clock), but in
> > some SoCs (specifically for the Renesas SoCs) that clock is always on and
> > can't be controlled. We already omit bus clocks in DT for most IP cores
> > when the clock can never be controlled (and we also omit a bunch of other
> > clocks that we don't even know exist), so it could make sense to make the
> > clock optional. Otherwise there would be runtime overhead trying to handle
> > a clock that can't be controlled.
>
> If this is the case on Renesas SOCs, we can consider make the clock as
> optional. Or move all the clock operations to platform specific
> code(dw_hdmi-rockchip.c/dw_hdmi-imx.c)?
I'd prefer keeping the code generic, otherwise we'd end up with platform-
specific code that would perform the same operations on most platforms. I'll
submit a patch soon to make the clock optional, we can discuss it then.
> >> By the way while we're discussing DW HDMI bindings specific to iMX,
> >> I would recommend to remove utterly hackish and iMX only "gpr"
> >> property from the example in bindings/display/bridge/dw_hdmi.txt
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-11-25 15:20 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
linux-arm-kernel
In-Reply-To: <20161124210509.be743aae84c26c6c2e666c6e@bidouilliste.com>
[-- Attachment #1.1: Type: text/plain, Size: 1266 bytes --]
On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> On Thu, 24 Nov 2016 20:55:17 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > others three only have 1.
> > > Add the num-cs property to each node.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> >
> > I don't think we have any code that uses it at the moment. What is the
> > rationale behind this patch?
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> Hi Maxime,
>
> If num-cs isn't present nothing prevent to start a transfer with a
> non-valid CS pin, resulting in an error.
> num-cs are default property especially made for this and a SPI driver
> should try to get the property at probe/attach time.
Yes, but as far as I know, our driver doesn't. I'm all in for having
support for that in our driver, but without it, that patch is kind of
useless.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 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 RESEND 2/2] gpio: axp209: add pinctrl support
From: Maxime Ripard @ 2016-11-25 15:17 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, gnurou, devicetree, linus.walleij, linux-kernel,
linux-gpio, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20161123141151.25315-3-quentin.schulz@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 927 bytes --]
Hi,
On Wed, Nov 23, 2016 at 03:11:51PM +0100, Quentin Schulz wrote:
> The GPIOs present in the AXP209 PMIC have multiple functions. They
> typically allow a pin to be used as GPIO input or output and can also be
> used as ADC or regulator for example.[1]
>
> This adds the possibility to use all functions of the GPIOs present in
> the AXP209 PMIC thanks to pinctrl subsystem.
>
> [1] see registers 90H, 92H and 93H at
> http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
I've said it already face to face, but ideally you should split that
patch into logical changes.
I can see here at least three:
- Adding the pinctrl features
- Renaming the structure and functions
- Removal of a few functions
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 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 v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-11-25 15:12 UTC (permalink / raw)
To: Cédric Le Goater, Joel Stanley
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <b9d8ba33-2bb9-cb93-d833-89ddd8cfd7f9-Bxea+6Xhats@public.gmane.org>
On 11/25/2016 04:01 PM, Cédric Le Goater wrote:
> Hello Marek,
Hi!
> Sorry for the late answer. Here are a couple of answers to the naming
> problem
>
> On 11/25/2016 02:57 PM, Marek Vasut wrote:
>> On 11/21/2016 05:45 AM, Joel Stanley wrote:
>>> Hello Marek,
>>
>> Hi!
>>
>>> Thank you for the review. I have answered a few of your questions;
>>> I'll leave the rest to Cedric.
>>>
>>> On Mon, Nov 21, 2016 at 8:13 AM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>>>>> index 4a682ee0f632..96148600fdab 100644
>>>>> --- a/drivers/mtd/spi-nor/Kconfig
>>>>> +++ b/drivers/mtd/spi-nor/Kconfig
>>>>> @@ -76,4 +76,16 @@ config SPI_NXP_SPIFI
>>>>> Flash. Enable this option if you have a device with a SPIFI
>>>>> controller and want to access the Flash as a mtd device.
>>>>>
>>>>> +config ASPEED_FLASH_SPI
>>>>
>>>> Should be SPI_ASPEED , see the other controllers and keep the list sorted.
>>>
>>> Perhaps SPI_NOR_ASPEED so it's clear it's not a driver for a generic SPI bus?
>>
>> But it's not a driver for SPI-NOR only either, it seems it's a driver
>> for multiple distinct devices.
>
> yes and I think it was a mistake to send the whole at once. We have
> added the support in qemu controller by controller and it was easier
> to understand. I need to split the patchset in the next version.
Cool :-)
>>>>> + tristate "Aspeed flash controllers in SPI mode"
>>>>> + depends on HAS_IOMEM && OF
>>>>> + depends on ARCH_ASPEED || COMPILE_TEST
>>>>> + # IO_SPACE_LIMIT must be equivalent to (~0UL)
>>>>> + depends on !NEED_MACH_IO_H
>>>>
>>>> Why?
>>>>
>>>>> + help
>>>>> + This enables support for the New Static Memory Controller
>>>>> + (FMC) in the Aspeed SoCs (AST2400 and AST2500) when attached
>>>>> + to SPI nor chips, and support for the SPI Memory controller
>>>>> + (SPI) for the BIOS.
>>>>
>>>> I think there is a naming chaos between FMC, SMC (as in Static MC) and
>>>> SMC (as in SPI MC).
>>>
>>> Yes, you're spot on. This naming chaos comes form the vendor's documentation.
>>>
>>> I think we could re-work this sentence to make it clearer.
>>
>> Please do before someone's head explodes from this :)
>
> Indeed .. :) I will give a try. Here is the status :
>
> Aspeed SoC AST2400 has a set of SMC (Static Memory Controller)
> controllers in which you find :
>
> - Legacy Static Memory Controller (called SMC in the spec)
> . base address at 0x16000000
> . BMC firmware
> . old register set
> . supports NOR flash, NAND flash and SPI flash memory. All bootable.
> . 1 chip select pin (CE0)
>
> - New Static Memory Controller (called FMC in the spec)
> . base address at 0x16200000
> . BMC firmware
> . new register set
> . supports NOR flash, NAND flash and SPI flash memory.
> . 5 chip select pins (CE0 ∼ CE4)
>
> - SPI Flash Controller (called SPI in the spec)
> . base address at 0x16300000
> . host Firmware
> . exotic register set, between old and new ...
> . supports SPI flash memory
> . 1 chip select pin (CE0)
This should be (except for the base address) be in some documentation,
it helps.
> Aspeed SoC AST2500 defines has a similar set of SMC (Static Memory
> Controller) controllers, more in the vein of the AST2400 FMC :
>
> - Legacy Static Memory Controller is gone, NOR and NAND support also
>
> - Firmware SPI Memory Controller (called FMC in the spec)
> . base address at 0x16200000
> . BMC firmware
> . new register set
> . supports SPI flash memory.
> . 3 chip select pins (CE0 ~ CE2)
>
> - SPI Flash Controller (called SPI1 in the spec) first
> . base address at 0x16300000
> . host firmware
> . new register set
> . supports SPI flash memory.
> . 2 chip select pins (CE0 ~ CE1)
>
> - SPI Flash Controller (called SPI2 in the spec) second
> . base address at 0x16310000
> . host firmware
> . new register set
> . supports SPI flash memory.
> . 2 chip select pins (CE0 ~ CE1)
>
>
> So, these are the reasons behind the naming mess. Added to that the
> driver considers the acronym SMC to stand for SPI Memory Controller,
> which is wrong. I tried to reduce the confusion with some comments but
> that was a failure :)
The explanation above is awesome though.
> In qemu, we have used FMC (Firmware ...) and SPI to name the controllers
> and we just dropped the legacy SMC. I think using the same naming scheme
> is a good idea. We don't support anything else than SPI either so we can
> drop the other types for the moment.
One thing which I still ponder about is how do you support those
controllers which support NOR and NAND flash and SPI, do you tap
into all subsystems ?
>>>>> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
>>>>> + size_t len)
>>>>> +{
>>>>
>>>> What if start of buf is unaligned ?
>>>>
>>>>> + if ((((unsigned long)src | (unsigned long)buf | len) & 3) == 0) {
>>>>
>>>> Uh, should use boolean OR, not bitwise or. Also, if you're testing
>>>> pointer for NULL, do if (!ptr) .
>>>>
>>>> if (!src || !buf || !len)
>>>> return;
>>>
>>> That's a different test. We're testing here that the buffers are
>>> aligned to see if we can do a word-at-a-time copy.
>>>
>>> If not, it falls through to do a byte-at-a-time copy. I think this
>>> covers your first question about buf being unaligned.
>>
>> Ah, I see, thanks for clarifying. Comment in the code would be helpful
>> for why what you're doing is OK. And I think you want to cast to
>> uintptr_t instead to make this work on 64bit.
>
> yes
>
>>> Cedric, perhaps you could create a macro called IS_ALLIGNED to make it
>>> clear what this is doing?
>>
>> Yup, thanks!
>
> sure. I still need to go through Marek's comments in the initial email,
> I will split the pachset and fix the naming in next version.
Thanks!
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Valo, Kalle @ 2016-11-25 15:06 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org,
nbd-Vt+b4OUoWG0@public.gmane.org
In-Reply-To: <87insxg0yc.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:
> Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
>> There are two types of swapping the EEPROM data in the ath9k driver.
>> Before this series one type of swapping could not be used without the
>> other.
>>
>> The first type of swapping looks at the "magic bytes" at the start of
>> the EEPROM data and performs swab16 on the EEPROM contents if needed.
>> The second type of swapping is EEPROM format specific and swaps
>> specific fields within the EEPROM itself (swab16, swab32 - depends on
>> the EEPROM format).
>>
>> With this series the second part now looks at the EEPMISC register
>> inside the EEPROM, which uses a bit to indicate if the EEPROM data
>> is Big Endian (this is also done by the FreeBSD kernel).
>> This has a nice advantage: currently there are some out-of-tree hacks
>> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
>> Big Endian system (= no swab16 is performed) but the EEPROM itself
>> indicates that it's data is Little Endian. Until now the out-of-tree
>> code simply did a swab16 before passing the data to ath9k, so ath9k
>> first did the swab16 - this also enabled the format specific swapping.
>> These out-of-tree hacks are still working with the new logic, but it
>> is recommended to remove them. This implementation is based on a
>> discussion with Arnd Bergmann who raised concerns about the
>> robustness and portability of the swapping logic in the original OF
>> support patch review, see [0].
>>
>> After a second round of patches (= v1 of this series) neither Arnd
>> Bergmann nor I were really happy with the complexity of the EEPROM
>> swapping logic. Based on a discussion (see [1] and [2]) we decided
>> that ath9k should use a defined format (specifying the endianness
>> of the data - I went with __le16 and __le32) when accessing the
>> EEPROM fields. A benefit of this is that we enable the EEPMISC based
>> swapping logic by default, just like the FreeBSD driver, see [3]. On
>> the devices which I have tested (see below) ath9k now works without
>> having to specify the "endian_check" field in ath9k_platform_data (or
>> a similar logic which could provide this via devicetree) as ath9k now
>> detects the endianness automatically. Only EEPROMs which are mangled
>> by some out-of-tree code still need the endian_check flag (or one can
>> simply remove that mangling from the out-of-tree code).
>>
>> Testing:
>> - tested by myself on AR9287 with Big Endian EEPROM
>> - tested by myself on AR9227 with Little Endian EEPROM
>> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
>> which did not suffer from this whole problem)
>> - how do we proceed with testing? maybe we could keep this in a
>> feature-branch and add these patches to LEDE once we have an ACK to
>> get more people to test this
>>
>> This series depends on my other series (v7):
>> "add devicetree support to ath9k" - see [4]
>
> I think this looks pretty good. If there's a bug somewhere it should be
> quite easy to fix so I'm not that worried and would be willing to take
> these as soon as I have applied the dependency series. IIRC your
> devicetree patches will have at least one more review round so that will
> take some time still. In the meantime it would be great if LEDE folks
> could take a look at these and comment (or test).
So are everyone happy with this? I haven't seen any comments. If I don't
here anything I'm planning to take these, most likely for 4.11.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Cédric Le Goater @ 2016-11-25 15:01 UTC (permalink / raw)
To: Marek Vasut, Joel Stanley
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Rob Herring, linux-mtd, Cyrille Pitchen, Brian Norris,
David Woodhouse
In-Reply-To: <9569aaca-5748-e82d-20e1-ed846fb762f6@gmail.com>
Hello Marek,
Sorry for the late answer. Here are a couple of answers to the naming
problem
On 11/25/2016 02:57 PM, Marek Vasut wrote:
> On 11/21/2016 05:45 AM, Joel Stanley wrote:
>> Hello Marek,
>
> Hi!
>
>> Thank you for the review. I have answered a few of your questions;
>> I'll leave the rest to Cedric.
>>
>> On Mon, Nov 21, 2016 at 8:13 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>>>> index 4a682ee0f632..96148600fdab 100644
>>>> --- a/drivers/mtd/spi-nor/Kconfig
>>>> +++ b/drivers/mtd/spi-nor/Kconfig
>>>> @@ -76,4 +76,16 @@ config SPI_NXP_SPIFI
>>>> Flash. Enable this option if you have a device with a SPIFI
>>>> controller and want to access the Flash as a mtd device.
>>>>
>>>> +config ASPEED_FLASH_SPI
>>>
>>> Should be SPI_ASPEED , see the other controllers and keep the list sorted.
>>
>> Perhaps SPI_NOR_ASPEED so it's clear it's not a driver for a generic SPI bus?
>
> But it's not a driver for SPI-NOR only either, it seems it's a driver
> for multiple distinct devices.
yes and I think it was a mistake to send the whole at once. We have
added the support in qemu controller by controller and it was easier
to understand. I need to split the patchset in the next version.
>>>> + tristate "Aspeed flash controllers in SPI mode"
>>>> + depends on HAS_IOMEM && OF
>>>> + depends on ARCH_ASPEED || COMPILE_TEST
>>>> + # IO_SPACE_LIMIT must be equivalent to (~0UL)
>>>> + depends on !NEED_MACH_IO_H
>>>
>>> Why?
>>>
>>>> + help
>>>> + This enables support for the New Static Memory Controller
>>>> + (FMC) in the Aspeed SoCs (AST2400 and AST2500) when attached
>>>> + to SPI nor chips, and support for the SPI Memory controller
>>>> + (SPI) for the BIOS.
>>>
>>> I think there is a naming chaos between FMC, SMC (as in Static MC) and
>>> SMC (as in SPI MC).
>>
>> Yes, you're spot on. This naming chaos comes form the vendor's documentation.
>>
>> I think we could re-work this sentence to make it clearer.
>
> Please do before someone's head explodes from this :)
Indeed .. :) I will give a try. Here is the status :
Aspeed SoC AST2400 has a set of SMC (Static Memory Controller)
controllers in which you find :
- Legacy Static Memory Controller (called SMC in the spec)
. base address at 0x16000000
. BMC firmware
. old register set
. supports NOR flash, NAND flash and SPI flash memory. All bootable.
. 1 chip select pin (CE0)
- New Static Memory Controller (called FMC in the spec)
. base address at 0x16200000
. BMC firmware
. new register set
. supports NOR flash, NAND flash and SPI flash memory.
. 5 chip select pins (CE0 ∼ CE4)
- SPI Flash Controller (called SPI in the spec)
. base address at 0x16300000
. host Firmware
. exotic register set, between old and new ...
. supports SPI flash memory
. 1 chip select pin (CE0)
Aspeed SoC AST2500 defines has a similar set of SMC (Static Memory
Controller) controllers, more in the vein of the AST2400 FMC :
- Legacy Static Memory Controller is gone, NOR and NAND support also
- Firmware SPI Memory Controller (called FMC in the spec)
. base address at 0x16200000
. BMC firmware
. new register set
. supports SPI flash memory.
. 3 chip select pins (CE0 ~ CE2)
- SPI Flash Controller (called SPI1 in the spec) first
. base address at 0x16300000
. host firmware
. new register set
. supports SPI flash memory.
. 2 chip select pins (CE0 ~ CE1)
- SPI Flash Controller (called SPI2 in the spec) second
. base address at 0x16310000
. host firmware
. new register set
. supports SPI flash memory.
. 2 chip select pins (CE0 ~ CE1)
So, these are the reasons behind the naming mess. Added to that the
driver considers the acronym SMC to stand for SPI Memory Controller,
which is wrong. I tried to reduce the confusion with some comments but
that was a failure :)
In qemu, we have used FMC (Firmware ...) and SPI to name the controllers
and we just dropped the legacy SMC. I think using the same naming scheme
is a good idea. We don't support anything else than SPI either so we can
drop the other types for the moment.
>>>> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
>>>> + size_t len)
>>>> +{
>>>
>>> What if start of buf is unaligned ?
>>>
>>>> + if ((((unsigned long)src | (unsigned long)buf | len) & 3) == 0) {
>>>
>>> Uh, should use boolean OR, not bitwise or. Also, if you're testing
>>> pointer for NULL, do if (!ptr) .
>>>
>>> if (!src || !buf || !len)
>>> return;
>>
>> That's a different test. We're testing here that the buffers are
>> aligned to see if we can do a word-at-a-time copy.
>>
>> If not, it falls through to do a byte-at-a-time copy. I think this
>> covers your first question about buf being unaligned.
>
> Ah, I see, thanks for clarifying. Comment in the code would be helpful
> for why what you're doing is OK. And I think you want to cast to
> uintptr_t instead to make this work on 64bit.
yes
>> Cedric, perhaps you could create a macro called IS_ALLIGNED to make it
>> clear what this is doing?
>
> Yup, thanks!
sure. I still need to go through Marek's comments in the initial email,
I will split the pachset and fix the naming in next version.
Thanks,
C.
>>>
>>> while (...)
>>>
>>>> + while (len > 3) {
>>>> + *(u32 *)buf = readl(src);
>>>> + buf += 4;
>>>> + src += 4;
>>>> + len -= 4;
>>>> + }
>>>> + }
>>>> +
>>>> + while (len--) {
>>>> + *(u8 *)buf = readb(src);
>>>> + buf += 1;
>>>> + src += 1;
>>>> + }
>>>> + return 0;
>>>> +}
>>>> +/*
>>>> + * SPI Flash Configuration Register (AST2400 SPI)
>>>> + */
>>>> +#define CONFIG_REG 0x0
>>>> +#define CONFIG_ENABLE_CE_INACTIVE BIT(1)
>>>> +#define CONFIG_WRITE BIT(0)
>>>
>>> #define[space]FOO[tab]BIT(bar)
>>
>> These are bits within the CONFIG_REG. It follows the same style as
>> other spi-nor drivers, eg. nxp-spifi.
>>
>> I think it's somewhat clearer, but if you have a strong preference
>> against then fair enough.
>
> It triggers my OCD, but I think it's a matter of taste, so I don't care
> that much.
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v6 2/2] DW DMAC: add multi-block property to device tree
From: Eugeniy Paltsev @ 2016-11-25 14:59 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, christian.ruppert, arnd, vinod.koul,
vireshk, linux-kernel, Eugeniy Paltsev, robh+dt, dmaengine,
andriy.shevchenko, shiraz.linux.kernel
In-Reply-To: <1480085947-31273-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Also:
Update DT documentation.
Update existing platform data and DTS.
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
arch/arc/boot/dts/abilis_tb10x.dtsi | 1 +
arch/arm/boot/dts/spear13xx.dtsi | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 12 +++++++++++-
drivers/dma/dw/regs.h | 3 ++-
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 5 +++--
8 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..4775c66f 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,8 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- multi-block: Multi block transfers supported by hardware. Array property with
+ one cell per channel. 0: not supported, 1 (default): supported.
Example:
diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi b/arch/arc/boot/dts/abilis_tb10x.dtsi
index de53f5c..3121536 100644
--- a/arch/arc/boot/dts/abilis_tb10x.dtsi
+++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
@@ -129,6 +129,7 @@
data-width = <4>;
clocks = <&ahb_clk>;
clock-names = "hclk";
+ multi-block = <1 1 1 1 1 1>;
};
i2c0: i2c@FF120000 {
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index 449acf0..17ea0ab 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -118,6 +118,7 @@
block_size = <0xfff>;
dma-masters = <2>;
data-width = <8 8>;
+ multi-block = <1 1 1 1 1 1 1 1>;
};
dma@eb000000 {
@@ -134,6 +135,7 @@
chan_priority = <1>;
block_size = <0xfff>;
data-width = <8 8>;
+ multi-block = <1 1 1 1 1 1 1 1>;
};
fsmc: flash@b0000000 {
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..e5adf5d 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = !pdata->multi_block[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index aa7a5c1..b1655e4 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -102,7 +102,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct dw_dma_platform_data *pdata;
- u32 tmp, arr[DW_DMA_MAX_NR_MASTERS];
+ u32 tmp, arr[DW_DMA_MAX_NR_MASTERS], mb[DW_DMA_MAX_NR_CHANNELS];
u32 nr_masters;
u32 nr_channels;
@@ -118,6 +118,8 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_u32(np, "dma-channels", &nr_channels))
return NULL;
+ if (nr_channels > DW_DMA_MAX_NR_CHANNELS)
+ return NULL;
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -152,6 +154,14 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "multi-block", mb, nr_channels)) {
+ for (tmp = 0; tmp < nr_channels; tmp++)
+ pdata->multi_block[tmp] = mb[tmp];
+ } else {
+ for (tmp = 0; tmp < nr_channels; tmp++)
+ pdata->multi_block[tmp] = 1;
+ }
+
return pdata;
}
#else
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index f65dd10..4e0128c 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -12,7 +12,8 @@
#include <linux/interrupt.h>
#include <linux/dmaengine.h>
-#define DW_DMA_MAX_NR_CHANNELS 8
+#include "internal.h"
+
#define DW_DMA_MAX_NR_REQUESTS 16
/* flow controller */
diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
index f607946..58cbb30 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -157,12 +157,12 @@ static int byt_serial_setup(struct lpss8250 *lpss, struct uart_port *port)
static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
.nr_channels = 2,
.is_private = true,
- .is_nollp = true,
.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
.chan_priority = CHAN_PRIORITY_ASCENDING,
.block_size = 4095,
.nr_masters = 1,
.data_width = {4},
+ .multi_block = {0},
};
static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..e69e415 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -14,6 +14,7 @@
#include <linux/device.h>
#define DW_DMA_MAX_NR_MASTERS 4
+#define DW_DMA_MAX_NR_CHANNELS 8
/**
* struct dw_dma_slave - Controller-specific information about a slave
@@ -40,19 +41,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @multi_block: Multi block transfers supported by hardware per channel.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +62,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH v6 1/2] DW DMAC: enable memory-to-memory transfers support
From: Eugeniy Paltsev @ 2016-11-25 14:59 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, christian.ruppert, arnd, vinod.koul,
vireshk, linux-kernel, Eugeniy Paltsev, robh+dt, dmaengine,
andriy.shevchenko, shiraz.linux.kernel
In-Reply-To: <1480085947-31273-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ /*
+ * All known devices, which use DT for configuration, support
+ * memory-to-memory transfers. So enable it by default.
+ */
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ permalink raw reply related
* [PATCH v6 0/2] DW DMAC: update device tree
From: Eugeniy Paltsev @ 2016-11-25 14:59 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, christian.ruppert, arnd, vinod.koul,
vireshk, linux-kernel, Eugeniy Paltsev, robh+dt, dmaengine,
andriy.shevchenko, shiraz.linux.kernel
It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
Changes for v6:
* Use "supported" as default state for "multi-block" property,
to keep old DTBs working. Pointed by Andy Shevchenko.
Changes for v5:
* Update existing DTS. Pointed by Andy Shevchenko.
* Read multi-block per chanel instead of per master (Move
DW_DMA_MAX_NR_CHANNELS define from regs.h to dma-dw.h to
implement this) Pointed by Andy Shevchenko.
Changes for v4:
* Fix setting inverted value to "dwc->nollp". My fault - I
tested with wrong DTS, so DMAC was configured from autoconfig
instead of device tree. Pointed by Andy Shevchenko.
* Update "multi-block" diescription in documentation to be more
clear. Pointed by Arnd Bergmann.
Changes for v3:
* Update existing platform data.
We don't need to update existing DTS because default logic
wasn't change: we don't set "is_nollp" if we read
configuration from DT before. And we don't set it now if
"multi-block" property doesn't exist in DTS.
Changes for v2:
* I thought about is_memcpy DT property: all known devices, which
use DT for configuration, support memory-to-memory transfers.
So we don't need to read it from DT. So enable it by default,
if we read configuration from DT.
* Use "multi-block" instead of "hw-llp" name to be more clear.
* Move adding DT property and adding documentation for this
property to one patch.
Eugeniy Paltsev (2):
DW DMAC: enable memory-to-memory transfers support
DW DMAC: add multi-block property to device tree
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
arch/arc/boot/dts/abilis_tb10x.dtsi | 1 +
arch/arm/boot/dts/spear13xx.dtsi | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 18 +++++++++++++++++-
drivers/dma/dw/regs.h | 3 ++-
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 5 +++--
8 files changed, 29 insertions(+), 6 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver
From: Todor Tomov @ 2016-11-25 14:56 UTC (permalink / raw)
To: mchehab, laurent.pinchart+renesas, hans.verkuil, javier,
s.nawrocki, linux-media, linux-kernel, robh+dt, mark.rutland,
devicetree
Cc: bjorn.andersson, srinivas.kandagatla, Todor Tomov
Add DT binding document for Qualcomm Camera subsystem driver.
Signed-off-by: Todor Tomov <todor.tomov@linaro.org>
---
.../devicetree/bindings/media/qcom,camss.txt | 196 +++++++++++++++++++++
1 file changed, 196 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt b/Documentation/devicetree/bindings/media/qcom,camss.txt
new file mode 100644
index 0000000..76ad89a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
@@ -0,0 +1,196 @@
+Qualcomm Camera Subsystem
+
+* Properties
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain:
+ - "qcom,8x16-camss"
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Register ranges as listed in the reg-names property.
+- reg-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "csiphy0"
+ - "csiphy0_clk_mux"
+ - "csiphy1"
+ - "csiphy1_clk_mux"
+ - "csid0"
+ - "csid1"
+ - "ispif"
+ - "csi_clk_mux"
+ - "vfe0"
+- interrupts:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Interrupts as listed in the interrupt-names property.
+- interrupt-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "csiphy0"
+ - "csiphy1"
+ - "csid0"
+ - "csid1"
+ - "ispif"
+ - "vfe0"
+- power-domains:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A phandle and power domain specifier pairs to the
+ power domain which is responsible for collapsing
+ and restoring power to the peripheral.
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A list of phandle and clock specifier pairs as listed
+ in clock-names property.
+- clock-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "camss_top_ahb_clk"
+ - "ispif_ahb_clk"
+ - "csiphy0_timer_clk"
+ - "csiphy1_timer_clk"
+ - "csi0_ahb_clk"
+ - "csi0_clk"
+ - "csi0_phy_clk"
+ - "csi0_pix_clk"
+ - "csi0_rdi_clk"
+ - "csi1_ahb_clk"
+ - "csi1_clk"
+ - "csi1_phy_clk"
+ - "csi1_pix_clk"
+ - "csi1_rdi_clk"
+ - "camss_ahb_clk"
+ - "camss_vfe_vfe_clk"
+ - "camss_csi_vfe_clk"
+ - "iface_clk"
+ - "bus_clk"
+- vdda-supply:
+ Usage: required
+ Value type: <phandle>
+ Definition: A phandle to voltage supply for CSI2.
+- iommus:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A list of phandle and IOMMU specifier pairs.
+
+* Nodes
+
+- ports:
+ Usage: required
+ Definition: As described in video-interfaces.txt in same directory.
+ Properties:
+ - reg:
+ Usage: required
+ Value type: <u32>
+ Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
+ Endpoint node properties:
+ - clock-lanes:
+ Usage: required
+ Value type: <u32>
+ Definition: The clock lane.
+ - data-lanes:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: An array of data lanes.
+ - qcom,settle-cnt:
+ Usage: required
+ Value type: <u32>
+ Definition: The settle count parameter for CSI PHY.
+
+* An Example
+
+ camss: camss@1b00000 {
+ compatible = "qcom,8x16-camss";
+ reg = <0x1b0ac00 0x200>,
+ <0x1b00030 0x4>,
+ <0x1b0b000 0x200>,
+ <0x1b00038 0x4>,
+ <0x1b08000 0x100>,
+ <0x1b08400 0x100>,
+ <0x1b0a000 0x500>,
+ <0x1b00020 0x10>,
+ <0x1b10000 0x1000>;
+ reg-names = "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "csid0",
+ "csid1",
+ "ispif",
+ "csi_clk_mux",
+ "vfe0";
+ interrupts = <GIC_SPI 78 0>,
+ <GIC_SPI 79 0>,
+ <GIC_SPI 51 0>,
+ <GIC_SPI 52 0>,
+ <GIC_SPI 55 0>,
+ <GIC_SPI 57 0>;
+ interrupt-names = "csiphy0",
+ "csiphy1",
+ "csid0",
+ "csid1",
+ "ispif",
+ "vfe0";
+ power-domains = <&gcc VFE_GDSC>;
+ clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE_AXI_CLK>;
+ clock-names = "camss_top_ahb_clk",
+ "ispif_ahb_clk",
+ "csiphy0_timer_clk",
+ "csiphy1_timer_clk",
+ "csi0_ahb_clk",
+ "csi0_clk",
+ "csi0_phy_clk",
+ "csi0_pix_clk",
+ "csi0_rdi_clk",
+ "csi1_ahb_clk",
+ "csi1_clk",
+ "csi1_phy_clk",
+ "csi1_pix_clk",
+ "csi1_rdi_clk",
+ "camss_ahb_clk",
+ "camss_vfe_vfe_clk",
+ "camss_csi_vfe_clk",
+ "iface_clk",
+ "bus_clk";
+ vdda-supply = <&pm8916_l2>;
+ iommus = <&apps_iommu 3>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ csiphy0_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ qcom,settle-cnt = <0xe>;
+ remote-endpoint = <&ov5645_ep>;
+ };
+ };
+ };
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] usb: ohci: s3c2410: allow probing from device tree
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, stern, kgene, krzk, javier,
linux-usb, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc
Cc: Sergio Prado
In-Reply-To: <1480085249-25014-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung's s3c2410 USB OHCI controller using a
devicetree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/usb/host/ohci-s3c2410.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 7a1919ca543a..d8e03a801f2e 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -457,6 +457,13 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
.resume = ohci_hcd_s3c2410_drv_resume,
};
+static const struct of_device_id ohci_hcd_s3c2410_dt_ids[] = {
+ { .compatible = "samsung,s3c2410-ohci" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, ohci_hcd_s3c2410_dt_ids);
+
static struct platform_driver ohci_hcd_s3c2410_driver = {
.probe = ohci_hcd_s3c2410_drv_probe,
.remove = ohci_hcd_s3c2410_drv_remove,
@@ -464,6 +471,7 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
.driver = {
.name = "s3c2410-ohci",
.pm = &ohci_hcd_s3c2410_pm_ops,
+ .of_match_table = ohci_hcd_s3c2410_dt_ids,
},
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
kgene-DgEjT+Ai2ygdnm+yROfE0A, krzk-DgEjT+Ai2ygdnm+yROfE0A,
javier-JPH+aEBZ4P+UEJcrhfAQsw, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
Cc: Sergio Prado
In-Reply-To: <1480085249-25014-1-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
Adds the device tree bindings description for Samsung S3C2410 and
compatible USB OHCI controller.
Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
---
.../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
new file mode 100644
index 000000000000..e45b38ce2986
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -0,0 +1,22 @@
+Samsung S3C2410 and compatible SoC USB controller
+
+OHCI
+
+Required properties:
+ - compatible: should be "samsung,s3c2410-ohci" for USB host controller
+ - reg: address and lenght of the controller memory mapped region
+ - interrupts: interrupt number for the USB OHCI controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+ "usb-bus-host" for the USB bus clock
+ "usb-host" for the USB host clock
+
+Example:
+
+usb0: ohci@49000000 {
+ compatible = "samsung,s3c2410-ohci";
+ reg = <0x49000000 0x100>;
+ interrupts = <0 0 26 3>;
+ clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
+ clock-names = "usb-bus-host", "usb-host";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] usb: ohci: s3c2410: add device tree support
From: Sergio Prado @ 2016-11-25 14:47 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland, stern, kgene, krzk, javier,
linux-usb, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc
Cc: Sergio Prado
This series adds support for configuring Samsung's s3c2410 and
compatible USB OHCI controller via devicetree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Sergio Prado (2):
dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
usb: ohci: s3c2410: allow probing from device tree
.../devicetree/bindings/usb/s3c2410-usb.txt | 22 ++++++++++++++++++++++
drivers/usb/host/ohci-s3c2410.c | 8 ++++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
--
1.9.1
^ 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