[PATCHv2 1/5] drivers: w1: omap_hdq: cleanup and bug fixes.
The patch adds the following to the omap hdq driver.
1. HDQ Device reset call in probe.
2. Enabling '1 wire mode' and checking for presence pulse bit.
3. Proper disabling and enabling of interrupts during read path.
4. Add re-initialization code during SKIP ROM command execution.
5. Miscellaneous cleanup(formatting, return error checks).
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/w1/masters/omap_hdq.c | 84 -
1 file changed, 67 insertions(+), 17 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 9900e8e..ca3623c 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -27,21 +27,22 @@
#define OMAP_HDQ_TX_DATA 0x04
#define OMAP_HDQ_RX_DATA 0x08
#define OMAP_HDQ_CTRL_STATUS 0x0c
-#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (16)
-#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (15)
-#define OMAP_HDQ_CTRL_STATUS_GO(14)
-#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION(12)
-#define OMAP_HDQ_CTRL_STATUS_DIR (11)
-#define OMAP_HDQ_CTRL_STATUS_MODE (10)
+#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (1 6)
+#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (1 5)
+#define OMAP_HDQ_CTRL_STATUS_PRESENCE (1 3)
+#define OMAP_HDQ_CTRL_STATUS_GO (1 4)
+#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION(1 2)
+#define OMAP_HDQ_CTRL_STATUS_DIR (1 1)
+#define OMAP_HDQ_CTRL_STATUS_MODE (1 0)
#define OMAP_HDQ_INT_STATUS0x10
-#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (12)
-#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (11)
-#define OMAP_HDQ_INT_STATUS_TIMEOUT(10)
+#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (1 2)
+#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (1 1)
+#define OMAP_HDQ_INT_STATUS_TIMEOUT(1 0)
#define OMAP_HDQ_SYSCONFIG 0x14
-#define OMAP_HDQ_SYSCONFIG_SOFTRESET (11)
-#define OMAP_HDQ_SYSCONFIG_AUTOIDLE(10)
+#define OMAP_HDQ_SYSCONFIG_SOFTRESET (1 1)
+#define OMAP_HDQ_SYSCONFIG_AUTOIDLE(1 0)
#define OMAP_HDQ_SYSSTATUS 0x18
-#define OMAP_HDQ_SYSSTATUS_RESETDONE (10)
+#define OMAP_HDQ_SYSSTATUS_RESETDONE (1 0)
#define OMAP_HDQ_FLAG_CLEAR0
#define OMAP_HDQ_FLAG_SET 1
@@ -115,6 +116,15 @@ static inline u8 hdq_reg_merge(struct hdq_data *hdq_data,
u32 offset,
return new_val;
}
+static void hdq_disable_interrupt(struct hdq_data *hdq_data)
+{
+ u32 ie;
+
+ ie = readl(hdq_data-hdq_base + OMAP_HDQ_CTRL_STATUS);
+ writel(ie ~OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK,
+ hdq_data-hdq_base + OMAP_HDQ_CTRL_STATUS);
+}
+
/*
* Wait for one or more bits in flag change.
* HDQ_FLAG_SET: wait until any bit in the flag is set.
@@ -263,8 +273,7 @@ static int _omap_hdq_reset(struct hdq_data *hdq_data)
* interrupt.
*/
hdq_reg_out(hdq_data, OMAP_HDQ_CTRL_STATUS,
- OMAP_HDQ_CTRL_STATUS_CLOCKENABLE |
- OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK);
+ OMAP_HDQ_CTRL_STATUS_CLOCKENABLE);
/* wait for reset to complete */
ret = hdq_wait_for_flag(hdq_data, OMAP_HDQ_SYSSTATUS,
@@ -275,7 +284,8 @@ static int _omap_hdq_reset(struct hdq_data *hdq_data)
else {
hdq_reg_out(hdq_data, OMAP_HDQ_CTRL_STATUS,
OMAP_HDQ_CTRL_STATUS_CLOCKENABLE |
- OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK);
+ OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK |
+ OMAP_HDQ_CTRL_STATUS_MODE);
hdq_reg_out(hdq_data, OMAP_HDQ_SYSCONFIG,
OMAP_HDQ_SYSCONFIG_AUTOIDLE);
}
@@ -327,6 +337,18 @@ static int omap_hdq_break(struct hdq_data *hdq_data)
ret = -ETIMEDOUT;
goto out;
}
+
+ /*
+* check for the presence detect bit to get
+* set to show that the slave is responding
+*/
+ if (hdq_reg_in(hdq_data, OMAP_HDQ_CTRL_STATUS)
+ OMAP_HDQ_CTRL_STATUS_PRESENCE) {
+ dev_dbg(hdq_data-dev, Presence bit not set\n);
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
/*
* wait for both INIT and GO bits rerurn to zero.
* zero wait time expected for interrupt mode.
@@ -361,6 +383,8 @@ static int hdq_read_byte(struct hdq_data *hdq_data, u8 *val)
goto out;
}
+ hdq_data-hdq_irqstatus = 0;
+
if (!(hdq_data-hdq_irqstatus OMAP_HDQ_INT_STATUS_RXCOMPLETE)) {
hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS,
OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO,
@@ -426,7 +450,8 @@ static int omap_hdq_get(struct hdq_data
[PATCHv2 2/5] w1: omap_hdq: Add compatible property for omap hdq driver.
Add compatible property for omap hdq driver.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
.../devicetree/bindings/hdq1w/omap_hdq.txt | 20
drivers/w1/masters/omap_hdq.c |8
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hdq1w/omap_hdq.txt
diff --git a/Documentation/devicetree/bindings/hdq1w/omap_hdq.txt
b/Documentation/devicetree/bindings/hdq1w/omap_hdq.txt
new file mode 100644
index 000..a7e011e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hdq1w/omap_hdq.txt
@@ -0,0 +1,20 @@
+HDQ/1w for OMAP platforms
+
+Required properties :
+- compatible : Must be ti,am43xx-hdq.
+- ti,hwmods : Must be hdq1w.
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clock: Clock input to HDQ1w controller.
+
+Example:
+
+ hdq: hdq@48347000 {
+ compatible = ti,am43xx-hdq;
+ reg = 0x48347000 0x1000;
+ interrupts = GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH;
+ clocks = func_12m_clk;
+ clock-names = fck;
+ ti,hwmods = hdq1w;
+ status = disabled;
+ };
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index ca3623c..97a8412 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/sched.h
#include linux/pm_runtime.h
+#include linux/of.h
#include ../w1.h
#include ../w1_int.h
@@ -73,11 +74,18 @@ struct hdq_data {
static int omap_hdq_probe(struct platform_device *pdev);
static int omap_hdq_remove(struct platform_device *pdev);
+static const struct of_device_id omap_hdq_dt_match[] = {
+ { .compatible = ti,am43xx-hdq},
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_hdq_dt_match);
+
static struct platform_driver omap_hdq_driver = {
.probe =omap_hdq_probe,
.remove = omap_hdq_remove,
.driver = {
.name = omap_hdq,
+ .of_match_table = of_match_ptr(omap_hdq_dt_match),
},
};
--
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
[PATCHv2 0/5] AM437x: HDQ/1wire protocol
This series adds support for HDQ/1w protocol driver for am43x epos evm where it can be used for measuring the temperature of a slave device connected to a particular header. Tested the patch series on AM437x, hdq master and slave devices are getting registered and interrupts are getting triggered for break and tx conditions. v1-v2: cleaned up hdq_disable_interrupt api. Sourav Poddar (5): drivers: w1: omap_hdq: cleanup and bug fixes. w1: omap_hdq: Add compatible property for omap hdq driver. arm: mach-omap2: selective device build from the platform code. arm: dts: am4372: Add hdq device tree data. arm: hwmod: am437x: Add hwmod data for hdq1w. .../devicetree/bindings/hdq1w/omap_hdq.txt | 20 + arch/arm/boot/dts/am4372.dtsi | 10 +++ arch/arm/boot/dts/am43x-epos-evm.dts | 12 +++ arch/arm/mach-omap2/hdq1w.c|2 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 arch/arm/mach-omap2/prcm43xx.h |1 + drivers/w1/masters/omap_hdq.c | 93 7 files changed, 157 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/hdq1w/omap_hdq.txt -- 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
[PATCHv2 4/5] arm: dts: am4372: Add hdq device tree data.
Add device tree nodes and pinmux for hdq/1wire on
am43x epos evm.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/am4372.dtsi| 10 ++
arch/arm/boot/dts/am43x-epos-evm.dts | 12
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..5f7c167 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -735,6 +735,16 @@
#size-cells = 1;
status = disabled;
};
+
+ hdq: hdq@48347000 {
+ compatible = ti,am43xx-hdq;
+ reg = 0x48347000 0x1000;
+ interrupts = GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH;
+ clocks = func_12m_clk;
+ clock-names = fck;
+ ti,hwmods = hdq1w;
+ status = disabled;
+ };
};
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..e71ef1c 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -138,6 +138,12 @@
0x160 (PIN_INPUT | MUX_MODE7) /*
spi0_cs1.gpio0_6 */
;
};
+
+ hdq_pins: pinmux_hdq_pins {
+ pinctrl-single,pins =
+ 0x234 (PIN_INPUT_PULLUP | MUX_MODE1)/*
cam1_wen.hdq_gpio */
+ ;
+ };
};
matrix_keypad: matrix_keypad@0 {
@@ -367,3 +373,9 @@
pinctrl-0 = spi1_pins;
status = okay;
};
+
+hdq {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = hdq_pins;
+};
--
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
[PATCHv2 3/5] arm: omap2: skip device build from platform code for dt.
For SOCs with dt enabled, device should be build through device tree.
Prevent device build call from platform code, if device tree is
enabled.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/mach-omap2/hdq1w.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/hdq1w.c b/arch/arm/mach-omap2/hdq1w.c
index cbc8e3c..f78b4a1 100644
--- a/arch/arm/mach-omap2/hdq1w.c
+++ b/arch/arm/mach-omap2/hdq1w.c
@@ -76,6 +76,7 @@ int omap_hdq1w_reset(struct omap_hwmod *oh)
return 0;
}
+#ifndef CONFIG_OF
static int __init omap_init_hdq(void)
{
int id = -1;
@@ -95,3 +96,4 @@ static int __init omap_init_hdq(void)
return 0;
}
omap_arch_initcall(omap_init_hdq);
+#endif
--
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
[PATCHv2 5/5] arm: hwmod: am437x: Add hwmod data for hdq1w.
These adds hwmod data for hdq/1w driver.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36
arch/arm/mach-omap2/prcm43xx.h |1 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc80..3a8ca96 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,7 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include hdq1w.h
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +416,32 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0014,
+ .syss_offs = 0x0018,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = am43xx_hdq1w_sysc,
+ .reset = omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = am43xx_hdq1w_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +681,14 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per - hdq1w */
+static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_hdq1w_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -748,6 +783,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+ am43xx_l4_ls__hdq1w,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be9..cabff53 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET0x05B8
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET0x05C0
+#define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET 0x04a0
#endif
--
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: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140416 06:20]: Add DT node for the ctrl-core sub module of the DRA7 control module. We map the CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register fields which configure clocks. The remainder of the registers are related to pad configurations or cross-bar configurations, and therefore aren't mapped. Can you please check if this can just use the existing regmap syscon mapping: syscon = dra7_ctrl_general; See how the drivers/regulator/pbias-regulator.c is using the syscon to initialize a regulator and then omap_hsmmc.c just does the standard regulator calls. The thing is that this bit needs to be set before the the DSS hwmods are reset, and that happens very early. If we don't do this, DSS won't reset properly, and not get back to an idle state. I am not sure where I can configure the syscon register early enough that it happens before the hwmods are reset. With a syscon mapping, I guess we would access the register when the DSS driver is probed. But that's too late for us. Ideally, it would be much better to have a syscon mapping. Do you have any suggestions how this can be achieved very early in boot? It's best to move the reset and initialization of DSS happen later. I believe we already are resetting only some of the hwmods early on. I looked at this in some more detail. With the current hwmod flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just the reset part(ocp reset/custom reset and sysc register) or the disable part that is skipped. hwmod still tries to enable the IP. This again results in the same issue. One thing which wasn't clear was that why do we enable a hwmod in the first place, if we know that we are going to skip reset? Probably to configure the idle bits. In general, we should configure the modules lazily as the driver probes as requested, and then idle the unused modules with a late_initcall. Okay, we were thinking of changing the hwmod code to skip enable for hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that doesn't seem like a viable option. I can't think of any other way of getting around this, besides making control module a clock provider. Paul said that it's not that bad to make DRA7 CTRL module a clock provider, but outside of PRCM code. I guess that would involve having something along the lines of of_prcm_init() in mach-omap2/control.c Archit Archit -- 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 0/2] OMAP2+: optional clock handling fixes
On Thursday 08 May 2014 05:38 AM, Paul Walmsley wrote: Hi Rajendra, On Wed, 23 Apr 2014, Rajendra Nayak wrote: The patches fix some opt clock handling in gpio and in hwmod. Rajendra Nayak (2): gpio: omap: prepare and unprepare the debounce clock ARM: OMAP2+: hwmod: Don't leave the optional clocks in clk_prepare()ed state arch/arm/mach-omap2/omap_hwmod.c | 13 ++--- drivers/gpio/gpio-omap.c | 10 +- 2 files changed, 7 insertions(+), 16 deletions(-) Can these patches be merged separately? Looks to me that the two options are either to: A. to merge them together, or B. to merge patch 1 first, then patch 2 Thats right. Or will things break if only patch 1 is merged? Things will break if only patch 2 is merged as gpios clk_enable() request would fail. Merging only patch 1 has no issues. If we merge them together, I'd say the best situation would be to take them through the OMAP tree, since the changes are all OMAP-specific. In that case we'll want an ack for the first patch from the GPIO maintainers, Linus Walleij linus.wall...@linaro.org and Alexandre Courbot gnu...@gmail.com. Otherwise the path of least resistance would be (B) - you can get patch 1 merged via the GPIO tree. The GPIO maintainers can then provide a stable branch for us to base our changes on, or we can wait until the change reaches Linus. Then we can subsequently merge patch 2 via the OMAP side. Thoughts? I am fine either way. I will check with Linus W. what he prefers. Thanks. regards, Rajendra - 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] ARM: OMAP2+: don't try to register the main clock twice.
I also get this message printed for the d_can driver with am335x; they have two entries in drivers/clk/ti/clk-33xx.c. Probably as a workaround to match the desired clock name for the d_can driver? Didn't really investigate yet. That's pretty weird. I wonder where the second fck alias is coming from? The DT hwmod data for those devices looks relatively straightforward. Is the hwmod code adding fck aliases for both of the entries from the clock file? $ grep 'can' drivers/clk/ti/clk-33xx.c * This program is free software; you can redistribute it and/or DT_CLK(NULL, dcan0_fck, dcan0_fck), DT_CLK(481cc000.d_can, NULL, dcan0_fck), DT_CLK(NULL, dcan1_fck, dcan1_fck), DT_CLK(481d.d_can, NULL, dcan1_fck), I quickly tried to remove the entries not specifying platform devices but that prevented my system from booting (Huh?). Still, no time to really check it, though. Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
On Wednesday 23 April 2014 11:41 AM, Rajendra Nayak wrote:
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Linus,
Do you mind picking this fix up via the GPIO tree? Alternatively you could
Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from this
series via the OMAP tree.
Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that order
else
gpio would break. More discussions are here [1].
Let us know what you think. Thanks.
regards,
Rajendra
[1] http://www.mail-archive.com/linux-gpio@vger.kernel.org/msg02801.html
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32 reg,
u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
writel_relaxed(debounce, reg);
@@ -245,7 +245,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
bank-dbck_enable_mask = val;
writel_relaxed(val, reg);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
/*
* Enable debounce clock per module.
* This call is mandatory because in omap_gpio_request() when
@@ -290,7 +290,7 @@ static void _clear_gpio_debounce(struct gpio_bank *bank,
unsigned gpio)
bank-context.debounce = 0;
writel_relaxed(bank-context.debounce, bank-base +
bank-regs-debounce);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
--
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 2/4] ARM: dts: Add ctrl-core DT node for DRA7
On 05/08/2014 09:02 AM, Archit Taneja wrote: On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140416 06:20]: Add DT node for the ctrl-core sub module of the DRA7 control module. We map the CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register fields which configure clocks. The remainder of the registers are related to pad configurations or cross-bar configurations, and therefore aren't mapped. Can you please check if this can just use the existing regmap syscon mapping: syscon = dra7_ctrl_general; See how the drivers/regulator/pbias-regulator.c is using the syscon to initialize a regulator and then omap_hsmmc.c just does the standard regulator calls. The thing is that this bit needs to be set before the the DSS hwmods are reset, and that happens very early. If we don't do this, DSS won't reset properly, and not get back to an idle state. I am not sure where I can configure the syscon register early enough that it happens before the hwmods are reset. With a syscon mapping, I guess we would access the register when the DSS driver is probed. But that's too late for us. Ideally, it would be much better to have a syscon mapping. Do you have any suggestions how this can be achieved very early in boot? It's best to move the reset and initialization of DSS happen later. I believe we already are resetting only some of the hwmods early on. I looked at this in some more detail. With the current hwmod flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just the reset part(ocp reset/custom reset and sysc register) or the disable part that is skipped. hwmod still tries to enable the IP. This again results in the same issue. One thing which wasn't clear was that why do we enable a hwmod in the first place, if we know that we are going to skip reset? Probably to configure the idle bits. In general, we should configure the modules lazily as the driver probes as requested, and then idle the unused modules with a late_initcall. Okay, we were thinking of changing the hwmod code to skip enable for hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that doesn't seem like a viable option. I can't think of any other way of getting around this, besides making control module a clock provider. Paul said that it's not that bad to make DRA7 CTRL module a clock provider, but outside of PRCM code. I guess that would involve having something along the lines of of_prcm_init() in mach-omap2/control.c That sounds like pretty much one of the things I have done here: https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip The patches in their current form haven't been posted yet though, as they are waiting for some of the pre-reqs, but feel free to re-use something from here. -Tero Archit Archit -- 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 V5 0/3] arm: dts: dra7: Updates for adding crossbar device
On Wednesday 07 May 2014 03:15 AM, Darren Etheridge wrote: Sricharan R r.sricha...@ti.com wrote on Tue [2014-May-06 19:26:16 +0530]: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. The dts file update to support the crossbar device and convert peripheral irq numbers to crossbar number are added here. This is a rebase of V4 series on top of 3.15-rc4 This series depends on crossbar-driver-fixes sent below http://marc.info/?l=linux-omapm=139929963420299w=2 Sricharan R (3): arm: dts: dra7: Add crossbar device binding arm: dts: dra7: Replace peripheral interrupt numbers with crossbar inputs arm: dts: dra7: Add routable-irqs property for gic node OK, assuming the bisectability issues discussed earlier on this thread are addressed. I have tested the earlier crossbar patch series in conjunction with this dts series with VIP capture and DSS display running together on DRA7. Looks good with this combination of devices. VIP is one of the modules that must have a crossbar mapping as there is no default interrupt mapping for it, therefore VIP makes a good test case. So please feel free to add: Tested-by: Darren Etheridge detheri...@ti.com DMM doesn't get used by default since it's hwmod is missing in DRA7x's hwmod data. I added the hwmod and tried using dmm with omapdrm, it works fine. So, for DSS and DMM: Tested-by: Archit Taneja arc...@ti.com arch/arm/boot/dts/dra7.dtsi | 109 +-- 1 file changed, 63 insertions(+), 46 deletions(-) -- 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 -- 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 -- 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 2/4] ARM: dts: Add ctrl-core DT node for DRA7
On Thursday 08 May 2014 01:23 PM, Tero Kristo wrote: On 05/08/2014 09:02 AM, Archit Taneja wrote: On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140505 22:24]: Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140416 06:20]: Add DT node for the ctrl-core sub module of the DRA7 control module. We map the CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register fields which configure clocks. The remainder of the registers are related to pad configurations or cross-bar configurations, and therefore aren't mapped. Can you please check if this can just use the existing regmap syscon mapping: syscon = dra7_ctrl_general; See how the drivers/regulator/pbias-regulator.c is using the syscon to initialize a regulator and then omap_hsmmc.c just does the standard regulator calls. The thing is that this bit needs to be set before the the DSS hwmods are reset, and that happens very early. If we don't do this, DSS won't reset properly, and not get back to an idle state. I am not sure where I can configure the syscon register early enough that it happens before the hwmods are reset. With a syscon mapping, I guess we would access the register when the DSS driver is probed. But that's too late for us. Ideally, it would be much better to have a syscon mapping. Do you have any suggestions how this can be achieved very early in boot? It's best to move the reset and initialization of DSS happen later. I believe we already are resetting only some of the hwmods early on. I looked at this in some more detail. With the current hwmod flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just the reset part(ocp reset/custom reset and sysc register) or the disable part that is skipped. hwmod still tries to enable the IP. This again results in the same issue. One thing which wasn't clear was that why do we enable a hwmod in the first place, if we know that we are going to skip reset? Probably to configure the idle bits. In general, we should configure the modules lazily as the driver probes as requested, and then idle the unused modules with a late_initcall. Okay, we were thinking of changing the hwmod code to skip enable for hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that doesn't seem like a viable option. I can't think of any other way of getting around this, besides making control module a clock provider. Paul said that it's not that bad to make DRA7 CTRL module a clock provider, but outside of PRCM code. I guess that would involve having something along the lines of of_prcm_init() in mach-omap2/control.c That sounds like pretty much one of the things I have done here: https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip The patches in their current form haven't been posted yet though, as they are waiting for some of the pre-reqs, but feel free to re-use something from here. Ah nice, thanks! Archit -- 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 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Wednesday, May 07, 2014 6:26 PM, Arnd Bergmann wrote:
On Wednesday 07 May 2014 14:52:47 Kishon Vijay Abraham I wrote:
On Tuesday 06 May 2014 10:05 PM, Jason Gunthorpe wrote:
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+compatible = ti,dra7xx-pcie;
+reg = 0x51002000 0x14c, 0x5100 0x2000;
+reg-names = ti_conf, rc_dbics;
+interrupts = 0 232 0x4, 0 233 0x4;
+#address-cells = ;
+#size-cells = 2;
+device_type = pci;
+ti,device_type = ;
+ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
Configuration space should not show up in the ranges, please don't
copy that mistake from other drivers, put it in reg.
But then it needs pcie-designware.c to be modified and it will be breaking
other platforms no?
I think the pcie-designware driver should be changed to allow either way.
Ideally we would deprecate the existing method in a way that for new
front-ends
it doesn't work, but the old front-ends can still deal with it but also work
if you put it into the reg property.
(+cc Pratyush Anand, Thierry Reding)
Hi Arnd,
Thank you for your comment.
Do you mean the case of Tegra PCIe as below?
./arch/arm/boot/dts/tegra20.dts
pcie-controller@80003000 {
...
reg = 0x80003000 0x0800 /* PADS registers */
0x80003800 0x0200 /* AFI registers */
0x9000 0x1000; /* configuration space */
...
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /*
port 0 registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /*
port 1 registers */
0x8100 0 0 0x8200 0 0x0001 /*
downstream I/O */
0x8200 0 0xa000 0xa000 0 0x0800 /*
non-prefetchable memory */
0xc200 0 0xa800 0xa800 0 0x1800; /*
prefetchable memory */
...
./drivers/pci/host/pci-tegra.c
/* request configuration space, but remap later, on demand */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, cs);
...
pcie-cs = devm_request_mem_region(pcie-dev, res-start,
resource_size(res), res-name);
Best regards,
Jingoo Han
--
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: AM33XX: fix ethernet and mdio default state
Make sure ethernet and mdio nodes are disabled by default and enable
them explicitly only on boards that actually use them.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 3 ++-
arch/arm/boot/dts/am335x-evm.dts | 2 ++
arch/arm/boot/dts/am335x-evmsk.dts| 2 ++
arch/arm/boot/dts/am335x-igep0033.dtsi| 8
arch/arm/boot/dts/am335x-nano.dts | 5 +
arch/arm/boot/dts/am33xx.dtsi | 2 ++
6 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932887b5..26a1fa958f37 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -280,13 +280,14 @@
pinctrl-names = default, sleep;
pinctrl-0 = cpsw_default;
pinctrl-1 = cpsw_sleep;
-
+ status = okay;
};
davinci_mdio {
pinctrl-names = default, sleep;
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
+ status = okay;
};
mmc1 {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 6028217ace0f..44c63d1c4f12 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -614,12 +614,14 @@
pinctrl-names = default, sleep;
pinctrl-0 = cpsw_default;
pinctrl-1 = cpsw_sleep;
+ status = okay;
};
davinci_mdio {
pinctrl-names = default, sleep;
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
+ status = okay;
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab238850a7b2..365383f7f617 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -484,12 +484,14 @@
pinctrl-0 = cpsw_default;
pinctrl-1 = cpsw_sleep;
dual_emac = 1;
+ status = okay;
};
davinci_mdio {
pinctrl-names = default, sleep;
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
+ status = okay;
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 9f22c189f636..27445d07f953 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -95,6 +95,14 @@
};
};
+mac {
+ status = okay;
+};
+
+davinci_mdio {
+ status = okay;
+};
+
cpsw_emac0 {
phy_id = davinci_mdio, 0;
};
diff --git a/arch/arm/boot/dts/am335x-nano.dts
b/arch/arm/boot/dts/am335x-nano.dts
index 9907b494b99c..a3466455b171 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -344,6 +344,11 @@
mac {
dual_emac = 1;
+ status = okay;
+};
+
+davinci_mdio {
+ status = okay;
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index cb6811e5ae5a..0fb5df4ad498 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -688,6 +688,7 @@
*/
interrupts = 40 41 42 43;
ranges;
+ status = disabled;
davinci_mdio: mdio@4a101000 {
compatible = ti,davinci_mdio;
@@ -696,6 +697,7 @@
ti,hwmods = davinci_mdio;
bus_freq = 100;
reg = 0x4a101000 0x100;
+ status = disabled;
};
cpsw_emac0: slave@4a100200 {
--
1.8.3.2
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html Thank you. Best regards, Jingoo Han I also suspect you will have to implement swiotlb support to make generic PCI devices work behind this bridge. Otherwise you end up with random physical addresses passed into DMA registers. -- 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/3] clk: ti: add 'ti,round-rate' flag
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
It could be argued that this is a bug, but as the current drivers may
depend on that behavior, a new flag 'ti,round-rate' is added which
enables clock rate rounding.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Documentation/devicetree/bindings/clock/ti/dpll.txt | 2 ++
drivers/clk/ti/dpll.c | 3 +++
include/linux/clk/ti.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 30bfdb7c9f18..7912d876e858 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -48,6 +48,8 @@ Optional properties:
- ti,low-power-stop : DPLL supports low power stop mode, gating output
- ti,low-power-bypass : DPLL output matches rate of parent bypass clock
- ti,lock : DPLL locks in programmed rate
+- ti,round-rate : if not set, the dpll will return an error if asked for a
+ clock rate that it cannot produce exactly.
Examples:
dpll_core_ck: dpll_core_ck@44e00490 {
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a44f97d..c5858c46b58c 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dpll_mode)
dd-modes = dpll_mode;
+ if (of_property_read_bool(node, ti,round-rate))
+ clk_hw-flags |= DPLL_USE_ROUNDED_RATE;
+
ti_clk_register_dpll(clk_hw-hw, node);
return;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 4a21a872dbbd..79e8a7876457 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -155,6 +155,7 @@ struct clk_hw_omap {
#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 5)
#define MEMMAP_ADDRESSING (1 6)
+#define DPLL_USE_ROUNDED_RATE (1 7)/* dpll's round_rate() returns
rounded rate */
/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
#define DPLL_LOW_POWER_STOP0x1
--
1.9.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 3/3] arm: dts: fix display clk rate rounding for am33xx am43xx
Add ti,round-rate flag for the display PLLs for both AM33xx and AM43xx.
This is needed so that the display driver can request pixel clocks
freely.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/am33xx-clocks.dtsi | 1 +
arch/arm/boot/dts/am43xx-clocks.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe508dea2..3e152d0d6bdc 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -266,6 +266,7 @@
compatible = ti,am3-dpll-no-gate-clock;
clocks = sys_clkin_ck, sys_clkin_ck;
reg = 0x0498, 0x0448, 0x0454;
+ ti,round-rate;
};
dpll_disp_m2_ck: dpll_disp_m2_ck {
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009cc9332..23019f3f3fbf 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -218,6 +218,7 @@
compatible = ti,am3-dpll-clock;
clocks = sys_clkin_ck, sys_clkin_ck;
reg = 0x2e20, 0x2e24, 0x2e2c;
+ ti,round-rate;
};
dpll_disp_m2_ck: dpll_disp_m2_ck {
--
1.9.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 2/3] ARM: OMAP2+: fix dpll round_rate() to actually round
omap2_dpll_round_rate() doesn't actually round the given rate, even if
the name and the description so hints. Instead it only tries to find an
exact rate match, or if that fails, return ~0 as an error.
What this basically means is that the user of the clock needs to know
what rates the dpll can support, which obviously isn't right.
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
However, as it is unclear whether current drivers rely on the current
behavior, the rounding functionality not enabled by default, but by
setting DPLL_USE_ROUNDED_RATE for the DPLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 332af927f4d3..ddbb8d003719 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long
target_rate,
struct dpll_data *dd;
unsigned long ref_rate;
const char *clk_name;
+ unsigned long diff, closest_diff = ~0;
+ bool use_rounding = clk-flags DPLL_USE_ROUNDED_RATE;
if (!clk || !clk-dpll_data)
return ~0;
@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
pr_debug(clock: %s: m = %d: n = %d: new_rate = %lu\n,
clk_name, m, n, new_rate);
- if (target_rate == new_rate) {
+ diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+ if ((use_rounding diff closest_diff) ||
+ (!use_rounding diff == 0)) {
+ closest_diff = diff;
+
dd-last_rounded_m = m;
dd-last_rounded_n = n;
- dd-last_rounded_rate = target_rate;
- break;
+ dd-last_rounded_rate = new_rate;
+
+ if (diff == 0)
+ break;
}
}
- if (target_rate != new_rate) {
+ if (closest_diff == ~0) {
pr_debug(clock: %s: cannot round to rate %lu\n,
clk_name, target_rate);
return ~0;
}
- return target_rate;
+ if (closest_diff 0)
+ pr_debug(clock: %s: rounded rate %lu to %lu\n,
+clk_name, target_rate, dd-last_rounded_rate);
+
+ return dd-last_rounded_rate;
}
--
1.9.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: OMAP baseline test results for v3.15-rc4
On 8 May 2014 06:23, Paul Walmsley p...@pwsan.com wrote: Here are some basic OMAP test results for Linux v3.15-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.15-rc4/20140505112251/ Test summary snip The eMMC on the 4460 VAR-SOM-OM has failed; I guess it's run out of reserve blocks to reallocate. Now it's time to find yet another way to boot it. I have some patches for u-boot which makes it possible to use the on-board LAN7500 USB Ethernet controller for tftp. Since you have a VAR-SOM-OM44 module maybe you could test my dts patches for it? I will post a new version of the patch set early next week. I can cc you. Do you have the VAR-DVK-OM44 eval board? regards Joachim Eastwood -- 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
[RFC 1/6] omapdss: remove check for simpler port/endpoint binding
The support for simpler port/endpoint binding was removed in the merged version
of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
port exists. Remove this as this doesn't work.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..31ef262 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device
*pdev)
return 0;
port = omapdss_of_get_next_port(parent, NULL);
- if (!port) {
-#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_init_port(pdev, parent);
-#endif
+ if (!port)
return 0;
- }
do {
u32 reg;
--
1.8.3.2
--
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
[RFC 2/6] omapdss: add init port functions for different omap revs
The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.
For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property to specify the DPI output number.
The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
'reg' is used to specify whether the output is SDI, or a later DPI instance.
Create DSS revision specific init/uninit_port functions such that we have a
separate functions for OMAP34xx, this helps us deal with the SDI case
separately.
Also, make the uninit_port functions iterative since we will have multiple DPI
ports in the future.
dpi_uninit_port/sdi_uninit_port functions have to be removed from the exit
section as dss_features(which is initconst data) uses it, this prevents the
section mismatch.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 88 ++---
drivers/video/fbdev/omap2/dss/dss.h | 4 +-
drivers/video/fbdev/omap2/dss/sdi.c | 2 +-
4 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c
b/drivers/video/fbdev/omap2/dss/dpi.c
index 157921d..6593c8b 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -765,7 +765,7 @@ err_datalines:
return r;
}
-void __exit dpi_uninit_port(void)
+void dpi_uninit_port(struct platform_device *pdev, struct device_node *port)
{
if (!dpi.port_initialized)
return;
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index 31ef262..c415029 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -65,12 +65,18 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+static int __init dss_init_ports(struct platform_device *pdev);
+static int __init dss_init_ports_omap34xx(struct platform_device *pdev);
+static void dss_uninit_ports(struct platform_device *pdev);
+static void dss_uninit_ports_omap34xx(struct platform_device *pdev);
struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
int (*dpi_select_source)(enum omap_channel channel);
+ int (*init_ports)(struct platform_device *pdev);
+ void (*uninit_ports)(struct platform_device *pdev);
};
static struct {
@@ -698,6 +704,8 @@ static const struct dss_features omap24xx_dss_feats
__initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name= core_ck,
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
+ .init_ports = dss_init_ports,
+ .uninit_ports = dss_uninit_ports,
};
static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -705,6 +713,8 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name= dpll4_ck,
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
+ .init_ports = dss_init_ports_omap34xx,
+ .uninit_ports = dss_uninit_ports_omap34xx,
};
static const struct dss_features omap3630_dss_feats __initconst = {
@@ -712,6 +722,8 @@ static const struct dss_features omap3630_dss_feats
__initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name= dpll4_ck,
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
+ .init_ports = dss_init_ports,
+ .uninit_ports = dss_uninit_ports,
};
static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -719,6 +731,8 @@ static const struct dss_features omap44xx_dss_feats
__initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name= dpll_per_x2_ck,
.dpi_select_source = dss_dpi_select_source_omap4,
+ .init_ports = dss_init_ports,
+ .uninit_ports = dss_uninit_ports,
};
static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -726,6 +740,8 @@ static const struct dss_features omap54xx_dss_feats
__initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name= dpll_per_x2_ck,
.dpi_select_source = dss_dpi_select_source_omap5,
+ .init_ports = dss_init_ports,
+ .uninit_ports = dss_uninit_ports,
};
static int __init dss_init_features(struct platform_device *pdev)
@@ -774,7 +790,7 @@ static int __init
[RFC 3/6] omapdss: DT: Get source endpoint by matching reg-id
In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node,
and then see what omapdss output has the matching device_node pointer in
omap_dss_find_output_by_node.
For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS
device_node pointer. If the source is one of these outputs, the above method
won't work.
To get the correct output for ports within DSS with the existing omapdss DT
framework, we check in omapdss_of_find_source_for_first_ep, whether the source
node is of the DSS parent device. If so, we take an extra step of extracting
the 'reg' property from the port corresponding to the endpoint source, and get
the omap_dss_device output by matching both device_node and reg-id.
We would want to get rid of this eventually, and support multiple ports in
general. That would involve making some more changes the omapdss DT
framework.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dss-of.c | 41 ++
drivers/video/fbdev/omap2/dss/dss.c| 6 +
drivers/video/fbdev/omap2/dss/dss.h| 2 ++
drivers/video/fbdev/omap2/dss/output.c | 15 +
include/video/omapdss.h| 6 +
5 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c
b/drivers/video/fbdev/omap2/dss/dss-of.c
index a4b20aa..4261c14 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -19,6 +19,7 @@
#include linux/seq_file.h
#include video/omapdss.h
+#include dss.h
struct device_node *
omapdss_of_get_next_port(const struct device_node *parent,
@@ -142,12 +143,44 @@ omapdss_of_find_source_for_first_ep(struct device_node
*node)
src_node = omapdss_of_get_remote_device_node(ep);
- of_node_put(ep);
-
- if (!src_node)
+ if (!src_node) {
+ of_node_put(ep);
return ERR_PTR(-EINVAL);
+ }
- src = omap_dss_find_output_by_node(src_node);
+ /*
+* TODO: Find a better solution for this.
+*
+* DPI and SDI outputs share the same DSS device node. In order to find
+* the correct omap_dss_device output, we need to match the reg-id
+* property of the DPI/SDI port.
+*
+* For the special case of device_node being the parent DSS device, make
+* sure we check for both device_node and reg-id to get the correct
+* source
+*/
+ if (src_node == dss_device_node()) {
+ struct device_node *src_port;
+ u32 reg;
+ int r;
+
+ src_port = of_parse_phandle(ep, remote-endpoint, 0);
+
+ /* the parent of the endpoint is always the port node */
+ src_port = of_get_next_parent(src_port);
+
+ r = of_property_read_u32(src_port, reg, reg);
+ if (r)
+ reg = 0;
+
+ of_node_put(src_port);
+
+ src = omap_dss_find_output_by_node_and_reg(src_node, reg);
+ } else {
+ src = omap_dss_find_output_by_node(src_node);
+ }
+
+ of_node_put(ep);
of_node_put(src_node);
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index c415029..4087f3b 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -790,6 +790,12 @@ static int __init dss_init_features(struct platform_device
*pdev)
return 0;
}
+/* of_node pointer for the DSS parent node */
+struct device_node *dss_device_node(void)
+{
+ return dss.pdev-dev.of_node;
+}
+
static int __init dss_init_ports_omap34xx(struct platform_device *pdev)
{
struct device_node *parent = pdev-dev.of_node;
diff --git a/drivers/video/fbdev/omap2/dss/dss.h
b/drivers/video/fbdev/omap2/dss/dss.h
index 9f4ee49..6f68f72 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -240,6 +240,8 @@ typedef bool (*dss_div_calc_func)(unsigned long fck, void
*data);
bool dss_div_calc(unsigned long pck, unsigned long fck_min,
dss_div_calc_func func, void *data);
+struct device_node *dss_device_node(void);
+
/* SDI */
int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
diff --git a/drivers/video/fbdev/omap2/dss/output.c
b/drivers/video/fbdev/omap2/dss/output.c
index 2ab3afa..2b556f1 100644
--- a/drivers/video/fbdev/omap2/dss/output.c
+++ b/drivers/video/fbdev/omap2/dss/output.c
@@ -144,6 +144,21 @@ struct omap_dss_device
*omap_dss_find_output_by_node(struct device_node *node)
}
EXPORT_SYMBOL(omap_dss_find_output_by_node);
+struct omap_dss_device
+ *omap_dss_find_output_by_node_and_reg(struct device_node *node,
+ u32 reg)
+{
+ struct omap_dss_device *out;
+
+ list_for_each_entry(out, output_list, list) {
+ if (out-dev-of_node == node
[RFC 5/6] omapdss: DPI: make dpi_get_channel take DPI reg-id
To support multiple DPI instances, dpi_get_channel needs to take the DPI
instance's reg-id to get the corresponding channel. Make it take this
argument.
We just pass 0 in the non-DT path, since we don't support multiple instances
in the non-DT case.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c
b/drivers/video/fbdev/omap2/dss/dpi.c
index b891e17..faf266e 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -640,7 +640,7 @@ static void dpi_init_pll(struct dpi_data *dpi)
* the channel in some more dynamic manner, or get the channel as a user
* parameter.
*/
-static enum omap_channel dpi_get_channel(void)
+static enum omap_channel dpi_get_channel(int reg)
{
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
@@ -733,7 +733,7 @@ static void dpi_init_output(struct platform_device *pdev)
out-id = OMAP_DSS_OUTPUT_DPI;
out-output_type = OMAP_DISPLAY_TYPE_DPI;
out-name = dpi.0;
- out-dispc_channel = dpi_get_channel();
+ out-dispc_channel = dpi_get_channel(0);
out-ops.dpi = dpi_ops;
out-owner = THIS_MODULE;
@@ -768,7 +768,7 @@ static void dpi_init_output_port(struct platform_device
*pdev,
out-dev = pdev-dev;
out-id = OMAP_DSS_OUTPUT_DPI;
out-output_type = OMAP_DISPLAY_TYPE_DPI;
- out-dispc_channel = dpi_get_channel();
+ out-dispc_channel = dpi_get_channel(reg);
out-ops.dpi = dpi_ops;
out-reg = reg;
out-owner = THIS_MODULE;
--
1.8.3.2
--
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
[RFC 4/6] omapdss: DPI: support multiple DPI instances
SoCs containing DSS until now had only one DPI instance. DRA7x has 3 DPI
instances.
In order to support multiple instances, we allocate a driver data
struct(dpi_data) for each instance. This is somewhat similar to how DSI driver
was changed to support multiple instances.
One difference is that there are no platform devices for each instance when DT
is used. In the DT case, we store the dpi_data pointer in the DPI port's
(of the type struct device_node) data pointer. In the non DT case, we still
have dummy platform devices, and the device's private data pointer is used to
store the DPI instance's dpi_data.
When an encoder/panel driver calls a dpi op, we get dpi_data using the function
dpi_get_data_from_dssdev. This function iterates through the ports under DSS
device node, and returns the port which has reg-id matching the reg-id specified
in omap_dss_device.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dpi.c | 282 +---
1 file changed, 200 insertions(+), 82 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c
b/drivers/video/fbdev/omap2/dss/dpi.c
index 6593c8b..b891e17 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -37,7 +37,7 @@
#include dss.h
#include dss_features.h
-static struct {
+struct dpi_data {
struct platform_device *pdev;
struct regulator *vdds_dsi_reg;
@@ -52,7 +52,45 @@ static struct {
struct omap_dss_device output;
bool port_initialized;
-} dpi;
+};
+
+static struct dpi_data *dpi_get_data_from_dssdev(struct omap_dss_device
*dssdev)
+{
+ struct device_node *parent = dssdev-dev-of_node;
+ struct device_node *port;
+
+ /* non DT */
+ if (!parent) {
+ struct omap_dss_device *out = dssdev-src;
+
+ return dev_get_drvdata(out-dev);
+ }
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return NULL;
+
+ do {
+ int r;
+ u32 reg;
+
+ r = of_property_read_u32(port, reg, reg);
+ if (r)
+ reg = 0;
+
+ if (reg == dssdev-reg)
+ return port-data;
+
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+
+ return NULL;
+}
+
+/* use only for non DT mode */
+static struct dpi_data *dpi_get_data_from_pdev(struct platform_device *pdev)
+{
+ return dev_get_drvdata(pdev-dev);
+}
static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
{
@@ -197,15 +235,16 @@ static bool dpi_calc_dss_cb(unsigned long fck, void *data)
dpi_calc_dispc_cb, ctx);
}
-static bool dpi_dsi_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
+static bool dpi_dsi_clk_calc(struct dpi_data *dpi, unsigned long pck,
+ struct dpi_clk_calc_ctx *ctx)
{
unsigned long clkin;
unsigned long pll_min, pll_max;
- clkin = dsi_get_pll_clkin(dpi.dsidev);
+ clkin = dsi_get_pll_clkin(dpi-dsidev);
memset(ctx, 0, sizeof(*ctx));
- ctx-dsidev = dpi.dsidev;
+ ctx-dsidev = dpi-dsidev;
ctx-pck_min = pck - 1000;
ctx-pck_max = pck + 1000;
ctx-dsi_cinfo.clkin = clkin;
@@ -213,7 +252,7 @@ static bool dpi_dsi_clk_calc(unsigned long pck, struct
dpi_clk_calc_ctx *ctx)
pll_min = 0;
pll_max = 0;
- return dsi_pll_calc(dpi.dsidev, clkin,
+ return dsi_pll_calc(dpi-dsidev, clkin,
pll_min, pll_max,
dpi_calc_pll_cb, ctx);
}
@@ -249,7 +288,7 @@ static bool dpi_dss_clk_calc(unsigned long pck, struct
dpi_clk_calc_ctx *ctx)
-static int dpi_set_dsi_clk(enum omap_channel channel,
+static int dpi_set_dsi_clk(struct dpi_data *dpi, enum omap_channel channel,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
@@ -257,18 +296,18 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
int r;
bool ok;
- ok = dpi_dsi_clk_calc(pck_req, ctx);
+ ok = dpi_dsi_clk_calc(dpi, pck_req, ctx);
if (!ok)
return -EINVAL;
- r = dsi_pll_set_clock_div(dpi.dsidev, ctx.dsi_cinfo);
+ r = dsi_pll_set_clock_div(dpi-dsidev, ctx.dsi_cinfo);
if (r)
return r;
dss_select_lcd_clk_source(channel,
dpi_get_alt_clk_src(channel));
- dpi.mgr_config.clock_info = ctx.dispc_cinfo;
+ dpi-mgr_config.clock_info = ctx.dispc_cinfo;
*fck = ctx.dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = ctx.dispc_cinfo.lck_div;
@@ -277,8 +316,8 @@ static int dpi_set_dsi_clk(enum omap_channel channel,
return 0;
}
-static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
- int *lck_div, int *pck_div)
+static int dpi_set_dispc_clk(struct dpi_data *dpi, unsigned long
[RFC 6/6] omapdss: DSS: add reg-id param to dpi_select_source
Add an argument which describes which DPI instance we are referring to when
selecting it's overlay manager. This will come into use when a DSS version
supports multiple DPI instances.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 12 ++--
drivers/video/fbdev/omap2/dss/dss.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c
b/drivers/video/fbdev/omap2/dss/dpi.c
index faf266e..def8e68 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -420,7 +420,7 @@ static int dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_get_dispc;
- r = dss_dpi_select_source(out-manager-id);
+ r = dss_dpi_select_source(out-reg, out-manager-id);
if (r)
goto err_src_sel;
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index 4087f3b..ffa6d84 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -74,7 +74,7 @@ struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
- int (*dpi_select_source)(enum omap_channel channel);
+ int (*dpi_select_source)(int id, enum omap_channel channel);
int (*init_ports)(struct platform_device *pdev);
void (*uninit_ports)(struct platform_device *pdev);
};
@@ -570,7 +570,7 @@ enum dss_hdmi_venc_clk_source_select
dss_get_hdmi_venc_clk_source(void)
return REG_GET(DSS_CONTROL, 15, 15);
}
-static int dss_dpi_select_source_omap2_omap3(enum omap_channel channel)
+static int dss_dpi_select_source_omap2_omap3(int id, enum omap_channel channel)
{
if (channel != OMAP_DSS_CHANNEL_LCD)
return -EINVAL;
@@ -578,7 +578,7 @@ static int dss_dpi_select_source_omap2_omap3(enum
omap_channel channel)
return 0;
}
-static int dss_dpi_select_source_omap4(enum omap_channel channel)
+static int dss_dpi_select_source_omap4(int id, enum omap_channel channel)
{
int val;
@@ -598,7 +598,7 @@ static int dss_dpi_select_source_omap4(enum omap_channel
channel)
return 0;
}
-static int dss_dpi_select_source_omap5(enum omap_channel channel)
+static int dss_dpi_select_source_omap5(int id, enum omap_channel channel)
{
int val;
@@ -624,9 +624,9 @@ static int dss_dpi_select_source_omap5(enum omap_channel
channel)
return 0;
}
-int dss_dpi_select_source(enum omap_channel channel)
+int dss_dpi_select_source(int id, enum omap_channel channel)
{
- return dss.feat-dpi_select_source(channel);
+ return dss.feat-dpi_select_source(id, channel);
}
static int dss_get_clocks(void)
diff --git a/drivers/video/fbdev/omap2/dss/dss.h
b/drivers/video/fbdev/omap2/dss/dss.h
index 6f68f72..f3ddcc9 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -209,7 +209,7 @@ int dss_init_platform_driver(void) __init;
void dss_uninit_platform_driver(void);
unsigned long dss_get_dispc_clk_rate(void);
-int dss_dpi_select_source(enum omap_channel channel);
+int dss_dpi_select_source(int id, enum omap_channel channel);
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
--
1.8.3.2
--
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 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Thursday 08 May 2014 17:56:38 Jingoo Han wrote:
On Wednesday, May 07, 2014 6:26 PM, Arnd Bergmann wrote:
On Wednesday 07 May 2014 14:52:47 Kishon Vijay Abraham I wrote:
On Tuesday 06 May 2014 10:05 PM, Jason Gunthorpe wrote:
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+compatible = ti,dra7xx-pcie;
+reg = 0x51002000 0x14c, 0x5100 0x2000;
+reg-names = ti_conf, rc_dbics;
+interrupts = 0 232 0x4, 0 233 0x4;
+#address-cells = ;
+#size-cells = 2;
+device_type = pci;
+ti,device_type = ;
+ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
Configuration space should not show up in the ranges, please don't
copy that mistake from other drivers, put it in reg.
But then it needs pcie-designware.c to be modified and it will be breaking
other platforms no?
I think the pcie-designware driver should be changed to allow either way.
Ideally we would deprecate the existing method in a way that for new
front-ends
it doesn't work, but the old front-ends can still deal with it but also work
if you put it into the reg property.
(+cc Pratyush Anand, Thierry Reding)
Hi Arnd,
Thank you for your comment.
Do you mean the case of Tegra PCIe as below?
./arch/arm/boot/dts/tegra20.dts
pcie-controller@80003000 {
...
reg = 0x80003000 0x0800 /* PADS registers */
0x80003800 0x0200 /* AFI registers */
0x9000 0x1000; /* configuration space */
...
ranges = 0x8200 0 0x8000 0x8000 0 0x1000
/* port 0 registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /*
port 1 registers */
0x8100 0 0 0x8200 0 0x0001 /*
downstream I/O */
0x8200 0 0xa000 0xa000 0 0x0800 /*
non-prefetchable memory */
0xc200 0 0xa800 0xa800 0 0x1800; /*
prefetchable memory */
...
./drivers/pci/host/pci-tegra.c
/* request configuration space, but remap later, on demand */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, cs);
...
pcie-cs = devm_request_mem_region(pcie-dev, res-start,
resource_size(res),
res-name);
Yes, that is how the config space should be handled normally.
Arnd
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 Arnd -- 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 1/2] gpio: omap: prepare and unprepare the debounce clock
Hello Rajendra,
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote:
On Wednesday 23 April 2014 11:41 AM, Rajendra Nayak wrote:
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Linus,
Do you mind picking this fix up via the GPIO tree? Alternatively you could
Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from
this
series via the OMAP tree.
Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that order
else
gpio would break. More discussions are here [1].
Let us know what you think. Thanks.
I wonder if that is really the case. Your Patch 2/2 removes the call
to clk_prepare on _init_opt_clks() but it also replaces
clk_{enable,disable} with clk_prepare_enable()/clk_disable_unprepare()
on _enable_optional_clocks() and _disable_optional_clocks()
respectively.
And GPIO banks are reset by hwmod on init which as far as I know
happen very early before the GPIO OMAP driver is even probed so by the
time clk_enable() is called on the GPIO driver the clock will already
be prepared by _enable_optional_clocks(). I tested linux-gpio/devel
branch + only your Patch 2/2 and the GPIOs were working correctly on a
OMAP3 board.
So I think that there isn't a strict dependency between these two
patches or am I missing something?
In fact now that I think about it I wonder what's the functional
change of your Patch 2/2 since hwmod is still calling clk_prepare()
before the driver. If the clocks should actually be controlled by the
drivers like you said then I think that we should remove
_{enable,disable}_optional_clocks() completely and let the drivers do
the clock prepare and enable like is made on your Patch 1/2 for the
GPIO driver.
What do you think about it?
Best regards,
Javier
regards,
Rajendra
[1] http://www.mail-archive.com/linux-gpio@vger.kernel.org/msg02801.html
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32
reg, u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
writel_relaxed(debounce, reg);
@@ -245,7 +245,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
bank-dbck_enable_mask = val;
writel_relaxed(val, reg);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
/*
* Enable debounce clock per module.
* This call is mandatory because in omap_gpio_request() when
@@ -290,7 +290,7 @@ static void _clear_gpio_debounce(struct gpio_bank *bank,
unsigned gpio)
bank-context.debounce = 0;
writel_relaxed(bank-context.debounce, bank-base +
bank-regs-debounce);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-gpio in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.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: [PATCH 3/5] usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function
On Thursday 08 May 2014 02:51 PM, George Cherian wrote:
Move the extcon related code to its own function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 65
++--
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b739a24..0b9b1d8 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -450,6 +450,42 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap
*omap)
dwc3_omap_write_utmi_status(omap, reg);
}
+static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
+{
+ u32 ret;
'ret' shouldn't be unsigned.
Thanks
Kishon
+ struct device_node *node = omap-dev-of_node;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(node, extcon)) {
+ edev = extcon_get_edev_by_phandle(omap-dev, 0);
+ if (IS_ERR(edev)) {
+ dev_vdbg(omap-dev, couldn't get extcon device\n);
+ return -EPROBE_DEFER;
+ }
+
+ omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
+ ret = extcon_register_interest(omap-extcon_vbus_dev,
+edev-name, USB,
+omap-vbus_nb);
+ if (ret 0)
+ dev_vdbg(omap-dev, failed to register notifier for
USB\n);
+
+ omap-id_nb.notifier_call = dwc3_omap_id_notifier;
+ ret = extcon_register_interest(omap-extcon_id_dev,
+edev-name, USB-HOST,
+omap-id_nb);
+ if (ret 0)
+ dev_vdbg(omap-dev, failed to register notifier for
USB-HOST\n);
+
+ if (extcon_get_cable_state(edev, USB) == true)
+ dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
+ if (extcon_get_cable_state(edev, USB-HOST) == true)
+ dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+ }
+
+ return 0;
+}
+
static int dwc3_omap_probe(struct platform_device *pdev)
{
struct device_node *node = pdev-dev.of_node;
@@ -457,7 +493,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = pdev-dev;
- struct extcon_dev *edev;
struct regulator*vbus_reg = NULL;
int ret = -ENOMEM;
@@ -529,31 +564,9 @@ static int dwc3_omap_probe(struct platform_device *pdev)
dwc3_omap_enable_irqs(omap);
- if (of_property_read_bool(node, extcon)) {
- edev = extcon_get_edev_by_phandle(dev, 0);
- if (IS_ERR(edev)) {
- dev_vdbg(dev, couldn't get extcon device\n);
- ret = -EPROBE_DEFER;
- goto err2;
- }
-
- omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
- ret = extcon_register_interest(omap-extcon_vbus_dev,
- edev-name, USB, omap-vbus_nb);
- if (ret 0)
- dev_vdbg(dev, failed to register notifier for USB\n);
- omap-id_nb.notifier_call = dwc3_omap_id_notifier;
- ret = extcon_register_interest(omap-extcon_id_dev, edev-name,
- USB-HOST, omap-id_nb);
- if (ret 0)
- dev_vdbg(dev,
- failed to register notifier for USB-HOST\n);
-
- if (extcon_get_cable_state(edev, USB) == true)
- dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state(edev, USB-HOST) == true)
- dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
- }
+ ret = dwc3_omap_extcon_register(omap);
+ if (ret 0)
+ goto err2;
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
--
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] Cleanup and fixes for dwc3-omap
The series does some refactoring on dwc3_probe() Patch 1-3 - reduce the size of dwc3_probe() Patch 4 - Fix the crash on dwc3_omap removal Patch 5 - Addresses the issue of xhci hang while resuming from system sleep. George Cherian (5): usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function usb: dwc3: dwc3-omap: Add dwc3_omap_set_utmi_mode() function usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function usb: dwc3: dwc3-omap: Fix the crash on module removal usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume drivers/usb/dwc3/dwc3-omap.c | 211 +++ 1 file changed, 111 insertions(+), 100 deletions(-) -- 1.8.3.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] usb: dwc3: dwc3-omap: Fix the crash on module removal
Following crash is seen on dwc3_omap removal
Unable to handle kernel NULL pointer dereference at virtual address 0018
pgd = ec098000
[0018] *pgd=ad1f9831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm u_ether
libcomposite configfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hwdep
snd_soc_omap snd_pcm_dmaengine snd_soc_core snd_compress snd_pcm snd_tim]
CPU: 0 PID: 1296 Comm: rmmod Tainted: GW
3.15.0-rc4-02716-g95c4e18-dirty #10
task: ed05a080 ti: ec368000 task.ti: ec368000
PC is at release_resource+0x14/0x7c
LR is at release_resource+0x10/0x7c
pc : [c0044724]lr : [c0044720]psr: 6013
sp : ec369ec0 ip : 6013 fp : 00021008
r10: r9 : ec368000 r8 : c000e7a4
r7 : 0081 r6 : bf0062c0 r5 : ed7cd000 r4 : ed7d85c0
r3 : r2 : r1 : 0011 r0 : c086d08c
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: ac098059 DAC: 0015
Process rmmod (pid: 1296, stack limit = 0xec368248)
Stack: (0xec369ec0 to 0xec36a000)
9ec0: 0001 ed7cd000 c034de94 ed7cd010 ed7cd000 c034e194
9ee0: bf0062cc ed7cd010 c03490b0 ed154cc0 ed4c2570 ed2b8410 ed156810
ed156810 bf006d24 c034db9c c034db84 c034c518
9f20: bf006d24 ed156810 bf006d24 c034cd2c bf006d24 bf006d68 0800 c034c340
9f40: c00a9e5c 0020 bf006d68 0800 ec369f4c 33637764
9f60: 616d6f5f 0070 0001 ec368000 ed05a080 c000e670 0001 c0084010
9f80: 00021088 0800 00021088 0081 8010 e6f4 00021088 0800
9fa0: 00021088 c000e5e0 00021088 0800 000210b8 0800 e04f6d00 e04f6d00
9fc0: 00021088 0800 00021088 0081 0001 be91de08 00021008
9fe0: 4d768880 be91dbb4 b6fc5984 4d76888c 8010 000210b8
[c0044724] (release_resource) from [c034de94]
(platform_device_del+0x6c/0x9c)
[c034de94] (platform_device_del) from [c034e194]
(platform_device_unregister+0xc/0x18)
[c034e194] (platform_device_unregister) from [bf0062cc]
(dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
[bf0062cc] (dwc3_omap_remove_core [dwc3_omap]) from [c03490b0]
(device_for_each_child+0x34/0x74)
[c03490b0] (device_for_each_child) from [bf0062b4]
(dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
[bf0062b4] (dwc3_omap_remove [dwc3_omap]) from [c034db9c]
(platform_drv_remove+0x18/0x1c)
[c034db9c] (platform_drv_remove) from [c034c518]
(__device_release_driver+0x70/0xc8)
[c034c518] (__device_release_driver) from [c034cd2c]
(driver_detach+0xb4/0xb8)
[c034cd2c] (driver_detach) from [c034c340] (bus_remove_driver+0x4c/0x90)
[c034c340] (bus_remove_driver) from [c00a9e5c]
(SyS_delete_module+0x10c/0x198)
[c00a9e5c] (SyS_delete_module) from [c000e5e0] (ret_fast_syscall+0x0/0x48)
Code: e1a04000 e59f0068 eb14505e e5943010 (e5932018)
---[ end trace 7e2a8746ff4fc811 ]---
Segmentation fault
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 0b9b1d8..82b20d8f 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -322,7 +322,7 @@ static int dwc3_omap_remove_core(struct device *dev, void
*c)
{
struct platform_device *pdev = to_platform_device(dev);
- platform_device_unregister(pdev);
+ of_device_unregister(pdev);
return 0;
}
--
1.8.3.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 2/5] usb: dwc3: dwc3-omap: Add dwc3_omap_set_utmi_mode() function
Move find and set the utmi mode to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 872f065..b739a24 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -426,6 +426,30 @@ static void dwc3_omap_map_offset(struct dwc3_omap *omap)
}
}
+static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
+{
+ u32 reg;
+ struct device_node *node = omap-dev-of_node;
+ int utmi_mode = 0;
+
+ reg = dwc3_omap_read_utmi_status(omap);
+
+ of_property_read_u32(node, utmi-mode, utmi_mode);
+
+ switch (utmi_mode) {
+ case DWC3_OMAP_UTMI_MODE_SW:
+ reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+ break;
+ case DWC3_OMAP_UTMI_MODE_HW:
+ reg = ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+ break;
+ default:
+ dev_dbg(omap-dev, UNKNOWN utmi mode %d\n, utmi_mode);
+ }
+
+ dwc3_omap_write_utmi_status(omap, reg);
+}
+
static int dwc3_omap_probe(struct platform_device *pdev)
{
struct device_node *node = pdev-dev.of_node;
@@ -439,8 +463,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int ret = -ENOMEM;
int irq;
- int utmi_mode = 0;
-
u32 reg;
void __iomem*base;
@@ -491,23 +513,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
}
dwc3_omap_map_offset(omap);
-
- reg = dwc3_omap_read_utmi_status(omap);
-
- of_property_read_u32(node, utmi-mode, utmi_mode);
-
- switch (utmi_mode) {
- case DWC3_OMAP_UTMI_MODE_SW:
- reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
- break;
- case DWC3_OMAP_UTMI_MODE_HW:
- reg = ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
- break;
- default:
- dev_dbg(dev, UNKNOWN utmi mode %d\n, utmi_mode);
- }
-
- dwc3_omap_write_utmi_status(omap, reg);
+ dwc3_omap_set_utmi_mode(omap);
/* check the DMA Status */
reg = dwc3_omap_readl(omap-base, USBOTGSS_SYSCONFIG);
--
1.8.3.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] usb: dwc3: dwc3-omap: Disable/Enable core interrupts in Suspend/Resume
Enabling the core interrupts in complete is too late for XHCI, and stops
xhci from proper operation. So remove prepare and complete and disable/enable
interrupts in suspend/resume
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 82b20d8f..0916c4b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -622,27 +622,12 @@ static const struct of_device_id of_dwc3_match[] = {
MODULE_DEVICE_TABLE(of, of_dwc3_match);
#ifdef CONFIG_PM_SLEEP
-static int dwc3_omap_prepare(struct device *dev)
-{
- struct dwc3_omap*omap = dev_get_drvdata(dev);
-
- dwc3_omap_disable_irqs(omap);
-
- return 0;
-}
-
-static void dwc3_omap_complete(struct device *dev)
-{
- struct dwc3_omap*omap = dev_get_drvdata(dev);
-
- dwc3_omap_enable_irqs(omap);
-}
-
static int dwc3_omap_suspend(struct device *dev)
{
struct dwc3_omap*omap = dev_get_drvdata(dev);
omap-utmi_otg_status = dwc3_omap_read_utmi_status(omap);
+ dwc3_omap_disable_irqs(omap);
return 0;
}
@@ -652,6 +637,7 @@ static int dwc3_omap_resume(struct device *dev)
struct dwc3_omap*omap = dev_get_drvdata(dev);
dwc3_omap_write_utmi_status(omap, omap-utmi_otg_status);
+ dwc3_omap_enable_irqs(omap);
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
@@ -661,8 +647,6 @@ static int dwc3_omap_resume(struct device *dev)
}
static const struct dev_pm_ops dwc3_omap_dev_pm_ops = {
- .prepare= dwc3_omap_prepare,
- .complete = dwc3_omap_complete,
SET_SYSTEM_SLEEP_PM_OPS(dwc3_omap_suspend, dwc3_omap_resume)
};
--
1.8.3.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 3/5] usb: dwc3: dwc3-omap: Add dwc3_omap_extcon_register function
Move the extcon related code to its own function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 65 ++--
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b739a24..0b9b1d8 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -450,6 +450,42 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
dwc3_omap_write_utmi_status(omap, reg);
}
+static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
+{
+ u32 ret;
+ struct device_node *node = omap-dev-of_node;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(node, extcon)) {
+ edev = extcon_get_edev_by_phandle(omap-dev, 0);
+ if (IS_ERR(edev)) {
+ dev_vdbg(omap-dev, couldn't get extcon device\n);
+ return -EPROBE_DEFER;
+ }
+
+ omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
+ ret = extcon_register_interest(omap-extcon_vbus_dev,
+ edev-name, USB,
+ omap-vbus_nb);
+ if (ret 0)
+ dev_vdbg(omap-dev, failed to register notifier for
USB\n);
+
+ omap-id_nb.notifier_call = dwc3_omap_id_notifier;
+ ret = extcon_register_interest(omap-extcon_id_dev,
+ edev-name, USB-HOST,
+ omap-id_nb);
+ if (ret 0)
+ dev_vdbg(omap-dev, failed to register notifier for
USB-HOST\n);
+
+ if (extcon_get_cable_state(edev, USB) == true)
+ dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
+ if (extcon_get_cable_state(edev, USB-HOST) == true)
+ dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+ }
+
+ return 0;
+}
+
static int dwc3_omap_probe(struct platform_device *pdev)
{
struct device_node *node = pdev-dev.of_node;
@@ -457,7 +493,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = pdev-dev;
- struct extcon_dev *edev;
struct regulator*vbus_reg = NULL;
int ret = -ENOMEM;
@@ -529,31 +564,9 @@ static int dwc3_omap_probe(struct platform_device *pdev)
dwc3_omap_enable_irqs(omap);
- if (of_property_read_bool(node, extcon)) {
- edev = extcon_get_edev_by_phandle(dev, 0);
- if (IS_ERR(edev)) {
- dev_vdbg(dev, couldn't get extcon device\n);
- ret = -EPROBE_DEFER;
- goto err2;
- }
-
- omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
- ret = extcon_register_interest(omap-extcon_vbus_dev,
- edev-name, USB, omap-vbus_nb);
- if (ret 0)
- dev_vdbg(dev, failed to register notifier for USB\n);
- omap-id_nb.notifier_call = dwc3_omap_id_notifier;
- ret = extcon_register_interest(omap-extcon_id_dev, edev-name,
-USB-HOST, omap-id_nb);
- if (ret 0)
- dev_vdbg(dev,
- failed to register notifier for USB-HOST\n);
-
- if (extcon_get_cable_state(edev, USB) == true)
- dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state(edev, USB-HOST) == true)
- dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
- }
+ ret = dwc3_omap_extcon_register(omap);
+ if (ret 0)
+ goto err2;
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
--
1.8.3.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] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function
Calculate the wrapper register offsets in a seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 80
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1160ff4..872f065 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -383,6 +383,49 @@ static int dwc3_omap_vbus_notifier(struct notifier_block
*nb,
return NOTIFY_DONE;
}
+static void dwc3_omap_map_offset(struct dwc3_omap *omap)
+{
+ u32 reg;
+ struct device_node *node = omap-dev-of_node;
+ int x_major;
+
+ reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
+ omap-revision = reg;
+ x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+ /* Differentiate between OMAP5 and AM437x */
+ switch (x_major) {
+ case USBOTGSS_REVISION_XMAJOR1:
+ case USBOTGSS_REVISION_XMAJOR2:
+ omap-irq_eoi_offset = 0;
+ omap-irq0_offset = 0;
+ omap-irqmisc_offset = 0;
+ omap-utmi_otg_offset = 0;
+ omap-debug_offset = 0;
+ break;
+ default:
+ /* Default to the latest revision */
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ break;
+ }
+
+ /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+ if (of_device_is_compatible(node, ti,am437x-dwc3)) {
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ }
+}
+
static int dwc3_omap_probe(struct platform_device *pdev)
{
struct device_node *node = pdev-dev.of_node;
@@ -397,7 +440,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int irq;
int utmi_mode = 0;
- int x_major;
u32 reg;
@@ -448,41 +490,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
goto err0;
}
- reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
- omap-revision = reg;
- x_major = USBOTGSS_REVISION_XMAJOR(reg);
-
- /* Differentiate between OMAP5 and AM437x */
- switch (x_major) {
- case USBOTGSS_REVISION_XMAJOR1:
- case USBOTGSS_REVISION_XMAJOR2:
- omap-irq_eoi_offset = 0;
- omap-irq0_offset = 0;
- omap-irqmisc_offset = 0;
- omap-utmi_otg_offset = 0;
- omap-debug_offset = 0;
- break;
- default:
- /* Default to the latest revision */
- omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
- omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
- omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
- omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
- omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
- break;
- }
-
- /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
-* changes in wrapper registers, Using dt compatible for aegis
-*/
-
- if (of_device_is_compatible(node, ti,am437x-dwc3)) {
- omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
- omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
- omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
- omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
- omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
- }
+ dwc3_omap_map_offset(omap);
reg = dwc3_omap_read_utmi_status(omap);
--
1.8.3.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 v2 1/5] usb: musb: core: Convert babble recover work to delayed work
During babble condition first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.
To acheive this schedule a delayed work for babble rrecovery.
While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 15 ---
drivers/usb/musb/musb_core.h | 2 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..dcadc62 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
/* handle babble condition */
if (int_usb MUSB_INTR_BABBLE)
- schedule_work(musb-recover_work);
+ schedule_delayed_work(musb-recover_work,
+ msecs_to_jiffies(100));
#if 0
/* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1753,16 +1754,16 @@ static void musb_irq_work(struct work_struct *data)
/* Recover from babble interrupt conditions */
static void musb_recover_work(struct work_struct *data)
{
- struct musb *musb = container_of(data, struct musb, recover_work);
+ struct musb *musb = container_of(data, struct musb, recover_work.work);
int status;
musb_platform_reset(musb);
usb_phy_vbus_off(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
usb_phy_vbus_on(musb-xceiv);
- udelay(100);
+ usleep_range(100, 200);
/*
* When a babble condition occurs, the musb controller removes the
@@ -1945,7 +1946,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
- INIT_WORK(musb-recover_work, musb_recover_work);
+ INIT_DELAYED_WORK(musb-recover_work, musb_recover_work);
INIT_DELAYED_WORK(musb-deassert_reset_work, musb_deassert_reset);
INIT_DELAYED_WORK(musb-finish_resume_work, musb_host_finish_resume);
@@ -2041,7 +2042,7 @@ fail4:
fail3:
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
if (musb-dma_controller)
@@ -2107,7 +2108,7 @@ static int musb_remove(struct platform_device *pdev)
dma_controller_destroy(musb-dma_controller);
cancel_work_sync(musb-irq_work);
- cancel_work_sync(musb-recover_work);
+ cancel_delayed_work_sync(musb-recover_work);
cancel_delayed_work_sync(musb-finish_resume_work);
cancel_delayed_work_sync(musb-deassert_reset_work);
musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 47e8874..423cd00 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
- struct work_struct recover_work;
+ struct delayed_work recover_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
u16 hwvers;
--
1.8.3.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 v2 4/5] usb: musb: dsps: Add the sw_babble_control()
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 50
drivers/usb/musb/musb_regs.h | 7 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 8438200..6647e7e 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static int sw_babble_control(struct musb *musb)
+{
+ int timeout = 10;
+ u8 babble_ctl, session_restart = 0;
+
+ babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ dev_dbg(musb-controller, babble: MUSB_BABBLE_CTL value %x\n,
+ babble_ctl);
+ /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+ dev_dbg(musb-controller, STUCK_J is %s\n,
+ babble_ctl MUSB_BABBLE_STUCK_J ? set : reset);
+
+ if (babble_ctl MUSB_BABBLE_STUCK_J) {
+ /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+ babble_ctl = musb_readb(musb-mregs, MUSB_BABBLE_CTL);
+ babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+ /* wait till line monitor flag cleared */
+ dev_dbg(musb-controller, Set TXIDLE, wait J to clear\n);
+ do {
+ babble_ctl = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ udelay(1);
+ } while ((babble_ctl MUSB_BABBLE_STUCK_J) timeout--);
+
+ /* check whether stuck_at_j bit cleared */
+ if (babble_ctl MUSB_BABBLE_STUCK_J) {
+ /*
+* real babble condition is occured
+* restart the controller to start the
+* session again
+*/
+ dev_dbg(musb-controller, J not cleared, misc (%x)\n,
+ babble_ctl);
+ session_restart = 1;
+ }
+
+ } else {
+ session_restart = 1;
+ }
+
+ return session_restart;
+}
+
static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 03f2655..b9bcda5 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -72,6 +72,12 @@
#define MUSB_DEVCTL_HR 0x02
#define MUSB_DEVCTL_SESSION0x01
+/* BABBLE_CTL */
+#define MUSB_BABBLE_FORCE_TXIDLE 0x80
+#define MUSB_BABBLE_SW_SESSION_CTRL0x40
+#define MUSB_BABBLE_STUCK_J0x20
+#define MUSB_BABBLE_RCV_DISABLE0x04
+
/* MUSB ULPI VBUSCONTROL */
#define MUSB_ULPI_USE_EXTVBUS 0x01
#define MUSB_ULPI_USE_EXTVBUSIND 0x02
@@ -246,6 +252,7 @@
*/
#define MUSB_DEVCTL0x60/* 8 bit */
+#define MUSB_BABBLE_CTL0x61/* 8 bit */
/* These are always controlled through the INDEX register */
#define MUSB_TXFIFOSZ 0x62/* 8-bit (see masks) */
--
1.8.3.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 v2 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.
Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for musb_platform_reset().
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_core.c | 38 +-
drivers/usb/musb/musb_core.h | 10 ++
drivers/usb/musb/musb_dsps.c | 3 ++-
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index dcadc62..983a591 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1755,28 +1755,32 @@ static void musb_irq_work(struct work_struct *data)
static void musb_recover_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, recover_work.work);
- int status;
+ int status, reset_done;
- musb_platform_reset(musb);
+ reset_done = musb_platform_reset(musb);
+ if (reset_done 0)
+ return;
- usb_phy_vbus_off(musb-xceiv);
- usleep_range(100, 200);
+ if (reset_done) {
+ usb_phy_vbus_off(musb-xceiv);
+ usleep_range(100, 200);
- usb_phy_vbus_on(musb-xceiv);
- usleep_range(100, 200);
+ usb_phy_vbus_on(musb-xceiv);
+ usleep_range(100, 200);
- /*
-* When a babble condition occurs, the musb controller removes the
-* session bit and the endpoint config is lost.
-*/
- if (musb-dyn_fifo)
- status = ep_config_from_table(musb);
- else
- status = ep_config_from_hw(musb);
+ /*
+* When a babble condition occurs, the musb controller removes
the
+* session bit and the endpoint config is lost.
+*/
+ if (musb-dyn_fifo)
+ status = ep_config_from_table(musb);
+ else
+ status = ep_config_from_hw(musb);
- /* start the session again */
- if (status == 0)
- musb_start(musb);
+ /* start the session again */
+ if (status == 0)
+ musb_start(musb);
+ }
}
/* --
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 423cd00..3ccb428 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
int (*set_mode)(struct musb *musb, u8 mode);
void(*try_idle)(struct musb *musb, unsigned long timeout);
- void(*reset)(struct musb *musb);
+ int (*reset)(struct musb *musb);
int (*vbus_status)(struct musb *musb);
void(*set_vbus)(struct musb *musb, int on);
@@ -554,10 +554,12 @@ static inline void musb_platform_try_idle(struct musb
*musb,
musb-ops-try_idle(musb, timeout);
}
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb-ops-reset)
- musb-ops-reset(musb);
+ if (!musb-ops-reset)
+ return -EINVAL;
+
+ return musb-ops-reset(musb);
}
static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..8438200 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ return 1;
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v2 5/5] usb: musb: dsps: Enable sw babble control for newer silicon
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 6647e7e..665d1dd 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+ bool sw_babble_enabled;
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -469,6 +470,16 @@ static int dsps_musb_init(struct musb *musb)
val = ~(1 wrp-otg_disable);
dsps_writel(musb-ctrl_base, wrp-phy_utmi, val);
+ /*
+* Check whether the dsps version has babble control enabled.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+ val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
+ if (val == MUSB_BABBLE_RCV_DISABLE)
+ glue-sw_babble_enabled = true;
+
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
return ret;
@@ -591,14 +602,25 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
+ int session_restart = 0;
- dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- usleep_range(100, 200);
- usb_phy_shutdown(musb-xceiv);
- usleep_range(100, 200);
- usb_phy_init(musb-xceiv);
+ if (glue-sw_babble_enabled)
+ session_restart = sw_babble_control(musb);
+ /*
+* In case of new silicon version babble condition can be recovered
+* without resetting the MUSB. But for older silicon versions, MUSB
+* reset is needed
+*/
+ if (session_restart || !glue-sw_babble_enabled) {
+ dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
+ usleep_range(100, 200);
+ usb_phy_shutdown(musb-xceiv);
+ usleep_range(100, 200);
+ usb_phy_init(musb-xceiv);
+ session_restart = 1;
+ }
- return 1;
+ return session_restart;
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v2 2/5] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()
For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/musb/musb_dsps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue-wrp;
dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
- udelay(100);
+ usleep_range(100, 200);
+ usb_phy_shutdown(musb-xceiv);
+ usleep_range(100, 200);
+ usb_phy_init(musb-xceiv);
+
}
static struct musb_platform_ops dsps_ops = {
--
1.8.3.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 v2 0/5] Add support for SW babble Control
Series add support for SW babble control logic found in new silicon versions of AM335x. Runtime differentiation of silicon version is done by checking the BABBLE_CTL register. For newer silicon the register default value read is 0x4 and for older versions its 0x0. Patch 1 - Convert recover work to delayed work. Patch 2 - usb_phy_vbus_(off/_on) are NOPs for am335x PHY so use usb_phy(_shutdown/_init) in musb_platform_reset() Patch 3 - Add return value for musb_platform_reset() in prepration to support SW babble_ctrl Patch 4 - Add the sw_babble_control() Patch 5 - Enable sw babble control for newer silicon v1 - v2 : Fixed the issue with Patch 5. In v1 it was not calling sw_babble_control(). George Cherian (5): usb: musb: core: Convert babble recover work to delayed work usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: musb: core: Convert the musb_platform_reset to have a return value. usb: musb: dsps: Add the sw_babble_control() usb: musb: dsps: Enable sw babble control for newer silicon drivers/usb/musb/musb_core.c | 49 + drivers/usb/musb/musb_core.h | 12 --- drivers/usb/musb/musb_dsps.c | 85 ++-- drivers/usb/musb/musb_regs.h | 7 4 files changed, 124 insertions(+), 29 deletions(-) -- 1.8.3.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: [PATCH v2 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.
Hi Geroge,
On 05/08/2014 11:35 AM, George Cherian wrote:
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb-ops-reset)
- musb-ops-reset(musb);
+ if (!musb-ops-reset)
+ return -EINVAL;
+
+ return musb-ops-reset(musb);
}
static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..8438200 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ return 1;
Could we follow the general kernel rule here and return 0 for success,
and 0 on failure?
Thanks,
Daniel
--
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 1/2] ARM: omap5: hwmod_data: Update McPDM hwmod's flags
Hi Paul, On 05/08/2014 03:20 AM, Paul Walmsley wrote: Hi Péter, On Wed, 30 Apr 2014, Peter Ujfalusi wrote: Add HWMOD_SWSUP_SIDLE to flags. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This patch could use a better changelog. It would be ideal to understand _why_ HWMOD_SWSUP_SIDLE is needed. Is there a known hardware bug? Or is this simply based on practical observation, e.g., something bad happens if the McPDM is not software-idled? The same issue exists on OMAP5 as on OMAP4: commit 12d82e4b0aa6c71f38b668a372f9a13f243207da Author: Peter Ujfalusi peter.ujfal...@ti.com Date: Fri Jan 18 16:48:16 2013 -0700 ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com [p...@pwsan.com: copy patch description into hwmod data comments] Signed-off-by: Paul Walmsley p...@pwsan.com diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- Péter -- 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 v2 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.
On 5/8/2014 3:17 PM, Daniel Mack wrote:
Hi Geroge,
On 05/08/2014 11:35 AM, George Cherian wrote:
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb-ops-reset)
- musb-ops-reset(musb);
+ if (!musb-ops-reset)
+ return -EINVAL;
+
+ return musb-ops-reset(musb);
}
static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..8438200 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
{
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ return 1;
Could we follow the general kernel rule here and return 0 for success,
and 0 on failure?
I made this to return 1, just because the next patch in the series would
make it
return session_restart. Depending on which the musb_platform_reset()
would return
whether actual reset of IP (reset_done) is done or not .
Thanks,
Daniel
--
-George
--
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 0/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
On 21/04/14 13:41, Laurent Pinchart wrote: Hello, This patch set enables rate propagation from the OMAP3 ISP functional clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set for the OMAP DSS functional clock from the OMAP: OMAP3 DSS related clock patches patch series. Laurent Pinchart (2): ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) These look fine to me. Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
On Thursday 08 May 2014 02:56 PM, Javier Martinez Canillas wrote:
Hello Rajendra,
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote:
On Wednesday 23 April 2014 11:41 AM, Rajendra Nayak wrote:
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Linus,
Do you mind picking this fix up via the GPIO tree? Alternatively you could
Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from
this
series via the OMAP tree.
Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that order
else
gpio would break. More discussions are here [1].
Let us know what you think. Thanks.
I wonder if that is really the case. Your Patch 2/2 removes the call
to clk_prepare on _init_opt_clks() but it also replaces
clk_{enable,disable} with clk_prepare_enable()/clk_disable_unprepare()
on _enable_optional_clocks() and _disable_optional_clocks()
respectively.
Right, the difference being, by the time hwmod is done enabling/disabling
the opt clocks, without patch 2/2, the prepare count is 1, with patch 2/2
prepare count is 0.
And GPIO banks are reset by hwmod on init which as far as I know
happen very early before the GPIO OMAP driver is even probed so by the
time clk_enable() is called on the GPIO driver the clock will already
be prepared by _enable_optional_clocks(). I tested linux-gpio/devel
and unprepared by _disable_optional_clocks()?
branch + only your Patch 2/2 and the GPIOs were working correctly on a
OMAP3 board.
Did gpio_debounce() ever get called for any of the gpios?
So I think that there isn't a strict dependency between these two
patches or am I missing something?
In fact now that I think about it I wonder what's the functional
change of your Patch 2/2 since hwmod is still calling clk_prepare()
before the driver. If the clocks should actually be controlled by the
I don't understand why you say 'before the driver'. Hwmod needs to control
optional clocks for some devices in order to do a ocp reset. So it does
touch these optional clocks, but if you look at the code it subsequently
also disables (and unprepares with patch 2/2) these clocks before returning
the control to the driver.
drivers like you said then I think that we should remove
_{enable,disable}_optional_clocks() completely and let the drivers do
the clock prepare and enable like is made on your Patch 1/2 for the
GPIO driver.
What do you think about it?
Best regards,
Javier
regards,
Rajendra
[1] http://www.mail-archive.com/linux-gpio@vger.kernel.org/msg02801.html
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32
reg, u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
writel_relaxed(debounce, reg);
@@ -245,7 +245,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
bank-dbck_enable_mask = val;
writel_relaxed(val, reg);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
/*
* Enable debounce clock per module.
* This call is mandatory because in omap_gpio_request() when
@@ -290,7 +290,7 @@ static void _clear_gpio_debounce(struct gpio_bank
*bank, unsigned gpio)
bank-context.debounce = 0;
writel_relaxed(bank-context.debounce, bank-base +
bank-regs-debounce);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
--
To
Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
Hello Rajendra,
On Thu, May 8, 2014 at 1:10 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 08 May 2014 02:56 PM, Javier Martinez Canillas wrote:
Hello Rajendra,
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote:
On Wednesday 23 April 2014 11:41 AM, Rajendra Nayak wrote:
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Linus,
Do you mind picking this fix up via the GPIO tree? Alternatively you could
Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from
this
series via the OMAP tree.
Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that
order else
gpio would break. More discussions are here [1].
Let us know what you think. Thanks.
I wonder if that is really the case. Your Patch 2/2 removes the call
to clk_prepare on _init_opt_clks() but it also replaces
clk_{enable,disable} with clk_prepare_enable()/clk_disable_unprepare()
on _enable_optional_clocks() and _disable_optional_clocks()
respectively.
Right, the difference being, by the time hwmod is done enabling/disabling
the opt clocks, without patch 2/2, the prepare count is 1, with patch 2/2
prepare count is 0.
Ok, got it now.
And GPIO banks are reset by hwmod on init which as far as I know
happen very early before the GPIO OMAP driver is even probed so by the
time clk_enable() is called on the GPIO driver the clock will already
be prepared by _enable_optional_clocks(). I tested linux-gpio/devel
and unprepared by _disable_optional_clocks()?
I see that _disable_optional_clocks() is called as well so the clock
is left unprepared as you said.
branch + only your Patch 2/2 and the GPIOs were working correctly on a
OMAP3 board.
Did gpio_debounce() ever get called for any of the gpios?
I don't see gpio_debounce() to be called indeed.
omap_gpio_runtime_resume() is executed and calls
_gpio_dbck_enable(bank) but clk_enable(bank-dbck) is not called since
bank-dbck_enable_mask is 0, that was my confusion since I thought
that clk_enable() was called.
Now I understand the dependency between the two patches.
So I think that there isn't a strict dependency between these two
patches or am I missing something?
In fact now that I think about it I wonder what's the functional
change of your Patch 2/2 since hwmod is still calling clk_prepare()
before the driver. If the clocks should actually be controlled by the
I don't understand why you say 'before the driver'. Hwmod needs to control
optional clocks for some devices in order to do a ocp reset. So it does
touch these optional clocks, but if you look at the code it subsequently
also disables (and unprepares with patch 2/2) these clocks before returning
the control to the driver.
Right, it was just me getting confused by the interaction between
hwmod and the GPIO driver. Thanks a lot for the explanation and sorry
for the noise.
Feel free to add my:
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
Best regards,
Javier
drivers like you said then I think that we should remove
_{enable,disable}_optional_clocks() completely and let the drivers do
the clock prepare and enable like is made on your Patch 1/2 for the
GPIO driver.
What do you think about it?
Best regards,
Javier
regards,
Rajendra
[1] http://www.mail-archive.com/linux-gpio@vger.kernel.org/msg02801.html
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32
reg, u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank
*bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
l = GPIO_BIT(bank, gpio);
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
Re: [PATCH 1/2] gpio: omap: prepare and unprepare the debounce clock
On Thursday 08 May 2014 05:34 PM, Javier Martinez Canillas wrote:
Hello Rajendra,
On Thu, May 8, 2014 at 1:10 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 08 May 2014 02:56 PM, Javier Martinez Canillas wrote:
Hello Rajendra,
On Thu, May 8, 2014 at 9:06 AM, Rajendra Nayak rna...@ti.com wrote:
On Wednesday 23 April 2014 11:41 AM, Rajendra Nayak wrote:
Replace the clk_enable()s with a clk_prepare_enable() and
the clk_disables()s with a clk_disable_unprepare()
This never showed issues due to the OMAP platform code (hwmod)
leaving these clocks in clk_prepare()ed state by default.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux-g...@vger.kernel.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Linus,
Do you mind picking this fix up via the GPIO tree? Alternatively you could
Ack this if you are fine and we can take both Patch 1/2 and Patch 2/2 from
this
series via the OMAP tree.
Patch 2/2 has a dependency on Patch 1/2 and they need to go in in that
order else
gpio would break. More discussions are here [1].
Let us know what you think. Thanks.
I wonder if that is really the case. Your Patch 2/2 removes the call
to clk_prepare on _init_opt_clks() but it also replaces
clk_{enable,disable} with clk_prepare_enable()/clk_disable_unprepare()
on _enable_optional_clocks() and _disable_optional_clocks()
respectively.
Right, the difference being, by the time hwmod is done enabling/disabling
the opt clocks, without patch 2/2, the prepare count is 1, with patch 2/2
prepare count is 0.
Ok, got it now.
And GPIO banks are reset by hwmod on init which as far as I know
happen very early before the GPIO OMAP driver is even probed so by the
time clk_enable() is called on the GPIO driver the clock will already
be prepared by _enable_optional_clocks(). I tested linux-gpio/devel
and unprepared by _disable_optional_clocks()?
I see that _disable_optional_clocks() is called as well so the clock
is left unprepared as you said.
branch + only your Patch 2/2 and the GPIOs were working correctly on a
OMAP3 board.
Did gpio_debounce() ever get called for any of the gpios?
I don't see gpio_debounce() to be called indeed.
omap_gpio_runtime_resume() is executed and calls
_gpio_dbck_enable(bank) but clk_enable(bank-dbck) is not called since
bank-dbck_enable_mask is 0, that was my confusion since I thought
that clk_enable() was called.
Now I understand the dependency between the two patches.
So I think that there isn't a strict dependency between these two
patches or am I missing something?
In fact now that I think about it I wonder what's the functional
change of your Patch 2/2 since hwmod is still calling clk_prepare()
before the driver. If the clocks should actually be controlled by the
I don't understand why you say 'before the driver'. Hwmod needs to control
optional clocks for some devices in order to do a ocp reset. So it does
touch these optional clocks, but if you look at the code it subsequently
also disables (and unprepares with patch 2/2) these clocks before returning
the control to the driver.
Right, it was just me getting confused by the interaction between
hwmod and the GPIO driver. Thanks a lot for the explanation and sorry
for the noise.
No issues, thanks for the review and ack.
Feel free to add my:
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
Best regards,
Javier
drivers like you said then I think that we should remove
_{enable,disable}_optional_clocks() completely and let the drivers do
the clock prepare and enable like is made on your Patch 1/2 for the
GPIO driver.
What do you think about it?
Best regards,
Javier
regards,
Rajendra
[1] http://www.mail-archive.com/linux-gpio@vger.kernel.org/msg02801.html
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 19b886c..78bc5a4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -180,7 +180,7 @@ static inline void _gpio_rmw(void __iomem *base, u32
reg, u32 mask, bool set)
static inline void _gpio_dbck_enable(struct gpio_bank *bank)
{
if (bank-dbck_enable_mask !bank-dbck_enabled) {
- clk_enable(bank-dbck);
+ clk_prepare_enable(bank-dbck);
bank-dbck_enabled = true;
writel_relaxed(bank-dbck_enable_mask,
@@ -198,7 +198,7 @@ static inline void _gpio_dbck_disable(struct
gpio_bank *bank)
*/
writel_relaxed(0, bank-base + bank-regs-debounce_en);
- clk_disable(bank-dbck);
+ clk_disable_unprepare(bank-dbck);
bank-dbck_enabled = false;
}
}
@@ -231,7 +231,7 @@ static void _set_gpio_debounce(struct gpio_bank
*bank, unsigned gpio,
l = GPIO_BIT(bank,
omap4-panda-es boot issues with v3.15-rc4
Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. cheers, -roger -- 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/8] usb: phy: fix isp1301-omap dependency on tps65010
The isp1301-omap driver cannot be built-in if the tps65010 driver
is a module, otherwise we get a link error from the reference to
the tps65010_set_vbus_draw function.
There is already a hack in the driver to work around the problem
of tps65010 being not available at all. This patch extends that
hack to ensure that the real tps65010_set_vbus_draw() function
is only called when it's avaiable.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-omap@vger.kernel.org
---
drivers/usb/phy/phy-isp1301-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d7..35a0dd2 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -94,7 +94,7 @@ struct isp1301 {
#if defined(CONFIG_MACH_OMAP_H2) || defined(CONFIG_MACH_OMAP_H3)
-#ifdefined(CONFIG_TPS65010) || defined(CONFIG_TPS65010_MODULE)
+#ifdefined(CONFIG_TPS65010) || (defined(CONFIG_TPS65010_MODULE)
defined(MODULE))
#include linux/i2c/tps65010.h
--
1.8.3.2
--
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/8] usb: musb: tusb-dma can't be built-in if tusb is not
A configuration with CONFIG_USB_MUSB_HDRC=y, CONFIG_USB_TUSB_OMAP_DMA=y and CONFIG_USB_MUSB_TUSB6010=m causes a link failure because of the dependency on the tusb_get_revision symbol: (.text+0x154ce8): undefined reference to `tusb_get_revision' This patch ensures that either MUSB_HDRC and MUSB_TUSB6010 are both modules or both built-in, which are the valid configurations. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org --- drivers/usb/musb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 8b78979..618b152 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -144,7 +144,7 @@ config USB_TI_CPPI41_DMA config USB_TUSB_OMAP_DMA bool 'TUSB 6010' - depends on USB_MUSB_TUSB6010 + depends on USB_MUSB_TUSB6010 = USB_MUSB_HDRC # both built-in or both modules depends on ARCH_OMAP help Enable DMA transfers on TUSB 6010 when OMAP DMA is available. -- 1.8.3.2 -- 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/8] usb: musb: omap2plus bus glue needs USB host support
The musb/omap2430.c bus glue driver calls usb_hcd_poll_rh_status, which is only available if CONFIG_USB is also set, i.e. we are building USB host mode and not just endpoint mode. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org --- drivers/usb/musb/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 618b152..fce762c 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -76,7 +76,7 @@ config USB_MUSB_TUSB6010 config USB_MUSB_OMAP2PLUS tristate OMAP2430 and onwards - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS USB select GENERIC_PHY config USB_MUSB_AM35X -- 1.8.3.2 -- 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 7/8] usb: ohci: sort out dependencies for lpc32xx and omap
The dependency on the isp1301 driver is not something that should be in the main OHCI driver but rather the SoC specific part of it. This moves the dependency for LPC32xx into USB_OHCI_HCD_LPC32XX, and changes the 'select ISP1301_OMAP' to a similar 'depends on'. Since the same dependency exists for the client driver, do the same change there. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org Cc: Alan Stern st...@rowland.harvard.edu --- drivers/usb/gadget/Kconfig | 4 ++-- drivers/usb/host/Kconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 7fca52b..ba18e9c 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -157,7 +157,7 @@ config USB_AT91 config USB_LPC32XX tristate LPC32XX USB Peripheral Controller - depends on ARCH_LPC32XX + depends on ARCH_LPC32XX I2C select USB_ISP1301 help This option selects the USB device controller in the LPC32xx SoC. @@ -226,7 +226,7 @@ config USB_GR_UDC config USB_OMAP tristate OMAP USB Device Controller depends on ARCH_OMAP1 - select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 + depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) help Many Texas Instruments OMAP processors have flexible full speed USB device controllers, with support for up to 30 diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 890fc8c..e229a47 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -345,8 +345,6 @@ config USB_FOTG210_HCD config USB_OHCI_HCD tristate OHCI HCD (USB 1.1) support - select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 - depends on USB_ISP1301 || !ARCH_LPC32XX ---help--- The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's @@ -365,6 +363,7 @@ if USB_OHCI_HCD config USB_OHCI_HCD_OMAP1 tristate OHCI support for OMAP1/2 chips depends on ARCH_OMAP1 + depends on ISP1301_OMAP || !(MACH_OMAP_H2 || MACH_OMAP_H3) default y ---help--- Enables support for the OHCI controller on OMAP1/2 chips. @@ -388,6 +387,7 @@ config USB_OHCI_HCD_S3C2410 config USB_OHCI_HCD_LPC32XX tristate Support for LPC on-chip OHCI USB controller depends on USB_OHCI_HCD ARCH_LPC32XX + depends on USB_ISP1301 default y ---help--- Enables support for the on-chip OHCI controller on -- 1.8.3.2 -- 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: [RESEND PATCH 0/4] ARM: OMAP: raw read and write endian fix
* Taras Kondratiuk taras.kondrat...@linaro.org [140415 10:38]: This series does trivial replacement of __raw_xxx functions with xxx_relaxed endian-neutral variants in 'mach-omap2' and 'plat-omap' directories. Some code here most probably won't be used in BE mode (like debug-leds for OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions completely and simplify future grep'ing for new __raw_xxx() entries. This is a part of RFC series [1]. It was missed in previous merge window [2]. Based on v3.15-rc1. Thanks applying these into omap-for-v3.16/be. Regards, Tony [1] http://www.spinics.net/lists/linux-omap/msg99927.html [2] https://lkml.org/lkml/2014/4/2/292 Victor Kamensky (4): ARM: OMAP2+: raw read and write endian fix ARM: OMAP: dmtimer: raw read and write endian fix ARM: OMAP: counter-32k: raw read and write endian fix ARM: OMAP: debug-leds: raw read and write endian fix arch/arm/mach-omap2/board-flash.c |4 +-- arch/arm/mach-omap2/clkt2xxx_dpllcore.c |2 +- arch/arm/mach-omap2/clkt2xxx_osc.c|8 +++--- arch/arm/mach-omap2/clkt2xxx_sys.c|2 +- arch/arm/mach-omap2/cm2xxx_3xxx.h |4 +-- arch/arm/mach-omap2/cm33xx.c |4 +-- arch/arm/mach-omap2/cm3xxx.c |8 +++--- arch/arm/mach-omap2/cm44xx.c |8 +++--- arch/arm/mach-omap2/cminst44xx.c |4 +-- arch/arm/mach-omap2/control.c | 20 +++--- arch/arm/mach-omap2/dma.c |4 +-- arch/arm/mach-omap2/gpmc.c|8 +++--- arch/arm/mach-omap2/id.c |2 +- arch/arm/mach-omap2/irq.c |4 +-- arch/arm/mach-omap2/mux.c |8 +++--- arch/arm/mach-omap2/omap-hotplug.c|4 +-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 ++--- arch/arm/mach-omap2/omap-smp.c|6 ++--- arch/arm/mach-omap2/omap-wakeupgen.c | 42 ++--- arch/arm/mach-omap2/omap4-common.c| 18 ++--- arch/arm/mach-omap2/omap_hwmod.c | 10 +++ arch/arm/mach-omap2/omap_phy_internal.c |6 ++--- arch/arm/mach-omap2/prcm_mpu44xx.c|4 +-- arch/arm/mach-omap2/prm2xxx.h |2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h|4 +-- arch/arm/mach-omap2/prm33xx.c |4 +-- arch/arm/mach-omap2/prm3xxx.h |2 +- arch/arm/mach-omap2/prm44xx.c |4 +-- arch/arm/mach-omap2/prminst44xx.c |4 +-- arch/arm/mach-omap2/sdrc.h|8 +++--- arch/arm/mach-omap2/sdrc2xxx.c|4 +-- arch/arm/mach-omap2/sr_device.c |2 +- arch/arm/mach-omap2/sram.c| 16 +-- arch/arm/mach-omap2/timer.c |8 +++--- arch/arm/mach-omap2/vc.c |4 +-- arch/arm/mach-omap2/wd_timer.c|8 +++--- arch/arm/plat-omap/counter_32k.c |6 ++--- arch/arm/plat-omap/debug-leds.c | 14 +- arch/arm/plat-omap/dmtimer.c |8 +++--- arch/arm/plat-omap/include/plat/dmtimer.h | 16 +-- 40 files changed, 156 insertions(+), 156 deletions(-) -- 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: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, 8 May 2014, Zhuang Jin Can wrote: When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request My understanding is dwc3 will return NYET to host for this Get-Descriptor request transaction, as dwc3 is still in STATUS phase, there's no buffer to receive anything in ep0-out. dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not allow it. A device must always respond to SETUP with ACK. On the other hand, dwc3 _can_ return NYET to the token packet that follows the SETUP transaction. That's what it should do. But at this point it should be in the DATA stage, not the STATUS stage. Receiving a SETUP packet should abort a STATUS stage. And your below comments is not applicapable to dwc3. True, they apply to composite.c rather than dwc3. However, they address an issue very similar to your patch, so I raised this topic in your email thread. Alan Stern -- 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: AM33XX: fix ethernet and mdio default state
On Thursday 08 May 2014 02:27 PM, Johan Hovold wrote: Make sure ethernet and mdio nodes are disabled by default and enable them explicitly only on boards that actually use them. Signed-off-by: Johan Hovold jhov...@gmail.com Acked-by: Mugunthan V N mugunthan...@ti.com Regards Mugunthan V N -- 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 1/2] gpio: omap: prepare and unprepare the debounce clock
On Wednesday 23 April 2014 02:11 AM, Rajendra Nayak wrote: Replace the clk_enable()s with a clk_prepare_enable() and the clk_disables()s with a clk_disable_unprepare() This never showed issues due to the OMAP platform code (hwmod) leaving these clocks in clk_prepare()ed state by default. Reported-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Cc: linux-g...@vger.kernel.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- drivers/gpio/gpio-omap.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 1/2] gpio: omap: prepare and unprepare the debounce clock
On Wednesday 23 April 2014 02:11 AM, Rajendra Nayak wrote: Replace the clk_enable()s with a clk_prepare_enable() and the clk_disables()s with a clk_disable_unprepare() This never showed issues due to the OMAP platform code (hwmod) leaving these clocks in clk_prepare()ed state by default. Reported-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Cc: linux-g...@vger.kernel.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- $subject patch looks fine but I don't see patch 2/2 assuming this is series of two patches. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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 v3.15-rc4
Hello Joachim, On Thu, 8 May 2014, Joachim Eastwood wrote: On 8 May 2014 06:23, Paul Walmsley p...@pwsan.com wrote: Here are some basic OMAP test results for Linux v3.15-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.15-rc4/20140505112251/ Test summary snip The eMMC on the 4460 VAR-SOM-OM has failed; I guess it's run out of reserve blocks to reallocate. Now it's time to find yet another way to boot it. I have some patches for u-boot which makes it possible to use the on-board LAN7500 USB Ethernet controller for tftp. That's great! Since you have a VAR-SOM-OM44 module maybe you could test my dts patches for it? I will post a new version of the patch set early next week. I can cc you. I'd like to load the rootfs off the external SD slot. Looks like you might be adding support for that with your recent DT patches? Do you have the VAR-DVK-OM44 eval board? Yes. - 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] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, May 08, 2014 at 10:25:46AM -0400, Alan Stern wrote: On Thu, 8 May 2014, Zhuang Jin Can wrote: When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request My understanding is dwc3 will return NYET to host for this Get-Descriptor request transaction, as dwc3 is still in STATUS phase, there's no buffer to receive anything in ep0-out. dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not allow it. A device must always respond to SETUP with ACK. It true that device can not return NYET to a SETUP packet. A device must always respond to SETUP with ACK _if_ the SETUP packet is correctly received. Because there's no buffer prepared in ep0 for dwc3 to receive the SETUP packet, I guess there will be no handshake returned to host. I can confirm this by doing an experiment tomorrow:) Jincan -- 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: [GIT PULL #1/2] bus: omap_l3_noc: driver fixes and DRA7/AM437x support
* Nishanth Menon n...@ti.com [140505 13:03]: Hi Tony, Please pull the following driver fixes based on V3 of l3noc fixes and support for DRA7 and AM437x for upcoming 3.16 window. http://marc.info/?l=linux-omapm=139869922030493w=2 This is part 1 of the pull request containing purely the driver updates. The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/l3noc/driver-fixes for you to fetch changes up to 27b7d5f3cc49f2e5cd6c005d73696058b7140c5c: bus: omap_l3_noc: Add AM4372 interconnect error data (2014-05-05 14:34:37 -0500) Thanks pulling this into omap-for-v3.16/l3-noc. Tony Afzal Mohammed (2): bus: omap_l3_noc: ignore masked out unclearable targets bus: omap_l3_noc: Add AM4372 interconnect error data Nishanth Menon (14): bus: omap_l3_noc: Fix copyright information bus: omap_l3_noc: remove iclk from omap_l3 struct bus: omap_l3_noc: populate l3-dev and use it bus: omap_l3_noc: switch over to relaxed variants of readl/writel bus: omap_l3_noc: un-obfuscate l3_targ address computation bus: omap_l3_noc: move L3 master data structure out bus: omap_l3_noc: convert target information into a structure bus: omap_l3_noc: convert flagmux information into a structure bus: omap_l3_noc: fix masterid detection bus: omap_l3_noc: make error reporting and handling common bus: omap_l3_noc: improve readability by using helper for slave event parsing bus: omap_l3_noc: add information about the type of operation bus: omap_l3_noc: Add information about the context of operation bus: omap_l3_noc: introduce concept of submodule Peter Ujfalusi (5): drivers: bus: omap_l3: Convert to use devm_kzalloc drivers: bus: omap_l3: Convert to use devm_ioremap_resource() drivers: bus: omap_l3: Convert to use devm_request_irq() drivers: bus: omap_l3: Remove the platform driver's remove function drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails Rajendra Nayak (2): bus: omap_l3_noc: Add support for discountinous flag mux input numbers bus: omap_l3_noc: Add DRA7 interconnect error data Sricharan R (2): bus: omap_l3_noc: rename functions and data to omap_l3 bus: omap_l3_noc: use of_match_data to pick up SoC information .../devicetree/bindings/arm/omap/l3-noc.txt|2 + drivers/bus/omap_l3_noc.c | 406 --- drivers/bus/omap_l3_noc.h | 545 +++- 3 files changed, 653 insertions(+), 300 deletions(-) -- Regards, Nishanth Menon -- 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: [GIT PULL #2/2] ARM: dts: DRA7/AM437x l3noc dts updates
* Nishanth Menon n...@ti.com [140505 13:07]: Hi Tony, Please pull the following to the dts support of AM437x and DRA7 support for l3_noc for the upcoming 3.16 window. This series was posted http://marc.info/?l=linux-omapm=139750288003978w=2 and the functionality enabled by the first pull request for driver. The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/l3noc/dts-fixes for you to fetch changes up to 2eeddb8a5356e088021a8dd84de870de89bf793d: ARM: dts: AM4372: add l3-noc information (2014-05-05 14:35:29 -0500) Thanks pulling into omap-for-v3.16/fixes-not-urgent. Tony Afzal Mohammed (1): ARM: dts: AM4372: add l3-noc information Rajendra Nayak (1): ARM: dts: DRA7: Use dra7-l3-noc instead of omap4-l3-noc arch/arm/boot/dts/am4372.dtsi |6 +- arch/arm/boot/dts/dra7.dtsi |6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) -- Regards, Nishanth Menon -- 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] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, 8 May 2014, Zhuang Jin Can wrote: dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not allow it. A device must always respond to SETUP with ACK. It true that device can not return NYET to a SETUP packet. A device must always respond to SETUP with ACK _if_ the SETUP packet is correctly received. Because there's no buffer prepared in ep0 for dwc3 to receive the SETUP packet, I guess there will be no handshake returned to host. I can confirm this by doing an experiment tomorrow:) The dwc3 driver should always prepare a buffer for the next ep0 SETUP packet as soon as it retrieves the information for the current SETUP packet from the buffer. Otherwise, as you described it, if the gadget driver never sends its delayed status response then the UDC will never respond to any more control transfers. Alan Stern -- 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: omap4-panda-es boot issues with v3.15-rc4
Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Kevin -- 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: omap4-panda-es boot issues with v3.15-rc4
On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Kevin -- 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 7/8] usb: ohci: sort out dependencies for lpc32xx and omap
On Thu, 8 May 2014, Arnd Bergmann wrote: The dependency on the isp1301 driver is not something that should be in the main OHCI driver but rather the SoC specific part of it. This moves the dependency for LPC32xx into USB_OHCI_HCD_LPC32XX, and changes the 'select ISP1301_OMAP' to a similar 'depends on'. Since the same dependency exists for the client driver, do the same change there. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org Cc: Alan Stern st...@rowland.harvard.edu For the host side changes: Acked-by: Alan Stern st...@rowland.harvard.edu -- 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: OMAP5: DSS hwmod data
Hi Archit, On Thu, 8 May 2014, Archit Taneja wrote: Hi Paul, On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: Hi, On Wed, 12 Mar 2014, Tomi Valkeinen wrote: This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Am looking at this for v3.16. But I think someone needs to take a look at those warnings and figure out why they are happening. We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. The rest of the dss hwmods don't touch MODULEMODE. Therefore, these hwmods cannot be enabled independently, and reset. We don't face this issue in the omapdss driver since the platform devices corresponding to these hwmods have their parent as the platform device corresponding to 'dss_core'. This parent child-relation ensures that 'dss_core' is enabled when the a child calls a pm_runtime_get function. The problem is that we have multiple hwmods which use the same MODULEMODE bit. There is no use-counting done when it comes to enabling/disabling modulemode. If there was such a thing, we could have provided MODULEMODE flags even for the children hwmods. Thanks for the summary. This is indeed a long-overdue item for the hwmod core code. Can you please patch the hwmod core code to add this? I'd suggest making the use-counting functionality conditional on a hwmod flag that you can set for all of the DSS hwmods. (Ideally, the core code would detect that several modules share the same MODULEMODE bits, and automatically set it for those cases, but that seems a bit too complex for a first cut.) - 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 1/2] ARM: omap5: hwmod_data: Update McPDM hwmod's flags
On Thu, 8 May 2014, Peter Ujfalusi wrote: Hi Paul, On 05/08/2014 03:20 AM, Paul Walmsley wrote: Hi Péter, On Wed, 30 Apr 2014, Peter Ujfalusi wrote: Add HWMOD_SWSUP_SIDLE to flags. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This patch could use a better changelog. It would be ideal to understand _why_ HWMOD_SWSUP_SIDLE is needed. Is there a known hardware bug? Or is this simply based on practical observation, e.g., something bad happens if the McPDM is not software-idled? The same issue exists on OMAP5 as on OMAP4: commit 12d82e4b0aa6c71f38b668a372f9a13f243207da Author: Peter Ujfalusi peter.ujfal...@ti.com Date: Fri Jan 18 16:48:16 2013 -0700 ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com [p...@pwsan.com: copy patch description into hwmod data comments] Signed-off-by: Paul Walmsley p...@pwsan.com diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c Thanks, could you please resend the patch with an updated commit message? Then I'll take it. I assume this is -rc material? - Paul
Re: omap4-panda-es boot issues with v3.15-rc4
Hi, On 05/08/2014 06:40 PM, Kevin Hilman wrote: On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Is it observed on OMAP4460 only? if no - it's smth new. if yes - may be some racing condition is still present. Roger, is it possible to connect debugger and check GIC distributor status (gic_dist_base_addr + GIC_DIST_CTRL) in case of failure? According to the current code (OMAP4460) it's possible that CPU0 will stuck only in case if CPU1 is kicked off from PWRDM_POWER_OFF state somehow but not by CPU0. Code assumes that CPU1 can exit from PWRDM_POWER_OFF state only when CPU0 calls clkdm_wakeup(cpu_clkdm[1]); Sorry, but I'm not able to debug it now. Regards, -grygorii -- 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: omap4-panda-es boot issues with v3.15-rc4
* Kevin Hilman khil...@linaro.org [140508 08:40]: On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Booting today's next with multi_v7_defconfig (so cpuidle enabled) on omap4 sdp seems to boot reliably. And it's not producing these: gic_timer_retrigger: lost localtimer interrupt while panda is producing those errors like Roger mentioned. It seems that the USB networking is the main difference between omap4 sdp and panda? 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 v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
Hi George, On 29 April 2014 04:58, George Cherian george.cher...@ti.com wrote: On 4/29/2014 11:49 AM, Yegor Yefremov wrote: On Thu, Apr 24, 2014 at 11:11 PM, Ezequiel Garcia ezequ...@vanguardiasur.com.ar wrote: The DMA controller is needed for the USB controller to be correctly registered. Therefore, if the DMA node is located at the end an unecessary probe deferral is produced systematically. This is easily fixed by moving the node at the beggining of the child list, so it's probed first. This will give issues on module removal. Since we use device_for_each_child in remove patch, it will try to remove cppi dma controller, while the channel is still in use by musb node. OK, this seems confusing: are you sure module removal works? Doing this simple test on v3.15-rcN: $ modprobe musb_dsps $ modprobe musb_am335x $ modprobe musb_am335x -r And the kernel blows up :-( I've been debugging this and I think we simply cannot support removal of the musb_am335x module. Had this ever worked before? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, May 08, 2014 at 11:22:36AM -0400, Alan Stern wrote: On Thu, 8 May 2014, Zhuang Jin Can wrote: dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not allow it. A device must always respond to SETUP with ACK. It true that device can not return NYET to a SETUP packet. A device must always respond to SETUP with ACK _if_ the SETUP packet is correctly received. Because there's no buffer prepared in ep0 for dwc3 to receive the SETUP packet, I guess there will be no handshake returned to host. I can confirm this by doing an experiment tomorrow:) The dwc3 driver should always prepare a buffer for the next ep0 SETUP packet as soon as it retrieves the information for the current SETUP packet from the buffer. In current model dwc3 doesn't prepare a buffer for the next ep0 SETUP packet, and normally host should not send another SETUP packet if the current control transfer is not finished. So below model works well if every control transfer succeeds one by one. Here's the 2-stage control transfer model in dwc3. *** * SETUP PHASE:* *Setup a Control-Setup TRB, start Transfer*- *** | | | XferComplete irq | | | V | *** | *Interpret Setup bytes* | *** | | | 2 stage XferComplete | Setup Pending=0 or 1 V | * | * Wait for Host * | * | | | Status XferNotReady irq | | | V | *** | * STATUS PHASE: * | *Setup Control-Status2 TRB, Start Transfer*-| *** (note: in *STATUS PHASE* it can't start transfer if the delayed status request is not queued by gadget driver). If the gadget driver can't queue the delayed status request in time, dwc3 will stay at *STATUS PHASE*. Then, current control transfer fails. Host starts to send a new SETUP packet. At this point, it really depends on how dwc3 controller will behave when it receives the new SETUP packet. If it can move on to *SETUP PHASE* with similar way to [Tree-stage back to back SETUP handling] (see below), then the stale delayed status request could cause a problem. [ Tree-stage back to back SETUP handling] For a tree-stage control transfer, dwc3 can handle back to back SETUP packets. Below is quoted from dwc3 ep0.c /* * Unfortunately we have uncovered a limitation wrt the Data * Phase. * * Section 9.4 says we can wait for the XferNotReady(DATA) event * to * come before issueing Start Transfer command, but if we do, we * will * miss situations where the host starts another SETUP phase * instead of * the DATA phase. Such cases happen at least on TD.7.6 of the * Link * Layer Compliance Suite. * * The problem surfaces due to the fact that in case of * back-to-back * SETUP packets there will be no XferNotReady(DATA) generated * and we * will be stuck waiting for XferNotReady(DATA) forever. * * By looking at tables 9-13 and 9-14 of the Databook, we can * see that * it tells us to start Data Phase right away. It also mentions * that if * we receive a SETUP phase instead of the DATA phase, core will * issue * XferComplete for the DATA phase, before actually initiating * it in * the wire, with the TRB's status set to SETUP_PENDING. Such * status * can only be used to print some debugging logs, as the core * expects * us to go through to the STATUS phase and start a * CONTROL_STATUS TRB, * just so it completes right away, without transferring * anything and, * only then, we can go back to the SETUP phase. * * Because of this scenario, SNPS decided to change the * programming * model of control transfers and support on-demand transfers * only for * the STATUS phase. To fix the issue we have now, we will * always wait * for gadget driver to queue the DATA phase's struct * usb_request, then * start it right away. * * If we're actually in a 2-stage transfer, we will wait for * XferNotReady(STATUS). */ Otherwise, as you described
[RFC/PATCH] usb: musb: Prevent musb_am335x from being removed
At probe time, the musb_am335x driver registers its childs by calling of_platform_populate(), which registers all childs in the devicetree hierarchy recursively. On the other side, the driver's remove() function uses of_device_unregister() to remove each child in the musb_am335x driver device struct. However, when musb_dsps is loaded, its devices are attached to the musb_am335x driver device struct as musb_am335x childs. Hence, musb_am335x remove() will attempt to unregister the devices registered by musb_dsps, which produces a kernel panic. In other words, the childs in the struct device hierarchy are not the same as the childs in the devicetree hierarchy. Ideally, we should be enforcing the removal of the devices registered by musb_am335x *only*, instead of all the child devices. However, because of the recursive nature of of_platform_populate, this doesn't seem possible. Therefore, as the only solution at hand, this commit disables musb_am335x driver removal capability, preventing it from being ever removed. Just for reference, here's the panic upon module removal: musb-hdrc musb-hdrc.0.auto: remove, state 4 usb usb1: USB disconnect, device number 1 musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered Unable to handle kernel NULL pointer dereference at virtual address 008c pgd = de11c000 [008c] *pgd=9e174831, *pte=, *ppte= Internal error: Oops: 17 [#1] ARM Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-1-g24efd13 #69 task: de1b7500 ti: de122000 task.ti: de122000 PC is at am335x_shutdown+0x10/0x28 LR is at am335x_shutdown+0xc/0x28 pc : [c0327798]lr : [c0327794]psr: a013 sp : de123df8 ip : 0004 fp : 00028f00 r10: r9 : de122000 r8 : c000e6c4 r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 r3 : de0e3810 r2 : r1 : 0001 r0 : Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e11c019 DAC: 0015 Process modprobe (pid: 623, stack limit = 0xde122240) Stack: (0xde123df8 to 0xde124000) 3de0: de0e3810 bf054488 3e00: bf05444c de624010 6013 bf043650 12fc de624010 de0e3810 bf043a20 3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c 3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c 3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 3ee0: bf059000 a013 c02c5bc0 bf05900c de0e3c10 c02c5c48 3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c 3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c 3f40: 0800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 0001 c000e6c4 c0060160 3f80: 00028e70 00028e70 00028ea4 0081 6010 00028e70 00028e70 00028ea4 3fa0: 0081 c000e500 00028e70 00028e70 00028ea4 0800 becb59f8 00027608 3fc0: 00028e70 00028e70 00028ea4 0081 0001 0001 00028f00 3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 6010 00028ea4 [c0327798] (am335x_shutdown) from [bf054488] (dsps_musb_exit+0x3c/0x4c [musb_dsps]) [bf054488] (dsps_musb_exit [musb_dsps]) from [bf043650] (musb_shutdown+0x80/0x90 [musb_hdrc]) [bf043650] (musb_shutdown [musb_hdrc]) from [bf043a20] (musb_remove+0x24/0x68 [musb_hdrc]) [bf043a20] (musb_remove [musb_hdrc]) from [c02ca37c] (platform_drv_remove+0x18/0x1c) [c02ca37c] (platform_drv_remove) from [c02c8db0] (__device_release_driver+0x70/0xc8) [c02c8db0] (__device_release_driver) from [c02c8e28] (device_release_driver+0x20/0x2c) [c02c8e28] (device_release_driver) from [c02c884c] (bus_remove_device+0xdc/0x10c) [c02c884c] (bus_remove_device) from [c02c5b20] (device_del+0x104/0x198) [c02c5b20] (device_del) from [c02ca838] (platform_device_del+0x14/0x9c) [c02ca838] (platform_device_del) from [c02ca8cc] (platform_device_unregister+0xc/0x20) [c02ca8cc] (platform_device_unregister) from [bf054194] (dsps_remove+0x18/0x38 [musb_dsps]) [bf054194] (dsps_remove [musb_dsps]) from [c02ca37c] (platform_drv_remove+0x18/0x1c) [c02ca37c] (platform_drv_remove) from [c02c8db0] (__device_release_driver+0x70/0xc8) [c02c8db0] (__device_release_driver) from [c02c8e28] (device_release_driver+0x20/0x2c) [c02c8e28] (device_release_driver) from [c02c884c] (bus_remove_device+0xdc/0x10c) [c02c884c] (bus_remove_device) from [c02c5b20] (device_del+0x104/0x198) [c02c5b20] (device_del) from [c02c5bc0] (device_unregister+0xc/0x20) [c02c5bc0] (device_unregister) from [bf05900c] (of_remove_populated_child+0xc/0x14 [musb_am335x]) [bf05900c]
Re: omap4-panda-es boot issues with v3.15-rc4
Added few cpuidle people to Cc on this regression. * Tony Lindgren t...@atomide.com [140508 09:57]: * Kevin Hilman khil...@linaro.org [140508 08:40]: On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Booting today's next with multi_v7_defconfig (so cpuidle enabled) on omap4 sdp seems to boot reliably. And it's not producing these: gic_timer_retrigger: lost localtimer interrupt Still seeing the above, looks like the lost localtimer interrupt above is a separate issue.. while panda is producing those errors like Roger mentioned. It seems that the USB networking is the main difference between omap4 sdp and panda? ..but I think I found the cause for recent hangs on panda, just a wild guess based on looking at the recent cpuidle patches after v3.14. Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) makes booting work reliably again on panda. Can you guys confirm, so far no issues here after few boot tests, but it might be too early to tell. 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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/05/2014 09:18 AM, Sricharan R wrote:
From: Nishanth Menon n...@ti.com
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Just wondering, instead of hardcoding this data in the code, and
introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs
in the ti,irq-reserved property in DTS for platforms where such IRQs are
not usable. That way you're skipping these IRQs anyway.
Also that would avoid adding more hard coded data for future SoCs into
the source for such IRQs that must be skipped, and also reduces LOC.
thanks,
-Joel
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 47
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 51d4b87..847f6e3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -13,11 +13,13 @@
#include linux/io.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/irqchip/arm-gic.h
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START32
/*
@@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
};
+/**
+ * struct crossbar_data: Platform specific data
+ * @irqs_unused: array of irqs that cannot be used because of hw erratas
+ * @size: size of the irqs_unused array
+ */
+struct crossbar_data {
+ const uint *irqs_unused;
+ const uint size;
+};
+
static struct crossbar_device *cb;
static inline void crossbar_writel(int irq_no, int cb_no)
@@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
.xlate = crossbar_domain_xlate
};
-static int __init crossbar_of_init(struct device_node *node)
+static int __init crossbar_of_init(struct device_node *node,
+const struct crossbar_data *data)
{
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
+ const int *irqsk = NULL;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
@@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ /* Skip the ones marked as unused */
+ if (data) {
+ irqsk = data-irqs_unused;
+ size = data-size;
+
+ for (i = 0; i size; i++) {
+ entry = irqsk[i];
+
+ if (entry max) {
+ pr_err(Invalid skip entry\n);
+ goto err3;
+ }
+ cb-irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
@@ -208,18 +238,27 @@ err1:
return -ENOMEM;
}
+/* irq number 10 cannot be used because of hw bug */
+int dra_irqs_unused[] = { 10 };
+struct crossbar_data cb_dra_data = { dra_irqs_unused,
+ ARRAY_SIZE(dra_irqs_unused) };
+
static const struct of_device_id crossbar_match[] __initconst = {
- { .compatible = ti,irq-crossbar },
+ { .compatible = ti,irq-crossbar, .data = cb_dra_data },
{}
};
int __init irqcrossbar_init(void)
{
struct device_node *np;
- np = of_find_matching_node(NULL, crossbar_match);
+ const struct of_device_id *of_id;
+ const struct crossbar_data *cdata;
+
+ np = of_find_matching_node_and_match(NULL, crossbar_match, of_id);
if (!np)
return -ENODEV;
- crossbar_of_init(np);
+ cdata = of_id-data;
+ crossbar_of_init(np, cdata);
return 0;
}
--
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: OMAP2+: Add support for RNG on DT booted N900
Hi, On Mon, Apr 07, 2014 at 02:28:46PM +0200, Sebastian Reichel wrote: Add support for OMAP3 ROM Random Number Generator via pdata-quirks. ping -- Sebastian signature.asc Description: Digital signature
RE: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern Sent: Wednesday, May 07, 2014 9:59 AM On Thu, 8 May 2014, Zhuang Jin Can wrote: A similar problem can occur in the opposite sense: The thread queuing the delayed status request might be delayed for so long that another SETUP packet arrives from the host first. In that case, the delayed status request is a response for a stale transfer, so it must not be sent to the host. Do dwc3 and composite.c handle this case correctly? So the situation you describe is that we get the STATUS XferNotReady event, but gadget queues a status request when control transfer already failed. When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request The gadget driver finally submits the delayed request response to the Set-Configuration request. But it is now too late, because the host expects a response to the Get-Descriptor request. dwc3 can't move to SETUP phase until the status request arrives, so any SETUP transaction from host will fail. If status request eventually arrives, it already missed the first control transfer, and I don't know how the controller will behave. If we still can get a STATUS XferComplete event without actually transfer anything on the bus, then we can move back to SETUP PHASE which will remove the stale delayed status request and start the new SETUP transaction. But I think in this situation, the host should already lose it patience and start to reset the bus. My point is that the UDC driver can't handle this. Therefore the gadget driver has to prevent this from happening. That means composite.c has to avoid sending delayed status responses if a new SETUP packet has been received already. Per my understanding, it's impossible for dwc3 to send a stale STATUS request for a new SETUP transaction. dwc3 won't know that the status response is stale. It will think the response was meant for the new transfer, not the old one. The DWC3 controller will actually handle this case on its own. If it sees another SETUP packet come in before the previous Control transfer has completed, it will not send any DATA or STATUS phase packets for the previous Control transfer to the host. But it will fake the correct responses to the software, so the dwc3 driver will think that the DATA/STATUS stages completed successfully, even though nothing actually went out on the bus. For other controllers that can't do this, maybe it should be handled in the UDC driver rather than in the composite gadget? -- 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
[PATCH v3 2/3] ARM: dts: oma3-gta04: Add display support
This patch add support for lcd display on gta04 board. Display control
is connected to spi (used spi bitbang driver).
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dts | 87 +++
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index f8ad125..eb9ab1a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -44,6 +44,36 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ spi_lcd {
+ compatible = spi-gpio;
+ #address-cells = 0x1;
+ #size-cells = 0x0;
+ pinctrl-names = default;
+ pinctrl-0 = spi_gpio_pins;
+
+ gpio-sck = gpio1 12 0;
+ gpio-miso = gpio1 18 0;
+ gpio-mosi = gpio1 20 0;
+ cs-gpios = gpio1 19 0;
+ num-chipselects = 1;
+
+ /* lcd panel */
+ lcd: td028ttec1@0 {
+ compatible = toppoly,td028ttec1;
+ reg = 0;
+ spi-max-frequency = 10;
+ spi-cpol;
+ spi-cpha;
+
+ label = lcd;
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+ };
+ };
};
omap3_pmx_core {
@@ -78,6 +108,47 @@
0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
;
};
+
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync
*/
+ 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync
*/
+ 0x0aa (PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+ 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0
*/
+ 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1
*/
+ 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2
*/
+ 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3
*/
+ 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4
*/
+ 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5
*/
+ 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6
*/
+ 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7
*/
+ 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8
*/
+ 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9
*/
+ 0x0c0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ 0x0c2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ 0x0c4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ 0x0c6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ 0x0c8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ 0x0ca (PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ 0x0cc (PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ 0x0ce (PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+ 0x0d0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data18.dss_data18 */
+ 0x0d2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data19.dss_data19 */
+ 0x0d4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data20.dss_data20 */
+ 0x0d6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data21.dss_data21 */
+ 0x0d8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data22.dss_data22 */
+ 0x0da (PIN_OUTPUT | MUX_MODE0) /*
dss_data23.dss_data23 */
+ ;
+ };
+
+ spi_gpio_pins: spi_gpio_pinmux {
+ pinctrl-single,pins = 0x5a8 (PIN_OUTPUT | MUX_MODE4) /* clk */
+ 0x5b6 (PIN_OUTPUT | MUX_MODE4) /* cs */
+ 0x5b8 (PIN_OUTPUT | MUX_MODE4) /* tx */
+ 0x5b4 (PIN_INPUT | MUX_MODE4) /* rx */
+ ;
+ };
};
i2c1 {
@@ -219,3 +290,19 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 315;
};
+
+dss {
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins ;
+
+ status = okay;
+
+ vdds_dsi-supply = vpll2;
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+ };
[PATCH v3 0/3] Add display support for gta04 device
This 3 patches adding display support for openmoko gta04 device. First patch add DT bindings for topolly td028 panel. Second add description for dss + panel and third fix panel probing when panel is compiled as module. Changes from v2: - add missing 'port' node for dpi_out endpoint (comment from Tomi Valkeinen) Changes from v1: - extend panel compatible string by 'omapdss' - add tpo-td028 panel to dss_compat_conv_list - add MODULE_ALIAS macro to properly probe panel when is compiled as module Marek Belisko (3): omapdss: panel-tpo-td028ec1: Add DT support. ARM: dts: oma3-gta04: Add display support omapdss: panel-tpo-td028ec1: Add module alias .../bindings/video/toppoly,td028ttec1.txt | 30 arch/arm/boot/dts/omap3-gta04.dts | 87 ++ arch/arm/mach-omap2/display.c | 1 + .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 +++- 4 files changed, 150 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt -- 1.9.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 v3 3/3] omapdss: panel-tpo-td028ec1: Add module alias
Add module alias string to make it working when panel is compiled as module.
Without this change panel module is not probed thus display is not working.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
index 5b3466e..728808b 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -505,6 +505,7 @@ static struct spi_driver td028ttec1_spi_driver = {
module_spi_driver(td028ttec1_spi_driver);
+MODULE_ALIAS(spi:toppoly,td028ttec1);
MODULE_AUTHOR(H. Nikolaus Schaller h...@goldelico.com);
MODULE_DESCRIPTION(Toppoly TD028TTEC1 panel driver);
MODULE_LICENSE(GPL);
--
1.9.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 v3 1/3] omapdss: panel-tpo-td028ec1: Add DT support.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../bindings/video/toppoly,td028ttec1.txt | 30
arch/arm/mach-omap2/display.c | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 32 +-
3 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
diff --git a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
new file mode 100644
index 000..7175dc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
@@ -0,0 +1,30 @@
+Toppoly TD028TTEC1 Panel
+
+
+Required properties:
+- compatible: toppoly,td028ttec1
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+---
+
+lcd-panel: td028ttec1@0 {
+ compatible = toppoly,td028ttec1;
+ reg = 0;
+ spi-max-frequency = 10;
+ spi-cpol;
+ spi-cpha;
+
+ label = lcd;
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
+
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d8..66a2ee0 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -566,6 +566,7 @@ static const char * const dss_compat_conv_list[]
__initconst = {
svideo-connector,
ti,tfp410,
ti,tpd12s015,
+ toppoly,td028ttec1,
};
/* prepend compatible string with omapdss, */
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
index fae6adc..5b3466e 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -206,7 +206,8 @@ static int td028ttec1_panel_enable(struct omap_dss_device
*dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
r = in-ops.dpi-enable(in);
@@ -389,6 +390,23 @@ static int td028ttec1_panel_probe_pdata(struct spi_device
*spi)
return 0;
}
+static int td028ttec1_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi-dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(spi-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int td028ttec1_panel_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -418,6 +436,10 @@ static int td028ttec1_panel_probe(struct spi_device *spi)
r = td028ttec1_panel_probe_pdata(spi);
if (r)
return r;
+ } else if (spi-dev.of_node) {
+ r = td028ttec1_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -463,6 +485,13 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id td028ttec1_of_match[] = {
+ { .compatible = omapdss,toppoly,td028ttec1, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, td028ttec1_of_match);
+
static struct spi_driver td028ttec1_spi_driver = {
.probe = td028ttec1_panel_probe,
.remove = td028ttec1_panel_remove,
@@ -470,6 +499,7 @@ static struct spi_driver td028ttec1_spi_driver = {
.driver = {
.name = panel-tpo-td028ttec1,
.owner = THIS_MODULE,
+ .of_match_table = td028ttec1_of_match,
},
};
--
1.9.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: [PATCH 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 14:24-20140508, Joel Fernandes wrote: On 05/05/2014 09:18 AM, Sricharan R wrote: From: Nishanth Menon n...@ti.com When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Just wondering, instead of hardcoding this data in the code, and introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs in the ti,irq-reserved property in DTS for platforms where such IRQs are not usable. That way you're skipping these IRQs anyway. Also that would avoid adding more hard coded data for future SoCs into the source for such IRQs that must be skipped, and also reduces LOC. Good question - lets try to explain the hardware a little here - obviously a driver that cannot use the hardware is useless compared to reducing LOC count ;).. and apologies about the long reply.. Basic understanding: GIC has 160 SPIs and number of hardware block interrupt sources is around or more than 400. So, in comes crossbar - which is basically a mapper by allowing us to select an hardware block interrupt source (identified as crossbar_number or cb_no in code). So all we have to do is to write to a register in crossbar corresponding to GIC and viola, we now routed the interrupt source to a GIC interrupt of our choice. At least the Specification reads so until you drill down to the details. A) You have 160 SPI GIC, and 152 crossbar registers. So, you have 8 GIC SPI interrupts that are hardwired. the reserved mapping basically marks these to indicate that we dont have registers. Example: 0 1 2 3 5 6 131 and 132 - Limitation today - if you want to use PMU for CPU0, SPI interrupt is 131, then if you define, in dts: interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH driver assumes it is crossbar number 131(reserved), Similarly: GIC CS_CTI_MPU_C0_IRQ (SPI 1) is ELM_IRQ (crossbar 1) GIC CS_CTI_MPU_C1_IRQ (SPI 2) is EXT_SYS_IRQ_1 (crossbar 2) GIC MPU_CLUSTER_IRQ_AXIERR (SPI 3) is reserved (crossbar 3) GIC WD_TIMER_MPU_C0_IRQ_WARN (SPI 5) is L3_MAIN_IRQ_APP_ERR (crossbar 5) GIC WD_TIMER_MPU_C1_IRQ_WARN (SPI 6) is PRM_IRQ_MPU (crossbar 6) GIC MPU_CLUSTER_IRQ_PMU_C0 (SPI 131) is reserved (crossbar 131) GIC MPU_CLUSTER_IRQ_PMU_C1 (SPI 132) is reserved (crossbar 132) As of today, we cannot differentiate in DTS if it is one of these direct map interrupts we are requesting or crossbar number we are requesting. B) among the 152 cross bar registers, you have three sets: B.1) The ones like Crossbar register 1 which maps to SPI4 - no problem - you write the crossbar number you want to map, bingo, job done. - The driver works brilliantly here. and this is true for 148 GIC SPIs. B.2) The ones like 10 139 140 - these are interesting, because we have crossbar registers corresponding to these, However writing anything to them has no impact - at least 10 is confirmed to have been hardwired to L3_APP_IRQ (but not documented), we are trying to get explanations for 139 and 140. - but there is strong indication based on testing performed that the registers are NOPs and GIC is hardwired in. I had originally discovered 10, but only a day or so back did we understand what is going on, others we dont know yet. B.3) 133 is a variation to B.2 - There is an magical efuse register which controls if the GIC is hardwired or not. when the efuse bit is 0, it behaves like B.1(program and it works), but almost all silicon have it set to hardwired mode :( The following you wont find in any TRM, and is based on tests performed during the last few days - primarily meant to illustrate this. MPU Crossbar 152 registers +---+ +--+ | |++C1| | PPI.. ||+--+ | 0..32 || --+C2| | ||+--+ ++ +---+| +--+C5| |+---+ | SPI1 || | +--+ -+ L3 APP IRQ | | | || | | | ++---+---+ | +---+| | | | +---+ | | SPI3 || | +--+ | CPU0 | | | || | | | | PMU ++ | +---+| | +--+ +---+| | | SPI4 | --+ | | | | | | | | | | | | +---+ | | |+-+| | | SPI10 | + | || External|| | + | | | || NMI || | | +---+ +--++-+-+-++ | | | | SPI131| | | +-+ | | | | | | + +--+ | Efuse
Re: [PATCH v3 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
* Tony Lindgren t...@atomide.com [140507 14:20]:
* Gupta, Pekon pe...@ti.com [140507 12:20]:
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@ti.com [140422 00:34]:
+gpmc {
+status = okay;
+pinctrl-names = default;
+pinctrl-0 = nand_flash_x8;
+ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
Please use the minimum size 16MB GPMC range here, NAND only
has few registers addressable unlike NOR that actually uses the
whole range.
+nand@0,0 {
+reg = 0 0 0; /* CS0, offset 0 */
Then here map the true size of the NAND device IO register area.
BTW, we should do the similar changes to other files so we can
unify the GPMC partitioning a bit. But that's unsafe to do until
we have fixed the issue of mapping GPMC devices to a different
location from the bootloader location.
I have found the fix of this issue in gpmc_cs_remap() just testing it
using beaglebone NOR cape. I'll post that separately, once I'm confident.
OK that's great. Yet another issue I've noticed is that u-boot
seems to program 37xx L3 to run at 200 MHz and the LAN9220
timings overflow the GPMC registers as 200 / 5 = 32.
And looks like we have a build warning in the -rc cycle with
omap2plus_defconfig:
drivers/mtd/nand/omap2.c:1250:12: warning: ‘erased_sector_bitflips’ defined but
not used [-Wunused-function]
Can you please fix that if not already fixed?
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] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, 8 May 2014, Paul Zimmerman wrote: When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request The gadget driver finally submits the delayed request response to the Set-Configuration request. But it is now too late, because the host expects a response to the Get-Descriptor request. dwc3 can't move to SETUP phase until the status request arrives, so any SETUP transaction from host will fail. If status request eventually arrives, it already missed the first control transfer, and I don't know how the controller will behave. If we still can get a STATUS XferComplete event without actually transfer anything on the bus, then we can move back to SETUP PHASE which will remove the stale delayed status request and start the new SETUP transaction. But I think in this situation, the host should already lose it patience and start to reset the bus. My point is that the UDC driver can't handle this. Therefore the gadget driver has to prevent this from happening. That means composite.c has to avoid sending delayed status responses if a new SETUP packet has been received already. Per my understanding, it's impossible for dwc3 to send a stale STATUS request for a new SETUP transaction. dwc3 won't know that the status response is stale. It will think the response was meant for the new transfer, not the old one. The DWC3 controller will actually handle this case on its own. If it sees another SETUP packet come in before the previous Control transfer has completed, it will not send any DATA or STATUS phase packets for the previous Control transfer to the host. But it will fake the correct responses to the software, so the dwc3 driver will think that the DATA/STATUS stages completed successfully, even though nothing actually went out on the bus. That doesn't handle the problem I described above. When the dwc3 driver gets the late delayed status response, it will think it is a response to the new SETUP packet, and so it will carry out a bogus transfer. It won't know that the status request was meant to be a response to a defunct control transfer. For other controllers that can't do this, maybe it should be handled in the UDC driver rather than in the composite gadget? The only place this can be handled properly is in the gadget driver: composite.c for those gadgets using it, otherwise in the higher level driver (if there are any remaining gadgets that don't use the composite framework). Alan Stern -- 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 13/13] video: omap: allow building on !MMU
* Tomi Valkeinen tomi.valkei...@ti.com [140507 02:15]: On 24/04/14 15:28, Peter Griffin wrote: From: Arnd Bergmann a...@arndb.de The omap lcdc driver has an elaborate mmap_kern function to map the frame buffer into kernel address space as write-combined. This uses functions that are only available on MMU-enabled builds. It does seem equivalent to ioremap_wc though, so we should be able to just use that instead. This patch is build-tested only, it needs to be run on real hardware before applying. I don't have omap1 boards, and I don't know anyone that has. I don't even know if the omap1 fb is working or not... Tony, any idea of omap1's fb? Are you able to test this? I have three omap1 boards in my rack that I use for my boot testing. Tried to enable framebuffer but so far no luck on any of them. So I'm not much of a help here. Looks like the patch should work though.. Aaro Janusz, care to take a look at the patch in this thread? 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: omap4-panda-es boot issues with v3.15-rc4
Tony Lindgren t...@atomide.com writes: [...] ..but I think I found the cause for recent hangs on panda, just a wild guess based on looking at the recent cpuidle patches after v3.14. Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts until all coupled CPUs leave idle) makes booting work reliably again on panda. Can you guys confirm, so far no issues here after few boot tests, but it might be too early to tell. Reverting that makes things a bit more stable, but it still eventually fails in the same way. For me it took 8 boots for it to eventually fail. However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable (20+ boots in a row and still going.) Kevin -- 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] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thu, May 8, 2014 at 3:37 PM, Nishanth Menon n...@ti.com wrote: On 14:24-20140508, Joel Fernandes wrote: On 05/05/2014 09:18 AM, Sricharan R wrote: From: Nishanth Menon n...@ti.com When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Just wondering, instead of hardcoding this data in the code, and introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs in the ti,irq-reserved property in DTS for platforms where such IRQs are not usable. That way you're skipping these IRQs anyway. Also that would avoid adding more hard coded data for future SoCs into the source for such IRQs that must be skipped, and also reduces LOC. Good question - lets try to explain the hardware a little here - obviously a driver that cannot use the hardware is useless compared to reducing LOC count ;).. and apologies about the long reply.. Basic understanding: GIC has 160 SPIs and number of hardware block interrupt sources is around or more than 400. So, in comes crossbar - which is basically a mapper by allowing us to select an hardware block interrupt source (identified as crossbar_number or cb_no in code). So all we have to do is to write to a register in crossbar corresponding to GIC and viola, we now routed the interrupt source to a GIC interrupt of our choice. At least the Specification reads so until you drill down to the details. Thanks for the long explanation and the diagrams! Yes, I feel there is no other way and with so many HW bugs, I think it makes sense to make it a real irqchip driver. Further since not everything goes through the crossbar and some are direct mapped like your diagram, the correct fix is probably making it an irqchip and doing the interrupt controller parenting correctly in DT. That would take care of A), because users of such direct mapped interrupts will go through the GIC interrupt controller directly. It will also take care of B), because if writing to cross bar has no effect for a particular IRQ, or if those IRQs are hard-wired to something, as you said, then that something should go through the GIC directly. I can try to whip up something like this if it makes sense, let me know... thanks, -Joel A) You have 160 SPI GIC, and 152 crossbar registers. So, you have 8 GIC SPI interrupts that are hardwired. the reserved mapping basically marks these to indicate that we dont have registers. Example: 0 1 2 3 5 6 131 and 132 - Limitation today - if you want to use PMU for CPU0, SPI interrupt is 131, then if you define, in dts: interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH driver assumes it is crossbar number 131(reserved), Similarly: GIC CS_CTI_MPU_C0_IRQ (SPI 1) is ELM_IRQ (crossbar 1) GIC CS_CTI_MPU_C1_IRQ (SPI 2) is EXT_SYS_IRQ_1 (crossbar 2) GIC MPU_CLUSTER_IRQ_AXIERR (SPI 3) is reserved (crossbar 3) GIC WD_TIMER_MPU_C0_IRQ_WARN (SPI 5) is L3_MAIN_IRQ_APP_ERR (crossbar 5) GIC WD_TIMER_MPU_C1_IRQ_WARN (SPI 6) is PRM_IRQ_MPU (crossbar 6) GIC MPU_CLUSTER_IRQ_PMU_C0 (SPI 131) is reserved (crossbar 131) GIC MPU_CLUSTER_IRQ_PMU_C1 (SPI 132) is reserved (crossbar 132) As of today, we cannot differentiate in DTS if it is one of these direct map interrupts we are requesting or crossbar number we are requesting. B) among the 152 cross bar registers, you have three sets: B.1) The ones like Crossbar register 1 which maps to SPI4 - no problem - you write the crossbar number you want to map, bingo, job done. - The driver works brilliantly here. and this is true for 148 GIC SPIs. B.2) The ones like 10 139 140 - these are interesting, because we have crossbar registers corresponding to these, However writing anything to them has no impact - at least 10 is confirmed to have been hardwired to L3_APP_IRQ (but not documented), we are trying to get explanations for 139 and 140. - but there is strong indication based on testing performed that the registers are NOPs and GIC is hardwired in. I had originally discovered 10, but only a day or so back did we understand what is going on, others we dont know yet. B.3) 133 is a variation to B.2 - There is an magical efuse register which controls if the GIC is hardwired or not. when the efuse bit is 0, it behaves like B.1(program and it works), but almost all silicon have it set to hardwired mode :( The following you wont find in any TRM, and is based on tests performed during the last few days - primarily meant to illustrate this. MPU Crossbar 152 registers +---+ +--+ | |++C1| | PPI.. ||+--+ | 0..32 || --+C2
RE: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Thursday, May 08, 2014 2:18 PM On Thu, 8 May 2014, Paul Zimmerman wrote: When the host already timed out the control transfer and started a new one. Here's what I'm talking about: Host sends a Set-Configuration request. The UDC driver calls the gadget driver's setup function. The setup function returns DELAYED_STATUS. After a few seconds, the host gets tired of waiting and sends a Get-Descriptor request The gadget driver finally submits the delayed request response to the Set-Configuration request. But it is now too late, because the host expects a response to the Get-Descriptor request. dwc3 can't move to SETUP phase until the status request arrives, so any SETUP transaction from host will fail. If status request eventually arrives, it already missed the first control transfer, and I don't know how the controller will behave. If we still can get a STATUS XferComplete event without actually transfer anything on the bus, then we can move back to SETUP PHASE which will remove the stale delayed status request and start the new SETUP transaction. But I think in this situation, the host should already lose it patience and start to reset the bus. My point is that the UDC driver can't handle this. Therefore the gadget driver has to prevent this from happening. That means composite.c has to avoid sending delayed status responses if a new SETUP packet has been received already. Per my understanding, it's impossible for dwc3 to send a stale STATUS request for a new SETUP transaction. dwc3 won't know that the status response is stale. It will think the response was meant for the new transfer, not the old one. The DWC3 controller will actually handle this case on its own. If it sees another SETUP packet come in before the previous Control transfer has completed, it will not send any DATA or STATUS phase packets for the previous Control transfer to the host. But it will fake the correct responses to the software, so the dwc3 driver will think that the DATA/STATUS stages completed successfully, even though nothing actually went out on the bus. That doesn't handle the problem I described above. When the dwc3 driver gets the late delayed status response, it will think it is a response to the new SETUP packet, and so it will carry out a bogus transfer. It won't know that the status request was meant to be a response to a defunct control transfer. I think you misunderstood me. What I meant was, once the DWC3 controller sees the next SETUP packet, it will still accept the commands from the dwc3 driver to start the DATA and STATUS phases for the previous Control transfer, and will send back (fake) completion events for those commands to the driver. But it won't actually send anything on the wire. So it should be impossible for the dwc3 driver to carry out a bogus transfer. This is a feature of the DWC3 controller intended to simplify what the software needs to handle, and to automatically take care of the corner cases involved here. For other controllers that can't do this, maybe it should be handled in the UDC driver rather than in the composite gadget? The only place this can be handled properly is in the gadget driver: composite.c for those gadgets using it, otherwise in the higher level driver (if there are any remaining gadgets that don't use the composite framework). Why can't the UDC drivers handle this? AFAIK they all keep track of which phase of a Control transfer they are in. If they see another SETUP packet arrive, they could fake the DATA/STATUS stages of the previous transfer, before passing on the next SETUP packet to the gadget driver. Similar to what the DWC3 controller does in hardware. Although, I guess it would be simpler to do it once in composite.c, instead of in each individual UDC driver. But there would have to be a quirk or something, to disable the code if the dwc3 driver is in use. And that wouldn't fix the problem for gadgets that don't use composite.c. -- 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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thursday 08 May 2014 06:43 PM, Joel Fernandes wrote: On Thu, May 8, 2014 at 3:37 PM, Nishanth Menon n...@ti.com wrote: On 14:24-20140508, Joel Fernandes wrote: On 05/05/2014 09:18 AM, Sricharan R wrote: From: Nishanth Menon n...@ti.com When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Just wondering, instead of hardcoding this data in the code, and introducing additional flags (IRQ_SKIP), why not just put these GIC IRQs in the ti,irq-reserved property in DTS for platforms where such IRQs are not usable. That way you're skipping these IRQs anyway. Also that would avoid adding more hard coded data for future SoCs into the source for such IRQs that must be skipped, and also reduces LOC. Good question - lets try to explain the hardware a little here - obviously a driver that cannot use the hardware is useless compared to reducing LOC count ;).. and apologies about the long reply.. Basic understanding: GIC has 160 SPIs and number of hardware block interrupt sources is around or more than 400. So, in comes crossbar - which is basically a mapper by allowing us to select an hardware block interrupt source (identified as crossbar_number or cb_no in code). So all we have to do is to write to a register in crossbar corresponding to GIC and viola, we now routed the interrupt source to a GIC interrupt of our choice. At least the Specification reads so until you drill down to the details. Thanks for the long explanation and the diagrams! Yes, I feel there is no other way and with so many HW bugs, I think it makes sense to make it a real irqchip driver. It doesn't because its not an irqchip. Further since not everything goes through the crossbar and some are direct mapped like your diagram, the correct fix is probably making it an irqchip and doing the interrupt controller parenting correctly in DT. That would take care of A), because users of such direct mapped interrupts will go through the GIC interrupt controller directly. It will also take care of B), because if writing to cross bar has no effect for a particular IRQ, or if those IRQs are hard-wired to something, as you said, then that something should go through the GIC directly. I can try to whip up something like this if it makes sense, let me know... I have been ignoring this series considering they were just fixes but you comments are like re-inventing wheel. Please read all the old threads and comments from Thomas and me on why we took approach and why it is not an irqchip. There is no need to complicate it further. Regards, Santosh -- 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 13/13] video: omap: allow building on !MMU
Hi, On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140507 02:15]: I don't have omap1 boards, and I don't know anyone that has. I don't even know if the omap1 fb is working or not... OMAP1 fb is working very well. As a matter of fact, it's much more usable for me than fb on OMAP2/3 - apart from N900 (on which fb is working again with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb in mainline yet. :-( Tony, any idea of omap1's fb? Are you able to test this? I have three omap1 boards in my rack that I use for my boot testing. Tried to enable framebuffer but so far no luck on any of them. So I'm not much of a help here. Looks like the patch should work though.. Aaro Janusz, care to take a look at the patch in this thread? I couldn't figure out how to enter this code path. Amstrad E3 Nokia 770 will take the alloc_fbmem() path exit, and based on quick look I could not see way to enter mmap_kern(). Is that dead code? A. -- 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 13/13] video: omap: allow building on !MMU
* Aaro Koskinen aaro.koski...@iki.fi [140508 16:09]: Hi, On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140507 02:15]: I don't have omap1 boards, and I don't know anyone that has. I don't even know if the omap1 fb is working or not... OMAP1 fb is working very well. As a matter of fact, it's much more usable for me than fb on OMAP2/3 - apart from N900 (on which fb is working again with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb in mainline yet. :-( I hear you.. What do you have in the .config for omap1? Would be nice to enable the framebuffer in omap1_defconfig? Tony, any idea of omap1's fb? Are you able to test this? I have three omap1 boards in my rack that I use for my boot testing. Tried to enable framebuffer but so far no luck on any of them. So I'm not much of a help here. Looks like the patch should work though.. Aaro Janusz, care to take a look at the patch in this thread? I couldn't figure out how to enter this code path. Amstrad E3 Nokia 770 will take the alloc_fbmem() path exit, and based on quick look I could not see way to enter mmap_kern(). Is that dead code? Could be. It may be something left from when we had code to keep the bootloader logo displayed while booting kernel. 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
[PATCH v11 0/7] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi Balaji, Tony, all
v11
- split !CONFIG_OF compile break into separate patch
- enable IWE/CLKEXTFREE in CON/HCTL register needed for omap4
- '' vs '' in omap_hsmmc_resume, 1/5 (Andreas Müller)
- #define DLEV_DAT instead of BIT(21) 2/5 (Balaji)
- pinctrl_pm_select_default_state() removed, 4/5 (Balaji)
- drop _irqsave/_irqrestore from omap_hsmmc_wake_irq handler since it
can't be preempted by same priority omap_hsmmc_irq handler 1/5(Joel Fernandes)
- replace devres_open_group by explicit devm_free calls 1/5 (Balaji)
- disable_irq_nosync wake_irq since we handle it thread safe 1/5 (Balaji)
- drop 'gpio_dat1' pinctrl states and rework documentation 5/5 (Balaji)
v10
- bug fix on multi-core, untested
- incorporated changes from Balaji
- use devres / RAII mechanism to configure wake_up /
sdio irq capabilities
- drop pinctrl state 'active'
rely on driver-model states 'default', 'idle'
- add specific 'gpio_dat1' state for am335x SWAKEUP hack
- reorganized patches; +1 patch multi-core bugfix / +1 for pinctrl
- rebased 455c6fdbd21916 / cherry-picks from mmc-next
v9
- extended comment about why wake-irq is needed
- drop double '(' ')' around card_detect_irq
- drop final '.' in in subject line of patch
v8
- rebased on top of Tony Lindgrent...@atomide.com changes
- improved changelog describing the earlier work
- improved wakeup irq setup
- works for am3730 es platform now
- my changes on top:
- compile tested with #undef CONFIG_OF
- disable wake_irq in handler to prevent infinite loop
- fixed typo and added comment about wake-irq
v7
- rebase on 3.14.0-rc3-49726-g77e15ec
- split omap_hsmmc_pin_init due to regression on omap-3730 platform
v6
- rebase on Linux 3.13-rc3
- reformatting debugfs
v5
- fix compile error introduced by last minute one line fix
v4:
- switch to interrupts-extended format
- drop ti,swakeup-missing flag convert to comaptible section
v3:
- removed gpio_irq from platform_data
v2:
- incorparated changes as suggested by reviewers
- simplified workaround for am335x, gpio will now only wake
the module from runtime suspend, not handle the sdio irq
itself
Andreas Fenkart (6):
mmc: omap_hsmmc: compile fix for !CONFIG_OF build
mmc: omap_hsmmc: Enable SDIO interrupt
mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x
Balaji T K (1):
mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 53
drivers/mmc/host/omap_hsmmc.c | 283 ++--
include/linux/platform_data/mmc-omap.h |1 +
3 files changed, 316 insertions(+), 21 deletions(-)
--
1.7.10.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: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tony Lindgren t...@atomide.com [140429 16:53]:
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
BTW, I'm also seeing this warning on 3730-evm it may be related:
[3.523101] [ cut here ]
[3.528015] WARNING: CPU: 0 PID: 6 at
drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
[3.538360] clk rate mismatch: 10800 != 11520
[3.543518] Modules linked in:
[3.546966] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: GW
3.15.0-rc3-00015-gaa296fa-dirty #391
[3.557159] Workqueue: deferwq deferred_probe_work_func
[3.562774] [c0014cbc] (unwind_backtrace) from [c001191c]
(show_stack+0x10/0x14)
[3.571014] [c001191c] (show_stack) from [c05660b4]
(dump_stack+0x80/0x9c)
[3.578704] [c05660b4] (dump_stack) from [c003f558]
(warn_slowpath_common+0x68/0x8c)
[3.587249] [c003f558] (warn_slowpath_common) from [c003f610]
(warn_slowpath_fmt+0x30/0x40)
[3.596496] [c003f610] (warn_slowpath_fmt) from [c03129f0]
(dss_set_fck_rate+0x6c/0x8c)
[3.605407] [c03129f0] (dss_set_fck_rate) from [c0323728]
(dpi_display_enable+0x23c/0x2e4)
[3.614562] [c0323728] (dpi_display_enable) from [c03323a8]
(sharp_ls_enable+0x58/0xc4)
[3.623474] [c03323a8] (sharp_ls_enable) from [c0335ee0]
(omapfb_probe+0x548/0x848)
[3.631988] [c0335ee0] (omapfb_probe) from [c0378cfc]
(platform_drv_probe+0x18/0x48)
[3.640594] [c0378cfc] (platform_drv_probe) from [c0377938]
(driver_probe_device+0x110/0x22c)
[3.650024] [c0377938] (driver_probe_device) from [c0376038]
(bus_for_each_drv+0x44/0x8c)
[3.659088] [c0376038] (bus_for_each_drv) from [c03777f0]
(device_attach+0x74/0x8c)
[3.667541] [c03777f0] (device_attach) from [c0376ecc]
(bus_probe_device+0x88/0xb0)
[3.676025] [c0376ecc] (bus_probe_device) from [c03772d0]
(deferred_probe_work_func+0x64/0x94)
[3.685546] [c03772d0] (deferred_probe_work_func) from [c0057220]
(process_one_work+0x1b4/0x4bc)
[3.695251] [c0057220] (process_one_work) from [c0057908]
(worker_thread+0x11c/0x398)
[3.704620] [c0057908] (worker_thread) from [c005df10]
(kthread+0xc8/0xe4)
[3.712280] [c005df10] (kthread) from [c000e768]
(ret_from_fork+0x14/0x2c)
[3.719909] ---[ end trace 1c9526c1a2975498 ]---
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
.parent_clk_name= dpll4_ck,
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
--
1.8.1.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
--
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 v11 2/7] mmc: omap_hsmmc: Enable SDIO interrupt
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Cc: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5042a15..f43a69e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -133,6 +135,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -167,7 +170,6 @@ static void apply_clk_hack(struct device *dev)
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 1)/* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -221,6 +223,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -233,6 +236,9 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 2)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -537,27 +543,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal MMC core */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
-
[PATCH v11 1/7] mmc: omap_hsmmc: compile fix for !CONFIG_OF build
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8d07e2b..5042a15 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1864,6 +1864,7 @@ static inline struct omap_mmc_platform_data
{
return ERR_PTR(-EINVAL);
}
+#define omap_mmc_of_match NULL
#endif
static int omap_hsmmc_probe(struct platform_device *pdev)
--
1.7.10.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 v11 5/7] mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
On multicores, an sdio irq handler could be running in parallel to
runtime suspend. In the worst case it could be waiting for the spinlock
held by the runtime suspend. When runtime suspend is complete and the
functional clock (fclk) turned off, the irq handler will continue and
cause a SIGBUS on the first register access.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 14857d7..47a5982 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -134,6 +134,9 @@ static void apply_clk_hack(struct device *dev)
#define SRD(1 26)
#define SOFTRESET (1 1)
+/* PSTATE */
+#define DLEV_DAT(x)(1 (20 + (x)))
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 0)
#define TC_EN (1 1)
@@ -2455,6 +2458,7 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
@@ -2466,14 +2470,29 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
/* disable sdio irq handling to prevent race */
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+
+ if (!(OMAP_HSMMC_READ(host-base, PSTATE) DLEV_DAT(1))) {
+ /*
+* dat1 line low, pending sdio irq
+* race condition: possible irq handler running on
+* multi-core, abort
+*/
+ dev_dbg(dev, pending sdio irq, abort suspend\n);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ pm_runtime_mark_last_busy(dev);
+ ret = -EBUSY;
+ goto abort;
+ }
WARN_ON(host-flags HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
}
+abort:
spin_unlock_irqrestore(host-irq_lock, flags);
- return 0;
+ return ret;
}
static int omap_hsmmc_runtime_resume(struct device *dev)
--
1.7.10.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 v11 3/7] mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
From: Balaji T K balaj...@ti.com
To detect sdio irqs properly without spurious events,
OMAP4 needs IWE in CON and CTPL, CLKEXTFREE in HCTL to be set
Signed-off-by: Balaji T K balaj...@ti.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f43a69e..f76462d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -120,7 +120,10 @@ static void apply_clk_hack(struct device *dev)
#define BCE(1 1)
#define FOUR_BIT (1 1)
#define HSPE (1 2)
+#define IWE(1 24)
#define DDR(1 19)
+#define CLKEXTFREE (1 16)
+#define CTPL (1 11)
#define DW8(1 5)
#define OD 0x1
#define STAT_CLEAR 0x
@@ -713,6 +716,9 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
capa = VS18;
}
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ)
+ hctl |= IWE;
+
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) | hctl);
@@ -1709,19 +1715,23 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
{
struct omap_hsmmc_host *host = mmc_priv(mmc);
- u32 irq_mask;
+ u32 irq_mask, con;
unsigned long flags;
spin_lock_irqsave(host-irq_lock, flags);
+ con = OMAP_HSMMC_READ(host-base, CON);
irq_mask = OMAP_HSMMC_READ(host-base, ISE);
if (enable) {
host-flags |= HSMMC_SDIO_IRQ_ENABLED;
irq_mask |= CIRQ_EN;
+ con |= CTPL | CLKEXTFREE;
} else {
host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
irq_mask = ~CIRQ_EN;
+ con = ~(CTPL | CLKEXTFREE);
}
+ OMAP_HSMMC_WRITE(host-base, CON, con);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
/*
@@ -1773,6 +1783,8 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
goto err;
}
+ OMAP_HSMMC_WRITE(host-base, HCTL,
+OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;
err:
--
1.7.10.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 v11 4/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f76462d..14857d7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -83,6 +83,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1854,14 +1855,29 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
- seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
- mmc-index, host-context_loss);
+ seq_printf(s, mmc%d:\n, mmc-index);
+ seq_printf(s, sdio irq mode\t%s\n,
+ (mmc-caps MMC_CAP_SDIO_IRQ) ? interrupt : polling);
- pm_runtime_get_sync(host-dev);
+ if (mmc-caps MMC_CAP_SDIO_IRQ) {
+ seq_printf(s, sdio irq \t%s\n,
+ (host-flags HSMMC_SDIO_IRQ_ENABLED) ? enabled
+ : disabled);
+ }
+
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, runtime state\t%s\n, (suspended ? idle : active));
+ seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+
+ pm_runtime_get_sync(host-dev);
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.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 v11 6/7] mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
These are predefined states of the driver model. When not present,
as if not set in the device tree, they become no-ops.
Explicitly selecting the default state is not needed since the
device core layer sets pin mux to default state before probe.
This is not the simplest implementation, on AM335x at least, we could
switch to idle at any point in the suspend hook, only the default state
needs to be set before writing to the irq registers or an IRQ might get
lost.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 47a5982..5a321f98 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2032,7 +2032,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
const struct omap_mmc_of_data *data;
apply_clk_hack(pdev-dev);
@@ -2258,11 +2257,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev,
- pins are not configured from the driver\n);
-
/*
* For now, only support SDIO interrupt if we have a separate
* wake-up interrupt configured from device tree. This is because
@@ -2486,10 +2480,15 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
goto abort;
}
+ pinctrl_pm_select_idle_state(dev);
+
WARN_ON(host-flags HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
+ } else {
+ pinctrl_pm_select_idle_state(dev);
}
+
abort:
spin_unlock_irqrestore(host-irq_lock, flags);
return ret;
@@ -2513,9 +2512,14 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
host-flags = ~HSMMC_WAKE_IRQ_ENABLED;
}
+ pinctrl_pm_select_default_state(host-dev);
+
+ /* irq lost, if pinmux incorrect */
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ } else {
+ pinctrl_pm_select_default_state(host-dev);
}
spin_unlock_irqrestore(host-irq_lock, flags);
return 0;
--
1.7.10.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
