[PATCH 5/9] ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.
CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
accessing the wrong memory address for idle and standby
operations. Fix this by removing the ADDR_TYPE_RT flag from
the 1st memory region in CPGMAC0 hwmod entry.
Signed-off-by: Vaibhav Bedia
---
Change from RFC version:
No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index f2f408c..34a67e4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2496,7 +2496,6 @@ static struct omap_hwmod_addr_space
am33xx_cpgmac0_addr_space[] = {
{
.pa_start = 0x4a10,
.pa_end = 0x4a10 + SZ_2K - 1,
- .flags = ADDR_TYPE_RT,
},
/* cpsw wr */
{
--
1.7.0.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 9/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
Add minimal APIs for writing to the IPC and the M3_TXEV registers
in the Control module. These will be used in a subsequent patch which
adds suspend-resume support for AM33XX.
Signed-off-by: Vaibhav Bedia
Acked-by: Santosh Shilimkar
---
Change from RFC version:
No change
arch/arm/mach-omap2/control.c | 20
arch/arm/mach-omap2/control.h | 41 +
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 2adb268..c5d54ae 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -604,3 +604,23 @@ int omap3_ctrl_save_padconf(void)
}
#endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
+
+#if defined(CONFIG_SOC_AM33XX) && defined(CONFIG_PM)
+void am33xx_txev_eoi(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ACK, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_txev_enable(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ENABLE, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data)
+{
+ omap_ctrl_writel(data->resume_addr, AM33XX_CONTROL_IPC_MSG_REG0);
+ omap_ctrl_writel(data->sleep_mode, AM33XX_CONTROL_IPC_MSG_REG1);
+ omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2);
+ omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3);
+}
+#endif /* CONFIG_SOC_AM33XX && CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..cb85f0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,37 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 << 22)
+#define AM33XX_DDR_IO_CTRL 0x0E04
+#define AM33XX_VTP0_CTRL_REG 0x0E0C
+
+/* AM33XX VTP0_CTRL_REG bits */
+#define AM33XX_VTP_CTRL_START_EN (1 << 0)
+#define AM33XX_VTP_CTRL_LOCK_EN(1 << 4)
+#define AM33XX_VTP_CTRL_READY (1 << 5)
+#define AM33XX_VTP_CTRL_ENABLE (1 << 6)
+
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI 0x1324
+
+#define AM33XX_M3_TXEV_ACK (0x1 << 0)
+#define AM33XX_M3_TXEV_ENABLE (0x0 << 0)
+
+/* AM33XX IPC message registers */
+#define AM33XX_CONTROL_IPC_MSG_REG00x1328
+#define AM33XX_CONTROL_IPC_MSG_REG10x132C
+#define AM33XX_CONTROL_IPC_MSG_REG20x1330
+#define AM33XX_CONTROL_IPC_MSG_REG30x1334
+#define AM33XX_CONTROL_IPC_MSG_REG40x1338
+#define AM33XX_CONTROL_IPC_MSG_REG50x133C
+#define AM33XX_CONTROL_IPC_MSG_REG60x1340
+#define AM33XX_CONTROL_IPC_MSG_REG70x1344
+
+#define AM33XX_DDR_CMD0_IOCTRL 0x1404
+#define AM33XX_DDR_CMD1_IOCTRL 0x1408
+#define AM33XX_DDR_CMD2_IOCTRL 0x140C
+#define AM33XX_DDR_DATA0_IOCTRL0x1440
+#define AM33XX_DDR_DATA1_IOCTRL0x1444
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
@@ -417,6 +448,16 @@ extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
extern void omap2_set_globals_control(void __iomem *ctrl,
void __iomem *ctrl_pad);
+struct am33xx_ipc_data {
+ u32 resume_addr;
+ u32 param1;
+ u32 param2;
+ u32 sleep_mode;
+};
+extern void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data);
+extern void am33xx_txev_eoi(void);
+extern void am33xx_txev_enable(void);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
--
1.7.0.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 7/9] ARM: OMAP2+: AM33XX: Update the hardreset API
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the hardreset API to ensure that the reset line properly
deasserted.
Signed-off-by: Vaibhav Bedia
Acked-by: Santosh Shilimkar
---
Change from RFC version:
No change
arch/arm/mach-omap2/omap_hwmod.c |5 +
arch/arm/mach-omap2/prm33xx.c| 11 +++
arch/arm/mach-omap2/prm33xx.h|2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..6549439 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3041,11 +3041,8 @@ static int _am33xx_assert_hardreset(struct omap_hwmod
*oh,
static int _am33xx_deassert_hardreset(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri)
{
- if (ohri->st_shift)
- pr_err("omap_hwmod: %s: %s: hwmod data error: OMAP4 does not
support st_shift\n",
- oh->name, ohri->name);
-
return am33xx_prm_deassert_hardreset(ohri->rst_shift,
+ ohri->st_shift,
oh->clkdm->pwrdm.ptr->prcm_offs,
oh->prcm.omap4.rstctrl_offs,
oh->prcm.omap4.rstst_offs);
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 1ac7388..44c0d72 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -110,11 +110,11 @@ int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16
rstctrl_offs)
* -EINVAL upon an argument error, -EEXIST if the submodule was already out
* of reset, or -EBUSY if the submodule did not exit reset promptly.
*/
-int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs)
{
int c;
- u32 mask = 1 << shift;
+ u32 mask = 1 << st_shift;
/* Check the current status to avoid de-asserting the line twice */
if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
@@ -122,11 +122,14 @@ int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
/* Clear the reset status by writing 1 to the status bit */
am33xx_prm_rmw_reg_bits(0x, mask, inst, rstst_offs);
+
/* de-assert the reset control line */
+ mask = 1 << shift;
+
am33xx_prm_rmw_reg_bits(mask, 0, inst, rstctrl_offs);
- /* wait the status to be set */
- omap_test_timeout(am33xx_prm_is_hardreset_asserted(shift, inst,
+ /* wait the status to be set */
+ omap_test_timeout(am33xx_prm_is_hardreset_asserted(st_shift, inst,
rstst_offs),
MAX_MODULE_HARDRESET_WAIT, c);
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 1c40373..9b9918d 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -125,7 +125,7 @@ extern void am33xx_prm_global_warm_sw_reset(void);
extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst,
u16 rstctrl_offs);
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
-extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+extern int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
#endif /* ASSEMBLER */
#endif
--
1.7.0.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 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
Hi, The following patches were earlier posted as part the AM33XX suspend-resume support series [1]. Based on the suggestion from Santosh Shilimkar i have split out the changes which update the various data files related to AM33XX support. These patches apply on top of v3.8-rc3 Regards, Vaibhav [1] http://marc.info/?l=linux-arm-kernel&m=135698501821074&w=2 Vaibhav Bedia (9): ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit ARM: OMAP2+: AM33XX: Update the hardreset API ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3 ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs arch/arm/boot/dts/am33xx.dtsi | 11 ++ arch/arm/mach-omap2/cm33xx.h |9 ++--- arch/arm/mach-omap2/control.c | 20 +++ arch/arm/mach-omap2/control.h | 41 +++ arch/arm/mach-omap2/omap_hwmod.c |5 +-- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 50 arch/arm/mach-omap2/prm33xx.c | 11 -- arch/arm/mach-omap2/prm33xx.h |4 ++- 8 files changed, 115 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions
Some of the included header files are not needed so remove them. Signed-off-by: Vaibhav Bedia Acked-by: Santosh Shilimkar --- Change from RFC version: No change arch/arm/mach-omap2/cm33xx.h |7 +-- 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 5fa0b62..8009e13 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -17,16 +17,11 @@ #ifndef __ARCH_ARM_MACH_OMAP2_CM_33XX_H #define __ARCH_ARM_MACH_OMAP2_CM_33XX_H -#include -#include -#include -#include - #include "common.h" #include "cm.h" #include "cm-regbits-33xx.h" -#include "cm33xx.h" +#include "iomap.h" /* CM base address */ #define AM33XX_CM_BASE 0x44e0 -- 1.7.0.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 8/9] ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
Since AM33XX supports only DT-boot, this is needed
for the appropriate device nodes to be created.
Note: OCMC RAM is part of the PER power domain and supports
retention. The assembly code for low power entry/exit will
run from OCMC RAM. To ensure that the OMAP PM code does not
attempt to disable the clock to OCMC RAM as part of the
suspend process add the no_idle_on_suspend flag.
Signed-off-by: Vaibhav Bedia
Acked-by: Santosh Shilimkar
---
Change from RFC version:
No change
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..4731748 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,16 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ ocmcram: ocmcram@4030 {
+ compatible = "ti,ocmcram";
+ ti,hwmods = "ocmcram";
+ ti,no_idle_on_suspend;
+ };
+
+ wkup_m3: wkup_m3@44d0 {
+ compatible = "ti,wkup_m3";
+ ti,hwmods = "wkup_m3";
+ };
};
};
--
1.7.0.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 6/9] ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the WKUP-M3 hwmod data to reflect the same.
Signed-off-by: Vaibhav Bedia
---
Change from RFC version:
No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 34a67e4..78929a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -269,6 +269,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_WKUP_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_WKUP_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.0.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 2/9] ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
This is necessary to ensure that macros declared here can be reused from assembly files. Signed-off-by: Vaibhav Bedia Acked-by: Santosh Shilimkar --- Change from RFC version: Get rid of extra lines arch/arm/mach-omap2/cm33xx.h |2 ++ arch/arm/mach-omap2/prm33xx.h |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 8009e13..64f4baf 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -376,6 +376,7 @@ #define AM33XX_CM_CEFUSE_CEFUSE_CLKCTRL AM33XX_CM_REGADDR(AM33XX_CM_CEFUSE_MOD, 0x0020) +#ifndef __ASSEMBLER__ extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs); @@ -412,4 +413,5 @@ static inline int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, } #endif +#endif /* ASSEMBLER */ #endif diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h index 3f25c56..1c40373 100644 --- a/arch/arm/mach-omap2/prm33xx.h +++ b/arch/arm/mach-omap2/prm33xx.h @@ -117,6 +117,7 @@ #define AM33XX_PM_CEFUSE_PWRSTST_OFFSET0x0004 #define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) +#ifndef __ASSEMBLER__ extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); @@ -126,4 +127,5 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs, u16 rstst_offs); +#endif /* ASSEMBLER */ #endif -- 1.7.0.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 4/9] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia
Acked-by: Santosh Shilimkar
---
Change from RFC version:
Clarify TPTC in the changelog
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 8280f11..f2f408c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1823,6 +1823,7 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
.class = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
.mpu_irqs = am33xx_tptc0_irqs,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
OCMC RAM lies in the PER power domain and this memory
support retention.
Signed-off-by: Vaibhav Bedia
Acked-by: Santosh Shilimkar
---
Change from RFC version:
No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 47
1 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..8280f11 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -414,7 +414,6 @@ static struct omap_hwmod am33xx_adc_tsc_hwmod = {
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
- *- ocmc ram
*- ocp watch point
*- aes0
*- sha0
@@ -481,25 +480,6 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
},
};
-/* ocmcram */
-static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
- .name = "ocmcram",
-};
-
-static struct omap_hwmod am33xx_ocmcram_hwmod = {
- .name = "ocmcram",
- .class = &am33xx_ocmcram_hwmod_class,
- .clkdm_name = "l3_clkdm",
- .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
- .main_clk = "l3_gclk",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocpwp */
static struct omap_hwmod_class am33xx_ocpwp_hwmod_class = {
.name = "ocpwp",
@@ -570,6 +550,25 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/* ocmcram */
+static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
+ .name = "ocmcram",
+};
+
+static struct omap_hwmod am33xx_ocmcram_hwmod = {
+ .name = "ocmcram",
+ .class = &am33xx_ocmcram_hwmod_class,
+ .clkdm_name = "l3_clkdm",
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .main_clk = "l3_gclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* 'smartreflex' class */
static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
.name = "smartreflex",
@@ -3328,6 +3327,13 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
.flags = OCPIF_SWSUP_IDLE,
};
+/* l3 main -> ocmc */
+static struct omap_hwmod_ocp_if am33xx_l3_main__ocmc = {
+ .master = &am33xx_l3_main_hwmod,
+ .slave = &am33xx_ocmcram_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l4_fw__emif_fw,
&am33xx_l3_main__emif,
@@ -3398,6 +3404,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
&am33xx_l3_main__tptc0,
&am33xx_l3_main__tptc1,
&am33xx_l3_main__tptc2,
+ &am33xx_l3_main__ocmc,
&am33xx_l3_s__usbss,
&am33xx_l4_hs__cpgmac0,
&am33xx_cpgmac0__mdio,
--
1.7.0.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 v2] pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
On Fri, Jan 18, 2013 at 04:18:27AM +, Philip, Avinash wrote: > On Thu, Jan 17, 2013 at 21:22:18, Thierry Reding wrote: > > On Thu, Jan 10, 2013 at 06:35:26PM +0530, Philip Avinash wrote: > > > From: "Philip, Avinash" > > > > > > The clock framework has changed and it's now better to invoke > > > clock_prepare_enable() and clk_disable_unprepare() rather than the > > > legacy clk_enable() and clk_disable() calls. This patch converts the > > > pwm-tiehrpwm driver to the new framework. > > > > > > Signed-off-by: Philip Avinash > > > --- > > > Changes Since v1: > > > - Check the return value of TBCLK enable in .pwm_enable() > > > > > > In 3.8-rc1, common clock frame work support added to AM335x. > > > > > > drivers/pwm/pwm-tiehrpwm.c | 10 -- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > I had applied this to my for-next branch, but reading the commit message > > again it would seem that this should actually go into 3.8, right? > > Common clock framework support added for am335x in 3.8 only, still EHRPWM > tbclk not present in clock tree. I expect this to be in 3.9. So this patch > also requires to be in 3.9 only. Okay, I'll leave it in my for-next branch then, which gets merged into linux-next and will go into 3.9. Thierry pgpkXs4tKB7rN.pgp Description: PGP signature
[PATCH 2/3] ARM: dts: AM33XX: Add GPMC node
From: "Philip, Avinash"
Add GPMC data node to AM33XX device tree file.
Signed-off-by: Philip Avinash
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index eaef5e7..f4209d8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -393,5 +393,17 @@
ti,hwmods = "elm";
status = "disabled";
};
+
+ gpmc: gpmc@5000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x5000 0x2000>;
+ interrupts = <100>;
+ num-cs = <8>;
+ num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ status = "disabled";
+ };
};
};
--
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
[PATCH 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am335x-evm with GPMC controller timing for NAND flash
interface, NAND partition table, ECC scheme, elm handle id, pin-mux
setup.
Signed-off-by: Philip Avinash
---
arch/arm/boot/dts/am335x-evm.dts | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d649644..1c6b1a8 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,8 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
+ pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0
+ &nandflash_pins_s0>;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins = <
@@ -44,6 +45,26 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
>;
};
+
+ nandflash_pins_s0: nandflash_pins_s0 {
+ pinctrl-single,pins = <
+ 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
PULLUP | MODE0 */
+ 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
PULLUP | MODE0 */
+ 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
PULLUP | MODE0 */
+ 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
PULLUP | MODE0 */
+ 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
PULLUP | MODE0 */
+ 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
PULLUP | MODE0 */
+ 0x18 0x30 /* gpmc_ad6.gpmc_ad6, INPUT |
PULLUP | MODE0 */
+ 0x1c 0x30 /* gpmc_ad7.gpmc_ad7, INPUT |
PULLUP | MODE0 */
+ 0x70 0x30 /* gpmc_wait0.gpmc_wait0, INPUT
| PULLUP | MODE0 */
+ 0x74 0x37 /* gpmc_wpn.gpio0_30, INPUT |
PULLUP | MODE7 */
+ 0x7c 0x8/* gpmc_csn0.gpmc_csn0, PULL
DISA */
+ 0x90 0x8/* gpmc_advn_ale.gpmc_advn_ale,
PULL DISA */
+ 0x94 0x8/* gpmc_oen_ren.gpmc_oen_ren,
PULL DISA */
+ 0x98 0x8/* gpmc_wen.gpmc_wen, PULL DISA
*/
+ 0x9c 0x8/* gpmc_be0n_cle.gpmc_be0n_cle,
PULL DISA */
+ >;
+ };
};
ocp {
@@ -102,6 +123,81 @@
reg = <0x48>;
};
};
+
+ elm: elm@4808 {
+ status = "okay";
+ };
+
+ gpmc: gpmc@5000 {
+ status = "okay";
+ ranges = <0 0 0x0800 0x1000>; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <8>;
+ ti,nand-ecc-opt = "bch8";
+
+ gpmc,sync-clk = <0>;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <44>;
+ gpmc,cs-wr-off = <44>;
+ gpmc,adv-on = <6>;
+ gpmc,adv-rd-off = <34>;
+ gpmc,adv-wr-off = <44>;
+ gpmc,we-off = <40>;
+ gpmc,oe-off = <54>;
+ gpmc,access = <64>;
+ gpmc,rd-cycle = <82>;
+ gpmc,wr-cycle = <82>;
+ gpmc,wr-access = <40>;
+ gpmc,wr-data-mux-bus = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ elm_id = <&elm>;
+
+ /* MTD partition table */
+ partition@0 {
+ label = "SPL1";
+ reg = <0x 0x2>;
+ };
+
+ partition@1 {
+ label = "SPL2";
+ reg = <0x0002 0x0002>;
+ };
+
+ partition@2 {
+ label = "SPL3";
+ reg = <0x0004 0x0002>;
+ };
+
+ partition@3 {
+ label = "SPL
[PATCH 1/3] ARM: dts: AM33XX: Add ELM node
From: "Philip, Avinash"
Add ELM data node to AM33XX device tree file.
Signed-off-by: Philip Avinash
---
arch/arm/boot/dts/am33xx.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..eaef5e7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,13 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ elm: elm@4808 {
+ compatible = "ti,am33xx-elm";
+ reg = <0x4808 0x2000>;
+ interrupts = <4>;
+ ti,hwmods = "elm";
+ status = "disabled";
+ };
};
};
--
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
[PATCH 0/3] Add device tree support for NAND flash in am335x-evm
This patch series adds device tree support for NAND flash in am335x-evm. Also ELM node is populated in device tree and been used for BCH error correction in NAND flash part. Also this patch series ensures RBL ecc layout maintained in Linux kernel with BCH8 ecc scheme. This patch series based on [1] and depends on [2] & [3]. 1. http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=tree;h=refs/heads/for_3.9/dts;hb=refs/heads/for_3.9/dts 2. OMAP GPMC DT bindings http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/omap-for-v3.9/gpmc 3. mtd: nand: OMAP: ELM error correction support for BCH ecc http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/shortlog/refs/heads/master Philip Avinash (1): ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm Philip, Avinash (2): ARM: dts: AM33XX: Add ELM node ARM: dts: AM33XX: Add GPMC node arch/arm/boot/dts/am335x-evm.dts | 93 +- arch/arm/boot/dts/am33xx.dtsi| 18 2 files changed, 110 insertions(+), 1 deletion(-) -- 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 PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type
Hi, On Thursday 17 January 2013 09:37 PM, Roger Quadros wrote: On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote: In order to add support for multipe PHY's of the same type, the API's for adding PHY and getting PHY has been changed. Now the binding information of the PHY and controller should be done in platform file using usb_bind_phy API. And for getting a PHY, the device pointer of the USB controller and an index should be passed. Based on the binding information that is added in the platform file, get_phy will return the approappropriate PHY. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-shmobile/board-marzen.c |2 +- drivers/power/ab8500_charger.c|2 +- drivers/power/isp1704_charger.c |2 +- drivers/power/pda_power.c |2 +- drivers/power/twl4030_charger.c |2 +- drivers/usb/chipidea/udc.c|2 +- drivers/usb/dwc3/core.c |4 +- drivers/usb/gadget/fsl_udc_core.c |2 +- drivers/usb/gadget/mv_udc_core.c |2 +- drivers/usb/gadget/omap_udc.c |2 +- drivers/usb/gadget/pxa25x_udc.c |2 +- drivers/usb/gadget/pxa27x_udc.c |2 +- drivers/usb/gadget/s3c-hsudc.c|2 +- drivers/usb/host/ehci-fsl.c |2 +- drivers/usb/host/ehci-msm.c |2 +- drivers/usb/host/ehci-mv.c|2 +- drivers/usb/host/ehci-tegra.c |2 +- drivers/usb/host/ohci-omap.c |2 +- drivers/usb/musb/am35x.c |2 +- drivers/usb/musb/blackfin.c |2 +- drivers/usb/musb/da8xx.c |2 +- drivers/usb/musb/davinci.c|2 +- drivers/usb/musb/musb_dsps.c |2 +- drivers/usb/musb/omap2430.c |2 +- drivers/usb/musb/tusb6010.c |2 +- drivers/usb/musb/ux500.c |2 +- drivers/usb/otg/ab8500-usb.c |3 +- drivers/usb/otg/fsl_otg.c |5 ++- drivers/usb/otg/gpio_vbus.c |3 +- drivers/usb/otg/isp1301_omap.c|3 +- drivers/usb/otg/msm_otg.c |3 +- drivers/usb/otg/mv_otg.c |3 +- drivers/usb/otg/nop-usb-xceiv.c |3 +- drivers/usb/otg/otg.c | 67 +++-- drivers/usb/otg/twl4030-usb.c |3 +- drivers/usb/phy/mv_u3d_phy.c |3 +- drivers/usb/phy/omap-usb2.c | 11 ++ drivers/usb/phy/rcar-phy.c|3 +- include/linux/usb/phy.h | 12 +++--- 39 files changed, 87 insertions(+), 89 deletions(-) I think it better to leave the existing add/get APIs as they are add add new APIs that support multiple PHYs. You could probably mark the old ones as deprecated. That way you don't need to wait till all users are converted and tested. Makes sense. Will do that :-) Thanks Kishon -- 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 v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On Friday 18 January 2013 12:15 AM, Jon Hunter wrote:
On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Vaibhav Hiremath
Cc: Jon Hunter
---
v1->v2:
Get rid of harcoded timer id.
Note: since a platform device is not created for these timer
instances and because there's very minimal change needed for
restarting the timer a full blown context save and restore
has been skipped.
arch/arm/mach-omap2/timer.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..38f9cbc 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, "timer%d", clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ __omap_dm_timer_stop(&clkev, 1, clkev.rate);
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, "timer%d", clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_load_start(&clkev,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
hooks.
Jon, Any alternatives you can think of ?
Jon,
Any suggestions here?
Sorry completed this missed this!
Unfortunately, I don't have any good suggestions here. However, I am
wondering if the suspend/resume handlers can just be calls to
omap_hwmod_idle/enable and we can remove these __omap_dm_timer_
calls (I don't think they are needed). Furthermore, my understanding is
this is only needed for AM335x (per the changelog), and so we should not
add suspend/resume handlers for all OMAP2+ based devices.
I agree with the direction.
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: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard This implementation looks fine. Acked-by: Mugunthan V N 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
[PATCH] ARM: OMAP: gpmc: Add device tree documentation for elm handle
In case ELM module available, omap2 NAND driver can opt for hardware
correction method for bit flip errors in NAND flash with BCH. Hence the
detection of ELM module is done through devicetree population of elm_id.
This patch update device tree documentation for gpmc-nand for elm-id
data population.
Signed-off-by: Philip Avinash
---
This patch based [1] and depends on [2]. As Artem suggested, this patch can
go in omap_tree due to the dependency on [3].
Discussion can found at [4]
Tony,
Can you accept this patch.
1.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=shortlog;h=refs/heads/omap-for-v3.9/gpmc
2. mtd: nand: omap2: Support for hardware BCH error correction
http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/576daed18c3f27bb5d0e57e1df11e8f7b493dce8
3. ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0
4. https://lkml.org/lkml/2013/1/17/167
.../devicetree/bindings/mtd/gpmc-nand.txt |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 9f464f9..e7f8d7e 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -29,6 +29,9 @@ Optional properties:
"bch4" 4-bit BCH ecc code
"bch8" 8-bit BCH ecc code
+ - elm_id: Specifies elm device node. This is required to support BCH
+ error correction using ELM module.
+
For inline partiton table parsing (optional):
- #address-cells: should be set to 1
@@ -46,6 +49,7 @@ Example for an AM33xx board:
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x0800 0x2000>; /* CS0: NAND */
+ elm_id = <&elm>;
nand@0,0 {
reg = <0 0 0>; /* CS0, offset 0 */
--
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 v2 2/2] pwm: pwm-tiecap: Low power sleep support
On Thu, Jan 17, 2013 at 21:29:14, Thierry Reding wrote: > On Thu, Jan 17, 2013 at 02:50:03PM +0530, Philip Avinash wrote: > > In low power modes of AM33XX platforms, peripherals power is cut off. > > This patch supports low power sleep transition support for ECAP driver. > > > > Signed-off-by: Philip Avinash > > --- > > Changes since v1: > > - check the enabled status of pwm device for handling module > > enable/disable on resume/suspend > > > > drivers/pwm/pwm-tiecap.c | 53 > > ++ > > 1 file changed, 53 insertions(+) > > Applied, thanks. Thanks for applying this patch Avinash > > Thierry > -- 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 1/2] pwm: pwm-tiehrpwm: Low power sleep support
On Thu, Jan 17, 2013 at 21:29:04, Thierry Reding wrote: > On Thu, Jan 17, 2013 at 02:50:02PM +0530, Philip Avinash wrote: > > In low power modes of AM33XX platforms, peripherals power is cut off. > > This patch supports low power sleep transition support for EHRPWM > > driver. > > > > Signed-off-by: Philip Avinash > > --- > > Changes since v1: > > - check the enabled status of pwm device for handling module > > enable/disable on resume/suspend > > > > drivers/pwm/pwm-tiehrpwm.c | 83 > > > > 1 file changed, 83 insertions(+) > > Applied, thanks. Thanks for applying this patch Avinash > > Thierry > -- 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] pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
On Thu, Jan 17, 2013 at 21:22:18, Thierry Reding wrote: > On Thu, Jan 10, 2013 at 06:35:26PM +0530, Philip Avinash wrote: > > From: "Philip, Avinash" > > > > The clock framework has changed and it's now better to invoke > > clock_prepare_enable() and clk_disable_unprepare() rather than the > > legacy clk_enable() and clk_disable() calls. This patch converts the > > pwm-tiehrpwm driver to the new framework. > > > > Signed-off-by: Philip Avinash > > --- > > Changes Since v1: > > - Check the return value of TBCLK enable in .pwm_enable() > > > > In 3.8-rc1, common clock frame work support added to AM335x. > > > > drivers/pwm/pwm-tiehrpwm.c | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > I had applied this to my for-next branch, but reading the commit message > again it would seem that this should actually go into 3.8, right? Common clock framework support added for am335x in 3.8 only, still EHRPWM tbclk not present in clock tree. I expect this to be in 3.9. So this patch also requires to be in 3.9 only. Thanks Avinash > > Thierry > -- 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 v4 0/3] mtd: nand: OMAP: ELM error correction support for BCH ecc
On Thu, Jan 17, 2013 at 17:36:15, Artem Bityutskiy wrote:
> On Wed, 2013-01-16 at 12:22 +, Philip, Avinash wrote:
> > > This series is based on linux 3.8-rc2 and tested with [1].
> > > Also this patch series depend on [1] for NAND flash device
> > > tree data and gpmc nand device tree binding documentation updates.
> > >
> > > 1. [PATCH v7 0/5] OMAP GPMC DT bindings
> > > http://www.spinics.net/lists/linux-omap/msg83505.html
> > >
> > > Tested on am335x-evm for BCH 4 and 8 bit error correction.
> >
> > Can you apply this patch series on l2-mtd tree as it will help RBL
> > compatibility
> > ecc layout for NAND flash in am335x-platforms and hardware based BCH error
> > correction.
>
> OK, I've applied them. I dropped the part that updates the
> documentation. Please, handle it separately when Daniel's patches are
> in.
>
> Pushed to l2-mtd.git, thanks!
Thanks for applying this patch series.
I will update gpmc-nand documentation part in a separate patch.
Thanks,
Avinash
>
> --
> Best Regards,
> Artem Bityutskiy
>
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH 0/5] staging: tidspbridge: for 3.9
* Greg Kroah-Hartman [130117 16:51]: > On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: > > Patches for staging-next, fixing comments and suggestions provided > > by Chen Gang. > > > > There is an additional scm patch, that removes hardcoded defines > > related to direct register handling for SCM, it was dependent on > > changes that already made it to mainline. > > What is the status on getting this out of the staging tree? What needs > to be done still? Omar, please correct me if I'm wrong. This thing should be reimplemented using remoteproc AFAIK. But I doubt that anybody is working on making it happen? 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 0/5] staging: tidspbridge: for 3.9
On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: > Patches for staging-next, fixing comments and suggestions provided > by Chen Gang. > > There is an additional scm patch, that removes hardcoded defines > related to direct register handling for SCM, it was dependent on > changes that already made it to mainline. What is the status on getting this out of the staging tree? What needs to be done still? thanks, greg k-h -- 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: Fix missing omap2xxx_clkt_vps_xxx function calls
Here's the updated version (at the bottom of this message). Seems to work based on a quick test on 2430SDP. # shutdown -r -n now shutdown: sending all processes the TERM signal... shutdown: sending all processes the KILL signal. shutdown: turning off swap shutdown: unmounting all file systems umount: /debug: not mounted umount: /run/shm: not mounted umount: /dev: not mounted umount: /tmp: not mounted umount: /run/lock: not mounted umount: /run: not mounted umount: /lib/init/rw: not found Please stand by while rebooting the system. [ 79.635925] Disabling non-boot CPUs ... [ 79.640197] Restarting system. U-Boot 1.1.4 (Mar 18 2007 - 12:22:00) OMAP2430C-GP revision 3, PRCM #5A TI 2430SDP 1.1 Version + mDDR (Boot NOR) DRAM: 128 MB Flash: 192 MB NAND:64 MB In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 ... etc. ... - Paul From: Jon Hunter Date: Thu, 10 Jan 2013 14:53:29 -0600 Subject: [PATCH] ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls During the migration to the common clock framework, calls to the functions omap2xxx_clkt_vps_late_init() were not preserved for OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the following error message to be displayed because the appropriate MPU clock frequency (derived from sys_ck_rate) cannot be found. "Could not set MPU rate to 4294MHz" Fix this by adding back calls to omap2xxx_clkt_vps_late_init() in the OMAP2420 and OMAP2430 clock initialisation code. Signed-off-by: Jon Hunter [p...@pwsan.com: dropped the duplicated call to omap2xxx_clkt_vps_check_bootloader_rates() after consultation with Jon; updated patch description] Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/cclock2420_data.c |2 ++ arch/arm/mach-omap2/cclock2430_data.c |2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-omap2/cclock2420_data.c index 7e5febe..ab7e952 100644 --- a/arch/arm/mach-omap2/cclock2420_data.c +++ b/arch/arm/mach-omap2/cclock2420_data.c @@ -1935,6 +1935,8 @@ int __init omap2420_clk_init(void) omap2_init_clk_hw_omap_clocks(c->lk.clk); } + omap2xxx_clkt_vps_late_init(); + omap2_clk_disable_autoidle_all(); omap2_clk_enable_init_clocks(enable_init_clks, diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-omap2/cclock2430_data.c index eda079b..eb3dab6 100644 --- a/arch/arm/mach-omap2/cclock2430_data.c +++ b/arch/arm/mach-omap2/cclock2430_data.c @@ -2050,6 +2050,8 @@ int __init omap2430_clk_init(void) omap2_init_clk_hw_omap_clocks(c->lk.clk); } + omap2xxx_clkt_vps_late_init(); + omap2_clk_disable_autoidle_all(); omap2_clk_enable_init_clocks(enable_init_clks, -- 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 v2]] OMAP: omap4-panda: add WiLink shared transport power functions
* Luciano Coelho [130117 10:04]: > Hi Tony, > > On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote: > > * Peter Ujfalusi [130117 02:44]: > > > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > > > This out-of-tree code doesn't explain why we need to do the > > > > enable/disable in the board file. We just need to do things a bit > > > > differently in the driver. I'll start cleaning all this stuff up for > > > > -next pretty soon. > > > > > > > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so > > > > that TI-ST at least works on Panda? Simply reverting the gpio removal > > > > patch doesn't help, because we also need to handle the UART2 muxing > > > > (which my patch does as well). > > > > > > I don't see better way to fix this either. In any case, I give you my: > > > > > > Reviewed-by: Peter Ujfalusi > > > > So what is actually broken? The horrible bluetooth muxing over serial > > port? If so, let's rather fix it properly than even attempt to fix > > it as it seems that it's been broken for two merge windows now. > > Yes, it is the horrible Bluetooth muxing over serial that is broken. It > has been broken for two merge windows, because nobody seemed to care > until I started looking into it and tried to figure out how to get it to > work. :) Heh I see. > The implementation is really weak and there are loads of things I want > to start fixing/cleaning up. This patch was just my intention to start > with a relatively clean table (ie. horrible or not, at least working). > > > > Also, let's just do absolutely minimal board-*.c file fixes now. > > This thing should be just moved to use DT so we can flip over omap4 > > to be DT only and drop estimated 5k LOC from mach-omap2. > > I totally agree, I'll start looking into that next. > > But this patch is pretty small and simple, so why not include it to at > least fix the breakage in 3.7 and 3.8? Whether you take it or not now > won't make any difference in the 5k LOC in these kernel versions. Well we are planning to drop the non-DT support for omap4 as soon as it's usable with DT. For omap4 we are only carrying SDP and panda support to make this transition easier. The only bindings missing AFAIK are wl12xx and USB. If we add this, then it implies we're somehow supporting it, which is not the way to go IMHO as we need to get rid of these platform callbacks instead. What's your estimate of having minimal wl12xx WLAN DT binding available? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
On Thu, Jan 17, 2013 at 07:21:42PM +, Paul Walmsley wrote: > Hi Mark > > On Tue, 8 Jan 2013, Mark A. Greer wrote: > > > Sorry to nag but I think the comment needs to be updated to remove the > > sentence about the missing EMAC hwmod. > > You are absolutely right, and the correction is very much appreciated. > Updated patch follows. > > > - Paul > > From: Paul Walmsley > Date: Sun, 30 Dec 2012 10:36:36 -0700 > Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active > > According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable > to wake the ARM up from WFI: > > http://www.spinics.net/lists/arm-kernel/msg174734.html > > Further troubleshooting was unable to narrow the problem down. So we > don't have much choice other than to block WFI when the EMAC is active > with the HWMOD_BLOCK_WFI flag. > > Based on Mark's original patch. We're removing the omap_device-based > pm_lats code, so a different approach was needed. > > This third version contains some corrections thanks to Mark's review. > > Signed-off-by: Paul Walmsley > Cc: Mark A. Greer > --- FWIW, Acked-by: Mark A. Greer -- 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 00/15] OMAP SHAM & AES Crypto Updates
On Thu, Jan 17, 2013 at 07:13:36PM +, Paul Walmsley wrote:
> Hi Mark,
Hi Paul.
> I regret the delay,
>
> On Tue, 8 Jan 2013, Mark A. Greer wrote:
>
> > On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote:
> >
> > > - The patch series causes AM3517/3505 to crash. I'd guess this is due to
> > > the SHAM/AES modules being initialized on those chips, but they probably
> > > don't exist there. Can you change the initialization for those on OMAP3
> > > to only take place on OMAP34xx/36xx GP? I guess you'd need to create new
> > > lists for those in the hwmod init.
> >
> > All am35xx GPs have the SHAM and AES modules except some very old ones.
> > I've been told that there should be very few of the "old" ones around
> > (I don't know how to differentiate them). We're likely safe since the
> > SHAM & AES modules are not enabled in omap2plus_defconfig so nobody
> > should be enabling them on an am35xx unless they know that they have
> > the modules. Do you agree?
>
> Those will presumably only enable or disable the device drivers. The
> hwmod code will probably still try to write to those IP blocks if they are
> listed as present in the hwmod data, during the initial reset-and-idle
> phase.
Um, yeah, good point. :)
> What do you think about adding an am35xx_es11plus_hwmod_ocp_ifs[] array to
> omap_hwmod_3xxx_data.c for these secure hwmods? That carries the implicit
> and possibly wrong assumption that it's likely to be ES1.0 devices that
> are missing the SHAM/AES, but it seems unlikely that TI would have
> multiple silicon revs running around claiming to be ES1.1? Or maybe I'm
> just being naïve.
Something like that makes sense to me. I'll re-read my email, etc. and
see if I can find something to help us figure it out.
> > The issue that you're likely running into is that 'CK_AM35XX' needs to be
> > added for aes2_ick & sha12_ick in cclock3xxx_data.c. The following
> > patch should fix it (applies to my submitted/crypto/hwmod branch):
> >
> > diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
> > b/arch/arm/mach-omap2/cclock3xxx_data.c
> > index 582b055..aa5bdf6 100644
> > --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> > @@ -3332,10 +3332,10 @@ static struct omap_clk omap3xxx_clks[] = {
> > CLK("omap_hsmmc.2", "ick", &mmchs3_ick,CK_3430ES2PLUS |
> > CK_AM35XX | CK_36XX),
> > CLK(NULL, "mmchs3_ick", &mmchs3_ick,CK_3430ES2PLUS |
> > CK_AM35XX | CK_36XX),
> > CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> > - CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_36XX),
> > - CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_36XX),
> > - CLK("omap-sham","ick", &sha12_ick, CK_34XX | CK_36XX),
> > - CLK(NULL, "sha12_ick",&sha12_ick, CK_34XX | CK_36XX),
> > + CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_AM35XX |
> > CK_36XX),
> > + CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_AM35XX |
> > CK_36XX),
> > + CLK("omap-sham","ick", &sha12_ick, CK_34XX | CK_AM35XX |
> > CK_36XX),
> > + CLK(NULL, "sha12_ick",&sha12_ick, CK_34XX | CK_AM35XX |
> > CK_36XX),
> > CLK(NULL, "des2_ick", &des2_ick, CK_34XX | CK_36XX),
> > CLK("omap_hsmmc.1", "ick", &mmchs2_ick,CK_3XXX),
> > CLK("omap_hsmmc.0", "ick", &mmchs1_ick,CK_3XXX),
> >
> >
> > Please let me know if this patch works for you and, if it does, I'll respin
> > my patches to add those changes.
>
> If those clocks are referenced by the hwmods, that that patch makes sense
> to me. Haven't had the chance to test it yet but maybe tomorrow. On the
> other hand it looks 'obviously correct' so maybe just add that change to
> your patches and repost that one?
Will do.
Mark
--
--
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: Fix missing omap2xxx_clkt_vps_xxx function calls
Hi Jon, On Thu, 17 Jan 2013, Jon Hunter wrote: > Yes I still see it. You don't see it on reboot? Ah that's probably explains the discrepancy - I missed the part about the reboot. > The reason why there is such a large number is because > omap2_round_to_table_rate() is returning the value -EINVAL. You could > add a print to omap2_round_to_table_rate() to see what it returns on > reboot. Or we could add a WARN to the function is sys_ck_rate is 0 for > testing. > > > Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates() > > -- is it necessary to add another one? > > Thanks. I see that now and so that is not needed then. OK, I'll queue your patch for 3.8-rc fixes, dropping the omap2xxx_clkt_vps_check_bootloader_rates() calls. - 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] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
> "Tony" == Tony Lindgren writes: Hi, >> The way I've handled it is similar to how it is done on atleast one >> other arm subarchicture, see >> arch/arm/mach-mxs/mach-mxs.c::update_fec_mac_prop() Tony> Cool this seems like the cleanest way to deal with it so far. Can Tony> you please resend with also linux-net and DT list Cc:d too? Tony> Also the arch_initcall should be omap_arch_initcall in linux next Tony> for consistency if we ever have SoC specific sections for those. Sure, resent with the initcall change and netdev/devicetree-discuss added. -- Bye, Peter Korsgaard -- 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] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.
The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.
Signed-off-by: Peter Korsgaard
---
Changes since v1:
- Use omap_arch_initcall as pointed out by Tony
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/am33xx-cpsw.c | 94 +
arch/arm/mach-omap2/control.h |4 ++
3 files changed, 101 insertions(+)
create mode 100644 arch/arm/mach-omap2/am33xx-cpsw.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 65fb6fb..54fb2ee 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -298,4 +298,7 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
+cpsw-$(CONFIG_TI_CPSW) := am33xx-cpsw.o
+obj-y += $(cpsw-m) $(cpsw-y)
+
obj-y += common-board-devices.o twl-common.o
dss-common.o
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c
b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 000..eec29a4
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "soc.h"
+#include "control.h"
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np:Pointer to the cpsw slave to set mac address of
+ * @idx: Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int idx)
+{
+ struct property *prop;
+ u32 lo, hi;
+ u8 *mac;
+
+ switch (idx) {
+ case 0:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+ break;
+
+ case 1:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+ break;
+
+ default:
+ pr_err("cpsw.%d: too many slaves found\n", idx);
+ return;
+ }
+
+ prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop->value = prop + 1;
+ prop->length = ETH_ALEN;
+ prop->name = kstrdup("mac-address", GFP_KERNEL);
+ if (!prop->name) {
+ kfree(prop);
+ return;
+ }
+
+ mac = prop->value;
+
+ mac[0] = hi;
+ mac[1] = hi >> 8;
+ mac[2] = hi >> 16;
+ mac[3] = hi >> 24;
+ mac[4] = lo;
+ mac[5] = lo >> 8;
+
+ of_update_property(np, prop);
+
+ pr_info("cpsw.%d: No hwaddr in dt. Using %pM from efuse\n", idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+ struct device_node *np, *slave;
+ int idx = 0;
+
+ if (!soc_is_am33xx())
+ return -ENODEV;
+
+ for_each_compatible_node(np, NULL, "ti,cpsw")
+ for_each_node_by_name(slave, "slave") {
+ if (!of_get_mac_address(slave))
+ am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+ idx++;
+ }
+
+ return 0;
+}
+omap_arch_initcall(am33xx_dt_cpsw_mac_fixup);
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..266d512 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -352,6 +352,10 @@
/* AM33XX CONTROL_STATUS register */
#define AM33XX_CONTROL_STATUS 0x040
#define AM33XX_CONTROL_SEC_CLK_CTRL0x1bc
+#define AM33XX_CONTROL_MAC_ID0_LOW 0x630
+#define AM33XX_CONTROL_MAC_ID0_HIGH0x634
+#define AM33XX_CONTROL_MAC_ID1_LOW 0x638
+#define AM33XX_CONTROL_MAC_ID1_HIGH0x63c
/* AM33XX CONTROL_STATUS bitfields (partial) */
#define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT 22
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscri
Re: Help wanted with USB and OMAP3 off_mode
On Thu, 17 Jan 2013 13:29:07 +0200 Roger Quadros wrote: > On 01/17/2013 01:01 PM, NeilBrown wrote: > > On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros wrote: > > > >> On 01/16/2013 12:27 PM, NeilBrown wrote: > >>> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros wrote: > >>> > On 01/09/2013 12:29 AM, NeilBrown wrote: > > > > Hi, > > I'm trying to get off_mode working reliably on my gta04 mobile phone. > > > > My current stumbling block is USB. The "Option" GSM module is attached > > via > > USB (there is a separate transceiver chip attached to port 1 which is > > placed > > in OMAP_EHCI_PORT_MODE_PHY). > > > > After a suspend/resume cycle with off_mode enabled the GSM module > > disappears. > > i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices > > don't > > exist. > > Without off mode, the modem always appears after resume. > > > > I discovered that the registers set by: > > > >drivers/mfd/omap-usb-host.c > > > > are not maintained across as suspend/resume so I added the following > > patch > > (which I can make a formal submission of if it looks right to others), > > but > > that didn't help (or didn't help enough). > > > > If I > > > > echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend > > > > thus keeping just the USBHOST power domain out of off_mode, the GSM > > module > > doesn't disappear. So it seems that some context in the usbhost domain > > is > > not being save and restored. > > > > This is as far as I can get. Can someone suggest where I should look > > to find > > out what is not being saved/restored properly, and how to go about > > saving and > > restoring? > > You need to ensure that USBHOST/TLL context is saved as per the Save and > Restore sequence see section "USBHOST/USBTLL Save-and-Restore > Management" in the OMAP Technical Reference Manual. > > The basic idea there is that software does the context saving into SAR > RAM before entering OFF mode and hardware automatically restores the > context after coming out of OFF mode. > >>> > >>> Is it? The way I read the doco, the hardware both saves to SAR RAM, and > >>> restores from SAR RAM. > >>> Section 22.2.4.1.6 Save and Restore > >>> of my copy of the TRM says: > >>> > The save-and-restore (SAR) mechanism can extract the hardware context of > the high-speed USB host > controller (after all USB activity has been suspended) before switching > off (=save), save it to an external > always-on memory, and reinject it later after the module has been > switched on again and reset (=restore) > seamlessly for the USB. Part of that context is composed of the register > fields described in the current > chapter. The rest of the context is composed of the "buried" flip-flops > and memories (not accessible by > software) like finite state-machine (FSM) states, buffer contents, and > miscellaneous random logic bits. > >>> > >>> which strongly suggests that it is all handled by hardware. Of course > >>> there > >>> are other registers that aren't covered by the SAR - we need to identify > >>> those and make sure they are saved and restored. I've found a few > >>> registers > >>> that aren't being restored, but restoring them hasn't made a visible > >>> difference yet. > >> > >> Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. > >> But still, software needs to ensure that the USBHOST and CORE power > >> domain's SAVEANDRESTORE bit are set to ensure that SAR works. > >> > >> see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management" > >> > >> This seems to be done by the powerdomain code based on the > >> PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST > >> powerdomain with the following comment. > >> > >>> Both USBHOST and USBTLL support a save-and-restore mechanism. When the > >>> device enters into off > >>> mode (that is, all power domains, except the WKUP power domain, are off), > >>> the user may want to save > >>> the USBHOST context and restore it when exiting off mode. The > >>> save-and-restore mechanism for the HS > >>> USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] > >>> SAVEANDRESTORE bit; for > >>> the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] > >>> SAVEANDRESTORE bit. The save > >>> mechanism is initiated as the power domain transitions from active to off > >>> state (or to OSWR state for the > >>> USBTLL), whereas the restore mechanism is initiated as the power domain > >>> transitions from off to active > >>> power state. > >> > >> Can you try with the flag enabled? > > > > If I keep CORE and USBHOST out of off-mode (by writing to the relevant > > 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. > > > > If
Re: [PATCH] ARM: OMAP2: Fix missing omap2xxx_clkt_vps_xxx function calls
Hi Paul, On 01/17/2013 12:51 PM, Paul Walmsley wrote: > Hi Jon > > On Thu, 10 Jan 2013, Jon Hunter wrote: > >> During the migration to the common clock framework, calls to the >> functions omap2xxx_clkt_vps_late_init() and >> omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for >> OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and >> "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the >> following error message to be displayed because the appropriate MPU >> clock frequency (derived from sys_ck_rate) cannot be found. >> >> "Could not set MPU rate to 4294MHz" > > I don't see this message on 2430sdp or n800 with v3.8-rc3, but maybe > that's due to sys_clk differences. Do you still see this on v3.8-rc3 > with H4? Yes I still see it. You don't see it on reboot? The reason why there is such a large number is because omap2_round_to_table_rate() is returning the value -EINVAL. You could add a print to omap2_round_to_table_rate() to see what it returns on reboot. Or we could add a WARN to the function is sys_ck_rate is 0 for testing. > Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates() > -- is it necessary to add another one? Thanks. I see that now and so that is not needed then. Cheers Jon -- 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: OMAP AM3517/05: hwmod data: block WFI when EMAC active
Hi Mark
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> Sorry to nag but I think the comment needs to be updated to remove the
> sentence about the missing EMAC hwmod.
You are absolutely right, and the correction is very much appreciated.
Updated patch follows.
- Paul
From: Paul Walmsley
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:
http://www.spinics.net/lists/arm-kernel/msg174734.html
Further troubleshooting was unable to narrow the problem down. So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.
Based on Mark's original patch. We're removing the omap_device-based
pm_lats code, so a different approach was needed.
This third version contains some corrections thanks to Mark's review.
Signed-off-by: Paul Walmsley
Cc: Mark A. Greer
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8bb2628..ac7e03e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3493,7 +3493,12 @@ static struct omap_hwmod am35xx_emac_hwmod = {
.name = "davinci_emac",
.mpu_irqs = am35xx_emac_mpu_irqs,
.class = &am35xx_emac_class,
- .flags = HWMOD_NO_IDLEST,
+ /*
+* According to Mark Greer, the MPU will not return from WFI
+* when the EMAC signals an interrupt.
+* http://www.spinics.net/lists/arm-kernel/msg174734.html
+*/
+ .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI),
};
/* l3_core -> davinci emac interface */
--
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 00/15] OMAP SHAM & AES Crypto Updates
Hi Mark,
I regret the delay,
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote:
>
> > - The patch series causes AM3517/3505 to crash. I'd guess this is due to
> > the SHAM/AES modules being initialized on those chips, but they probably
> > don't exist there. Can you change the initialization for those on OMAP3
> > to only take place on OMAP34xx/36xx GP? I guess you'd need to create new
> > lists for those in the hwmod init.
>
> All am35xx GPs have the SHAM and AES modules except some very old ones.
> I've been told that there should be very few of the "old" ones around
> (I don't know how to differentiate them). We're likely safe since the
> SHAM & AES modules are not enabled in omap2plus_defconfig so nobody
> should be enabling them on an am35xx unless they know that they have
> the modules. Do you agree?
Those will presumably only enable or disable the device drivers. The
hwmod code will probably still try to write to those IP blocks if they are
listed as present in the hwmod data, during the initial reset-and-idle
phase.
What do you think about adding an am35xx_es11plus_hwmod_ocp_ifs[] array to
omap_hwmod_3xxx_data.c for these secure hwmods? That carries the implicit
and possibly wrong assumption that it's likely to be ES1.0 devices that
are missing the SHAM/AES, but it seems unlikely that TI would have
multiple silicon revs running around claiming to be ES1.1? Or maybe I'm
just being naïve.
> The issue that you're likely running into is that 'CK_AM35XX' needs to be
> added for aes2_ick & sha12_ick in cclock3xxx_data.c. The following
> patch should fix it (applies to my submitted/crypto/hwmod branch):
>
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
> b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 582b055..aa5bdf6 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3332,10 +3332,10 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK("omap_hsmmc.2", "ick", &mmchs3_ick,CK_3430ES2PLUS |
> CK_AM35XX | CK_36XX),
> CLK(NULL, "mmchs3_ick", &mmchs3_ick,CK_3430ES2PLUS |
> CK_AM35XX | CK_36XX),
> CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> - CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_36XX),
> - CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_36XX),
> - CLK("omap-sham","ick", &sha12_ick, CK_34XX | CK_36XX),
> - CLK(NULL, "sha12_ick",&sha12_ick, CK_34XX | CK_36XX),
> + CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_AM35XX |
> CK_36XX),
> + CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_AM35XX |
> CK_36XX),
> + CLK("omap-sham","ick", &sha12_ick, CK_34XX | CK_AM35XX |
> CK_36XX),
> + CLK(NULL, "sha12_ick",&sha12_ick, CK_34XX | CK_AM35XX |
> CK_36XX),
> CLK(NULL, "des2_ick", &des2_ick, CK_34XX | CK_36XX),
> CLK("omap_hsmmc.1", "ick", &mmchs2_ick,CK_3XXX),
> CLK("omap_hsmmc.0", "ick", &mmchs1_ick,CK_3XXX),
>
>
> Please let me know if this patch works for you and, if it does, I'll respin
> my patches to add those changes.
If those clocks are referenced by the hwmods, that that patch makes sense
to me. Haven't had the chance to test it yet but maybe tomorrow. On the
other hand it looks 'obviously correct' so maybe just add that change to
your patches and repost that one?
- Paul
Re: [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> AM33XX has two timers (DTIMER0/1) in the WKUP domain.
> On GP devices the source of DMTIMER0 is fixed to an
> inaccurate internal 32k RC oscillator and this makes
> the DMTIMER0 practically either as a clocksource or
> as clockevent.
>
> Currently the timer instance in WKUP domain is used
> as the clockevent and the timer in non-WKUP domain
> as the clocksource. DMTIMER1 in WKUP domain can keep
> running in suspend from a 32K clock fed from external
> OSC and can serve as the persistent clock for the kernel.
> To enable this, interchange the timers used as clocksource
> and clockevent for AM33XX.
>
> For now a new DT property has been added to allow the timer code
> to select the timer with the right property.
>
> It has been pointed out by Santosh Shilimkar and Kevin Hilman
> that such a change will result in soc-idle never being achieved
> on AM33XX. There are other reasons why soc-idle does not look
> feasible on AM33XX so for now we go ahead with the interchange
> of the the timers. If at a later point of time we do come up
> with an approach which makes soc-idle possible on AM33XX, this
> can be revisited.
>
> Signed-off-by: Vaibhav Bedia
> Signed-off-by: Vaibhav Hiremath
> Cc: Tony Lingren
> Cc: Santosh Shilimkar
> Cc: Benoit Cousson
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Jon Hunter
>
> ---
> v1->v2:
> Use DT properties for changing the timers
>
> .../devicetree/bindings/arm/omap/timer.txt |2 ++
> arch/arm/boot/dts/am33xx.dtsi |1 +
> arch/arm/mach-omap2/timer.c|6 +++---
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> index 8732d4d..62d4f2c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -18,6 +18,8 @@ Optional properties:
> - ti,timer-pwm: Indicates the timer can generate a PWM output.
> - ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> and therefore cannot be used by the kernel.
> +- ti,timer-non-wkup Indicates the timer is in non-wkup power domain and
> hence
> + will lose register context when the power domain
> transitions
I was hoping that we could avoid adding another property, especially
given that his equivalent to a timer that does not have the
"ti,timer-alwon" property.
> Example:
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4731748..b4e8bf7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -251,6 +251,7 @@
> reg = <0x4804 0x400>;
> interrupts = <68>;
> ti,hwmods = "timer2";
> + ti,timer-non-wkup;
Is this is only one not in the wake-up domain?
> };
>
> timer3: timer@48042000 {
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 38f9cbc..cfb3413 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -264,7 +264,7 @@ static int __init omap_dm_timer_init_one(struct
> omap_dm_timer *timer,
> int r = 0;
>
> if (of_have_populated_dt()) {
> - np = omap_get_timer_dt(omap_timer_match, NULL);
> + np = omap_get_timer_dt(omap_timer_match, property);
> if (!np)
> return -ENODEV;
>
> @@ -633,8 +633,8 @@ OMAP_SYS_TIMER(3_gp, gptimer);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> #ifdef CONFIG_SOC_AM33XX
> -OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
> -2, OMAP4_MPU_SOURCE);
> +OMAP_SYS_GP_TIMER_INIT(3_am33xx, 2, OMAP4_MPU_SOURCE, "ti,timer-non-wkup",
> +1, OMAP4_MPU_SOURCE);
It seems to me here that we should specify the property "ti,timer-alwon"
for the clocksource and then no property for the clockevent. Hence, may
be the code needs to be adjusted so that if clockevent or clocksource
can use any timer (ie. no property specified), we look for a timer that
has no "ti-timer-" properties. This will ensure that if we need a
particular timer for clocksource, which we look for after clockevent, it
will be available.
Cheers
Jon
--
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: Fix missing omap2xxx_clkt_vps_xxx function calls
Hi Jon On Thu, 10 Jan 2013, Jon Hunter wrote: > During the migration to the common clock framework, calls to the > functions omap2xxx_clkt_vps_late_init() and > omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for > OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and > "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the > following error message to be displayed because the appropriate MPU > clock frequency (derived from sys_ck_rate) cannot be found. > > "Could not set MPU rate to 4294MHz" I don't see this message on 2430sdp or n800 with v3.8-rc3, but maybe that's due to sys_clk differences. Do you still see this on v3.8-rc3 with H4? Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates() -- is it necessary to add another one? - 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: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
> On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
>> On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
>>> The current OMAP timer code registers two timers -
>>> one as clocksource and one as clockevent.
>>> AM33XX has only one usable timer in the WKUP domain
>>> so one of the timers needs suspend-resume support
>>> to restore the configuration to pre-suspend state.
>>>
>>> commit adc78e6 (timekeeping: Add suspend and resume
>>> of clock event devices) introduced .suspend and .resume
>>> callbacks for clock event devices. Leverages these
>>> callbacks to have AM33XX clockevent timer which is
>>> in not in WKUP domain to behave properly across system
>>> suspend.
>>>
>>> Signed-off-by: Vaibhav Bedia
>>> Cc: Santosh Shilimkar
>>> Cc: Benoit Cousson
>>> Cc: Paul Walmsley
>>> Cc: Kevin Hilman
>>> Cc: Vaibhav Hiremath
>>> Cc: Jon Hunter
>>> ---
>>> v1->v2:
>>> Get rid of harcoded timer id.
>>> Note: since a platform device is not created for these timer
>>> instances and because there's very minimal change needed for
>>> restarting the timer a full blown context save and restore
>>> has been skipped.
>>>
>>> arch/arm/mach-omap2/timer.c | 33 +
>>> 1 files changed, 33 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 691aa67..38f9cbc 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum
>>> clock_event_mode mode,
>>> }
>>> }
>>>
>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
>>> + omap_hwmod_idle(oh);
>>> +}
>>> +
>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + omap_hwmod_enable(oh);
>>> + __omap_dm_timer_load_start(&clkev,
>>> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>> +}
>>> +
>> Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
>> hooks.
>>
>> Jon, Any alternatives you can think of ?
>>
>
> Jon,
>
> Any suggestions here?
Sorry completed this missed this!
Unfortunately, I don't have any good suggestions here. However, I am
wondering if the suspend/resume handlers can just be calls to
omap_hwmod_idle/enable and we can remove these __omap_dm_timer_
calls (I don't think they are needed). Furthermore, my understanding is
this is only needed for AM335x (per the changelog), and so we should not
add suspend/resume handlers for all OMAP2+ based devices.
Cheers
Jon
--
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.8-rc3
Hi Péter, On Tue, 15 Jan 2013, Peter Ujfalusi wrote: > On 01/14/2013 06:59 PM, Paul Walmsley wrote: > > Failing tests: needing investigation > > > > > > Build tests: > > > > * rmk_3430_ldp_allnoconfig, rmk_4430_sdp_allnoconfig: twl4030 build failures > > - in drivers/mfd/twl-core.c > > The following patch fixes these: > https://lkml.org/lkml/2012/12/24/3 Thanks, I've added that info in the v3.8-rc3 test summary, and moved the paragraph to the 'resolved by posted patches' section. - Paul
Re: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> The current OMAP timer code registers two timers -
> one as clocksource and one as clockevent.
> AM33XX has only one usable timer in the WKUP domain
> so one of the timers needs suspend-resume support
> to restore the configuration to pre-suspend state.
>
> commit adc78e6 (timekeeping: Add suspend and resume
> of clock event devices) introduced .suspend and .resume
> callbacks for clock event devices. Leverages these
> callbacks to have AM33XX clockevent timer which is
> in not in WKUP domain to behave properly across system
> suspend.
>
> Signed-off-by: Vaibhav Bedia
> Cc: Santosh Shilimkar
> Cc: Benoit Cousson
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Vaibhav Hiremath
> Cc: Jon Hunter
> ---
> v1->v2:
> Get rid of harcoded timer id.
> Note: since a platform device is not created for these timer
> instances and because there's very minimal change needed for
> restarting the timer a full blown context save and restore
> has been skipped.
>
> arch/arm/mach-omap2/timer.c | 33 +
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..38f9cbc 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum
> clock_event_mode mode,
> }
> }
>
> +static void omap_clkevt_suspend(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
I am not sure you need to call __omap_dm_timer_stop() here. This should
have already been called as timekeeping_suspend() will call
omap2_gp_timer_set_mode() to shutdown the timer.
> + omap_hwmod_idle(oh);
> +}
> +
> +static void omap_clkevt_resume(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + omap_hwmod_enable(oh);
> + __omap_dm_timer_load_start(&clkev,
> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
Similarly here, I am not sure these __omap_dm_timer_ calls are needed.
> +}
> +
> static struct clock_event_device clockevent_gpt = {
> .name = "gp_timer",
> .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> @@ -135,6 +165,8 @@ static struct clock_event_device clockevent_gpt = {
> .rating = 300,
> .set_next_event = omap2_gp_timer_set_next_event,
> .set_mode = omap2_gp_timer_set_mode,
> + .suspend= omap_clkevt_suspend,
> + .resume = omap_clkevt_resume,
AFAIK, this is only applicable for AM335x devices and so should not be
added for all.
> };
>
> static struct property device_disabled = {
> @@ -323,6 +355,7 @@ static void __init omap2_gp_clockevent_init(int
> gptimer_id,
> int res;
>
> clkev.errata = omap_dm_timer_get_errata();
> + clkev.id = gptimer_id;
We should not use gptimer_id anymore. This will go away once the
migration to dev-tree is completed. You may be better off storing the
oh_name in the clock_event_device name field and passing to the
suspend/resume handlers.
Cheers
Jon
--
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.8-rc3
On Mon, 14 Jan 2013, Aaro Koskinen wrote: > N900 boot is unstable again, I2C issues are back. > > Boot succeeds and fails randomly. Let's see if this can be bisected. > The same kernel works on N950. Thanks, I've added a section about this to the v3.8-rc3 test summary. - 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 v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Hi Tony, On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote: > * Peter Ujfalusi [130117 02:44]: > > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > > This out-of-tree code doesn't explain why we need to do the > > > enable/disable in the board file. We just need to do things a bit > > > differently in the driver. I'll start cleaning all this stuff up for > > > -next pretty soon. > > > > > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so > > > that TI-ST at least works on Panda? Simply reverting the gpio removal > > > patch doesn't help, because we also need to handle the UART2 muxing > > > (which my patch does as well). > > > > I don't see better way to fix this either. In any case, I give you my: > > > > Reviewed-by: Peter Ujfalusi > > So what is actually broken? The horrible bluetooth muxing over serial > port? If so, let's rather fix it properly than even attempt to fix > it as it seems that it's been broken for two merge windows now. Yes, it is the horrible Bluetooth muxing over serial that is broken. It has been broken for two merge windows, because nobody seemed to care until I started looking into it and tried to figure out how to get it to work. :) The implementation is really weak and there are loads of things I want to start fixing/cleaning up. This patch was just my intention to start with a relatively clean table (ie. horrible or not, at least working). > Also, let's just do absolutely minimal board-*.c file fixes now. > This thing should be just moved to use DT so we can flip over omap4 > to be DT only and drop estimated 5k LOC from mach-omap2. I totally agree, I'll start looking into that next. But this patch is pretty small and simple, so why not include it to at least fix the breakage in 3.7 and 3.8? Whether you take it or not now won't make any difference in the 5k LOC in these kernel versions. -- Cheers, Luca. -- 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] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
* Peter Korsgaard [130117 08:46]: > > "Michal" == Michal Bachraty writes: > > Hi Michael, > > Michal> I made changes to cpsw driver two weeks ago, which add support > Michal> for reading MAC address from CPU and also I posted it to > Michal> review. You can find patch here : > Michal> https://patchwork.kernel.org/patch/1966481/ I will create > Michal> updated patch next week, depended on reactions. Can you try > Michal> that patch? I'll be glad to hear your opinion. > > Thanks, I missed that patch. Functionality wise the patches do the same, > but I must say I find my patch cleaner, as it doesn't involve any new dt > bindings or access to the am33xx specific control module registers from > the cpsw driver. > > The way I've handled it is similar to how it is done on atleast one > other arm subarchicture, see > arch/arm/mach-mxs/mach-mxs.c::update_fec_mac_prop() Cool this seems like the cleanest way to deal with it so far. Can you please resend with also linux-net and DT list Cc:d too? Also the arch_initcall should be omap_arch_initcall in linux next for consistency if we ever have SoC specific sections for those. 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]] OMAP: omap4-panda: add WiLink shared transport power functions
* Peter Ujfalusi [130117 02:44]: > On 01/17/2013 11:35 AM, Luciano Coelho wrote: > > This out-of-tree code doesn't explain why we need to do the > > enable/disable in the board file. We just need to do things a bit > > differently in the driver. I'll start cleaning all this stuff up for > > -next pretty soon. > > > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so > > that TI-ST at least works on Panda? Simply reverting the gpio removal > > patch doesn't help, because we also need to handle the UART2 muxing > > (which my patch does as well). > > I don't see better way to fix this either. In any case, I give you my: > > Reviewed-by: Peter Ujfalusi So what is actually broken? The horrible bluetooth muxing over serial port? If so, let's rather fix it properly than even attempt to fix it as it seems that it's been broken for two merge windows now. Also, let's just do absolutely minimal board-*.c file fixes now. This thing should be just moved to use DT so we can flip over omap4 to be DT only and drop estimated 5k LOC from mach-omap2. 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] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
> "Michal" == Michal Bachraty writes: Hi Michael, Michal> I made changes to cpsw driver two weeks ago, which add support Michal> for reading MAC address from CPU and also I posted it to Michal> review. You can find patch here : Michal> https://patchwork.kernel.org/patch/1966481/ I will create Michal> updated patch next week, depended on reactions. Can you try Michal> that patch? I'll be glad to hear your opinion. Thanks, I missed that patch. Functionality wise the patches do the same, but I must say I find my patch cleaner, as it doesn't involve any new dt bindings or access to the am33xx specific control module registers from the cpsw driver. The way I've handled it is similar to how it is done on atleast one other arm subarchicture, see arch/arm/mach-mxs/mach-mxs.c::update_fec_mac_prop() -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/6] usb: otg: utils: change the phy lib to support multiple PHYs of same type
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote: > In order to add support for multipe PHY's of the same type, the API's > for adding PHY and getting PHY has been changed. Now the binding > information of the PHY and controller should be done in platform file > using usb_bind_phy API. And for getting a PHY, the device pointer of the > USB controller and an index should be passed. Based on the binding > information that is added in the platform file, get_phy will return the > approappropriate PHY. > > Signed-off-by: Kishon Vijay Abraham I > --- > arch/arm/mach-shmobile/board-marzen.c |2 +- > drivers/power/ab8500_charger.c|2 +- > drivers/power/isp1704_charger.c |2 +- > drivers/power/pda_power.c |2 +- > drivers/power/twl4030_charger.c |2 +- > drivers/usb/chipidea/udc.c|2 +- > drivers/usb/dwc3/core.c |4 +- > drivers/usb/gadget/fsl_udc_core.c |2 +- > drivers/usb/gadget/mv_udc_core.c |2 +- > drivers/usb/gadget/omap_udc.c |2 +- > drivers/usb/gadget/pxa25x_udc.c |2 +- > drivers/usb/gadget/pxa27x_udc.c |2 +- > drivers/usb/gadget/s3c-hsudc.c|2 +- > drivers/usb/host/ehci-fsl.c |2 +- > drivers/usb/host/ehci-msm.c |2 +- > drivers/usb/host/ehci-mv.c|2 +- > drivers/usb/host/ehci-tegra.c |2 +- > drivers/usb/host/ohci-omap.c |2 +- > drivers/usb/musb/am35x.c |2 +- > drivers/usb/musb/blackfin.c |2 +- > drivers/usb/musb/da8xx.c |2 +- > drivers/usb/musb/davinci.c|2 +- > drivers/usb/musb/musb_dsps.c |2 +- > drivers/usb/musb/omap2430.c |2 +- > drivers/usb/musb/tusb6010.c |2 +- > drivers/usb/musb/ux500.c |2 +- > drivers/usb/otg/ab8500-usb.c |3 +- > drivers/usb/otg/fsl_otg.c |5 ++- > drivers/usb/otg/gpio_vbus.c |3 +- > drivers/usb/otg/isp1301_omap.c|3 +- > drivers/usb/otg/msm_otg.c |3 +- > drivers/usb/otg/mv_otg.c |3 +- > drivers/usb/otg/nop-usb-xceiv.c |3 +- > drivers/usb/otg/otg.c | 67 > +++-- > drivers/usb/otg/twl4030-usb.c |3 +- > drivers/usb/phy/mv_u3d_phy.c |3 +- > drivers/usb/phy/omap-usb2.c | 11 ++ > drivers/usb/phy/rcar-phy.c|3 +- > include/linux/usb/phy.h | 12 +++--- > 39 files changed, 87 insertions(+), 89 deletions(-) I think it better to leave the existing add/get APIs as they are add add new APIs that support multiple PHYs. You could probably mark the old ones as deprecated. That way you don't need to wait till all users are converted and tested. e.g. you could name the new APIs as usb_add_phy_dev(struct usb_phy *phy); usb_get_phy_dev(struct device *dev, int index); -- 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
Re: [PATCH v2 2/2] pwm: pwm-tiecap: Low power sleep support
On Thu, Jan 17, 2013 at 02:50:03PM +0530, Philip Avinash wrote: > In low power modes of AM33XX platforms, peripherals power is cut off. > This patch supports low power sleep transition support for ECAP driver. > > Signed-off-by: Philip Avinash > --- > Changes since v1: > - check the enabled status of pwm device for handling module > enable/disable on resume/suspend > > drivers/pwm/pwm-tiecap.c | 53 > ++ > 1 file changed, 53 insertions(+) Applied, thanks. Thierry pgpjqf4IIWAHK.pgp Description: PGP signature
Re: [PATCH v2 1/2] pwm: pwm-tiehrpwm: Low power sleep support
On Thu, Jan 17, 2013 at 02:50:02PM +0530, Philip Avinash wrote: > In low power modes of AM33XX platforms, peripherals power is cut off. > This patch supports low power sleep transition support for EHRPWM > driver. > > Signed-off-by: Philip Avinash > --- > Changes since v1: > - check the enabled status of pwm device for handling module > enable/disable on resume/suspend > > drivers/pwm/pwm-tiehrpwm.c | 83 > > 1 file changed, 83 insertions(+) Applied, thanks. Thierry pgpC79fLUWLAR.pgp Description: PGP signature
Re: [PATCH v2] pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
On Thu, Jan 10, 2013 at 06:35:26PM +0530, Philip Avinash wrote: > From: "Philip, Avinash" > > The clock framework has changed and it's now better to invoke > clock_prepare_enable() and clk_disable_unprepare() rather than the > legacy clk_enable() and clk_disable() calls. This patch converts the > pwm-tiehrpwm driver to the new framework. > > Signed-off-by: Philip Avinash > --- > Changes Since v1: > - Check the return value of TBCLK enable in .pwm_enable() > > In 3.8-rc1, common clock frame work support added to AM335x. > > drivers/pwm/pwm-tiehrpwm.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) I had applied this to my for-next branch, but reading the commit message again it would seem that this should actually go into 3.8, right? Thierry pgpHyKBMHb6Dj.pgp Description: PGP signature
Re: [RFC PATCH 2/7] ARM: OMAP: devices: create device for usb part of control module
Hello.
On 01/15/2013 05:26 PM, kishon wrote:
>> On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
>>> A seperate driver has been added to handle the usb part of control
>>> module. A device for the above driver is created here, using the register
>>> address information to be used by the driver for powering on the PHY and
>>> for writing to the mailbox.
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> arch/arm/mach-omap2/devices.c | 50
>>> +
>>> 1 file changed, 50 insertions(+)
>>> diff --git a/arch/arm/mach-omap2/devices.c
>>> b/arch/arm/mach-omap2/devices.c
>>> index 5e304d0..a761faf4 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>> [...]
>>> @@ -254,6 +255,54 @@ static inline void omap_init_camera(void)
>>> #endif
>>> }
>>>
>>> +#if (defined(CONFIG_OMAP_CONTROL_USB) || \
>>> +defined(CONFIG_OMAP_CONTROL_USB_MODULE))
>> () around || not needed, and you're indenting the second line too much.
>>> +static inline void __init omap_init_control_usb(void)
>>> +{
>>> +int ret = 0;
>> Initializer not needed.
>>> +
>>> +if (cpu_is_omap44xx()) {
>>> +ret = platform_device_register(&omap4_control_usb);
>>> +if (ret)
>>> +pr_err("Error registering omap_control_usb device: %d\n"
>>> +, ret);
>> Please leave the comma on the previous line.
> Sure. I'll fix it.
Actually, you can use #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB) now instead of
your above constuct.
WBR, Sergei
--
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] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Hi Peter, I made changes to cpsw driver two weeks ago, which add support for reading MAC address from CPU and also I posted it to review. You can find patch here : https://patchwork.kernel.org/patch/1966481/ I will create updated patch next week, depended on reactions. Can you try that patch? I'll be glad to hear your opinion. Michal -- 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 v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
> "V" == Vaibhav Bedia writes:
Hi,
V> +static void am33xx_pm_firmware_cb(const struct firmware *fw, void *context)
V> +{
V> + struct wkup_m3_context *wkup_m3_context = context;
V> + struct platform_device *pdev = to_platform_device(wkup_m3_context->dev);
V> + int ret = 0;
V> +
V> + /* no firmware found */
V> + if (!fw) {
V> + dev_err(wkup_m3_context->dev, "request_firmware failed\n");
V> + goto err;
V> + }
V> +
V> + memcpy((void *)wkup_m3_context->code, fw->data, fw->size);
A size check would be good. I don't know much about the finer details
about the m3 and how it is connected, but don't you need to ensure data
is flushed before resetting the m3?
V> + pr_info("Copied the M3 firmware to UMEM\n");
V> +
V> + wkup_m3->state = M3_STATE_RESET;
V> +
V> + ret = omap_device_deassert_hardreset(pdev, "wkup_m3");
V> + if (ret) {
V> + pr_err("Could not deassert the reset for WKUP_M3\n");
V> + goto err;
V> + } else {
V> +#ifdef CONFIG_SUSPEND
V> + suspend_set_ops(&am33xx_pm_ops);
V> + /*
V> +* Physical resume address to be used by ROM code
V> +*/
V> + wkup_m3->ipc_data.resume_addr = (AM33XX_OCMC_END -
V> + am33xx_do_wfi_sz + am33xx_resume_offset + 0x4);
V> +#endif
V> + return;
V> + }
V> +
V> +err:
V> + mailbox_put(wkup_m3_context->mbox, &wkup_mbox_notifier);
V> +}
--
Bye, Peter Korsgaard
--
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 v3] gpio: twl4030: Cache the direction and output states in private data
Hi Linus, On 01/17/2013 11:43 AM, Linus Walleij wrote: > On Thu, Jan 10, 2013 at 2:09 PM, Peter Ujfalusi wrote: >> On 01/10/2013 11:41 AM, Linus Walleij wrote: > >>> Sorry Peter this must have been missed somehow. >>> >>> This does not apply to the current v3.8-rc3, could you respin >>> this on top of Torvalds' tree? >> >> Grant applied the patch which this one depends on: >> [1] https://patchwork.kernel.org/patch/1844511/ > > Hm, it is not in mainline, nor on Grant's "merge" or "next" > branches so it must have fallen on the floor somehow. > > I applied both the patches not, thanks! Thank you, I was planning to go through my pending patches tomorrow and resend or annoy maintainers with them. Thanks again, 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: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
Hi Kishon,
Thanks for the explanation.
On Thu, Jan 17, 2013 at 6:01 PM, kishon wrote:
> Hi,
>
>
> On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
>>
>> Hi Kishon,
>>
>>
>> On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I
>> wrote:
>>>
>>> This is in preparation for the changes in PHY library to support adding
>>> and getting multiple PHYs of the same type. In the new design, the
>>> binding information between the PHY and the USB controller should be
>>> specified in the platform specific initialization code. So it's been
>>> done for OMAP platforms here.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> This kind-of binding should be done in all the platforms (I've done only
>>> for OMAP platform).
>>> arch/arm/mach-omap2/usb-musb.c |7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/usb-musb.c
>>> b/arch/arm/mach-omap2/usb-musb.c
>>> index 9d27e3f..bbe2fa5 100644
>>> --- a/arch/arm/mach-omap2/usb-musb.c
>>> +++ b/arch/arm/mach-omap2/usb-musb.c
>>> @@ -24,6 +24,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "omap_device.h"
>>> #include "soc.h"
>>> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
>>> *musb_board_data)
>>> musb_plat.mode = board_data->mode;
>>> musb_plat.extvbus = board_data->extvbus;
>>>
>>> - if (cpu_is_omap44xx())
>>> + if (cpu_is_omap44xx()) {
>>> musb_plat.has_mailbox = true;
>>> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>>> + } else if (cpu_is_omap34xx()) {
>>> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>>> + }
>>
>>
>> Just trying to understand things here.
>> Is the device name we are using here the platform device name (pdev->name)
>> ?
>
>
> it's pdev->dev.name.
>
>> If i am not wrong then for devices added through device tree
>> the device name would actually include the device address in the string,
>
>
> Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the 5th
> patch of this series should be used.
Ok.
> usb_bind_phy should be called from platform specific initialization files
> (like your board file), which won't get executed in dt boot.
>
Right.
>> wouldn't that make things somewhat weird, since we will have to add
>> such bindings
>> using this address string.
>>
>> one more doubt please :)
>> is it possible to bind phy in the controllers' driver somehow ?
>
> Thats not going to be good. Why do you need to do that?
>
I was certainly missing something while understanding your patches.
That's why got some doubt on this. :)
> Thanks
> Kishon
--
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
Hi,
On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
Hi Kishon,
On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I wrote:
This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done for OMAP platforms here.
Signed-off-by: Kishon Vijay Abraham I
---
This kind-of binding should be done in all the platforms (I've done only
for OMAP platform).
arch/arm/mach-omap2/usb-musb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 9d27e3f..bbe2fa5 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "omap_device.h"
#include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+ } else if (cpu_is_omap34xx()) {
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ }
Just trying to understand things here.
Is the device name we are using here the platform device name (pdev->name) ?
it's pdev->dev.name.
If i am not wrong then for devices added through device tree
the device name would actually include the device address in the string,
Ideally for device tree, devm_usb_get_phy_by_phandle() introduced in the
5th patch of this series should be used.
usb_bind_phy should be called from platform specific initialization
files (like your board file), which won't get executed in dt boot.
wouldn't that make things somewhat weird, since we will have to add
such bindings
using this address string.
one more doubt please :)
is it possible to bind phy in the controllers' driver somehow ?
Thats not going to be good. Why do you need to do that?
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
Hi Kishon,
On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform specific initialization code. So it's been
> done for OMAP platforms here.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> This kind-of binding should be done in all the platforms (I've done only
> for OMAP platform).
> arch/arm/mach-omap2/usb-musb.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 9d27e3f..bbe2fa5 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "omap_device.h"
> #include "soc.h"
> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
> *musb_board_data)
> musb_plat.mode = board_data->mode;
> musb_plat.extvbus = board_data->extvbus;
>
> - if (cpu_is_omap44xx())
> + if (cpu_is_omap44xx()) {
> musb_plat.has_mailbox = true;
> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> + } else if (cpu_is_omap34xx()) {
> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> + }
Just trying to understand things here.
Is the device name we are using here the platform device name (pdev->name) ?
If i am not wrong then for devices added through device tree
the device name would actually include the device address in the string,
wouldn't that make things somewhat weird, since we will have to add
such bindings
using this address string.
one more doubt please :)
is it possible to bind phy in the controllers' driver somehow ?
>
> if (soc_is_am35xx()) {
> oh_name = "am35x_otg_hs";
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks & Regards
Vivek
--
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 v4 0/3] mtd: nand: OMAP: ELM error correction support for BCH ecc
On Wed, 2013-01-16 at 12:22 +, Philip, Avinash wrote: > > This series is based on linux 3.8-rc2 and tested with [1]. > > Also this patch series depend on [1] for NAND flash device > > tree data and gpmc nand device tree binding documentation updates. > > > > 1. [PATCH v7 0/5] OMAP GPMC DT bindings > > http://www.spinics.net/lists/linux-omap/msg83505.html > > > > Tested on am335x-evm for BCH 4 and 8 bit error correction. > > Can you apply this patch series on l2-mtd tree as it will help RBL > compatibility > ecc layout for NAND flash in am335x-platforms and hardware based BCH error > correction. OK, I've applied them. I dropped the part that updates the documentation. Please, handle it separately when Daniel's patches are in. Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] mtd: omap-onenand: pass device_node in platform data
On Tue, 2013-01-15 at 19:48 -0300, Ezequiel Garcia wrote: > I saw you have acked the gpmc patch on nand. > Can I add your Acked-by on this one, when I send the rebased patch set? Yes, I saw this series which depends on Daniel Mack's work. It looks good. You can add Acked-by: Artem Bityutskiy -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: Help wanted with USB and OMAP3 off_mode
On 01/17/2013 01:01 PM, NeilBrown wrote: > On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros wrote: > >> On 01/16/2013 12:27 PM, NeilBrown wrote: >>> On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros wrote: >>> On 01/09/2013 12:29 AM, NeilBrown wrote: > > Hi, > I'm trying to get off_mode working reliably on my gta04 mobile phone. > > My current stumbling block is USB. The "Option" GSM module is attached > via > USB (there is a separate transceiver chip attached to port 1 which is > placed > in OMAP_EHCI_PORT_MODE_PHY). > > After a suspend/resume cycle with off_mode enabled the GSM module > disappears. > i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't > exist. > Without off mode, the modem always appears after resume. > > I discovered that the registers set by: > >drivers/mfd/omap-usb-host.c > > are not maintained across as suspend/resume so I added the following patch > (which I can make a formal submission of if it looks right to others), but > that didn't help (or didn't help enough). > > If I > > echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend > > thus keeping just the USBHOST power domain out of off_mode, the GSM module > doesn't disappear. So it seems that some context in the usbhost domain is > not being save and restored. > > This is as far as I can get. Can someone suggest where I should look to > find > out what is not being saved/restored properly, and how to go about saving > and > restoring? You need to ensure that USBHOST/TLL context is saved as per the Save and Restore sequence see section "USBHOST/USBTLL Save-and-Restore Management" in the OMAP Technical Reference Manual. The basic idea there is that software does the context saving into SAR RAM before entering OFF mode and hardware automatically restores the context after coming out of OFF mode. >>> >>> Is it? The way I read the doco, the hardware both saves to SAR RAM, and >>> restores from SAR RAM. >>> Section 22.2.4.1.6 Save and Restore >>> of my copy of the TRM says: >>> The save-and-restore (SAR) mechanism can extract the hardware context of the high-speed USB host controller (after all USB activity has been suspended) before switching off (=save), save it to an external always-on memory, and reinject it later after the module has been switched on again and reset (=restore) seamlessly for the USB. Part of that context is composed of the register fields described in the current chapter. The rest of the context is composed of the "buried" flip-flops and memories (not accessible by software) like finite state-machine (FSM) states, buffer contents, and miscellaneous random logic bits. >>> >>> which strongly suggests that it is all handled by hardware. Of course there >>> are other registers that aren't covered by the SAR - we need to identify >>> those and make sure they are saved and restored. I've found a few registers >>> that aren't being restored, but restoring them hasn't made a visible >>> difference yet. >> >> Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. >> But still, software needs to ensure that the USBHOST and CORE power >> domain's SAVEANDRESTORE bit are set to ensure that SAR works. >> >> see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management" >> >> This seems to be done by the powerdomain code based on the >> PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST >> powerdomain with the following comment. >> >>> Both USBHOST and USBTLL support a save-and-restore mechanism. When the >>> device enters into off >>> mode (that is, all power domains, except the WKUP power domain, are off), >>> the user may want to save >>> the USBHOST context and restore it when exiting off mode. The >>> save-and-restore mechanism for the HS >>> USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] >>> SAVEANDRESTORE bit; for >>> the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE >>> bit. The save >>> mechanism is initiated as the power domain transitions from active to off >>> state (or to OSWR state for the >>> USBTLL), whereas the restore mechanism is initiated as the power domain >>> transitions from off to active >>> power state. >> >> Can you try with the flag enabled? > > If I keep CORE and USBHOST out of off-mode (by writing to the relevant > 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. > > If I set this flag, then I can allow USBHOST to enter off-mode as long as I > keep CORE in retention or better. > > If I let CORE and USBHOST go to off-mode and don't have the flag set, then I > can resume from suspend, but the usb modem has disappeared. > > If I let CORE and USBHOST go to off-mode and DO have the flag set, then I > c
Re: [RFC PATCH 1/6] usb: otg: Add an API to bind the USB controller and PHY
Hi,
On Thursday 17 January 2013 03:07 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
New platforms are added which has multiple PHY's (of same type) and
which has multiple USB controllers. The binding information has to be
present in the PHY library (otg.c) in order for it to return the
appropriate PHY whenever the USB controller request for the PHY. So
added a new API to pass the binding information. This API should be
called by platform specific initialization code.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/otg.c | 37 +
include/linux/usb/phy.h | 22 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..492ba2f 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
#include
static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
static DEFINE_SPINLOCK(phy_lock);
static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
}
EXPORT_SYMBOL(usb_remove_phy);
+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+ if (!phy_bind) {
+ pr_err("phy_bind(): No memory for phy_bind");
Function name in comment doesn't match the actual.
Instead, you could use
pr_err("%s ...", __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ phy_bind->dev_name = dev_name;
+ phy_bind->phy_dev_name = phy_dev_name;
+ phy_bind->index = index;
+
+ spin_lock_irqsave(&phy_lock, flags);
+ list_add_tail(&phy_bind->list, &phy_bind_list);
+ spin_unlock_irqrestore(&phy_lock, flags);
+
+ return phy_bind;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
const char *otg_state_string(enum usb_otg_state state)
{
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..fbeab1a 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
};
+/**
+ * struct usb_phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct usb_phy_bind {
+ const char *dev_name;
+ const char *phy_dev_name;
+ u8 index;
+ struct usb_phy *phy;
+ struct list_head list;
+};
/* for board-specific init logic */
extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
@@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern void usb_put_phy(struct usb_phy *);
extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
+extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name);
#else
static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
{
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev,
struct usb_phy *x)
{
}
+static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ return NULL;
+}
#endif
static inline int
Controllers like ehci-omap which don't need OTG functionality would
benefit from this API. Can we make these PHY APIs not dependent on OTG /
OTG_UTILS?
Actually much of whatever is in otg.c can be used by controllers which
don't have OTG functionality (except otg_state_string). I vaguely
remember, there was a patch that renamed otg.c to phy.c etc.. I'm not
sure what happened to that.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
Hi,
On Thursday 17 January 2013 03:09 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done for OMAP platforms here.
Signed-off-by: Kishon Vijay Abraham I
---
This kind-of binding should be done in all the platforms (I've done only
for OMAP platform).
arch/arm/mach-omap2/usb-musb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 9d27e3f..bbe2fa5 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "omap_device.h"
#include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+ } else if (cpu_is_omap34xx()) {
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+ }
Are you sure than these OMAP platforms cannot be wired in any other way
to the PHY?
If they can be then this association must come from the board files or
device tree.
I had given some thought about that and since all the existing OMAP
platforms had it this way, I added it here.
You having pointed that out, I'll move these to board files.
Thanks
Kishon
--
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: Help wanted with USB and OMAP3 off_mode
On Wed, 16 Jan 2013 12:57:08 +0200 Roger Quadros wrote: > On 01/16/2013 12:27 PM, NeilBrown wrote: > > On Wed, 16 Jan 2013 12:00:48 +0200 Roger Quadros wrote: > > > >> On 01/09/2013 12:29 AM, NeilBrown wrote: > >>> > >>> Hi, > >>> I'm trying to get off_mode working reliably on my gta04 mobile phone. > >>> > >>> My current stumbling block is USB. The "Option" GSM module is attached > >>> via > >>> USB (there is a separate transceiver chip attached to port 1 which is > >>> placed > >>> in OMAP_EHCI_PORT_MODE_PHY). > >>> > >>> After a suspend/resume cycle with off_mode enabled the GSM module > >>> disappears. > >>> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't > >>> exist. > >>> Without off mode, the modem always appears after resume. > >>> > >>> I discovered that the registers set by: > >>> > >>>drivers/mfd/omap-usb-host.c > >>> > >>> are not maintained across as suspend/resume so I added the following patch > >>> (which I can make a formal submission of if it looks right to others), but > >>> that didn't help (or didn't help enough). > >>> > >>> If I > >>> > >>> echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend > >>> > >>> thus keeping just the USBHOST power domain out of off_mode, the GSM module > >>> doesn't disappear. So it seems that some context in the usbhost domain is > >>> not being save and restored. > >>> > >>> This is as far as I can get. Can someone suggest where I should look to > >>> find > >>> out what is not being saved/restored properly, and how to go about saving > >>> and > >>> restoring? > >> > >> You need to ensure that USBHOST/TLL context is saved as per the Save and > >> Restore sequence see section "USBHOST/USBTLL Save-and-Restore > >> Management" in the OMAP Technical Reference Manual. > >> > >> The basic idea there is that software does the context saving into SAR > >> RAM before entering OFF mode and hardware automatically restores the > >> context after coming out of OFF mode. > > > > Is it? The way I read the doco, the hardware both saves to SAR RAM, and > > restores from SAR RAM. > > Section 22.2.4.1.6 Save and Restore > > of my copy of the TRM says: > > > >> The save-and-restore (SAR) mechanism can extract the hardware context of > >> the high-speed USB host > >> controller (after all USB activity has been suspended) before switching > >> off (=save), save it to an external > >> always-on memory, and reinject it later after the module has been switched > >> on again and reset (=restore) > >> seamlessly for the USB. Part of that context is composed of the register > >> fields described in the current > >> chapter. The rest of the context is composed of the "buried" flip-flops > >> and memories (not accessible by > >> software) like finite state-machine (FSM) states, buffer contents, and > >> miscellaneous random logic bits. > > > > which strongly suggests that it is all handled by hardware. Of course there > > are other registers that aren't covered by the SAR - we need to identify > > those and make sure they are saved and restored. I've found a few registers > > that aren't being restored, but restoring them hasn't made a visible > > difference yet. > > Yes, you are right. I mixed it up with OMAP4 behaviour, sorry. > But still, software needs to ensure that the USBHOST and CORE power > domain's SAVEANDRESTORE bit are set to ensure that SAR works. > > see section "3.5.4.6 USBHOST/USBTLL Save-and-Restore Management" > > This seems to be done by the powerdomain code based on the > PWRDM_HAS_HDWR_SAR flag. However, this flag is disabled for USBHOST > powerdomain with the following comment. > > > Both USBHOST and USBTLL support a save-and-restore mechanism. When the > > device enters into off > > mode (that is, all power domains, except the WKUP power domain, are off), > > the user may want to save > > the USBHOST context and restore it when exiting off mode. The > > save-and-restore mechanism for the HS > > USB Host is enabled by setting the PRCM.PM_PWSTCTRL_USBHOST[4] > > SAVEANDRESTORE bit; for > > the USBTLL, it is configured by the PRCM.PM_PWSTCTRL_CORE[4] SAVEANDRESTORE > > bit. The save > > mechanism is initiated as the power domain transitions from active to off > > state (or to OSWR state for the > > USBTLL), whereas the restore mechanism is initiated as the power domain > > transitions from off to active > > power state. > > Can you try with the flag enabled? If I keep CORE and USBHOST out of off-mode (by writing to the relevant 'suspend' files in /sys/kernel/debug/pm-debug) then it all works. If I set this flag, then I can allow USBHOST to enter off-mode as long as I keep CORE in retention or better. If I let CORE and USBHOST go to off-mode and don't have the flag set, then I can resume from suspend, but the usb modem has disappeared. If I let CORE and USBHOST go to off-mode and DO have the flag set, then I cannot even resume from suspend sometimes. I hate those "sometimes"s!
Re: [PATCH v3] gpio: twl4030: Cache the direction and output states in private data
On Thu, Jan 10, 2013 at 2:09 PM, Peter Ujfalusi wrote: > On 01/10/2013 11:41 AM, Linus Walleij wrote: >> Sorry Peter this must have been missed somehow. >> >> This does not apply to the current v3.8-rc3, could you respin >> this on top of Torvalds' tree? > > Grant applied the patch which this one depends on: > [1] https://patchwork.kernel.org/patch/1844511/ Hm, it is not in mainline, nor on Grant's "merge" or "next" branches so it must have fallen on the floor somehow. I applied both the patches not, thanks! Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On 01/17/2013 11:35 AM, Luciano Coelho wrote: > This out-of-tree code doesn't explain why we need to do the > enable/disable in the board file. We just need to do things a bit > differently in the driver. I'll start cleaning all this stuff up for > -next pretty soon. > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so > that TI-ST at least works on Panda? Simply reverting the gpio removal > patch doesn't help, because we also need to handle the UART2 muxing > (which my patch does as well). I don't see better way to fix this either. In any case, I give you my: Reviewed-by: Peter Ujfalusi -- 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]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, 2013-01-17 at 12:09 +0200, Felipe Balbi wrote: > On Thu, Jan 17, 2013 at 12:05:10PM +0200, Felipe Balbi wrote: > > Hi, > > > > On Thu, Jan 17, 2013 at 10:55:14AM +0100, Peter Ujfalusi wrote: > > > On 01/17/2013 10:34 AM, Felipe Balbi wrote: > > > >> I just wonder how this is going to work with DT... You are not going > > > >> to have > > > >> the ability to use callback in this form. > > > >> I think the GPIO handling should be done in the driver itself rather > > > >> than in > > > >> the board file. > > > > > > > > that can (should ?) be moved to ti-st eventually. In fact I don't know > > > > why it was removed in the first place, we would need Pavan to help us > > > > with that query. > > > > > > Yes, this is a good question. I don't know what is the spacial thing > > > platforms > > > need to do in the callback.. > > hah! looks like I found the reason: > > http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-44xx-54xx-connectivity.c;h=e4852b93e91b6daa8f85cca91a1e7fbcc778f45b;hb=594aedd9e7da0491523411f8999efd98297f4fe4#l177 > > IMHO: > > a) removing gpio handling wasn't necessary, we could just check > if gpio_is_valid(nshutdown_gpio) > > b) that whole omap_serial_ext_uart_enable() looks really hacky. I'm sure > we can come up with something better. > This out-of-tree code doesn't explain why we need to do the enable/disable in the board file. We just need to do things a bit differently in the driver. I'll start cleaning all this stuff up for -next pretty soon. For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so that TI-ST at least works on Panda? Simply reverting the gpio removal patch doesn't help, because we also need to handle the UART2 muxing (which my patch does as well). -- Cheers, Luca. -- 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]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, Jan 17, 2013 at 12:05:10PM +0200, Felipe Balbi wrote: > Hi, > > On Thu, Jan 17, 2013 at 10:55:14AM +0100, Peter Ujfalusi wrote: > > On 01/17/2013 10:34 AM, Felipe Balbi wrote: > > >> I just wonder how this is going to work with DT... You are not going to > > >> have > > >> the ability to use callback in this form. > > >> I think the GPIO handling should be done in the driver itself rather > > >> than in > > >> the board file. > > > > > > that can (should ?) be moved to ti-st eventually. In fact I don't know > > > why it was removed in the first place, we would need Pavan to help us > > > with that query. > > > > Yes, this is a good question. I don't know what is the spacial thing > > platforms > > need to do in the callback.. hah! looks like I found the reason: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-44xx-54xx-connectivity.c;h=e4852b93e91b6daa8f85cca91a1e7fbcc778f45b;hb=594aedd9e7da0491523411f8999efd98297f4fe4#l177 IMHO: a) removing gpio handling wasn't necessary, we could just check if gpio_is_valid(nshutdown_gpio) b) that whole omap_serial_ext_uart_enable() looks really hacky. I'm sure we can come up with something better. -- balbi signature.asc Description: Digital signature
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Hi, On Thu, Jan 17, 2013 at 10:55:14AM +0100, Peter Ujfalusi wrote: > On 01/17/2013 10:34 AM, Felipe Balbi wrote: > >> I just wonder how this is going to work with DT... You are not going to > >> have > >> the ability to use callback in this form. > >> I think the GPIO handling should be done in the driver itself rather than > >> in > >> the board file. > > > > that can (should ?) be moved to ti-st eventually. In fact I don't know > > why it was removed in the first place, we would need Pavan to help us > > with that query. > > Yes, this is a good question. I don't know what is the spacial thing platforms > need to do in the callback.. > > > Still, for -rc, the minimal patch had to be cooked, right ? > > Sure it need to be fixed. I would try to revert the patch which caused the > issue (eccf2979 drivers/misc/ti-st: remove gpio handling). > > Should fix the legacy boot, but it is going to be even bigger fun to move to > DT (and get rid of the callbacks). > > I don't have anything against this patch as such. Just wanted to point out the > obvious that the comfort of callbacks are not going to be around in some > cases. I guess Luca's choice was to cause the minimum impact to current code, also reverting original commit isn't free os hassles either. -- balbi signature.asc Description: Digital signature
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Hi Luca, On 01/17/2013 10:35 AM, Luciano Coelho wrote: >> I just wonder how this is going to work with DT... You are not going to have >> the ability to use callback in this form. >> I think the GPIO handling should be done in the driver itself rather than in >> the board file. > > I agree. The problem is that it used to be in the ti-st driver itself, > but it has been removed in a patch that says "different platforms have > begun to have their own ways to power-up/down the chip." (eccf2979 > drivers/misc/ti-st: remove gpio handling). Hrm, this is a strange patch for sure. Coming at times when we all suppose to move to DT and get rid of such callbacks for drivers. > This needs to be clarified first. I think we could use this for now and > later fix this properly (hopefully move it back to the ti-st driver). Can the offending patch be reverted? As I said to Felipe, I don't have any objections against this patch. It fits the purpose. But with the DT support (and removing callbacks to platform code) you are going to have fair amount work. -- 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]] OMAP: omap4-panda: add WiLink shared transport power functions
On 01/17/2013 10:34 AM, Felipe Balbi wrote: >> I just wonder how this is going to work with DT... You are not going to have >> the ability to use callback in this form. >> I think the GPIO handling should be done in the driver itself rather than in >> the board file. > > that can (should ?) be moved to ti-st eventually. In fact I don't know > why it was removed in the first place, we would need Pavan to help us > with that query. Yes, this is a good question. I don't know what is the spacial thing platforms need to do in the callback.. > Still, for -rc, the minimal patch had to be cooked, right ? Sure it need to be fixed. I would try to revert the patch which caused the issue (eccf2979 drivers/misc/ti-st: remove gpio handling). Should fix the legacy boot, but it is going to be even bigger fun to move to DT (and get rid of the callbacks). I don't have anything against this patch as such. Just wanted to point out the obvious that the comfort of callbacks are not going to be around in some cases. -- 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: [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform specific initialization code. So it's been
> done for OMAP platforms here.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> This kind-of binding should be done in all the platforms (I've done only
> for OMAP platform).
> arch/arm/mach-omap2/usb-musb.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 9d27e3f..bbe2fa5 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "omap_device.h"
> #include "soc.h"
> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data
> *musb_board_data)
> musb_plat.mode = board_data->mode;
> musb_plat.extvbus = board_data->extvbus;
>
> - if (cpu_is_omap44xx())
> + if (cpu_is_omap44xx()) {
> musb_plat.has_mailbox = true;
> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
> + } else if (cpu_is_omap34xx()) {
> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> + }
Are you sure than these OMAP platforms cannot be wired in any other way
to the PHY?
If they can be then this association must come from the board files or
device tree.
>
> if (soc_is_am35xx()) {
> oh_name = "am35x_otg_hs";
>
--
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
Re: [RFC PATCH 1/6] usb: otg: Add an API to bind the USB controller and PHY
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> New platforms are added which has multiple PHY's (of same type) and
> which has multiple USB controllers. The binding information has to be
> present in the PHY library (otg.c) in order for it to return the
> appropriate PHY whenever the USB controller request for the PHY. So
> added a new API to pass the binding information. This API should be
> called by platform specific initialization code.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/otg/otg.c | 37 +
> include/linux/usb/phy.h | 22 ++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index a30c041..492ba2f 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -18,6 +18,7 @@
> #include
>
> static LIST_HEAD(phy_list);
> +static LIST_HEAD(phy_bind_list);
> static DEFINE_SPINLOCK(phy_lock);
>
> static struct usb_phy *__usb_find_phy(struct list_head *list,
> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
> }
> EXPORT_SYMBOL(usb_remove_phy);
>
> +/**
> + * usb_bind_phy - bind the phy and the controller that uses the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @index: index to specify the port number
> + * @phy_dev_name: the device name of the phy
> + *
> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
> + * be used when the phy driver registers the phy and when the controller
> + * requests this phy.
> + *
> + * To be used by platform specific initialization code.
> + */
> +struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name)
> +{
> + struct usb_phy_bind *phy_bind;
> + unsigned long flags;
> +
> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
> + if (!phy_bind) {
> + pr_err("phy_bind(): No memory for phy_bind");
Function name in comment doesn't match the actual.
Instead, you could use
pr_err("%s ...", __func__);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + phy_bind->dev_name = dev_name;
> + phy_bind->phy_dev_name = phy_dev_name;
> + phy_bind->index = index;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> + list_add_tail(&phy_bind->list, &phy_bind_list);
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy_bind;
> +}
> +EXPORT_SYMBOL_GPL(usb_bind_phy);
> +
> const char *otg_state_string(enum usb_otg_state state)
> {
> switch (state) {
> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> index a29ae1e..fbeab1a 100644
> --- a/include/linux/usb/phy.h
> +++ b/include/linux/usb/phy.h
> @@ -106,6 +106,21 @@ struct usb_phy {
> enum usb_device_speed speed);
> };
>
> +/**
> + * struct usb_phy_bind - represent the binding for the phy
> + * @dev_name: the device name of the device that will bind to the phy
> + * @phy_dev_name: the device name of the phy
> + * @index: used if a single controller uses multiple phys
> + * @phy: reference to the phy
> + * @list: to maintain a linked list of the binding information
> + */
> +struct usb_phy_bind {
> + const char *dev_name;
> + const char *phy_dev_name;
> + u8 index;
> + struct usb_phy *phy;
> + struct list_head list;
> +};
>
> /* for board-specific init logic */
> extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
> @@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device
> *dev,
> enum usb_phy_type type);
> extern void usb_put_phy(struct usb_phy *);
> extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
> +extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
> + const char *phy_dev_name);
> #else
> static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
> {
> @@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev,
> struct usb_phy *x)
> {
> }
>
> +static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8
> index,
> + const char *phy_dev_name)
> +{
> + return NULL;
> +}
> #endif
>
> static inline int
>
Controllers like ehci-omap which don't need OTG functionality would
benefit from this API. Can we make these PHY APIs not dependent on OTG /
OTG_UTILS?
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
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, 2013-01-17 at 10:30 +0100, Peter Ujfalusi wrote:
> Hi Luca,
Hi Péter!
> On 01/16/2013 10:45 PM, Luciano Coelho wrote:
> > static struct ti_st_plat_data wilink_platform_data = {
> > - .nshutdown_gpio = 46,
> > .dev_name = "/dev/ttyO1",
> > .flow_cntrl = 1,
> > .baud_rate = 300,
> > - .chip_enable= NULL,
> > - .suspend= NULL,
> > - .resume = NULL,
> > + .chip_enable= plat_kim_chip_enable,
> > + .chip_disable = plat_kim_chip_disable,
>
> I just wonder how this is going to work with DT... You are not going to have
> the ability to use callback in this form.
> I think the GPIO handling should be done in the driver itself rather than in
> the board file.
I agree. The problem is that it used to be in the ti-st driver itself,
but it has been removed in a patch that says "different platforms have
begun to have their own ways to power-up/down the chip." (eccf2979
drivers/misc/ti-st: remove gpio handling).
This needs to be clarified first. I think we could use this for now and
later fix this properly (hopefully move it back to the ti-st driver).
--
Cheers,
Luca.
--
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]] OMAP: omap4-panda: add WiLink shared transport power functions
On Thu, Jan 17, 2013 at 10:30:15AM +0100, Peter Ujfalusi wrote:
> Hi Luca,
>
> On 01/16/2013 10:45 PM, Luciano Coelho wrote:
> > The code to enable and disable the WiLink shared transport has been
> > removed from the TI-ST driver, so it must be implemented in the board
> > files instead. Add the relevant operations to Panda's board file.
> >
> > Additionally, add the UART2 muxing data, so it's properly configured.
> >
> > Cc: stable [3.7]
> > Signed-off-by: Luciano Coelho
> > ---
> >
> > In v2: use gpio_request_one() instead of gpio_request() and
> > gpio_direction_output(). (Thanks Fabio!)
> >
> > arch/arm/mach-omap2/board-omap4panda.c | 50
> > +---
> > 1 file changed, 46 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap4panda.c
> > b/arch/arm/mach-omap2/board-omap4panda.c
> > index 5c8e9ce..f44fccf 100644
> > --- a/arch/arm/mach-omap2/board-omap4panda.c
> > +++ b/arch/arm/mach-omap2/board-omap4panda.c
> > @@ -51,18 +51,50 @@
> > #define GPIO_HUB_NRESET62
> > #define GPIO_WIFI_PMENA43
> > #define GPIO_WIFI_IRQ 53
> > +#define GPIO_BT_EN 46
> >
> > /* wl127x BT, FM, GPS connectivity chip */
> > +static int plat_kim_chip_enable(struct kim_data_s *kim_data)
> > +{
> > + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> > + mdelay(5);
> > + gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
> > + mdelay(100);
> > +
> > + return 0;
> > +}
> > +
> > +static int plat_kim_chip_disable(struct kim_data_s *kim_data)
> > +{
> > + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> > + mdelay(1);
> > + gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
> > + mdelay(1);
> > + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> > +
> > + return 0;
> > +}
> > +
> > static struct ti_st_plat_data wilink_platform_data = {
> > - .nshutdown_gpio = 46,
> > .dev_name = "/dev/ttyO1",
> > .flow_cntrl = 1,
> > .baud_rate = 300,
> > - .chip_enable= NULL,
> > - .suspend= NULL,
> > - .resume = NULL,
> > + .chip_enable= plat_kim_chip_enable,
> > + .chip_disable = plat_kim_chip_disable,
>
> I just wonder how this is going to work with DT... You are not going to have
> the ability to use callback in this form.
> I think the GPIO handling should be done in the driver itself rather than in
> the board file.
that can (should ?) be moved to ti-st eventually. In fact I don't know
why it was removed in the first place, we would need Pavan to help us
with that query.
Still, for -rc, the minimal patch had to be cooked, right ?
--
balbi
signature.asc
Description: Digital signature
Re: [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
Hi Luca,
On 01/16/2013 10:45 PM, Luciano Coelho wrote:
> The code to enable and disable the WiLink shared transport has been
> removed from the TI-ST driver, so it must be implemented in the board
> files instead. Add the relevant operations to Panda's board file.
>
> Additionally, add the UART2 muxing data, so it's properly configured.
>
> Cc: stable [3.7]
> Signed-off-by: Luciano Coelho
> ---
>
> In v2: use gpio_request_one() instead of gpio_request() and
> gpio_direction_output(). (Thanks Fabio!)
>
> arch/arm/mach-omap2/board-omap4panda.c | 50
> +---
> 1 file changed, 46 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c
> b/arch/arm/mach-omap2/board-omap4panda.c
> index 5c8e9ce..f44fccf 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -51,18 +51,50 @@
> #define GPIO_HUB_NRESET 62
> #define GPIO_WIFI_PMENA 43
> #define GPIO_WIFI_IRQ53
> +#define GPIO_BT_EN 46
>
> /* wl127x BT, FM, GPS connectivity chip */
> +static int plat_kim_chip_enable(struct kim_data_s *kim_data)
> +{
> + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> + mdelay(5);
> + gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
> + mdelay(100);
> +
> + return 0;
> +}
> +
> +static int plat_kim_chip_disable(struct kim_data_s *kim_data)
> +{
> + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> + mdelay(1);
> + gpio_set_value(GPIO_BT_EN, GPIO_HIGH);
> + mdelay(1);
> + gpio_set_value(GPIO_BT_EN, GPIO_LOW);
> +
> + return 0;
> +}
> +
> static struct ti_st_plat_data wilink_platform_data = {
> - .nshutdown_gpio = 46,
> .dev_name = "/dev/ttyO1",
> .flow_cntrl = 1,
> .baud_rate = 300,
> - .chip_enable= NULL,
> - .suspend= NULL,
> - .resume = NULL,
> + .chip_enable= plat_kim_chip_enable,
> + .chip_disable = plat_kim_chip_disable,
I just wonder how this is going to work with DT... You are not going to have
the ability to use callback in this form.
I think the GPIO handling should be done in the driver itself rather than in
the board file.
> };
>
> +static int wilink_st_init(void)
> +{
> + int status;
> +
> + status = gpio_request_one(GPIO_BT_EN, GPIOF_OUT_INIT_LOW, "kim");
> + if (status)
> + pr_err("%s: failed to request gpio %d\n", __func__,
> +GPIO_BT_EN);
> +
> + return status;
> +}
> +
> static struct platform_device wl1271_device = {
> .name = "kim",
> .id = -1,
> @@ -397,6 +429,12 @@ static struct omap_board_mux board_mux[] __initdata = {
> OMAP_PULL_ENA),
> OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>
> + /* UART2 - BT/FM/GPS shared transport */
> + OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
> +
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
>
> @@ -433,6 +471,10 @@ static void __init omap4_panda_init(void)
> if (ret)
> pr_err("error setting wl12xx data: %d\n", ret);
>
> + ret = wilink_st_init();
> + if (ret)
> + pr_err("WiLink shared transport init failed: %d\n", ret);
> +
> omap4_panda_init_rev();
> omap4_panda_i2c_init();
> platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
>
--
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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 01/16/13 12:19, NeilBrown wrote: > > > On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg > > > wrote: > > > > > >> -BEGIN PGP SIGNED MESSAGE- > > >> Hash: SHA1 > > > > > >> On 01/16/13 09:26, NeilBrown wrote: > > >>> On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg > > >>> > > >>> wrote: > > >>> > > On 01/09/13 14:08, Michael Trimarchi wrote: > > > Hi Neil > > > > > > I forget to answer to your questions > > > > > > On 01/09/2013 12:34 PM, NeilBrown wrote: > > >> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi > > >> wrote: > > >> > > >>> Hi Neil > > >>> > > >>> On 01/09/2013 11:19 AM, NeilBrown wrote: > > On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg > > > > wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > Hi Neil, > > > > > On 01/09/13 00:29, NeilBrown wrote: > > >> > > >> Hi, > > >> I'm trying to get off_mode working reliably on my gta04 mobile > > >> phone. > > >> > > >> My current stumbling block is USB. The "Option" GSM module is > > >> attached via > > >> USB (there is a separate transceiver chip attached to port 1 > > >> which is placed > > >> in OMAP_EHCI_PORT_MODE_PHY). > > > > > Which PHY is this (vendor/model)? > > > > Hi Igor, > > it is the SMSC USB3322 > > > > http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf > > > > > > BTW I subsequently discovered that keeping USBHOST out off > > off_mode only > > sometimes avoid the problem, not always. So there are probably > > multiple > > issues :-( > > > > We have the same PHY and it has some issues with the OMAP USB code. > > First issue we experience is that if we reset the PHY more then once > > w/o power cycling it, the PHY dies until next power cycle. > > So, we stop providing the reset GPIO to the usb code and do the reset > > in the board code. > > >>> > > >>> I've tried various change w.r.t the resetting and I cannot fault it. > > >>> Resetting or not resetting neither causes a problem while the USB is > > >>> otherwise working, not fixed the USB while it is otherwise failing. > > >>> So I don't think this is my problem - thanks. > > >>> > > > > >>> > > >>> Are you sure that you don't have glitch on power, reset pin during > > >>> suspend? > > >>> > > >> > > >> No, I don't really have the equipment to measure such things. > > >> But is it likely? Would enabling off_mode make it more likely? > > > > > > I don't know the reason of the off_mode problem :( > > > > We have the equipment to check this and no - this is not the case. > > > > > > > >> Can you suggest some way I could test the hypothesis? > > > > > > I had the same problem on a rugged mobile phone, so it is just > > > experience > > > Check the modem power and reset gpio too, but if you don't need to > > > unblock it > > > with the pin after resume we know that modem is not the problem > > > > I don't think modem is the problem... > > We have plain USB connector ports that are dead after the resume from > > off-mode. > > > > The good news are that we have the off-mode working on v3.6.1, > > including the USB, but we had to do some horrible ugly hacking for > > this. > > > > >>> > > >>> I assume this means "some patches on top of 3.6.1" ?? > > >>> Care to share your code? Even horribly ugly hacks can be educational. > > > > > >> We are not ready to share these patches (this will happen eventually > > >> after some work is finished), but I can explain what they do... > > > > > >> We split the ehci_run function to separate the debugfs and sysfs stuff > > >> from > > >> other initializations, so we can run the new version without the debugfs > > >> and > > >> sysfs stuff multiple times. > > > > > >> Then we implement the suspend/resume ehci callbacks: > > >> on suspend, assert phy reset, > > >> on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to > > >> EHCI_INSNREG04, and call the new ehci_run() function. > > > > > >> That does the job for USB host to resume from off mode. > > > > > > Interesting thanks. That makes a certain amount of sense. > > > > > > However I tried compiling ehci-hcd as a module and unload/reloading it > > > which > > > should have a similar net effect to what you did, but it didn'
[PATCH v2 2/2] pwm: pwm-tiecap: Low power sleep support
In low power modes of AM33XX platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ECAP driver.
Signed-off-by: Philip Avinash
---
Changes since v1:
- check the enabled status of pwm device for handling module
enable/disable on resume/suspend
drivers/pwm/pwm-tiecap.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 5cf016d..05b676d 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -41,10 +41,17 @@
#define ECCTL2_SYNC_SEL_DISA (BIT(7) | BIT(6))
#define ECCTL2_TSCTR_FREERUN BIT(4)
+struct ecap_context {
+ u32 cap3;
+ u32 cap4;
+ u16 ecctl2;
+};
+
struct ecap_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
void __iomem*mmio_base;
+ struct ecap_context ctx;
};
static inline struct ecap_pwm_chip *to_ecap_pwm_chip(struct pwm_chip *chip)
@@ -288,11 +295,57 @@ static int ecap_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(&pc->chip);
}
+void ecap_pwm_save_context(struct ecap_pwm_chip *pc)
+{
+ pm_runtime_get_sync(pc->chip.dev);
+ pc->ctx.ecctl2 = readw(pc->mmio_base + ECCTL2);
+ pc->ctx.cap4 = readl(pc->mmio_base + CAP4);
+ pc->ctx.cap3 = readl(pc->mmio_base + CAP3);
+ pm_runtime_put_sync(pc->chip.dev);
+}
+
+void ecap_pwm_restore_context(struct ecap_pwm_chip *pc)
+{
+ writel(pc->ctx.cap3, pc->mmio_base + CAP3);
+ writel(pc->ctx.cap4, pc->mmio_base + CAP4);
+ writew(pc->ctx.ecctl2, pc->mmio_base + ECCTL2);
+}
+
+static int ecap_pwm_suspend(struct device *dev)
+{
+ struct ecap_pwm_chip *pc = dev_get_drvdata(dev);
+ struct pwm_device *pwm = pc->chip.pwms;
+
+ ecap_pwm_save_context(pc);
+
+ /* Disable explicitly if PWM is running */
+ if (test_bit(PWMF_ENABLED, &pwm->flags))
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int ecap_pwm_resume(struct device *dev)
+{
+ struct ecap_pwm_chip *pc = dev_get_drvdata(dev);
+ struct pwm_device *pwm = pc->chip.pwms;
+
+ /* Enable explicitly if PWM was running */
+ if (test_bit(PWMF_ENABLED, &pwm->flags))
+ pm_runtime_get_sync(dev);
+
+ ecap_pwm_restore_context(pc);
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ecap_pwm_pm_ops, ecap_pwm_suspend, ecap_pwm_resume);
+
static struct platform_driver ecap_pwm_driver = {
.driver = {
.name = "ecap",
.owner = THIS_MODULE,
.of_match_table = ecap_of_match,
+ .pm = &ecap_pwm_pm_ops,
},
.probe = ecap_pwm_probe,
.remove = ecap_pwm_remove,
--
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
[PATCH v2 1/2] pwm: pwm-tiehrpwm: Low power sleep support
In low power modes of AM33XX platforms, peripherals power is cut off.
This patch supports low power sleep transition support for EHRPWM
driver.
Signed-off-by: Philip Avinash
---
Changes since v1:
- check the enabled status of pwm device for handling module
enable/disable on resume/suspend
drivers/pwm/pwm-tiehrpwm.c | 83
1 file changed, 83 insertions(+)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 4058df4..6627f42 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -113,6 +113,17 @@
#define NUM_PWM_CHANNEL2 /* EHRPWM channels */
+struct ehrpwm_context {
+ u16 tbctl;
+ u16 tbprd;
+ u16 cmpa;
+ u16 cmpb;
+ u16 aqctla;
+ u16 aqctlb;
+ u16 aqsfrc;
+ u16 aqcsfrc;
+};
+
struct ehrpwm_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
@@ -120,6 +131,7 @@ struct ehrpwm_pwm_chip {
unsigned long period_cycles[NUM_PWM_CHANNEL];
enum pwm_polarity polarity[NUM_PWM_CHANNEL];
struct clk *tbclk;
+ struct ehrpwm_context ctx;
};
static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -127,6 +139,11 @@ static inline struct ehrpwm_pwm_chip
*to_ehrpwm_pwm_chip(struct pwm_chip *chip)
return container_of(chip, struct ehrpwm_pwm_chip, chip);
}
+static u16 ehrpwm_read(void *base, int offset)
+{
+ return readw(base + offset);
+}
+
static void ehrpwm_write(void *base, int offset, unsigned int val)
{
writew(val & 0x, base + offset);
@@ -516,11 +533,77 @@ static int ehrpwm_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(&pc->chip);
}
+void ehrpwm_pwm_save_context(struct ehrpwm_pwm_chip *pc)
+{
+ pm_runtime_get_sync(pc->chip.dev);
+ pc->ctx.tbctl = ehrpwm_read(pc->mmio_base, TBCTL);
+ pc->ctx.tbprd = ehrpwm_read(pc->mmio_base, TBPRD);
+ pc->ctx.cmpa = ehrpwm_read(pc->mmio_base, CMPA);
+ pc->ctx.cmpb = ehrpwm_read(pc->mmio_base, CMPB);
+ pc->ctx.aqctla = ehrpwm_read(pc->mmio_base, AQCTLA);
+ pc->ctx.aqctlb = ehrpwm_read(pc->mmio_base, AQCTLB);
+ pc->ctx.aqsfrc = ehrpwm_read(pc->mmio_base, AQSFRC);
+ pc->ctx.aqcsfrc = ehrpwm_read(pc->mmio_base, AQCSFRC);
+ pm_runtime_put_sync(pc->chip.dev);
+}
+
+void ehrpwm_pwm_restore_context(struct ehrpwm_pwm_chip *pc)
+{
+ ehrpwm_write(pc->mmio_base, TBPRD, pc->ctx.tbprd);
+ ehrpwm_write(pc->mmio_base, CMPA, pc->ctx.cmpa);
+ ehrpwm_write(pc->mmio_base, CMPB, pc->ctx.cmpb);
+ ehrpwm_write(pc->mmio_base, AQCTLA, pc->ctx.aqctla);
+ ehrpwm_write(pc->mmio_base, AQCTLB, pc->ctx.aqctlb);
+ ehrpwm_write(pc->mmio_base, AQSFRC, pc->ctx.aqsfrc);
+ ehrpwm_write(pc->mmio_base, AQCSFRC, pc->ctx.aqcsfrc);
+ ehrpwm_write(pc->mmio_base, TBCTL, pc->ctx.tbctl);
+}
+
+static int ehrpwm_pwm_suspend(struct device *dev)
+{
+ struct ehrpwm_pwm_chip *pc = dev_get_drvdata(dev);
+ int i;
+
+ ehrpwm_pwm_save_context(pc);
+ for (i = 0; i < pc->chip.npwm; i++) {
+ struct pwm_device *pwm = &pc->chip.pwms[i];
+
+ if (!test_bit(PWMF_ENABLED, &pwm->flags))
+ continue;
+
+ /* Disable explicitly if PWM is running */
+ pm_runtime_put_sync(dev);
+ }
+ return 0;
+}
+
+static int ehrpwm_pwm_resume(struct device *dev)
+{
+ struct ehrpwm_pwm_chip *pc = dev_get_drvdata(dev);
+ int i;
+
+ for (i = 0; i < pc->chip.npwm; i++) {
+ struct pwm_device *pwm = &pc->chip.pwms[i];
+
+ if (!test_bit(PWMF_ENABLED, &pwm->flags))
+ continue;
+
+ /* Enable explicitly if PWM was running */
+ pm_runtime_get_sync(dev);
+ }
+ ehrpwm_pwm_restore_context(pc);
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ehrpwm_pwm_pm_ops, ehrpwm_pwm_suspend,
+ ehrpwm_pwm_resume);
+
static struct platform_driver ehrpwm_pwm_driver = {
.driver = {
.name = "ehrpwm",
.owner = THIS_MODULE,
.of_match_table = ehrpwm_of_match,
+ .pm = &ehrpwm_pwm_pm_ops,
},
.probe = ehrpwm_pwm_probe,
.remove = ehrpwm_pwm_remove,
--
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
[PATCH v2 0/2] LOW power sleep support for TI PWM submodules
TI PWM sub modules like ECAP & EHRPWM can enter in low power sleep state during low power transitions of the platforms (like in AM33XX). This patch series support low power sleep transition support. This patch series depend on [1] and [2] and tested for low sleep support on AM335x-evm for ECAP based PWM backlight. 1. ARM: OMAP2+: AM33XX: Add suspend-resume support http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82635.html 2. HWMOD fixes for AM33xx PWM submodules and device tree nodes. https://lkml.org/lkml/2013/1/2/87 Philip Avinash (2): pwm: pwm-tiehrpwm: Low power sleep support pwm: pwm-tiecap: Low power sleep support drivers/pwm/pwm-tiecap.c | 53 drivers/pwm/pwm-tiehrpwm.c | 83 2 files changed, 136 insertions(+) -- 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
