Re: [PATCHv3 00/10] ARM: DRA7: add display support
On 01/06/15 08:46, Paul Walmsley wrote: Hi Tomi On Wed, 6 May 2015, Tomi Valkeinen wrote: This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. This series is v3, and is based on v4.1-rc2. There are no differences to v2, except rebased and tested. Are you still planning to move the DESHDCP clock enable to the beginning of the series to avoid the warnings, per: http://www.spinics.net/lists/arm-kernel/msg410968.html Sorry, I totally forgot that. I will do that and send a v4. Also, not sure if you can arrange for someone at TI to send over a DRA7xx board for the testbed, but it would be nice to have a board to test these patches with, to avoid issues like the one mentioned in your E-mails... I'll forward the request. Tomi signature.asc Description: OpenPGP digital signature
[PATCHv4 03/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 470f39c4e326..357bedeebfac 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1531,6 +1531,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 00/10] ARM: DRA7: add display support
Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. The difference to v4 is that the DESHDCP patches were moved to the beginning of the series to fix boot issues if bisecting. Tomi Tomi Valkeinen (10): arm: dra7: add DESHDCP clock CLK: TI: always enable DESHDCP clock arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP: display: change compat names to array ARM: OMAP2+: display: detect DRA7 DSS arm/dts: dra7.dtsi: add DSS support arm/dts: dra72-evm.dts: add HDMI arm/dts: am57xx-beagle-x15.dts: add HDMI arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 ++ arch/arm/boot/dts/dra7.dtsi | 43 arch/arm/boot/dts/dra72-evm.dts | 110 ++ arch/arm/boot/dts/dra72x.dtsi | 11 +++ arch/arm/boot/dts/dra74x.dtsi | 15 arch/arm/boot/dts/dra7xx-clocks.dtsi | 11 +++ arch/arm/mach-omap2/display.c | 32 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 33 + drivers/clk/ti/clk-7xx.c | 8 ++- 9 files changed, 328 insertions(+), 16 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 02/10] CLK: TI: always enable DESHDCP clock
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.
As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.
Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.
So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 2dd956b9affa..63b8323df918 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -312,7 +312,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
int __init dra7xx_dt_clk_init(void)
{
int rc;
- struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
ti_dt_clocks_register(dra7xx_clks);
@@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
+ hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+ rc = clk_prepare_enable(hdcp_ck);
+ if (rc)
+ pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 01/10] arm: dra7: add DESHDCP clock
Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
drivers/clk/ti/clk-7xx.c | 1 +
4 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5332b57b4950..db0890a36e96 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -131,6 +131,11 @@
regulator-max-microvolt
= 300;
};
};
+
+ scm_conf_clocks: clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3b933f74d000..470f39c4e326 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2136,3 +2136,13 @@
clocks = dpll_usb_ck;
};
};
+
+scm_conf_clocks {
+ dss_deshdcp_clk: dss_deshdcp_clk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l3_iclk_div;
+ ti,bit-shift = 0;
+ reg = 0x558;
+ };
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0e64c2fac0b5..817dbd87ce67 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -438,6 +438,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = video2_clk, .clk = dss_video2_clk },
{ .role = video1_clk, .clk = dss_video1_clk },
{ .role = hdmi_clk, .clk = dss_hdmi_clk },
+ { .role = hdcp_clk, .clk = dss_deshdcp_clk },
};
static struct omap_hwmod dra7xx_dss_hwmod = {
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 5d2217ae4478..2dd956b9affa 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -305,6 +305,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(4882c000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(4882e000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(NULL, sys_clkin, sys_clkin1),
+ DT_CLK(NULL, dss_deshdcp_clk, dss_deshdcp_clk),
{ .node_name = NULL },
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 09/10] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 110
1 file changed, 110 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index ce0390f081d9..4e1b60581782 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
+ aliases {
+ display0 = hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
@@ -35,6 +39,51 @@
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 2 GPIO_ACTIVE_HIGH;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+ pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -45,6 +94,13 @@
;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ ;
+ };
+
nand_default: nand_default {
pinctrl-single,pins =
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -142,6 +198,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1) /* gpmc_cs2.qspi1_cs0 */
;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ ;
+ };
};
i2c1 {
@@ -277,6 +346,27 @@
};
};
+i2c5 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+ clock-frequency = 40;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = 0x0f2b;
+ };
+};
+
uart1 {
status = okay;
};
@@ -566,3 +656,23 @@
};
};
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 08/10] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index db0890a36e96..f3a8237cea39 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1474,6 +1474,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ dss: dss@5800 {
+ compatible = ti,dra7-dss;
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = disabled;
+ ti,hwmods = dss_core;
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = scm_conf 0x538;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,dra7-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = scm_conf 0x534;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,dra7-hdmi;
+ reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_hdmi_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
thermal_zones: thermal-zones {
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index 03d742f8d572..eaca143faa77 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -34,3 +34,14 @@
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH;
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1;
+
+ clocks = dss_dss_clk,
+dss_video1_clk;
+ clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index cc560a70926f..fa995d0ca1f2 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -73,3 +73,18 @@
};
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1,
+ pll2_clkctrl, pll2;
+
+ clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+ clock-names = fck, video1_clk, video2_clk;
+};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 07/10] ARM: OMAP2+: display: detect DRA7 DSS
Add platform code to detect DRA7 DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -287,6 +287,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+ else if (soc_is_dra7xx())
+ return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
}
@@ -573,6 +575,7 @@ static const char * const omapdss_compat_names[]
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+ ti,dra7-dss,
};
struct device_node * __init omapdss_find_dss_of_node(void)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 05/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index f6b94854fafc..9961f95f52ae 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -522,6 +522,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr = dss_dispc_dev_attr,
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
@@ -563,6 +564,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 06/10] ARM: OMAP: display: change compat names to array
Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index f492ae147c6a..9868d0bc7805 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -568,25 +568,24 @@ void __init omapdss_early_init_of(void)
}
+static const char * const omapdss_compat_names[] __initconst = {
+ ti,omap2-dss,
+ ti,omap3-dss,
+ ti,omap4-dss,
+ ti,omap5-dss,
+};
+
struct device_node * __init omapdss_find_dss_of_node(void)
{
struct device_node *node;
+ int i;
- node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
- if (node)
- return node;
+ for (i = 0; i ARRAY_SIZE(omapdss_compat_names); ++i) {
+ node = of_find_compatible_node(NULL, NULL,
+ omapdss_compat_names[i]);
+ if (node)
+ return node;
+ }
return NULL;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 04/10] ARM: DRA7: hwmod: add DMM hwmod description
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 817dbd87ce67..f6b94854fafc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
*/
/*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+ .name = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+ .name = dmm,
+ .class = dra7xx_dmm_hwmod_class,
+ .clkdm_name = emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'l3' class
* instance(s): l3_instr, l3_main_1, l3_main_2
*/
@@ -2322,6 +2343,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
* Interfaces
*/
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_dmm_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_SDMA,
+};
+
/* l3_main_2 - l3_instr */
static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3290,6 +3319,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2
= {
};
static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+ dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
1 file changed, 81 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 15f198e4864d..f1e430507e4f 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -18,6 +18,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ display0 = hdmi0;
};
memory {
@@ -102,6 +103,51 @@
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio7 10 GPIO_ACTIVE_HIGH, /* gpio7_10, CT CP HPD
*/
+ gpio6 28 GPIO_ACTIVE_HIGH, /* gpio6_28, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -121,6 +167,13 @@
;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ ;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins =
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_ctsn.gpio7_24 */
;
};
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ ;
+ };
};
i2c1 {
@@ -607,3 +668,23 @@
};
};
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: DRA7: Add TBCLK for PWMSS
tbclk is used by ehrpwm to generate PWM waveform on DRA7 SoC. Add Linux
clock to control ehrpwm tbclk.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 26 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f03a091cd076..387c76ca41f9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -131,6 +131,11 @@
regulator-max-microvolt
= 300;
};
};
+
+ scm_conf_clocks: clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3b933f74d000..92452d61cf58 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2136,3 +2136,29 @@
clocks = dpll_usb_ck;
};
};
+
+scm_conf_clocks {
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l4_root_clk_div;
+ ti,bit-shift = 20;
+ reg = 0x0558;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l4_root_clk_div;
+ ti,bit-shift = 21;
+ reg = 0x0558;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l4_root_clk_div;
+ ti,bit-shift = 22;
+ reg = 0x0558;
+ };
+};
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
program clock domain to SW_WKUP.
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 57d5df0c1fbd..7581e036bda6 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
.dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT,
.wkdep_srcs = l4per2_wkup_sleep_deps,
.sleepdep_srcs= l4per2_wkup_sleep_deps,
- .flags= CLKDM_CAN_HWSUP_SWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain mpu0_7xx_clkdm = {
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] clk: ti: DRA7: Add tbclk data for ehrpwm
tbclk is needed by ehrpwm to generate pwm waveforms. Hence, register
the required clock information.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/clk/ti/clk-7xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 5d2217ae4478..366be43d15fe 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -304,6 +304,9 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(4882a000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(4882c000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(4882e000.timer, timer_sys_ck, timer_sys_clk_div),
+ DT_CLK(4843e200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48440200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48442200.ehrpwm, tbclk, ehrpwm2_tbclk),
DT_CLK(NULL, sys_clkin, sys_clkin1),
{ .node_name = NULL },
};
--
2.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: dts: DRA7: Add dt nodes for PWMSS
Add PWMSS device tree nodes for DRA7 SoC family and add documentation
for dt bindings.
Signed-off-by: Vignesh R vigne...@ti.com
---
.../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 +++
.../devicetree/bindings/pwm/pwm-tipwmss.txt| 17 +-
arch/arm/boot/dts/dra7.dtsi| 64 ++
3 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 9c100b2c5b23..25d91ae57de5 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Must be ti,soc-ehrpwm.
for am33xx - compatible = ti,am33xx-ehrpwm;
for da850 - compatible = ti,da850-ehrpwm, ti,am33xx-ehrpwm;
+ for dra7xx - compatible = ti,dra7xx-ehrpwm, ti,am33xx-ehrpwm;
- #pwm-cells: should be 3. See pwm.txt in this directory for a description of
the cells format. The only third cell flag supported by this binding is
PWM_POLARITY_INVERTED.
@@ -27,3 +28,10 @@ ehrpwm0: ehrpwm@0 { /* EHRPWM on da850 */
#pwm-cells = 3;
reg = 0x30 0x2000;
};
+
+ehrpwm0: ehrpwm@0 { /* EHRPWM on dra7xx */
+ compatible = ti,dra7xx-ehrpwm, ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48440200 0x80;
+ ti,hwmods = ehrpwm0;
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
index f7eae77f8354..9270ce6b2da2 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
@@ -1,7 +1,9 @@
TI SOC based PWM Subsystem
Required properties:
-- compatible: Must be ti,am33xx-pwmss;
+- compatible: Must be ti,soc-pwmss.
+ for am33xx - compatible = ti,am33xx-pwmss
+ for dra7xx - compatible = ti,dra7xx-pwmss, ti,am33xx-pwmss
- reg: physical base address and size of the registers map.
- address-cells: Specify the number of u32 entries needed in child nodes.
Should set to 1.
@@ -29,3 +31,16 @@ pwmss0: pwmss@4830 {
/* child nodes go here */
};
+
+epwmss0: epwmss@4843e000 { /* On DRA7xx */
+ compatible = ti,dra7xx-pwmss, ti,am33xx-pwmss;
+ reg = 0x4843e000 0x30;
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0x4843e100 0x4843e100 0x80 /* ECAP */
+ 0x4843e180 0x4843e180 0x80 /* EQEP */
+ 0x4843e200 0x4843e200 0x80; /* EHRPWM */
+
+ /* child nodes go here */
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 387c76ca41f9..98a9203d6992 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1474,6 +1474,70 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ epwmss0: epwmss@4843e000 {
+ compatible = ti,dra7xx-pwmss, ti,am33xx-pwmss;
+ reg = 0x4843e000 0x30;
+ ti,hwmods = epwmss0;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges = 0x4843e100 0x4843e100 0x80 /* ECAP */
+ 0x4843e180 0x4843e180 0x80 /* EQEP */
+ 0x4843e200 0x4843e200 0x80;/* EHRPWM */
+
+ ehrpwm0: ehrpwm@4843e200 {
+ compatible = ti,dra7xx-ehrpwm,
+ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x4843e200 0x80;
+ ti,hwmods = ehrpwm0;
+ status = disabled;
+ };
+ };
+
+ epwmss1: epwmss@4844 {
+ compatible = ti,dra7xx-pwmss, ti,am33xx-pwmss;
+ reg = 0x4844 0x30;
+ ti,hwmods = epwmss1;
+ #address-cells = 1;
+ #size-cells = 1;
+ status = disabled;
+ ranges = 0x48440100 0x48440100 0x80 /* ECAP */
+ 0x48440180 0x48440180 0x80 /* EQEP */
+ 0x48440200 0x48440200 0x80; /* EHRPWM */
+
+ ehrpwm1: ehrpwm@48440200 {
+ compatible = ti,dra7xx-ehrpwm,
+ti,am33xx-ehrpwm;
+ #pwm-cells = 3;
+ reg = 0x48440200 0x80;
+ ti,hwmods = ehrpwm1;
+ status = disabled;
+ };
+ };
+
+ epwmss2: epwmss@48442000 {
+
Re: [PATCH 1/7] gpio: omap: fix omap_gpio_free to not clean up irq configuration
On Fri, May 22, 2015 at 4:35 PM, Grygorii Strashko grygorii.stras...@linaro.org wrote: This patch fixes following issue: - GPIOn is used as IRQ by some dev, for example PCF8575.INT - gpio6.11 - PCFx driver knows nothing about type of IRQ line (GPIO or not) so it doesn't request gpio and just do request_irq() - If gpio6.11 will be exported through the sysfs and then un-xeported then IRQs from PCFx will not be received any more, because IRQ configuration for gpio6.11 will be cleaned up unconditionally in omap_gpio_free. Fix this by removing all GPIO IRQ specific code from omap_gpio_free() and also do GPIO clean up (change direction to 'in' and disable debounce) only if corresponding GPIO is not used as IRQ too. GPIO IRQ will be properly cleaned up by GPIO irqchip code. Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Can I get an ACK or comment from one of the three (!) maintainers on atleast these non-RFC patches? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Add support for PWMSS on DRA7
Hi, This patch series adds support for PWMSS on DRA7. The IP is same as that present in AM33XX and AM43XX. The first patch changes clock domain in which PWMSS is present (l4per2_7xx_clkdm) to SW_WKUP. This is because legacy IPs like PWM does'nt support HW_AUTO prorperly. Hence, switch clock domain to SW_WKUP. This is based on the input from the hardware team. The rest of the patches add hwmod and dt entries and enable PWMSS on DRA7 based SoCs. Vignesh R (5): ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS ARM: dts: DRA7: Add TBCLK for PWMSS clk: ti: DRA7: Add tbclk data for ehrpwm ARM: dts: DRA7: Add dt nodes for PWMSS .../devicetree/bindings/pwm/pwm-tiehrpwm.txt | 8 + .../devicetree/bindings/pwm/pwm-tipwmss.txt| 17 +- arch/arm/boot/dts/dra7.dtsi| 69 ++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 26 +++ arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 + drivers/clk/ti/clk-7xx.c | 3 + 7 files changed, 362 insertions(+), 2 deletions(-) -- 2.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 05/25] gpio: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
On Wed, May 20, 2015 at 11:59 AM, Jiang Liu jiang@linux.intel.com wrote: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Are there dependencies on this patch or can I just apply it directly to the GPIO tree? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Add hwmod entries for the PWMSS on DRA7.
Signed-off-by: Vignesh R vigne...@ti.com
---
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,
+ .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,
+ },
+ },
+};
+
+/* ecap0 */
+struct omap_hwmod dra7xx_ecap0_hwmod = {
+ .name = ecap0,
+ .class = dra7xx_ecap_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* eqep0 */
+struct omap_hwmod dra7xx_eqep0_hwmod = {
+ .name = eqep0,
+ .class = dra7xx_eqep_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* ehrpwm0 */
+struct omap_hwmod dra7xx_ehrpwm0_hwmod = {
+ .name = ehrpwm0,
+ .class = dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* epwmss1 */
+struct omap_hwmod dra7xx_epwmss1_hwmod = {
+ .name = epwmss1,
+ .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_PWMSS2_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* ecap1 */
+struct omap_hwmod dra7xx_ecap1_hwmod = {
+ .name = ecap1,
+ .class = dra7xx_ecap_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* eqep1 */
+struct omap_hwmod dra7xx_eqep1_hwmod = {
+ .name = eqep1,
+ .class = dra7xx_eqep_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* ehrpwm1 */
+struct omap_hwmod dra7xx_ehrpwm1_hwmod = {
+ .name = ehrpwm1,
+ .class = dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* epwmss2 */
+struct omap_hwmod dra7xx_epwmss2_hwmod = {
+ .name = epwmss2,
+ .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_PWMSS3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS3_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* ecap2 */
+struct omap_hwmod dra7xx_ecap2_hwmod = {
+ .name = ecap2,
+ .class = dra7xx_ecap_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* eqep2 */
+struct omap_hwmod dra7xx_eqep2_hwmod = {
+ .name = eqep2,
+ .class = dra7xx_eqep_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk = l4_root_clk_div,
+};
+
+/* ehrpwm2 */
+struct omap_hwmod dra7xx_ehrpwm2_hwmod = {
+ .name = ehrpwm2,
+ .class = dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = l4per2_clkdm,
+ .main_clk =
Re: [RFC PATCH 2/2] usb: dwc3: Add chained TRB support for ep0
Hi Felipe,
On Friday 06 February 2015 08:18 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 06, 2015 at 05:25:35PM +0530, Kishon Vijay Abraham I wrote:
dwc3 can do only max packet aligned transfers. So in case request length
is not max packet aligned and is bigger than DWC3_EP0_BOUNCE_SIZE
two chained TRBs is required to handle the transfer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
*) Did eumeration testing with g_zero in kernel
*) Similar patch was added in u-boot. With DFU, was able to create a scenario
where the request length is not max packet aligned and is bigger than
DWC3_EP0_BOUNCE_SIZE (512 bytes). In that case, 2 chained TRBs will be used.
I really need a test case for this. If you have to patch g_zero to have
a configuration descriptor so large that it's over 512, so be it, but I
really need to have a test case exposing the problem.
sure.
I also need you to run full USB30CV (for USB2 and USB3 device), together
with Link Layer Tests (on USB3-only, clearly) using USB30CV and LeCroy's
compliance suite (there's a slight difference from USB30CV and LeCroy's
compliance, we must work with both because both are accepted test
vectors per USB-IF).
sure.
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 24b7925..3b728b8 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state
state)
}
static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t
buf_dma,
- u32 len, u32 type)
+ u32 len, u32 type, unsigned chain)
{
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_trb *trb;
@@ -70,7 +70,10 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
return 0;
}
- trb = dwc-ep0_trb;
+ trb = dwc-ep0_trb[dep-free_slot];
+
+ if (chain)
+ dep-free_slot++;
trb-bpl = lower_32_bits(buf_dma);
trb-bph = upper_32_bits(buf_dma);
@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
trb-ctrl = type;
trb-ctrl |= (DWC3_TRB_CTRL_HWO
- | DWC3_TRB_CTRL_LST
- | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);
+ if (chain)
+ trb-ctrl |= DWC3_TRB_CTRL_CHN;
+ else
+ trb-ctrl |= (DWC3_TRB_CTRL_IOC
+ | DWC3_TRB_CTRL_LST);
+
+ if (chain)
+ return 0;
+
memset(params, 0, sizeof(params));
params.param0 = upper_32_bits(dwc-ep0_trb_addr);
params.param1 = lower_32_bits(dwc-ep0_trb_addr);
@@ -302,7 +312,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
int ret;
ret = dwc3_ep0_start_trans(dwc, 0, dwc-ctrl_req_addr, 8,
- DWC3_TRBCTL_CONTROL_SETUP);
+ DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret 0);
}
@@ -817,6 +827,22 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
maxp = ep0-endpoint.maxpacket;
+ /* Handle the first TRB before handling the bounce buffer if the request
+* length is greater than the bounce buffer size
+*/
+ if (!IS_ALIGNED(ur-length, maxp)
+ ur-length DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = (ur-length / maxp) * maxp;
you can use ALIGN() for this which is more efficient. Note however that
this is not safe, see below.
right, I can achieve the same using ALIGN(ur-length - maxp, maxp);
+ transferred = transfer_size - length;
+ buf = (u8 *)buf + transferred;
+ ur-actual += transferred;
this is dangerous. The extra size is because you *must* align OUT to
wMaxPacketSize, so you cannot allow more than the original req-length
to be copied into buf. That bounce buffer, is really supposed to be a
Here we are not handling bounce buffer. The bounce buffer is used only for the
2nd TRB which actually programs to receive data that is less than bounce buffer
size. The 1st TRB will always be max packet aligned and the data is directly
copied to the request buffer. (However note that if the request length is less
than bounce buffer size, we'll use 1 TRB only)
To summarize..
We are splitting req-length into 2 TRB's if the req-length is not aligned to
wMaxPacketSize _and_ req-length is greater than bounce buffer size. By this
way we can make the 2nd TRB to receive data lesser than or equal to bounce
buffer size and the rest of it can be received using the 1st TRB.
Consider the following case.
ur-length = 612;
maxp = 512;
This case can't be handled by the existing bounce buffer mechanism since the
size of bounce buffer is only 512. So we program 2 TRB's.
First TRB
trb-size = 512; /* We don't need bounce buffer for this TRB since it is max
packet aligned. The data is
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Sat, May 30, 2015 at 12:14:30PM +0200, Pavel Machek wrote: Well... the driver was not broken... before you did cleanup that did two functional changes. And yes, the dts should be fixed, but that does not make your cleanup good. Whether it's good or not is arguable, and it really boils down to what we consider the default value when properties are missing. If it's 0, then my code does the right thing. If it's undefined, well, I'd expect undefined behaviour to change without any notice. Feel free to suggest any better solution. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Fri, May 29, 2015 at 10:34:56PM +0200, Pavel Machek wrote: Hi! single DT, you don't even use that property in your driver, and now that you realise you meant something else, you want the code that not Pali, Sebastian. actually parse the *right* property and does the right thing, that all other DT agree (and depend on) to be reverted? We shouldn't revert, that I agree. But both properties should be parsed. No. If the property is wrong, and nobody parsed it, I do not see any reason to start now. Agreed. But that's not what I'm asking. See a changelog of 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it actually does. It is buggy. If fuzz is specified but maximum is not, it overwites maximum with zero. If maximum is not set, you'll have other issues anyway. But it really boils down on what the default behaviour should be. Plus it introduces new failure if (!test_bit(axis, dev-absbit)). It's not a new failure, it's testing against stupid code. If an axis is setup in the DT but not registered in the driver, something is wrong, most probably the DT. Plus it fails to distinguish between value not specified in the dt and zero is specified in the dt. Again, default behaviour. The 3eea8b5d68c801fec788b411582b803463834752 is just bad. You were very welcome to review this patch at the time and/or suggest a fix that pleases everyone. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
OMAP baseline test results for v4.1-rc6
Here are some basic OMAP test results for Linux v4.1-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (14/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc5 (ba155e2d21f6bf05de86a78dbe5bfd8757604a65)): text data bsstotal kernel +5600 +56 omap1_defconfig +4800 +48 omap1_defconfig_1510innovator_only +4800 +48 omap1_defconfig_5912osk_only +26779 +2640 +27043 multi_v7_defconfig +107100+1071 omap2plus_defconfig +584 +640 +648 omap2plus_defconfig_2430sdp_only +107100+1071 omap2plus_defconfig_am33xx_only +107500+1075 omap2plus_defconfig_am43xx_only +107100+1071 omap2plus_defconfig_cpupm +107500+1075
Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900
On Mon 2015-06-01 11:49:19, Maxime Ripard wrote: On Sat, May 30, 2015 at 12:14:30PM +0200, Pavel Machek wrote: Well... the driver was not broken... before you did cleanup that did two functional changes. And yes, the dts should be fixed, but that does not make your cleanup good. Whether it's good or not is arguable, and it really boils down to what we consider the default value when properties are missing. If it's 0, then my code does the right thing. If it's undefined, well, I'd expect undefined behaviour to change without any notice. It is whatever was in the structure in the first place, as it was before you patched the code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: AM35xx: fix system control module clocks
New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/boot/dts/am35xx-clocks.dtsi b/arch/arm/boot/dts/am35xx-clocks.dtsi index 518b8fd..18cc826 100644 --- a/arch/arm/boot/dts/am35xx-clocks.dtsi +++ b/arch/arm/boot/dts/am35xx-clocks.dtsi @@ -12,7 +12,7 @@ #clock-cells = 0; compatible = ti,am35xx-gate-clock; clocks = ipss_ick; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 1; }; @@ -20,7 +20,7 @@ #clock-cells = 0; compatible = ti,gate-clock; clocks = rmii_ck; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 9; }; @@ -28,7 +28,7 @@ #clock-cells = 0; compatible = ti,am35xx-gate-clock; clocks = ipss_ick; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 2; }; @@ -36,7 +36,7 @@ #clock-cells = 0; compatible = ti,gate-clock; clocks = pclk_ck; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 10; }; @@ -44,7 +44,7 @@ #clock-cells = 0; compatible = ti,am35xx-gate-clock; clocks = ipss_ick; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 0; }; @@ -52,7 +52,7 @@ #clock-cells = 0; compatible = ti,gate-clock; clocks = sys_ck; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 8; }; @@ -60,7 +60,7 @@ #clock-cells = 0; compatible = ti,am35xx-gate-clock; clocks = sys_ck; - reg = 0x059c; + reg = 0x032c; ti,bit-shift = 3; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v4.1-rc5
On 06/01/2015 08:49 AM, Paul Walmsley wrote: + Tero Hello Jeroen, On Mon, 1 Jun 2015, Jeroen Hofstee wrote: On 30-05-15 17:56, Jeroen Hofstee wrote: Hello Paul, On 30-05-15 17:50, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v4.1-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc5/20150529162206/ The cmt3517 seems to have these some In-Band errors. Do you happen to know where these are coming from? git bisect + some workarounds seem to indicate: d744ce37b721d6678f420ba0fb058f615eb015b6 is the first bad commit commit d744ce37b721d6678f420ba0fb058f615eb015b6 Author: Tero Kristo t-kri...@ti.com Date: Tue Feb 24 16:22:45 2015 +0200 ARM: dts: omap3: add minimal l4 bus layout with control module support This patch creates an l4_core interconnect for OMAP3, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM node as the clock provider. Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Tony Lindgren t...@atomide.com I haven't looked further into it yet, Interesting; thanks for the bisect. In the mainline kernel, this appears to be commit b8845074cfbbd1d1b46720a1b563d7b4240dac21. I took a quick look at the control module offsets in that patch, and they appear to match what's in the SPRUGR0B PDF. Will try a few test boots here to confirm your findings. Tero, care to take a look? Yes, seems I have introduced a bug with this patch on am35xx only. I missed updating part of the am35xx related dts files. Will post a fix in a bit. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
Hello Tero, On 01-06-15 17:30, Tero Kristo wrote: New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) With this patch the error interrupt / stack dumps are no longer present. Thanks, Tested-by: Jeroen Hofstee jer...@myspectrum.nl -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
You were very welcome to review this patch at the time and/or suggest
a fix that pleases everyone.
You should be the one that should suggest fixes, as you broke it in
the first place. But clearly you don't understand that.
You actually never asked for a fix, and went head first calling this
patch bad and asking for nothing but reverting it.
Date: Fri, 29 May 2015 21:08:16 +0200
Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
linux-n900
...
Maxime, can you suggest a fix?
...
diff --git a/drivers/input/touchscreen/of_touchscreen.c
b/drivers/input/touchscreen/of_touchscreen.c
index b82b5207c78b..7e98c2e443ab 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -14,10 +14,10 @@
#include linux/input/mt.h
#include linux/input/touchscreen.h
-static u32 of_get_optional_u32(struct device_node *np,
+static int of_get_optional_u32(struct device_node *np,
const char *property)
{
- u32 val = 0;
+ int val = -1;
of_property_read_u32(np, property, val);
@@ -42,8 +42,12 @@ static void touchscreen_set_params(struct input_dev *dev,
}
absinfo = dev-absinfo[axis];
- absinfo-maximum = max;
- absinfo-fuzz = fuzz;
+
+ if (max = 0)
+ absinfo-maximum = max;
+
+ if (fuzz = 0)
+ absinfo-fuzz = fuzz;
}
/**
@@ -57,7 +61,7 @@ static void touchscreen_set_params(struct input_dev *dev,
void touchscreen_parse_of_params(struct input_dev *dev)
{
struct device_node *np = dev-dev.parent-of_node;
- u32 maximum, fuzz;
+ int maximum, fuzz;
input_alloc_absinfo(dev);
if (!dev-absinfo)
-- 8 --
That reduces the max size of the screens, but I don't really expect the screen
size to reach that order of magnitude before a few years...
Umm. Won't you have to update
- if (maximum || fuzz)
+ if (maximum = 0 || fuzz = 0)
? Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT PATCH 0/7] gpio: omap: rework and fixes
On Fri, May 22, 2015 at 9:03 PM, Tony Lindgren t...@atomide.com wrote: * Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]: Patches 1-5 seem to work for me, patch 6 does not. So for patches 1-5, please feel free to add: Tested-by: Tony Lindgren t...@atomide.com OK I take this as an excuse to apply patches 1-5 with Tony's test tag. The maintainers can cheer in if they want, I will anyway take the OMAP maintainers test tag as a good quality indication. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi,
On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
From: NeilBrown ne...@suse.de
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
Little sceptical about adding new sysfs entries. Do you have a good reason to
add this?
Thanks
Kishon
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek pa...@ucw.cz
Signed-off-by: NeilBrown ne...@suse.de
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: on, off.
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ unknown indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb *twl,
int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
+ floating,
+ unknown
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl-dev);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0 || !(ret ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret 0 || (ret 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ if (ret 0)
+ return TWL4030_ID_UNKNOWN;
+ ret = ffs(ret) - 1;
+ if (ret TWL4030_GROUND || ret TWL4030_FLOATING)
+ return TWL4030_ID_UNKNOWN;
+
+ return ret;
+}
+
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
@@ -532,6 +582,16 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
}
static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
+static ssize_t twl4030_usb_id_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ return scnprintf(buf, PAGE_SIZE, %s\n,
+twl4030_id_names[twl4030_get_id(twl)]);
+}
+static DEVICE_ATTR(id, 0444, twl4030_usb_id_show, NULL);
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -709,6 +769,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(pdev-dev, dev_attr_id))
+ dev_warn(pdev-dev, could not create sysfs file\n);
ATOMIC_INIT_NOTIFIER_HEAD(twl-phy.notifier);
@@ -753,6 +815,7 @@ static int twl4030_usb_remove(struct platform_device *pdev)
pm_runtime_get_sync(twl-dev);
cancel_delayed_work(twl-id_workaround_work);
device_remove_file(twl-dev, dev_attr_vbus);
+ device_remove_file(twl-dev, dev_attr_id);
/* set transceiver mode to power on defaults */
twl4030_usb_set_mode(twl, -1);
--
To unsubscribe from this list: send the line
Re: [RFC v1 05/25] gpio: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
On 2015/6/1 20:45, Linus Walleij wrote: On Wed, May 20, 2015 at 11:59 AM, Jiang Liu jiang@linux.intel.com wrote: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Are there dependencies on this patch or can I just apply it directly to the GPIO tree? Hi Linus, Thanks for review. There's a very long dependency list of this patch set, so it would be safer to merge this patch set altogether through the irq tree if that works:) Thanks! Gerry Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
Hi! But that's not what I'm asking. See a changelog of 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it actually does. It is buggy. If fuzz is specified but maximum is not, it overwites maximum with zero. If maximum is not set, you'll have other issues anyway. But it really boils down on what the default behaviour should be. It was not broken before commit 3eea8b5d68c801fec788b411582b803463834752. Maximum was set, but after your patch, it is overwritten with zero. Plus it introduces new failure if (!test_bit(axis, dev-absbit)). It's not a new failure, it's testing against stupid code. Yes. In a commit marked cleanup. We call this undocumented feature. If an axis is setup in the DT but not registered in the driver, something is wrong, most probably the DT. Yes, we have fixed the DT, so that bug you introduced will not happen on n900 with updated device tree. Plus it fails to distinguish between value not specified in the dt and zero is specified in the dt. Again, default behaviour. Again, regression from 4.0 kernel, you are not willing to fix. The 3eea8b5d68c801fec788b411582b803463834752 is just bad. You were very welcome to review this patch at the time and/or suggest a fix that pleases everyone. You should be the one that should suggest fixes, as you broke it in the first place. But clearly you don't understand that. Dmitry, please revert 3eea8b5d68c801fec788b411582b803463834752 . You'll probably need to revert 0a363a380954e10fece7cd9931b66056eeb07d56 too. Then, Maxime can submit his multitouch patches in a way it does not break existing setups. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon, Jun 01, 2015 at 04:06:06PM +0200, Pavel Machek wrote:
Hi!
But that's not what I'm asking. See a changelog of
3eea8b5d68c801fec788b411582b803463834752 and compare it with what it
actually does.
It is buggy. If fuzz is specified but maximum is not, it overwites
maximum with zero.
If maximum is not set, you'll have other issues anyway. But it really
boils down on what the default behaviour should be.
It was not broken before commit
3eea8b5d68c801fec788b411582b803463834752. Maximum was set, but after
your patch, it is overwritten with zero.
Plus it introduces new failure if (!test_bit(axis, dev-absbit)).
It's not a new failure, it's testing against stupid code.
Yes. In a commit marked cleanup. We call this undocumented
feature.
It has never been said that it was a cleanup (whatever the double
quotes mean) but a rework. And it's not a feature either.
If an axis is setup in the DT but not registered in the driver,
something is wrong, most probably the DT.
Yes, we have fixed the DT, so that bug you introduced will not happen
on n900 with updated device tree.
s/updated/fixed/
Plus it fails to distinguish between value not specified in the dt
and zero is specified in the dt.
Again, default behaviour.
Again, regression from 4.0 kernel, you are not willing to fix.
The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
You were very welcome to review this patch at the time and/or suggest
a fix that pleases everyone.
You should be the one that should suggest fixes, as you broke it in
the first place. But clearly you don't understand that.
You actually never asked for a fix, and went head first calling this
patch bad and asking for nothing but reverting it.
It's not really a very good way to move forward and start a productive
discussion.
I'm sorry if this cause you any issues, but reverting this patch will
break users (and this time at the kernel level only, the DT has
nothing to do with that) just like you are right now.
What about:
-- 8 --
diff --git a/drivers/input/touchscreen/of_touchscreen.c
b/drivers/input/touchscreen/of_touchscreen.c
index b82b5207c78b..7e98c2e443ab 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -14,10 +14,10 @@
#include linux/input/mt.h
#include linux/input/touchscreen.h
-static u32 of_get_optional_u32(struct device_node *np,
+static int of_get_optional_u32(struct device_node *np,
const char *property)
{
- u32 val = 0;
+ int val = -1;
of_property_read_u32(np, property, val);
@@ -42,8 +42,12 @@ static void touchscreen_set_params(struct input_dev *dev,
}
absinfo = dev-absinfo[axis];
- absinfo-maximum = max;
- absinfo-fuzz = fuzz;
+
+ if (max = 0)
+ absinfo-maximum = max;
+
+ if (fuzz = 0)
+ absinfo-fuzz = fuzz;
}
/**
@@ -57,7 +61,7 @@ static void touchscreen_set_params(struct input_dev *dev,
void touchscreen_parse_of_params(struct input_dev *dev)
{
struct device_node *np = dev-dev.parent-of_node;
- u32 maximum, fuzz;
+ int maximum, fuzz;
input_alloc_absinfo(dev);
if (!dev-absinfo)
-- 8 --
That reduces the max size of the screens, but I don't really expect the screen
size to reach that order of magnitude before a few years...
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH] serial: 8250_omap: provide complete custom startup shutdown callbacks
* Greg Kroah-Hartman gre...@linuxfoundation.org [150531 15:14]: On Tue, May 26, 2015 at 09:09:26AM -0700, Tony Lindgren wrote: * Peter Hurley pe...@hurleysoftware.com [150526 07:14]: On 05/20/2015 04:07 PM, Sebastian Andrzej Siewior wrote: The currently in-use port-startup and port-shutdown are okay. The startup part for instance does the tiny omap extra part and invokes serial8250_do_startup() for the remaining pieces. The workflow in serial8250_do_startup() is okay except for the part where UART_RX is read without a check if there is something to read. I tried to workaround it in commit 0aa525d11859 (tty: serial: 8250_core: read only RX if there is something in the FIFO) but then reverted it later in commit ca8bb4aefb9 (serial: 8250: Revert tty: serial: 8250_core: read only RX if there is something in the FIFO). This is the second attempt to get it to work on older OMAPs without breaking other chips this time Peter Hurley suggested to pull in the few needed lines from serial8250_do_startup() and drop everything else that is not required including making it simpler like using just request_irq() instead the chain handler like it is doing now. So lets try that. Thanks, Sebastian. Reviewed-by: Peter Hurley pe...@hurleysoftware.com Can we please get this into the v4.1-rc series? It fixes the following: Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa06a000 ... [c04217e8] (mem_serial_in) from [c0425480] (serial8250_do_startup+0xe4/0x694) [c0425480] (serial8250_do_startup) from [c0427e48] (omap_8250_startup+0x70/0x144) [c0427e48] (omap_8250_startup) from [c0425a54] (serial8250_startup+0x24/0x30) [c0425a54] (serial8250_startup) from [c04208e4] (uart_startup.part.14+0x8c/0x1a0) [c04208e4] (uart_startup.part.14) from [c0420fec] (uart_open+0xd8/0x134) [c0420fec] (uart_open) from [c0403e50] (tty_open+0xdc/0x5e0) [c0403e50] (tty_open) from [c018f008] (chrdev_open+0xac/0x188) In looking at it closer, this is fine, I'll queue it up for 4.1-final now. OK thanks, yes I agree this fix should have been done earlier. But it does fix a fault for omaps. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: am335x-boneblack: disable RTC-only sleep
* Robert Nelson robertcnel...@gmail.com [150531 19:20]:
On Sun, May 31, 2015 at 7:20 PM, Matthijs van Duin
matthijsvand...@gmail.com wrote:
Sorry for the late response, I only just noticed this since I wasn't CC'd.
This fix was not ever Reported-By or Tested-By me as it claims. It
is in fact wrong: rtc { system-power-controller; } needs to be
present for every variety of beaglebone (more generally every design
with a TPS65217 whose PWR_EN is connected to the PMIC_POWER_EN pin of
an AM335x).
Without a system-power-controller, the kernel has no way of turning
off the system and shutdown will leave the system halted instead.
The previously posted fix, which added tps {
ti,pmic-shutdown-controller; } was correct, and ensures that a
poweroff makes the pmic enter OFF-state rather than SLEEP-state
(aka RTC-only sleep).
Sorry Matthijs, (and everyone else)
That's my fault for completely screwing up this patch..
Hmm OK. So do we now have a situation in the mainline that can
potentially cause hardware damage?
It seems we don't need to revert anything, just apply Matthijs'
new patch?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT PATCH 0/7] gpio: omap: rework and fixes
On 6/1/2015 6:15 AM, Linus Walleij wrote: On Fri, May 22, 2015 at 9:03 PM, Tony Lindgren t...@atomide.com wrote: * Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]: Patches 1-5 seem to work for me, patch 6 does not. So for patches 1-5, please feel free to add: Tested-by: Tony Lindgren t...@atomide.com OK I take this as an excuse to apply patches 1-5 with Tony's test tag. The maintainers can cheer in if they want, I will anyway take the OMAP maintainers test tag as a good quality indication. Cheers for patch 1-5 ;-) Acked-by: Santosh Shilimkar ssant...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: am335x-boneblack: disable RTC-only sleep
* Matthijs van Duin matthijsvand...@gmail.com [150531 22:16]:
Here's a version that attempts to address Tony's earlier request to
include some comments in the patch itself. Since I saw no way to
concisely summarize the issues, I included links to relevant messages
(and enough info to locate the thread again in case of link rot).
Ah finally you got around doing a proper patch :)
Since the patch itself contains more explanation, I made the commit
message more concise.
Apologies for the attachment (inline text would get fucked up by gmail)
Hmm no ideas about that, I guess people are using gmail to send email
with smtps though?
From 4278ecc32e886d2e83bc486e6409d8f6df82a0d1 Mon Sep 17 00:00:00 2001
From: Matthijs van Duin matthijsvand...@gmail.com
Date: Mon, 1 Jun 2015 06:56:24 +0200
Subject: [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
Fixes: http://bugs.elinux.org/issues/143
Avoid entering RTC-only mode at poweroff. It is unsupported by most
versions of BeagleBone, and risks hardware damage.
Reported-by: Matthijs van Duin matthijsvand...@gmail.com
Tested-by: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Felipe Balbi ba...@ti.com
Cc: Johan Hovold jo...@kernel.org
[Matthijs van Duin: added explanatory comments]
Signed-off-by: Matthijs van Duin matthijsvand...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index c3255e0..90fbbb1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -223,6 +223,24 @@
/include/ tps65217.dtsi
tps {
+ // Configure pmic to enter OFF-state instead of SLEEP-state (RTC-only
+ // mode) at poweroff. Most BeagleBone versions do not support RTC-only
+ // mode and risk hardware damage if this mode is entered.
+ //
+ // For details, see linux-omap mailing list May 2015 thread
+ // [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
+ // In particular, messages:
+ // http://www.spinics.net/lists/linux-omap/msg118585.html
+ // http://www.spinics.net/lists/linux-omap/msg118615.html
+ //
+ ti,pmic-shutdown-controller;
+ //
+ // You can override this later with
+ // tps { /delete-property/ ti,pmic-shutdown-controller; }
+ // if you want to use RTC-only mode and made sure you are not affected
+ // by the hardware problems. (Tip: double-check by performing a current
+ // measurement after shutdown: it should be less than 1 mA.)
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = vdds_dpr;
Linux usually does not use the // style comments.. Can you please change
that? And how about have just one section of comments then the entry
for ti,pmic-shutdown-controller? Or maybe something like this:
/*
* Configure pmic to enter OFF-state instead of SLEEP-state (RTC-only
* mode) at poweroff. Most BeagleBone versions do not support RTC-only
*
*/
tps {
ti,pmic-shutdown-controller;
regulators {
...
};
...
};
Also, if this is needed as a fix for the mainline kernel to avoid hardware
damage, please let me know too ASAP.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
* Jeroen Hofstee linux-...@myspectrum.nl [150601 09:58]: Hello Tero, On 01-06-15 17:30, Tero Kristo wrote: New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) With this patch the error interrupt / stack dumps are no longer present. Thanks, Tested-by: Jeroen Hofstee jer...@myspectrum.nl Thanks, I'm suprised this was not caught earlier with all the automated boot testing going on? Anyways, applying into omap-for-v4.1/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: * Jeroen Hofstee linux-...@myspectrum.nl [150601 09:58]: On 01-06-15 17:30, Tero Kristo wrote: New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) With this patch the error interrupt / stack dumps are no longer present. Thanks, Tested-by: Jeroen Hofstee jer...@myspectrum.nl Thanks, I'm suprised this was not caught earlier with all the automated boot testing going on? At least speaking in terms the testbed results that I post, the warnings get reported. But not many people seem to act on them. (Jeroen is a pleasant exception.) See for example the Build warnings from toolchain, Kernel warnings during boot to userspace, Kernel warnings during PM test, and Obsolete Kconfig symbols sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Matthijs van Duin matthijsvand...@gmail.com [150530 08:24]:
On 29 May 2015 at 17:50, Tony Lindgren t...@atomide.com wrote:
I believe some TI kernels use strongly-ordered mappings, mainline
kernel does not. Which kernel version are you using?
Normally I periodically rebuild based on Robert C Nelson's -bone
kernel (but with heavily customized config). I also tried a plain
4.1.0-rc5-bone3, the generic 4.1.0-rc5-armv7-x0 (the most
vanilla-looking kernel I could find in my debian package list), and
for the heck of it also the classic 3.14.43-ti-r66.
In all cases I observed a synchronous bus error (dubiously reported as
external abort on non-linefetch (0x1818)) on an AM335x with this
trivial test:
int main() {
int fd = open( /dev/mem, O_RDWR | O_DSYNC );
if( fd 0 ) return 1;
void *ptr = mmap( NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0x4200
);
if( ptr == MAP_FAILED ) return 1;
*(volatile int *)ptr = 0;
return 0;
}
I even considered for a moment that maybe the AM335x has some all
writes non-posted thing enabled (which I think is available as a
switch on OMAP 4/5?). It seemed unlikely, but since most of my
exploration of interconnect behaviour was done on a DM814x, I
double-checked by performing the same write in a baremetal test
program (with that region configured Device-type in the MMU). As
expected, no data abort occurred, so writes most certainly are posted.
So I have trouble coming up with any explanation for this other than
the use of strongly-ordered mappings.
(Curiously BTW, omitting O_DSYNC made no difference.)
I think these kernels are missing the configuration for l3-noc
driver?
I tried it on omap4 that has l3-noc configured, and it first produces
Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000,
and the L3 interrupt only after that. So yeah, you're right, we can't
use the interrupts here. I somehow remembered we'd get only the L3
interrupt if configured.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote:
The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
You were very welcome to review this patch at the time and/or suggest
a fix that pleases everyone.
You should be the one that should suggest fixes, as you broke it in
the first place. But clearly you don't understand that.
You actually never asked for a fix, and went head first calling this
patch bad and asking for nothing but reverting it.
Date: Fri, 29 May 2015 21:08:16 +0200
Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
linux-n900
...
Maxime, can you suggest a fix?
How about we do something like below (it needs a small edt-ft5x06 fixup
that I'll send separately). Not tested.
Thanks.
--
Dmitry
Input: improve parsing OF parameters for touchscreens
From: Dmitry Torokhov dmitry.torok...@gmail.com
When applying touchscreen parameters specified in device tree let's make
sure we keep whatever setup was done by the driver and not reset the
missing values to zero.
Reported-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/touchscreen/edt-ft5x06.c |2 -
drivers/input/touchscreen/of_touchscreen.c | 67 ++--
drivers/input/touchscreen/tsc2005.c|2 -
include/linux/input/touchscreen.h |5 +-
4 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index 29d179a..394b1de 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1041,7 +1041,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
0, tsdata-num_y * 64 - 1, 0, 0);
if (!pdata)
- touchscreen_parse_of_params(input);
+ touchscreen_parse_of_params(input, true);
error = input_mt_init_slots(input, MAX_SUPPORT_POINTS, INPUT_MT_DIRECT);
if (error) {
diff --git a/drivers/input/touchscreen/of_touchscreen.c
b/drivers/input/touchscreen/of_touchscreen.c
index b82b520..c132624 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -14,14 +14,22 @@
#include linux/input/mt.h
#include linux/input/touchscreen.h
-static u32 of_get_optional_u32(struct device_node *np,
- const char *property)
+static bool touchscreen_get_property_u32(struct device_node *np,
+const char *property,
+unsigned int default_value,
+unsigned int *value)
{
u32 val = 0;
+ int error;
- of_property_read_u32(np, property, val);
+ error = of_property_read_u32(np, property, val);
+ if (error) {
+ *value = default_value;
+ return false;
+ }
- return val;
+ *value = val;
+ return true;
}
static void touchscreen_set_params(struct input_dev *dev,
@@ -54,34 +62,45 @@ static void touchscreen_set_params(struct input_dev *dev,
* input device accordingly. The function keeps previously setuped default
* values if no value is specified via DT.
*/
-void touchscreen_parse_of_params(struct input_dev *dev)
+void touchscreen_parse_of_params(struct input_dev *dev, bool multitouch)
{
struct device_node *np = dev-dev.parent-of_node;
- u32 maximum, fuzz;
+ unsigned int maximum, fuzz;
+ int axis;
+ bool present;
input_alloc_absinfo(dev);
if (!dev-absinfo)
return;
- maximum = of_get_optional_u32(np, touchscreen-size-x);
- fuzz = of_get_optional_u32(np, touchscreen-fuzz-x);
- if (maximum || fuzz) {
- touchscreen_set_params(dev, ABS_X, maximum, fuzz);
- touchscreen_set_params(dev, ABS_MT_POSITION_X, maximum, fuzz);
- }
+ axis = multitouch ? ABS_MT_POSITION_X : ABS_X;
+ data_present = touchscreen_get_prop_u32(np, touchscreen-size-x,
+ input_abs_get_maximum(axis),
+ maximum) |
+ touchscreen_get_prop_u32(np, touchscreen-fuzz-x,
+ input_abs_get_fuzz(axis),
+ fuzz);
+ if (data_present)
+ touchscreen_set_params(dev, axis, maximum, fuzz);
- maximum = of_get_optional_u32(np, touchscreen-size-y);
- fuzz = of_get_optional_u32(np, touchscreen-fuzz-y);
- if (maximum || fuzz) {
- touchscreen_set_params(dev, ABS_Y, maximum, fuzz);
- touchscreen_set_params(dev, ABS_MT_POSITION_Y, maximum, fuzz);
- }
+ axis = multitouch ? ABS_MT_POSITION_Y : ABS_Y;
+ data_present = touchscreen_get_prop_u32(np,
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
* Tony Lindgren t...@atomide.com [150601 11:06]: * Paul Walmsley p...@pwsan.com [150601 10:45]: See for example the Build warnings from toolchain, Kernel warnings during boot to userspace, Kernel warnings during PM test, and Obsolete Kconfig symbols sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt OK somehow 3517evm is listed under skip there? Oh I see you have two 3517 devices there, never mind. Hmm now I'm wondering what the panda es warnings listed there are.. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
* Paul Walmsley p...@pwsan.com [150601 10:45]: On Mon, 1 Jun 2015, Tony Lindgren wrote: * Jeroen Hofstee linux-...@myspectrum.nl [150601 09:58]: On 01-06-15 17:30, Tero Kristo wrote: New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) With this patch the error interrupt / stack dumps are no longer present. Thanks, Tested-by: Jeroen Hofstee jer...@myspectrum.nl Thanks, I'm suprised this was not caught earlier with all the automated boot testing going on? At least speaking in terms the testbed results that I post, the warnings get reported. But not many people seem to act on them. (Jeroen is a pleasant exception.) See for example the Build warnings from toolchain, Kernel warnings during boot to userspace, Kernel warnings during PM test, and Obsolete Kconfig symbols sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt OK somehow 3517evm is listed under skip there? The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. Right. Also seems we should diff dmesg output too (after stripping out the timestamps). Pretty much the only things that should change are the sysfs paths for devices in the dmesg output unless some warnings get fixed. That output probably still also needs to be manually looked at though.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
On 06/01/2015 08:44 PM, Paul Walmsley wrote: On Mon, 1 Jun 2015, Tony Lindgren wrote: * Jeroen Hofstee linux-...@myspectrum.nl [150601 09:58]: On 01-06-15 17:30, Tero Kristo wrote: New system control module layout for omap3 overlooked parts of the am35xx configuration. Basically the am35xx clocks were not converted to use the changed offsets, which caused weird boot warnings. The errors were not fatal so far, so they were not caught earlier. Fixed by applying the proper offsets for the AM35xx scm clocks. Fixes: b8845074cf (ARM: dts: omap3: add minimal l4 bus layout with...) Signed-off-by: Tero Kristo t-kri...@ti.com Reported-by: Jeroen Hofstee linux-...@myspectrum.nl Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) With this patch the error interrupt / stack dumps are no longer present. Thanks, Tested-by: Jeroen Hofstee jer...@myspectrum.nl Thanks, I'm suprised this was not caught earlier with all the automated boot testing going on? At least speaking in terms the testbed results that I post, the warnings get reported. But not many people seem to act on them. (Jeroen is a pleasant exception.) See for example the Build warnings from toolchain, Kernel warnings during boot to userspace, Kernel warnings during PM test, and Obsolete Kconfig symbols sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. I added some extra logic into my test setup today for detecting this. Previously the dumps were pretty much hidden as there are existing dumps so I kind of ignored the new ones semi-blindly. . -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: am335x-boneblack: disable RTC-only sleep
On 1 June 2015 at 19:23, Tony Lindgren t...@atomide.com wrote:
Ah finally you got around doing a proper patch :)
My First Linux Patch(tm) ;-)
Also, if this is needed as a fix for the mainline kernel to avoid hardware
damage, please let me know too ASAP.
The damaging configuration is having rtc { system-power-controller; }
without tps { ti,pmic-shutdown-controller; }
So 3d76be5b9 also avoids damage, but with the unfortunate side-effect
that the system doesn't power off at all anymore (it just halts). I do
recommend applying this patch (restyled as needed) before reverting
3d76be5b9.
Hmm no ideas about that, I guess people are using gmail to send email
with smtps though?
Hmm, setting up mutt turned out less hassle than I remembered...
(Let's hope all goes well)
Linux usually does not use the // style comments.. Can you please change
that? And how about have just one section of comments then the entry
for ti,pmic-shutdown-controller?
Fresh try...
--- 8 -
Fixes: http://bugs.elinux.org/issues/143
Avoid entering RTC-only mode at poweroff. It is unsupported by most
versions of BeagleBone, and risks hardware damage.
Reported-by: Matthijs van Duin matthijsvand...@gmail.com
Tested-by: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Robert Nelson robertcnel...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Felipe Balbi ba...@ti.com
Cc: Johan Hovold jo...@kernel.org
[Matthijs van Duin: added explanatory comments]
Signed-off-by: Matthijs van Duin matthijsvand...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index c3255e0..c0b0c02 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -223,6 +223,24 @@
/include/ tps65217.dtsi
tps {
+ /* Configure pmic to enter OFF-state instead of SLEEP-state (RTC-only
+* mode) at poweroff. Most BeagleBone versions do not support RTC-only
+* mode and risk hardware damage if this mode is entered.
+*
+* For details, see linux-omap mailing list May 2015 thread
+* [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
+* In particular, messages:
+* http://www.spinics.net/lists/linux-omap/msg118585.html
+* http://www.spinics.net/lists/linux-omap/msg118615.html
+*
+* You can override this later with
+* tps { /delete-property/ ti,pmic-shutdown-controller; }
+* if you want to use RTC-only mode and made sure you are not affected
+* by the hardware problems. (Tip: double-check by performing a current
+* measurement after shutdown: it should be less than 1 mA.)
+*/
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-name = vdds_dpr;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] usb: dwc3: Add chained TRB support for ep0
Hi, On Mon, Jun 01, 2015 at 03:23:48PM +0530, Kishon Vijay Abraham I wrote: + transferred = transfer_size - length; + buf = (u8 *)buf + transferred; + ur-actual += transferred; this is dangerous. The extra size is because you *must* align OUT to wMaxPacketSize, so you cannot allow more than the original req-length to be copied into buf. That bounce buffer, is really supposed to be a Here we are not handling bounce buffer. The bounce buffer is used only for the 2nd TRB which actually programs to receive data that is less than bounce buffer size. The 1st TRB will always be max packet aligned and the data is directly copied to the request buffer. (However note that if the request length is less than bounce buffer size, we'll use 1 TRB only) To summarize.. We are splitting req-length into 2 TRB's if the req-length is not aligned to wMaxPacketSize _and_ req-length is greater than bounce buffer size. By this way we can make the 2nd TRB to receive data lesser than or equal to bounce buffer size and the rest of it can be received using the 1st TRB. Consider the following case. ur-length = 612; maxp = 512; This case can't be handled by the existing bounce buffer mechanism since the size of bounce buffer is only 512. So we program 2 TRB's. First TRB trb-size = 512; /* We don't need bounce buffer for this TRB since it is max packet aligned. The data is directly loaded to the request buffer. */ Second TRB trb-size = 512 /* For the remaining 100 bytes we use bounce buffer and it uses the same existing bounce buffer mechanism. But instead of copying the data to the start of the request buffer, it has to be appended to the data that is received due to first TRB. */ this is all fine, but you need to make sure that you only copy the remaining 100 bytes. Never, ever, ever copy anything past that. throw-away buffer and should never have data in it. You should really add a big fat WARN() if transferred req-length. The thing is that if host sends more data than we were expecting, this could be someone trying to use our driver as an exploit vector, trying to send more data than it should. We must be robust against that. This is handled in the existing bounce buffer mechanism and I use the same bounce buffer mechanism for the 2nd TRB. ok. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: am335x-boneblack: disable RTC-only sleep
* Matthijs van Duin matthijsvand...@gmail.com [150601 12:35]:
On 1 June 2015 at 19:23, Tony Lindgren t...@atomide.com wrote:
Ah finally you got around doing a proper patch :)
My First Linux Patch(tm) ;-)
Probably easier than trying to get other people to do the right
thing by writing emails ;)
Also, if this is needed as a fix for the mainline kernel to avoid hardware
damage, please let me know too ASAP.
The damaging configuration is having rtc { system-power-controller; }
without tps { ti,pmic-shutdown-controller; }
OK thanks updating the description with that.
So 3d76be5b9 also avoids damage, but with the unfortunate side-effect
that the system doesn't power off at all anymore (it just halts). I do
recommend applying this patch (restyled as needed) before reverting
3d76be5b9.
Hmm no ideas about that, I guess people are using gmail to send email
with smtps though?
Hmm, setting up mutt turned out less hassle than I remembered...
(Let's hope all goes well)
Linux usually does not use the // style comments.. Can you please change
that? And how about have just one section of comments then the entry
for ti,pmic-shutdown-controller?
Fresh try...
Thanks applying into omap-for-v4.1/fixes with Cc stable.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon, Jun 01, 2015 at 10:27:40PM +0200, Pavel Machek wrote: On Mon 2015-06-01 10:47:30, Dmitry Torokhov wrote: On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote: The 3eea8b5d68c801fec788b411582b803463834752 is just bad. You were very welcome to review this patch at the time and/or suggest a fix that pleases everyone. You should be the one that should suggest fixes, as you broke it in the first place. But clearly you don't understand that. You actually never asked for a fix, and went head first calling this patch bad and asking for nothing but reverting it. Date: Fri, 29 May 2015 21:08:16 +0200 Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re: linux-n900 ... Maxime, can you suggest a fix? How about we do something like below (it needs a small edt-ft5x06 fixup that I'll send separately). Not tested. + data_present = touchscreen_get_prop_u32(np, touchscreen-size-x, + input_abs_get_maximum(axis), + maximum) | + touchscreen_get_prop_u32(np, touchscreen-fuzz-x, + input_abs_get_fuzz(axis), + fuzz); + if (data_present) + touchscreen_set_params(dev, axis, maximum, fuzz); Umm. So you are changing behaviour from whatever was there to input_abs_get_maximum... in n900 case.o That _is_ whatever was there. Is that a good idea for a regression fix this late in release cycle? As Maxime mentioned the new behavior is needed for other touchscreens. Given that fixed DTS is going into 4.1 (as far as I understand) we do not need to rush this change into 4.1. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 19:58, Tony Lindgren t...@atomide.com wrote: I think these kernels are missing the configuration for l3-noc driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... I tried it on omap4 that has l3-noc configured, and it first produces Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000, (Though making a patch to fix that annoyingly wrong and useless message is higher on my list of priorities) and the L3 interrupt only after that. So yeah, you're right, we can't use the interrupts here. I somehow remembered we'd get only the L3 interrupt if configured. The bus error is not influenced by L3 error reporting config afaik, and it will always win from the irq: even though the irq is almost certainly asserted first, it can't be taken until the load/store instruction completes, and then the fault will take precedence. While implementing L3 error reporting in my forth system I ran into a tricky scenario though: it turns out that if an irq occurs while the cpu is waiting for instruction fetch, it does allow the irq to be taken. The interrupted fetch is abandoned and any bus error it may have produced is ignored since exception entry/exit is an implicit instruction sync barrier. On return it is simply refetched... Hence, the result from attempting to execute code from an invalid address: fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] ... (repeat until watchdog expires) Anyhow, so we still have the puzzling fact that apparently neither of us was expecting device memory to use a strongly-ordered mapping, getting a bus error on a write (outside MPUSS itself) shows that it does. I've tried to read arch/arm/mm/mmu.c to find out why, but so far I'm feeling hopelessly lost there... (the multitude of ARM architecture versions/flavors supported aren't helping.) -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150601 10:45]: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt OK somehow 3517evm is listed under skip there? Yep that board is down right now; something's wrong with it and I haven't had the time to figure out whether it's fixable, or if it's fried. The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. Right. Also seems we should diff dmesg output too (after stripping out the timestamps). Pretty much the only things that should change are the sysfs paths for devices in the dmesg output unless some warnings get fixed. That output probably still also needs to be manually looked at though.. Yep, there are still some other minor loose ends to be tied up too that don't show up as full warnings, such as the broken UART4 idle protocol integration on AM35xx... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon 2015-06-01 10:47:30, Dmitry Torokhov wrote: On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote: The 3eea8b5d68c801fec788b411582b803463834752 is just bad. You were very welcome to review this patch at the time and/or suggest a fix that pleases everyone. You should be the one that should suggest fixes, as you broke it in the first place. But clearly you don't understand that. You actually never asked for a fix, and went head first calling this patch bad and asking for nothing but reverting it. Date: Fri, 29 May 2015 21:08:16 +0200 Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re: linux-n900 ... Maxime, can you suggest a fix? How about we do something like below (it needs a small edt-ft5x06 fixup that I'll send separately). Not tested. + data_present = touchscreen_get_prop_u32(np, touchscreen-size-x, + input_abs_get_maximum(axis), + maximum) | + touchscreen_get_prop_u32(np, touchscreen-fuzz-x, + input_abs_get_fuzz(axis), + fuzz); + if (data_present) + touchscreen_set_params(dev, axis, maximum, fuzz); Umm. So you are changing behaviour from whatever was there to input_abs_get_maximum... in n900 case. Is that a good idea for a regression fix this late in release cycle? Maxime's patch should be easy to fix... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Matthijs van Duin matthijsvand...@gmail.com [150601 13:34]: On 1 June 2015 at 19:58, Tony Lindgren t...@atomide.com wrote: I think these kernels are missing the configuration for l3-noc driver? Yup. Since I'm pretty sure I have all the necessary info I was hoping look into that... somewhere in my copious spare time... I tried it on omap4 that has l3-noc configured, and it first produces Unhandled fault: external abort on non-linefetch (0x1818) at 0xb6fd7000, (Though making a patch to fix that annoyingly wrong and useless message is higher on my list of priorities) and the L3 interrupt only after that. So yeah, you're right, we can't use the interrupts here. I somehow remembered we'd get only the L3 interrupt if configured. The bus error is not influenced by L3 error reporting config afaik, and it will always win from the irq: even though the irq is almost certainly asserted first, it can't be taken until the load/store instruction completes, and then the fault will take precedence. While implementing L3 error reporting in my forth system I ran into a tricky scenario though: it turns out that if an irq occurs while the cpu is waiting for instruction fetch, it does allow the irq to be taken. The interrupted fetch is abandoned and any bus error it may have produced is ignored since exception entry/exit is an implicit instruction sync barrier. On return it is simply refetched... Hence, the result from attempting to execute code from an invalid address: fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] irq entry (LR=[invalid]) L3 error displayed irq exit fetching from [invalid] ... (repeat until watchdog expires) OK that must be the case I've seen then. Probably that happens when a device is not clocked. Anyhow, so we still have the puzzling fact that apparently neither of us was expecting device memory to use a strongly-ordered mapping, getting a bus error on a write (outside MPUSS itself) shows that it does. Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Care to verify that from a device driver that does ioremap on it first? I've tried to read arch/arm/mm/mmu.c to find out why, but so far I'm feeling hopelessly lost there... (the multitude of ARM architecture versions/flavors supported aren't helping.) Heh yeah too much hardware churn going on :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
* Dmitry Torokhov dmitry.torok...@gmail.com [150601 13:47]: On Mon, Jun 01, 2015 at 10:27:40PM +0200, Pavel Machek wrote: On Mon 2015-06-01 10:47:30, Dmitry Torokhov wrote: On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote: The 3eea8b5d68c801fec788b411582b803463834752 is just bad. You were very welcome to review this patch at the time and/or suggest a fix that pleases everyone. You should be the one that should suggest fixes, as you broke it in the first place. But clearly you don't understand that. You actually never asked for a fix, and went head first calling this patch bad and asking for nothing but reverting it. Date: Fri, 29 May 2015 21:08:16 +0200 Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re: linux-n900 ... Maxime, can you suggest a fix? How about we do something like below (it needs a small edt-ft5x06 fixup that I'll send separately). Not tested. + data_present = touchscreen_get_prop_u32(np, touchscreen-size-x, + input_abs_get_maximum(axis), + maximum) | + touchscreen_get_prop_u32(np, touchscreen-fuzz-x, + input_abs_get_fuzz(axis), + fuzz); + if (data_present) + touchscreen_set_params(dev, axis, maximum, fuzz); Umm. So you are changing behaviour from whatever was there to input_abs_get_maximum... in n900 case.o That _is_ whatever was there. Is that a good idea for a regression fix this late in release cycle? As Maxime mentioned the new behavior is needed for other touchscreens. Given that fixed DTS is going into 4.1 (as far as I understand) we do not need to rush this change into 4.1. OK great. I'm planning to send a pull request to arm-soc for Pavel's DTS fix today along with few other fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for v4.1, urgent fix to avoid potential hardware damage
Hi, Here's a pull request to fix potential hardware breaking configuration on BeagleBones. For the other fixes, apologies for these coming in so late, seems that people have been busy finding regressions. Regards, Tony The following changes since commit f25bf74c8862efdc30453d16d60cf22958a4873e: ARM: dts: Fix WLAN interrupt line for AM335x EVM-SK (2015-05-20 10:00:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.1/fixes-rc6 for you to fetch changes up to 7a6cb0abe1aa63334f3ded6d2b6c8eca80e72302: ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage (2015-06-01 12:48:23 -0700) Omap fixes for the -rc cycle, including a fix for potential hardware breakage on BeagleBones: - BeagleBones don't support RTC-only mode, it can cause hardware damage if system-power-controller is specified without ti,pmic-shutdown-controller - Fix a recent regression to am3517 SoCs caused by the recent clock move that was not noticed until now despite automated boot testing - Fix a regression for n900 touchscreen triggered by recent recent input changes - Fix compatible property for dm816x USB to avoid errors with USB Ethernet - Fix oops for omap3 when built with CONFIG_THUMB2_KERNEL Matthijs van Duin (1): ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage Pavel Machek (1): ARM: dts: Fix n900 dts file to work around 4.1 touchscreen regression on n900 Tero Kristo (1): ARM: dts: AM35xx: fix system control module clocks Tony Lindgren (2): ARM: OMAP3: Fix booting with thumb2 kernel ARM: dts: Fix dm816x to use right compatible flag for MUSB .../bindings/input/touchscreen/tsc2005.txt | 4 ++-- arch/arm/boot/dts/am335x-bone-common.dtsi | 19 +++ arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- arch/arm/boot/dts/dm816x.dtsi | 4 ++-- arch/arm/boot/dts/omap3-n900.dts | 4 ++-- arch/arm/mach-omap2/sleep34xx.S| 22 ++ 6 files changed, 34 insertions(+), 33 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
* Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]: AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. This one does not seem to apply to linux next, did not look further where it conflicts. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] mach-omap2:Remove unnessary return statement from the void function, omap2_show_dma_caps
* Nicholas Krause xerofo...@gmail.com [150528 08:06]: This removes the no longer required return statement at the end of the void function, omap2_show_dma_cap due to no need for a return statement due to this function always running successfully. Signed-off-by: Nicholas Krause xerofo...@gmail.com --- arch/arm/mach-omap2/dma.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c index e1a56d8..1ed4be1 100644 --- a/arch/arm/mach-omap2/dma.c +++ b/arch/arm/mach-omap2/dma.c @@ -117,7 +117,6 @@ static void omap2_show_dma_caps(void) u8 revision = dma_read(REVISION, 0) 0xff; printk(KERN_INFO OMAP DMA hardware revision %d.%d\n, revision 4, revision 0xf); - return; } static unsigned configure_dma_errata(void) Sorry for the delay, applying this into omap-for-v4.2/fixes as it's not urgent. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
On Mon, Jun 01, 2015 at 11:22:26PM +0200, Maxime Ripard wrote:
Hi Dmitry,
On Mon, Jun 01, 2015 at 10:47:30AM -0700, Dmitry Torokhov wrote:
On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote:
The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
You were very welcome to review this patch at the time and/or
suggest
a fix that pleases everyone.
You should be the one that should suggest fixes, as you broke it in
the first place. But clearly you don't understand that.
You actually never asked for a fix, and went head first calling this
patch bad and asking for nothing but reverting it.
Date: Fri, 29 May 2015 21:08:16 +0200
Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
linux-n900
...
Maxime, can you suggest a fix?
How about we do something like below (it needs a small edt-ft5x06 fixup
that I'll send separately). Not tested.
Thanks.
--
Dmitry
Input: improve parsing OF parameters for touchscreens
From: Dmitry Torokhov dmitry.torok...@gmail.com
When applying touchscreen parameters specified in device tree let's make
sure we keep whatever setup was done by the driver and not reset the
missing values to zero.
Reported-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/touchscreen/edt-ft5x06.c |2 -
drivers/input/touchscreen/of_touchscreen.c | 67
++--
drivers/input/touchscreen/tsc2005.c|2 -
include/linux/input/touchscreen.h |5 +-
4 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index 29d179a..394b1de 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1041,7 +1041,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client
*client,
0, tsdata-num_y * 64 - 1, 0, 0);
if (!pdata)
- touchscreen_parse_of_params(input);
+ touchscreen_parse_of_params(input, true);
error = input_mt_init_slots(input, MAX_SUPPORT_POINTS, INPUT_MT_DIRECT);
if (error) {
diff --git a/drivers/input/touchscreen/of_touchscreen.c
b/drivers/input/touchscreen/of_touchscreen.c
index b82b520..c132624 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -14,14 +14,22 @@
#include linux/input/mt.h
#include linux/input/touchscreen.h
-static u32 of_get_optional_u32(struct device_node *np,
- const char *property)
+static bool touchscreen_get_property_u32(struct device_node *np,
+const char *property,
+unsigned int default_value,
+unsigned int *value)
{
u32 val = 0;
+ int error;
- of_property_read_u32(np, property, val);
+ error = of_property_read_u32(np, property, val);
+ if (error) {
+ *value = default_value;
+ return false;
+ }
- return val;
+ *value = val;
+ return true;
This looks good.
However, of_property_read_u32 already does the right thing here by not
update val if the property is not found.
I know but it is not documented anywhere (as far as I know) so I'd
rather not rely on the implementation detail that might change in the
future. This is not a hot path so extra assignment should not hurt.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] serial: omap: Switch wake-up interrupt to generic wakeirq
* Greg Kroah-Hartman gre...@linuxfoundation.org [150531 00:24]: On Thu, May 28, 2015 at 07:56:16AM -0700, Tony Lindgren wrote: Hi Greg, * Tony Lindgren t...@atomide.com [150513 16:38]: We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts. How do you prefer to handle the two omap specific serial driver changes in this series? There's a dependency to Rafael's pm-wakeirq branch that contains: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) 56f487c78015 (PM / Runtime: Update last_busy in rpm_resume) f6a2fbb903d5 (PM / runtime: add note about re-calling in during device probe()) The 8250_omap.c driver change also needs to be merged with: 9e91597f2423 (serial: 8250_omap: provide complete custom startup shutdown callbacks) Not sure if 9e91597f2423 is immutable, but if so then I could: a) Send you a pull request for the two serial driver patches based on Rafael's pm-wakeirq branch merged with 9e91597f2423 to avoid the merge conflict. b) Apply both serial driver patches into omap-for-v4.2/wakeirq based on Rafael's pm-wakeirq branch merged with 9e91597f2423. That one sounds good to me, feel free to do so and add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org It's the easiest for everyone involved, right? OK thanks, looks like there's a new commit for the fix as 9809889c708e, I'll base on that and wait that the commit gets merged before sending out any pull request. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please revert 3eea8b5d68c801fec788b411582b803463834752 as it breaks touchscreen on n900.
Hi Dmitry,
On Mon, Jun 01, 2015 at 10:47:30AM -0700, Dmitry Torokhov wrote:
On Mon, Jun 01, 2015 at 05:21:11PM +0200, Pavel Machek wrote:
The 3eea8b5d68c801fec788b411582b803463834752 is just bad.
You were very welcome to review this patch at the time and/or suggest
a fix that pleases everyone.
You should be the one that should suggest fixes, as you broke it in
the first place. But clearly you don't understand that.
You actually never asked for a fix, and went head first calling this
patch bad and asking for nothing but reverting it.
Date: Fri, 29 May 2015 21:08:16 +0200
Subject: 4.1 touchscreen regression on n900 -- pinpointed [was Re:
linux-n900
...
Maxime, can you suggest a fix?
How about we do something like below (it needs a small edt-ft5x06 fixup
that I'll send separately). Not tested.
Thanks.
--
Dmitry
Input: improve parsing OF parameters for touchscreens
From: Dmitry Torokhov dmitry.torok...@gmail.com
When applying touchscreen parameters specified in device tree let's make
sure we keep whatever setup was done by the driver and not reset the
missing values to zero.
Reported-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/touchscreen/edt-ft5x06.c |2 -
drivers/input/touchscreen/of_touchscreen.c | 67
++--
drivers/input/touchscreen/tsc2005.c|2 -
include/linux/input/touchscreen.h |5 +-
4 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index 29d179a..394b1de 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1041,7 +1041,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client
*client,
0, tsdata-num_y * 64 - 1, 0, 0);
if (!pdata)
- touchscreen_parse_of_params(input);
+ touchscreen_parse_of_params(input, true);
error = input_mt_init_slots(input, MAX_SUPPORT_POINTS, INPUT_MT_DIRECT);
if (error) {
diff --git a/drivers/input/touchscreen/of_touchscreen.c
b/drivers/input/touchscreen/of_touchscreen.c
index b82b520..c132624 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -14,14 +14,22 @@
#include linux/input/mt.h
#include linux/input/touchscreen.h
-static u32 of_get_optional_u32(struct device_node *np,
-const char *property)
+static bool touchscreen_get_property_u32(struct device_node *np,
+ const char *property,
+ unsigned int default_value,
+ unsigned int *value)
{
u32 val = 0;
+ int error;
- of_property_read_u32(np, property, val);
+ error = of_property_read_u32(np, property, val);
+ if (error) {
+ *value = default_value;
+ return false;
+ }
- return val;
+ *value = val;
+ return true;
This looks good.
However, of_property_read_u32 already does the right thing here by not
update val if the property is not found.
So I guess you could just do:
*value = default_value;
return of_property_read_u32(np, property, value) ? true : false;
It looks good otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150601 11:06]: * Paul Walmsley p...@pwsan.com [150601 10:45]: See for example the Build warnings from toolchain, Kernel warnings during boot to userspace, Kernel warnings during PM test, and Obsolete Kconfig symbols sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt OK somehow 3517evm is listed under skip there? Oh I see you have two 3517 devices there, never mind. Hmm now I'm wondering what the panda es warnings listed there are.. http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/boot/4430es2panda/4430es2panda_log.txt Looked to me like an OMAP4430 ES2.2 bug. I recall discussing it with someone with an ES2.3 Pandaboard and they said it didn't show up. So I asked TI at the time if there was an erratum for it; apparently not. So I think we may need to add in another hardware bug workaround flag to the OMAP integration code... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
From: NeilBrown ne...@suse.de
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
Little sceptical about adding new sysfs entries. Do you have a good reason to
add this?
The hardware can report the value, so why not present it to user-space?
I originally used this with a udev rule which would configure the maximum
current based on the resistance measure - to work with the particular charger
hardware I have.
More recent patches try to do all of the max-current configuration in the
kernel, so I could live without exporting the value via sysfs if that is a
show-stopper.
I can't see where the scepticism comes from though. It is a well defined
and cleary documented feature of the hardware. Why not expose it?
Thanks,
NeilBrown
Thanks
Kishon
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek pa...@ucw.cz
Signed-off-by: NeilBrown ne...@suse.de
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: on, off.
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ unknown indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
+ floating,
+ unknown
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl-dev);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0 || !(ret ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret 0 || (ret 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ if (ret 0)
+ return TWL4030_ID_UNKNOWN;
+ ret = ffs(ret) - 1;
+ if (ret TWL4030_GROUND || ret TWL4030_FLOATING)
+ return TWL4030_ID_UNKNOWN;
+
+ return ret;
+}
+
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
@@ -532,6 +582,16 @@ static ssize_t twl4030_usb_vbus_show(struct device
*dev,
}
static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
+static ssize_t twl4030_usb_id_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ return scnprintf(buf, PAGE_SIZE, %s\n,
+twl4030_id_names[twl4030_get_id(twl)]);
+}
+static DEVICE_ATTR(id, 0444, twl4030_usb_id_show, NULL);
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -709,6 +769,8 @@ static int twl4030_usb_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, twl);
if (device_create_file(pdev-dev, dev_attr_vbus))
Re: [PATCHv4 02/10] CLK: TI: always enable DESHDCP clock
Hi Mike, Stephen Tero,
* Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]:
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.
As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.
Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.
So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
This series seems like I should take it as a whole series..
Care to ack/nack on this one?
Regards,
Tony
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 2dd956b9affa..63b8323df918 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -312,7 +312,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
int __init dra7xx_dt_clk_init(void)
{
int rc;
- struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
ti_dt_clocks_register(dra7xx_clks);
@@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
+ hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+ rc = clk_prepare_enable(hdcp_ck);
+ if (rc)
+ pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 04/10] ARM: DRA7: hwmod: add DMM hwmod description
On Mon, 1 Jun 2015, Tomi Valkeinen wrote: Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 05/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
On Mon, 1 Jun 2015, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Paul Walmsley p...@pwsan.com By the way, for commits like this one, it would be nice to add a line describing why the change is needed to the commit message. Something like This ensures that the parent hwmods are enabled before any DSS submodules are accessed. Tony, feel free to add that to the commit message if you think it's useful. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: hwmod code and data changes for v4.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118: Linux 4.1-rc4 (2015-05-18 10:13:47 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.2/omap-hwmod-a for you to fetch changes up to a55a744582e0dc106537ba5e508c340c39cfe454: ARM: OMAP3: Fix crypto support for HS devices (2015-06-01 19:23:04 -0600) The branch contains a AM43xx hwmod data change, and thus is based on v4.1-rc4 to avoid merge conflicts. - ARM: OMAP2+: hwmod code and data changes for v4.2 Several OMAP2+ hwmod changes for v4.2. One patch cleans up a nasty interaction between the OMAP GPMC and the hwmod code when debugging is enabled. IP block integration data has been added for the AM43xx EMIF RAM controller. There's also a fix for the omap-aes driver when used in QEMU. And finally, some changes to the OMAP3 hwmod code to support the use of the security IP blocks (AES and SHA) on GP devices, or when they've specifically been enabled in the DT data. Basic build, boot, and power management test results are here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.2/20150601192349/ - Dave Gerlach (1): ARM: OMAP: AM43xx hwmod: Add data for am43xx emif hwmod Pali Rohár (2): ARM: OMAP2+: Return correct error values from device and hwmod ARM: OMAP3: Fix crypto support for HS devices Tony Lindgren (1): memory: omap-gpmc: Add Kconfig option for debug arch/arm/mach-omap2/omap_device.c | 30 +++--- arch/arm/mach-omap2/omap_hwmod.c | 10 +- arch/arm/mach-omap2/omap_hwmod.h | 6 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 12 +-- .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 + .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 16 ++- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 13 --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 119 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 22 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 11 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 4 +- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 + arch/arm/mach-omap2/prcm43xx.h | 2 + drivers/memory/Kconfig | 8 ++ drivers/memory/omap-gpmc.c | 6 +- 15 files changed, 184 insertions(+), 78 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVbSEcAAoJEMePsQ0LvSpLTiwP/2dv6NKgLL2PoXkyqcMcHdcI /zlh8mGH6yaia8jsNZ09Tf6lqZpsIr8FIOZAxq/kx21PhfQ89AcPDYAILmEB1DGk x3/Z6rl26SgZ2HOgjs95FzJYjxy1T48BgZve9rVa/oKlkXdQ6CIdl9rP1SLwLAla Cw++IwfBMr95y+71ov+6Tvit5UmMgCnjCsrcjK0RWUdeVps9Kye8HvWMBLMq7NB2 Tif9S7QGXVFIdPGsOL2ADeC/dvshgSjGsGkQWLi8bkJX92AfU2+WobdZ1aZlKJj+ e8+hj+hVwOLbIYCDPqG14r5z1cVCkoNDvb81J/XTszKTYEcr1d5Z9UgAJkj0kdyb zv41VKL7WxWw7R0biwDlC7XkLD7Ob57ZL3BJ3yMNT7T4dzaJxX8nvwWN0c1OBMXG LyhDm10pPWyy9SAKDczh35veL0EQEMSMt6HUGx9h+fhyU3Sw/XUHzO13l7AWxnIu s0JWYuzk89YXN6q3vBK3OWBe0oQXd7rxKigQ3w2BZ7Squ9jWqIka3vphuwx+UNZ+ UU+wv2+/3gHkzoPFSsVB4C7O3oI07A5HjHegDbPdyaEDq5Bv4Ri7t38+DyKzuZs6 L7J1kMD/xa8XoFHnLuX1cv9k3PPTpkYxxGJOmkhRZ3XVfpqxKYi34uvKkJbHnD7E jDycRKMnfuDOWsqpinJ9 =AOYe -END PGP SIGNATURE-
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 22:52, Tony Lindgren t...@atomide.com wrote: OK that must be the case I've seen then. Probably that happens when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't apply to device memory. Another case where the L3 error irq may be taken first is if the bus error is asynchronous, but I don't think this combo can be produced on a dm81xx or am335x, but that's mainly due to the strictly in-order Cortex-A8 making almost every abort synchronous. I'd expect async aborts are more common on an A9. Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Yikes, so both /dev/mem and uio are behaving unlike any device driver: both use remap_pfn_range() after running the vm_page_prot though pgprot_noncached() to set the memory type to L_PTE_MT_UNCACHED, which counterintuitively turns out to mean strongly-ordered. o.O Especially uio is acting inappropriate here imho. But this is problematic... these ranges are already mapped by the kernel, and ARM explicitly forbids mapping the same physical range twice with different memory attributes (and it's not the only architecture to do so). Hmmz... Anyhow, drifting a bit off-topic here. I'm going to some more reading and thinking about this. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
