[PATCH v5 03/10] clk: mediatek: Add __initdata and __init for data and functions

[James Liao]

Add __init for clock registration functions, and add __initdata for
mtk_gate_regs initial structures.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-gate.c   |  2 +-
 drivers/clk/mediatek/clk-mt8173.c |  6 +++---
 drivers/clk/mediatek/clk-mtk.c| 13 +++--
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 5702036..576bdb7 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -97,7 +97,7 @@ const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
.disable= mtk_cg_disable_inv,
 };
 
-struct clk *mtk_clk_register_gate(
+struct clk * __init mtk_clk_register_gate(
const char *name,
const char *parent_name,
struct regmap *regmap,
diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4478849..a33a531 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -586,7 +586,7 @@ static const struct mtk_composite top_muxes[] __initconst = 
{
MUX(CLK_TOP_I2S3_B_SEL, "i2s3_b_ck_sel", i2s3_b_ck_parents, 0x120, 8, 
1),
 };
 
-static const struct mtk_gate_regs infra_cg_regs = {
+static const struct mtk_gate_regs infra_cg_regs __initconst = {
.set_ofs = 0x0040,
.clr_ofs = 0x0044,
.sta_ofs = 0x0048,
@@ -615,13 +615,13 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_PMICWRAP, "infra_pmicwrap", "axi_sel", 23),
 };
 
-static const struct mtk_gate_regs peri0_cg_regs = {
+static const struct mtk_gate_regs peri0_cg_regs __initconst = {
.set_ofs = 0x0008,
.clr_ofs = 0x0010,
.sta_ofs = 0x0018,
 };
 
-static const struct mtk_gate_regs peri1_cg_regs = {
+static const struct mtk_gate_regs peri1_cg_regs __initconst = {
.set_ofs = 0x000c,
.clr_ofs = 0x0014,
.sta_ofs = 0x001c,
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 18444ae..268b6ff 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -24,7 +24,7 @@
 #include "clk-mtk.h"
 #include "clk-gate.h"
 
-struct clk_onecell_data *mtk_alloc_clk_data(unsigned int clk_num)
+struct clk_onecell_data * __init mtk_alloc_clk_data(unsigned int clk_num)
 {
int i;
struct clk_onecell_data *clk_data;
@@ -49,8 +49,8 @@ err_out:
return NULL;
 }
 
-void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, int num,
-   struct clk_onecell_data *clk_data)
+void __init mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+   int num, struct clk_onecell_data *clk_data)
 {
int i;
struct clk *clk;
@@ -72,7 +72,8 @@ void mtk_clk_register_factors(const struct mtk_fixed_factor 
*clks, int num,
}
 }
 
-int mtk_clk_register_gates(struct device_node *node, const struct mtk_gate 
*clks,
+int __init mtk_clk_register_gates(struct device_node *node,
+   const struct mtk_gate *clks,
int num, struct clk_onecell_data *clk_data)
 {
int i;
@@ -111,7 +112,7 @@ int mtk_clk_register_gates(struct device_node *node, const 
struct mtk_gate *clks
return 0;
 }
 
-struct clk *mtk_clk_register_composite(const struct mtk_composite *mc,
+struct clk * __init mtk_clk_register_composite(const struct mtk_composite *mc,
void __iomem *base, spinlock_t *lock)
 {
struct clk *clk;
@@ -196,7 +197,7 @@ err_out:
return ERR_PTR(ret);
 }
 
-void mtk_clk_register_composites(const struct mtk_composite *mcs,
+void __init mtk_clk_register_composites(const struct mtk_composite *mcs,
int num, void __iomem *base, spinlock_t *lock,
struct clk_onecell_data *clk_data)
 {
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 04/10] clk: mediatek: Add fixed clocks support for Mediatek SoC.

[James Liao]

This patch adds fixed clocks support by using CCF fixed-rate
clock implementation.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mtk.c | 23 +++
 drivers/clk/mediatek/clk-mtk.h | 17 +
 2 files changed, 40 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 268b6ff..cf08db6 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -49,6 +49,29 @@ err_out:
return NULL;
 }
 
+void __init mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+   int num, struct clk_onecell_data *clk_data)
+{
+   int i;
+   struct clk *clk;
+
+   for (i = 0; i < num; i++) {
+   const struct mtk_fixed_clk *rc = &clks[i];
+
+   clk = clk_register_fixed_rate(NULL, rc->name, rc->parent,
+   rc->parent ? 0 : CLK_IS_ROOT, rc->rate);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n",
+   rc->name, PTR_ERR(clk));
+   continue;
+   }
+
+   if (clk_data)
+   clk_data->clks[rc->id] = clk;
+   }
+}
+
 void __init mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data)
 {
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 740fe5e..32d4f55 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -25,6 +25,23 @@
 
 #define MHZ (1000 * 1000)
 
+struct mtk_fixed_clk {
+   int id;
+   const char *name;
+   const char *parent;
+   unsigned long rate;
+};
+
+#define FIXED_CLK(_id, _name, _parent, _rate) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent = _parent,  \
+   .rate = _rate,  \
+   }
+
+void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
+   int num, struct clk_onecell_data *clk_data);
+
 struct mtk_fixed_factor {
int id;
const char *name;
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks

[James Liao]

From: Sascha Hauer 

On the MT8173 the clocks are provided by different units. To enable
the critical clocks we must be sure that all parent clocks are already
registered, otherwise the parents of the critical clocks end up being
unused and get disabled later.

On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED
PLLs as their parents, so we cannot enable the CLK_TOP critical clocks
until the CLK_APMIXED clocks have all been registered.

To find a place where all parents are registered we try each time
after we've registered some clocks if all known providers are present
now and only then we enable the critical clocks.

Signed-off-by: Sascha Hauer 
Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 412c36d..c7933b2 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -697,6 +697,22 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static struct clk_onecell_data *mt8173_top_clk_data;
+static struct clk_onecell_data *mt8173_pll_clk_data;
+
+static void __init mtk_clk_enable_critical(void)
+{
+   if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
+   return;
+
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
+   clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
+}
+
 static void __init mtk_topckgen_init(struct device_node *node)
 {
struct clk_onecell_data *clk_data;
@@ -709,19 +725,19 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
return;
}
 
-   clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+   mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
-
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
 
@@ -815,13 +831,13 @@ static void __init mtk_apmixedsys_init(struct device_node 
*node)
 {
struct clk_onecell_data *clk_data;
 
-   clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
+   mt8173_pll_clk_data = clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
if (!clk_data)
return;
 
mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
 
-   clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
+   mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
mtk_apmixedsys_init);
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 02/10] clk: mediatek: Remove unused code from MT8173.

[James Liao]

Remove unused header files from MT8173, and remove unused
keywords from function declaration.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 2 --
 drivers/clk/mediatek/clk-mtk.h| 4 ++--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4486f8f..4478849 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -14,8 +14,6 @@
 
 #include 
 #include 
-#include 
-#include 
 
 #include "clk-mtk.h"
 #include "clk-gate.h"
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 9dda9d8..740fe5e 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -41,7 +41,7 @@ struct mtk_fixed_factor {
.div = _div,\
}
 
-extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
+void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
int num, struct clk_onecell_data *clk_data);
 
 struct mtk_composite {
@@ -152,7 +152,7 @@ struct mtk_pll_data {
int pcw_shift;
 };
 
-void __init mtk_clk_register_plls(struct device_node *node,
+void mtk_clk_register_plls(struct device_node *node,
const struct mtk_pll_data *plls, int num_plls,
struct clk_onecell_data *clk_data);
 
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 05/10] clk: mediatek: Fix rate and dependency of MT8173 clocks

[James Liao]

Remove the dependency from clk_null, and give all root clocks a
typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.

dpi_ck was removed due to no clock reference to it.

Replace parent clock of infra_cpum with cpum_ck, which is an external
clock and can be defined in the device tree.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index a33a531..412c36d 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -22,10 +22,9 @@
 
 static DEFINE_SPINLOCK(mt8173_clk_lock);
 
-static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
-   FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
+static const struct mtk_fixed_clk fixed_clks[] __initconst = {
+   FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
+   FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -50,6 +49,7 @@ static const struct mtk_fixed_factor top_divs[] __initconst = 
{
FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
 
+   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1, 3),
FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
 
@@ -608,7 +608,7 @@ static const struct mtk_gate infra_clks[] __initconst = {
GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
-   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
+   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel", 22),
@@ -711,7 +711,7 @@ static void __init mtk_topckgen_init(struct device_node 
*node)
 
clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
 
-   mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias), 
clk_data);
+   mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks), 
clk_data);
mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
&mt8173_clk_lock, clk_data);
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 10/10] arm64: dts: mt8173: Add subsystem clock controller device nodes

[James Liao]

This patch adds device nodes providing subsystem clocks on MT8173,
includes mmsys, imgsys, vdecsys, vencsys and vencltsys.

Signed-off-by: James Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index a2f63e4..32c85cc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -102,6 +102,13 @@
clock-output-names = "clk32k";
};
 
+   cpum_ck: oscillator@2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   clock-output-names = "cpum_ck";
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -227,6 +234,36 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencsys: clock-controller@1800 {
+   compatible = "mediatek,mt8173-vencsys", "syscon";
+   reg = <0 0x1800 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+   };
};
 };
 
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 08/10] clk: mediatek: Add subsystem clocks of MT8173

[James Liao]

Most multimedia subsystem clocks will be accessed by multiple
drivers, so it's a better way to manage these clocks in CCF.
This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
subsystems.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 267 +
 include/dt-bindings/clock/mt8173-clk.h |  97 +++-
 2 files changed, 361 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index c7933b2..4506083 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -25,6 +25,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
 static const struct mtk_fixed_clk fixed_clks[] __initconst = {
FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 * 
MHZ),
+   FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
+   FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
 };
 
 static const struct mtk_fixed_factor top_divs[] __initconst = {
@@ -697,6 +701,183 @@ static const struct mtk_composite peri_clks[] __initconst 
= {
MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 
1),
 };
 
+static const struct mtk_gate_regs cg_regs_4_8_0 __initconst = {
+   .set_ofs = 0x0004,
+   .clr_ofs = 0x0008,
+   .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &cg_regs_4_8_0, \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate img_clks[] __initconst = {
+   GATE_IMG(CLK_IMG_LARB2_SMI, "img_larb2_smi", "mm_sel", 0),
+   GATE_IMG(CLK_IMG_CAM_SMI, "img_cam_smi", "mm_sel", 5),
+   GATE_IMG(CLK_IMG_CAM_CAM, "img_cam_cam", "mm_sel", 6),
+   GATE_IMG(CLK_IMG_SEN_TG, "img_sen_tg", "camtg_sel", 7),
+   GATE_IMG(CLK_IMG_SEN_CAM, "img_sen_cam", "mm_sel", 8),
+   GATE_IMG(CLK_IMG_CAM_SV, "img_cam_sv", "mm_sel", 9),
+   GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
+};
+
+static const struct mtk_gate_regs mm0_cg_regs __initconst = {
+   .set_ofs = 0x0104,
+   .clr_ofs = 0x0108,
+   .sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs mm1_cg_regs __initconst = {
+   .set_ofs = 0x0114,
+   .clr_ofs = 0x0118,
+   .sta_ofs = 0x0110,
+};
+
+#define GATE_MM0(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm0_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+#define GATE_MM1(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = &mm1_cg_regs,   \
+   .shift = _shift,\
+   .ops = &mtk_clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate mm_clks[] __initconst = {
+   /* MM0 */
+   GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
+   GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+   GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
+   GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
+   GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
+   GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
+   GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
+   GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
+   GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
+   GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
+   GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
+   GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
+   GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
+   GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
+   GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
+   GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
+   GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "m

[PATCH v5 07/10] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers

[James Liao]

This adds the binding documentation for the mmsys, imgsys, vdecsys,
vencsys and vencltsys controllers found on Mediatek SoCs.

Signed-off-by: James Liao 
---
 .../bindings/arm/mediatek/mediatek,imgsys.txt  | 22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   | 22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++
 5 files changed, 110 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
new file mode 100644
index 000..b1f2ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -0,0 +1,22 @@
+Mediatek imgsys controller
+
+
+The Mediatek imgsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-imgsys", "syscon"
+- #clock-cells: Must be 1
+
+The imgsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+imgsys: clock-controller@1500 {
+   compatible = "mediatek,mt8173-imgsys", "syscon";
+   reg = <0 0x1500 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
new file mode 100644
index 000..4385946
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -0,0 +1,22 @@
+Mediatek mmsys controller
+
+
+The Mediatek mmsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-mmsys", "syscon"
+- #clock-cells: Must be 1
+
+The mmsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
new file mode 100644
index 000..1faacf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -0,0 +1,22 @@
+Mediatek vdecsys controller
+
+
+The Mediatek vdecsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vdecsys", "syscon"
+- #clock-cells: Must be 1
+
+The vdecsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vdecsys: clock-controller@1600 {
+   compatible = "mediatek,mt8173-vdecsys", "syscon";
+   reg = <0 0x1600 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
new file mode 100644
index 000..3cc299f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
@@ -0,0 +1,22 @@
+Mediatek vencltsys controller
+
+
+The Mediatek vencltsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt8173-vencltsys", "syscon"
+- #clock-cells: Must be 1
+
+The vencltsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+vencltsys: clock-controller@1900 {
+   compatible = "mediatek,mt8173-vencltsys", "syscon";
+   reg = <0 0x1900 0 0x1000>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
new file mode 100644
index 000..5bb2866
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/med

[PATCH v5 01/10] clk: mediatek: Removed unused dpi_ck clock from MT8173

[James Liao]

The dpi_ck clock can be removed because it not actually used
in topckgen and subsystems.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/clk-mt8173.c  | 1 -
 include/dt-bindings/clock/mt8173-clk.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4b9e04c..4486f8f 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -26,7 +26,6 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
 
 static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
-   FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
 };
diff --git a/include/dt-bindings/clock/mt8173-clk.h 
b/include/dt-bindings/clock/mt8173-clk.h
index 4ad76ed..7230c38 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -18,7 +18,6 @@
 /* TOPCKGEN */
 
 #define CLK_TOP_CLKPH_MCK_O1
-#define CLK_TOP_DPI2
 #define CLK_TOP_USB_SYSPLL_125M3
 #define CLK_TOP_HDMITX_DIG_CTS 4
 #define CLK_TOP_ARMCA7PLL_754M 5
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/10] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

[James Liao]

Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
is needed by USB 3.0.

Signed-off-by: James Liao 
---
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 107 +
 drivers/clk/mediatek/clk-mt8173.c  |  47 +++
 drivers/clk/mediatek/clk-mtk.h |   3 +
 drivers/clk/mediatek/clk-pll.c |   7 +--
 include/dt-bindings/clock/mt8173-clk.h |   3 +-
 6 files changed, 161 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..95fdfac 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
 obj-y += clk-mt8135.o
 obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-apmixed.c 
b/drivers/clk/mediatek/clk-apmixed.c
new file mode 100644
index 000..5303c59
--- /dev/null
+++ b/drivers/clk/mediatek/clk-apmixed.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: James Liao 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+
+#define REF2USB_TX_EN  BIT(0)
+#define REF2USB_TX_LPF_EN  BIT(1)
+#define REF2USB_TX_OUT_EN  BIT(2)
+#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
+REF2USB_TX_OUT_EN)
+
+struct mtk_ref2usb_tx {
+   struct clk_hw   hw;
+   void __iomem*base_addr;
+};
+
+static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
+{
+   return container_of(hw, struct mtk_ref2usb_tx, hw);
+}
+
+static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+
+   return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
+}
+
+static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+
+   val |= REF2USB_TX_EN;
+   writel(val, tx->base_addr);
+   udelay(100);
+
+   val |= REF2USB_TX_LPF_EN;
+   writel(val, tx->base_addr);
+
+   val |= REF2USB_TX_OUT_EN;
+   writel(val, tx->base_addr);
+
+   return 0;
+}
+
+static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
+{
+   struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
+   u32 val;
+
+   val = readl(tx->base_addr);
+   val &= ~REF2USB_EN_MASK;
+   writel(val, tx->base_addr);
+}
+
+static const struct clk_ops mtk_ref2usb_tx_ops = {
+   .is_prepared= mtk_ref2usb_tx_is_prepared,
+   .prepare= mtk_ref2usb_tx_prepare,
+   .unprepare  = mtk_ref2usb_tx_unprepare,
+};
+
+struct clk * __init mtk_clk_register_ref2usb_tx(const char *name,
+   const char *parent_name, void __iomem *reg)
+{
+   struct mtk_ref2usb_tx *tx;
+   struct clk_init_data init = {};
+   struct clk *clk;
+
+   tx = kzalloc(sizeof(*tx), GFP_KERNEL);
+   if (!tx)
+   return ERR_PTR(-ENOMEM);
+
+   tx->base_addr = reg;
+   tx->hw.init = &init;
+
+   init.name = name;
+   init.ops = &mtk_ref2usb_tx_ops;
+   init.parent_names = &parent_name;
+   init.num_parents = 1;
+
+   clk = clk_register(NULL, &tx->hw);
+
+   if (IS_ERR(clk)) {
+   pr_err("Failed to register clk %s: %ld\n", name, PTR_ERR(clk));
+   kfree(tx);
+   }
+
+   return clk;
+}
diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 4506083..c0665b7 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -969,6 +969,24 @@ static void __init mtk_pericfg_init(struct device_node 
*node)
 }
 CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg", mtk_pericfg_init);
 
+struct mtk_clk_usb {
+   int id;
+   const char *name;
+   const char *parent;
+   u32 reg_ofs;
+};
+
+#define APMIXED_USB(_id, _name, _parent, _reg_ofs) {   \
+   .id = _id,  \
+   .name = _name,  \
+   .parent = _parent,  \
+   .reg_ofs = _reg_ofs,\
+   }
+
+static const struct mtk_clk_usb apmixed_usb[] __initconst = {
+   AP

[PATCH v5 00/10] Fixes and new clocks support for Mediatek MT8173

[James Liao]

This patchset is based on 4.2-rc1 and [1], and contains minor fixes and
subsystem clocks support for Mediatek MT8173.

The previous reviews can be found in [2]. The most different from previous
patchset are adding separated patches for minor coding fixes, and refining
USB clock implementation by removing mtk_clk_register_apmixed_ex().

changes since v4:
- Add a separated patch to remove unused dpi_ck.
- Add separated patches to fix clk/mediatek in release 4.2-rc1.
- Add __init* for initialization data and functions.
- Rename dummy_clk with oscillator in DT.
- Remove mtk_clk_register_apmixed_ex(), call mtk_clk_register_ref2usb_tx()
  directly to register USB clock.

changes since v3:
- Remove clk_null dependency from root clocks.
- Use fixed-rate clocks with typical rate to replace clk_null.
- Separate ref2usb_tx implementation to clk-apmixed.c
- Use clock-controller as the name of clock providers.

changes since v2:
- Rebase to 4.2-rc1.
- Add device tree nodes for subsystem clocks.
- Fine tune comments of patches.
- Add __init, __initconst and const to init data and functions.
- Removed unused code from init functions of subsystem clocks.

changes since v1:
- Add CA7PLL and CA15PLL as critical clocks.
- Use the same register descriptor for imgsys, vensys and vencltsys.
- Generalize apmixedsys special clocks registration.

[1] https://patchwork.kernel.org/patch/6446341/
[2] https://lkml.org/lkml/2015/7/23/911

James Liao (9):
  clk: mediatek: Removed unused dpi_ck clock from MT8173
  clk: mediatek: Remove unused code from MT8173.
  clk: mediatek: Add __initdata and __init for data and functions
  clk: mediatek: Add fixed clocks support for Mediatek SoC.
  clk: mediatek: Fix rate and dependency of MT8173 clocks
  dt-bindings: ARM: Mediatek: Document devicetree bindings for clock
controllers
  clk: mediatek: Add subsystem clocks of MT8173
  clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
  arm64: dts: mt8173: Add subsystem clock controller device nodes

Sascha Hauer (1):
  clk: mediatek: mt8173: Fix enabling of critical clocks

 .../bindings/arm/mediatek/mediatek,imgsys.txt  |  22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |  22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   |  22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt |  22 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  37 +++
 drivers/clk/mediatek/Makefile  |   2 +-
 drivers/clk/mediatek/clk-apmixed.c | 107 ++
 drivers/clk/mediatek/clk-gate.c|   2 +-
 drivers/clk/mediatek/clk-mt8173.c  | 361 -
 drivers/clk/mediatek/clk-mtk.c |  36 +-
 drivers/clk/mediatek/clk-mtk.h |  24 +-
 drivers/clk/mediatek/clk-pll.c |   7 +-
 include/dt-bindings/clock/mt8173-clk.h | 101 +-
 14 files changed, 749 insertions(+), 38 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Vignesh R]

On 07/23/2015 09:05 PM, R, Vignesh wrote:
> 
> 
> On 7/16/2015 9:01 PM, R, Vignesh wrote:
>> Hi,
>>
>> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>>> Hi,
>>>
>>> some comments.
>>>
>>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>>
 Add hwmod entries for the PWMSS on DRA7.

 Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
 equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
 As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
 clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
 L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
>>>
>>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
>>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
>>
>> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
>> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
>> the clock input for PWMSS. This will be updated in TRM soon.
>>
>>>
 [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf

 Signed-off-by: Vignesh R 
 ---

 v2:
  * add TRM references.

  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 
 ++
  1 file changed, 239 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 index 0e64c2fac0b5..86a7ac9a3138 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
},
  };
  
 +/* pwmss  */
 +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
 +  .rev_offs   = 0x0,
 +  .sysc_offs  = 0x4,
 +  .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
>>>
>>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
>>> RESETSTATUS bit.  There is a SOFTRESET bit. 
>>>
>>> Could you please confirm whether this is intentional?
>>
>> sorry my bad... I will change this in v3.
>>
>>>
 +  .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 +  .sysc_fields= &omap_hwmod_sysc_type2,
 +};
 +
 +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
 +  .name   = "epwmss",
 +  .sysc   = &dra7xx_epwmss_sysc,
 +};
 +
 +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
 +  .name   = "ecap",
 +};
 +
 +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
 +  .name   = "eqep",
 +};
 +
 +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
 +  .name   = "ehrpwm",
 +};
 +
 +/* epwmss0 */
 +struct omap_hwmod dra7xx_epwmss0_hwmod = {
 +  .name   = "epwmss0",
 +  .class  = &dra7xx_epwmss_hwmod_class,
 +  .clkdm_name = "l4per2_clkdm",
 +  .main_clk   = "l4_root_clk_div",
 +  .prcm   = {
 +  .omap4  = {
 +  .modulemode = MODULEMODE_SWCTRL,
 +  .clkctrl_offs   = 
 DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
 +  .context_offs   = 
 DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
 +  },
 +  },
>>>
>>> Per my comment on the previous patch, sounds like it might be better to 
>>> mark this as HWMOD_SWSUP_SIDLE?  Then again, see the next comment below 
>>> re: main_clk.
>>>
 +};
 +
 +/* ecap0 */
 +struct omap_hwmod dra7xx_ecap0_hwmod = {
 +  .name   = "ecap0",
 +  .class  = &dra7xx_ecap_hwmod_class,
 +  .clkdm_name = "l4per2_clkdm",
 +  .main_clk   = "l4_root_clk_div",
>>>
>>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
>>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
>>> clock gating and reports back on the status of what I'd guess is the local 
>>> clock gating FSM.
>>>
>>> So from that point of view, you should probably create a clock driver that 
>>> manages both the clock gate request bit and the FSM status bit.  It should 
>>> be something that can be reused for the other PWMSS IP blocks.  Then 
>>> you'd create per-IP block clock nodes and set the main_clk to point to 
>>> that node.
>>>
>>
>> Since, this register is within the config space of PWMSS, the individual
>> gating and reporting for the modules within PWMSS
>> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
>> the sole function this driver is doing). It has been the same since
>> am335x. Adding new clock nodes will result in driver changes and also
>> changes to am335x, am437x (and other platforms) hwmod files. It also
>> involves adding new nodes to clocks.dtsi and it will be difficult to
>> maintain backward compatibility for older platforms. Is it not better to
>> keep this as is, in order to maintain consistency (with am335x, am437x
>> etc) and also that thes

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-07-27 at 14:23 +0100, Robin Murphy wrote:
> On 16/07/15 10:04, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> >
> > Signed-off-by: Yong Wu 
> [...]
> > +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> > +{
> > +   struct mtk_iommu_domain *domain = cookie;
> > +   unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
> > +
> > +   dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
> > +size, DMA_TO_DEVICE);
> 
> Nit: this looks like it may as well be dma_map_single.
> 
> It would probably be worth following it with a matching unmap too, just 
> to avoid any possible leakage bugs (especially if this M4U ever appears 
> in a SoC supporting RAM above the 32-bit boundary).

About the map, I will read and try to follow your patch:
iommu/io-pgtable-arm: Allow appropriate DMA API use.

> 
>  > +}
>  > +
> [...]
> > +static int mtk_iommu_parse_dt(struct platform_device *pdev,
> > + struct mtk_iommu_data *data)
> > +{
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *ofnode;
> > +   struct resource *res;
> > +   int i;
> > +
> > +   ofnode = dev->of_node;
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   data->base = devm_ioremap_resource(&pdev->dev, res);
> > +   if (IS_ERR(data->base))
> > +   return PTR_ERR(data->base);
> > +
> > +   data->irq = platform_get_irq(pdev, 0);
> > +   if (data->irq < 0)
> > +   return data->irq;
> > +
> > +   data->bclk = devm_clk_get(dev, "bclk");
> > +   if (IS_ERR(data->bclk))
> > +   return PTR_ERR(data->bclk);
> > +
> > +   data->larb_nr = of_count_phandle_with_args(
> > +   ofnode, "mediatek,larb", NULL);
> > +   if (data->larb_nr < 0)
> > +   return data->larb_nr;
> > +
> > +   for (i = 0; i < data->larb_nr; i++) {
> > +   struct device_node *larbnode;
> > +   struct platform_device *plarbdev;
> > +
> > +   larbnode = of_parse_phandle(ofnode, "mediatek,larb", i);
> > +   if (!larbnode)
> > +   return -EINVAL;
> > +
> > +   plarbdev = of_find_device_by_node(larbnode);
> > +   of_node_put(larbnode);
> > +   if (!plarbdev)
> > +   return -EPROBE_DEFER;
> > +   data->larbdev[i] = &plarbdev->dev;
> > +   }
> 
> At a glance this seems like a job for of_parse_phandle_with_args, but I 
> may be missing something subtle.

It seems We can not use of_parse_phandle_with_args here.

The node of larb is.
//=
larb0: larb@14021000 {
compatible = "mediatek,mt8173-smi-larb";
reg = <0 0x14021000 0 0x1000>;
mediatek,smi = <&smi_common>;   
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_SMI_LARB0>,
 <&mmsys CLK_MM_SMI_LARB0>;
clock-names = "apb", "smi";
};
//==
  of_parse_phandle_with_args(ofnode,"mediatek,larb", "mediatek,smi",
&larb) will be wrong due to there is no item like "mediatek,smi = <1>;"
in larb.

And this code seems to be not simple if we use
of_parse_phandle_with_args. Both need a loop.

so I don't change it here, ok?
> 
> > +   return 0;
> > +}
> > +
> [...]
> > +static int mtk_iommu_init_domain_context(struct mtk_iommu_domain *dom)
> > +{
> > +   int ret;
> > +
> > +   if (dom->iop)
> > +   return 0;
> > +
> > +   spin_lock_init(&dom->pgtlock);
> > +   dom->cfg.quirks = IO_PGTABLE_QUIRK_ARM_NS |
> > +   IO_PGTABLE_QUIRK_SHORT_SUPERSECTION |
> > +   IO_PGTABLE_QUIRK_SHORT_MTK;
> > +   dom->cfg.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
> > +   dom->cfg.ias = 32;
> > +   dom->cfg.oas = 32;
> > +   dom->cfg.tlb = &mtk_iommu_gather_ops;
> > +
> > +   dom->iop = alloc_io_pgtable_ops(ARM_SHORT_DESC, &dom->cfg, dom);
> > +   if (!dom->iop) {
> > +   pr_err("Failed to alloc io pgtable\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Update our support page sizes bitmap */
> > +   mtk_iommu_ops.pgsize_bitmap = dom->cfg.pgsize_bitmap;
> > +
> > +   ret = mtk_iommu_hw_init(dom);
> > +   if (ret)
> > +   free_io_pgtable_ops(dom->iop);
> > +
> > +   return ret;
> > +}
> 
> I don't see that you need the above function at all - since your 
> pagetable config is fixed and doesn't have any depency on which IOMMU 
> you're attaching to, can't you just do all of that straight away in 
> domain_alloc?

Yes. We could move it into domain_alloc.

> 
> > +static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
> > +{
> > +   struct mtk_iommu_domain *priv;
> > +
> > +   /* We only support unmanaged domains for now */
> > +   if (typ

Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Moritz Fischer]

Hi Sören,

On Tue, Jul 28, 2015 at 3:53 PM, Sören Brinkmann
 wrote:
> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote:
>> Hi Sören,
>>
>> thanks for your feedback.
>>
>> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
>>  wrote:
>> > Hi Moritz,
>> >
>> > On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
>> >> Signed-off-by: Moritz Fischer 
>> >> ---
>> >>  Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 
>> >> +
>> >>  1 file changed, 13 insertions(+)
>> >>  create mode 100644 
>> >> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt 
>> >> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >> new file mode 100644
>> >> index 000..ac4499e
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
>> >> @@ -0,0 +1,13 @@
>> >> +Xilinx Zynq PL Reset Manager
>> >> +
>> >> +Required properties:
>> >> +- compatible: "xlnx,zynq-reset-pl"
>> >> +- syscon <&slcr>;
>> >> +- #reset-cells: 1
>> >> +
>> >> +Example:
>> >> + rstc: rstc@240 {
>> >> + #reset-cells = <1>;
>> >> + compatible = "xlnx,zynq-reset-pl";
>> >> + syscon = <&slcr>;
>> >> + };
>> >
>> > I think you also have to add the outputs and make them part of the
>> > binding. Otherwise you'd have to read the implementation to find
>> > out what device should be hooked up to which output of the 
>> > reset-controller.
>>
>> Is something like this what you had in mind? I had that prepared for
>> the next round of patches:
>>
>> Reset outputs:
>>  0  : soft reset
>>  32 : ddr reset
>>  64 : topsw reset
>>  96 : dmac reset
>>  128: usb0 reset
>>  129: usb1 reset
>>  160: gem0 reset
>>  161: gem1 reset
>>  164: gem0 rx reset
>>  165: gem1 rx reset
>>  166: gem0 ref reset
>>  167: gem1 ref reset
>>  192: sdio0 reset
>>  193: sdio1 reset
>>  196: sdio0 ref reset
>>  197: sdio1 ref reset
>>  224: spi0 reset
>>  225: spi1 reset
>>  226: spi0 ref reset
>>  227: spi1 ref reset
>>  256: can0 reset
>>  257: can1 reset
>>  258: can0 ref reset
>>  259: can1 ref reset
>>  288: i2c0 reset
>>  289: i2c1 reset
>>  320: uart0 reset
>>  321: uart1 reset
>>  322: uart0 ref reset
>>  323: uart1 ref reset
>>  352: gpio reset
>>  384: lqspi reset
>>  385: qspi ref reset
>>  416: smc reset
>>  417: smc ref reset
>>  448: ocm reset
>>  512: fpga0 out reset
>>  513: fpga1 out reset
>>  514: fpga2 out reset
>>  515: fpga3 out reset
>>  544: a9 reset 0
>>  545: a9 reset 1
>>  552: peri reset
>
> Basically, yes. I guess the gaps are due to directly mapping this number
> to bank and bit instead of doing some more complex mapping in between?
> I'm not sure whether I like this :) I guess if a number is off the
> driver would still toggle the addressed bit?

My assumption was that people would use a #include
 in their dts. Assuming I got the
numbers in there right this makes it hard to misuse by accident.
I'm not saying it's perfect ...

> I'm not sure, is it worth
> to do some explicit mapping from logical outputs to a physical reset? It
> seems it would be a little safer since it would be easy to check that
> the addressed reset is valid and there wouldn't be any reserved/invalid
> bits be toggled. Also, it would make the outputs in here a continuous
> series of numbers without these gaps. Not sure though whether
> it's worth the additional complexity in the implementation.

So your suggestion is to have a large switch case kind of thingy? I
thought about it and it seemed complex as there's quite a bunch of
resets with gaps. Do you know of a driver that does something similar?
When I wrote this I looked at the other reset drivers and figured they
all had this kind of bank mapping of sorts so I assumed that's how
people usually do it.

>
> Thanks,
> Sören

Thanks again for your input,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/22] of/platform: add of_platform_device_find()

[Tomeu Vizoso]

On 28 July 2015 at 17:31, Rob Herring  wrote:
> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
>  wrote:
>> On 28 July 2015 at 15:39, Rob Herring  wrote:
>>> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
>>>  wrote:
 From an arbitrary node in the tree, find the enclosing node that
 corresponds to a platform device, as registered by
 of_platform_populate().

 This can be used to find out what device needs to be probed so the
 dependency described by a given node is made available.

 Signed-off-by: Tomeu Vizoso 
 ---

 Changes in v2:
 - Move the logic for finding a platform device from its firmware node to
   of/platform.c as it's not needed for ACPI nodes.

  drivers/of/platform.c   | 60 
 +
  include/linux/of_platform.h |  1 +
  2 files changed, 61 insertions(+)

 diff --git a/drivers/of/platform.c b/drivers/of/platform.c
 index ff27494cda8c..89c5cd513027 100644
 --- a/drivers/of/platform.c
 +++ b/drivers/of/platform.c
 @@ -501,6 +501,66 @@ void of_platform_depopulate(struct device *parent)
  }
  EXPORT_SYMBOL_GPL(of_platform_depopulate);

 +static bool of_is_platform(struct device_node *np)
 +{
 +   int count;
 +
 +   count = of_property_count_strings(np, "compatible");
 +
 +   /* The node has to have a compatible string */
 +   if (!count)
 +   return false;
 +
 +   /* But it cannot be just a simple memory-mapped bus */
 +   if (count == 1 && of_match_node(of_default_bus_match_table, np))
 +   return false;
 +
 +   /* But AMBA devices aren't platform devices */
 +   if (of_device_is_compatible(np, "arm,primecell"))
 +   return false;
 +
 +   /* Node is immediately below root */
 +   if (!np->parent || !np->parent->parent)
 +   return true;
 +
 +   /* If it's a node in a simple memory-mapped bus */
 +   if (of_match_node(of_default_bus_match_table, np->parent))
 +   return true;
>>>
>>> This seems really fragile.
>>
>> I think this finding logic matches the logic for registering platform
>> devices in of_platform_populate and also what is documented in
>> Documentation/devicetree/usage-model.txt.
>
> Right. So now we have that logic in 2 places. One is descending from
> the root and one is walking up from the child. That's an opportunity
> for some mismatch.

Definitely.

>>> What about platform devices which are
>>> children of MFDs but are not "simple-mfd"?
>>
>> This code should deal fine with those (the boards I tested with do
>> have them). It probes the mfd master, and that in turn will call
>> mfd_add_devices causing the target device to be probed.
>
> I don't see how this function would ever return true in this case
> unless you put the MFD at the root level. The only other way to return
> true is matching on of_default_bus_match_table for the parent (i.e.
> the MFD).

Oops, you are right.

>>> Does of_find_device_by_node not work for you?
>>
>> Well, the dependencies aren't always platform devices, that's why I
>> need to go up the tree until I find a node that corresponds to a
>> platform device that I can query and probe.
>>
>> If I had a way to get, say, a i2c device from its fwnode then I would
>> just need to make sure that a device's parent is probed before probing
>> it and everything would be cleaner in the OF case.
>
> If you have the struct device from the device_node, then you should be
> able to do this, right?

Yes, if I could go back from the device_node to the struct device that
was registered from it, for all buses, then all this would be much
simpler and more robust. It would basically work like in the ACPI
case.

I will play with this idea.

>>> That is probably not the
>>> most efficient search, but we could fix that. We could add struct
>>> device ptr to struct device_node and check without searching for
>>> example.
>>
>> That would be great, but I thought there was an issue with a OF node
>> being able to be related to more than one struct device (but I haven't
>> found this myself yet).
>
> I think it pretty much should be one to one. I'm not aware of any
> examples where that is not the case. This function would already be
> broken if you could have more than one struct device.

Well, for platform devices we currently know that there can only be
one struct device for a given device_node, but that's not so clear for
other devices.

> There is an issue where you could have 2 drivers match the same node,
> but on different compatible strings. But that's a different issue.

Yup.

Thanks,

Tomeu

> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the F

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Sascha Hauer]

On Wed, Jul 29, 2015 at 07:51:55AM +0200, Sascha Hauer wrote:
> Hi Peter,
> 
> On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> > The system bus and chipidea IP have different limitations for
> > both host and device mode.
> > For example, with below errata, we need to enable SDIS(Stream Disable Mode)
> > at host mode. But we don't want it for device mode at the same system.
> > 
> > TAR 9000378958
> > Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang 
> > on OUT Retry
> > Impacted Configuration: Host mode, all transfer types
> > Description:
> > The host core operating in streaming mode may under run while sending the 
> > data packet of an OUT transaction. This under run can occur if there are 
> > unexpected system delays in fetching the remaining packet data from memory. 
> > The host forces a bad CRC on the packet, the device detects the error and 
> > discards the packet. The host then retries a Bulk, Interrupt, or Control 
> > transfer if an under run occurs according to the USB specification.
> 
> Please add linebreaks at 75 characters or so.

Oh sorry, this already had been addressed. Should have read further.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Sascha Hauer]

Hi Peter,

On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> The system bus and chipidea IP have different limitations for
> both host and device mode.
> For example, with below errata, we need to enable SDIS(Stream Disable Mode)
> at host mode. But we don't want it for device mode at the same system.
> 
> TAR 9000378958
> Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang 
> on OUT Retry
> Impacted Configuration: Host mode, all transfer types
> Description:
> The host core operating in streaming mode may under run while sending the 
> data packet of an OUT transaction. This under run can occur if there are 
> unexpected system delays in fetching the remaining packet data from memory. 
> The host forces a bad CRC on the packet, the device detects the error and 
> discards the packet. The host then retries a Bulk, Interrupt, or Control 
> transfer if an under run occurs according to the USB specification.

Please add linebreaks at 75 characters or so.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Peter Chen]

On Tue, Jul 28, 2015 at 10:10:16PM -0700, Greg KH wrote:
> On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> > @@ -20,7 +20,6 @@ struct ci_hdrc_platform_data {
> > unsigned longflags;
> >  #define CI_HDRC_REGS_SHAREDBIT(0)
> >  #define CI_HDRC_SUPPORTS_RUNTIME_PMBIT(2)
> > -#define CI_HDRC_DISABLE_STREAMING  BIT(3)
> 
> Why not just rename this one, now you have a "hole" in your bit field
> that people aren't going to know if they can use or not.
> 

I will change it, thanks.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Peter Chen]

On Tue, Jul 28, 2015 at 10:08:28PM -0700, Greg KH wrote:
> On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> > The system bus and chipidea IP have different limitations for
> > both host and device mode.
> > For example, with below errata, we need to enable SDIS(Stream Disable Mode)
> > at host mode. But we don't want it for device mode at the same system.
> > 
> > TAR 9000378958
> > Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang 
> > on OUT Retry
> > Impacted Configuration: Host mode, all transfer types
> > Description:
> > The host core operating in streaming mode may under run while sending the 
> > data packet of an OUT transaction. This under run can occur if there are 
> > unexpected system delays in fetching the remaining packet data from memory. 
> > The host forces a bad CRC on the packet, the device detects the error and 
> > discards the packet. The host then retries a Bulk, Interrupt, or Control 
> > transfer if an under run occurs according to the USB specification.
> 
> 
> 
> Properly format this huge wall of text please, don't commit this as-is.
> 

Thanks, I will

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-07-27 at 16:49 +0100, Robin Murphy wrote:
> On 27/07/15 16:31, Russell King - ARM Linux wrote:
> > On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote:
> >> On 16/07/15 10:04, Yong Wu wrote:
> >>> This patch adds support for mediatek m4u (MultiMedia Memory Management
> >>> Unit).
> >>>
> >>> Signed-off-by: Yong Wu 
> >> [...]
> >>> +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> >>> +{
> >>> +   struct mtk_iommu_domain *domain = cookie;
> >>> +   unsigned long offset = (unsigned long)ptr & ~PAGE_MASK;
> >>> +
> >>> +   dma_map_page(domain->data->dev, virt_to_page(ptr), offset,
> >>> +size, DMA_TO_DEVICE);
> >>
> >> Nit: this looks like it may as well be dma_map_single.
> >>
> >> It would probably be worth following it with a matching unmap too, just to
> >> avoid any possible leakage bugs (especially if this M4U ever appears in a
> >> SoC supporting RAM above the 32-bit boundary).
> >
> > Why not do the job properly?  Take a look at how I implemented the
> > streaming DMA API on Tegra SMMU (patch set recently sent out earlier
> > today).
> >
> > There's no need for hacks like dma_map_page() (and discarding it's
> > return value) or dma_map_page() followed by dma_unmap_page().
> 
> Indeed, as it happens I do have a branch where I prototyped that for the 
> long-descriptor io-pgtable-arm code a while ago; this discussion has 
> prompted me to dig it up again. Stay tuned, folks...

Hi Russell, Robin,

 From I see in arm-smmu-v3.c in v4.2-rc1, 
 
 The flush_pgtable seems like this:
//==
dma_addr_t dma_addr;

dma_addr = dma_map_page(dev, ptr, size, DMA_TO_DEVICE);

if (dma_mapping_error(dev, dma_addr))
dev_err(dev, "failed to flush pgtable at %p\n", ptr);
else
dma_unmap_page(dev, dma_addr, size, DMA_TO_DEVICE);
//==
   I will change map like this and use dma_map_single instead.

   Is this also seems to be not proper?

   Then how to do it?  add this before unmap? :
   dma_sync_single_for_device(dev, dma_addr, size, DMA_TO_DEVICE);

> 
> Robin.
> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Archit Taneja]

Hi Srini,

On 07/28/2015 06:24 PM, Srinivas Kandagatla wrote:

This patch adds LVDS panel for IFC6410.

Signed-off-by: Rob Clark 
[Rob Clark: WIP patch]
Signed-off-by: Srinivas Kandagatla 
---
  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 ++
  1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 1ab71f1..3bdac02 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -63,6 +63,12 @@
qcom,switch-mode-frequency = <320>;
};

+   pm8921_l2: l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   bias-pull-down;
+   };
+
pm8921_l3: l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
@@ -96,6 +102,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs7: lvs7 {
+   bias-pull-down;
+   };
};
};

@@ -119,6 +129,41 @@

mdp: qcom,mdp@510 {
status = "okay";
+   qcom,lvds-panel = <&panel>;


We're trying to switch to the of_graph way of representing connected
panels. With that, the above phandle will go away. This needs to be 
replaced with:


port {
lvds_out: endpoint {
remote_endpoint = <&auo_in>;
};
};


+   lvds-vccs-3p3v-supply = <&ext_3p3v>;
+   lvds-pll-vdda-supply = <&pm8921_l2>;
+   lvds-vdda-supply = <&pm8921_lvs7>;
+   };
+
+   panel_3p3v: panel_3p3v {
+   compatible = "regulator-fixed";
+   pinctrl-0 = <&disp_en_gpios>;
+   pinctrl-names = "default";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "panel_en_3p3v";
+   regulator-type = "voltage";
+   startup-delay-us = <0>;
+   gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   backlight: backlight{
+   pinctrl-0 = <&pwm_bl_gpios>;
+   pinctrl-names = "default";
+   compatible = "gpio-backlight";
+   gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+   default-on;
+   };
+
+   panel: auo,b101xtn01 {
+   status = "okay";
+   compatible = "auo,b101xtn01";
+
+   ddc-i2c-bus = <&i2c3>;
+   backlight = <&backlight>;
+   power-supply = <&panel_3p3v>;


and for the panel:

port {
auo_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};

Thanks,
Archit


};

gsbi3: gsbi@1620 {
@@ -235,6 +280,27 @@
pm8921_gpio: gpio@150 {
pinctrl-names = "default";
pinctrl-0 = <&wlan_default_gpios>;
+
+   pwm_bl_gpios: pwm-bl-gpios {
+   pios {
+   pins = "gpio26";
+   bias-disable;
+   function = "normal";
+   qcom,drive-strength = 
;
+   power-source = 
;
+   };
+   };
+
+   disp_en_gpios: disp-en-gpios {
+   pios {
+   pins = "gpio36";
+   bias-disable;
+   function = "normal"

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Greg KH]

On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> @@ -20,7 +20,6 @@ struct ci_hdrc_platform_data {
>   unsigned longflags;
>  #define CI_HDRC_REGS_SHARED  BIT(0)
>  #define CI_HDRC_SUPPORTS_RUNTIME_PM  BIT(2)
> -#define CI_HDRC_DISABLE_STREAMINGBIT(3)

Why not just rename this one, now you have a "hole" in your bit field
that people aren't going to know if they can use or not.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Greg KH]

On Wed, Jul 29, 2015 at 10:42:06AM +0800, Peter Chen wrote:
> The system bus and chipidea IP have different limitations for
> both host and device mode.
> For example, with below errata, we need to enable SDIS(Stream Disable Mode)
> at host mode. But we don't want it for device mode at the same system.
> 
> TAR 9000378958
> Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang 
> on OUT Retry
> Impacted Configuration: Host mode, all transfer types
> Description:
> The host core operating in streaming mode may under run while sending the 
> data packet of an OUT transaction. This under run can occur if there are 
> unexpected system delays in fetching the remaining packet data from memory. 
> The host forces a bad CRC on the packet, the device detects the error and 
> discards the packet. The host then retries a Bulk, Interrupt, or Control 
> transfer if an under run occurs according to the USB specification.



Properly format this huge wall of text please, don't commit this as-is.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/7] DT: APQ8064 for qcom-dt-next

[Andy Gross]

On Tue, Jul 28, 2015 at 01:52:36PM +0100, Srinivas Kandagatla wrote:
> Hi Andy, 
> 
> As discussed here are some dt patches which depend on
> pmic header "dt-bindings/pinctrl/qcom,pmic-gpio.h" which is availble in
> linux-next.

Ok.  I took all of these and put them on top of my 4.3 tags on the
qcom/for-next.  I compiled against the current next master and all was well.




-- 
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: introduce of_has_named_irqs helper

[Vignesh R]

On 07/28/2015 11:37 PM, Dmitry Torokhov wrote:
> On Tue, Jul 28, 2015 at 11:16:44PM +0530, R, Vignesh wrote:
>> Hi,
>>
>> On 7/28/2015 10:53 PM, Dmitry Torokhov wrote:
>>> On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
 Hi Dmitry,

 On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
> On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
>> On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
>>> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
>>>  wrote:
 Sometimes drivers might wish to transition from index-based to named
 interrupt descriptions. To aid in decision-making when parsing device
 tree data let's provide a helper that will indicate the scheme that is
 being used.
>>>
>>> Generally, IRQs are retrieved by platform_get_irq or
>>> platform_get_irq_byname. Drivers should not call the of_irq_*
>>> functions directly in most cases.
>>
>> That would be true for platform drivers, but not all devices are
>> platform devices.
>>
>>>

 Signed-off-by: Dmitry Torokhov 
 ---

 The intent is to it like this:

 if (of_has_named_irqs(np) {
 /* Wake IRQ is optional */
 dev->wakeirq = of_irq_get_byname(np, "wakeup");
 if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
 return dev->wakeirq;
 }
>>>
>>> of_irq_get_byname will already return an error if the property is not
>>> present. Use that.
>>
>> I do not like that it returns -EINVAL when property is missing, can we
>> change it to return -ENODATA (so it is the same as when the property is
>> defined but such name is missing)?
>
> So here is what I had in mind.. It is based on recent patch by Vignesh
> for pixcir touchscreen, but I think it should be made available to all
> I2C devices. Completely untested at the moment.
>

 Thanks for the patch! I tested this on am437x-gp-evm and the
 suspend/resume worked fine (below patch + $subject patch). I was able to
 wake the system from low power state using touchscreen. Also verified
 module insertion and removal. One comment though, please see below.

> ---
>  drivers/i2c/i2c-core.c |   43 +--
>  1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index e6d4935..3971461 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
>  {
>   struct i2c_client   *client = i2c_verify_client(dev);
>   struct i2c_driver   *driver;
> + int wakeirq = 0;
>   int status;
>  
>   if (!client)
> @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
>   if (!client->irq) {
>   int irq = -ENOENT;
>  
> - if (dev->of_node)
> - irq = of_irq_get(dev->of_node, 0);
> - else if (ACPI_COMPANION(dev))
> + if (dev->of_node) {
> + irq = of_has_named_irqs(dev->of_node) ?
> + of_irq_get_byname(dev->of_node, "irq") :
> + of_irq_get(dev->of_node, 0);
> + } else if (ACPI_COMPANION(dev)) {
>   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> -
> + }
>   if (irq == -EPROBE_DEFER)
>   return irq;
>   if (irq < 0)
> @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
>   client->irq = irq;
>   }
>  
> + if (dev->of_node && of_has_named_irqs(dev->of_node)) {
> + wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> + if (wakeirq < 0) {
> + if (wakeirq != -ENODATA)
> + return wakeirq;
> + wakeirq = 0;
> + }
> + }
> +
>   driver = to_i2c_driver(dev->driver);
>   if (!driver->probe || !driver->id_table)
>   return -ENODEV;diff --git 
> a/drivers/input/touchscreen/pixcir_i2c_ts.c 
> b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index 8f3e243a62bf..6bd1d1ca9883 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -365,7 +365,6 @@ static int __maybe_unused
>> pixcir_i2c_ts_suspend(struct device *dev)
>> }
>> }
>>
>> -   enable_irq_wake(client->irq);
>> } else if (input->users) {
>> ret = pixcir_stop(ts);
>>

Re: [PATCH v4 0/2] iio: light: add support for APDS9660 sensor

[Matt Ranostay]

Jonathan,

Does this solve the issues in v3 minus the apds9960_regfield_init() cleanup?


Thanks,

Matt

On Sun, Jul 19, 2015 at 8:57 PM, Matt Ranostay  wrote:
> This patchset adds support for the APDS9960 ALS + proximity + gesture
> sensor.
>
> Included support for the various adjustable settings and controls:
>  * Falling and rising ALS + proximity thresholds events
>  * Gain controls
>  * ALS time integration
>
> Changes from v3:
>  * Added interrupt client mode document reference in DT bindings
>  * Add missing dep for CONFIG_REGMAP_I2C in respective Kconfig
>  * Changed from iio_trigger_poll_chained() to irq_work queue
>  * Changed channel masks to prevent channels that can't be polled from
>having sysfs entries
>  * Renamed regmap_field declarations with apds9660_* prefix
>  * Added available channel masks and removed unneeded buffer copy in
>poll function
>  * Remove unneeded default regmap values in apds9960_reg_defaults
>  * Clear interrupts from ALS and proximity sensor seperately to avoid
>race condition
>  * Changed max threshold values to a macro define, and prevent values
>less than 0
>  * Avoid needlessly checking the APDS9960_REG_GFLVL value until we read
>all the FIFO from the count value. Note this can save up to 32
>superfluous i2c reads per gesture engine entry
>
> Matt Ranostay (2):
>   iio: light: DT binding docs for APDS9960 driver
>   iio: light: add APDS9960 ALS + promixity driver
>
>  .../ABI/testing/sysfs-bus-iio-light-apds9960   |7 +
>  .../devicetree/bindings/iio/light/apds9960.txt |   22 +
>  drivers/iio/light/Kconfig  |   13 +
>  drivers/iio/light/Makefile |1 +
>  drivers/iio/light/apds9960.c   | 1191 
> 
>  5 files changed, 1234 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
>  create mode 100644 Documentation/devicetree/bindings/iio/light/apds9960.txt
>  create mode 100644 drivers/iio/light/apds9960.c
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/10] usb: chipidea: add tx/rx burst size configuration interface

[Peter Chen]

The user can adjust it through dts or platform data

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/bits.h  |  4 
 drivers/usb/chipidea/ci.h|  1 +
 drivers/usb/chipidea/core.c  | 35 +++
 include/linux/usb/chipidea.h |  4 
 4 files changed, 44 insertions(+)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 462ad02..e462f55 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -61,6 +61,10 @@
 /* Set non-zero value for internal TT Hub address representation */
 #define TTCTRL_TTHA(0x7fUL << 24)
 
+/* BURSTSIZE */
+#define RX_BURST_MASK  0xff
+#define TX_BURST_MASK  0xff00
+
 /* PORTSC */
 #define PORTSC_CCSBIT(0)
 #define PORTSC_CSCBIT(1)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index b562544..41d7cf6 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -51,6 +51,7 @@ enum ci_hw_regs {
OP_DEVICEADDR,
OP_ENDPTLISTADDR,
OP_TTCTRL,
+   OP_BURSTSIZE,
OP_PORTSC,
OP_DEVLC,
OP_OTGSC,
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f60cbf6..0375412 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
+   [OP_BURSTSIZE]  = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0x64U,
@@ -109,6 +110,7 @@ static const u8 ci_regs_lpm[] = {
[OP_DEVICEADDR] = 0x14U,
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
+   [OP_BURSTSIZE]  = 0x20U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0xC4U,
@@ -442,6 +444,17 @@ void ci_platform_configure(struct ci_hdrc *ci)
if (ci->platdata->flags & CI_HDRC_OVERRIDE_AHB_BURST)
hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
ci->platdata->ahb_burst_config);
+
+   /* override burst size, take effect only when ahb_burst_config is 0 */
+   if (!hw_read_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK)) {
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_TX_BURST)
+   hw_write(ci, OP_BURSTSIZE, TX_BURST_MASK,
+   ci->platdata->tx_burst_size << __ffs(TX_BURST_MASK));
+
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_RX_BURST)
+   hw_write(ci, OP_BURSTSIZE, RX_BURST_MASK,
+   ci->platdata->rx_burst_size);
+   }
 }
 
 /**
@@ -661,6 +674,28 @@ static int ci_get_platdata(struct device *dev,
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
}
 
+   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   &platdata->tx_burst_size);
+   if (ret) {
+   dev_err(dev,
+   "failed to get tx-burst-size-dword\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   }
+
+   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   &platdata->rx_burst_size);
+   if (ret) {
+   dev_err(dev,
+   "failed to get rx-burst-size-dword\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   }
+
return 0;
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 9848a4e..524ef3d 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -34,6 +34,8 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_DISABLE_STREAMING (CI_HDRC_DISABLE_DEVICE_STREAMING |  \
CI_HDRC_DISABLE_HOST_STREAMING)
 #define CI_HDRC_OVERRIDE_AHB_BURST BIT(11)
+#define CI_HDRC_OVERRIDE_TX_BURST  BIT(12)
+#define CI_HDRC_OVERRIDE_RX_BURST  BIT(13)
enum usb_dr_modedr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT 0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
@@ -44,6 +46,8 @@ struct ci_hdrc_platform_data {
/* interrupt threshold setting */
u32 itc_setting;
u32 ahb_burst_config;
+   u32 tx_burst_size;
+   u32 rx_burst_size;
 };
 
 /* Default offset of capability registers */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the bo

[PATCH 03/10] usb: chipidea: imx: add stream mode enable for device mode at imx6sl/imx6sx

[Peter Chen]

Stream mode enable is known for better performance, this stream mode
enable patch has been passed with stress tests at device mode for
imx6sl and imx6sx, and no issue is found.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 6d2a85a..3f41679 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -29,26 +29,31 @@ struct ci_hdrc_imx_platform_flag {
 };
 
 static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
.flags = CI_HDRC_IMX28_WRITE_FIX |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6q_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6sl_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_HOST_STREAMING,
 };
 
 static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = {
.flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
-   CI_HDRC_TURN_VBUS_EARLY_ON,
+   CI_HDRC_TURN_VBUS_EARLY_ON |
+   CI_HDRC_DISABLE_HOST_STREAMING,
 };
 
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
@@ -126,8 +131,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
struct ci_hdrc_platform_data pdata = {
.name   = dev_name(&pdev->dev),
.capoffset  = DEF_CAPOFFSET,
-   .flags  = CI_HDRC_DISABLE_STREAMING |
-   CI_HDRC_SET_NON_ZERO_TTHA,
+   .flags  = CI_HDRC_SET_NON_ZERO_TTHA,
};
int ret;
const struct of_device_id *of_id =
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/10] ARM: imx6: set ahb-burst-config as 0 for USB

[Peter Chen]

After setting ahb burst configuration as 0, we can increase tx/rx
burst size, it will improve the USB performance

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 4 
 arch/arm/boot/dts/imx6sl.dtsi  | 3 +++
 arch/arm/boot/dts/imx6sx.dtsi  | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e6d1359..42d62b0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -853,6 +853,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -864,6 +865,7 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -874,6 +876,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -884,6 +887,7 @@
clocks = <&clks IMX6QDL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 3>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index a78e715..066fac9 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -688,6 +688,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -698,6 +699,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -708,6 +710,7 @@
clocks = <&clks IMX6SL_CLK_USBOH3>;
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 708175d..3656a1d 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -746,6 +746,7 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
fsl,anatop = <&anatop>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -756,6 +757,7 @@
clocks = <&clks IMX6SX_CLK_USBOH3>;
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
@@ -768,6 +770,7 @@
phy_type = "hsic";
fsl,anatop = <&anatop>;
dr_mode = "host";
+   ahb-burst-config = <0x0>;
status = "disabled";
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/10] ARM: imx6: change default burst size for USB

[Peter Chen]

It can improve the USB performance when choosing larger
burst size at some systems (bus size is larger), there is
no side effect if this burst size is larger than bus size.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 
 arch/arm/boot/dts/imx6sl.dtsi  | 6 ++
 arch/arm/boot/dts/imx6sx.dtsi  | 6 ++
 3 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 42d62b0..b9f2e3a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -854,6 +854,8 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -866,6 +868,8 @@
fsl,usbmisc = <&usbmisc 1>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -877,6 +881,8 @@
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -888,6 +894,8 @@
fsl,usbmisc = <&usbmisc 3>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 066fac9..627549f 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -689,6 +689,8 @@
fsl,usbphy = <&usbphy1>;
fsl,usbmisc = <&usbmisc 0>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -700,6 +702,8 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -711,6 +715,8 @@
fsl,usbmisc = <&usbmisc 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 3656a1d..6844e9e 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -747,6 +747,8 @@
fsl,usbmisc = <&usbmisc 0>;
fsl,anatop = <&anatop>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -758,6 +760,8 @@
fsl,usbphy = <&usbphy2>;
fsl,usbmisc = <&usbmisc 1>;
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
@@ -771,6 +775,8 @@
fsl,anatop = <&anatop>;
dr_mode = "host";
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>;
+   rx-burst-size-dword = <0x10>;
status = "disabled";
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@

[PATCH 06/10] usb: chipidea: add ahb burst configuration interface

[Peter Chen]

The users can change it through dts or platform data if they
want to change the default value.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/bits.h  |  3 +++
 drivers/usb/chipidea/core.c  | 14 ++
 include/linux/usb/chipidea.h |  2 ++
 3 files changed, 19 insertions(+)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 831a8f6..462ad02 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -25,6 +25,9 @@
 #define VERSION  (0xF << 25)
 #define CIVERSION(0x7 << 29)
 
+/* SBUSCFG */
+#define AHBBRST_MASK   0x7
+
 /* HCCPARAMS */
 #define HCCPARAMS_LEN BIT(17)
 
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 38bd036..f60cbf6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -439,6 +439,9 @@ void ci_platform_configure(struct ci_hdrc *ci)
 
hw_write(ci, OP_USBCMD, 0xff, ci->platdata->itc_setting << 16);
 
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_AHB_BURST)
+   hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
+   ci->platdata->ahb_burst_config);
 }
 
 /**
@@ -647,6 +650,17 @@ static int ci_get_platdata(struct device *dev,
}
}
 
+   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   &platdata->ahb_burst_config);
+   if (ret) {
+   dev_err(dev,
+   "failed to get ahb-burst-config\n");
+   return ret;
+   }
+   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   }
+
return 0;
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 982f8cc..9848a4e 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -33,6 +33,7 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_DISABLE_HOST_STREAMING BIT(10)
 #define CI_HDRC_DISABLE_STREAMING (CI_HDRC_DISABLE_DEVICE_STREAMING |  \
CI_HDRC_DISABLE_HOST_STREAMING)
+#define CI_HDRC_OVERRIDE_AHB_BURST BIT(11)
enum usb_dr_modedr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT 0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
@@ -42,6 +43,7 @@ struct ci_hdrc_platform_data {
booltpl_support;
/* interrupt threshold setting */
u32 itc_setting;
+   u32 ahb_burst_config;
 };
 
 /* Default offset of capability registers */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/10] usb: chipidea: usbmisc_imx: add unburst setting for imx6

[Peter Chen]

With this setting and AHBBRST at SBUSCFG as "Incremental burst of
unspecified length", each unburst size can be taken as one single transfer.
It is benefit for unburst size transfer.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/usbmisc_imx.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 3cefd49..69d39dc 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -54,6 +54,7 @@
 #define MX53_USB_PHYCTRL1_PLLDIV_MASK  0x3
 #define MX53_USB_PLL_DIV_24_MHZ0x01
 
+#define MX6_BM_UNBURST_SETTING BIT(1)
 #define MX6_BM_OVER_CUR_DISBIT(7)
 #define MX6_BM_WAKEUP_ENABLE   BIT(10)
 #define MX6_BM_ID_WAKEUP   BIT(16)
@@ -255,14 +256,21 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data 
*data)
if (data->index > 3)
return -EINVAL;
 
+   spin_lock_irqsave(&usbmisc->lock, flags);
+
if (data->disable_oc) {
-   spin_lock_irqsave(&usbmisc->lock, flags);
reg = readl(usbmisc->base + data->index * 4);
writel(reg | MX6_BM_OVER_CUR_DIS,
usbmisc->base + data->index * 4);
-   spin_unlock_irqrestore(&usbmisc->lock, flags);
}
 
+   /* SoC unburst setting */
+   reg = readl(usbmisc->base + data->index * 4);
+   writel(reg | MX6_BM_UNBURST_SETTING,
+   usbmisc->base + data->index * 4);
+
+   spin_unlock_irqrestore(&usbmisc->lock, flags);
+
usbmisc_imx6q_set_wakeup(data, false);
 
return 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/10] Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc

[Peter Chen]

It is used to override the default setting for burst size, changing
burst size takes effect only when the SBUSCFG.AHBBRST = 0.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 3c377a3..0f0929c 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -34,6 +34,10 @@ Optional properties:
   should be aligned with ITC bits at register USBCMD.
 - ahb-burst-config: it is vendor dependent, the required value should be
   aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7.
+- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword
+  (4 bytes).
+- rx-burst-size-dword: it is vendor dependent, the rx burst size in dword
+  (4 bytes).
 
 Example:
 
@@ -48,4 +52,6 @@ Example:
gadget-itc-setting = <0x4>; /* 4 micro-frames */
 /* Incremental burst of unspecified length */
ahb-burst-config = <0x0>;
+   tx-burst-size-dword = <0x10>; /* 64 bytes */
+   rx-burst-size-dword = <0x10>;
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/10] Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc

[Peter Chen]

It is used to change ahb burst configuration for platforms, it is
vendor specific.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 4159c8c..3c377a3 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -32,6 +32,8 @@ Optional properties:
 - external-vbus-divider: (FSL only) enables off-chip resistor divider for Vbus
 - itc-setting: interrupt threshold control register control, the setting
   should be aligned with ITC bits at register USBCMD.
+- ahb-burst-config: it is vendor dependent, the required value should be
+  aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7.
 
 Example:
 
@@ -44,4 +46,6 @@ Example:
phy-names = "usb-phy";
vbus-supply = <®_usb0_vbus>;
gadget-itc-setting = <0x4>; /* 4 micro-frames */
+/* Incremental burst of unspecified length */
+   ahb-burst-config = <0x0>;
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/10] USB: chipidea misc patches

[Peter Chen]

Hi all,

In this series, I add several new interfaces for chipidea driver,
they are mainly for system configuration adjustment. The USB
performance may be improved with these configuration changing,
but each vendor driver owner needs to consult with your IC
owner which configuration parameters are suitable for your system
before changing it, and only change it if necessary.

The other changes are for imx, it shows how imx uses these interfaces.
Shawn, the patch [5/10] and [9/10] are dts changes, help to review it
please.

Peter Chen (10):
  usb: chipidea: udc: zero-length packet is only needed for TX
  usb: chipidea: define stream mode disable for both roles
  usb: chipidea: imx: add stream mode enable for device mode at
imx6sl/imx6sx
  Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc
  ARM: imx6: set ahb-burst-config as 0 for USB
  usb: chipidea: add ahb burst configuration interface
  usb: chipidea: usbmisc_imx: add unburst setting for imx6
  Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc
  ARM: imx6: change default burst size for USB
  usb: chipidea: add tx/rx burst size configuration interface

 .../devicetree/bindings/usb/ci-hdrc-usb2.txt   | 10 
 arch/arm/boot/dts/imx6qdl.dtsi | 12 +
 arch/arm/boot/dts/imx6sl.dtsi  |  9 
 arch/arm/boot/dts/imx6sx.dtsi  |  9 
 drivers/usb/chipidea/bits.h|  7 +++
 drivers/usb/chipidea/ci.h  |  1 +
 drivers/usb/chipidea/ci_hdrc_imx.c | 16 +++---
 drivers/usb/chipidea/core.c| 62 +-
 drivers/usb/chipidea/udc.c |  2 +-
 drivers/usb/chipidea/usbmisc_imx.c | 12 -
 include/linux/usb/chipidea.h   | 11 +++-
 11 files changed, 140 insertions(+), 11 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/10] usb: chipidea: define stream mode disable for both roles

[Peter Chen]

The system bus and chipidea IP have different limitations for
both host and device mode.
For example, with below errata, we need to enable SDIS(Stream Disable Mode)
at host mode. But we don't want it for device mode at the same system.

TAR 9000378958
Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to Hang on 
OUT Retry
Impacted Configuration: Host mode, all transfer types
Description:
The host core operating in streaming mode may under run while sending the data 
packet of an OUT transaction. This under run can occur if there are unexpected 
system delays in fetching the remaining packet data from memory. The host 
forces a bad CRC on the packet, the device detects the error and discards the 
packet. The host then retries a Bulk, Interrupt, or Control transfer if an 
under run occurs according to the USB specification.
During simulations, it was found that the host does not issue the retry of the 
failed bulk OUT. It does not issue any other transactions except SOF packets 
that have incorrect frame numbers.
The second failure mode occurs if the under run occurs on an ISO OUT 
transaction and the next ISO transaction is a zero byte packet. The host does 
not issue any transactions (including SOFs). The device detects a Suspend 
condition, reverts to full speed, and waits for resume signaling.
A third failure mode occurs when the host under runs on an ISO OUT and the next 
ISO in the schedule is an ISO OUT with two max packets of 1024 bytes each.
The host should issue MDATA for the first OUT followed by DATA1 for the second. 
However, it drops the MDATA transaction, and issues the DATA1 transaction.
The system impact of this bug is the same regardless of the failure mode 
observed. The host core hangs, the ehci_ctrl state machine waits for the 
protocol engine to send the completion status for the corrupted transaction, 
which never occurs. No indication is sent to the host controller driver, no 
register bits change and no interrupts occur. Eventually the requesting 
application times out.
Detailed internal behavior:
The EHCI control state machine (ehci_ctrl) in the DMA block is responsible for 
parsing the schedules and initiating all transactions. The ehci_ctrl state 
machine passes the transaction details to the protocol block by writing the 
transaction information in to the TxFIFO. It then asserts the pe_hst_run_pkt 
signal to inform the host protocol state machine (pe_hst_state) that there is a 
packet in the TxFIFO.
A tag of 0x0 indicates a start of packet with the data providing the following 
information:

35:32 Tag
31:30 Reserved
29:23 Endpoint (lowest 4 bits)
22:16 Address
15:10 Reserved
9:8 Endpoint speed
7:6 Endpoint type
5:6 Data Toggle
3:0 PID
The pe_hst_state reads the packet information and constructs the packet and 
issues it to the PHY interface.
The ehci_ctrl state machine writes the start transaction information in to the 
TxFIFO as 0x03002910c for the OUT packet that had the under run error. However, 
it writes 0xC3002910C for the retry of the Out transaction, which is incorrect.
The pe_hst_state enters a bus timeout state after sending the bad CRC for the 
packet that under ran. It then purges any data that was back filled in to the 
TxFIFO for the packet that under ran. The pe_hst_state machine stops purging 
the TxFIFO when it is empty or if it reads a location that has a tag of 0x0, 
indicating a start of packet command.
The pe_hst_state reads 0xC3002910C and discards it as it does not decode to a 
start of packet command. It continues to purge the OUT data that has been 
pre-buffered for the OUT retry . The pe_hst_state detects the hst_packet_run 
signal and attempts to read the PID and address information from the TxFIFO. 
This location has packet data and so does not decode to a valid PID and so 
falls through to the PE_HST_SOF_LOAD state where the frame_num_counter is 
updated. The frame_num_counter is updated with the data in the TxFIFO. In this 
case, the data is incorrect as the ehci_ctrl state machine did not initiate the 
load. The hst_pe_state machine detects the SOF request signal and sends an SOF 
with the bad frame number. Meanwhile, the ehci_ctrl state machine waits 
indefinitely in the run_pkt state waiting for the completion status from 
pe_hst_state machine, which will never happen.
The ISO failure case is similar except that there is no retry for ISO. The 
ehci_ctrl state machine moves to the next transfer in the periodic schedule. If 
the under run occurs on the last entry of the periodic list then it moves to 
the Async schedule.
In the case of ISO OUT simulations, the next ISO is a zero byte OUT and again 
the start of packet command gets corrupted. The TxFIFO is empty when the 
hst_pe_state attempts to read the Address and PID information as the 
transaction is a zero byte packet. This results in the hst_pe_state machine 
staying in the GET_PID state, which means that it does not issue any 
transactions (including SOFs). The device detect

[PATCH 01/10] usb: chipidea: udc: zero-length packet is only needed for TX

[Peter Chen]

The zero-length packet is the sendor tells the receiver that there
is no more data, so it is only needed at the TX side.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 06b7224..51e66a1 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -445,7 +445,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
rest -= count;
}
 
-   if (hwreq->req.zero && hwreq->req.length
+   if (hwreq->req.zero && hwreq->req.length && hwep->dir == TX
&& (hwreq->req.length % hwep->ep.maxpacket == 0))
add_td_to_list(hwep, hwreq, 0);
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] pci:host: Add Altera PCIe host controller driver

[Rob Herring]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds the Altera PCIe host controller driver.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   9 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 576 
> +
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..af19039 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>   Say Y here if you want to use the Broadcom iProc PCIe controller
>   through the BCMA bus interface
>
> +config PCIE_ALTERA
> +   bool "Altera PCIe controller"
> +   depends on ARCH_SOCFPGA
> +   depends on OF
> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> +   help
> + Say Y here if you want to enable PCIe controller support for Altera
> + SoCFPGA family of SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6954f76 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>  obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
> new file mode 100644
> index 000..afa64e9
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -0,0 +1,576 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define A2P_ADDR_MAP_LO0   0x1000
> +#define A2P_ADDR_MAP_HI0   0x1004
> +#define RP_TX_REG0 0x2000
> +#define RP_TX_REG1 0x2004
> +#define RP_TX_CNTRL0x2008
> +#define RP_TX_EOP  0x2
> +#define RP_TX_SOP  0x1
> +#define RP_RXCPL_STATUS0x2010
> +#define RP_RXCPL_EOP   0x2
> +#define RP_RXCPL_SOP   0x1
> +#define RP_RXCPL_REG0  0x2014
> +#define RP_RXCPL_REG1  0x2018
> +#define P2A_INT_STATUS 0x3060
> +#define P2A_INT_STS_ALL0xF
> +#define P2A_INT_ENABLE 0x3070
> +#define P2A_INT_ENA_ALL0xF
> +#define RP_LTSSM   0x3C64
> +#define LTSSM_L0   0xF
> +
> +/* TLP configuration type 0 and 1 */
> +#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 
> */
> +#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 
> */
> +#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 
> */
> +#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 
> */
> +#define TLP_PAYLOAD_SIZE   0x01
> +#define TLP_READ_TAG   0x1D
> +#define TLP_WRITE_TAG  0x10
> +#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
> +#define TLP_CFG_DW1(reqid, tag)(((reqid) << 16) | (tag << 8) 
> | 0xF)
> +#define TLP_CFG_DW2(bus, devfn, offset)\
> +   (((bus) << 24) | ((devfn) << 16) | (offset))
> +#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
> +#define TLP_COMPL_STATUS(hdr)  (((hdr) & 0xE0) >> 13)
> +#define TLP_HDR_SIZE   3
> +#define TLP_LOOP   10
> +
> +#define INTX_NUM   4
> +
> +/* Address translation table entry size */
> +#define ATT_ENTRY_SIZE 8
> +
> +#define DWORD_MASK 3
> +
> +struct altera_pcie {
> +   struct platform_device  *pdev;
> +   struct resource *txs;
> +   void __iomem*cra_base;
> +   int hwirq;
> +   u8  root_bus_nr;
> +   struct irq_domain   *irq_domain;
> +   struct resource bus_range;
> +   struct list_head 

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 10:07 PM, Ley Foon Tan  wrote:
> On Wed, Jul 29, 2015 at 1:00 AM, Dinh Nguyen  wrote:
>> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
>>> number of vectors, which is a dts parameter.
>>> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>>>   Say Y here if you want to enable PCIe controller support for 
>>> Altera
>>>   SoCFPGA family of SoCs.
>>>
>>> +config PCIE_ALTERA_MSI
>>> +   bool "Altera PCIe MSI feature"
>>> +   depends on PCI_MSI && PCIE_ALTERA
>>> +   help
>>> + Say Y here if you want PCIe MSI support for the Altera SocFPGA 
>>> SoC.
>>> + This MSI driver supports Altera MSI to GIC controller IP.
>>> +
>>
>> Couldn't this driver get combined with the pcie-altera driver?
>
> This MSI IP is a soft IP and it is optional to PCI system. So, we have
> individual driver for it and user can disable it.
>

So why can't you use CONFIG_PCI_MSI in the pcie-altera driver? I see
that most, if not
all of the other drivers are combined with MSI.

Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Ley Foon Tan]

On Wed, Jul 29, 2015 at 1:00 AM, Dinh Nguyen  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
>> number of vectors, which is a dts parameter.
>> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>>   Say Y here if you want to enable PCIe controller support for Altera
>>   SoCFPGA family of SoCs.
>>
>> +config PCIE_ALTERA_MSI
>> +   bool "Altera PCIe MSI feature"
>> +   depends on PCI_MSI && PCIE_ALTERA
>> +   help
>> + Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
>> + This MSI driver supports Altera MSI to GIC controller IP.
>> +
>
> Couldn't this driver get combined with the pcie-altera driver?

This MSI IP is a soft IP and it is optional to PCI system. So, we have
individual driver for it and user can disable it.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] pci:host: Add Altera PCIe host controller driver

[Ley Foon Tan]

On Wed, Jul 29, 2015 at 12:45 AM, Dinh Nguyen  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> This patch adds the Altera PCIe host controller driver.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  drivers/pci/host/Kconfig   |   9 +
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pcie-altera.c | 576 
>> +
>>  3 files changed, 586 insertions(+)
>>  create mode 100644 drivers/pci/host/pcie-altera.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index 675c2d1..af19039 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>>   Say Y here if you want to use the Broadcom iProc PCIe controller
>>   through the BCMA bus interface
>>
>> +config PCIE_ALTERA
>> +   bool "Altera PCIe controller"
>> +   depends on ARCH_SOCFPGA
>> +   depends on OF
>
> I don't think you need this, "depends on ARCH_SOCFPGA" should already
> have taken care of this.
Okay, will remove this.
>
>> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> +   help
>> + Say Y here if you want to enable PCIe controller support for Altera
>> + SoCFPGA family of SoCs.
>> +
>>  endmenu
>
> 
>
>> +
>> +static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
>> +{
>> +   u8 loop;
>> +   struct tlp_rp_regpair_t tlp_rp_regdata;
>> +
>> +   for (loop = TLP_LOOP; loop > 0; loop--) {
>> +
>> +   tlp_read_rx(pcie, &tlp_rp_regdata);
>> +
>> +   if (tlp_rp_regdata.ctrl & RP_RXCPL_EOP) {
>> +
>> +   if (value)
>> +   *value = tlp_rp_regdata.reg0;
>> +
>> +   return PCIBIOS_SUCCESSFUL;
>> +   }
>
> Remove all the unnecessary newlines in this function.
Noted.

>> +   }
>> +
>> +   return -ENOENT;
>> +}
>> +
>
> 
>
>> +
>> +static struct platform_driver altera_pcie_driver = {
>> +   .probe  = altera_pcie_probe,
>> +   .remove = altera_pcie_remove,
>> +   .driver = {
>> +   .name   = "altera-pcie",
>> +   .owner  = THIS_MODULE,
>
> Don't need to set owner anymore as this will get populated by the driver core.

Will remove it.

Thanks for reviewing.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] arm: mach-socfpga: enable pci support

[Ley Foon Tan]

On Tue, Jul 28, 2015 at 9:26 PM, Rob Herring  wrote:
> On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
>> Enable CONFIG_ARCH_SUPPORT_MSI and CONFIG_PCI in SOCFPGA platform.
>>
>> Signed-off-by: Ley Foon Tan 
>> ---
>>  arch/arm/mach-socfpga/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
>> index 90efdeb..7ff4576 100644
>> --- a/arch/arm/mach-socfpga/Kconfig
>> +++ b/arch/arm/mach-socfpga/Kconfig
>> @@ -1,6 +1,7 @@
>>  menuconfig ARCH_SOCFPGA
>> bool "Altera SOCFPGA family" if ARCH_MULTI_V7
>> select ARCH_SUPPORTS_BIG_ENDIAN
>> +   select ARCH_SUPPORTS_MSI
>
> This doesn't exist in mainline having been removed in 3.12.
Will removed this.
>
>> select ARM_AMBA
>> select ARM_GIC
>> select CACHE_L2X0
>> @@ -9,6 +10,7 @@ menuconfig ARCH_SOCFPGA
>> select HAVE_ARM_SCU
>> select HAVE_ARM_TWD if SMP
>> select MFD_SYSCON
>> +   select PCI
>
> This should not be selected by the platform, but be user selectable
> unless perhaps you require PCI to boot.

Will removed this as well.

Thanks for reviewing.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/3] Add MediaTek display PWM driver

[YH Huang]

On Fri, 2015-07-24 at 17:10 +0800, YH Huang wrote:
> On Fri, 2015-07-24 at 10:42 +0200, Matthias Brugger wrote:
> > On Monday, July 20, 2015 04:17:14 PM YH Huang wrote:
> > > This patch series add the use of display PWM driver, documentation
> > > and device tree for Mediatek SoCs. The driver is used to support
> > > the backlight of the panel. This is based on v4.2-rc1.
> > > 
> > > The clock definitions (CLK_MM_DISP_PWM*) are added by James Liao's patch:
> > > clk: mediatek: Add subsystem clocks of MT8173
> > > 
> > > Change in v6:
> > > 1. Enable clocks in the pwm_enable function
> > > 2. Remove suspend/resume code since pwm-backlight driver has done the same
> > > things 3. Revise some code to make it easier to read
> > > 
> > 
> > Can you please provide the whole change log for all versions the next time.
> > It's easier this way to understand the evolution of the series.
> 
> Change in v6:
> 1. Enable clocks in the pwm_enable function.
> 2. Remove suspend/resume code since pwm-backlight driver has done the
> same things.
> 3. Revise some code to make it easier to read.
> 
> Change in v5:
> 1. Configure PWM output via pinctrl.
> 2. Fix the parameter name in dtsi.
> 
> Change in v4:
> 1. Codebase is on v4.2-rc1.
> 2. Add the PWM node in dtsi.
> 3. Change the dependency in Kconfig.
> 4. Rewrite some code for readability.
> 
> Change in v3:
> 1. Add suspend/resume function.
> 2. Fix the formula for high_width calculation.
> 3. Rewrite some code to make it easier to read.
> 4. Add more information in the commit message.
> 
> Change in v2:
> 1. Rewrite descriptions for driver in kconfig to make it much clear.
> 2. Rename the driver from "pwm-mediatek-disp" to "pwm-mtk-disp".
> 3. Disable clocks in the error path.
> 4. Change the shift values in decimal instead of hex.
> 5. Rename and add some variables or function name for consistency and
> readability.
> 6. Drop unnecessary parentheses, spaces, variables and add newlines to
> make the code easiler to read.

Hi all,

If you have any suggestions, please let me know.
Perhaps we can apply the patch?

Regards,
YH Huang

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Yang, Wenyou]

Hi Guenter,

Thank you for your prompt answer.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年7月29日 9:23
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
> support
> 
> On 07/28/2015 05:38 PM, Yang, Wenyou wrote:
> > Hi Guenter,
> >
> > Thank you very much for your review.
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:li...@roeck-us.net]
> >> Sent: 2015年7月28日 15:14
> >> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org;
> >> pawel.m...@arm.com; mark.rutl...@arm.com;
> >> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> >> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas;
> >> boris.brezillon@free- electrons.com; devicetree@vger.kernel.org;
> >> linux-ker...@vger.kernel.org; linux- watch...@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org
> >> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new
> >> feature support
> >>
> >> On 07/28/2015 12:00 AM, Wenyou Yang wrote:
> >>> In the datasheet, the new feature is describled as "WDT_MR can be
> >>> written until a LOCKMR command is issued in WDT_CR".
> >>> That is to say, as long as the bootstrap and u-boot don't issue a
> >>> LOCKMR command, WDT_MR can be written in kernel.
> >>>
> >>> So the driver can enable/disable the watchdog timer hardware, set
> >>> WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
> >>> WDT_MR register to set the watchdog timer timeout.
> >>>
> >>> The timer is not necessary that regularly sends a keepalive ping to
> >>> the watchdog timer hardware.
> >>>
> >>> It is introduced from sama5d4 SoCs.
> >>>
> >> Since there are so many changes, I wonder is a separate driver would
> >> make more sense.
> > Yes, a bit many changes.
> > I thought reuse the driver code.
> > If a separate driver, I am afraid it includes much duplicated code.
> > After all, it is for the same device with different feature.
> >
> > I don't think it is necessary to have multiple drivers for the same 
> > peripheral with
> different feature.
> >
> 
> The concept for the two mechanisms is all different: In one, the watchdog
> keepalive is triggered from timer code. In the other, the watchdog timeout is
> triggered directly from the heartbeat function. One assumes that the watchdog 
> is
> always running, and that it must be pinged even if closed. The other disables 
> the
> watchdog on close.
> 
> What I _can_ see is that the driver is becoming an unmaintainable mess, with 
> lots
> of if/else in pretty much every function. I consider this much less desirable 
> than a
> bit of code duplication - if there is any. Seriously, most of the added code 
> might as
> well be for a completely different chip.

You are right, I accepted your advice. I will rewrite it. Thanks.

> 
> Guenter

Best Regards,
Wenyou Yang

[PATCH 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

[Bjorn Andersson]

From: Werner Johansson 

Signed-off-by: Werner Johansson 
Signed-off-by: Bjorn Andersson 
---
 .../bindings/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt

diff --git a/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..758d48d33e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3" qHD TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls043t1le01-qhd-vid"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi0: qcom,mdss_dsi@fd922800 {
+   panel: panel@0 {
+   compatible = "sharp,ls043t1le01-qhd-vid";
+   reg = <0>;
+   avdd-supply = <&pm8941_l22>;
+   backlight = <&pm8941_wled>;
+   reset-gpios = <&pm8941_gpios 19 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
1.8.2.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Add vendor prefix for Sharp Microelectronics

[Bjorn Andersson]

On Wed, Jul 1, 2015 at 10:41 AM, Rob Herring  wrote:
> On Wed, Jul 1, 2015 at 7:01 AM, Thierry Reding  
> wrote:
>> On Mon, Oct 13, 2014 at 01:54:09PM +0200, Thierry Reding wrote:
>>> On Fri, Aug 01, 2014 at 03:50:44PM +0200, Thierry Reding wrote:
>>> > From: Thierry Reding 
>>> >
>>> > Use "sharp" as the vendor prefix for Sharp Microelectronics in device
>>> > tree compatible strings.
>>> >
>>> > Signed-off-by: Thierry Reding 
>>> > ---
>>> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>> >  1 file changed, 1 insertion(+)
>>>
>>> Ping?
>>
>> Rob, I just stumbled across this in my stack of patches that never got
>> merged. Can you ack this?
>
> Sorry, missed this one. I've flagged it now to apply for 4.2 or you
> can if you prefer:
>
> Acked-by: Rob Herring 
>

Sorry for jumping in late, but found this as I was about to submit a
patch for the same addition.

Except that from what I can find the real name is "Sharp
Microelectronics of the Americas" (or Europe...), which is a division
of Sharp Electronics Corporation, a subsidiary of Sharp Corporation -
the latter which is what's used in the data sheets for my e.g. the
lp855x.

So I think the patch should instead be adding:
sharp   Sharp Corporation

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Guenter Roeck]

On 07/28/2015 05:38 PM, Yang, Wenyou wrote:

Hi Guenter,

Thank you very much for your review.


-Original Message-
From: Guenter Roeck [mailto:li...@roeck-us.net]
Sent: 2015年7月28日 15:14
To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
support

On 07/28/2015 12:00 AM, Wenyou Yang wrote:

In the datasheet, the new feature is describled as "WDT_MR can be
written until a LOCKMR command is issued in WDT_CR".
That is to say, as long as the bootstrap and u-boot don't issue a
LOCKMR command, WDT_MR can be written in kernel.

So the driver can enable/disable the watchdog timer hardware, set
WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
WDT_MR register to set the watchdog timer timeout.

The timer is not necessary that regularly sends a keepalive ping to
the watchdog timer hardware.

It is introduced from sama5d4 SoCs.


Since there are so many changes, I wonder is a separate driver would make more
sense.

Yes, a bit many changes.
I thought reuse the driver code.
If a separate driver, I am afraid it includes much duplicated code.
After all, it is for the same device with different feature.

I don't think it is necessary to have multiple drivers for the same peripheral 
with different feature.



The concept for the two mechanisms is all different: In one, the watchdog 
keepalive is triggered
from timer code. In the other, the watchdog timeout is triggered directly from 
the heartbeat
function. One assumes that the watchdog is always running, and that it must be 
pinged even
if closed. The other disables the watchdog on close.

What I _can_ see is that the driver is becoming an unmaintainable mess, with 
lots of if/else
in pretty much every function. I consider this much less desirable than a bit 
of code
duplication - if there is any. Seriously, most of the added code might as well 
be for
a completely different chip.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3] ARM: dts: Add SPI CS on exynos5250-snow

[Kukjin Kim]

Michal Suchanek wrote:
> 
> Although there is only one choice of chipselect it is necessary to
> specify it. The driver cannot claim the gpio otherwise.
> 
> Signed-off-by: Michal Suchanek 
> Acked-by: Javier Martinez Canillas 
> Acked-by: Krzysztof Kozlowski 
> 

>From here ---8<8<---

> --
>  - don't move unrelated line
>  - use symbolic GPIO_ACTIVE_HIGH

to here  ---8<8<---

should be added under the following '---'.

Please add some additional comments like above 'changes since previous version'
under the following '---' not '--', because all comments will be logged before
the '---' and I don't want to keep the changes basically.

Anyway, applied with removing above comments.

Thanks,
Kukjin

> ---
>  arch/arm/boot/dts/exynos5250-snow.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index b7f4122..2d6a976 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -688,6 +688,7 @@
>   status = "okay";
>   samsung,spi-src-clk = <0>;
>   num-cs = <1>;
> + cs-gpios = <&gpa2 5 GPIO_ACTIVE_HIGH>;
>  };
> 
>  &usbdrd_dwc3 {
> --
> 2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mmc: sunxi: Don't start commands while the card is busy

[Shawn Lin]

在 2015/7/29 3:22, Arend van Spriel 写道:

On 07/21/2015 02:15 PM, Ulf Hansson wrote:

On 10 July 2015 at 17:14, Hans de Goede  wrote:

Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by it starting new commands while
the card signals that it is still busy processing a previous command.


Which are those commands? Or more interesting, which response types do
these commands expect?
I don't think this is a sunxi specific issue, I have seen similar
issues for other host controllers.


Indeed. A similar fix was needed for dw_mmc host controller.
bit 10 in STATUS register of sysnopsys dw_mmc should be issued each time 
you start a new cmd. It's hard to say whetehr a local hack or not, 
because it's a mandatory requirement from IP databook(refer to 
"Sysnopsys DesignWare cores Mobile Storage Host Databook" Chapter 7- 
Programming the DWC_mobile_storage).


Bit 10: indicate state-machine is ready, controller MUST guarantee all
I/O used in "free state", actually high.

If dw_mmc's state-machine isn't ready, NO cmd can be issued, which means 
even we configure cmd and cmdarg, start bit cannot be auto-clean by 
controller that leads to no cmd_done interrupt generated which dw_mmc's 
tasklet state-machine need.





I am thinking that perhaps this should be managed by the mmc core
instead of local hacks to sunxi. Potentially we could make the core to
invoke the already existing host_ops->card_busy() callback when
needed...


The problem here is that there are a number of host controllers out
there not implementing that callback. That may be because the hardware
is dealing properly with busy signalling, but I would not bet on that.

Regards,
Arend


Within this context, could I ask whether you controller supports IRQ
based HW-busy detection? Or you need polling of the status register?



This commit fixes this, thereby fixing the wifi reliability issues on
the Cubietruck and other sunxi boards using sdio wifi.

Reported-by: Eugene K 
Suggested-by: Eugene K 
Cc: Eugene K 
Cc: Arend van Spriel 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Properly accredit Eugene K for coming up with the fix for this
---
  drivers/mmc/host/sunxi-mmc.c | 32 
  1 file changed, 32 insertions(+)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..daa90b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -289,6 +289,24 @@ static int sunxi_mmc_init_host(struct mmc_host
*mmc)
 return 0;
  }

+/* Wait for card to report ready before starting a new cmd */
+static int sunxi_mmc_wait_card_ready(struct sunxi_mmc_host *host)
+{
+   unsigned long expire = jiffies + msecs_to_jiffies(500);
+   u32 rval;
+
+   do {
+   rval = mmc_readl(host, REG_STAS);
+   } while (time_before(jiffies, expire) && (rval &
SDXC_CARD_DATA_BUSY));
+
+   if (rval & SDXC_CARD_DATA_BUSY) {
+   dev_err(mmc_dev(host->mmc), "Error R1 ready timeout\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
  static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host,
 struct mmc_data *data)
  {
@@ -383,6 +401,8 @@ static void sunxi_mmc_send_manual_stop(struct
sunxi_mmc_host *host,
 u32 arg, cmd_val, ri;
 unsigned long expire = jiffies + msecs_to_jiffies(1000);

+   sunxi_mmc_wait_card_ready(host);
+
 cmd_val = SDXC_START | SDXC_RESP_EXPIRE |
   SDXC_STOP_ABORT_CMD | SDXC_CHECK_RESPONSE_CRC;

@@ -597,6 +617,11 @@ static int sunxi_mmc_oclk_onoff(struct
sunxi_mmc_host *host, u32 oclk_en)
  {
 unsigned long expire = jiffies + msecs_to_jiffies(250);
 u32 rval;
+   int ret;
+
+   ret = sunxi_mmc_wait_card_ready(host);
+   if (ret)
+   return ret;

 rval = mmc_readl(host, REG_CLKCR);
 rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
@@ -785,6 +810,13 @@ static void sunxi_mmc_request(struct mmc_host
*mmc, struct mmc_request *mrq)
 return;
 }

+   ret = sunxi_mmc_wait_card_ready(host);
+   if (ret) {
+   mrq->cmd->error = ret;
+   mmc_request_done(mmc, mrq);
+   return;
+   }
+
 if (data) {
 ret = sunxi_mmc_map_dma(host, data);
 if (ret < 0) {
--
2.4.3



Kind regards
Uffe



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Shawn Lin

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Yang, Wenyou]

Hi Guenter,

Thank you very much for your review.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年7月28日 15:14
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
> support
> 
> On 07/28/2015 12:00 AM, Wenyou Yang wrote:
> > In the datasheet, the new feature is describled as "WDT_MR can be
> > written until a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written in kernel.
> >
> > So the driver can enable/disable the watchdog timer hardware, set
> > WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
> > WDT_MR register to set the watchdog timer timeout.
> >
> > The timer is not necessary that regularly sends a keepalive ping to
> > the watchdog timer hardware.
> >
> > It is introduced from sama5d4 SoCs.
> >
> Since there are so many changes, I wonder is a separate driver would make more
> sense.
Yes, a bit many changes.
I thought reuse the driver code.
If a separate driver, I am afraid it includes much duplicated code. 
After all, it is for the same device with different feature. 

I don't think it is necessary to have multiple drivers for the same peripheral 
with different feature.
 
> 
> Thoughts ?
> 
> Guenter
> 
> > Signed-off-by: Wenyou Yang 
> > ---
> >   drivers/watchdog/at91sam9_wdt.c |  255
> ---
> >   drivers/watchdog/at91sam9_wdt.h |4 +
> >   2 files changed, 190 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c
> > b/drivers/watchdog/at91sam9_wdt.c index 1443b3c..6b61084 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -10,9 +10,12 @@
> >*/
> >
> >   /*
> > + * For AT91SAM9x SoCs, the Watchdog Timer has the following constraint.
> >* The Watchdog Timer Mode Register can be only written to once. If the
> >* timeout need to be set from Linux, be sure that the bootstrap or the
> >* bootloader doesn't write to this register.
> > + * From SAMA5D4, the Watchdog Timer Mode Register can be written
> > + * until a LOCKMR command is issued in WDT_CR.
> >*/
> >
> >   #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt @@ -80,6 +83,11 @@
> > MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> "
> > "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> >
> >   #define to_wdt(wdd) container_of(wdd, struct at91wdt, wdd)
> > +
> > +struct at91wdt_variant {
> > +   bool mr_writable;
> > +};
> > +
> >   struct at91wdt {
> > struct watchdog_device wdd;
> > void __iomem *base;
> > @@ -90,6 +98,9 @@ struct at91wdt {
> > unsigned long heartbeat;/* WDT heartbeat in jiffies */
> > bool nowayout;
> > unsigned int irq;
> > +   bool use_timer;
> > +   bool enabled;
> > +   struct at91wdt_variant *drv_data;
> >   };
> >
> >   /*
> > . 
> > */ @@ -133,21 +144,67 @@
> static void at91_ping(unsigned long data)
> >   static int at91_wdt_start(struct watchdog_device *wdd)
> >   {
> > struct at91wdt *wdt = to_wdt(wdd);
> > -   /* calculate when the next userspace timeout will be */
> > -   wdt->next_heartbeat = jiffies + wdd->timeout * HZ;
> > +   u32 reg;
> > +
> > +   if (wdt->drv_data->mr_writable) {
> > +   reg = wdt_read(wdt, AT91_WDT_MR);
> > +   reg &= ~AT91_WDT_WDDIS;
> > +   wdt_write(wdt, AT91_WDT_MR, reg);
> > +   } else {
> > +   /* calculate when the next userspace timeout will be */
> > +   wdt->next_heartbeat = jiffies + wdd->timeout * HZ;
> > +   }
> > +
> > return 0;
> >   }
> >
> >   static int at91_wdt_stop(struct watchdog_device *wdd)
> >   {
> > -   /* The watchdog timer hardware can not be stopped... */
> > +   struct at91wdt *wdt = to_wdt(wdd);
> > +   u32 reg;
> > +
> > +   if (wdt->drv_data->mr_writable) {
> > +   reg = wdt_read(wdt, AT91_WDT_MR);
> > +   reg |= AT91_WDT_WDDIS;
> > +   wdt_write(wdt, AT91_WDT_MR, reg);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static int at91_wdt_ping(struct watchdog_device *wdd) {
> > +   struct at91wdt *wdt = to_wdt(wdd);
> > +
> > +   wdt_write(wdt, AT91_WDT_CR, AT91_WDT_KEY |
> AT91_WDT_WDRSTT);
> > +
> > return 0;
> >   }
> >
> >   static int at91_wdt_set_timeout(struct watchdog_device *wdd, unsigned int
> new_timeout)
> >   {
> > -   wdd->timeout = new_timeout;
> > -   return at91_wdt_start(wdd);
> > +   struct at91wdt *wdt = to_wdt(wdd);
> > +   u32 reg, timeout;
> > +
> > +   if 

Re: [PATCH v2 0/22] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, July 28, 2015 03:19:31 PM Tomeu Vizoso wrote:
> Hello,
> 
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
> 
> While reading the thread [1] that Alexander Holler started with his
> series to make probing order deterministic, it occurred to me that it
> should be possible to achieve the same by probing devices as they are
> referenced by other devices.
> 
> This basically reuses the information that is already implicit in the
> probe() implementations, saving us from refactoring existing drivers or
> adding information to DTBs.
> 
> During review of v1 of this series Linus Walleij suggested that it
> should be the device driver core to make sure that dependencies are
> ready before probing a device. I gave this idea a try [2] but Mark Brown
> pointed out to the logic duplication between the resource acquisition
> and dependency discovery code paths (though I think it's fairly minor).
> 
> To address that code duplication I experimented with Arnd's devm_probe
> [3] concept of having drivers declare their dependencies instead of
> acquiring them during probe, and while it worked [4], I don't think we
> end up winning anything when compared to just probing devices on-demand
> from resource getters.
> 
> One remaining objection is to the "sprinkling" of calls to
> fwnode_ensure_device() in the resource getters of each subsystem, but I
> think it's the right thing to do given that the storage of resources is
> currently subsystem-specific.
> 
> We could avoid the above by moving resource storage into the core, but I
> don't think there's a compelling case for that.
> 
> I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
> and these patches were enough to eliminate all the deferred probes
> (except one in PandaBoard because omap_dma_system doesn't have a
> firmware node as of yet).
> 
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.

Can you trim your CC list somewhat, please?

I'm definitely going to look at this, but not before then next week.
Sorry about that.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: shmobile: r8a7794: add PFC DT support

[Simon Horman]

On Tue, Jul 28, 2015 at 03:45:47PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 2/15/2015 8:02 PM, Sergei Shtylyov wrote:
> 
> >Define the generic R8A7794 part of the PFC device node.
> 
> >Based on original patch by Hisashi Nakamura
> >.
> 
> >Signed-off-by: Sergei Shtylyov 
> 
> Acked-by: by: Geert Uytterhoeven 
> 
> >>>Thanks, I have queued this up.
> 
> >>Sorry, I was a bit hasty here.
> 
> >>Could you repost this once the driver has been accepted?
> 
> >I don't expect it to change, but OK.
> 
>Sent v2 last night but overlooked Geert's ACK to v1. Should I resend?

No need, I have queued up v2 with Geert's ACK.
Thanks for bringing the ACK to my attention,
I would surely have missed it otherwise.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: shmobile: r8a7794: add PFC DT support

[Simon Horman]

On Tue, Jul 28, 2015 at 01:29:31AM +0300, Sergei Shtylyov wrote:
> Define the generic R8A7794 part of the PFC device node.
> 
> Based on original patch by Hisashi Nakamura .
> 
> Signed-off-by: Sergei Shtylyov 

Thanks, I have queued this up.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] iio: mma8452: add devicetree property to allow all pin wirings

[Martin Kepplinger]

Am 2015-07-28 um 11:28 schrieb Mark Rutland:
> On Tue, Jul 28, 2015 at 10:11:29AM +0100, Martin Kepplinger wrote:
>>
>>
>> On 2015-07-27 19:33, Mark Rutland wrote:
>>> On Mon, Jul 27, 2015 at 03:37:48PM +0100, Martin Kepplinger wrote:
 Am 2015-07-27 um 16:23 schrieb Mark Rutland:
> On Mon, Jul 27, 2015 at 03:08:15PM +0100, Martin Kepplinger wrote:
>> For the devices supported by the mma8452 driver, two interrupt pins are
>> available to route the interrupt signals to. By default INT1 is assumed.
>>
>> This adds a bitmask DT property for users to configure interrupt sources
>> for INT2, if that is the wired interrupt pin for them.
>
> This sounds like configureation rather than a HW property. Why does this
> need to be in the DT?

 It's a hardware property of the board that uses the device. There might
 be boards that connect just one of them at random, which is the reason
 for this DT property. There also might be exotic users who will want
 to use both pins to route different interrupt sources to (not yet
 supported, but no problem with such a bitmask).
>>>
>>> Ok, so I'm somewhat confused as to what the hardware looks like and what
>>> this means.
>>>
>>> Could you elaborate on how INT1 and INT2 are used? It looks like they're
>>> used as output pins, and so interrupt-names would seem appropriate for
>>> describing the combination which is wired up.
>>
>> They are just the chip's two possible interrupt lines for us to get
>> notified about event.
> 
> Ok. So that matches my understanding.
> 
>> You build a board, you use one of these 4 chips, wiring up just one of
>> the 2 interrupt pins. By far most people won't ever need both pins.
>>
>> DT describes your hardware, right? So you describe how you built your
>> board (wired the accelerometer chip) with this DT property.
> 
> Ok.
> 
>>> w.r.t. configuring the choice of output(s), that sounds like a runtime
>>> decision rather than something which needs to be configured statically.
>>
>> This won't be useful during runtime. (De)activating events is what you
>> do in iio sysfs.
>>
>> Even in the rare case (maybe supported in the future) when you want one
>> interrupt source on one pin and another source on the other pin, that
>> describes your hardware. You wire, say, data-ready to Linux and
>> motion-detection to some strange alarm system. When you change your
>> hardware (say, use Linux for both pins), I think it would justify
>> changing a DT property.
> 
> In that case you would need additional properties anyway.
> 
>> Btw, we are talking about very theoretical stuff here. For now (and even
>> possibly forever) we just don't ever want to break a DT propery we
>> introduce here, thus the bitmask.
> 
> I don't think you need the bitmask.
> 
> I think all you need is interrupt-names, e.g.
> 
> dev1 {
>   /* both wired up */
>   interrupts = <&some_ic 0 47>, <&some_ic 5 62>;
>   interrupt-names = "INT1", "INT2";
> }
> 
> dev2 {
>   /* only INT2 wired up */
>   interrupts = <&some_ic 3 96>;
>   interrupt-names = "INT2";
> }
> 
> You can figure out which interrupts are wired up by trying to acquire
> them by name, then falling back to acquiting an anonymouos interrupt
> (assuming it's INT1) to keep compatible with existing DTBs. You can
> choose which to use arbitrarily, try to load balance, or whatever you'd
> like.
> 
> If it's later necessary to route some interrupts to another device,
> additional properties can be added to accomodate that. We already know
> that the bitmask alone is not sufficient for that case.
> 

Yes, this sounds reasonable indeed. I like the idea. I'm sorry I won't
rewrite patch 8/8 now. Relocation and a lot to do before holidays. I'll
be happy to write and test this properly in one month from now, if not
done by somebody until then.

Until then, since patches 1-7 only introduce a bindings document, they
shouldn't be problematic for devicetree people.


So if Jonathan and IIO people find anybody for review, feel free to take
patches 1-7. In any case, there is direct register access via debugfs to
at least somehow make the driver work for everybody ;)

so long, thanks.
martin

> Thanks,
> Mark.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Stephen Boyd]

On 07/28, Viresh Kumar wrote:
> Cc'ing few people (whom I cc'd last time as well :)).
> 
> On 27-07-15, 16:20, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> > 
> > Signed-off-by: Lee Jones 
> > ---
> > 
> > Changelog:
> >  - None, new patch
> > 
> >  Documentation/devicetree/bindings/power/opp-st.txt | 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt 
> > b/Documentation/devicetree/bindings/power/opp-st.txt
> > new file mode 100644
> > index 000..6eb2a91
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/opp-st.txt
> > @@ -0,0 +1,76 @@
> > +STMicroelectronics OPP (Operating Performance Points) Bindings
> > +--
> > +
> > +Frequency Scaling only
> > +--
> > +
> > +Located in CPU's node:
> > +
> > +- operating-points : [See: ./opp.txt]
> > +
> > +Example [safe]
> > +--
> > +
> > +cpus {
> > +   cpu@0 {
> > +/* kHz uV   */
> > +   operating-points = <150 0
> > +   120 0
> > +   80  0
> > +   50  0>;
> > +   };
> > +};
> > +
> > +Dynamic Voltage and Frequency Scaling (DVFS)
> > +
> > +
> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> > +
> > +- compatible   : Should be "operating-points-v2-sti"
> > +- opp{1..N}: Each 'oppX' subnode will contain the 
> > following properties:
> 
> Or should we mention:
> - opp{1..N}   : Each 'oppX' subnode shall contain below properties,
>   over what ./opp.txt defines:
> 
> ?
> 
> 
> > + - opp-hz  : CPU frequency [Hz] for this OPP [See: ./opp.txt]
> > + - st,avs  : List of available voltages [uV] indexed by process 
> > code
> > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL]
> > + - st,substrate: Substrate version this OPP is suitable for 
> > [0xFF means ALL]
> > +- st,syscfg: Phandle to Major number register
> > +   First cell: offset to major number
> > +- st,syscfg-eng: Phandle to Minor number and Pcode registers
> > +   First cell: offset to process code
> > +   Second cell: offset to minor number
> > +
> > +WARNING: The opp{1..N} nodes will be provided by the bootloader.  Do not 
> > attempt to
> > +artificially synthesise the opp{1..N} nodes or any of their 
> > descendants.
> > +They are very platform specific and may damage the hardware if created
> > +incorrectly.
> > +
> > +Example [unsafe]
> > +
> > +
> > +cpus {
> > +   cpu@0 {
> > +   operating-points-v2 = <&cpu0_opp_list>;
> > +   };
> > +};
> > +
> > +/*  */
> > +/* # WARNING: Do not attempt to copy/replicate this node, # */
> > +/* #  it is only to be supplied by the bootloader !!! # */
> > +/*  */
> > +cpu0-opp-list {
> > +   compatible  = "operating-points-v2-sti";
> > +   st,syscfg   = <&syscfg [major_offset]>;
> > +   st,syscfg-eng   = <&syscfg_eng [pcode_offset] [minor_offset]>;
> > +
> > +   opp0 {
> > +   opp-hz  = <12>;
> > +   st,avs  = <1110 1150 1100 1080 1040 1020 980 930>;
> > +   st,substrate= <0xff>;
> > +   st,cuts = <0xff>;
> > +   };
> > +   opp1 {
> > +   opp-hz  = <15>;
> > +   st,avs  = <1200 1200 1200 1200 1170 1140 1100 1070>;
> > +   st,substrate= <0xff>;
> > +   st,cuts = <0x2>;
> > +   };
> > +};
> 
> I don't see more problems here, unless we can move some of this to the
> generic bindings.
> 
> @Rob/Stephen: Please respond before it is late :)
> 

It's interesting to have vendor specific properties like avs,
cuts, and substrate. That could replace our planned usage of the
opp-names property where we encode similar information (speed
bin, revision, etc.) into a string that we look for.

So I wonder why the avs/cut/substrate information can't be
encoded into the opp name? That would make these properties
obsolete, given that all they're used for is to pick out the
correct OPP?

-- 
Qualcomm Innovation Center, Inc. is a member of 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Sören Brinkmann]

On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote:
> Hi Sören,
> 
> thanks for your feedback.
> 
> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
>  wrote:
> > Hi Moritz,
> >
> > On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
> >> Signed-off-by: Moritz Fischer 
> >> ---
> >>  Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 
> >> +
> >>  1 file changed, 13 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt 
> >> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> new file mode 100644
> >> index 000..ac4499e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> @@ -0,0 +1,13 @@
> >> +Xilinx Zynq PL Reset Manager
> >> +
> >> +Required properties:
> >> +- compatible: "xlnx,zynq-reset-pl"
> >> +- syscon <&slcr>;
> >> +- #reset-cells: 1
> >> +
> >> +Example:
> >> + rstc: rstc@240 {
> >> + #reset-cells = <1>;
> >> + compatible = "xlnx,zynq-reset-pl";
> >> + syscon = <&slcr>;
> >> + };
> >
> > I think you also have to add the outputs and make them part of the
> > binding. Otherwise you'd have to read the implementation to find
> > out what device should be hooked up to which output of the reset-controller.
> 
> Is something like this what you had in mind? I had that prepared for
> the next round of patches:
> 
> Reset outputs:
>  0  : soft reset
>  32 : ddr reset
>  64 : topsw reset
>  96 : dmac reset
>  128: usb0 reset
>  129: usb1 reset
>  160: gem0 reset
>  161: gem1 reset
>  164: gem0 rx reset
>  165: gem1 rx reset
>  166: gem0 ref reset
>  167: gem1 ref reset
>  192: sdio0 reset
>  193: sdio1 reset
>  196: sdio0 ref reset
>  197: sdio1 ref reset
>  224: spi0 reset
>  225: spi1 reset
>  226: spi0 ref reset
>  227: spi1 ref reset
>  256: can0 reset
>  257: can1 reset
>  258: can0 ref reset
>  259: can1 ref reset
>  288: i2c0 reset
>  289: i2c1 reset
>  320: uart0 reset
>  321: uart1 reset
>  322: uart0 ref reset
>  323: uart1 ref reset
>  352: gpio reset
>  384: lqspi reset
>  385: qspi ref reset
>  416: smc reset
>  417: smc ref reset
>  448: ocm reset
>  512: fpga0 out reset
>  513: fpga1 out reset
>  514: fpga2 out reset
>  515: fpga3 out reset
>  544: a9 reset 0
>  545: a9 reset 1
>  552: peri reset

Basically, yes. I guess the gaps are due to directly mapping this number
to bank and bit instead of doing some more complex mapping in between?
I'm not sure whether I like this :) I guess if a number is off the
driver would still toggle the addressed bit? I'm not sure, is it worth
to do some explicit mapping from logical outputs to a physical reset? It
seems it would be a little safer since it would be easy to check that
the addressed reset is valid and there wouldn't be any reserved/invalid
bits be toggled. Also, it would make the outputs in here a continuous
series of numbers without these gaps. Not sure though whether
it's worth the additional complexity in the implementation.

Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv7 0/2] Adding driver for Xilinx LogiCORE IP mailbox.

[Moritz Fischer]

Hi Jassi,

just a ping to see if you're waiting on me to fix things or if this is
good to go from your point of view,
and you're just waiting some time to give people more time to review.

Let me know if you want me to resend with Soeren's Acked-By

Cheers,

Moritz

On Tue, Jul 14, 2015 at 6:00 PM, Moritz Fischer
 wrote:
> Hi all,
>
> Thanks for hanging in there, hopefully the last round of review ...
>
> This patchset adds mailbox framework integration for the Xilinx LogiCORE IP
> mailbox.  The Xilinx LogiCORE IP mailbox is a fpga softcore that allows
> interprocessor communication between AXI4 stream / memory mapped
> processors.
>
> Cheers,
>
> Moritz
>
> Changes from v6:
> - As suggested by Jassi and Sören use #mbox-cells = <1>
>
> Changes from v5:
> - Fixed constness for ops struct
> - Removed redundant checks
> - Moved ops assignment
> - Removed MODULE_ALIAS
>
> Changes from v4:
> - Have separate mbox_ops structs for polling / irq mode
> - Moved clk handling to startup / shutdown
> - Embedded struct mbox_chan in struct xilinx_mbox
> - Fixed mbox-cells in devicetree documentation
> - Misc stylistic issues
>
> Changes from v3:
> - Stylistic changes
> - Changed reg size in dts to 0x100
>
> Changes from v2:
> - Fixed error condition for IRQ from >= 0 to > 0
> - Fixed clock enable
> - Cleaned up docs
>
> Changes from v1:
> - Added common clock framework support
> - Deal with IRQs that happend before driver load,
>   since HW will not let us know about them when we enable IRQs
>
> Changes from v0:
> - Several stylistic issues
> - Dropped superfluous intr_mode member
> - Really masking the IRQs on mailbox_shutdown
> - No longer using polling by accident in non-IRQ mode
> - Swapped doc and driver commits
>
>
> Moritz Fischer (2):
>   dts: Adding docs for Xilinx LogiCORE IP mailbox driver.
>   mailbox: Adding driver for Xilinx LogiCORE IP mailbox.
>
>  .../devicetree/bindings/mailbox/xilinx-mailbox.txt |  44 +++
>  MAINTAINERS|   7 +
>  drivers/mailbox/Kconfig|   7 +
>  drivers/mailbox/Makefile   |   2 +
>  drivers/mailbox/mailbox-xilinx.c   | 367 
> +
>  5 files changed, 427 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>  create mode 100644 drivers/mailbox/mailbox-xilinx.c
>
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND] ARM: shmobile: silk: add Ether DT support

[Sergei Shtylyov]

Define the SILK board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.

Based on the original patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20150728-v4.2-rc4' tag of Simon
Horman's 'renesas.git' repo.  It depends on just posted SILK board initial DT
patch in order to apply and on R8A7794 PFC DT patch posted yesterday in order
to compile.

 arch/arm/boot/dts/r8a7794-silk.dts |   28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -22,7 +22,7 @@
};
 
chosen {
-   bootargs = "ignore_loglevel";
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = &scif2;
};
 
@@ -41,6 +41,16 @@
renesas,groups = "scif2_data";
renesas,function = "scif2";
};
+
+   ether_pins: ether {
+   renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
+   renesas,function = "eth";
+   };
+
+   phy1_pins: phy1 {
+   renesas,groups = "intc_irq8";
+   renesas,function = "intc";
+   };
 };
 
 &scif2 {
@@ -49,3 +59,19 @@
 
status = "okay";
 };
+
+ðer {
+   pinctrl-0 = <ðer_pins &phy1_pins>;
+   pinctrl-names = "default";
+
+   phy-handle = <&phy1>;
+   renesas,ether-link-active-low;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   interrupt-parent = <&irqc0>;
+   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+   micrel,led-mode = <1>;
+   };
+};

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] ARM: shmobile: silk: initial device tree

[Sergei Shtylyov]

Add the initial device  tree for the R8A7794 SoC based SILK low cost board.
SCIF2 serial port support is included, so that the serial console can work.

Based on the original patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
This patch is against the 'renesas-devel-20150728-v4.2-rc4' tag of Simon
Horman's 'renesas.git' repo. It requires R8A7794 PFC DT patch posted yesterday
in order to compile.

Changes in version 3:
- refreshed the patch;
- reformatted the changelog.

Changes in version 2:
- removed "console=" parameter from the kernel command line;
- added PFC node with SCIF2 pins subnode and referred it from the SCIF2 node;
- rebased the patch
- mentioned the origin of patch in the changelog.

 arch/arm/boot/dts/Makefile |1 
 arch/arm/boot/dts/r8a7794-silk.dts |   51 +
 2 files changed, 52 insertions(+)

Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -515,6 +515,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a7791-koelsch.dtb \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
+   r8a7794-silk.dtb \
sh73a0-kzm9g.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_arria5_socdk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,51 @@
+/*
+ * Device Tree Source for the SILK board
+ *
+ * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2014-2015 Renesas Solutions Corp.
+ * Copyright (C) 2014-2015 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7794.dtsi"
+
+/ {
+   model = "SILK";
+   compatible = "renesas,silk", "renesas,r8a7794";
+
+   aliases {
+   serial0 = &scif2;
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel";
+   stdout-path = &scif2;
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x4000>;
+   };
+};
+
+&extal_clk {
+   clock-frequency = <2000>;
+};
+
+&pfc {
+   scif2_pins: serial2 {
+   renesas,groups = "scif2_data";
+   renesas,function = "scif2";
+   };
+};
+
+&scif2 {
+   pinctrl-0 = <&scif2_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+};

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/6] mailbox: Add support for ST's Mailbox IP

[Paul Bolle]

On ma, 2015-07-27 at 10:44 +0100, Lee Jones wrote:
> --- /dev/null
> +++ b/drivers/mailbox/mailbox-sti.c

> +static int sti_mbox_probe(struct platform_device *pdev)
> +{
> + [...]
> +
> + match = of_match_device(sti_mailbox_match, &pdev->dev);
> + if (!match) {
> + dev_err(&pdev->dev, "No configuration found\n");
> + return -ENODEV;
> + }
> + pdev->dev.platform_data = (struct sti_mbox_pdata *) match->data;
> +
> + [...]
> +}

> +static struct platform_driver sti_mbox_driver = {
> + .probe = sti_mbox_probe,
> + .remove = sti_mbox_remove,
> + .driver = {
> + .name = "sti-mailbox",
> + .of_match_table = sti_mailbox_match,
> + },
> +};
> +module_platform_driver(sti_mbox_driver);

> +MODULE_ALIAS("platform:mailbox-sti");

It seems this alias is only useful if there's a corresponding struct
platform_device with a "mailbox-sti" .name. I couldn't spot that
platform_device.

Besides, if I read sti_max_probe() correctly, without OF support loading
this module won't accomplish much. So what would another way of
autoloading this module buy you?

Thanks,


Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] improve binding for linux,wdt-gpio

[Guenter Roeck]

Hi Uwe,

On Tue, Jul 28, 2015 at 10:33:48PM +0200, Uwe Kleine-König wrote:
> This is just a suggestion up to now, I don't have any code yet to share.
> 
> Apart from minor rewording to make the document easier to understand and
> less ambiguous the relevant changes are:
> 
>  - add an "enable-gpio" property.
>I admit the device I'm currently working with doesn't have this.
>Still I imagine this to be a common hardware property. I added it
>mainly to demonstrate the shortcomings of the existing binding.
>  - rename "gpios" to "trigger-gpio"
>This is more descriptive. And given there is "enable-gpio" now, too,
>using plain "gpios" seems wrong.
>  - deprecate always-running
>Apart from the description describing the driver behaviour and not
>the device property, always-running only seems to make sense in
>combination with hw_algo = "level" and in reality should only
>invalidate the sentence: "The watchdog timer is disabled when GPIO is
>left floating or connected to a three-state buffer."

always-running is meant to indicate that the watchdog can not be stopped
(meaning a timer has to be used to send keepalives while the watchdog
device is closed). The documentation specifically states that.

"If the watchdog timer cannot be disabled ..."

How would you express that condition without always-running or a similar
attribute ?  I am also not sure how that relates to hw_algo; I thought
those properties are orthogonal.

Of course, 'always-running' _may_ describe driver behavior, but that doesn't
have to be the case. There are lots of watchdogs out there which can not be
stopped. Some of them run all the time, others can not be stopped once started.

That gets us into the rat-hole of arguing if property X describes driver
behavior or the hardware, and of rejecting properties because they may
be driver descriptions in some use cases (because 'always-running' can
be set even if the hardware doesn't mandate it, making it driver behavior).
I'd rather not go there.

>With this semantic using a property "disable-on-tri-state" sounds
>more sensible. And note that even the following would make sense
>hardware-wise, while the device tree looks stupid:
> 
>   watchdog {
>   compatible = "linux,wdt-gpio";
>   trigger-gpio = ...;
>   hw_algo = "toggle";
>   always-running;
>   enable-gpio = ...;
>   };
> 
>(i.e. always-running, but disable possible by a dedicated gpio.)
> 
It might also mean that _enable_ is possible with a dedicated gpio.
That doesn't mean it can be stopped once started. Again, there are lots
of watchdogs out there which can be enabled/started but not stopped.

> I'm aware that using ...-gpios is more common than ...-gpio. I don't
> feel strong here, but as only a single gpio makes sense here, having
> -gpios seems wrong.
> 
Documentation/devicetree/bindings/gpio/gpio.txt states that gpio pin
references should be named -gpios. It even lists examples such as

enable-gpios = <&gpio2 2>;

I thought this was a hard rule, and I seem to recall requests to change
something-gpio to something-spios, but I may be wrong.

Thanks,
Guenter

> Also I considered renaming hw_margin_ms and hw_algo to use - instead of
> _. Doing this might even ease to implement the changes above in a
> compatible way. I.e. assume the watchdog can be disabled by tristating
> the gpio if the description uses underscores instead of hyphen.
> 

> Feedback very welcome!
> 
> Best regards
> Uwe
> 
> ---
>  .../devicetree/bindings/watchdog/gpio-wdt.txt  | 37 
> ++
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
> index 198794963786..ceb1a5f95f44 100644
> --- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
> @@ -2,27 +2,36 @@
>  
>  Required Properties:
>  - compatible: Should contain "linux,wdt-gpio".
> -- gpios: From common gpio binding; gpio connection to WDT reset pin.
> -- hw_algo: The algorithm used by the driver. Should be one of the
> +- trigger-gpio: reference to the gpio connected to watchdog's input pin
> +  (typically called WDI).
> +- hw_algo: The algorithm used by the device. Should be one of the
>following values:
> -  - toggle: Either a high-to-low or a low-to-high transition clears
> -the WDT counter. The watchdog timer is disabled when GPIO is
> -left floating or connected to a three-state buffer.
> -  - level: Low or high level starts counting WDT timeout,
> -the opposite level disables the WDT. Active level is determined
> -by the GPIO flags.
> -- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
> +  - toggle: Both a high-to-low and a low-to-high transition clear
> +the watchdog counter.
> +  - level: Low or high leve

Re: [PATCH v2 3/9] arm: twr-k70f120m: clock driver for Kinetis SoC

[Paul Osmialowski]

Hi Mike,

My trouble is that now I'm dealing with two conradictory opinions on how 
this driver should be written. The one you presented in your previous post 
assumes that there will be a header file with defines shared between the 
clock driver and DTS, also with clock gating details hidden behind some 
additional level of indirection, e.g.:

clocks = <&sim SIM_SCGC4_UART1_CLK>;

Note that I've been through this at the very beginning, though the names 
I used have been bit different, e.g.:

#define KINETIS_CG_UART1   KINETIS_MKCG(3, 11) /* SIM_SCGC4[11] */

This was rejected with a comment by Arnd:

Instead of using a triple indirection here, just put the tuples
in the DT directly using #clock-cells=<2>, and get rid of both this
header file and the dt-bindings/clock/kinetis-mcg.h file.

So I dropped all of these includes and started to use magic numbers (as 
you put it). Now I need to go one way or another or even go the third way: 
extend #clock-cells to <3> and address it like: <&sim parent_clock_id 
scgc_register_number bit_index_number>.

Reading your previous post I'm starting to feel that it would bring me 
closer to final acceptance if I stick to what you proposed in that post 
(I'm really grateful to you for writting so huge chunk of DTS for me!), so 
I'll probably adopt that.

You're right about my "get things up and running" attitude - currently I 
want to develop things extensively (cover as much subsystems as 
possible) and then at some stage switch to intensive approach. This board 
is a somewhat huge monster (for a Cortex-M4 SoC) and there will be a lot 
of coding opportunity in this field in the future.

Thanks,
Paul

On Tue, 28 Jul 2015, Michael Turquette wrote:

> Quoting Paul Osmialowski (2015-07-26 13:24:08)
> > Hi Mike,
> > 
> > Thank you for spending time on this and pointing me into the right 
> > direction. I'm wondering about going even further with it. Assuming that I 
> 
> Hi Paul,
> 
> No problem! And thanks for the quick turnaround on your patches so far.
> 
> > know everything about my board, I can skip run-time discovery phase (note 
> > that the original driver was designed for other Kinetis-based boards too) 
> > and move everything into DTS, somewhat like this:
> > 
> > / {
> > osc0: clock {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <5000>;
> > };
> > 
> > osc1: clock {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <1200>;
> > };
> > 
> > rtc: clock {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <32768>;
> > };
> > 
> > mcgout: clock {
> > compatible = "fixed-factor-clock";
> > #clock-cells = <0>;
> > clocks = <&osc0>;
> > clock-mult = <12>;
> > clock-div = <5>;
> > };
> 
> I think this is a step backwards.
> 
> Did you look at the qcom clock binding and read the email where I
> detailed how that binding works?
> 
> The point of that type of binding is to not shove per-clock data into
> DT, but instead to declare every clock controller IP block (e.g. the
> device) as well as every board-level clock (e.g. as osc that feeds into
> your mcu). Once these "clock providers" are enumerated in DT, then we
> create linkage between the clock providers and the clock consumers by
> using phandles + an index. Linux device drivers tap into this by using
> clk_get() and using the "clock-names" property from DT.
> 
> Put another way: we mostly use DT to model "devices". That is open to
> interpretation for but for clock-related stuff we typically interpret
> the clock controller as the device, not the individual clock outputs
> coming out of the controller.
> 
> Note that a clock controller IP block may be both a provider and a
> consumer.  I/O controllers are a very common type of consumer (e.g. USB
> host controller, MMC controller, GPU, etc).
> 
> Additionally, from my reading of the reference manual, mcgout is defined
> as:
> 
> """
> MCG output of either IRC, MCGFLLCLK MCGPLL0CLK,
> MCGPLL1CLK, or MCG's external reference clock that
> sources the core, system, bus, FlexBus, and flash clock. It is
> also an option for the debug trace clock.
> """
> 
> So why is it listed here as a fixed-factor clock? Is it not a
> multiplexer? Also, why is it listed here at all? Please take another
> look at the qcom binding example I linked to in my previous mail.
> 
> > 
> > core: clock {
> > compatible = "fixed-factor-clock";
> > #clock-cells = <0>;
> > clocks = <&mcgout>;
> > clock-mult = <1>;
> > clock-div = <1>;
> > };
> > 
> > bus: clock {
> > compatible = "fixed-factor-clock";

[RFC] improve binding for linux,wdt-gpio

[Uwe Kleine-König]

This is just a suggestion up to now, I don't have any code yet to share.

Apart from minor rewording to make the document easier to understand and
less ambiguous the relevant changes are:

 - add an "enable-gpio" property.
   I admit the device I'm currently working with doesn't have this.
   Still I imagine this to be a common hardware property. I added it
   mainly to demonstrate the shortcomings of the existing binding.
 - rename "gpios" to "trigger-gpio"
   This is more descriptive. And given there is "enable-gpio" now, too,
   using plain "gpios" seems wrong.
 - deprecate always-running
   Apart from the description describing the driver behaviour and not
   the device property, always-running only seems to make sense in
   combination with hw_algo = "level" and in reality should only
   invalidate the sentence: "The watchdog timer is disabled when GPIO is
   left floating or connected to a three-state buffer."
   With this semantic using a property "disable-on-tri-state" sounds
   more sensible. And note that even the following would make sense
   hardware-wise, while the device tree looks stupid:

watchdog {
compatible = "linux,wdt-gpio";
trigger-gpio = ...;
hw_algo = "toggle";
always-running;
enable-gpio = ...;
};

   (i.e. always-running, but disable possible by a dedicated gpio.)

I'm aware that using ...-gpios is more common than ...-gpio. I don't
feel strong here, but as only a single gpio makes sense here, having
-gpios seems wrong.

Also I considered renaming hw_margin_ms and hw_algo to use - instead of
_. Doing this might even ease to implement the changes above in a
compatible way. I.e. assume the watchdog can be disabled by tristating
the gpio if the description uses underscores instead of hyphen.

Feedback very welcome!

Best regards
Uwe

---
 .../devicetree/bindings/watchdog/gpio-wdt.txt  | 37 ++
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
index 198794963786..ceb1a5f95f44 100644
--- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
@@ -2,27 +2,36 @@
 
 Required Properties:
 - compatible: Should contain "linux,wdt-gpio".
-- gpios: From common gpio binding; gpio connection to WDT reset pin.
-- hw_algo: The algorithm used by the driver. Should be one of the
+- trigger-gpio: reference to the gpio connected to watchdog's input pin
+  (typically called WDI).
+- hw_algo: The algorithm used by the device. Should be one of the
   following values:
-  - toggle: Either a high-to-low or a low-to-high transition clears
-the WDT counter. The watchdog timer is disabled when GPIO is
-left floating or connected to a three-state buffer.
-  - level: Low or high level starts counting WDT timeout,
-the opposite level disables the WDT. Active level is determined
-by the GPIO flags.
-- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
+  - toggle: Both a high-to-low and a low-to-high transition clear
+the watchdog counter.
+  - level: Low or high level starts counting watchdog timeout,
+the opposite level disables the watchdog. Active level is determined
+by the GPIO flags of the trigger-gpio (with active meaning the watchdog is
+enabled).
+- hw_margin_ms: Maximum time to reset watchdog circuit in milliseconds.
 
 Optional Properties:
-- always-running: If the watchdog timer cannot be disabled, add this flag to
-  have the driver keep toggling the signal without a client. It will only cease
-  to toggle the signal when the device is open and the timeout elapsed.
+- enable-gpio: Reference to a gpio that when inactive stops the watchdog.
+- disable-on-tri-state: property that signals that the watchdog can be stopped
+  by setting the trigger-gpio to tri-state.
+
+Deprecated Properties:
+- always-running: This property signals the watchdog timer cannot be disabled.
+  Without this property the watchdog is expected to turn off for hw_algo=toggle
+  watchdogs when the gpio is set to tri-state.
+  Don't use it for new device descriptions as it is misleading in the presence
+  of an enable-gpio.
+- gpios: deprecated alias of trigger-gpio
 
 Example:
watchdog: watchdog {
/* ADM706 */
-   compatible = "linux,wdt-gpio";
-   gpios = <&gpio3 9 GPIO_ACTIVE_LOW>;
+   compatible = "adi,adm706", "linux,wdt-gpio";
+   trigger-gpio = <&gpio3 9 GPIO_ACTIVE_LOW>;
hw_algo = "toggle";
hw_margin_ms = <1600>;
};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] ARM: dts: ifc6410: add real regulators for sdcc nodes.

[Andy Gross]

On Tue, Jul 28, 2015 at 09:12:58AM +0100, Srinivas Kandagatla wrote:
> This patch adds real regulators for all the three sdcc nodes.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---

Applied.  Thanks

-- 
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] ARM: dts: qs600: Add real regulators to sdcc

[Andy Gross]

On Tue, Jul 28, 2015 at 09:13:05AM +0100, Srinivas Kandagatla wrote:
> This patch adds real regulators to sdcc nodes.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---

Applied.  Thanks

-- 
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] ARM: dts: apq8064: remove temporary fixed regulator for mmc

[Andy Gross]

On Tue, Jul 28, 2015 at 09:12:51AM +0100, Srinivas Kandagatla wrote:
> This patch removes temporary fixed regluator use for mmc.
> Board files should use the regulators which are wiredup appropriately.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---

Applied.  Thanks!

-- 
Qualcomm Innovation Center, Inc.
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

On Tue, Jul 28 2015 at 13:38 -0600, Lina Iyer wrote:

Hello,

I am looking to find a way to uniquely identify a device in the driver.
Here is an example -

big: power-controller@1 {


@1 is probably not a good example here. @1 could as well be a SoC
specific phy address that the driver may not really care about.


compatible = "soc,foo";
...
};

little: power-controller@2 {
compatible = "soc,foo";
...
};


In the driver for the power-controller foo.c, would like to do -

struct xyz {
const char *name;
...
};

static struct xyz a = {
.name = "big"; // To be associated with big device
...
};

static struct xyz b = {
.name = "little"; // To be associated with little device
...
};

What would be the best way to associate the power-controller devices 'big'
and 'little' with 'a' and 'b' respectively? A string comparison would be
ideal but possibly can work with other ways.

I could think of adding compatibles to achieve this, but was hoping to
find something more elegant and appropriate. Or, is compatible the
recommended way to uniquely identify devices by the driver?

Thanks,
Lina

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How-to: Uniquely identify a DT node in the driver?

[Lina Iyer]

Hello,

I am looking to find a way to uniquely identify a device in the driver.
Here is an example -

big: power-controller@1 {
compatible = "soc,foo";
...
};

little: power-controller@2 {
compatible = "soc,foo";
...
};


In the driver for the power-controller foo.c, would like to do -

struct xyz {
const char *name;
...
};

static struct xyz a = {
.name = "big"; // To be associated with big device
...
};

static struct xyz b = {
.name = "little"; // To be associated with little device
...
};

What would be the best way to associate the power-controller devices 'big'
and 'little' with 'a' and 'b' respectively? A string comparison would be
ideal but possibly can work with other ways.

I could think of adding compatibles to achieve this, but was hoping to
find something more elegant and appropriate. Or, is compatible the
recommended way to uniquely identify devices by the driver?

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mmc: sunxi: Don't start commands while the card is busy

[Arend van Spriel]

On 07/21/2015 02:15 PM, Ulf Hansson wrote:

On 10 July 2015 at 17:14, Hans de Goede  wrote:

Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by it starting new commands while
the card signals that it is still busy processing a previous command.


Which are those commands? Or more interesting, which response types do
these commands expect?
I don't think this is a sunxi specific issue, I have seen similar
issues for other host controllers.


Indeed. A similar fix was needed for dw_mmc host controller.


I am thinking that perhaps this should be managed by the mmc core
instead of local hacks to sunxi. Potentially we could make the core to
invoke the already existing host_ops->card_busy() callback when
needed...


The problem here is that there are a number of host controllers out 
there not implementing that callback. That may be because the hardware 
is dealing properly with busy signalling, but I would not bet on that.


Regards,
Arend


Within this context, could I ask whether you controller supports IRQ
based HW-busy detection? Or you need polling of the status register?



This commit fixes this, thereby fixing the wifi reliability issues on
the Cubietruck and other sunxi boards using sdio wifi.

Reported-by: Eugene K 
Suggested-by: Eugene K 
Cc: Eugene K 
Cc: Arend van Spriel 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Properly accredit Eugene K for coming up with the fix for this
---
  drivers/mmc/host/sunxi-mmc.c | 32 
  1 file changed, 32 insertions(+)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..daa90b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -289,6 +289,24 @@ static int sunxi_mmc_init_host(struct mmc_host *mmc)
 return 0;
  }

+/* Wait for card to report ready before starting a new cmd */
+static int sunxi_mmc_wait_card_ready(struct sunxi_mmc_host *host)
+{
+   unsigned long expire = jiffies + msecs_to_jiffies(500);
+   u32 rval;
+
+   do {
+   rval = mmc_readl(host, REG_STAS);
+   } while (time_before(jiffies, expire) && (rval & SDXC_CARD_DATA_BUSY));
+
+   if (rval & SDXC_CARD_DATA_BUSY) {
+   dev_err(mmc_dev(host->mmc), "Error R1 ready timeout\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
  static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host,
 struct mmc_data *data)
  {
@@ -383,6 +401,8 @@ static void sunxi_mmc_send_manual_stop(struct 
sunxi_mmc_host *host,
 u32 arg, cmd_val, ri;
 unsigned long expire = jiffies + msecs_to_jiffies(1000);

+   sunxi_mmc_wait_card_ready(host);
+
 cmd_val = SDXC_START | SDXC_RESP_EXPIRE |
   SDXC_STOP_ABORT_CMD | SDXC_CHECK_RESPONSE_CRC;

@@ -597,6 +617,11 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host 
*host, u32 oclk_en)
  {
 unsigned long expire = jiffies + msecs_to_jiffies(250);
 u32 rval;
+   int ret;
+
+   ret = sunxi_mmc_wait_card_ready(host);
+   if (ret)
+   return ret;

 rval = mmc_readl(host, REG_CLKCR);
 rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
@@ -785,6 +810,13 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 return;
 }

+   ret = sunxi_mmc_wait_card_ready(host);
+   if (ret) {
+   mrq->cmd->error = ret;
+   mmc_request_done(mmc, mrq);
+   return;
+   }
+
 if (data) {
 ret = sunxi_mmc_map_dma(host, data);
 if (ret < 0) {
--
2.4.3



Kind regards
Uffe



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Rob Clark]

On Tue, Jul 28, 2015 at 1:50 PM, Andreas Färber  wrote:
> Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
>> This patch adds LVDS panel for IFC6410.
>>
>> Signed-off-by: Rob Clark 
>> [Rob Clark: WIP patch]
>> Signed-off-by: Srinivas Kandagatla 
>> ---
>>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 
>> ++
>>  1 file changed, 66 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
>> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> index 1ab71f1..3bdac02 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
>> @@ -63,6 +63,12 @@
>>   qcom,switch-mode-frequency = <320>;
>>   };
>>
>> + pm8921_l2: l2 {
>> + regulator-min-microvolt = <120>;
>> + regulator-max-microvolt = <120>;
>> + bias-pull-down;
>> + };
>> +
>>   pm8921_l3: l3 {
>>   regulator-min-microvolt = <305>;
>>   regulator-max-microvolt = <330>;
>> @@ -96,6 +102,10 @@
>>   pm8921_lvs1: lvs1 {
>>   bias-pull-down;
>>   };
>> +
>> + pm8921_lvs7: lvs7 {
>> + bias-pull-down;
>> + };
>>   };
>>   };
>>
>> @@ -119,6 +129,41 @@
>>
>>   mdp: qcom,mdp@510 {
>>   status = "okay";
>> + qcom,lvds-panel = <&panel>;
>
> In my testing this broke/uglified HDMI output. Since not everyone has
> that LVDS panel attached, or might have a different panel type, I don't
> think the panel node belongs in the generic -ifc6410.dts file.
> I suggest you add an -ifc6410+inforce-lvds.dts or so for that.

I think the problem is not so much the dt bindings, since we have an
i2c/ddc where we can probe the panel's edid and see if it is actually
attached.

Probably panel_simple_probe() should attempt to read edid (or at least
first block) if ddc is not null, and return an error if that times
out.  That way we could tell at runtime whether the panel is there or
not.

BR,
-R

>> + lvds-vccs-3p3v-supply = <&ext_3p3v>;
>> + lvds-pll-vdda-supply = <&pm8921_l2>;
>> + lvds-vdda-supply = <&pm8921_lvs7>;
>> + };
>> +
>> + panel_3p3v: panel_3p3v {
>
> s/_/-/ ?
>
>> + compatible = "regulator-fixed";
>> + pinctrl-0 = <&disp_en_gpios>;
>> + pinctrl-names = "default";
>> + regulator-min-microvolt = <330>;
>> + regulator-max-microvolt = <330>;
>> + regulator-name = "panel_en_3p3v";
>> + regulator-type = "voltage";
>> + startup-delay-us = <0>;
>> + gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + regulator-boot-on;
>> + };
>> +
>> + backlight: backlight{
>> + pinctrl-0 = <&pwm_bl_gpios>;
>> + pinctrl-names = "default";
>> + compatible = "gpio-backlight";
>> + gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
>> + default-on;
>> + };
>> +
>> + panel: auo,b101xtn01 {
>
> panel: panel { ?
>
> Regards,
> Andreas
>
>> + status = "okay";
>> + compatible = "auo,b101xtn01";
>> +
>> + ddc-i2c-bus = <&i2c3>;
>> + backlight = <&backlight>;
>> + power-supply = <&panel_3p3v>;
>>   };
>>
>>   gsbi3: gsbi@1620 {
>> @@ -235,6 +280,27 @@
>>   pm8921_gpio: gpio@150 {
>>   pinctrl-names = "default";
>>   pinctrl-0 = <&wlan_default_gpios>;
>> +
>> + pwm_bl_gpios: pwm-bl-gpios {
>> + pios {
>> + pins = "gpio26";
>> + bias-disable;
>> + function = "normal";
>> + qcom,drive-strength = 
>> ;
>> + power-source = 
>> ;
>> + };
>> + };
>> +
>> + disp_en_gpios: di

Re: [PATCH v1 4/7] ARM: dts: apq8064: Add MDP support

[Rob Clark]

On Tue, Jul 28, 2015 at 1:31 PM, Andreas Färber  wrote:
> Hi,
>
> Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
>> From: Rob Clark 
>>
>> This patch adds MDP node to APQ8064 dt.
>>
>> Signed-off-by: Rob Clark 
>> [Srinivas Kandagatla] : updated with new style rpm regulators
>> Signed-off-by: Srinivas Kandagatla 
>> ---
>>  arch/arm/boot/dts/qcom-apq8064.dtsi | 87 
>> +
>>  1 file changed, 87 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
>> b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> index cba4ccb..7d2cc45 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> [...]
>> + gpu: qcom,adreno-3xx@430 {
>> + compatible = "qcom,adreno-3xx";
>
> I thought that wildcards were forbidden in compatible strings? Then this
> should be replaced by the real number, with a fallback to the first
> compatible one.

That would at least result in a big number of different compatibles,
esp. when you consider patchlevels of the different gpu's, which in
some cases needs to be known (esp. to userspace).. ie. a320.0 is not
the same thing as a320.2.  And the "real numbers" themselves are
confusing as a result of meddling by marketeers.. (ie. a305 vs a305b
vs a306.. which actually map to 305.x, 306.x and 307.x).  The current
scheme is easy to figure out how to setup the dt nodes, ie. easy to
know a3xx vs a4xx, and then copy the chipid property from downstream
dt, and everything works.

The current scheme groups by major gpu revision (ie. things where
basically all the registers change, ie. a3xx/a4xx/a5xx) with using
chipid and a few if statements here and there (kernel and userspace)
to deal with the intra-generation differences.  (The chipid is
something which in theory should be read out of a version register,
but seems that cannot be trusted.)

Not to mention that a3xx/a4xx/etc is how userspace code in mesa is partitioned.

BR,
-R

> And can't we just name the node qcom,adreno without version suffix?
>
> Regards,
> Andreas
>
>> + reg = <0x0430 0x2>;
>> + reg-names = "kgsl_3d0_reg_memory";
>> + interrupts = ;
>> + interrupt-names = "kgsl_3d0_irq";
>> + clock-names =
>> + "core_clk",
>> + "iface_clk",
>> + "mem_clk",
>> + "mem_iface_clk";
>> + clocks =
>> + <&mmcc GFX3D_CLK>,
>> + <&mmcc GFX3D_AHB_CLK>,
>> + <&mmcc GFX3D_AXI_CLK>,
>> + <&mmcc MMSS_IMEM_AHB_CLK>;
>> + qcom,chipid = <0x03020002>;
>> + qcom,gpu-pwrlevels {
>> + compatible = "qcom,gpu-pwrlevels";
>> + qcom,gpu-pwrlevel@0 {
>> + qcom,gpu-freq = <45000>;
>> + };
>> + qcom,gpu-pwrlevel@1 {
>> + qcom,gpu-freq = <2700>;
>> + };
>> + };
>> + };
>> +
>> + mdp: qcom,mdp@510 {
>> + compatible = "qcom,mdp";
>> + reg = <0x0510 0xf>;
>> + interrupts = ;
>> + connectors = <&hdmi>;
>> + gpus = <&gpu>;
>> + clock-names =
>> + "core_clk",
>> + "iface_clk",
>> + "lut_clk",
>> + "src_clk",
>> + "hdmi_clk",
>> + "mdp_clk",
>> + "mdp_axi_clk";
>> + clocks =
>> + <&mmcc MDP_CLK>,
>> + <&mmcc MDP_AHB_CLK>,
>> + <&mmcc MDP_LUT_CLK>,
>> + <&mmcc TV_SRC>,
>> + <&mmcc HDMI_TV_CLK>,
>> + <&mmcc MDP_TV_CLK>,
>> + <&mmcc MDP_AXI_CLK>;
>> + };
>>   };
>>  };
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
> 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: introduce of_has_named_irqs helper

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 11:16:44PM +0530, R, Vignesh wrote:
> Hi,
> 
> On 7/28/2015 10:53 PM, Dmitry Torokhov wrote:
> > On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
> >> Hi Dmitry,
> >>
> >> On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
> >>> On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
>  On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
> > On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
> >  wrote:
> >> Sometimes drivers might wish to transition from index-based to named
> >> interrupt descriptions. To aid in decision-making when parsing device
> >> tree data let's provide a helper that will indicate the scheme that is
> >> being used.
> >
> > Generally, IRQs are retrieved by platform_get_irq or
> > platform_get_irq_byname. Drivers should not call the of_irq_*
> > functions directly in most cases.
> 
>  That would be true for platform drivers, but not all devices are
>  platform devices.
> 
> >
> >>
> >> Signed-off-by: Dmitry Torokhov 
> >> ---
> >>
> >> The intent is to it like this:
> >>
> >> if (of_has_named_irqs(np) {
> >> /* Wake IRQ is optional */
> >> dev->wakeirq = of_irq_get_byname(np, "wakeup");
> >> if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
> >> return dev->wakeirq;
> >> }
> >
> > of_irq_get_byname will already return an error if the property is not
> > present. Use that.
> 
>  I do not like that it returns -EINVAL when property is missing, can we
>  change it to return -ENODATA (so it is the same as when the property is
>  defined but such name is missing)?
> >>>
> >>> So here is what I had in mind.. It is based on recent patch by Vignesh
> >>> for pixcir touchscreen, but I think it should be made available to all
> >>> I2C devices. Completely untested at the moment.
> >>>
> >>
> >> Thanks for the patch! I tested this on am437x-gp-evm and the
> >> suspend/resume worked fine (below patch + $subject patch). I was able to
> >> wake the system from low power state using touchscreen. Also verified
> >> module insertion and removal. One comment though, please see below.
> >>
> >>> ---
> >>>  drivers/i2c/i2c-core.c |   43 +--
> >>>  1 file changed, 37 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >>> index e6d4935..3971461 100644
> >>> --- a/drivers/i2c/i2c-core.c
> >>> +++ b/drivers/i2c/i2c-core.c
> >>> @@ -47,6 +47,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
> >>>  {
> >>>   struct i2c_client   *client = i2c_verify_client(dev);
> >>>   struct i2c_driver   *driver;
> >>> + int wakeirq = 0;
> >>>   int status;
> >>>  
> >>>   if (!client)
> >>> @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
> >>>   if (!client->irq) {
> >>>   int irq = -ENOENT;
> >>>  
> >>> - if (dev->of_node)
> >>> - irq = of_irq_get(dev->of_node, 0);
> >>> - else if (ACPI_COMPANION(dev))
> >>> + if (dev->of_node) {
> >>> + irq = of_has_named_irqs(dev->of_node) ?
> >>> + of_irq_get_byname(dev->of_node, "irq") :
> >>> + of_irq_get(dev->of_node, 0);
> >>> + } else if (ACPI_COMPANION(dev)) {
> >>>   irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> >>> -
> >>> + }
> >>>   if (irq == -EPROBE_DEFER)
> >>>   return irq;
> >>>   if (irq < 0)
> >>> @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
> >>>   client->irq = irq;
> >>>   }
> >>>  
> >>> + if (dev->of_node && of_has_named_irqs(dev->of_node)) {
> >>> + wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> >>> + if (wakeirq < 0) {
> >>> + if (wakeirq != -ENODATA)
> >>> + return wakeirq;
> >>> + wakeirq = 0;
> >>> + }
> >>> + }
> >>> +
> >>>   driver = to_i2c_driver(dev->driver);
> >>>   if (!driver->probe || !driver->id_table)
> >>>   return -ENODEV;diff --git 
> >>> a/drivers/input/touchscreen/pixcir_i2c_ts.c 
> >>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
> index 8f3e243a62bf..6bd1d1ca9883 100644
> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
> @@ -365,7 +365,6 @@ static int __maybe_unused
> pixcir_i2c_ts_suspend(struct device *dev)
> }
> }
> 
> -   enable_irq_wake(client->irq);
> } else if (input->users) {
> ret = pixcir_stop(ts);
> }
> @@ -386,7 +385,6 @@ static int __maybe_unused
> pixcir_

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Marc Zyngier]

Hi Ley,

On 28/07/15 11:45, Ley Foon Tan wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.

Can't you read this configuration from the HW?

> 
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 318 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index af19039..a8b87fd 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -154,4 +154,11 @@ config PCIE_ALTERA
> Say Y here if you want to enable PCIe controller support for Altera
> SoCFPGA family of SoCs.
>  
> +config PCIE_ALTERA_MSI
> + bool "Altera PCIe MSI feature"
> + depends on PCI_MSI && PCIE_ALTERA

What is the dependency with PCIE_ALTERA? Isn't that module standalone?

> + help
> +   Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> +   This MSI driver supports Altera MSI to GIC controller IP.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 6954f76..6c4913d 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
>  obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
>  obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> +obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> diff --git a/drivers/pci/host/pcie-altera-msi.c 
> b/drivers/pci/host/pcie-altera-msi.c
> new file mode 100644
> index 000..b852b51
> --- /dev/null
> +++ b/drivers/pci/host/pcie-altera-msi.c
> @@ -0,0 +1,318 @@
> +/*
> + * Copyright Altera Corporation (C) 2013-2015. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MSI_STATUS   0x0
> +#define MSI_ERROR0x4
> +#define MSI_INTMASK  0x8
> +
> +#define MAX_MSI_VECTORS  32
> +struct altera_msi {
> + DECLARE_BITMAP(used, MAX_MSI_VECTORS);
> + struct mutexlock;   /* proctect used variable */
> + struct platform_device  *pdev;
> + struct irq_domain   *msi_domain;
> + void __iomem*csr_base;
> + void __iomem*vector_base;
> + u32 vector_phy;

This should be a phys_addr_t. Not everything is 32bit.

> + u32 num_of_vectors;
> + int irq;
> +};
> +
> +static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
> +{
> + writel(value, msi->csr_base + reg);

You should be able to use the relaxed accessors.

> +}
> +
> +static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
> +{
> + return readl(msi->csr_base + reg);

Same here.

> +}
> +
> +static irqreturn_t altera_msi_isr(int irq, void *data)
> +{
> + struct altera_msi *msi = data;
> + unsigned long status;
> + u32 num_of_vectors = msi->num_of_vectors;
> + u32 processed = 0;
> + u32 offset;
> +
> + do {
> + status = msi_readl(msi, MSI_STATUS);
> + if (!status)
> + break;
> +
> + do {
> + offset = find_first_bit(&status, num_of_vectors);
> + /* Dummy read from vector to clear the interrupt */
> + readl(msi->vector_base + (offset * sizeof(u32)));

readl_relaxed

> +
> + irq = irq_find_mapping(msi->msi_domain->parent, offset);

This would tend to indicate that you don't really need to store the
msi_domain pointer, but the inner_domain pointer instead.

> + if (irq) {
> + if (test_bit(offset, msi->used))
> + generic_handle_irq(irq);
> + else
> + dev_info(&msi->pdev->dev, "unhandled 
> MSI\n");
> + } else
> + dev_info(&msi->pdev->dev, "unexpected MSI\n");
> +
> + /* Clear the bit from statu

Re: [PATCH 0/2 RESEND] power: reset: Add syscon reboot/poweroff device nodes for APM X-Gene platform

[Duc Dang]

On Sun, Jul 26, 2015 at 11:37 AM, Olof Johansson  wrote:
> On Sat, Jul 25, 2015 at 11:34:42AM -0700, Duc Dang wrote:
>> Hi Olof,
>>
>> We are debating whether we should setup a company server (where we can
>> have full control about storage, user permissions, backup, ...) or
>> just use github.com to host our X-Gene kernel tree.
>>
>> Github seems already provide everything we need for a public source
>> tree. Per your experience, what is your (and probably other
>> maintainers) reference in git hosting server? Is there any
>> inconvenience or difficulty for the maintainers to pull/merge code
>> from Github versus from a company server?
>
> Hosting on github is fine with us in general. We do prefer to get
> signed pull requests in particular when they come from other sources
> than kernel.org, mostly because there's another third party involved in
> hosting the repo and by using signed tags there's less room for anyone
> to do bad stuff with the repository without someone noticing.
>
> If you host on github, please still use native git pull requests and not the
> ones that github provides via the web interface.
>
> Note however, that given the total volume of patches there's no strong need 
> for
> you to have a public repo just to send code to us -- we're happy applying
> patches at the volumes we're currently looking at. I can imagine other reasons
> for why you would like to have a public repo though.
>

Thanks for the information, Olof.

We are setting up a public repo on Github. I will make sure that
native git pull request is used.

I will need your help in signing the PGP key when the repo is ready.

>
> Thanks,
>
> -Olof

-- 
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Andreas Färber]

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> This patch adds LVDS panel for IFC6410.
> 
> Signed-off-by: Rob Clark 
> [Rob Clark: WIP patch]
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 
> ++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 1ab71f1..3bdac02 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -63,6 +63,12 @@
>   qcom,switch-mode-frequency = <320>;
>   };
>  
> + pm8921_l2: l2 {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + bias-pull-down;
> + };
> +
>   pm8921_l3: l3 {
>   regulator-min-microvolt = <305>;
>   regulator-max-microvolt = <330>;
> @@ -96,6 +102,10 @@
>   pm8921_lvs1: lvs1 {
>   bias-pull-down;
>   };
> +
> + pm8921_lvs7: lvs7 {
> + bias-pull-down;
> + };
>   };
>   };
>  
> @@ -119,6 +129,41 @@
>  
>   mdp: qcom,mdp@510 {
>   status = "okay";
> + qcom,lvds-panel = <&panel>;

In my testing this broke/uglified HDMI output. Since not everyone has
that LVDS panel attached, or might have a different panel type, I don't
think the panel node belongs in the generic -ifc6410.dts file.
I suggest you add an -ifc6410+inforce-lvds.dts or so for that.

> + lvds-vccs-3p3v-supply = <&ext_3p3v>;
> + lvds-pll-vdda-supply = <&pm8921_l2>;
> + lvds-vdda-supply = <&pm8921_lvs7>;
> + };
> +
> + panel_3p3v: panel_3p3v {

s/_/-/ ?

> + compatible = "regulator-fixed";
> + pinctrl-0 = <&disp_en_gpios>;
> + pinctrl-names = "default";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "panel_en_3p3v";
> + regulator-type = "voltage";
> + startup-delay-us = <0>;
> + gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-boot-on;
> + };
> +
> + backlight: backlight{
> + pinctrl-0 = <&pwm_bl_gpios>;
> + pinctrl-names = "default";
> + compatible = "gpio-backlight";
> + gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> + default-on;
> + };
> +
> + panel: auo,b101xtn01 {

panel: panel { ?

Regards,
Andreas

> + status = "okay";
> + compatible = "auo,b101xtn01";
> +
> + ddc-i2c-bus = <&i2c3>;
> + backlight = <&backlight>;
> + power-supply = <&panel_3p3v>;
>   };
>  
>   gsbi3: gsbi@1620 {
> @@ -235,6 +280,27 @@
>   pm8921_gpio: gpio@150 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&wlan_default_gpios>;
> +
> + pwm_bl_gpios: pwm-bl-gpios {
> + pios {
> + pins = "gpio26";
> + bias-disable;
> + function = "normal";
> + qcom,drive-strength = 
> ;
> + power-source = 
> ;
> + };
> + };
> +
> + disp_en_gpios: disp-en-gpios {
> + pios {
> + pins = "gpio36";
> + bias-disable;
> + function = "normal";
> + qcom,drive-strength = 
> ;
> + power-source = 
> ;
> + };
> + };

Re: [PATCH] of/irq: introduce of_has_named_irqs helper

[R, Vignesh]

Hi,

On 7/28/2015 10:53 PM, Dmitry Torokhov wrote:
> On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
>> Hi Dmitry,
>>
>> On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
>>> On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
 On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
>  wrote:
>> Sometimes drivers might wish to transition from index-based to named
>> interrupt descriptions. To aid in decision-making when parsing device
>> tree data let's provide a helper that will indicate the scheme that is
>> being used.
>
> Generally, IRQs are retrieved by platform_get_irq or
> platform_get_irq_byname. Drivers should not call the of_irq_*
> functions directly in most cases.

 That would be true for platform drivers, but not all devices are
 platform devices.

>
>>
>> Signed-off-by: Dmitry Torokhov 
>> ---
>>
>> The intent is to it like this:
>>
>> if (of_has_named_irqs(np) {
>> /* Wake IRQ is optional */
>> dev->wakeirq = of_irq_get_byname(np, "wakeup");
>> if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
>> return dev->wakeirq;
>> }
>
> of_irq_get_byname will already return an error if the property is not
> present. Use that.

 I do not like that it returns -EINVAL when property is missing, can we
 change it to return -ENODATA (so it is the same as when the property is
 defined but such name is missing)?
>>>
>>> So here is what I had in mind.. It is based on recent patch by Vignesh
>>> for pixcir touchscreen, but I think it should be made available to all
>>> I2C devices. Completely untested at the moment.
>>>
>>
>> Thanks for the patch! I tested this on am437x-gp-evm and the
>> suspend/resume worked fine (below patch + $subject patch). I was able to
>> wake the system from low power state using touchscreen. Also verified
>> module insertion and removal. One comment though, please see below.
>>
>>> ---
>>>  drivers/i2c/i2c-core.c |   43 +--
>>>  1 file changed, 37 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>>> index e6d4935..3971461 100644
>>> --- a/drivers/i2c/i2c-core.c
>>> +++ b/drivers/i2c/i2c-core.c
>>> @@ -47,6 +47,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
>>>  {
>>> struct i2c_client   *client = i2c_verify_client(dev);
>>> struct i2c_driver   *driver;
>>> +   int wakeirq = 0;
>>> int status;
>>>  
>>> if (!client)
>>> @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
>>> if (!client->irq) {
>>> int irq = -ENOENT;
>>>  
>>> -   if (dev->of_node)
>>> -   irq = of_irq_get(dev->of_node, 0);
>>> -   else if (ACPI_COMPANION(dev))
>>> +   if (dev->of_node) {
>>> +   irq = of_has_named_irqs(dev->of_node) ?
>>> +   of_irq_get_byname(dev->of_node, "irq") :
>>> +   of_irq_get(dev->of_node, 0);
>>> +   } else if (ACPI_COMPANION(dev)) {
>>> irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
>>> -
>>> +   }
>>> if (irq == -EPROBE_DEFER)
>>> return irq;
>>> if (irq < 0)
>>> @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
>>> client->irq = irq;
>>> }
>>>  
>>> +   if (dev->of_node && of_has_named_irqs(dev->of_node)) {
>>> +   wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
>>> +   if (wakeirq < 0) {
>>> +   if (wakeirq != -ENODATA)
>>> +   return wakeirq;
>>> +   wakeirq = 0;
>>> +   }
>>> +   }
>>> +
>>> driver = to_i2c_driver(dev->driver);
>>> if (!driver->probe || !driver->id_table)
>>> return -ENODEV;diff --git 
>>> a/drivers/input/touchscreen/pixcir_i2c_ts.c 
>>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 8f3e243a62bf..6bd1d1ca9883 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -365,7 +365,6 @@ static int __maybe_unused
pixcir_i2c_ts_suspend(struct device *dev)
}
}

-   enable_irq_wake(client->irq);
} else if (input->users) {
ret = pixcir_stop(ts);
}
@@ -386,7 +385,6 @@ static int __maybe_unused
pixcir_i2c_ts_resume(struct device *dev)
mutex_lock(&input->mutex);

if (device_may_wakeup(&client->dev)) {
-   disable_irq_wake(client->irq);

if (!input->users) {
ret = pixcir_stop(ts);
@

Re: [PATCH v5 1/5] ARM/PCI: remove align_resource in pci_sys_data

[Lorenzo Pieralisi]

[CC'ing RMK]

On Tue, Jul 28, 2015 at 08:17:18AM +0100, Zhou Wang wrote:
> On 2015/7/25 11:21, Zhou Wang wrote:
> > From: Gabriele Paoloni 
> > 
> > This patch is needed in order to unify the PCIe designware framework for 
> > ARM and
> > ARM64 architectures. In the PCIe designware unification process we are 
> > calling
> > pci_create_root_bus() passing a "sysdata" parameter that is the same for 
> > both
> > ARM and ARM64 and is of type "struct pcie_port*". In the ARM case this will
> > cause a problem with the function pcibios_align_resource(); in fact this 
> > will
> > cast "dev->sysdata" to "struct pci_sys_data*", whereas designware had 
> > passed a
> > "struct pcie_port*" pointer.
> > 
> > This patch solves the issue by removing "align_resource" from "pci_sys_data"
> > struct and defining a static global function pointer in "bios32.c"
> > 
> > Signed-off-by: Gabriele Paoloni 
> 
> Hi Arnd and Rob,
> 
> What is your opinion about this patch? Gabriele adds a global pointer in 
> bios32.c
> to store align_resource, so we could remove sys->align_resource in 
> pcibios_align_resource.
> 
> As Lorenzo mentioned in v4 series, this is a temporary solution before moving
> align_resource to host bridge structure.
> 
> Any comments welcome.

The align_resource() pointer is just used in drivers/pci/host/pci-mvebu.c,
I would like the pci-mvebu.c maintainers to comment on this and test it, I
do not expect it to create any issue and might be a temporary solution to
make progress on ARM/ARM64 consolidation, it is a blocking point.

It would be good if Russell can have a look too, I do not see what
issue this can trigger given that is just used in:

drivers/pci/host/pci-mvebu.c

and a global pointer (not saying it is elegant, but it should work)
might be ok.

So yes, comments very welcome.

Thanks,
Lorenzo

> 
> Thanks,
> Zhou
> 
> > ---
> >  arch/arm/include/asm/mach/pci.h |  5 -
> >  arch/arm/kernel/bios32.c| 12 
> >  2 files changed, 8 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/mach/pci.h 
> > b/arch/arm/include/asm/mach/pci.h
> > index 28b9bb3..8a4e4de 100644
> > --- a/arch/arm/include/asm/mach/pci.h
> > +++ b/arch/arm/include/asm/mach/pci.h
> > @@ -58,11 +58,6 @@ struct pci_sys_data {
> > /* IRQ mapping  
> > */
> > int (*map_irq)(const struct pci_dev *, u8, u8);
> > /* Resource alignement requirements 
> > */
> > -   resource_size_t (*align_resource)(struct pci_dev *dev,
> > - const struct resource *res,
> > - resource_size_t start,
> > - resource_size_t size,
> > - resource_size_t align);
> > void*private_data;  /* platform controller private data 
> > */
> >  };
> >  
> > diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> > index fc1..4cdc64d 100644
> > --- a/arch/arm/kernel/bios32.c
> > +++ b/arch/arm/kernel/bios32.c
> > @@ -17,6 +17,11 @@
> >  #include 
> >  
> >  static int debug_pci;
> > +static resource_size_t (*align_resource)(struct pci_dev *dev,
> > + const struct resource *res,
> > + resource_size_t start,
> > + resource_size_t size,
> > + resource_size_t align) = NULL;
> >  
> >  #ifdef CONFIG_PCI_MSI
> >  struct msi_controller *pcibios_msi_controller(struct pci_dev *dev)
> > @@ -468,7 +473,7 @@ static void pcibios_init_hw(struct device *parent, 
> > struct hw_pci *hw,
> > sys->busnr   = busnr;
> > sys->swizzle = hw->swizzle;
> > sys->map_irq = hw->map_irq;
> > -   sys->align_resource = hw->align_resource;
> > +   align_resource = hw->align_resource;
> > INIT_LIST_HEAD(&sys->resources);
> >  
> > if (hw->private_data)
> > @@ -589,7 +594,6 @@ resource_size_t pcibios_align_resource(void *data, 
> > const struct resource *res,
> > resource_size_t size, resource_size_t align)
> >  {
> > struct pci_dev *dev = data;
> > -   struct pci_sys_data *sys = dev->sysdata;
> > resource_size_t start = res->start;
> >  
> > if (res->flags & IORESOURCE_IO && start & 0x300)
> > @@ -597,8 +601,8 @@ resource_size_t pcibios_align_resource(void *data, 
> > const struct resource *res,
> >  
> > start = (start + align - 1) & ~(align - 1);
> >  
> > -   if (sys->align_resource)
> > -   return sys->align_resource(dev, res, start, size, align);
> > +   if (align_resource)
> > +   return align_resource(dev, res, start, size, align);
> >  
> > return start;
> >  }
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe f

Re: [PATCH v1 3/7] ARM: dts: apq8064-ifc6410: add heart-beat led support.

[Andreas Färber]

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> This patch adds heart-beat led support on IFC6410.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index df560cf..1fc2ea5 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -207,6 +207,19 @@
>   status = "okay";
>   };
>  
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <¬ify_led>;
> +
> + led@1 {
> + label = "apq8064:green:user1";
> + gpios = <&pm8921_gpio 18 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";

Can we please drop the heartbeat default? While that's nice as proof of
concept, it's annoying to deliver it that way in Linux distros. Users
can enable that trigger with a simple boot script writing to /sys.

Thanks,
Andreas

> + default-state = "on";
> + };
> + };
> +
>   qcom,ssbi@50 {
>   pmicintc: pmic@0 {
>   pm8921_gpio: gpio@150 {
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 4/7] ARM: dts: apq8064: Add MDP support

[Andreas Färber]

Hi,

Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
> From: Rob Clark 
> 
> This patch adds MDP node to APQ8064 dt.
> 
> Signed-off-by: Rob Clark 
> [Srinivas Kandagatla] : updated with new style rpm regulators
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 87 
> +
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index cba4ccb..7d2cc45 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
[...]
> + gpu: qcom,adreno-3xx@430 {
> + compatible = "qcom,adreno-3xx";

I thought that wildcards were forbidden in compatible strings? Then this
should be replaced by the real number, with a fallback to the first
compatible one.

And can't we just name the node qcom,adreno without version suffix?

Regards,
Andreas

> + reg = <0x0430 0x2>;
> + reg-names = "kgsl_3d0_reg_memory";
> + interrupts = ;
> + interrupt-names = "kgsl_3d0_irq";
> + clock-names =
> + "core_clk",
> + "iface_clk",
> + "mem_clk",
> + "mem_iface_clk";
> + clocks =
> + <&mmcc GFX3D_CLK>,
> + <&mmcc GFX3D_AHB_CLK>,
> + <&mmcc GFX3D_AXI_CLK>,
> + <&mmcc MMSS_IMEM_AHB_CLK>;
> + qcom,chipid = <0x03020002>;
> + qcom,gpu-pwrlevels {
> + compatible = "qcom,gpu-pwrlevels";
> + qcom,gpu-pwrlevel@0 {
> + qcom,gpu-freq = <45000>;
> + };
> + qcom,gpu-pwrlevel@1 {
> + qcom,gpu-freq = <2700>;
> + };
> + };
> + };
> +
> + mdp: qcom,mdp@510 {
> + compatible = "qcom,mdp";
> + reg = <0x0510 0xf>;
> + interrupts = ;
> + connectors = <&hdmi>;
> + gpus = <&gpu>;
> + clock-names =
> + "core_clk",
> + "iface_clk",
> + "lut_clk",
> + "src_clk",
> + "hdmi_clk",
> + "mdp_clk",
> + "mdp_axi_clk";
> + clocks =
> + <&mmcc MDP_CLK>,
> + <&mmcc MDP_AHB_CLK>,
> + <&mmcc MDP_LUT_CLK>,
> + <&mmcc TV_SRC>,
> + <&mmcc HDMI_TV_CLK>,
> + <&mmcc MDP_TV_CLK>,
> + <&mmcc MDP_AXI_CLK>;
> + };
>   };
>  };

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Lee Jones]

On Tue, 28 Jul 2015, Dmitry Torokhov wrote:

> On Tue, Jul 28, 2015 at 09:40:19AM +0100, Lee Jones wrote:
> > On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
> > 
> > > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > > From: S Twiss 
> > > > > 
> > > > > Add device tree bindings for the DA9062 OnKey driver component
> > > > > 
> > > > > Signed-off-by: Steve Twiss 
> > > > > 
> > > > > ---
> > > > > Changes in V3:
> > > > >  - Child driver specifics separated out into separate document
> > > > >in this case ../input/da9062-onkey.txt
> > > > > Changes in V2:
> > > > >  - No change
> > > > > 
> > > > > This patch applies against linux-next and next-20150708 
> > > > > 
> > > > > 
> > > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36 
> > > > > ++
> > > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > > > 
> > > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > > 9063, folded into the onkey patch and applied.
> > > 
> > > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > > mainline.
> > 
> > Hmm... that's annoying.  You've put the patch below your signature
> > '--', so my mailer cuts it off.
> 
> OK, sorry, I'll make sure to put in before the signature next time.

Appreciated.

> > [pasting]
> > 
> > > Input: add DA9062 OnKey capability to DA9063 OnKey driver
> > > 
> > > From: S Twiss 
> > > 
> > > Add DA9062 OnKey support into the existing DA9063 OnKey driver component 
> > > by
> > > using generic access tables for common register and bit mask definitions.
> > > 
> > > The following change will add generic register and bit mask support to the
> > > DA9063 OnKey.
> > > 
> > > The following alterations have been made to the DA9063 OnKey:
> > > 
> > > - Addition of a da906x_chip_config structure to hold all
> > >   generic registers and bitmasks for this type of OnKey component.
> > > - Addition of an struct of_device_id table for DA9063 and DA9062
> > >   defaults
> > > - Refactoring functions to use struct da9063_onkey accesses to generic
> > >   registers/masks instead of using defines from registers.h
> > > - Re-work of da9063_onkey_probe() to use of_match_node() and
> > >   dev_get_regmap() to provide initialisation of generic registers and
> > >   masks and access to regmap
> > > 
> > > Signed-off-by: Steve Twiss 
> > > Signed-off-by: Dmitry Torokhov 
> > > ---
> > >  .../devicetree/bindings/input/da9062-onkey.txt |   32 +
> > >  drivers/input/misc/Kconfig |8 +
> > >  drivers/input/misc/da9063_onkey.c  |  129 
> > > 
> > >  3 files changed, 140 insertions(+), 29 deletions(-)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/input/da9062-onkey.txt
> >  
> > I'm confused.  What's the dependency?
> > 
> > There shouldn't be any issue applying input patches, just because
> > there isn't an MFD counterpart.  In fact, I would take prior
> > acceptance of the child into consideration (would be like a +1 vote)
> > when reviewing the MFD part.
> 
> It's this chunk:
> 
> +#include 
> +#include 
> 
> and these header files are not in mainline yet.

Ah, thanks for the clarification.

I will apply the other patches.

> > One suggestion however, I would ask for the DT binding and the driver
> > to be separated, as per [0].
> > 
> > [0] Documentation/devicetree/bindings/submitting-patches.txt
> 
> Right, but that says about submitting patches, not applying them ;)
> 
> When I chatted with Grant he said that the policy of separating binding
> and code into separate patches is done so not to overwhelm devicetree
> list and that is is perfectly fine to actually apply them as a single
> commit. I try to combine them together so that when looking through
> history they show up as one.

Got you. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of/irq: introduce of_has_named_irqs helper

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 06:53:52PM +0530, Vignesh R wrote:
> Hi Dmitry,
> 
> On 07/25/2015 01:46 AM, Dmitry Torokhov wrote:
> > On Fri, Jul 24, 2015 at 12:26:19PM -0700, Dmitry Torokhov wrote:
> >> On Fri, Jul 24, 2015 at 02:14:57PM -0500, Rob Herring wrote:
> >>> On Fri, Jul 24, 2015 at 1:26 PM, Dmitry Torokhov
> >>>  wrote:
>  Sometimes drivers might wish to transition from index-based to named
>  interrupt descriptions. To aid in decision-making when parsing device
>  tree data let's provide a helper that will indicate the scheme that is
>  being used.
> >>>
> >>> Generally, IRQs are retrieved by platform_get_irq or
> >>> platform_get_irq_byname. Drivers should not call the of_irq_*
> >>> functions directly in most cases.
> >>
> >> That would be true for platform drivers, but not all devices are
> >> platform devices.
> >>
> >>>
> 
>  Signed-off-by: Dmitry Torokhov 
>  ---
> 
>  The intent is to it like this:
> 
>  if (of_has_named_irqs(np) {
>  /* Wake IRQ is optional */
>  dev->wakeirq = of_irq_get_byname(np, "wakeup");
>  if (dev->wakeirq < 0 && dev->wakeirq != -ENODATA)
>  return dev->wakeirq;
>  }
> >>>
> >>> of_irq_get_byname will already return an error if the property is not
> >>> present. Use that.
> >>
> >> I do not like that it returns -EINVAL when property is missing, can we
> >> change it to return -ENODATA (so it is the same as when the property is
> >> defined but such name is missing)?
> > 
> > So here is what I had in mind.. It is based on recent patch by Vignesh
> > for pixcir touchscreen, but I think it should be made available to all
> > I2C devices. Completely untested at the moment.
> > 
> 
> Thanks for the patch! I tested this on am437x-gp-evm and the
> suspend/resume worked fine (below patch + $subject patch). I was able to
> wake the system from low power state using touchscreen. Also verified
> module insertion and removal. One comment though, please see below.
> 
> > ---
> >  drivers/i2c/i2c-core.c |   43 +--
> >  1 file changed, 37 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index e6d4935..3971461 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -47,6 +47,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -631,6 +632,7 @@ static int i2c_device_probe(struct device *dev)
> >  {
> > struct i2c_client   *client = i2c_verify_client(dev);
> > struct i2c_driver   *driver;
> > +   int wakeirq = 0;
> > int status;
> >  
> > if (!client)
> > @@ -639,11 +641,13 @@ static int i2c_device_probe(struct device *dev)
> > if (!client->irq) {
> > int irq = -ENOENT;
> >  
> > -   if (dev->of_node)
> > -   irq = of_irq_get(dev->of_node, 0);
> > -   else if (ACPI_COMPANION(dev))
> > +   if (dev->of_node) {
> > +   irq = of_has_named_irqs(dev->of_node) ?
> > +   of_irq_get_byname(dev->of_node, "irq") :
> > +   of_irq_get(dev->of_node, 0);
> > +   } else if (ACPI_COMPANION(dev)) {
> > irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > -
> > +   }
> > if (irq == -EPROBE_DEFER)
> > return irq;
> > if (irq < 0)
> > @@ -652,6 +656,15 @@ static int i2c_device_probe(struct device *dev)
> > client->irq = irq;
> > }
> >  
> > +   if (dev->of_node && of_has_named_irqs(dev->of_node)) {
> > +   wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> > +   if (wakeirq < 0) {
> > +   if (wakeirq != -ENODATA)
> > +   return wakeirq;
> > +   wakeirq = 0;
> > +   }
> > +   }
> > +
> > driver = to_i2c_driver(dev->driver);
> > if (!driver->probe || !driver->id_table)
> > return -ENODEV;
> > @@ -659,20 +672,34 @@ static int i2c_device_probe(struct device *dev)
> > if (!device_can_wakeup(&client->dev))
> > device_init_wakeup(&client->dev,
> > client->flags & I2C_CLIENT_WAKE);
> > +
> > +   status = wakeirq > 0 ?
> > +   dev_pm_set_dedicated_wake_irq(dev, wakeirq) :
> > +   (client->irq > 0 ?
> > +   dev_pm_set_wake_irq(dev, client->irq) : 0);
> 
> Above code tries to register wakeirq irrespective of whether the device
> is specified as wakeup-source in the dt or not. Hence, I see warn
> messages from every i2c device that has irq line but hasn't declared
> itself as wakeup-source:
> For example tps is on i2c:
> [1.961613] tps65218 0-0024: forgot to call call device_init_wakeup?
> [1.968340] tps65218 0-0024: failed to set up 

Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for DA9062 OnKey

[Dmitry Torokhov]

On Tue, Jul 28, 2015 at 09:40:19AM +0100, Lee Jones wrote:
> On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
> 
> > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > > From: S Twiss 
> > > > 
> > > > Add device tree bindings for the DA9062 OnKey driver component
> > > > 
> > > > Signed-off-by: Steve Twiss 
> > > > 
> > > > ---
> > > > Changes in V3:
> > > >  - Child driver specifics separated out into separate document
> > > >in this case ../input/da9062-onkey.txt
> > > > Changes in V2:
> > > >  - No change
> > > > 
> > > > This patch applies against linux-next and next-20150708 
> > > > 
> > > > 
> > > >  .../devicetree/bindings/input/da9062-onkey.txt | 36 
> > > > ++
> > > >  Documentation/devicetree/bindings/mfd/da9062.txt   |  3 ++
> > > 
> > > I dropped bits for mfd/da9062.txt, changed to mention both 9062 and
> > > 9063, folded into the onkey patch and applied.
> > 
> > Argh, da9062 core is not in mainline yet... OK, below is the patch I
> > had; if Lee does not pick it up I'll re-apply it when da9062 core hits
> > mainline.
> 
> Hmm... that's annoying.  You've put the patch below your signature
> '--', so my mailer cuts it off.

OK, sorry, I'll make sure to put in before the signature next time.

> 
> [pasting]
> 
> > Input: add DA9062 OnKey capability to DA9063 OnKey driver
> > 
> > From: S Twiss 
> > 
> > Add DA9062 OnKey support into the existing DA9063 OnKey driver component by
> > using generic access tables for common register and bit mask definitions.
> > 
> > The following change will add generic register and bit mask support to the
> > DA9063 OnKey.
> > 
> > The following alterations have been made to the DA9063 OnKey:
> > 
> > - Addition of a da906x_chip_config structure to hold all
> >   generic registers and bitmasks for this type of OnKey component.
> > - Addition of an struct of_device_id table for DA9063 and DA9062
> >   defaults
> > - Refactoring functions to use struct da9063_onkey accesses to generic
> >   registers/masks instead of using defines from registers.h
> > - Re-work of da9063_onkey_probe() to use of_match_node() and
> >   dev_get_regmap() to provide initialisation of generic registers and
> >   masks and access to regmap
> > 
> > Signed-off-by: Steve Twiss 
> > Signed-off-by: Dmitry Torokhov 
> > ---
> >  .../devicetree/bindings/input/da9062-onkey.txt |   32 +
> >  drivers/input/misc/Kconfig |8 +
> >  drivers/input/misc/da9063_onkey.c  |  129 
> > 
> >  3 files changed, 140 insertions(+), 29 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt
>  
> I'm confused.  What's the dependency?
> 
> There shouldn't be any issue applying input patches, just because
> there isn't an MFD counterpart.  In fact, I would take prior
> acceptance of the child into consideration (would be like a +1 vote)
> when reviewing the MFD part.

It's this chunk:

+#include 
+#include 

and these header files are not in mainline yet.

> 
> One suggestion however, I would ask for the DT binding and the driver
> to be separated, as per [0].
> 
> [0] Documentation/devicetree/bindings/submitting-patches.txt

Right, but that says about submitting patches, not applying them ;)

When I chatted with Grant he said that the policy of separating binding
and code into separate patches is done so not to overwhelm devicetree
list and that is is perfectly fine to actually apply them as a single
commit. I try to combine them together so that when looking through
history they show up as one.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> number of vectors, which is a dts parameter.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   7 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera-msi.c | 318 
> +
>  3 files changed, 326 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera-msi.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index af19039..a8b87fd 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -154,4 +154,11 @@ config PCIE_ALTERA
>   Say Y here if you want to enable PCIe controller support for Altera
>   SoCFPGA family of SoCs.
>
> +config PCIE_ALTERA_MSI
> +   bool "Altera PCIe MSI feature"
> +   depends on PCI_MSI && PCIE_ALTERA
> +   help
> + Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
> + This MSI driver supports Altera MSI to GIC controller IP.
> +

Couldn't this driver get combined with the pcie-altera driver?

Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] pci:host: Add Altera PCIe host controller driver

[Dinh Nguyen]

On Tue, Jul 28, 2015 at 5:45 AM, Ley Foon Tan  wrote:
> This patch adds the Altera PCIe host controller driver.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/pci/host/Kconfig   |   9 +
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pcie-altera.c | 576 
> +
>  3 files changed, 586 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-altera.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 675c2d1..af19039 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
>   Say Y here if you want to use the Broadcom iProc PCIe controller
>   through the BCMA bus interface
>
> +config PCIE_ALTERA
> +   bool "Altera PCIe controller"
> +   depends on ARCH_SOCFPGA
> +   depends on OF

I don't think you need this, "depends on ARCH_SOCFPGA" should already
have taken care of this.

> +   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> +   help
> + Say Y here if you want to enable PCIe controller support for Altera
> + SoCFPGA family of SoCs.
> +
>  endmenu



> +
> +static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
> +{
> +   u8 loop;
> +   struct tlp_rp_regpair_t tlp_rp_regdata;
> +
> +   for (loop = TLP_LOOP; loop > 0; loop--) {
> +
> +   tlp_read_rx(pcie, &tlp_rp_regdata);
> +
> +   if (tlp_rp_regdata.ctrl & RP_RXCPL_EOP) {
> +
> +   if (value)
> +   *value = tlp_rp_regdata.reg0;
> +
> +   return PCIBIOS_SUCCESSFUL;
> +   }

Remove all the unnecessary newlines in this function.
> +   }
> +
> +   return -ENOENT;
> +}
> +



> +
> +static struct platform_driver altera_pcie_driver = {
> +   .probe  = altera_pcie_probe,
> +   .remove = altera_pcie_remove,
> +   .driver = {
> +   .name   = "altera-pcie",
> +   .owner  = THIS_MODULE,

Don't need to set owner anymore as this will get populated by the driver core.

Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Drop owner assignment from platform and i2c driver

[Rob Herring]

On Fri, Jul 10, 2015 at 1:26 AM, Krzysztof Kozlowski
 wrote:
> platform_driver and i2c_driver do not need to set an owner because core
> will set it.
>
> Signed-off-by: Krzysztof Kozlowski 

Applied. Thanks.

Rob

>
> ---
>
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
> ---
>  drivers/of/unittest.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 18016341d5a9..9f71770b6226 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -979,7 +979,6 @@ static struct platform_driver unittest_driver = {
> .remove = unittest_remove,
> .driver = {
> .name   = "unittest",
> -   .owner  = THIS_MODULE,
> .of_match_table = of_match_ptr(unittest_match),
> },
>  };
> @@ -1666,7 +1665,6 @@ static const struct i2c_device_id unittest_i2c_dev_id[] 
> = {
>  static struct i2c_driver unittest_i2c_dev_driver = {
> .driver = {
> .name = "unittest-i2c-dev",
> -   .owner = THIS_MODULE,
> },
> .probe = unittest_i2c_dev_probe,
> .remove = unittest_i2c_dev_remove,
> @@ -1761,7 +1759,6 @@ static const struct i2c_device_id unittest_i2c_mux_id[] 
> = {
>  static struct i2c_driver unittest_i2c_mux_driver = {
> .driver = {
> .name = "unittest-i2c-mux",
> -   .owner = THIS_MODULE,
> },
> .probe = unittest_i2c_mux_probe,
> .remove = unittest_i2c_mux_remove,
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: constify drv arg of of_driver_match_device stub

[Rob Herring]

On Wed, Jul 1, 2015 at 2:10 AM, Tomeu Vizoso  wrote:
> With this change the stub has the same signature as the actual function,
> preventing this compiler warning when building without CONFIG_OF:
>
>drivers/base/property.c: In function 'fwnode_driver_match_device':
>>> drivers/base/property.c:608:38: warning: passing argument 2 of 
>>> 'of_driver_match_device' discards 'const' qualifier from pointer target type
>   return of_driver_match_device(dev, drv);
>  ^
>In file included from drivers/base/property.c:18:0:
>include/linux/of_device.h:61:19: note: expected 'struct device_driver *' 
> but argument is of type 'const struct device_driver *'
> static inline int of_driver_match_device(struct device *dev,
>   ^
>
> Signed-off-by: Tomeu Vizoso 

Applied. Thanks.

Rob

> ---
>  include/linux/of_device.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index 4c50854..cc7dd687 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -59,7 +59,7 @@ void of_dma_configure(struct device *dev, struct 
> device_node *np);
>  #else /* CONFIG_OF */
>
>  static inline int of_driver_match_device(struct device *dev,
> -struct device_driver *drv)
> +const struct device_driver *drv)
>  {
> return 0;
>  }
> --
> 2.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] DEVICETREE: Misc fix for the AR7100 SPI controller binding

[Rob Herring]

On Fri, Jul 3, 2015 at 3:14 AM, Alban Bedel  wrote:
> Fix the clocks property documentation and use lower case for
> hex values in the example.
>
> Signed-off-by: Alban Bedel 

Applied. Thanks.

Rob

> ---
>  Documentation/devicetree/bindings/spi/spi-ath79.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-ath79.txt 
> b/Documentation/devicetree/bindings/spi/spi-ath79.txt
> index f1ad9c3..9c696fa 100644
> --- a/Documentation/devicetree/bindings/spi/spi-ath79.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-ath79.txt
> @@ -3,7 +3,7 @@ Binding for Qualcomm Atheros AR7xxx/AR9xxx SPI controller
>  Required properties:
>  - compatible: has to be "qca,-spi", "qca,ar7100-spi" as fallback.
>  - reg: Base address and size of the controllers memory area
> -- clocks: phandle to the AHB clock.
> +- clocks: phandle of the AHB clock.
>  - clock-names: has to be "ahb".
>  - #address-cells: <1>, as required by generic SPI binding.
>  - #size-cells: <0>, also as required by generic SPI binding.
> @@ -12,9 +12,9 @@ Child nodes as per the generic SPI binding.
>
>  Example:
>
> -   spi@1F00 {
> +   spi@1f00 {
> compatible = "qca,ar9132-spi", "qca,ar7100-spi";
> -   reg = <0x1F00 0x10>;
> +   reg = <0x1f00 0x10>;
>
> clocks = <&pll 2>;
> clock-names = "ahb";
> --
> 2.0.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] DeviceTree fixes for 4.2

[Rob Herring]

Hi Linus,

Please pull this small set of DT fixes for 4.2.

Rob

The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f:

  Linux 4.2-rc4 (2015-07-26 12:26:21 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-4.2

for you to fetch changes up to 599ad5ac9a59587a46f6540a8e2ab79dff811f7d:

  of: Drop owner assignment from platform and i2c driver (2015-07-27
08:24:39 -0500)


A handful of DT related fixes for 4.2-rc.


Alban Bedel (1):
  DEVICETREE: Misc fix for the AR7100 SPI controller binding

Krzysztof Kozlowski (1):
  of: Drop owner assignment from platform and i2c driver

Rob Herring (1):
  of: add HAS_IOMEM depends to OF_ADDRESS

Tomeu Vizoso (1):
  of: constify drv arg of of_driver_match_device stub

 Documentation/devicetree/bindings/spi/spi-ath79.txt | 6 +++---
 drivers/of/Kconfig  | 2 +-
 drivers/of/unittest.c   | 3 ---
 include/linux/of_device.h   | 2 +-
 4 files changed, 5 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones]

On Tue, 28 Jul 2015, Rob Herring wrote:

> On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones  wrote:
> > On Tue, 28 Jul 2015, Rob Herring wrote:
> >
> >> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones  wrote:
> >> > These OPPs are used in ST's CPUFreq implementation.
> >> >
> >> > Signed-off-by: Lee Jones 
> >> > ---
> >> >
> >> > Changelog:
> >> >  - None, new patch
> >> >
> >> >  Documentation/devicetree/bindings/power/opp-st.txt | 76 
> >> > ++
> >> >  1 file changed, 76 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt 
> >> > b/Documentation/devicetree/bindings/power/opp-st.txt
> >> > new file mode 100644
> >> > index 000..6eb2a91
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/power/opp-st.txt
> >> > @@ -0,0 +1,76 @@
> >> > +STMicroelectronics OPP (Operating Performance Points) Bindings
> >> > +--
> >> > +
> >> > +Frequency Scaling only
> >> > +--
> >> > +
> >> > +Located in CPU's node:
> >> > +
> >> > +- operating-points : [See: ./opp.txt]
> >> > +
> >> > +Example [safe]
> >> > +--
> >> > +
> >> > +cpus {
> >> > +   cpu@0 {
> >> > +/* kHz uV   */
> >> > +   operating-points = <150 0
> >> > +   120 0
> >> > +   80  0
> >> > +   50  0>;
> >> > +   };
> >> > +};
> >> > +
> >> > +Dynamic Voltage and Frequency Scaling (DVFS)
> >> > +
> >> > +
> >> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> >> > +
> >> > +- compatible   : Should be "operating-points-v2-sti"
> >> > +- opp{1..N}: Each 'oppX' subnode will contain the following 
> >> > properties:
> >> > + - opp-hz  : CPU frequency [Hz] for this OPP [See: 
> >> > ./opp.txt]
> >> > + - st,avs  : List of available voltages [uV] indexed by 
> >> > process code
> >>
> >> Add a unit suffix (-microvolt).
> >
> > Sure.
> >
> >> > + - st,cuts : Cut version this OPP is suitable for [0xFF 
> >> > means ALL]
> >> > + - st,substrate: Substrate version this OPP is suitable 
> >> > for [0xFF means ALL]
> >>
> >> How about not present means all?
> >
> > I think that would be an unsafe assumption.  If it's forgotten, then
> > we may try to run an invalid/dangerous voltage/frequency combination.
> >
> > I'd really like 'all' to be defined an deliberate.
> 
> Okay.
> 
> >> > +- st,syscfg: Phandle to Major number register
> >> > +   First cell: offset to major number
> >> > +- st,syscfg-eng: Phandle to Minor number and Pcode 
> >> > registers
> >> > +   First cell: offset to process code
> >> > +   Second cell: offset to minor number
> >>
> >> Would the proposed nvmem binding work for this?
> >
> > We already use sysconf for all of this type of stuff, as this
> > information is contained in ST's Sysconf banks.  Moving over to a new
> > API would be a huge move and would require lots of planning
> > discussions with ST.
> 
> Okay.

Thanks.

I'm going to fix up your suggestions above and add your Ack to make
Viresh happy. :)

Thanks Rob.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Rob Herring]

On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones  wrote:
> On Tue, 28 Jul 2015, Rob Herring wrote:
>
>> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones  wrote:
>> > These OPPs are used in ST's CPUFreq implementation.
>> >
>> > Signed-off-by: Lee Jones 
>> > ---
>> >
>> > Changelog:
>> >  - None, new patch
>> >
>> >  Documentation/devicetree/bindings/power/opp-st.txt | 76 
>> > ++
>> >  1 file changed, 76 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt 
>> > b/Documentation/devicetree/bindings/power/opp-st.txt
>> > new file mode 100644
>> > index 000..6eb2a91
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/power/opp-st.txt
>> > @@ -0,0 +1,76 @@
>> > +STMicroelectronics OPP (Operating Performance Points) Bindings
>> > +--
>> > +
>> > +Frequency Scaling only
>> > +--
>> > +
>> > +Located in CPU's node:
>> > +
>> > +- operating-points : [See: ./opp.txt]
>> > +
>> > +Example [safe]
>> > +--
>> > +
>> > +cpus {
>> > +   cpu@0 {
>> > +/* kHz uV   */
>> > +   operating-points = <150 0
>> > +   120 0
>> > +   80  0
>> > +   50  0>;
>> > +   };
>> > +};
>> > +
>> > +Dynamic Voltage and Frequency Scaling (DVFS)
>> > +
>> > +
>> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
>> > +
>> > +- compatible   : Should be "operating-points-v2-sti"
>> > +- opp{1..N}: Each 'oppX' subnode will contain the following 
>> > properties:
>> > + - opp-hz  : CPU frequency [Hz] for this OPP [See: ./opp.txt]
>> > + - st,avs  : List of available voltages [uV] indexed by 
>> > process code
>>
>> Add a unit suffix (-microvolt).
>
> Sure.
>
>> > + - st,cuts : Cut version this OPP is suitable for [0xFF means 
>> > ALL]
>> > + - st,substrate: Substrate version this OPP is suitable 
>> > for [0xFF means ALL]
>>
>> How about not present means all?
>
> I think that would be an unsafe assumption.  If it's forgotten, then
> we may try to run an invalid/dangerous voltage/frequency combination.
>
> I'd really like 'all' to be defined an deliberate.

Okay.

>> > +- st,syscfg: Phandle to Major number register
>> > +   First cell: offset to major number
>> > +- st,syscfg-eng: Phandle to Minor number and Pcode 
>> > registers
>> > +   First cell: offset to process code
>> > +   Second cell: offset to minor number
>>
>> Would the proposed nvmem binding work for this?
>
> We already use sysconf for all of this type of stuff, as this
> information is contained in ST's Sysconf banks.  Moving over to a new
> API would be a huge move and would require lots of planning
> discussions with ST.

Okay.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 10/19] drm/tegra: dc: Prepare for generic PM domains

[Jon Hunter]

On 28/07/15 12:20, Thierry Reding wrote:
> On Tue, Jul 28, 2015 at 09:30:04AM +0100, Jon Hunter wrote:
>> May be that would be a cleaner transition than trying to do it all in
>> one go.
> 
> I have a couple of patches in my tree to do this for DRM as part of an
> effort to restore DPMS. It's fairly tricky to get right in DRM and
> requires all sorts of changes to the driver.

Hmmm ... I was just thinking about moving what is currently there in the 
pm-runtime helpers ...

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index a287e4fec865..0f1dc01215b1 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1922,29 +1923,12 @@ static int tegra_dc_probe(struct platform_device *pdev)
dc->powergate = TEGRA_POWERGATE_DIS;
else
dc->powergate = TEGRA_POWERGATE_DISB;
+   }
 
-   err = tegra_powergate_sequence_power_up(dc->powergate, dc->clk,
-   dc->rst);
-   if (err < 0) {
-   dev_err(&pdev->dev, "failed to power partition: %d\n",
-   err);
-   return err;
-   }
-   } else {
-   err = clk_prepare_enable(dc->clk);
-   if (err < 0) {
-   dev_err(&pdev->dev, "failed to enable clock: %d\n",
-   err);
-   return err;
-   }
+   platform_set_drvdata(pdev, dc);
 
-   err = reset_control_deassert(dc->rst);
-   if (err < 0) {
-   dev_err(&pdev->dev, "failed to deassert reset: %d\n",
-   err);
-   return err;
-   }
-   }
+   pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dc->regs = devm_ioremap_resource(&pdev->dev, regs);
@@ -1978,8 +1962,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
if (!dc->syncpt)
dev_warn(&pdev->dev, "failed to allocate syncpoint\n");
 
-   platform_set_drvdata(pdev, dc);
-
return 0;
 }
 
@@ -2003,6 +1985,17 @@ static int tegra_dc_remove(struct platform_device *pdev)
return err;
}
 
+   pm_runtime_put(&pdev->dev);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM
+static int tegra_dc_runtime_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct tegra_dc *dc = platform_get_drvdata(pdev);
+
reset_control_assert(dc->rst);
 
if (dc->soc->has_powergate)
@@ -2013,11 +2006,54 @@ static int tegra_dc_remove(struct platform_device *pdev)
return 0;
 }
 
+static int tegra_dc_runtime_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct tegra_dc *dc = platform_get_drvdata(pdev);
+   int err;
+
+   if (dc->soc->has_powergate) {
+   err = tegra_powergate_sequence_power_up(dc->powergate, dc->clk,
+   dc->rst);
+   if (err < 0) {
+   dev_err(&pdev->dev, "failed to power partition: %d\n",
+   err);
+   return err;
+   }
+   } else {
+   err = clk_prepare_enable(dc->clk);
+   if (err < 0) {
+   dev_err(&pdev->dev, "failed to enable clock: %d\n",
+   err);
+   return err;
+   }
+
+   err = reset_control_deassert(dc->rst);
+   if (err < 0) {
+   dev_err(&pdev->dev, "failed to deassert reset: %d\n",
+   err);
+   return err;
+   }
+   }
+
+   return 0;
+}
+
+static struct dev_pm_ops tegra_dc_pm_ops = {
+   SET_RUNTIME_PM_OPS(tegra_dc_runtime_suspend,
+  tegra_dc_runtime_resume, NULL)
+};
+#define TEGRA_DC_PM_OPS (&tegra_dc_pm_ops)
+#else
+#define TEGRA_DC_PM_OPS NULL
+#endif /* CONFIG_PM */
+
 struct platform_driver tegra_dc_driver = {
.driver = {
.name = "tegra-dc",
.owner = THIS_MODULE,
.of_match_table = tegra_dc_of_match,
+   .pm = TEGRA_DC_PM_OPS,
},
.probe = tegra_dc_probe,
.remove = tegra_dc_remove,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/22] of/platform: add of_platform_device_find()

[Rob Herring]

On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
 wrote:
> On 28 July 2015 at 15:39, Rob Herring  wrote:
>> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
>>  wrote:
>>> From an arbitrary node in the tree, find the enclosing node that
>>> corresponds to a platform device, as registered by
>>> of_platform_populate().
>>>
>>> This can be used to find out what device needs to be probed so the
>>> dependency described by a given node is made available.
>>>
>>> Signed-off-by: Tomeu Vizoso 
>>> ---
>>>
>>> Changes in v2:
>>> - Move the logic for finding a platform device from its firmware node to
>>>   of/platform.c as it's not needed for ACPI nodes.
>>>
>>>  drivers/of/platform.c   | 60 
>>> +
>>>  include/linux/of_platform.h |  1 +
>>>  2 files changed, 61 insertions(+)
>>>
>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>> index ff27494cda8c..89c5cd513027 100644
>>> --- a/drivers/of/platform.c
>>> +++ b/drivers/of/platform.c
>>> @@ -501,6 +501,66 @@ void of_platform_depopulate(struct device *parent)
>>>  }
>>>  EXPORT_SYMBOL_GPL(of_platform_depopulate);
>>>
>>> +static bool of_is_platform(struct device_node *np)
>>> +{
>>> +   int count;
>>> +
>>> +   count = of_property_count_strings(np, "compatible");
>>> +
>>> +   /* The node has to have a compatible string */
>>> +   if (!count)
>>> +   return false;
>>> +
>>> +   /* But it cannot be just a simple memory-mapped bus */
>>> +   if (count == 1 && of_match_node(of_default_bus_match_table, np))
>>> +   return false;
>>> +
>>> +   /* But AMBA devices aren't platform devices */
>>> +   if (of_device_is_compatible(np, "arm,primecell"))
>>> +   return false;
>>> +
>>> +   /* Node is immediately below root */
>>> +   if (!np->parent || !np->parent->parent)
>>> +   return true;
>>> +
>>> +   /* If it's a node in a simple memory-mapped bus */
>>> +   if (of_match_node(of_default_bus_match_table, np->parent))
>>> +   return true;
>>
>> This seems really fragile.
>
> I think this finding logic matches the logic for registering platform
> devices in of_platform_populate and also what is documented in
> Documentation/devicetree/usage-model.txt.

Right. So now we have that logic in 2 places. One is descending from
the root and one is walking up from the child. That's an opportunity
for some mismatch.

>> What about platform devices which are
>> children of MFDs but are not "simple-mfd"?
>
> This code should deal fine with those (the boards I tested with do
> have them). It probes the mfd master, and that in turn will call
> mfd_add_devices causing the target device to be probed.

I don't see how this function would ever return true in this case
unless you put the MFD at the root level. The only other way to return
true is matching on of_default_bus_match_table for the parent (i.e.
the MFD).


>> Does of_find_device_by_node not work for you?
>
> Well, the dependencies aren't always platform devices, that's why I
> need to go up the tree until I find a node that corresponds to a
> platform device that I can query and probe.
>
> If I had a way to get, say, a i2c device from its fwnode then I would
> just need to make sure that a device's parent is probed before probing
> it and everything would be cleaner in the OF case.

If you have the struct device from the device_node, then you should be
able to do this, right?

>> That is probably not the
>> most efficient search, but we could fix that. We could add struct
>> device ptr to struct device_node and check without searching for
>> example.
>
> That would be great, but I thought there was an issue with a OF node
> being able to be related to more than one struct device (but I haven't
> found this myself yet).

I think it pretty much should be one to one. I'm not aware of any
examples where that is not the case. This function would already be
broken if you could have more than one struct device.

There is an issue where you could have 2 drivers match the same node,
but on different compatible strings. But that's a different issue.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

[Hans de Goede]

Hi,

On 07/28/2015 05:09 PM, Timo Sigurdsson wrote:

Hi,

Hans de Goede schrieb am 28.07.2015 16:24:

I've no problem with Timo submitting a cleaned up version of his
patch and you taking that instead. I just wanted to point out that
I do have a similar patch pending.


Ok, I will do that. It might take a couple of days, though, as I will be moving
moving in the next few days as well.

However, another question first then: What maximum voltage for the dcdc2
regulator should we use then? You used 1.5V, I used 1.45V so far, which is what
Cubieboard 2 and Cubietruck use.

But after the discussion about overvoltaged settings, I'm wondering whether we
should limit the regulartor (and not only the opp) to 1.40V as well? Or is
1.45V ok for everybody here?


The datasheets lists a max cpu-voltage of 1.40V, so lets stick with that.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Philipp Zabel]

Hi Moritz, Michal,

Am Dienstag, den 28.07.2015, 06:57 -0700 schrieb Moritz Fischer:
[...]
> >>> +Example:
> >>> +rstc: rstc@240 {
> >>> +#reset-cells = <1>;
> >>> +compatible = "xlnx,zynq-reset-pl";
> >>> +syscon = <&slcr>;
> >>
> >> Why the syscon phandle if rstc always is the child of slcr? Why not just
> >> request the syscon for the rstc's parent node.
> >
> > We are using this description for pincntrl which was properly reviewed
> > that's why I expect Moritz just use the same style.
> > But yes also referencing parent should work.
> 
> Michal is right, I tried to be consistent with the pinctrl. Either one
> is fine for me.
> We'll just have to make a decision :-)

Do you have a pointer to the pinctrl review? I'd like to know if
somebody had a good reason to use the phandle over the parent-child
relationship. I'd rather not add DT properties if they are not
necessary.
Regarding consistency, since the pinctrl node is also a child of the
slcr, you could just as well make the syscon phandle optional there and
remove it from the DT without breaking backwards compatibility.

> > TBH I don't have strong preference but having unified style is something
> > what I would prefer.
> >
> > Also I see that using parent is used by others and it looks like that
> > having something like syscon_regmap_lookup_parent will be worth to have.

That would be useful, yes.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

[Timo Sigurdsson]

Hi,

Hans de Goede schrieb am 28.07.2015 16:24:
> I've no problem with Timo submitting a cleaned up version of his
> patch and you taking that instead. I just wanted to point out that
> I do have a similar patch pending.

Ok, I will do that. It might take a couple of days, though, as I will be moving
moving in the next few days as well.

However, another question first then: What maximum voltage for the dcdc2
regulator should we use then? You used 1.5V, I used 1.45V so far, which is what
Cubieboard 2 and Cubietruck use.

But after the discussion about overvoltaged settings, I'm wondering whether we
should limit the regulartor (and not only the opp) to 1.40V as well? Or is
1.45V ok for everybody here?


Thanks and regards,

Timo




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter

[Russell King - ARM Linux]

On Tue, Jul 28, 2015 at 04:39:12PM +0200, Jean-Francois Moine wrote:
> On Tue, 28 Jul 2015 14:53:58 +0100
> Russell King - ARM Linux  wrote:
> > In the case of the TDA998x, there is a 1:1 fixed relationship between the
> > connector and the encoder.  The connector part can't be used with any other
> > encoder, and the encoder part can't be used with any other connector.  The
> > same is true of many other HDMI implementations (such as the Synopsis
> > Designware HDMI interface found on iMX6 and Rockchip.)
> 
> But there is no direct link (pointer) between the encoder and the
> connector.

There's no direct link from an encoder to a connector because the DRM
model allows a single encoder to be associated with multiple connectors.
Adding a link from the encoder to a connector breaks that ability (an
encoder would then need an array of connectors.)

If we kill the old drm_slave_encoder support in TDA998x, then this would
solve the problem - we can then get at the TDA998x's drm_connector easily
as it then becomes part of TDA998x's private data.

However, this doesn't matter.  All that we need from the DRM side of the
TDA998x is to know is the EDID or ELD.  That can be broadcast via a
notification (using something like the code I illustrated in a follow up
email) to any listeners, whether they be an audio driver or a CEC bus
driver.  The audio driver may not care about HDMI connect/disconnect
events, but that's no reason not to include them.  Some consumers of
these events need to know (CEC certainly needs to know.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH,v3 2/3] ARM: dts: ls1021a: Add the eTSEC controller nodes

[Claudiu Manoil]

Add basic support for all the eTSEC controllers on the
ls1021a SoC.  Second interrupt group register blocks
and their corresponding Rx/Tx/Err interrupt sources are
included as well for each eTSEC node.

Signed-off-by: Alison Wang 
Signed-off-by: Claudiu Manoil 
---
v2: various findings, added 2nd interrupt group;
v3: addressed findings from Shawn Guo -
- initial patch split in soc, boards and bindings patches;
- removed redundant all zero local-mac-address;
- subject prefix;

 arch/arm/boot/dts/ls1021a.dtsi | 88 ++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 1b306c7..0638cda 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -59,6 +59,9 @@
serial3 = &lpuart3;
serial4 = &lpuart4;
serial5 = &lpuart5;
+   ethernet0 = &enet0;
+   ethernet1 = &enet1;
+   ethernet2 = &enet2;
sysclk = &sysclk;
};
 
@@ -391,6 +394,91 @@
reg = <0x0 0x2d24000 0x0 0x4000>;
};
 
+   enet0: ethernet@2d1 {
+   compatible = "fsl,etsec2";
+   device_type = "network";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&gic>;
+   model = "eTSEC";
+   fsl,magic-packet;
+   ranges;
+
+   queue-group@2d1 {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d1 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+
+   queue-group@2d14000  {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d14000 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+   };
+
+   enet1: ethernet@2d5 {
+   compatible = "fsl,etsec2";
+   device_type = "network";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&gic>;
+   model = "eTSEC";
+   ranges;
+
+   queue-group@2d5  {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d5 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+
+   queue-group@2d54000  {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d54000 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+   };
+
+   enet2: ethernet@2d9 {
+   compatible = "fsl,etsec2";
+   device_type = "network";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&gic>;
+   model = "eTSEC";
+   ranges;
+
+   queue-group@2d9  {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d9 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+
+   queue-group@2d94000  {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   reg = <0x0 0x2d94000 0x0 0x1000>;
+   interrupts = ,
+   ,
+   ;
+   };
+   };
+
usb@860 {
compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
reg = <0x0 0x860 0x0 0x1000>;
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

[Timo Sigurdsson]

Hi,

Maxime Ripard schrieb am 28.07.2015 14:55:
>> IMHO for a common maximum opp that's a good approach. But for the lowest
>> frequency setting, it would seem more logical to me, to raise the voltage
>> to a point where all boards will run fine with them, unless those boards 
>> cannot handle the frequency regardless of the higher voltage.
> 
> Agreed.

Ok, then I will write another patch for this as well, unless Chen-Yu or
someone else objects.

Regards,

Timo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH,v3 3/3] ARM: dts: ls1021a: Enable the eTSEC ports on QDS and TWR

[Claudiu Manoil]

This enables the available eTSEC ethernet ports for the
ls1021aqds and ls1021atwr boards.
For the QDS, SGMII connections (via riser cards) are assumed
for the eTSEC0 and eTSEC1 ports as default configuration.

Signed-off-by: Alison Wang 
Signed-off-by: Claudiu Manoil 
---
v2, v3 - none;

 arch/arm/boot/dts/ls1021a-qds.dts | 20 
 arch/arm/boot/dts/ls1021a-twr.dts | 20 
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-qds.dts 
b/arch/arm/boot/dts/ls1021a-qds.dts
index 9c5e16b..f16a061 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -75,6 +75,26 @@
};
 };
 
+&enet0 {
+   tbi-handle = <&tbi0>;
+   phy-handle = <&sgmii_phy1c>;
+   phy-connection-type = "sgmii";
+   status = "okay";
+};
+
+&enet1 {
+   tbi-handle = <&tbi0>;
+   phy-handle = <&sgmii_phy1d>;
+   phy-connection-type = "sgmii";
+   status = "okay";
+};
+
+&enet2 {
+   phy-handle = <&rgmii_phy3>;
+   phy-connection-type = "rgmii-id";
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..4b61766 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -73,6 +73,26 @@
};
 };
 
+&enet0 {
+   tbi-handle = <&tbi1>;
+   phy-handle = <&sgmii_phy2>;
+   phy-connection-type = "sgmii";
+   status = "okay";
+};
+
+&enet1 {
+   tbi-handle = <&tbi1>;
+   phy-handle = <&sgmii_phy0>;
+   phy-connection-type = "sgmii";
+   status = "okay";
+};
+
+&enet2 {
+   phy-handle = <&rgmii_phy1>;
+   phy-connection-type = "rgmii-id";
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 };
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH,v3 1/3] doc: dt: Update eTSEC bindings doc

[Claudiu Manoil]

Update the eTSEC bindings document with missing info on
properties that are already in use for the PPC platforms:
* "tbi-phy" property;
* "fsl,etsec2" compatibility string;

Signed-off-by: Claudiu Manoil 
---
v2 - none;
v3 - added "tbi-handle" documentation;
   - fixed typo ("fsl,etsec2" is the correct string);

 Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt 
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 1e97532..325c07d 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -45,12 +45,15 @@ Properties:
 
   - device_type : Should be "network"
   - model : Model of the device.  Can be "TSEC", "eTSEC", or "FEC"
-  - compatible : Should be "gianfar"
+  - compatible : "gianfar", "fsl,etsec2"
   - reg : Offset and length of the register set for the device
   - interrupts : For FEC devices, the first interrupt is the device's
 interrupt.  For TSEC and eTSEC devices, the first interrupt is
 transmit, the second is receive, and the third is error.
   - phy-handle : See ethernet.txt file in the same directory.
+  - tbi-handle : Handle to a tbi-phy node containing information about
+the TBIPA register needed to initialize the TBI PHY.  See
+"TBI Internal MDIO bus", this document.
   - fixed-link : See fixed-link.txt in the same directory.
   - phy-connection-type : See ethernet.txt file in the same directory.
 This property is only really needed if the connection is of type
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html