date:20101006

From: Senthilvadivu Guruswamy svad...@ti.com

Patch Base:
===
url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch pm-core
Commit id: 1dce15672f62296d059c44e70684600a2c80d3d0 
Description:  Merge branch 'pm-suspend' into pm-reset


v1 of the DSS HWMOD patch series focus on fixing the review comments and 
incorporating
TODO listed in the RFC patch of HWMOD adaptation to the current DSS
driver.

This patch series decouples the Clocks for DSS in HWMOD adaptation changes 
from
this series.  Another series would be posted which could be discussed w.r.t 
clocks
in DSS across omap2,3,4.

v1 patch series got delayed as we could not get a conclusion on the clock 
adaptation
across OMAP2,3,4, along with HWMOD hence decided to take up as a discussion in 
seperate series.

Summary of the HWMOD DSS design:

DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each 
corresponding to the HWMOD class in the HWMOD database. 

No Hardcoding of silicon data:
HWMOD database abstracts the SOC data like base addr, irq numbers and are
implemented in this patch series.

Continue to have custom bus for display panels:
omapdss driver continues to be a platform driver that registers the custom
bus.  It also continues to register the display panels(omap_dss_device) on the
board to the panel drivers (omap_dss_driver)
For Eg:  primary lcd device would be registered with lcd panel driver.
lcd panel driver if it is on a parallel interface would use library functions 
exported from dpi.o.  if it is on a dsi interface would use library functions
exported from dsi platform driver(dsi.o).

Clocks:
Handling of clocks in DSS only is one of the design approach, that does not
change the existing implementation.  If each of the DSS HW IPs had to handle
their own clocks, then corresponding clock changes are requested in the HWMOD
database as well which is not the present scenario.  As stated, this would be
handled in another series seperately.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart
for the dss main clocks.  Currently VENC driver needs to be aware of this and 
has to
use clk_get/put, clk_enable/disable, since VENC HWMOD is not aware of 54MCLK.


Current dss driver:
---
1.  Omapdss platform driver
- initialises necessary Ips dss, dispc.
- also initialises Ips like sdi, dsi, venc, rfbi
- creates a custom bus and registers the display devices/drivers
connected on the board to the custom bus.

2.  Suspend/resume of omapdss
- in turn sends suspend/resume calls for each of the display devices
registered to it.

Modified change:
---
Platform driver for each DSS HW IP in addition to the software omapdss
driver.

Omapdss platform driver
- initialises necessary software libraries like dpi, sdi.
- continues to have a custom bus and registers the display devices 
and drivers connected on the board to the custom bus.
- continues to handle suspend/resume of the display devices registered
to the custom bus.

DSS platform driver
- initialises DSS IP alone
- Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
DSI, VENC, DISPC.  Previously this was a part of omapdss driver in 
core.c
- Continues to handle the DSS IRQs.
- No suspend/resume hooks.

DISPC platform driver
- initialises DSS IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.

DSI platform driver
- initialises DSI IP alone
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.

RFBI, VENC platform drivers
- initialises DSI,VENC IPs
- Gets the required clock from DSS platform driver.
- No suspend/resume hooks.
- Continues to provide DISPC library functions.

The patches are tested on OMAP3430 and 3630.

Changes since RFC:
--
1) All the platform driver registration except DSS, were within the file core.c.
Registeration of these driver got seperated to its own file.
2) Usage of regulators by different drivers are implemented.
For Eg: Regulator used by VENC is moved to venc driver.  But vdda_dac would be 
needed by DPI and DSI as well.
4) OMAP2420 and OMAP2430 HWMOD database are generated in this v1.
5) Module support for omapdss driver can continue as the DSS HW IP specific 
platform
drivers are decoupled from omapdss driver.
6) Following review comments incorporated:
Changed the HWMOD device name from dss to dss_dss
Changed name of core driver from omapdss to omapdisplay as it deals 
with panels.
Fixed comments on return values from platform_get_resource/irq

[PATCH v1 03/16] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC

From: Senthilvadivu Guruswamy svad...@ti.com

Database generated for Display Sub System applicable for
OMAP34xx and OMAP36xx
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  333 
 1 files changed, 333 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..7df341f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -21,6 +21,7 @@
 #include omap_hwmod_common_data.h
 
 #include prm-regbits-34xx.h
+#include cm-regbits-34xx.h
 
 /*
  * OMAP3xxx hardware module integration data
@@ -31,6 +32,11 @@
  * elsewhere.
  */
 
+static struct omap_hwmod omap3xxx_dss_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
 static struct omap_hwmod omap3xxx_mpu_hwmod;
 static struct omap_hwmod omap3xxx_iva_hwmod;
 static struct omap_hwmod omap3xxx_l3_main_hwmod;
@@ -58,6 +64,13 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
.user   = OCP_USER_MPU,
 };
 
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+   .master = omap3xxx_dss_hwmod,
+   .slave  = omap3xxx_l3_main_hwmod,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Slave interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] = {
omap3xxx_mpu__l3_main,
@@ -197,6 +210,321 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+   .name = dss,
+   .sysc = omap3xxx_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+   { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+   { .name = dispc, .dma_req = 5 },
+   { .name = dsi1, .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+   omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+   {
+   .pa_start   = 0x4805,
+   .pa_end = 0x480503FF,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+   .master = omap3xxx_l4_core_hwmod,
+   .slave  = omap3xxx_dss_hwmod,
+   .clk= dss_ick,
+   .addr   = omap3xxx_dss_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_dss_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_slaves[] = {
+   omap3xxx_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+   { .role = tv_clk, .clk = dss_tv_fck },
+   { .role = dssclk, .clk = dss_96m_fck },
+   { .role = sys_clk, .clk = dss2_alwon_fck },
+};
+
+static struct omap_hwmod omap3xxx_dss_hwmod = {
+   .name   = dss,
+   .class  = omap3xxx_dss_hwmod_class,
+   .main_clk   = dss1_alwon_fck, /* instead of dss_fck */
+   .mpu_irqs   = omap3xxx_dss_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_dss_irqs),
+   .sdma_reqs  = omap3xxx_dss_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap3xxx_dss_sdma_chs),
+
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP3430_EN_DSS1_SHIFT,
+   .module_offs = OMAP3430_DSS_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
+   },
+   },
+   .opt_clks   = dss_opt_clks,
+   .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+   .slaves = omap3xxx_dss_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_dss_slaves),
+   .masters= omap3xxx_dss_masters,
+   .masters_cnt= ARRAY_SIZE(omap3xxx_dss_masters),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dispc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_ENAWAKEUP |
+

[PATCH v1 02/16] OMAP2430: hwmod data: add DSS DISPC RFBI VENC

From: Senthilvadivu Guruswamy svad...@ti.com

Database generated for OMAP2430 Display Sub System.
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  278 
 1 files changed, 278 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4526628..c610d10 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
 #include omap_hwmod_common_data.h
 
 #include prm-regbits-24xx.h
+#include cm-regbits-24xx.h
 
 /*
  * OMAP2430 hardware module integration data
@@ -29,6 +30,10 @@
  * elsewhere.
  */
 
+static struct omap_hwmod omap2430_dss_hwmod;
+static struct omap_hwmod omap2430_dss_dispc_hwmod;
+static struct omap_hwmod omap2430_dss_rfbi_hwmod;
+static struct omap_hwmod omap2430_dss_venc_hwmod;
 static struct omap_hwmod omap2430_mpu_hwmod;
 static struct omap_hwmod omap2430_iva_hwmod;
 static struct omap_hwmod omap2430_l3_main_hwmod;
@@ -48,6 +53,13 @@ static struct omap_hwmod_ocp_if omap2430_mpu__l3_main = {
.user   = OCP_USER_MPU,
 };
 
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2430_dss__l3 = {
+   .master = omap2430_dss_hwmod,
+   .slave  = omap2430_l3_main_hwmod,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Slave interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[] = {
omap2430_mpu__l3_main,
@@ -165,12 +177,278 @@ static struct omap_hwmod omap2430_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dss_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dss_hwmod_class = {
+   .name = dss,
+   .sysc = omap2430_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2430_dss_irqs[] = {
+   { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2430_dss_sdma_chs[] = {
+   { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_masters[] = {
+   omap2430_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_addrs[] = {
+   {
+   .pa_start   = 0x4805,
+   .pa_end = 0x480503FF,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss = {
+   .master = omap2430_l4_core_hwmod,
+   .slave  = omap2430_dss_hwmod,
+   .clk= dss_ick,
+   .addr   = omap2430_dss_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_dss_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
+   omap2430_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+   { .role = tv_clk, .clk = dss_54m_fck },
+   { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2430_dss_hwmod = {
+   .name   = dss,
+   .class  = omap2430_dss_hwmod_class,
+   .main_clk   = dss1_fck, /* instead of dss_fck */
+   .mpu_irqs   = omap2430_dss_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_dss_irqs),
+   .sdma_reqs  = omap2430_dss_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2430_dss_sdma_chs),
+
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+   },
+   },
+   .opt_clks   = dss_opt_clks,
+   .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+   .slaves = omap2430_dss_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_dss_slaves),
+   .masters= omap2430_dss_masters,
+   .masters_cnt= ARRAY_SIZE(omap2430_dss_masters),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dispc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct

[PATCH v1 04/16] OMAP3: hwmod data: change dss_hwmod to dss_dss_hwmod

From: Senthilvadivu Guruswamy svad...@ti.com

dss is also considered as a HW IP inside DSS.
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 7df341f..21fb9eb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -32,7 +32,7 @@
  * elsewhere.
  */
 
-static struct omap_hwmod omap3xxx_dss_hwmod;
+static struct omap_hwmod omap3xxx_dss_dss_hwmod;
 static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
 static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
 static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
@@ -66,7 +66,7 @@ static struct omap_hwmod_ocp_if omap3xxx_mpu__l3_main = {
 
 /* DSS - l3 */
 static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
-   .master = omap3xxx_dss_hwmod,
+   .master = omap3xxx_dss_dss_hwmod,
.slave  = omap3xxx_l3_main_hwmod,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
@@ -255,7 +255,7 @@ static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
 /* l4_core - dss */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
.master = omap3xxx_l4_core_hwmod,
-   .slave  = omap3xxx_dss_hwmod,
+   .slave  = omap3xxx_dss_dss_hwmod,
.clk= dss_ick,
.addr   = omap3xxx_dss_addrs,
.addr_cnt   = ARRAY_SIZE(omap3xxx_dss_addrs),
@@ -273,8 +273,8 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = sys_clk, .clk = dss2_alwon_fck },
 };
 
-static struct omap_hwmod omap3xxx_dss_hwmod = {
-   .name   = dss,
+static struct omap_hwmod omap3xxx_dss_dss_hwmod = {
+   .name   = dss_dss,
.class  = omap3xxx_dss_hwmod_class,
.main_clk   = dss1_alwon_fck, /* instead of dss_fck */
.mpu_irqs   = omap3xxx_dss_irqs,
@@ -532,7 +532,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
-   omap3xxx_dss_hwmod,
+   omap3xxx_dss_dss_hwmod,
omap3xxx_dss_dispc_hwmod,
omap3xxx_dss_dsi1_hwmod,
omap3xxx_dss_rfbi_hwmod,
-- 
1.6.3.3

--
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 v1 01/16] OMAP2420: hwmod data: add DSS DISPC RFBI VENC

From: Senthilvadivu Guruswamy svad...@ti.com

Database generated for OMAP2420 Display Sub System.
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  278 
 1 files changed, 278 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..d3b4fd4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -19,6 +19,7 @@
 #include omap_hwmod_common_data.h
 
 #include prm-regbits-24xx.h
+#include cm-regbits-24xx.h
 
 /*
  * OMAP2420 hardware module integration data
@@ -29,6 +30,10 @@
  * elsewhere.
  */
 
+static struct omap_hwmod omap2420_dss_hwmod;
+static struct omap_hwmod omap2420_dss_dispc_hwmod;
+static struct omap_hwmod omap2420_dss_rfbi_hwmod;
+static struct omap_hwmod omap2420_dss_venc_hwmod;
 static struct omap_hwmod omap2420_mpu_hwmod;
 static struct omap_hwmod omap2420_iva_hwmod;
 static struct omap_hwmod omap2420_l3_main_hwmod;
@@ -48,6 +53,13 @@ static struct omap_hwmod_ocp_if omap2420_mpu__l3_main = {
.user   = OCP_USER_MPU,
 };
 
+/* DSS - l3 */
+static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
+   .master = omap2420_dss_hwmod,
+   .slave  = omap2420_l3_main_hwmod,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Slave interfaces on the L3 interconnect */
 static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] = {
omap2420_mpu__l3_main,
@@ -165,12 +177,278 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
 };
 
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dss_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dss_hwmod_class = {
+   .name = dss,
+   .sysc = omap2420_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2420_dss_irqs[] = {
+   { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
+   { .name = dispc, .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
+   omap2420_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_addrs[] = {
+   {
+   .pa_start   = 0x4805,
+   .pa_end = 0x480503FF,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core - dss */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss = {
+   .master = omap2420_l4_core_hwmod,
+   .slave  = omap2420_dss_hwmod,
+   .clk= dss_ick,
+   .addr   = omap2420_dss_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_dss_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
+   omap2420_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+   { .role = tv_clk, .clk = dss_54m_fck },
+   { .role = sys_clk, .clk = dss2_fck },
+};
+
+static struct omap_hwmod omap2420_dss_hwmod = {
+   .name   = dss,
+   .class  = omap2420_dss_hwmod_class,
+   .main_clk   = dss1_fck, /* instead of dss_fck */
+   .mpu_irqs   = omap2420_dss_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_dss_irqs),
+   .sdma_reqs  = omap2420_dss_sdma_chs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap2420_dss_sdma_chs),
+
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_DSS_SHIFT,
+   },
+   },
+   .opt_clks   = dss_opt_clks,
+   .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+   .slaves = omap2420_dss_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_dss_slaves),
+   .masters= omap2420_dss_masters,
+   .masters_cnt= ARRAY_SIZE(omap2420_dss_masters),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dispc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct

[PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to driver

From: Senthilvadivu Guruswamy svad...@ti.com

Move init exit methods to its driver probe, remove.
pdev member has to be maintained by its own drivers.
regulator has to be privately handled in each driver.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c |2 +-
 drivers/video/omap2/dss/core.c  |   29 ---
 drivers/video/omap2/dss/venc.c  |   69 +--
 3 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 62b6523..edcfaff 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -303,7 +303,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
 };
 
 static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
-   REGULATOR_SUPPLY(vdda_dac, omapdisplay);
+   REGULATOR_SUPPLY(vdda_dac, dss_venc);
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
 };
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 9652ed7..df74116 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,7 +43,6 @@ static struct {
 
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
-   struct regulator *vdda_dac_reg;
 } core;
 
 
@@ -86,20 +85,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
 }
 
-struct regulator *dss_get_vdda_dac(void)
-{
-   struct regulator *reg;
-
-   if (core.vdda_dac_reg != NULL)
-   return core.vdda_dac_reg;
-
-   reg = regulator_get(core.pdev-dev, vdda_dac);
-   if (!IS_ERR(reg))
-   core.vdda_dac_reg = reg;
-
-   return reg;
-}
-
 #if defined(CONFIG_DEBUG_FS)  defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
 static int dss_debug_show(struct seq_file *s, void *unused)
 {
@@ -199,12 +184,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
 
-   r = venc_init(pdev);
-   if (r) {
-   DSSERR(Failed to initialize venc\n);
-   goto err_venc;
-   }
-
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -254,8 +233,6 @@ err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
 err_sdi:
-   venc_exit();
-err_venc:
dpi_exit();
 err_dpi:
 
@@ -269,7 +246,6 @@ static int omap_dss_remove(struct platform_device *pdev)
 
dss_uninitialize_debugfs();
 
-   venc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
@@ -562,11 +538,6 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
 
-   if (core.vdda_dac_reg != NULL) {
-   regulator_put(core.vdda_dac_reg);
-   core.vdda_dac_reg = NULL;
-   }
-
platform_driver_unregister(omap_dss_driver);
 
omap_dss_bus_unregister();
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index ec17b28..3a121cb 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -87,26 +87,6 @@
 #define VENC_OUTPUT_TEST   0xC8
 #define VENC_DAC_B__DAC_C  0xC8
 
-/* VENC HW IP initialisation */
-static int omap_venchw_probe(struct platform_device *pdev)
-{
-   return 0;
-}
-
-static int omap_venchw_remove(struct platform_device *pdev)
-{
-   return 0;
-}
-
-static struct platform_driver omap_venchw_driver = {
-   .probe  = omap_venchw_probe,
-   .remove = omap_venchw_remove,
-   .driver = {
-   .name   = dss_venc,
-   .owner  = THIS_MODULE,
-   },
-};
-
 struct venc_config {
u32 f_control;
u32 vidout_ctrl;
@@ -309,6 +289,7 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
 EXPORT_SYMBOL(omap_dss_ntsc_timings);
 
 static struct {
+   struct platform_device *pdev;
void __iomem *base;
struct mutex venc_lock;
u32 wss_data;
@@ -326,6 +307,37 @@ static inline u32 venc_read_reg(int idx)
return l;
 }
 
+/* VENC HW IP initialisation */
+static int omap_venchw_probe(struct platform_device *pdev)
+{
+   int r;
+   venc.pdev = pdev;
+
+   r = venc_init(pdev);
+   if (r) {
+   DSSERR(Failed to initialize venc\n);
+   goto err_venc;
+   }
+
+err_venc:
+   return r;
+}
+
+static int omap_venchw_remove(struct platform_device *pdev)
+{
+   venc_exit();
+   return 0;
+}
+
+static struct platform_driver omap_venchw_driver = {
+   .probe  = omap_venchw_probe,
+   .remove = omap_venchw_remove,
+   .driver = {
+   .name   = dss_venc,
+   .owner  = THIS_MODULE,
+   },
+};
+
 static void venc_write_config(const struct venc_config *config)
 {
DSSDBG(write venc conf\n);
@@ -661,7 +673,19 @@

[PATCH v1 12/16] OMAP3: hwmod DSS: DISPC Move init,exit to driver

From: Senthilvadivu Guruswamy svad...@ti.com

Move init exit methods to its driver probe,remove.
pdev member has to be maintained by its own drivers.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/core.c  |9 -
 drivers/video/omap2/dss/dispc.c |   14 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index cc7a5f1..9652ed7 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -199,12 +199,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
 
-   r = dispc_init();
-   if (r) {
-   DSSERR(Failed to initialize dispc\n);
-   goto err_dispc;
-   }
-
r = venc_init(pdev);
if (r) {
DSSERR(Failed to initialize venc\n);
@@ -262,8 +256,6 @@ err_dsi:
 err_sdi:
venc_exit();
 err_venc:
-   dispc_exit();
-err_dispc:
dpi_exit();
 err_dpi:
 
@@ -278,7 +270,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
 
venc_exit();
-   dispc_exit();
dpi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e48c6fa..e35cc87 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -156,6 +156,7 @@ struct dispc_irq_stats {
 };
 
 static struct {
+   struct platform_device *pdev;
void __iomem*base;
 
u32 fifo_size[3];
@@ -189,11 +190,22 @@ static inline u32 dispc_read_reg(const struct dispc_reg 
idx)
 /* DISPC HW IP initialisation */
 static int omap_dispchw_probe(struct platform_device *pdev)
 {
-   return 0;
+   int r;
+   dispc.pdev = pdev;
+
+   r = dispc_init();
+   if (r) {
+   DSSERR(Failed to initialize dispc\n);
+   goto err_dispc;
+   }
+
+err_dispc:
+   return r;
 }
 
 static int omap_dispchw_remove(struct platform_device *pdev)
 {
+   dispc_exit();
return 0;
 }
 
-- 
1.6.3.3

--
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 v1 14/16] OMAP3: hwmod DSS: DSI Move init, exit to driver

From: Senthilvadivu Guruswamy svad...@ti.com

Move init exit methods to its driver probe, remove.
pdev member has to be maintained by its own drivers.
regulator has to be privately handled in each driver.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c |1 +
 drivers/video/omap2/dss/core.c  |8 
 drivers/video/omap2/dss/dsi.c   |   28 ++--
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index edcfaff..fc27cd5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -528,6 +528,7 @@ static struct regulator_init_data sdp3430_vdac = {
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdisplay),
+   REGULATOR_SUPPLY(vdds_dsi, dss_dsi1),
 };
 
 static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index df74116..d44ed6c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -191,11 +191,6 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_sdi;
}
 
-   r = dsi_init(pdev);
-   if (r) {
-   DSSERR(Failed to initialize DSI\n);
-   goto err_dsi;
-   }
}
 
r = dss_initialize_debugfs();
@@ -228,9 +223,6 @@ err_register:
dss_uninitialize_debugfs();
 err_debugfs:
if (cpu_is_omap34xx())
-   dsi_exit();
-err_dsi:
-   if (cpu_is_omap34xx())
sdi_exit();
 err_sdi:
dpi_exit();
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index fd49663..092d7fe 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -222,6 +222,7 @@ struct dsi_irq_stats {
 
 static struct
 {
+   struct platform_device *pdev;
void __iomem*base;
 
struct dsi_clock_info current_cinfo;
@@ -295,11 +296,20 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
 /* DSI1 HW IP initialisation */
 static int omap_dsi1hw_probe(struct platform_device *pdev)
 {
-   return 0;
+   int r;
+   dsi.pdev = pdev;
+   r = dsi_init(pdev);
+   if (r) {
+   DSSERR(Failed to initialize DSI\n);
+   goto err_dsi;
+   }
+err_dsi:
+   return r;
 }
 
 static int omap_dsi1hw_remove(struct platform_device *pdev)
 {
+   dsi_exit();
return 0;
 }
 
@@ -312,6 +322,20 @@ static struct platform_driver omap_dsi1hw_driver = {
},
 };
 
+static struct regulator *dsi_get_vdds_dsi(void)
+{
+   struct regulator *reg;
+
+   if (dsi.vdds_dsi_reg != NULL)
+   return dsi.vdds_dsi_reg;
+
+   reg = regulator_get(dsi.pdev-dev, vdds_dsi);
+   if (!IS_ERR(reg))
+   dsi.vdds_dsi_reg = reg;
+
+   return reg;
+}
+
 
 void dsi_save_context(void)
 {
@@ -3292,7 +3316,7 @@ int dsi_init(struct platform_device *pdev)
goto err1;
}
 
-   dsi.vdds_dsi_reg = dss_get_vdds_dsi();
+   dsi.vdds_dsi_reg = dsi_get_vdds_dsi();
if (IS_ERR(dsi.vdds_dsi_reg)) {
iounmap(dsi.base);
DSSERR(can't get VDDS_DSI regulator\n);
-- 
1.6.3.3

--
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 v1 16/16] OMAP3: hwmod DSS: Get DSS IRQ from platform device

From: Senthilvadivu Guruswamy svad...@ti.com

DSS IRQ got from platform device.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/dss.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a95ab8..f56d1b8 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -966,7 +966,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
 int dss_init(bool skip_init)
 {
-   int r;
+   int r, dss_irq;
u32 rev;
struct resource *dss_mem;
 
@@ -1012,15 +1012,18 @@ int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);  /* venc clock mode = normal */
 #endif
 
-   r = request_irq(INT_24XX_DSS_IRQ,
+   dss_irq = platform_get_irq(dss.pdev, 0);
+   if (dss_irq != -ENXIO) {
+   r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, OMAP DSS, NULL);
 
-   if (r  0) {
-   DSSERR(omap2 dss: request_irq failed\n);
-   goto fail1;
+   if (r  0) {
+   DSSERR(omap2 dss: request_irq failed\n);
+   goto fail1;
+   }
}
 
if (cpu_is_omap34xx()) {
-- 
1.6.3.3

--
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 v1 15/16] OMAP3: hwmod DSS: Use platform device to get baseaddr

From: Senthilvadivu Guruswamy svad...@ti.com

DSS, DISPC, DSI, RFBI, VENC baseaddr got from platform_device.
Hardcoding of base addr could be removed.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   10 +++---
 drivers/video/omap2/dss/dsi.c   |   12 +---
 drivers/video/omap2/dss/dss.c   |   11 ---
 drivers/video/omap2/dss/rfbi.c  |   10 +++---
 drivers/video/omap2/dss/venc.c  |   10 +++---
 5 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e35cc87..4642bf1 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -41,8 +41,6 @@
 #include dss.h
 
 /* DISPC */
-#define DISPC_BASE 0x48050400
-
 #define DISPC_SZ_REGS  SZ_1K
 
 struct dispc_reg { u16 idx; };
@@ -3134,6 +3132,7 @@ static void _omap_dispc_initial_config(void)
 int dispc_init(void)
 {
u32 rev;
+   struct resource *dispc_mem;
 
spin_lock_init(dispc.irq_lock);
 
@@ -3144,7 +3143,12 @@ int dispc_init(void)
 
INIT_WORK(dispc.error_work, dispc_error_worker);
 
-   dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+   dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+   if (!dispc_mem) {
+   DSSERR(can't get IORESOURCE_MEM DISPC\n);
+   return -EINVAL;
+   }
+   dispc.base = ioremap(dispc_mem-start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR(can't ioremap DISPC\n);
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 092d7fe..f54f967 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,8 +42,6 @@
 /*#define VERBOSE_IRQ*/
 #define DSI_CATCH_MISSING_TE
 
-#define DSI_BASE   0x4804FC00
-
 struct dsi_reg { u16 idx; };
 
 #define DSI_REG(idx)   ((const struct dsi_reg) { idx })
@@ -3283,6 +3281,7 @@ int dsi_init(struct platform_device *pdev)
 {
u32 rev;
int r;
+   struct resource *dsi_mem;
 
spin_lock_init(dsi.errors_lock);
dsi.errors = 0;
@@ -3309,7 +3308,13 @@ int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
 #endif
-   dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+   dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+   if (!dsi_mem) {
+   DSSERR(can't get IORESOURCE_MEM DSI\n);
+   r = -EINVAL;
+   goto err0;
+   }
+   dsi.base = ioremap(dsi_mem-start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR(can't ioremap DSI\n);
r = -ENOMEM;
@@ -3337,6 +3342,7 @@ err2:
iounmap(dsi.base);
 err1:
destroy_workqueue(dsi.workqueue);
+err0:
return r;
 }
 
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index b93b118..9a95ab8 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -34,8 +34,6 @@
 #include plat/clock.h
 #include dss.h
 
-#define DSS_BASE   0x4805
-
 #define DSS_SZ_REGSSZ_512
 
 struct dss_reg {
@@ -970,8 +968,15 @@ int dss_init(bool skip_init)
 {
int r;
u32 rev;
+   struct resource *dss_mem;
 
-   dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+   dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+   if (!dss_mem) {
+   DSSERR(can't get IORESOURCE_MEM DSS\n);
+   r = -EINVAL;
+   goto fail0;
+   }
+   dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 9bee39d..0566eec 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,8 +36,6 @@
 #include plat/display.h
 #include dss.h
 
-#define RFBI_BASE   0x48050800
-
 struct rfbi_reg { u16 idx; };
 
 #define RFBI_REG(idx)  ((const struct rfbi_reg) { idx })
@@ -994,6 +992,7 @@ int rfbi_init(void)
 {
u32 rev;
u32 l;
+   struct resource *rfbi_mem;
 
spin_lock_init(rfbi.cmd_lock);
 
@@ -1001,7 +1000,12 @@ int rfbi_init(void)
atomic_set(rfbi.cmd_fifo_full, 0);
atomic_set(rfbi.cmd_pending, 0);
 
-   rfbi.base = ioremap(RFBI_BASE, SZ_256);
+   rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+   if (!rfbi_mem) {
+   DSSERR(can't get IORESOURCE_MEM RFBI\n);
+   return -EINVAL;
+   }
+   rfbi.base = ioremap(rfbi_mem-start, resource_size(rfbi_mem));
if (!rfbi.base) {
DSSERR(can't ioremap RFBI\n);
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/venc.c

[PATCH v1 09/16] OMAP3: hwmod DSS: Move clocks from core driver to dss driver

From: Senthilvadivu Guruswamy svad...@ti.com

cks are moved to dss platform driver.  clk_get/put
APIs use dss device instead of core platform device.
It leaves the core driver omapdisplay to take care of
panel registration with the custom bus.  dss driver would
take care of the clocks needed by DISPC,RFBI,DSI,VENC.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/core.c |  372 +--
 drivers/video/omap2/dss/dss.c  |  382 +++-
 drivers/video/omap2/dss/dss.h  |   14 +-
 3 files changed, 392 insertions(+), 376 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 7810a40..ce5240f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -34,30 +34,18 @@
 #include linux/regulator/consumer.h
 
 #include plat/display.h
-#include plat/clock.h
+
 
 #include dss.h
 
 static struct {
struct platform_device *pdev;
-   int ctx_id;
-
-   struct clk  *dss_ick;
-   struct clk  *dss1_fck;
-   struct clk  *dss2_fck;
-   struct clk  *dss_54m_fck;
-   struct clk  *dss_96m_fck;
-   unsignednum_clks_enabled;
 
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
struct regulator *vdda_dac_reg;
 } core;
 
-static void dss_clk_enable_all_no_ctx(void);
-static void dss_clk_disable_all_no_ctx(void);
-static void dss_clk_enable_no_ctx(enum dss_clock clks);
-static void dss_clk_disable_no_ctx(enum dss_clock clks);
 
 static char *def_disp_name;
 module_param_named(def_disp, def_disp_name, charp, 0);
@@ -68,297 +56,6 @@ unsigned int dss_debug;
 module_param_named(debug, dss_debug, bool, 0644);
 #endif
 
-/* CONTEXT */
-static int dss_get_ctx_id(void)
-{
-   struct omap_dss_board_info *pdata = core.pdev-dev.platform_data;
-   int r;
-
-   if (!pdata-get_last_off_on_transaction_id)
-   return 0;
-   r = pdata-get_last_off_on_transaction_id(core.pdev-dev);
-   if (r  0) {
-   dev_err(core.pdev-dev, getting transaction ID failed, 
-   will force context restore\n);
-   r = -1;
-   }
-   return r;
-}
-
-int dss_need_ctx_restore(void)
-{
-   int id = dss_get_ctx_id();
-
-   if (id  0 || id != core.ctx_id) {
-   DSSDBG(ctx id %d - id %d\n,
-   core.ctx_id, id);
-   core.ctx_id = id;
-   return 1;
-   } else {
-   return 0;
-   }
-}
-
-static void save_all_ctx(void)
-{
-   DSSDBG(save context\n);
-
-   dss_clk_enable_no_ctx(DSS_CLK_ICK | DSS_CLK_FCK1);
-
-   dss_save_context();
-   dispc_save_context();
-#ifdef CONFIG_OMAP2_DSS_DSI
-   dsi_save_context();
-#endif
-
-   dss_clk_disable_no_ctx(DSS_CLK_ICK | DSS_CLK_FCK1);
-}
-
-static void restore_all_ctx(void)
-{
-   DSSDBG(restore context\n);
-
-   dss_clk_enable_all_no_ctx();
-
-   dss_restore_context();
-   dispc_restore_context();
-#ifdef CONFIG_OMAP2_DSS_DSI
-   dsi_restore_context();
-#endif
-
-   dss_clk_disable_all_no_ctx();
-}
-
-#if defined(CONFIG_DEBUG_FS)  defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
-/* CLOCKS */
-static void core_dump_clocks(struct seq_file *s)
-{
-   int i;
-   struct clk *clocks[5] = {
-   core.dss_ick,
-   core.dss1_fck,
-   core.dss2_fck,
-   core.dss_54m_fck,
-   core.dss_96m_fck
-   };
-
-   seq_printf(s, - CORE -\n);
-
-   seq_printf(s, internal clk count\t\t%u\n, core.num_clks_enabled);
-
-   for (i = 0; i  5; i++) {
-   if (!clocks[i])
-   continue;
-   seq_printf(s, %-15s\t%lu\t%d\n,
-   clocks[i]-name,
-   clk_get_rate(clocks[i]),
-   clocks[i]-usecount);
-   }
-}
-#endif /* defined(CONFIG_DEBUG_FS)  defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) 
*/
-
-static int dss_get_clock(struct clk **clock, const char *clk_name)
-{
-   struct clk *clk;
-
-   clk = clk_get(core.pdev-dev, clk_name);
-
-   if (IS_ERR(clk)) {
-   DSSERR(can't get clock %s, clk_name);
-   return PTR_ERR(clk);
-   }
-
-   *clock = clk;
-
-   DSSDBG(clk %s, rate %ld\n, clk_name, clk_get_rate(clk));
-
-   return 0;
-}
-
-static int dss_get_clocks(void)
-{
-   int r;
-
-   core.dss_ick = NULL;
-   core.dss1_fck = NULL;
-   core.dss2_fck = NULL;
-   core.dss_54m_fck = NULL;
-   core.dss_96m_fck = NULL;
-
-   r = dss_get_clock(core.dss_ick, ick);
-   if (r)
-   goto err;
-
-   r = dss_get_clock(core.dss1_fck, dss1_fck);
-   if (r)
-   goto err;
-
-   r = dss_get_clock(core.dss2_fck, dss2_fck);
-   if (r)
-   goto err;
-
-   r =

[PATCH v1 11/16] OMAP3: hwmod DSS: RFBI Move init,exit to driver

From: Senthilvadivu Guruswamy svad...@ti.com

Move init exit methods to its driver probe,remove.
pdev member has to be maintained by its own drivers.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/core.c |9 -
 drivers/video/omap2/dss/rfbi.c |   14 +-
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 54fe333..cc7a5f1 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -193,12 +193,6 @@ static int omap_dss_probe(struct platform_device *pdev)
 
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
 
-   r = rfbi_init();
-   if (r) {
-   DSSERR(Failed to initialize rfbi\n);
-   goto err_rfbi;
-   }
-
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
@@ -272,8 +266,6 @@ err_venc:
 err_dispc:
dpi_exit();
 err_dpi:
-   rfbi_exit();
-err_rfbi:
 
return r;
 }
@@ -288,7 +280,6 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
-   rfbi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 23598ea..9bee39d 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings *t);
 static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
 
 static struct {
+   struct platform_device *pdev;
void __iomem*base;
 
unsigned long   l4_khz;
@@ -142,11 +143,22 @@ static inline u32 rfbi_read_reg(const struct rfbi_reg idx)
 /* RFBI HW IP initialisation */
 static int omap_rfbihw_probe(struct platform_device *pdev)
 {
-   return 0;
+   int r;
+   rfbi.pdev = pdev;
+
+   r = rfbi_init();
+   if (r) {
+   DSSERR(Failed to initialize rfbi\n);
+   goto err_rfbi;
+   }
+
+err_rfbi:
+   return r;
 }
 
 static int omap_rfbihw_remove(struct platform_device *pdev)
 {
+   rfbi_exit();
return 0;
 }
 
-- 
1.6.3.3

--
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 v1 08/16] OMAP3: clock data: change dss driver name

From: Senthilvadivu Guruswamy svad...@ti.com

Change the dss driver name from omapdss to dss_dss
in the clock database.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 arch/arm/mach-omap2/clock3xxx_data.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index c73906d..4e85d03 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3320,13 +3320,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_rng, ick,  rng_ick,   CK_343X),
CLK(NULL,   sha11_ick,sha11_ick, CK_343X),
CLK(NULL,   des1_ick, des1_ick,  CK_343X),
-   CLK(omapdss,  dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
-   CLK(omapdss,  dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 | 
CK_AM35XX),
-   CLK(omapdss,  tv_fck,   dss_tv_fck,CK_3XXX),
-   CLK(omapdss,  video_fck,dss_96m_fck,   CK_3XXX),
-   CLK(omapdss,  dss2_fck, dss2_alwon_fck, CK_3XXX),
-   CLK(omapdss,  ick,  dss_ick_3430es1,   CK_3430ES1),
-   CLK(omapdss,  ick,  dss_ick_3430es2,   CK_3430ES2 | 
CK_AM35XX),
+   CLK(dss_dss,  dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+   CLK(dss_dss,  dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2 | 
CK_AM35XX),
+   CLK(dss_dss,  tv_fck,   dss_tv_fck,CK_3XXX),
+   CLK(dss_dss,  video_fck,dss_96m_fck,   CK_3XXX),
+   CLK(dss_dss,  dss2_fck, dss2_alwon_fck, CK_3XXX),
+   CLK(dss_dss,  ick,  dss_ick_3430es1,   CK_3430ES1),
+   CLK(dss_dss,  ick,  dss_ick_3430es2,   CK_3430ES2 | 
CK_AM35XX),
CLK(NULL,   cam_mclk, cam_mclk,  CK_343X),
CLK(NULL,   cam_ick,  cam_ick,   CK_343X),
CLK(NULL,   csi2_96m_fck, csi2_96m_fck,  CK_343X),
-- 
1.6.3.3

--
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 v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP

From: Senthilvadivu Guruswamy svad...@ti.com

Platform driver of dsshw has to be registered before of dispc,
rfbi, dsi1, venc and omapdisplay driver should be after all
the hw IPs. Sequence it with arch_initcall and device_initcall_sync.
---
 drivers/video/omap2/dss/core.c  |2 +-
 drivers/video/omap2/dss/dispc.c |   28 
 drivers/video/omap2/dss/dsi.c   |   28 
 drivers/video/omap2/dss/dss.c   |   30 ++
 drivers/video/omap2/dss/rfbi.c  |   29 +
 drivers/video/omap2/dss/venc.c  |   28 
 6 files changed, 144 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 0f267e6..7810a40 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -986,7 +986,7 @@ static int __init omap_dss_init2(void)
 }
 
 core_initcall(omap_dss_init);
-device_initcall(omap_dss_init2);
+device_initcall_sync(omap_dss_init2);
 #endif
 
 MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5ecdc00..e48c6fa 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -186,6 +186,26 @@ static inline u32 dispc_read_reg(const struct dispc_reg 
idx)
return __raw_readl(dispc.base + idx.idx);
 }
 
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+   .probe  = omap_dispchw_probe,
+   .remove = omap_dispchw_remove,
+   .driver = {
+   .name   = dss_dispc,
+   .owner  = THIS_MODULE,
+   },
+};
+
 #define SR(reg) \
dispc.ctx[(DISPC_##reg).idx / sizeof(u32)] = dispc_read_reg(DISPC_##reg)
 #define RR(reg) \
@@ -3187,3 +3207,11 @@ int dispc_setup_plane(enum omap_plane plane,
 
return r;
 }
+
+static int __init omap_dispc_init(void)
+{
+   return platform_driver_register(omap_dispchw_driver);
+}
+
+device_initcall(omap_dispc_init);
+
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b3fa3a7..fd49663 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -292,6 +292,26 @@ static inline u32 dsi_read_reg(const struct dsi_reg idx)
return __raw_readl(dsi.base + idx.idx);
 }
 
+/* DSI1 HW IP initialisation */
+static int omap_dsi1hw_probe(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static int omap_dsi1hw_remove(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static struct platform_driver omap_dsi1hw_driver = {
+   .probe  = omap_dsi1hw_probe,
+   .remove = omap_dsi1hw_remove,
+   .driver = {
+   .name   = dss_dsi1,
+   .owner  = THIS_MODULE,
+   },
+};
+
 
 void dsi_save_context(void)
 {
@@ -3305,3 +3325,11 @@ void dsi_exit(void)
DSSDBG(omap_dsi_exit\n);
 }
 
+static int __init omap_dsi1_init(void)
+{
+   return platform_driver_register(omap_dsi1hw_driver);
+}
+
+device_initcall(omap_dsi1_init);
+
+
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..66ef804 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -86,6 +86,29 @@ static inline u32 dss_read_reg(const struct dss_reg idx)
return __raw_readl(dss.base + idx.idx);
 }
 
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+   .probe  = omap_dsshw_probe,
+   .remove = omap_dsshw_remove,
+   .shutdown   = NULL,
+   .suspend= NULL,
+   .resume = NULL,
+   .driver = {
+   .name   = dss,
+   .owner  = THIS_MODULE,
+   },
+};
+
 #define SR(reg) \
dss.ctx[(DSS_##reg).idx / sizeof(u32)] = dss_read_reg(DSS_##reg)
 #define RR(reg) \
@@ -639,3 +662,10 @@ void dss_exit(void)
iounmap(dss.base);
 }
 
+static int __init omap_dss_init1(void)
+{
+   return platform_driver_register(omap_dsshw_driver);
+}
+
+arch_initcall(omap_dss_init1);
+
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index bbe6246..23598ea 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -139,6 +139,27 @@ static inline u32 rfbi_read_reg(const struct rfbi_reg idx)
return __raw_readl(rfbi.base + idx.idx);
 }
 
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static int omap_rfbihw_remove(struct platform_device *pdev)
+{
+

[PATCH v1 10/16] OMAP3: hwmod DSS: DSS Move init,exit to driver

From: Senthilvadivu Guruswamy svad...@ti.com

Move init exit methods to its driver probe remove.
pdev member has to be maintained by its own drivers.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 drivers/video/omap2/dss/core.c |   16 
 drivers/video/omap2/dss/dss.c  |   16 
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index ce5240f..54fe333 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -193,18 +193,6 @@ static int omap_dss_probe(struct platform_device *pdev)
 
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
 
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
-   /* DISPC_CONTROL */
-   if (omap_readl(0x48050440)  1) /* LCD enabled? */
-   skip_init = 1;
-#endif
-
-   r = dss_init(skip_init);
-   if (r) {
-   DSSERR(Failed to initialize DSS\n);
-   goto err_dss;
-   }
-
r = rfbi_init();
if (r) {
DSSERR(Failed to initialize rfbi\n);
@@ -286,8 +274,6 @@ err_dispc:
 err_dpi:
rfbi_exit();
 err_rfbi:
-   dss_exit();
-err_dss:
 
return r;
 }
@@ -308,8 +294,6 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
 
-   dss_exit();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
 
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index fba8bcd..b93b118 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -410,6 +410,7 @@ void dss_debug_dump_clocks(struct seq_file *s)
 static int omap_dsshw_probe(struct platform_device *pdev)
 {
int r;
+   int skip_init = 0;
 
dss.pdev = pdev;
 
@@ -422,6 +423,19 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss.ctx_id = dss_get_ctx_id();
DSSDBG(initial ctx id %u\n, dss.ctx_id);
 
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+   /* DISPC_CONTROL */
+   if (omap_readl(0x48050440)  1) /* LCD enabled? */
+   skip_init = 1;
+#endif
+
+   r = dss_init(skip_init);
+   if (r) {
+   DSSERR(Failed to initialize DSS\n);
+   goto err_dss;
+   }
+
+err_dss:
dss_clk_disable_all_no_ctx();
 err_clocks:
 
@@ -432,6 +446,8 @@ static int omap_dsshw_remove(struct platform_device *pdev)
 {
int c;
 
+   dss_exit();
+
/* these should be removed at some point */
c = dss.dss_ick-usecount;
if (c  0) {
-- 
1.6.3.3

--
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 v1 06/16] OMAP3: hwmod DSS: Build omap_device for each DSS HWIP

From: Senthilvadivu Guruswamy svad...@ti.com

Looks up the HWMOD database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 arch/arm/mach-omap2/devices.c |   46 +
 arch/arm/plat-omap/include/plat/display.h |   10 ++
 2 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0702b87..7a75310 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,8 @@
 #include plat/mmc.h
 #include plat/dma.h
 #include plat/display.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
 
 #include mux.h
 
@@ -896,9 +898,53 @@ static struct platform_device omap_display_device = {
},
 };
 
+static struct omap_device_pm_latency omap_dss_latency[] = {
+   [0] = {
+   .deactivate_func= omap_device_idle_hwmods,
+   .activate_func  = omap_device_enable_hwmods,
+   },
+};
+
 void __init omap_display_init(struct omap_dss_board_info
*board_data)
 {
+   struct omap_hwmod *oh;
+   struct omap_device *od;
+   int l, i;
+   struct omap_display_platform_data pdata;
+   char *oh_name[] = {
+   dss_dss,
+   dss_dispc,
+   dss_dsi1,
+   dss_rfbi,
+   dss_venc
+   };
+
+   for (i = 0; i  ARRAY_SIZE(oh_name); i++) {
+   l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
+oh_name[i]);
+   WARN(l = MAX_OMAP_DSS_HWMOD_NAME_LEN,
+   String buffer overflow in DSS device setup\n);
+
+   oh = omap_hwmod_lookup(oh_name[i]);
+   if (!oh) {
+   pr_err(Could not look up %s\n, oh_name[i]);
+   return ;
+   }
+   strncpy(pdata.name, oh_name[i], sizeof(oh_name[i]));
+   pdata.board_data=   board_data;
+   pdata.board_data-get_last_off_on_transaction_id = NULL;
+   pdata.device_enable=   omap_device_enable;
+   pdata.device_idle  =   omap_device_idle;
+   pdata.device_shutdown  =   omap_device_shutdown;
+   od = omap_device_build(oh_name[i], -1, oh, pdata,
+   sizeof(struct omap_display_platform_data),
+   omap_dss_latency,
+   ARRAY_SIZE(omap_dss_latency), 0);
+
+   WARN((IS_ERR(od)), Could not build omap_device for %s\n,
+   oh_name[i]);
+   }
 
omap_display_device.dev.platform_data = board_data;
 
diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 4b71be3..84a63de 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -26,6 +26,8 @@
 #include linux/platform_device.h
 #include asm/atomic.h
 
+#define MAX_OMAP_DSS_HWMOD_NAME_LEN 16
+
 #define DISPC_IRQ_FRAMEDONE(1  0)
 #define DISPC_IRQ_VSYNC(1  1)
 #define DISPC_IRQ_EVSYNC_EVEN  (1  2)
@@ -255,6 +257,14 @@ struct omap_dss_board_info {
 /* Init with the board info */
 extern void omap_display_init(struct omap_dss_board_info *board_data);
 
+struct omap_display_platform_data {
+   char name[MAX_OMAP_DSS_HWMOD_NAME_LEN];
+   struct omap_dss_board_info *board_data;
+   int (*device_enable)(struct platform_device *pdev);
+   int (*device_shutdown)(struct platform_device *pdev);
+   int (*device_idle)(struct platform_device *pdev);
+};
+
 struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
-- 
1.6.3.3

--
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 v1 05/16] OMAP3 DSS Driver register moved to mach_omap2

From: Senthilvadivu Guruswamy svad...@ti.com

Move DSS driver register from board file to devices.c
Regulator initialisation done with driver name instead
of device name.
Changed device name from omapdss to omapdisplay as the
driver takes care of panel information.

Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
 arch/arm/mach-omap2/board-3430sdp.c   |   25 +++---
 arch/arm/mach-omap2/devices.c |   32 +
 arch/arm/plat-omap/include/plat/display.h |4 +++
 drivers/video/omap2/dss/core.c|2 +-
 4 files changed, 41 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 3eb9839..62b6523 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,22 +302,8 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = sdp3430_lcd_device,
 };
 
-static struct platform_device sdp3430_dss_device = {
-   .name   = omapdss,
-   .id = -1,
-   .dev= {
-   .platform_data = sdp3430_dss_data,
-   },
-};
-
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
-   .supply = vdda_dac,
-   .dev= sdp3430_dss_device.dev,
-};
-
-static struct platform_device *sdp3430_devices[] __initdata = {
-   sdp3430_dss_device,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+   REGULATOR_SUPPLY(vdda_dac, omapdisplay);
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
 };
@@ -541,10 +527,7 @@ static struct regulator_init_data sdp3430_vdac = {
 
 /* VPLL2 for digital video outputs */
 static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
-   {
-   .supply = vdds_dsi,
-   .dev= sdp3430_dss_device.dev,
-   }
+   REGULATOR_SUPPLY(vdds_dsi, omapdisplay),
 };
 
 static struct regulator_init_data sdp3430_vpll2 = {
@@ -798,7 +781,7 @@ static void __init omap_3430sdp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
-   platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+   omap_display_init(sdp3430_dss_data);
if (omap_rev()  OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9e5d51b..0702b87 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,7 @@
 #include mach/gpio.h
 #include plat/mmc.h
 #include plat/dma.h
+#include plat/display.h
 
 #include mux.h
 
@@ -885,6 +886,37 @@ static inline void omap_hdq_init(void) {}
 #endif
 
 /*---*/
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+   .name  = omapdisplay,
+   .id= -1,
+   .dev= {
+   .platform_data = NULL,
+   },
+};
+
+void __init omap_display_init(struct omap_dss_board_info
+   *board_data)
+{
+
+   omap_display_device.dev.platform_data = board_data;
+
+   if (platform_device_register(omap_display_device)  0)
+   printk(KERN_ERR Unable to register OMAP-Display device\n);
+
+
+   return ;
+}
+
+#else
+void __init omap_display_init(struct omap_dss_board_info *board_data)
+{
+}
+#endif
+
+
+/*---*/
 
 #if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 8bd15bd..4b71be3 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
 #include linux/list.h
 #include linux/kobject.h
 #include linux/device.h
+#include linux/platform_device.h
 #include asm/atomic.h
 
 #define DISPC_IRQ_FRAMEDONE(1  0)
@@ -251,6 +252,9 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
 };
 
+/* Init with the board info */
+extern void omap_display_init(struct omap_dss_board_info *board_data);
+
 struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b3a498f..0f267e6 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -712,7 +712,7 @@ static struct platform_driver omap_dss_driver = {
.suspend= omap_dss_suspend,
.resume = omap_dss_resume,
.driver = {
-   .name   = omapdss,
+   .name   = omapdisplay,
.owner  = THIS_MODULE,
},
 };
-- 
1.6.3.3

--
To unsubscribe from this list: send the line

Re: [PATCH 5/6] save and restore etm state across core OFF modes

2010-10-06 Thread Eduardo Valentin

Hey,

I think Gowda had also some thoughts about this patch. Cc'ing him.

BR,
On Wed, Oct 06, 2010 at 10:35:09AM +0200, Valentin Eduardo (Nokia-D/Helsinki) 
wrote:
 Hello Alexander,
 
 Few points as follows,
 
 On Sat, May 01, 2010 at 07:38:20PM +0200, ext virtu...@slind.org wrote:
  From: Alexander Shishkin virtu...@slind.org
  
  This prevents ETM stalls whenever core enters OFF mode. Original patch
  author is Richard Woodruff r-woodru...@ti.com.
  
  This version of the patch makes use of the ETM OS save/restore mechanism,
  which takes about 55 words in omap3_arm_context[] instead of 128. Also,
  saving ETM context can be switched on/off at runtime.
  
  Signed-off-by: Alexander Shishkin virtu...@slind.org
  CC: Richard Woodruff r-woodru...@ti.com
  ---
   arch/arm/mach-omap2/Kconfig   |9 ++
   arch/arm/mach-omap2/control.c |2 +-
   arch/arm/mach-omap2/sleep34xx.S   |  135 
  +
   arch/arm/plat-omap/include/plat/control.h |2 +-
   4 files changed, 146 insertions(+), 2 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
  index 2455dcc..5460bfe 100644
  --- a/arch/arm/mach-omap2/Kconfig
  +++ b/arch/arm/mach-omap2/Kconfig
  @@ -150,6 +150,15 @@ config MACH_OMAP_4430SDP
  bool OMAP 4430 SDP board
  depends on ARCH_OMAP4
   
  +config ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   bool Enable hardware emulation context save and restore
  +   depends on ARCH_OMAP3
  +   default y
  +   help
  + This option enables JTAG  ETM debugging across power states.
  + With out this option emulation features are reset across OFF
  + mode state changes.
  +
   config OMAP3_EMU
  bool OMAP3 debugging peripherals
  depends on ARCH_OMAP3
  diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
  index 43f8a33..70b1674 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -93,7 +93,7 @@ void *omap3_secure_ram_storage;
* The address is stored in scratchpad, so that it can be used
* during the restore path.
*/
  -u32 omap3_arm_context[128];
  +u32 omap3_arm_context[256];
   
   struct omap3_control_regs {
  u32 sysconfig;
  diff --git a/arch/arm/mach-omap2/sleep34xx.S 
  b/arch/arm/mach-omap2/sleep34xx.S
  index d522cd7..cd6a1d4 100644
  --- a/arch/arm/mach-omap2/sleep34xx.S
  +++ b/arch/arm/mach-omap2/sleep34xx.S
  @@ -28,6 +28,7 @@
   #include asm/assembler.h
   #include mach/io.h
   #include plat/control.h
  +#include asm/hardware/coresight.h
   
   #include cm.h
   #include prm.h
  @@ -226,6 +227,18 @@ loop:
  nop
  bl wait_sdrc_ok
   
  +#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   /*
  +* Restore Coresight debug registers
  +*/
  +   ldr r6, debug_vbase /* base Vaddr of CortexA8-Debug */
  +   ldr r4, debug_xlar_key  /* get lock key for OSLAR */
  +   bl  unlock_debug/* remove global lock if set */
  +   ldr r6, etm_vbase   /* base Vaddr of ETM */
  +   bl  unlock_debug/* remove global lock if set */
  +   str r6, [r6, #ETMMR_OSLAR]  /* clear OSLAR lock using non-key */
  +#endif
  +
  ldmfd   sp!, {r0-r12, pc}   @ restore regs and return
   restore_es3:
  /*b restore_es3*/   @ Enable to debug restore code
  @@ -385,6 +398,44 @@ logic_l1_restore:
  /*normal memory remap register */
  MCR p15, 0, r5, c10, c2, 1
   
  +#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   /*
  +* Restore Coresight debug registers
  +*/
  +   ldr r6, debug_pbase /* base paddr of CortexA8-Debug */
  +   ldr r4, debug_xlar_key  /* get lock key for OSLAR */
  +   bl  unlock_debug/* remove global lock if set */
  +   str r4, [r6, #ETMMR_OSLAR]  /* reset-pointer (already locked) */
  +   ldr r4, [r6, #ETMMR_OSSRR]  /* dummy read */
  +   ldr r4, [r3], #4/* load save size */
  +   cmp r4, #0  /* check for zero */
  +debug_restore:
  +   itttne  /* t2/compat if-then block */
  +   ldrne   r5, [r3], #4/* get saved value */
  +   strne   r5, [r6,#ETMMR_OSSRR]   /* restore saved value */
  +   subnes  r4, r4, #1  /* decrement loop */
  +   bne debug_restore   /* loop till done */
  +   str r5, [r6, #ETMMR_OSSRR]  /* clear lock */
 
 Maybe you mean ETMMR_OSLAR?
 
  +   /*
  +* Restore CoreSight ETM registers
  +*/
  +   ldr r6, etm_pbase   /* base paddr of ETM */
  +   ldr r4, debug_xlar_key  /* get lock key for OSLAR */
  +   bl  unlock_debug/* remove global lock if set */
  +   str r4, [r6, #ETMMR_OSLAR]  /* reset-pointer (already locked) */
  +   ldr r4, [r6, #ETMMR_OSSRR]  /* dummy read */
  +   ldr r4, [r3], #4/* load save size */
  +   cmp r4, #0  /* check for zero */
  +   beq

Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread Steve Sakoman

On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport m...@compulab.co.il wrote:

 I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck.
 The changes Adrian has made to the interrupt synchronization  affect the way
 the
 SDIO irq should be implemented and I haven't found a way to resolve it :-(

I tried my hand at making the patch apply on 2.6.35:

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=51b802d73191c306618cddefbd63379c839589f5

It seems to work, but I'm pretty sure I must have messed something up
because I get error messages every once in a while:

libertas: tx watch dog timeout

I don't recall seeing these with the original version of the patch :-(

Suggestions as to where I went wrong are welcome!

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

RE: [PATCH 5/6] save and restore etm state across core OFF modes

2010-10-06 Thread ext-madhusudhan.1.gowda

Hi,

  +   bne debug_restore   /* loop till done */
  +   str r5, [r6, #ETMMR_OSSRR]  /* clear lock */
I had informed Alexander about the missing OSLAR  to clear the lock and also 
the do_etm_save value does not retain across coreoff since sram size may vary 
across coreoffs. We need to save this do_etm_save value to sdram along with the 
jtag etm debug context and restore it to do_etm_save.

Thanks
Gowda



From: Eduardo Valentin [eduardo.valen...@nokia.com]
Sent: Wednesday, October 06, 2010 2:22 PM
To: Valentin Eduardo (Nokia-MS/Helsinki)
Cc: ext virtu...@slind.org; t...@atomide.com; linux-omap@vger.kernel.org; 
khil...@deeprootsystems.com; r-woodru...@ti.com; Gowda Madhusudhan.1 
(EXT-Elektrobit/Helsinki)
Subject: Re: [PATCH 5/6] save and restore etm state across core OFF modes

Hey,

I think Gowda had also some thoughts about this patch. Cc'ing him.

BR,
On Wed, Oct 06, 2010 at 10:35:09AM +0200, Valentin Eduardo (Nokia-D/Helsinki) 
wrote:
 Hello Alexander,

 Few points as follows,

 On Sat, May 01, 2010 at 07:38:20PM +0200, ext virtu...@slind.org wrote:
  From: Alexander Shishkin virtu...@slind.org
 
  This prevents ETM stalls whenever core enters OFF mode. Original patch
  author is Richard Woodruff r-woodru...@ti.com.
 
  This version of the patch makes use of the ETM OS save/restore mechanism,
  which takes about 55 words in omap3_arm_context[] instead of 128. Also,
  saving ETM context can be switched on/off at runtime.
 
  Signed-off-by: Alexander Shishkin virtu...@slind.org
  CC: Richard Woodruff r-woodru...@ti.com
  ---
   arch/arm/mach-omap2/Kconfig   |9 ++
   arch/arm/mach-omap2/control.c |2 +-
   arch/arm/mach-omap2/sleep34xx.S   |  135 
  +
   arch/arm/plat-omap/include/plat/control.h |2 +-
   4 files changed, 146 insertions(+), 2 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
  index 2455dcc..5460bfe 100644
  --- a/arch/arm/mach-omap2/Kconfig
  +++ b/arch/arm/mach-omap2/Kconfig
  @@ -150,6 +150,15 @@ config MACH_OMAP_4430SDP
  bool OMAP 4430 SDP board
  depends on ARCH_OMAP4
 
  +config ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   bool Enable hardware emulation context save and restore
  +   depends on ARCH_OMAP3
  +   default y
  +   help
  + This option enables JTAG  ETM debugging across power states.
  + With out this option emulation features are reset across OFF
  + mode state changes.
  +
   config OMAP3_EMU
  bool OMAP3 debugging peripherals
  depends on ARCH_OMAP3
  diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
  index 43f8a33..70b1674 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -93,7 +93,7 @@ void *omap3_secure_ram_storage;
* The address is stored in scratchpad, so that it can be used
* during the restore path.
*/
  -u32 omap3_arm_context[128];
  +u32 omap3_arm_context[256];
 
   struct omap3_control_regs {
  u32 sysconfig;
  diff --git a/arch/arm/mach-omap2/sleep34xx.S 
  b/arch/arm/mach-omap2/sleep34xx.S
  index d522cd7..cd6a1d4 100644
  --- a/arch/arm/mach-omap2/sleep34xx.S
  +++ b/arch/arm/mach-omap2/sleep34xx.S
  @@ -28,6 +28,7 @@
   #include asm/assembler.h
   #include mach/io.h
   #include plat/control.h
  +#include asm/hardware/coresight.h
 
   #include cm.h
   #include prm.h
  @@ -226,6 +227,18 @@ loop:
  nop
  bl wait_sdrc_ok
 
  +#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   /*
  +* Restore Coresight debug registers
  +*/
  +   ldr r6, debug_vbase /* base Vaddr of CortexA8-Debug */
  +   ldr r4, debug_xlar_key  /* get lock key for OSLAR */
  +   bl  unlock_debug/* remove global lock if set */
  +   ldr r6, etm_vbase   /* base Vaddr of ETM */
  +   bl  unlock_debug/* remove global lock if set */
  +   str r6, [r6, #ETMMR_OSLAR]  /* clear OSLAR lock using non-key */
  +#endif
  +
  ldmfd   sp!, {r0-r12, pc}   @ restore regs and return
   restore_es3:
  /*b restore_es3*/   @ Enable to debug restore code
  @@ -385,6 +398,44 @@ logic_l1_restore:
  /*normal memory remap register */
  MCR p15, 0, r5, c10, c2, 1
 
  +#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
  +   /*
  +* Restore Coresight debug registers
  +*/
  +   ldr r6, debug_pbase /* base paddr of CortexA8-Debug */
  +   ldr r4, debug_xlar_key  /* get lock key for OSLAR */
  +   bl  unlock_debug/* remove global lock if set */
  +   str r4, [r6, #ETMMR_OSLAR]  /* reset-pointer (already locked) */
  +   ldr r4, [r6, #ETMMR_OSSRR]  /* dummy read */
  +   ldr r4, [r3], #4/* load save size */
  +   cmp r4, #0  /* check for zero */
  +debug_restore:
  +   itttne  /* t2/compat if-then block */
  +   ldrne   r5, [r3],

RE: [PATCH v2 1/2] V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 1/2] V4L/DVB: OMAP_VOUT: Create a seperate vrfb
 functions library

 Create omap_vout_vrfb.c and omap_vout_vrfb.h, these contain functions
 which
 omap_vout will call if the rotation type is set to VRFB rotation. It is
 essentialy the code in omap_vout which is used for vrfb specific tasks.

 Apart from this, some functions and preprocessor defines needed by the new
 vrfb function's have been moved around.

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c  |   32 +--
  drivers/media/video/omap/omap_vout_vrfb.c |  417
 +
  drivers/media/video/omap/omap_vout_vrfb.h |   40 +++
  drivers/media/video/omap/omap_voutdef.h   |   25 ++
  4 files changed, 490 insertions(+), 24 deletions(-)
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h

 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 4ed51b1..46bc642
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -56,7 +56,6 @@ MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
  MODULE_LICENSE(GPL);

 -
  /* Driver Configuration macros */
  #define VOUT_NAMEomap_vout

 @@ -65,28 +64,13 @@ enum omap_vout_channels {
   OMAP_VIDEO2,
  };

 -enum dma_channel_state {
 - DMA_CHAN_NOT_ALLOTED,
 - DMA_CHAN_ALLOTED,
 -};
 -
  #define QQVGA_WIDTH  160
  #define QQVGA_HEIGHT 120

 -/* Max Resolution supported by the driver */
 -#define VID_MAX_WIDTH1280/* Largest width */
 -#define VID_MAX_HEIGHT   720 /* Largest height */
 -
[Hiremath, Vaibhav] I wanted to get rid of this sometime, but as of now we can 
live with this.

I would suggest to move QQVGA_xxx macros to header file to keep consistency.

  /* Mimimum requirement is 2x2 for DSS */
  #define VID_MIN_WIDTH2
  #define VID_MIN_HEIGHT   2

 -/* 2048 x 2048 is max res supported by OMAP display controller */
 -#define MAX_PIXELS_PER_LINE 2048
 -
 -#define VRFB_TX_TIMEOUT 1000
 -#define VRFB_NUM_BUFS4
 -
  /* Max buffer size tobe allocated during init */
  #define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)

 @@ -96,8 +80,8 @@ static u32 video1_numbuffers = 3;
  static u32 video2_numbuffers = 3;
  static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
 -static u32 vid1_static_vrfb_alloc;
 -static u32 vid2_static_vrfb_alloc;
 +u32 vid1_static_vrfb_alloc;
 +u32 vid2_static_vrfb_alloc;
[Hiremath, Vaibhav] Don't make this variable extern; I think these variables 
are being used during init time only so you can pass it as function argument.

  static int debug;

  /* Module parameters */
 @@ -174,7 +158,7 @@ const static struct v4l2_fmtdesc omap_formats[] = {
  /*
   * Allocate buffers
   */
 -static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
 +unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
[Hiremath, Vaibhav] This function can be moved to omap_voutlib.c file since it 
is something generic and independent.

  {
   u32 order, size;
   unsigned long virt_addr, addr;
 @@ -198,7 +182,7 @@ static unsigned long omap_vout_alloc_buffer(u32
 buf_size, u32 *phys_addr)
  /*
   * Free buffers
   */
 -static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
 +void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
  {
[Hiremath, Vaibhav] same here.

   u32 order, size;
   unsigned long addr = virtaddr;
 @@ -371,7 +355,7 @@ static void omap_vout_release_vrfb(struct
 omap_vout_device *vout)
  /*
   * Return true if rotation is 90 or 270
   */
 -static inline int rotate_90_or_270(const struct omap_vout_device *vout)
 +int rotate_90_or_270(const struct omap_vout_device *vout)
  {
[Hiremath, Vaibhav] You can move this to header file keeping it inline.
   return (vout-rotation == dss_rotation_90_degree ||
   vout-rotation == dss_rotation_270_degree);
 @@ -380,7 +364,7 @@ static inline int rotate_90_or_270(const struct
 omap_vout_device *vout)
  /*
   * Return true if rotation is enabled
   */
 -static inline int rotation_enabled(const struct omap_vout_device *vout)
 +int rotation_enabled(const struct omap_vout_device *vout)
[Hiremath, Vaibhav] ditto here.

  {
   return vout-rotation || vout-mirror;
  }
 @@ -388,7 +372,7 @@ static inline int rotation_enabled(const struct
 omap_vout_device *vout)
  /*
   * Reverse the rotation degree if mirroring is enabled
   */
 -static inline int calc_rotation(const struct omap_vout_device *vout)
 +int calc_rotation(const struct

Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread Mike Rapoport


Hi Steve,
Steve Sakoman wrote:

On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport m...@compulab.co.il wrote:


I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck.
The changes Adrian has made to the interrupt synchronization  affect the way
the
SDIO irq should be implemented and I haven't found a way to resolve it :-(


I tried my hand at making the patch apply on 2.6.35:

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=51b802d73191c306618cddefbd63379c839589f5


This one fails to build:

  CC  drivers/mmc/host/omap_hsmmc.o
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_start_command': 

drivers/mmc/host/omap_hsmmc.c:791: warning: unused variable 'int_en_mask' 

drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_do_irq': 

drivers/mmc/host/omap_hsmmc.c:1023: error: label 'out' used but not defined 

drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_irq': 

drivers/mmc/host/omap_hsmmc.c:1101: warning: label 'out' defined but not used 

drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend': 

drivers/mmc/host/omap_hsmmc.c:2346: warning: unused variable 'state' 


make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1

Moving the 'out' label where I believe it should live I get:
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
libertas: command 0x0003 timed out
libertas: Timeout submitting command 0x0003
libertas: PREP_CMD: command 0x0003 failed: -110
libertas_sdio: probe of mmc1:0001:1 failed with error -110



It seems to work, but I'm pretty sure I must have messed something up
because I get error messages every once in a while:

libertas: tx watch dog timeout

I don't recall seeing these with the original version of the patch :-(

Suggestions as to where I went wrong are welcome!


I've applied the patch almost the same way you did and I was not able to get 
any further than the point above (command 0x0003 timed out). As far as I 
understand, what we have now is that omap_hsmmc_request_done() calls 
omap_hsmmc_disable_irq() and the interrupts that come from the 8686 _between_ 
requests are simply missed. Whatever I've tried to keep the SDIO interrupts on 
didn't help... :(



Steve



--
Sincerely yours,
Mike.
--
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] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread John W. Linville

On Tue, Oct 05, 2010 at 11:39:47PM +0300, Luciano Coelho wrote:
 On Tue, 2010-10-05 at 15:19 +0200, ext Luciano Coelho wrote:
  On Tue, 2010-10-05 at 14:07 +0200, ext Luciano Coelho wrote:
   On Tue, 2010-10-05 at 13:53 +0200, ext Luciano Coelho wrote:
On Sat, 2010-10-02 at 01:10 +0200, ext Tony Lindgren wrote:
 * Anand Gadiyar gadi...@ti.com [101001 13:25]:
  Patch omap: zoom: add mmc3/wl1271 device support in the
  wireless tree still uses .wires in struct omap2_hsmmc_info.
  .wires has now been replaced with .caps in patch omap: mmc:
  extended to pass host capabilities from board file in the
  OMAP tree.
  
  This causes linux-next as of 20101001 build to break as
  below. Fix this.
  
CC  arch/arm/mach-omap2/board-zoom-peripherals.o
  arch/arm/mach-omap2/board-zoom-peripherals.c:217: error: unknown 
  field 'wires' specified in initializer
  make[1]: *** [arch/arm/mach-omap2/board-zoom-peripherals.o] Error 1
  make: *** [arch/arm/mach-omap2] Error 2
 
 Can you guys please queue this via the wireless tree along with
 the other wl1271 patches?
 
 Acked-by: Tony Lindgren t...@atomide.com

I can apply this to the wl12xx tree.  I just need John's confirmation.  

The pull request I sent to John last week is still pending.  I don't
know if it is possible to substitute it for a newer one with more
patches (and still try to make it to 2.6.37).  What do you think, John?
   
   Damn, for some reason I had a bug in John's email in my contact book.
   Now sending to the correct email address.
  
  Applied to the wl12xx tree.  I'll send a new replacement pull to John
  today, including this patch.  Thanks.
 
 Hmmm... We got a problem here.  This patch breaks builds when we *don't*
 have omap: mmc extended to pass host capabilities from board file.  We
 don't have that on wireless-next yet, so builds with zoom boards
 selected are broken.
 
 Any ideas on how to solve this dilemma? I guess the proper way to handle
 this would be to make the changes proposed in this patch when merging
 instead of having a normal commit for it, wouldn't it?

Just cherry-pick that change into the branch of your tree that I do
_not_ pull from.  I presume that it is already available in linux-next?

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread Gadiyar, Anand

 Hmmm... We got a problem here.  This patch breaks builds when we *don't*
 have omap: mmc extended to pass host capabilities from board file.  We
 don't have that on wireless-next yet, so builds with zoom boards
 selected are broken.

 Any ideas on how to solve this dilemma? I guess the proper way to handle
 this would be to make the changes proposed in this patch when merging
 instead of having a normal commit for it, wouldn't it?

 Just cherry-pick that change into the branch of your tree that I do
 _not_ pull from.  I presume that it is already available in linux-next?


Yup - both patches are in linux-next; that's where we noticed the build break.

- Anand
--
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 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build without VRFB

2010-10-06 Thread Hiremath, Vaibhav

 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 0/2] V4L/DVB: OMAP_VOUT: Allow omap_vout to build
 without VRFB
 
 This lets omap_vout driver build and run without VRFB. It works along the
 lines of the following patch series:
 
 OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB
 https://patchwork.kernel.org/patch/105371/
 
 Since VRFB is tightly coupled with the omap_vout driver, a handful of vrfb
 specific functions have been defined and placed in omap_vout_vrfb.c
 
 A variable rotation_type is introduced in omapvideo_info like the way in
 omapfb_info, this allows to call vrfb specific functions only if the
 rotation
 type is vrfb. When the rotation_type is set to SDMA, the S_CTRL ioctl
 prevents
 the user setting a non zero rotation value.
 
[Hiremath, Vaibhav] Lets make one stand here,

I think this series still doesn't support DMA based rotation, unlike Fbdev 
driver so I would say lets clearly state that we are not supporting sDMA based 
rotation here. So I don't see any reason why we need 

 Archit Taneja (2):
   V4L/DVB: OMAP_VOUT: Create a seperate vrfb functions library
   V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and
 sdram buffers
 
  drivers/media/video/omap/Kconfig  |1 -
  drivers/media/video/omap/Makefile |1 +
  drivers/media/video/omap/omap_vout.c  |  480 ++--
 -
  drivers/media/video/omap/omap_vout_vrfb.c |  417
 +
  drivers/media/video/omap/omap_vout_vrfb.h |   40 +++
  drivers/media/video/omap/omap_voutdef.h   |   26 ++
  6 files changed, 571 insertions(+), 394 deletions(-)
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
 --
 Version 2:
  - Don't try to enable SDRAM rotation , return an error if non zero
 rotation
is attempted when rotation_type is set to SDMA rotation.
 Version 1:
http://www.mail-archive.com/linux-me...@vger.kernel.org/msg21937.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 2/2] V4L/DVB: OMAP_VOUT: Use rotation_type to choose between vrfb and sdram buffers

2010-10-06 Thread Hiremath, Vaibhav


 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 27, 2010 12:47 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; Taneja,
 Archit
 Subject: [PATCH v2 2/2] V4L/DVB: OMAP_VOUT: Use rotation_type to choose
 between vrfb and sdram buffers

 Add rotation_type member to omapvideo_info, this is initialized based on
 the value def_vrfb bootarg parameter, vrfb rotation is chosen by
 default.
 The rotation_type var is now used to choose between vrfb and non-vrfb
 calls.

 vrfb specific code in omap_vout has been removed and is present in
 omap_vout_vrfb.c

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/Kconfig|1 -
  drivers/media/video/omap/Makefile   |1 +
  drivers/media/video/omap/omap_vout.c|  448 ++
 -
  drivers/media/video/omap/omap_voutdef.h |1 +
  4 files changed, 81 insertions(+), 370 deletions(-)

 diff --git a/drivers/media/video/omap/Kconfig
 b/drivers/media/video/omap/Kconfig
 index e63233f..d554bfd
 --- a/drivers/media/video/omap/Kconfig
 +++ b/drivers/media/video/omap/Kconfig
 @@ -5,7 +5,6 @@ config VIDEO_OMAP2_VOUT
   select VIDEOBUF_DMA_CONTIG
   select OMAP2_DSS
   select OMAP2_VRAM
 - select OMAP2_VRFB
[Hiremath, Vaibhav] Don't remove it, select for OMAP3 family of devices.

   default n
   ---help---
 V4L2 Display driver support for OMAP2/3 based boards.
 diff --git a/drivers/media/video/omap/Makefile
 b/drivers/media/video/omap/Makefile
 index b287880..bc47569
 --- a/drivers/media/video/omap/Makefile
 +++ b/drivers/media/video/omap/Makefile
 @@ -5,3 +5,4 @@
  # OMAP2/3 Display driver
  omap-vout-y := omap_vout.o omap_voutlib.o
  obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
 +obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 46bc642..4d61ee0
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -51,6 +51,7 @@

  #include omap_voutlib.h
  #include omap_voutdef.h
 +#include omap_vout_vrfb.h

  MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
 @@ -82,6 +83,7 @@ static u32 video1_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  static u32 video2_bufsize = OMAP_VOUT_MAX_BUF_SIZE;
  u32 vid1_static_vrfb_alloc;
  u32 vid2_static_vrfb_alloc;
 +static int def_vrfb = 1;
  static int debug;

  /* Module parameters */
 @@ -109,6 +111,10 @@ module_param(vid2_static_vrfb_alloc, bool, S_IRUGO);
  MODULE_PARM_DESC(vid2_static_vrfb_alloc,
   Static allocation of the VRFB buffer for video2 device);

 +module_param(def_vrfb, bool, S_IRUGO);
[Hiremath, Vaibhav] Till the time we don't come up with Tiler (for that matter 
any other way of rotating image) based rotation mechanism, I wouldn't want to 
change/introduce any new interface.

 +MODULE_PARM_DESC(def_vrfb,
 + decide if vrfb is used for rotation);
 +
  module_param(debug, bool, S_IRUGO);
  MODULE_PARM_DESC(debug, Debug level (0-1));

 @@ -199,41 +205,6 @@ void omap_vout_free_buffer(unsigned long virtaddr,
 u32 buf_size)
  }

  /*
 - * Function for allocating video buffers
 - */
 -static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
 - unsigned int *count, int startindex)
 -{
 - int i, j;
 -
 - for (i = 0; i  *count; i++) {
 - if (!vout-smsshado_virt_addr[i]) {
 - vout-smsshado_virt_addr[i] =
 - omap_vout_alloc_buffer(vout-smsshado_size,
 - vout-smsshado_phy_addr[i]);
 - }
 - if (!vout-smsshado_virt_addr[i]  startindex != -1) {
 - if (V4L2_MEMORY_MMAP == vout-memory  i = startindex)
 - break;
 - }
 - if (!vout-smsshado_virt_addr[i]) {
 - for (j = 0; j  i; j++) {
 - omap_vout_free_buffer(
 - vout-smsshado_virt_addr[j],
 - vout-smsshado_size);
 - vout-smsshado_virt_addr[j] = 0;
 - vout-smsshado_phy_addr[j] = 0;
 - }
 - *count = 0;
 - return -ENOMEM;
 - }
 - memset((void *) vout-smsshado_virt_addr[i], 0,
 - vout-smsshado_size);
 - }
 - return 0;
 -}
 -
 -/*
   * Try format
   */
  static int omap_vout_try_format(struct v4l2_pix_format *pix)
 @@ -326,33 +297,6 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
  }

  /*
 - * Wakes up the application once the DMA transfer to VRFB space is
 completed.
 - */
 -static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void
 *data)
 -{
 - struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
 -
 -

RE: [PATCH v1 12/16] OMAP3: hwmod DSS: DISPC Move init,exit to driver

2010-10-06 Thread Premi, Sanjeev

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Guruswamy, Senthilvadivu
 Sent: Wednesday, October 06, 2010 4:45 PM
 To: khil...@deeprootsystems.com; tomi.valkei...@nokia.com; 
 p...@pwsan.com; Hiremath, Vaibhav; linux-omap@vger.kernel.org
 Cc: Guruswamy, Senthilvadivu
 Subject: [PATCH v1 12/16] OMAP3: hwmod DSS: DISPC Move 
 init,exit to driver
 
 From: Senthilvadivu Guruswamy svad...@ti.com
 
 Move init exit methods to its driver probe,remove.
 pdev member has to be maintained by its own drivers.

[sp] How is this change related to hwmod mentioned in the
 subject line?

~sanjeev

[snip]...[snip]
--
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: Check for is_smp for tlb_ops and cache_ops boardcast

* Russell King - ARM Linux li...@arm.linux.org.uk [101005 15:24]:
 On Tue, Oct 05, 2010 at 03:19:52PM -0700, Tony Lindgren wrote:
  * Tony Lindgren t...@atomide.com [100907 20:04]:
   This should not be needed when running on UP systems.
   
   Additionally we will also get an undefined instruction on ARM cores
   without the extended CPUID registers with CONFIG_SMP_ON_UP.
   
   Also, we can now remove the is_smp() test from mmu.c.
  
  Just FYI, I've updated this one more time with to use cpus_empty
  instead of !smp_on_up() here as well.
 
 What's the rationale?

With CPU hotplug if the other SMP cores are unplugged for PM or
other reasons, no need to do the broadcast.

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 00/10] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37

* Peter Ujfalusi peter.ujfal...@nokia.com [101005 22:33]:
 On Tuesday 05 October 2010 21:40:17 ext Tony Lindgren wrote:
 
 ...
 
   For patches 6-7 you could have my ack.
   Acked-by: Jarkko Nikula jhnik...@gmail.com
   
   As they are touching also sound/soc/omap/omap-mcbsp.c, an ack from Mark
   and Liam are needed. Links to patches 6 and 7 below and my fixes on top
   of them [1].
   
   http://marc.info/?l=linux-omapm=128596931117788w=2
   http://marc.info/?l=linux-omapm=128596931417805w=2
  
  Sorry, I've already merged them as they fixed code that did not compile.
  
  Let me know if you guys want me to rebuild those parts of omap-for-linus
  to add the acks.
 
 If you decide to rebuild, than you can add my (for patch 6-7):
 Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com 

OK, let's do that then we should still have some time left before the
merge window.

Mark  Liam, care to ack as well?

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/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread Steve Sakoman

On Wed, Oct 6, 2010 at 6:45 AM, Mike Rapoport m...@compulab.co.il wrote:
 Hi Steve,
 Steve Sakoman wrote:

 On Tue, Oct 5, 2010 at 11:17 PM, Mike Rapoport m...@compulab.co.il
 wrote:

 I've tried to update the patches on top of 2.6.36-rc3 and I've got stuck.
 The changes Adrian has made to the interrupt synchronization  affect the
 way
 the
 SDIO irq should be implemented and I haven't found a way to resolve it
 :-(

 I tried my hand at making the patch apply on 2.6.35:


 http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=51b802d73191c306618cddefbd63379c839589f5

 This one fails to build:

  CC      drivers/mmc/host/omap_hsmmc.o
 drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_start_command':
 drivers/mmc/host/omap_hsmmc.c:791: warning: unused variable 'int_en_mask'
 drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_do_irq':
 drivers/mmc/host/omap_hsmmc.c:1023: error: label 'out' used but not defined
 drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_irq':
 drivers/mmc/host/omap_hsmmc.c:1101: warning: label 'out' defined but not
 used
 drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_suspend':
 drivers/mmc/host/omap_hsmmc.c:2346: warning: unused variable 'state'
 make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1

 Moving the 'out' label where I believe it should live I get:
 libertas_sdio: Libertas SDIO driver
 libertas_sdio: Copyright Pierre Ossman
 libertas: command 0x0003 timed out
 libertas: Timeout submitting command 0x0003
 libertas: PREP_CMD: command 0x0003 failed: -110
 libertas_sdio: probe of mmc1:0001:1 failed with error -110


 It seems to work, but I'm pretty sure I must have messed something up
 because I get error messages every once in a while:

 libertas: tx watch dog timeout

 I don't recall seeing these with the original version of the patch :-(

 Suggestions as to where I went wrong are welcome!

 I've applied the patch almost the same way you did and I was not able to
 get any further than the point above (command 0x0003 timed out). As far as I
 understand, what we have now is that omap_hsmmc_request_done() calls
 omap_hsmmc_disable_irq() and the interrupts that come from the 8686
 _between_ requests are simply missed. Whatever I've tried to keep the SDIO
 interrupts on didn't help... :(

You are correct!  The version of the patch in the repo indeed has
'out' in the wrong place and generates a compile error.

Could you post the patch you are using and I will try to reproduce
what you are seeing on my hardware?  Best we all work from exactly the
same patch!

Steve
--
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] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread Luciano Coelho

On Wed, 2010-10-06 at 16:01 +0200, ext Gadiyar, Anand wrote:
  Hmmm... We got a problem here.  This patch breaks builds when we *don't*
  have omap: mmc extended to pass host capabilities from board file.  We
  don't have that on wireless-next yet, so builds with zoom boards
  selected are broken.
 
  Any ideas on how to solve this dilemma? I guess the proper way to handle
  this would be to make the changes proposed in this patch when merging
  instead of having a normal commit for it, wouldn't it?
 
  Just cherry-pick that change into the branch of your tree that I do
  _not_ pull from.  I presume that it is already available in linux-next?
 
 
 Yup - both patches are in linux-next; that's where we noticed the build break.

Ok, I hope the patch applies cleanly in our trees.

John, don't you want to do the cherry-pick on your wireless-testing
then? If you do it, I can inherit that, because I pull from it into my
testing branch (wl12xx/master).  At the moment, w-t is broken too.

-- 
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] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread John W. Linville

On Wed, Oct 06, 2010 at 06:27:49PM +0300, Luciano Coelho wrote:
 On Wed, 2010-10-06 at 16:01 +0200, ext Gadiyar, Anand wrote:
   Hmmm... We got a problem here.  This patch breaks builds when we *don't*
   have omap: mmc extended to pass host capabilities from board file.  We
   don't have that on wireless-next yet, so builds with zoom boards
   selected are broken.
  
   Any ideas on how to solve this dilemma? I guess the proper way to handle
   this would be to make the changes proposed in this patch when merging
   instead of having a normal commit for it, wouldn't it?
  
   Just cherry-pick that change into the branch of your tree that I do
   _not_ pull from.  I presume that it is already available in linux-next?
  
  
  Yup - both patches are in linux-next; that's where we noticed the build 
  break.
 
 Ok, I hope the patch applies cleanly in our trees.
 
 John, don't you want to do the cherry-pick on your wireless-testing
 then? If you do it, I can inherit that, because I pull from it into my
 testing branch (wl12xx/master).  At the moment, w-t is broken too.

OK, that's fine -- do you have the commit ID and the tree that has it?

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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] OMAP2: PM: check UART status before trying to idle

As is done on OMAP3, check omap_uart_can_sleep() as one of the
pre-conditions for entering the idle loop.  Without this check,
entering idle introduces large latencies on active UARTs, and is
especially noticable on serial console.

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Tony, this fixes the UART lag when using the serial console on n8x0.
With this, the UARTs will not idle until their sleep timeouts are
activated, and they're disabled by default.

There's an additional bug I'm still looking into as to why UART3
does not trigger wakeup from idle on 2420, but that is only triggered
after enabling UART timeouts.

 arch/arm/mach-omap2/pm24xx.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c1bceec..a40457d 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -245,6 +245,8 @@ static int omap2_can_sleep(void)
 {
if (omap2_fclks_active())
return 0;
+   if (!omap_uart_can_sleep())
+   return 0;
if (osc_ck-usecount  1)
return 0;
if (omap_dma_running())
-- 
1.7.2.1

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

Re: [PATCH] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread Luciano Coelho

On Wed, 2010-10-06 at 17:30 +0200, ext John W. Linville wrote:
On Wed, Oct 06, 2010 at 06:27:49PM +0300, Luciano Coelho wrote:
On Wed, 2010-10-06 at 16:01 +0200, ext Gadiyar, Anand wrote:
Hmmm... We got a problem here. This patch breaks builds when we
*don't*
have omap: mmc extended to pass host capabilities from board file.
We
don't have that on wireless-next yet, so builds with zoom boards
selected are broken.

Any ideas on how to solve this dilemma? I guess the proper way to
handle
this would be to make the changes proposed in this patch when merging
instead of having a normal commit for it, wouldn't it?

Just cherry-pick that change into the branch of your tree that I do
_not_ pull from. I presume that it is already available in linux-next?

Yup - both patches are in linux-next; that's where we noticed the build
break.

Ok, I hope the patch applies cleanly in our trees.

John, don't you want to do the cherry-pick on your wireless-testing
then? If you do it, I can inherit that, because I pull from it into my
testing branch (wl12xx/master). At the moment, w-t is broken too.

OK, that's fine -- do you have the commit ID and the tree that has it?

Stephen's linux-net, commit 3a63833ec3002816a759a49ebda4e229c089114e.

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=3a63833ec3002816a759a49ebda4e229c089114e

--
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] PM: add synchronous runtime interface for interrupt handlers

2010-10-06 Thread Alan Stern

On Tue, 5 Oct 2010, Kevin Hilman wrote:

 Alan Stern st...@rowland.harvard.edu writes:
 
  On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
 
In my opinion the _irq operations should really be one-shot, without
any looping, waking up parents etc.  I mean, if the parent is not 
RPM_ACTIVE,
the _irq resume should immediately fail and analogously for the _irq
suspend.  And so on.  As simple as reasonably possible.
   
   But what if the device's own status is currently SUSPENDING or
   RESUMING?  Do you want to fail when that happens, instead of waiting
   for the concurrent operation to finish?
  
  Yes.  IMO an _irq() suspend should only be allowed if the status is 
  RPM_ACTIVE
  and an _irq() resume should fail if the status is not RPM_SUSPENDED.  The
  error code returned should depend on the situation, though.
  
   There's no way to prevent this
   on SMP systems, because a wakeup request can arrive while a
   software-initiated resume is in progress.
  
  I know that. :-)
 
  I suspect Kevin will not want to live with this restriction, but I'd
  like to hear from him.  Kevin?
 
 [ Apologies for the delays... I've been running around preparing OMAP PM
   stuff for the upcoming merge window. ]
 
 I think I can live with the above restrictions (the _irq methods failing
 unless they can immediately run.)  For the rare corner cases I've
 currently run into, this will work fine as they happen because of a
 wakeup IRQ, where we know the device is RPM_SUSPENDED.

Then what will the driver do if it gets a wakeup IRQ but it can't
resume the device because some other thread is in the middle of a
suspend or resume?

Alan Stern

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

[PATCHv3 1/7] pwm: Add pwm core driver

The existing pwm based led and backlight driver makes use of the
pwm(include/linux/pwm.h). So all the board specific pwm drivers will
be exposing the same set of function name as in include/linux/pwm.h.
Consder a platform with multi Soc or having more than one pwm module, in
such a case, there exists more than one pwm driver for a platform. Each
of these pwm drivers export the same set of function and hence leads to
re-declaration build error.

In order to overcome this issue all the pwm drivers must register to
some core pwm driver with function pointers for pwm operations (i.e
pwm_config, pwm_enable, pwm_disable).

The clients of pwm device will have to call pwm_request, wherein
they will get the pointer to struct pwm_ops. This structure include
function pointers for pwm_config, pwm_enable and pwm_disable.

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 drivers/Kconfig|2 +
 drivers/Makefile   |1 +
 drivers/pwm/Kconfig|   18 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-core.c |  171 
 include/linux/pwm.h|   12 +++-
 6 files changed, 204 insertions(+), 1 deletions(-)
 create mode 100644 drivers/pwm/Kconfig
 create mode 100644 drivers/pwm/Makefile
 create mode 100644 drivers/pwm/pwm-core.c

diff --git a/drivers/Kconfig b/drivers/Kconfig
index a2b902f..e042f27 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -111,4 +111,6 @@ source drivers/xen/Kconfig
 source drivers/staging/Kconfig
 
 source drivers/platform/Kconfig
+
+source drivers/pwm/Kconfig
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 443c4eb..1aec04e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -116,3 +116,4 @@ obj-$(CONFIG_STAGING)   += staging/
 obj-y  += platform/
 obj-y  += ieee802154/
 obj-y  += vbus/
+obj-$(CONFIG_PWM_DEVICES)  += pwm/
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
new file mode 100644
index 000..03a9813
--- /dev/null
+++ b/drivers/pwm/Kconfig
@@ -0,0 +1,18 @@
+#
+# PWM devices
+#
+
+menuconfig PWM_DEVICES
+   bool PWM devices
+   default y
+   ---help---
+ Say Y to enable pwm core driver and see options for various pwm
+ drivers. This option enables pwm drivers to register with the
+ pwm core driver and thereby provide a single interface to the
+ clients using PWM.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if PWM_DEVICES
+
+endif # PWM_DEVICES
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
new file mode 100644
index 000..552f969
--- /dev/null
+++ b/drivers/pwm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PWM_DEVICES)  += pwm-core.o
diff --git a/drivers/pwm/pwm-core.c b/drivers/pwm/pwm-core.c
new file mode 100644
index 000..c323969
--- /dev/null
+++ b/drivers/pwm/pwm-core.c
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) ST-Ericsson SA 2010
+ *
+ * License Terms: GNU General Public License v2
+ * Author: Arun R Murthy arun.mur...@stericsson.com
+ */
+#include linux/init.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/rwsem.h
+#include linux/err.h
+#include linux/pwm.h
+
+struct pwm_device {
+   struct pwm_ops *pops;
+   struct device *dev;
+   int pwm_id;
+   const char *name;
+};
+
+static struct class *pwm_class;
+
+/*
+ * TODO: This function is referenced in pwm based led and backlight driver.
+ * This function is no more required with the implementation of pwm core
+ * driver. This is retained as deprecated to make sure that the mips
+ * jz4740 pwm driver works fine as that is not aligned with this pwm core
+ * driver. On aligning the same this has to be removed.
+ */
+void __deprecated pwm_free(struct pwm_device *pwm)
+{
+}
+
+/**
+ * pwm_config() - configure the pwm device
+ * @pwm:   pointer to the struct pwm_device
+ * @period_ns: period in nano seconds
+ *
+ * This function verifies for the presence of the pops structure and if so
+ * calls the pwm device specific config fucntion.
+ */
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+   if (!pwm-pops)
+   return -EFAULT;
+   return pwm-pops-pwm_config(pwm, duty_ns, period_ns);
+}
+EXPORT_SYMBOL(pwm_config);
+
+/**
+ * pwm_enable() - enable pwm device
+ * @pwm:   pointer to the struct pwm_device
+ *
+ * This function verifies for the presence of the pops structure and if so
+ * calls the pwm device specific enable function.
+ */
+int pwm_enable(struct pwm_device *pwm)
+{
+   if (!pwm-pops)
+   return -EFAULT;
+   return pwm-pops-pwm_enable(pwm);
+}
+EXPORT_SYMBOL(pwm_enable);
+
+/**
+ * pwm_disable() - disable pwm device
+ * @pwm:   pointer to the struct pwm_device
+ *
+ * This function verifies for the presence of the pops structure and if so
+ * calls the pwm device specific disable

[PATCHv3 3/7] leds: pwm: add a new element 'name' to platform data

A new element 'name' is added to pwm led platform data structure.
This is required to identify the pwm device.

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 drivers/leds/leds-pwm.c  |4 +++-
 include/linux/leds_pwm.h |3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index da3fa8d..8da2be6 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -66,8 +66,10 @@ static int led_pwm_probe(struct platform_device *pdev)
cur_led = pdata-leds[i];
led_dat = leds_data[i];
 
+   if (!pdata-name)
+   pdata-name = cur_led-name;
led_dat-pwm = pwm_request(cur_led-pwm_id,
-   cur_led-name);
+   pdata-name);
if (IS_ERR(led_dat-pwm)) {
dev_err(pdev-dev, unable to request PWM %d\n,
cur_led-pwm_id);
diff --git a/include/linux/leds_pwm.h b/include/linux/leds_pwm.h
index 33a0711..dbc925a 100644
--- a/include/linux/leds_pwm.h
+++ b/include/linux/leds_pwm.h
@@ -14,8 +14,9 @@ struct led_pwm {
 };
 
 struct led_pwm_platform_data {
-   int num_leds;
+   int num_leds;
struct led_pwm  *leds;
+   char*name;
 };
 
 #endif
-- 
1.7.2.dirty

--
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

[PATCHv3 4/7] pwm: Align existing pwm drivers with pwm-core driver

pwm-core: make the driver visible for ARM only
Align ab8500 pwm with the pwm core driver
Align twl6030 pwm driver with pwm core driver
Align Freescale mxc pwm driver with pwm core driver
Align pxa pwm driver with pwm core driver
Align samsung(s3c) pwm driver with pwm core driver

mips-jz4740: pwm: Align with new pwm core driver

PWM core driver has been added and has been enabled only for ARM
platform. The same can be utilised for mips also.
Please align with the pwm core driver(drivers/pwm-core.c).

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 arch/arm/plat-mxc/pwm.c |  165 +-
 arch/arm/plat-pxa/pwm.c |  209 ++
 arch/arm/plat-samsung/pwm.c |  234 +++
 arch/mips/jz4740/pwm.c  |2 +-
 drivers/mfd/twl-core.c  |   13 +++
 drivers/mfd/twl6030-pwm.c   |  110 +---
 drivers/misc/ab8500-pwm.c   |  103 +---
 drivers/pwm/Kconfig |1 +
 drivers/pwm/pwm-core.c  |   11 +--
 include/linux/pwm.h |   38 +++-
 10 files changed, 440 insertions(+), 446 deletions(-)

diff --git a/arch/arm/plat-mxc/pwm.c b/arch/arm/plat-mxc/pwm.c
index c36f263..f74a280 100644
--- a/arch/arm/plat-mxc/pwm.c
+++ b/arch/arm/plat-mxc/pwm.c
@@ -38,22 +38,16 @@
 
 
 
-struct pwm_device {
-   struct list_headnode;
-   struct platform_device *pdev;
-
-   const char  *label;
+struct mxc_pwm_device {
struct clk  *clk;
-
int clk_enabled;
void __iomem*mmio_base;
-
-   unsigned intuse_count;
-   unsigned intpwm_id;
 };
 
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+static int mxc_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
 {
+   struct mxc_pwm_device *mxc_pwm = pwm-data;
+
if (pwm == NULL || period_ns == 0 || duty_ns  period_ns)
return -EINVAL;
 
@@ -62,7 +56,7 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
unsigned long period_cycles, duty_cycles, prescale;
u32 cr;
 
-   c = clk_get_rate(pwm-clk);
+   c = clk_get_rate(mxc_pwm-clk);
c = c * period_ns;
do_div(c, 10);
period_cycles = c;
@@ -74,8 +68,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
do_div(c, period_ns);
duty_cycles = c;
 
-   writel(duty_cycles, pwm-mmio_base + MX3_PWMSAR);
-   writel(period_cycles, pwm-mmio_base + MX3_PWMPR);
+   writel(duty_cycles, mxc_pwm-mmio_base + MX3_PWMSAR);
+   writel(period_cycles, mxc_pwm-mmio_base + MX3_PWMPR);
 
cr = MX3_PWMCR_PRESCALER(prescale) | MX3_PWMCR_EN;
 
@@ -84,7 +78,7 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
else
cr |= MX3_PWMCR_CLKSRC_IPG_HIGH;
 
-   writel(cr, pwm-mmio_base + MX3_PWMCR);
+   writel(cr, mxc_pwm-mmio_base + MX3_PWMCR);
} else if (cpu_is_mx1() || cpu_is_mx21()) {
/* The PWM subsystem allows for exact frequencies. However,
 * I cannot connect a scope on my device to the PWM line and
@@ -102,110 +96,76 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
 * both the prescaler (/1 .. /128) and then by CLKSEL
 * (/2 .. /16).
 */
-   u32 max = readl(pwm-mmio_base + MX1_PWMP);
+   u32 max = readl(mxc_pwm-mmio_base + MX1_PWMP);
u32 p = max * duty_ns / period_ns;
-   writel(max - p, pwm-mmio_base + MX1_PWMS);
+   writel(max - p, mxc_pwm-mmio_base + MX1_PWMS);
} else {
BUG();
}
 
return 0;
 }
-EXPORT_SYMBOL(pwm_config);
 
-int pwm_enable(struct pwm_device *pwm)
+static int mxc_pwm_enable(struct pwm_device *pwm)
 {
+   struct mxc_pwm_device *mxc_pwm = pwm-data;
int rc = 0;
 
-   if (!pwm-clk_enabled) {
-   rc = clk_enable(pwm-clk);
+   if (!mxc_pwm-clk_enabled) {
+   rc = clk_enable(mxc_pwm-clk);
if (!rc)
-   pwm-clk_enabled = 1;
+   mxc_pwm-clk_enabled = 1;
}
return rc;
 }
-EXPORT_SYMBOL(pwm_enable);
-
-void pwm_disable(struct pwm_device *pwm)
-{
-   writel(0, pwm-mmio_base + MX3_PWMCR);
-
-   if (pwm-clk_enabled) {
-   clk_disable(pwm-clk);
-   pwm-clk_enabled = 0;
-   }
-}
-EXPORT_SYMBOL(pwm_disable);
-
-static DEFINE_MUTEX(pwm_lock);
-static LIST_HEAD(pwm_list);
 
-struct pwm_device *pwm_request(int pwm_id, const char *label)
+static int mxc_pwm_disable(struct pwm_device *pwm)
 {
-   struct pwm_device

[PATCHv3 2/7] backlight:pwm: add an element 'name' to platform data

A new element 'name' is added to pwm backlight platform data structure.
This is required to identify the pwm device.

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 drivers/video/backlight/pwm_bl.c |4 +++-
 include/linux/pwm_backlight.h|1 +
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fa512a6..332cc50 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -94,7 +94,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb-notify = data-notify;
pb-dev = pdev-dev;
 
-   pb-pwm = pwm_request(data-pwm_id, backlight);
+   if (!data-name)
+   data-name = backlight;
+   pb-pwm = pwm_request(data-pwm_id, data-name);
if (IS_ERR(pb-pwm)) {
dev_err(pdev-dev, unable to request PWM for backlight\n);
ret = PTR_ERR(pb-pwm);
diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
index 01b3d75..c2ce8f8 100644
--- a/include/linux/pwm_backlight.h
+++ b/include/linux/pwm_backlight.h
@@ -6,6 +6,7 @@
 
 struct platform_pwm_backlight_data {
int pwm_id;
+   char *name;
unsigned int max_brightness;
unsigned int dft_brightness;
unsigned int pwm_period_ns;
-- 
1.7.2.dirty

--
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

[PATCHv3 6/7] pwm: move existing pwm driver to drivers/pwm

As of now only ab8500 and twl6030 are moved.

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 drivers/mfd/Kconfig   |9 --
 drivers/mfd/Makefile  |1 -
 drivers/mfd/twl6030-pwm.c |  195 -
 drivers/misc/Kconfig  |9 --
 drivers/misc/Makefile |1 -
 drivers/misc/ab8500-pwm.c |  157 
 drivers/pwm/Kconfig   |   18 
 drivers/pwm/Makefile  |3 +
 drivers/pwm/pwm-ab8500.c  |  157 
 drivers/pwm/pwm-twl6030.c |  195 +
 10 files changed, 373 insertions(+), 372 deletions(-)
 delete mode 100644 drivers/mfd/twl6030-pwm.c
 delete mode 100644 drivers/misc/ab8500-pwm.c
 create mode 100644 drivers/pwm/pwm-ab8500.c
 create mode 100644 drivers/pwm/pwm-twl6030.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82d013f..ed4359a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -186,15 +186,6 @@ config TWL4030_CODEC
select MFD_CORE
default n
 
-config TWL6030_PWM
-   tristate TWL6030 PWM (Pulse Width Modulator) Support
-   depends on TWL4030_CORE
-   select HAVE_PWM
-   default n
-   help
- Say yes here if you want support for TWL6030 PWM.
- This is used to control charging LED brightness.
-
 config MFD_STMPE
bool Support STMicroelectronics STMPE
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9aa8a2d..a66f2a7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_MENELAUS)+= menelaus.o
 obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
-obj-$(CONFIG_TWL6030_PWM)  += twl6030-pwm.o
 
 obj-$(CONFIG_MFD_MC13783)  += mc13783-core.o
 
diff --git a/drivers/mfd/twl6030-pwm.c b/drivers/mfd/twl6030-pwm.c
deleted file mode 100644
index 7091df9..000
--- a/drivers/mfd/twl6030-pwm.c
+++ /dev/null
@@ -1,195 +0,0 @@
-/*
- * twl6030_pwm.c
- * Driver for PHOENIX (TWL6030) Pulse Width Modulator
- *
- * Copyright (C) 2010 Texas Instruments
- * Author: Hemanth V heman...@ti.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/slab.h
-#include linux/pwm.h
-#include linux/err.h
-#include linux/i2c/twl.h
-
-#define LED_PWM_CTRL1  0xF4
-#define LED_PWM_CTRL2  0xF5
-
-/* Max value for CTRL1 register */
-#define PWM_CTRL1_MAX  255
-
-/* Pull down disable */
-#define PWM_CTRL2_DIS_PD   (1  6)
-
-/* Current control 2.5 milli Amps */
-#define PWM_CTRL2_CURR_02  (2  4)
-
-/* LED supply source */
-#define PWM_CTRL2_SRC_VAC  (1  2)
-
-/* LED modes */
-#define PWM_CTRL2_MODE_HW  (0  0)
-#define PWM_CTRL2_MODE_SW  (1  0)
-#define PWM_CTRL2_MODE_DIS (2  0)
-
-#define PWM_CTRL2_MODE_MASK0x3
-
-int twl6030_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
-{
-   u8 duty_cycle;
-   int ret = 0;
-
-   if (pwm == NULL || period_ns == 0 || duty_ns  period_ns)
-   return -EINVAL;
-
-   duty_cycle = (duty_ns * PWM_CTRL1_MAX) / period_ns;
-
-   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, duty_cycle, LED_PWM_CTRL1);
-
-   if (ret  0) {
-   pr_err(%s: Failed to configure PWM, Error %d\n,
-   pwm-label, ret);
-   return ret;
-   }
-   return 0;
-}
-
-int twl6030_pwm_enable(struct pwm_device *pwm)
-{
-   u8 val;
-   int ret = 0;
-
-   ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
-   if (ret  0) {
-   pr_err(%s: Failed to enable PWM, Error %d\n, pwm-label, ret);
-   return ret;
-   }
-
-   /* Change mode to software control */
-   val = ~PWM_CTRL2_MODE_MASK;
-   val |= PWM_CTRL2_MODE_SW;
-
-   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
-   if (ret  0) {
-   pr_err(%s: Failed to enable PWM, Error %d\n, pwm-label, ret);
-   return ret;
-   }
-
-   twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
-   return 0;
-}
-
-int twl6030_pwm_disable(struct pwm_device *pwm)
-{
-   u8 val;
-   int ret = 0;
-

[PATCHv3 7/7] pwm: Modify backlight and led Kconfig aligning to pwm core

PWM based backlight and led driver will not be calling the pwm drivers
through the pwm core driver and hence adding dependancy on the same.

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 drivers/leds/Kconfig|2 +-
 drivers/pwm/Kconfig |2 --
 drivers/video/backlight/Kconfig |2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e411262..8324dd0 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -244,7 +244,7 @@ config LEDS_DAC124S085
 
 config LEDS_PWM
tristate PWM driven LED Support
-   depends on HAVE_PWM
+   depends on HAVE_PWM || PWM_DEVICES
help
  This option enables support for pwm driven LEDs
 
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e4ef199..4acc0a6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -19,7 +19,6 @@ if PWM_DEVICES
 config AB8500_PWM
bool AB8500 PWM support
depends on AB8500_CORE
-   select HAVE_PWM
help
  This driver exports functions to enable/disble/config/free Pulse
  Width Modulation in the Analog Baseband Chip AB8500.
@@ -28,7 +27,6 @@ config AB8500_PWM
 config TWL6030_PWM
tristate TWL6030 PWM (Pulse Width Modulator) Support
depends on TWL4030_CORE
-   select HAVE_PWM
default n
help
  Say yes here if you want support for TWL6030 PWM.
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index e54a337..c07fc16 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -217,7 +217,7 @@ config BACKLIGHT_CARILLO_RANCH
 
 config BACKLIGHT_PWM
tristate Generic PWM based Backlight Driver
-   depends on HAVE_PWM
+   depends on HAVE_PWM || PWM_DEVICES
help
  If you have a LCD backlight adjustable by PWM, say Y to enable
  this driver.
-- 
1.7.2.dirty

--
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

[PATCHv3 0/7] PWM core driver for pwm based led and backlight driver

PWM core driver for pwm based led and backlight driver.
The intention of the pwm core driver is not to break the build if two or more
pwm drivers are enabled.
Align the existing pwm drivers to make use of the pwm core driver

Changes v2 - v3
Replaced the use of linked list to monitor the registered pwm devices
with class. By using this an interface to the user space through sysfs
can be provided for debugging purpose.

Further to Kelvin Hilman comments on v2 patch set:
Had a close look at the Bill patch set. Functionality wise my patch set
lags the callback implementation and the synchronize. Either Bill can
send a patch on top of this to implement the same or I can do that
adding credits to Bill.
Apart from the above said some more are the handling of duty cycle. It
is a parameter in function pwm_config() in my patch set. Hence there
is no need to have seperate function to set/get the same. Reason for
having this as a parameter in pwm_config() is: the duty cycle, period
maximum intensity are part of the platform data. Hence manipulation
of these is done in the client driver(ref: pwm based led and backlight
driver). I have provided a patch(backlight: add low threshold to pwm
backlight) for handling this in the pwm backlight (one such client)
which is now in Andrew's mm tree.

TODO: Align Atmel pwm driver with my pwm core driver patch set.

Arun Murthy (7):
  pwm: Add pwm core driver
  backlight:pwm: add an element 'name' to platform data
  leds: pwm: add a new element 'name' to platform data
  pwm: Align existing pwm drivers with pwm-core driver
  platform: Update the pwm based led and backlight platform data
  pwm: move existing pwm driver to drivers/pwm
  pwm: Modify backlight and led Kconfig aligning to pwm core

 arch/arm/mach-pxa/cm-x300.c   |1 +
 arch/arm/mach-pxa/colibri-pxa270-income.c |1 +
 arch/arm/mach-pxa/ezx.c   |1 +
 arch/arm/mach-pxa/hx4700.c|1 +
 arch/arm/mach-pxa/lpd270.c|1 +
 arch/arm/mach-pxa/magician.c  |1 +
 arch/arm/mach-pxa/mainstone.c |1 +
 arch/arm/mach-pxa/mioa701.c   |1 +
 arch/arm/mach-pxa/palm27x.c   |1 +
 arch/arm/mach-pxa/palmtc.c|1 +
 arch/arm/mach-pxa/palmte2.c   |1 +
 arch/arm/mach-pxa/pcm990-baseboard.c  |1 +
 arch/arm/mach-pxa/raumfeld.c  |1 +
 arch/arm/mach-pxa/tavorevb.c  |2 +
 arch/arm/mach-pxa/viper.c |1 +
 arch/arm/mach-pxa/z2.c|2 +
 arch/arm/mach-pxa/zylonite.c  |1 +
 arch/arm/mach-s3c2410/mach-h1940.c|1 +
 arch/arm/mach-s3c2440/mach-rx1950.c   |1 +
 arch/arm/mach-s3c64xx/mach-hmt.c  |1 +
 arch/arm/mach-s3c64xx/mach-smartq.c   |1 +
 arch/arm/plat-mxc/pwm.c   |  166 +
 arch/arm/plat-pxa/pwm.c   |  210 --
 arch/arm/plat-samsung/pwm.c   |  235 +
 arch/mips/jz4740/pwm.c|2 +-
 drivers/Kconfig   |2 +
 drivers/Makefile  |1 +
 drivers/leds/Kconfig  |2 +-
 drivers/leds/leds-pwm.c   |4 +-
 drivers/mfd/Kconfig   |9 -
 drivers/mfd/Makefile  |1 -
 drivers/mfd/twl-core.c|   13 ++
 drivers/mfd/twl6030-pwm.c |  163 
 drivers/misc/Kconfig  |9 -
 drivers/misc/Makefile |1 -
 drivers/misc/ab8500-pwm.c |  168 
 drivers/pwm/Kconfig   |   35 +
 drivers/pwm/Makefile  |4 +
 drivers/pwm/pwm-ab8500.c  |  157 +++
 drivers/pwm/pwm-core.c|  130 
 drivers/pwm/pwm-twl6040.c |  196 
 drivers/video/backlight/Kconfig   |2 +-
 drivers/video/backlight/pwm_bl.c  |4 +-
 include/linux/leds_pwm.h  |3 +-
 include/linux/pwm.h   |   31 -
 include/linux/pwm_backlight.h |1 +
 46 files changed, 876 insertions(+), 696 deletions(-)
 delete mode 100644 drivers/mfd/twl6030-pwm.c
 delete mode 100644 drivers/misc/ab8500-pwm.c
 create mode 100644 drivers/pwm/Kconfig
 create mode 100644 drivers/pwm/Makefile
 create mode 100644 drivers/pwm/pwm-ab8500.c
 create mode 100644 drivers/pwm/pwm-core.c
 create mode 100644 drivers/pwm/pwm-twl6040.c

-- 
1.7.2.dirty

--
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

[PATCHv3 5/7] platform: Update the pwm based led and backlight platform data

mxc-pwm: Update the platform data with pwm name for backlight
s3c24xx-pwm: update platform data for backlight with pwm name

Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Acked-by: Linus Walleij linus.wall...@stericsson.com
---
 arch/arm/mach-pxa/cm-x300.c   |1 +
 arch/arm/mach-pxa/colibri-pxa270-income.c |1 +
 arch/arm/mach-pxa/ezx.c   |1 +
 arch/arm/mach-pxa/hx4700.c|1 +
 arch/arm/mach-pxa/lpd270.c|1 +
 arch/arm/mach-pxa/magician.c  |1 +
 arch/arm/mach-pxa/mainstone.c |1 +
 arch/arm/mach-pxa/mioa701.c   |1 +
 arch/arm/mach-pxa/palm27x.c   |1 +
 arch/arm/mach-pxa/palmtc.c|1 +
 arch/arm/mach-pxa/palmte2.c   |1 +
 arch/arm/mach-pxa/pcm990-baseboard.c  |1 +
 arch/arm/mach-pxa/raumfeld.c  |1 +
 arch/arm/mach-pxa/tavorevb.c  |2 ++
 arch/arm/mach-pxa/viper.c |1 +
 arch/arm/mach-pxa/z2.c|2 ++
 arch/arm/mach-pxa/zylonite.c  |1 +
 arch/arm/mach-s3c2410/mach-h1940.c|1 +
 arch/arm/mach-s3c2440/mach-rx1950.c   |1 +
 arch/arm/mach-s3c64xx/mach-hmt.c  |1 +
 arch/arm/mach-s3c64xx/mach-smartq.c   |1 +
 21 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
index c70e6c2..ddf763b 100644
--- a/arch/arm/mach-pxa/cm-x300.c
+++ b/arch/arm/mach-pxa/cm-x300.c
@@ -301,6 +301,7 @@ static inline void cm_x300_init_lcd(void) {}
 #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
 static struct platform_pwm_backlight_data cm_x300_backlight_data = {
.pwm_id = 2,
+   .name   = pxa25x-pwm,
.max_brightness = 100,
.dft_brightness = 100,
.pwm_period_ns  = 1,
diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c 
b/arch/arm/mach-pxa/colibri-pxa270-income.c
index 37f0f3e..d5b5874 100644
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -234,6 +234,7 @@ static inline void income_lcd_init(void) {}
 #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM__MODULE)
 static struct platform_pwm_backlight_data income_backlight_data = {
.pwm_id = 0,
+   .name   = pxa25x-pwm,
.max_brightness = 0x3ff,
.dft_brightness = 0x1ff,
.pwm_period_ns  = 100,
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index 626c82b..747f217 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -49,6 +49,7 @@
 
 static struct platform_pwm_backlight_data ezx_backlight_data = {
.pwm_id = 0,
+   .name   = pxa25x-pwm,
.max_brightness = 1023,
.dft_brightness = 1023,
.pwm_period_ns  = 78770,
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index 848c861..8e4905a 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -565,6 +565,7 @@ static struct platform_device hx4700_lcd = {
 
 static struct platform_pwm_backlight_data backlight_data = {
.pwm_id = 1,
+   .name   = pxa25x-pwm,
.max_brightness = 200,
.dft_brightness = 100,
.pwm_period_ns  = 30923,
diff --git a/arch/arm/mach-pxa/lpd270.c b/arch/arm/mach-pxa/lpd270.c
index d279507..91efade 100644
--- a/arch/arm/mach-pxa/lpd270.c
+++ b/arch/arm/mach-pxa/lpd270.c
@@ -273,6 +273,7 @@ static struct platform_device lpd270_flash_device[2] = {
 
 static struct platform_pwm_backlight_data lpd270_backlight_data = {
.pwm_id = 0,
+   .name   = pxa25x-pwm,
.max_brightness = 1,
.dft_brightness = 1,
.pwm_period_ns  = 78770,
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index e81dd0c..bb657a4 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -382,6 +382,7 @@ static void magician_backlight_exit(struct device *dev)
 
 static struct platform_pwm_backlight_data backlight_data = {
.pwm_id = 0,
+   .name   = pxa25x-pwm,
.max_brightness = 272,
.dft_brightness = 100,
.pwm_period_ns  = 30923,
diff --git a/arch/arm/mach-pxa/mainstone.c b/arch/arm/mach-pxa/mainstone.c
index 5543c64..cbd359c 100644
--- a/arch/arm/mach-pxa/mainstone.c
+++ b/arch/arm/mach-pxa/mainstone.c
@@ -342,6 +342,7 @@ static struct platform_device mst_flash_device[2] = {
 #if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
 static struct platform_pwm_backlight_data mainstone_backlight_data = {
.pwm_id = 0,
+   .name   = pxa25x-pwm,
.max_brightness = 1023,
.dft_brightness = 1023,
.pwm_period_ns  = 78770,
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index dc66942..e442088 100644

Re: [PATCHv3 0/7] PWM core driver for pwm based led and backlight driver

2010-10-06 Thread Bill Gatliff

Arun:

On Wed, Oct 6, 2010 at 10:59 AM, Arun Murthy arun.mur...@stericsson.com wrote:
 PWM core driver for pwm based led and backlight driver.

With all due respect, it looks like you have reinvented portions of my
RFC for a comprehensive PWM API that has been floating around on
linux-embedded for over a year--- with an update coming in the last
two weeks or so.  Why?

To make matters worse, when I posted my original code I was told to
move the whole discussion to linux-embedded, because as a
cross-platform API proposal that's where it belongs.  I encourage you
do likewise.

I have a terse email style, so I just want to be clear that I'm not
mad or anything.  Honest!  I'm just disappointed that you've invested
so much hard work in traveling down the same path I came over a year
ago.  Bummer for everyone.

Can we not combine our efforts?  I haven't reviewed all of your
patches yet, but you are clearly ahead of me in specific ARM platform
support.  On the other hand, I think my code is more refined in many
other areas.  I also have Blackfin, PowerPC, and Cirrus (ARM) support,
though some of the code is from contributors who are holding it until
I proffer my final code.


What do you think?  Just let me know privately by email, or over on
linux-embedded.


Thanks!


b.g.
-- 
Bill Gatliff
b...@billgatliff.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37

2010-10-06 Thread Mark Brown

On Wed, Oct 06, 2010 at 07:48:07AM -0700, Tony Lindgren wrote:

 OK, let's do that then we should still have some time left before the
 merge window.

 Mark  Liam, care to ack as well?

Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 01/11] staging: tidspbridge: replace iommu custom for opensource implementation

2010-10-06 Thread David Cohen

Hi Fernando,

I have few comments below.

 diff --git a/drivers/staging/tidspbridge/core/io_sm.c 
 b/drivers/staging/tidspbridge/core/io_sm.c
 index 5718645..842b8db 100644
 --- a/drivers/staging/tidspbridge/core/io_sm.c
 +++ b/drivers/staging/tidspbridge/core/io_sm.c
 @@ -291,6 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
 struct cod_manager *cod_man;
 struct chnl_mgr *hchnl_mgr;
 struct msg_mgr *hmsg_mgr;
 +   struct iommu *mmu;
 u32 ul_shm_base;
 u32 ul_shm_base_offset;
 u32 ul_shm_limit;
 @@ -313,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
 struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
 struct cfg_hostres *host_res;
 struct bridge_dev_context *pbridge_context;
 -   u32 map_attrs;
 u32 shm0_end;
 u32 ul_dyn_ext_base;
 u32 ul_seg1_size = 0;
 @@ -337,6 +337,20 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
 status = -EFAULT;
 goto func_end;
 }
 +   mmu = pbridge_context-dsp_mmu;
 +
 +   if (mmu)
 +   iommu_put(mmu);
 +   mmu = iommu_get(iva2);
 +
 +   if (IS_ERR_OR_NULL(mmu)) {

You can use IS_ERR() instead.

[snip]

 @@ -1122,217 +1081,81 @@ static int bridge_brd_mem_write(struct 
 bridge_dev_context *dev_ctxt,
   *
   *  TODO: Disable MMU while updating the page tables (but that'll stall DSP)
   */
 -static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
 - u32 ul_mpu_addr, u32 virt_addr,
 - u32 ul_num_bytes, u32 ul_map_attr,
 - struct page **mapped_pages)
 +static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctx,
 +   u32 uva, u32 da, u32 size, u32 attr,
 +   struct page **usr_pgs)
 +
  {
 -   u32 attrs;
 -   int status = 0;
 -   struct bridge_dev_context *dev_context = dev_ctxt;
 -   struct hw_mmu_map_attrs_t hw_attrs;
 +   int res, w;
 +   unsigned pages, i;
 +   struct iommu *mmu = dev_ctx-dsp_mmu;
 struct vm_area_struct *vma;
 struct mm_struct *mm = current-mm;
 -   u32 write = 0;
 -   u32 num_usr_pgs = 0;
 -   struct page *mapped_page, *pg;
 -   s32 pg_num;
 -   u32 va = virt_addr;
 -   struct task_struct *curr_task = current;
 -   u32 pg_i = 0;
 -   u32 mpu_addr, pa;
 -
 -   dev_dbg(bridge,
 -   %s hDevCtxt %p, pa %x, va %x, size %x, ul_map_attr %x\n,
 -   __func__, dev_ctxt, ul_mpu_addr, virt_addr, ul_num_bytes,
 -   ul_map_attr);
 -   if (ul_num_bytes == 0)
 -   return -EINVAL;
 +   struct sg_table *sgt;
 +   struct scatterlist *sg;
 
 -   if (ul_map_attr  DSP_MAP_DIR_MASK) {
 -   attrs = ul_map_attr;
 -   } else {
 -   /* Assign default attributes */
 -   attrs = ul_map_attr | (DSP_MAPVIRTUALADDR | 
 DSP_MAPELEMSIZE16);
 -   }
 -   /* Take mapping properties */
 -   if (attrs  DSP_MAPBIGENDIAN)
 -   hw_attrs.endianism = HW_BIG_ENDIAN;
 -   else
 -   hw_attrs.endianism = HW_LITTLE_ENDIAN;
 -
 -   hw_attrs.mixed_size = (enum hw_mmu_mixed_size_t)
 -   ((attrs  DSP_MAPMIXEDELEMSIZE)  2);
 -   /* Ignore element_size if mixed_size is enabled */
 -   if (hw_attrs.mixed_size == 0) {
 -   if (attrs  DSP_MAPELEMSIZE8) {
 -   /* Size is 8 bit */
 -   hw_attrs.element_size = HW_ELEM_SIZE8BIT;
 -   } else if (attrs  DSP_MAPELEMSIZE16) {
 -   /* Size is 16 bit */
 -   hw_attrs.element_size = HW_ELEM_SIZE16BIT;
 -   } else if (attrs  DSP_MAPELEMSIZE32) {
 -   /* Size is 32 bit */
 -   hw_attrs.element_size = HW_ELEM_SIZE32BIT;
 -   } else if (attrs  DSP_MAPELEMSIZE64) {
 -   /* Size is 64 bit */
 -   hw_attrs.element_size = HW_ELEM_SIZE64BIT;
 -   } else {
 -   /*
 -* Mixedsize isn't enabled, so size can't be
 -* zero here
 -*/
 -   return -EINVAL;
 -   }
 -   }
 -   if (attrs  DSP_MAPDONOTLOCK)
 -   hw_attrs.donotlockmpupage = 1;
 -   else
 -   hw_attrs.donotlockmpupage = 0;
 +   if (!size || !usr_pgs)
 +   return -EINVAL;
 
 -   if (attrs  DSP_MAPVMALLOCADDR) {
 -   return mem_map_vmalloc(dev_ctxt, ul_mpu_addr, virt_addr,
 -  ul_num_bytes, hw_attrs);
 -   }
 -   /*
 -* Do OS-specific user-va to pa translation.
 -* Combine physically contiguous regions to reduce TLBs.
 -* Pass the translated pa to pte_update.
 -*/
 -

Re: [PATCH] OMAP2: PM: check UART status before trying to idle

* Kevin Hilman khil...@deeprootsystems.com [101006 08:43]:
 As is done on OMAP3, check omap_uart_can_sleep() as one of the
 pre-conditions for entering the idle loop.  Without this check,
 entering idle introduces large latencies on active UARTs, and is
 especially noticable on serial console.
 
 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
 ---
 Tony, this fixes the UART lag when using the serial console on n8x0.
 With this, the UARTs will not idle until their sleep timeouts are
 activated, and they're disabled by default.
 
 There's an additional bug I'm still looking into as to why UART3
 does not trigger wakeup from idle on 2420, but that is only triggered
 after enabling UART timeouts.
 
  arch/arm/mach-omap2/pm24xx.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
 index c1bceec..a40457d 100644
 --- a/arch/arm/mach-omap2/pm24xx.c
 +++ b/arch/arm/mach-omap2/pm24xx.c
 @@ -245,6 +245,8 @@ static int omap2_can_sleep(void)
  {
   if (omap2_fclks_active())
   return 0;
 + if (!omap_uart_can_sleep())
 + return 0;
   if (osc_ck-usecount  1)
   return 0;
   if (omap_dma_running())

Thanks, I'll add that to omap-for-linus. Also the following change
is needed for the n8x0 boards that use the kernel cmdline only.

Regards,

Tony

From: Tony Lindgren t...@atomide.com
Date: Tue, 5 Oct 2010 10:09:03 -0700
Subject: [PATCH] omap: Update omap2plus_defconfig to use ttyO instead ttyS

With the omap-serial the device has changed from ttyS to ttyO as
the system may have both omap-serial and 8250 ports.

Note that systems using omap-serial need to be updated to use ttyO[012]
instead of ttyS[012] in the bootloader, CONFIG_CMDLINE, /etc/inittab,
and the root file system with mknod. Also you may need to add ttyO[012]
to /etc/securetty.

Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 7deec89..ccedde1 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -63,7 +63,7 @@ CONFIG_AEABI=y
 CONFIG_LEDS=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyS2,115200
+CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
 CONFIG_KEXEC=y
 CONFIG_FPE_NWFPE=y
 CONFIG_VFP=y
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread Madhusudhan Chikkature


snip

 You are correct!  The version of the patch in the repo indeed has
 'out' in the wrong place and generates a compile error.

 Could you post the patch you are using and I will try to reproduce
 what you are seeing on my hardware?  Best we all work from exactly the
 same patch!

 Steve


Yes. I think that check breaking the compilation is not needed. How about the
below version? It just removes that check.

This version should apply fine on the latest kernel. I did a sanity test of
MMC/SD cards on OMAP4 SDP.

Steve or Mike can check if SDIO interrupts are working.

Regards,
Madhu

From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001
From: David Vrabel david.vra...@csr.com
Date: Wed, 6 Oct 2010 12:39:18 -0500
Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts

Enable the use of SDIO card interrupts.

FCLK must be enabled while SDIO interrupts are enabled or the MMC
module won't wake-up (even though ENAWAKEUP in SYSCONFIG and IWE in
HTCL have been set).  Enabling the MMC module to wake-up would require
configuring the MMC module (and the mmci_dat[1] GPIO when the CORE
power domain is OFF) as wake-up sources in the PRCM.

The writes to STAT and ISE when starting a command are unnecessary and
have been removed.

Signed-off-by: David Vrabel david.vra...@csr.com
---
 drivers/mmc/host/omap_hsmmc.c |   72 +
 1 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4693e62..948dd9a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -66,6 +66,7 @@
 #define SDVS_MASK  0x0E00
 #define SDVSCLR0xF1FF
 #define SDVSDET0x0400
+#define ENAWAKEUP  (1  2)
 #define AUTOIDLE   0x1
 #define SDBP   (1  8)
 #define DTO0xe
@@ -76,9 +77,12 @@
 #define CLKD_SHIFT 6
 #define DTO_MASK   0x000F
 #define DTO_SHIFT  16
+#define CIRQ_ENABLE(1  8)
 #define INT_EN_MASK0x307F0033
 #define BWR_ENABLE (1  4)
 #define BRR_ENABLE (1  5)
+#define CTPL   (1  11)
+#define CLKEXTFREE (1  16)
 #define DTO_ENABLE (1  20)
 #define INIT_STREAM(1  1)
 #define DP_SELECT  (1  21)
@@ -87,10 +91,12 @@
 #define MSBS   (1  5)
 #define BCE(1  1)
 #define FOUR_BIT   (1  1)
+#define IWE(1  24)
 #define DW8(1  5)
 #define CC 0x1
 #define TC 0x02
 #define OD 0x1
+#define CIRQ   (1  8)
 #define ERR(1  15)
 #define CMD_TIMEOUT(1  16)
 #define DATA_TIMEOUT   (1  20)
@@ -184,6 +190,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   int sdio_int;

struct  omap_mmc_platform_data  *pdata;
 };
@@ -551,6 +558,9 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_ENABLE;

+   if (host-sdio_int)
+   irq_mask |= CIRQ;
+
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -603,7 +613,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;

OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
-   OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+   OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE | ENAWAKEUP);

if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF 
@@ -618,7 +628,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}

OMAP_HSMMC_WRITE(host-base, HCTL,
-   OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+   OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);

OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -1019,6 +1029,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
 {
struct mmc_data *data;
int end_cmd = 0, end_trans = 0;
+   bool card_irq = false;

if (!host-req_in_progress) {
do {
@@ -1032,6 +1043,9 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
data = host-data;
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);

+   if (status  CIRQ)
+   card_irq = true;
+
if (status  ERR) {
 #ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1087,6 +1101,9 @@

Re: [PATCH 00/10] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37

2010-10-06 Thread Paul Walmsley

Hi, 
On Wed, 6 Oct 2010, Liam Girdwood wrote:

 On Wed, 2010-10-06 at 07:48 -0700, Tony Lindgren wrote:
  * Peter Ujfalusi peter.ujfal...@nokia.com [101005 22:33]:
   On Tuesday 05 October 2010 21:40:17 ext Tony Lindgren wrote:
   
   ...
   
 For patches 6-7 you could have my ack.
 Acked-by: Jarkko Nikula jhnik...@gmail.com
 
 As they are touching also sound/soc/omap/omap-mcbsp.c, an ack from 
 Mark
 and Liam are needed. Links to patches 6 and 7 below and my fixes on 
 top
 of them [1].
 
 http://marc.info/?l=linux-omapm=128596931117788w=2
 http://marc.info/?l=linux-omapm=128596931417805w=2

Sorry, I've already merged them as they fixed code that did not compile.

Let me know if you guys want me to rebuild those parts of omap-for-linus
to add the acks.
   
   If you decide to rebuild, than you can add my (for patch 6-7):
   Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com 
  
  OK, let's do that then we should still have some time left before the
  merge window.
  
  Mark  Liam, care to ack as well?
  
 
 Acked-by: Liam Girdwood l...@slimlogic.co.uk

Okay, acks from Liam, Mark, Peter, and Jarkko have been added to patches 6 
and 7.  Also, acks from Peter have been added to Jarkko's three patches.  
Jarkko's three patches have been added on to the original ten.  Will send 
out an updated pull request shortly.


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

[GIT PULL v2] OMAP: SCM/McBSP/clock: branch integration patches for 2.6.37

2010-10-06 Thread Paul Walmsley

Hello Tony,

Here is an updated pull request for the ten original patches sent earlier, 
with recent Acked-by:'s added, and also with Jarkko's three fix patches:

The following changes since commit dbd3ad5354dbbe3f4ea7c0675d91475c25280f69:

  omap: hwmod: Handle modules with 16bit registers (2010-10-06 10:18:04 -0700)

are available in the git repository at:
  git://git.pwsan.com/linux-2.6 control_mcbsp_fix_2.6.37

Jarkko Nikula (3):
  OMAP: McBSP: Fix CLKR and FSR signal muxing
  OMAP: McBSP: Swap CLKS source definition
  OMAP: McBSP: Remove null omap44xx ops comment

Paul Walmsley (10):
  OMAP2+: Kconfig: disallow builds for boards that don't use the 
currently-selected SoC
  OMAP2420: CTRL: fix OMAP242X_CTRL_REGADDR macro
  OMAP2420: clock: add MCBSP_CLKS node and clkdev aliases
  OMAP2430: clock: add MCBSP_CLKS node and clkdev aliases
  OMAP3xxx: clock: add clkdev aliases for McBSP fclk source switching
  OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via 
mach-omap2/mcbsp.c
  OMAP: McBSP: implement functional clock switching via clock framework
  OMAP: split plat-omap/common.c
  OMAP: control: move plat-omap/control.h to mach-omap2/control.h
  OMAP2+: clock: reduce the amount of standard debugging while disabling 
unused clocks

 arch/arm/mach-omap2/Kconfig|6 +-
 arch/arm/mach-omap2/Makefile   |3 +-
 arch/arm/mach-omap2/board-3430sdp.c|2 +-
 arch/arm/mach-omap2/board-4430sdp.c|2 +-
 arch/arm/mach-omap2/board-am3517evm.c  |2 +-
 arch/arm/mach-omap2/board-apollon.c|2 +-
 arch/arm/mach-omap2/board-cm-t3517.c   |2 +-
 arch/arm/mach-omap2/board-generic.c|   16 +-
 arch/arm/mach-omap2/board-h4.c |2 +-
 arch/arm/mach-omap2/board-ldp.c|2 +-
 arch/arm/mach-omap2/board-omap3logic.c |2 +-
 arch/arm/mach-omap2/board-omap4panda.c |4 +-
 arch/arm/mach-omap2/clock.c|2 +-
 arch/arm/mach-omap2/clock2420_data.c   |   40 +++-
 arch/arm/mach-omap2/clock2430_data.c   |   64 +-
 arch/arm/mach-omap2/clock3xxx_data.c   |   12 +-
 arch/arm/mach-omap2/clock44xx_data.c   |2 +-
 arch/arm/mach-omap2/common.c   |  135 ++
 arch/arm/mach-omap2/control.c  |3 +-
 .../include/plat = mach-omap2}/control.h  |   18 +-
 arch/arm/mach-omap2/cpuidle34xx.c  |2 +-
 arch/arm/mach-omap2/devices.c  |3 +-
 arch/arm/mach-omap2/hsmmc.c|2 +-
 arch/arm/mach-omap2/id.c   |3 +-
 arch/arm/mach-omap2/mcbsp.c|   80 ++
 arch/arm/mach-omap2/mux.c  |8 +-
 arch/arm/mach-omap2/pm24xx.c   |2 +-
 arch/arm/mach-omap2/pm34xx.c   |2 +-
 arch/arm/mach-omap2/prcm.c |2 +-
 arch/arm/mach-omap2/serial.c   |2 +-
 arch/arm/mach-omap2/sleep34xx.S|2 +-
 arch/arm/mach-omap2/usb-fs.c   |6 +-
 arch/arm/plat-omap/Makefile|2 +-
 arch/arm/plat-omap/clock.c |5 +-
 arch/arm/plat-omap/common.c|  275 
 arch/arm/plat-omap/counter_32k.c   |  183 +
 arch/arm/plat-omap/devices.c   |1 -
 arch/arm/plat-omap/include/plat/mcbsp.h|   22 ++
 arch/arm/plat-omap/include/plat/omap-serial.h  |1 -
 arch/arm/plat-omap/include/plat/omap24xx.h |2 +-
 arch/arm/plat-omap/mcbsp.c |3 -
 arch/arm/plat-omap/sram.c  |3 -
 drivers/usb/gadget/omap_udc.c  |   18 +-
 sound/soc/omap/omap-mcbsp.c|  119 ++---
 44 files changed, 625 insertions(+), 444 deletions(-)
 create mode 100644 arch/arm/mach-omap2/common.c
 rename arch/arm/{plat-omap/include/plat = mach-omap2}/control.h (97%)
 create mode 100644 arch/arm/plat-omap/counter_32k.c


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

Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread David Vrabel

Madhusudhan Chikkature wrote:
 
 This version should apply fine on the latest kernel. I did a sanity test of
 MMC/SD cards on OMAP4 SDP.

This /looks/ okay to me, but I can't test it.

 From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001
 From: David Vrabel david.vra...@csr.com
 Date: Wed, 6 Oct 2010 12:39:18 -0500
 Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts
 
[...]
 
 The writes to STAT and ISE when starting a command are unnecessary and
 have been removed.

Remove this last paragraph from the description as it isn't applicable
any more.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/


Member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

2010-10-06 Thread Madhusudhan

 -Original Message-
 From: David Vrabel [mailto:david.vra...@csr.com]
 Sent: Wednesday, October 06, 2010 2:02 PM
 To: Madhusudhan Chikkature
 Cc: Steve Sakoman; Mike Rapoport; Chris Ball; linux-...@vger.kernel.org;
 linux-omap@vger.kernel.org; Adrian Hunter
 Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)

 Madhusudhan Chikkature wrote:

  This version should apply fine on the latest kernel. I did a sanity test
 of
  MMC/SD cards on OMAP4 SDP.

 This /looks/ okay to me, but I can't test it.

  From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001
  From: David Vrabel david.vra...@csr.com
  Date: Wed, 6 Oct 2010 12:39:18 -0500
  Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts

 [...]

  The writes to STAT and ISE when starting a command are unnecessary and
  have been removed.

 Remove this last paragraph from the description as it isn't applicable
 any more.

Sure.

Regards,
Madhu

 David
 --
 David Vrabel, Senior Software Engineer, Drivers
 CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/

 Member of the CSR plc group of companies. CSR plc registered in England
 and Wales, registered number 4187346, registered office Churchill House,
 Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

--
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] PM: add synchronous runtime interface for interrupt handlers

2010-10-06 Thread Rafael J. Wysocki

On Wednesday, October 06, 2010, Alan Stern wrote:
 On Tue, 5 Oct 2010, Kevin Hilman wrote:
 
  Alan Stern st...@rowland.harvard.edu writes:
  
   On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
  
 In my opinion the _irq operations should really be one-shot, without
 any looping, waking up parents etc.  I mean, if the parent is not 
 RPM_ACTIVE,
 the _irq resume should immediately fail and analogously for the _irq
 suspend.  And so on.  As simple as reasonably possible.

But what if the device's own status is currently SUSPENDING or
RESUMING?  Do you want to fail when that happens, instead of waiting
for the concurrent operation to finish?
   
   Yes.  IMO an _irq() suspend should only be allowed if the status is 
   RPM_ACTIVE
   and an _irq() resume should fail if the status is not RPM_SUSPENDED.  The
   error code returned should depend on the situation, though.
   
There's no way to prevent this
on SMP systems, because a wakeup request can arrive while a
software-initiated resume is in progress.
   
   I know that. :-)
  
   I suspect Kevin will not want to live with this restriction, but I'd
   like to hear from him.  Kevin?
  
  [ Apologies for the delays... I've been running around preparing OMAP PM
stuff for the upcoming merge window. ]
  
  I think I can live with the above restrictions (the _irq methods failing
  unless they can immediately run.)  For the rare corner cases I've
  currently run into, this will work fine as they happen because of a
  wakeup IRQ, where we know the device is RPM_SUSPENDED.
 
 Then what will the driver do if it gets a wakeup IRQ but it can't
 resume the device because some other thread is in the middle of a
 suspend or resume?

Queue up a resume request and return.

Thanks,
Rafael
--
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] PM: add synchronous runtime interface for interrupt handlers

Alan Stern st...@rowland.harvard.edu writes:

 On Tue, 5 Oct 2010, Kevin Hilman wrote:

 Alan Stern st...@rowland.harvard.edu writes:
 
  On Fri, 1 Oct 2010, Rafael J. Wysocki wrote:
 
In my opinion the _irq operations should really be one-shot, without
any looping, waking up parents etc.  I mean, if the parent is not 
RPM_ACTIVE,
the _irq resume should immediately fail and analogously for the _irq
suspend.  And so on.  As simple as reasonably possible.
   
   But what if the device's own status is currently SUSPENDING or
   RESUMING?  Do you want to fail when that happens, instead of waiting
   for the concurrent operation to finish?
  
  Yes.  IMO an _irq() suspend should only be allowed if the status is 
  RPM_ACTIVE
  and an _irq() resume should fail if the status is not RPM_SUSPENDED.  The
  error code returned should depend on the situation, though.
  
   There's no way to prevent this
   on SMP systems, because a wakeup request can arrive while a
   software-initiated resume is in progress.
  
  I know that. :-)
 
  I suspect Kevin will not want to live with this restriction, but I'd
  like to hear from him.  Kevin?
 
 [ Apologies for the delays... I've been running around preparing OMAP PM
   stuff for the upcoming merge window. ]
 
 I think I can live with the above restrictions (the _irq methods failing
 unless they can immediately run.)  For the rare corner cases I've
 currently run into, this will work fine as they happen because of a
 wakeup IRQ, where we know the device is RPM_SUSPENDED.

 Then what will the driver do if it gets a wakeup IRQ but it can't
 resume the device because some other thread is in the middle of a
 suspend or resume?

In those cases, I guess it will have to return IRQ_NONE, and print some
sort of error.  Alternatively, it could fall back to the high-latency
case of masking the IRQ and doing an asynchronous call then call the ISR
in the runtime_resume callback.

For the corner cases that I've run into, other transitions will not be
in progress because system has just woken up (so no threads are in the
middle of suspends or resumes) and the IRQ fires as soon as pm_idle
enables interrupts, and before there's a chance to schedule anything
else.

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

Re: [PATCH] omap: zoom2/3: fix build caused by wl1271 support

2010-10-06 Thread Luciano Coelho

On Wed, 2010-10-06 at 17:55 +0200, ext Luciano Coelho wrote:
 On Wed, 2010-10-06 at 17:30 +0200, ext John W. Linville wrote:
  On Wed, Oct 06, 2010 at 06:27:49PM +0300, Luciano Coelho wrote:
   On Wed, 2010-10-06 at 16:01 +0200, ext Gadiyar, Anand wrote:
 Hmmm... We got a problem here.  This patch breaks builds when we 
 *don't*
 have omap: mmc extended to pass host capabilities from board file. 
  We
 don't have that on wireless-next yet, so builds with zoom boards
 selected are broken.

 Any ideas on how to solve this dilemma? I guess the proper way to 
 handle
 this would be to make the changes proposed in this patch when merging
 instead of having a normal commit for it, wouldn't it?

 Just cherry-pick that change into the branch of your tree that I do
 _not_ pull from.  I presume that it is already available in 
 linux-next?


Yup - both patches are in linux-next; that's where we noticed the build 
break.
   
   Ok, I hope the patch applies cleanly in our trees.
   
   John, don't you want to do the cherry-pick on your wireless-testing
   then? If you do it, I can inherit that, because I pull from it into my
   testing branch (wl12xx/master).  At the moment, w-t is broken too.
  
  OK, that's fine -- do you have the commit ID and the tree that has it?
 
 Stephen's linux-net, commit 3a63833ec3002816a759a49ebda4e229c089114e.
 
 http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=3a63833ec3002816a759a49ebda4e229c089114e

I have cherry-picked it and merged it (there was a tiny conflict).  I've
pushed it into my wl12xx/master branch (wl12xx is at
git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git).

If you want to take it from my tree (which is already merged) into
wireless-testing, the commit is
adca3773ed7ad185b1314432b6fbf92db7e11bc0.


-- 
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: [PATCHv3 01/11] staging: tidspbridge: replace iommu custom for opensource implementation

2010-10-06 Thread Guzman Lugo, Fernando



 -Original Message-
 From: David Cohen [mailto:david.co...@nokia.com]
 Sent: Wednesday, October 06, 2010 12:33 PM
 To: Guzman Lugo, Fernando
 Cc: gre...@suse.de; Contreras Felipe (Nokia-MS/Helsinki);
 Palande Ameya (Nokia-MS/Helsinki); Menon, Nishanth; Doyu
 Hiroshi (Nokia-MS/Espoo); o...@wizery.com;
 linux-ker...@vger.kernel.org; andy.shevche...@gmail.com;
 linux-omap@vger.kernel.org
 Subject: Re: [PATCHv3 01/11] staging: tidspbridge: replace
 iommu custom for opensource implementation

 Hi Fernando,

 I have few comments below.

Hi David,

Thanks for review.


  diff --git a/drivers/staging/tidspbridge/core/io_sm.c
  b/drivers/staging/tidspbridge/core/io_sm.c
  index 5718645..842b8db 100644
  --- a/drivers/staging/tidspbridge/core/io_sm.c
  +++ b/drivers/staging/tidspbridge/core/io_sm.c
  @@ -291,6 +291,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
  struct cod_manager *cod_man;
  struct chnl_mgr *hchnl_mgr;
  struct msg_mgr *hmsg_mgr;
  +   struct iommu *mmu;
  u32 ul_shm_base;
  u32 ul_shm_base_offset;
  u32 ul_shm_limit;
  @@ -313,7 +314,6 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
  struct bridge_ioctl_extproc ae_proc[BRDIOCTL_NUMOFMMUTLB];
  struct cfg_hostres *host_res;
  struct bridge_dev_context *pbridge_context;
  -   u32 map_attrs;
  u32 shm0_end;
  u32 ul_dyn_ext_base;
  u32 ul_seg1_size = 0;
  @@ -337,6 +337,20 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
  status = -EFAULT;
  goto func_end;
  }
  +   mmu = pbridge_context-dsp_mmu;
  +
  +   if (mmu)
  +   iommu_put(mmu);
  +   mmu = iommu_get(iva2);
  +
  +   if (IS_ERR_OR_NULL(mmu)) {

 You can use IS_ERR() instead.


The patch are already merged, so I cannot modified this patch. Even tought
That change is done when all related code is change to the new file
Dsp-mmu.c. Please check patch 7/11.

 [snip]

  @@ -1122,217 +1081,81 @@ static int
 bridge_brd_mem_write(struct bridge_dev_context *dev_ctxt,
*
*  TODO: Disable MMU while updating the page tables (but
 that'll stall DSP)
*/
  -static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
  - u32 ul_mpu_addr, u32 virt_addr,
  - u32 ul_num_bytes, u32 ul_map_attr,
  - struct page **mapped_pages)
  +static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctx,
  +   u32 uva, u32 da, u32 size, u32 attr,
  +   struct page **usr_pgs)
  +
   {
  -   u32 attrs;
  -   int status = 0;
  -   struct bridge_dev_context *dev_context = dev_ctxt;
  -   struct hw_mmu_map_attrs_t hw_attrs;
  +   int res, w;
  +   unsigned pages, i;
  +   struct iommu *mmu = dev_ctx-dsp_mmu;
  struct vm_area_struct *vma;
  struct mm_struct *mm = current-mm;
  -   u32 write = 0;
  -   u32 num_usr_pgs = 0;
  -   struct page *mapped_page, *pg;
  -   s32 pg_num;
  -   u32 va = virt_addr;
  -   struct task_struct *curr_task = current;
  -   u32 pg_i = 0;
  -   u32 mpu_addr, pa;
  -
  -   dev_dbg(bridge,
  -   %s hDevCtxt %p, pa %x, va %x, size %x,
 ul_map_attr %x\n,
  -   __func__, dev_ctxt, ul_mpu_addr, virt_addr,
 ul_num_bytes,
  -   ul_map_attr);
  -   if (ul_num_bytes == 0)
  -   return -EINVAL;
  +   struct sg_table *sgt;
  +   struct scatterlist *sg;
 
  -   if (ul_map_attr  DSP_MAP_DIR_MASK) {
  -   attrs = ul_map_attr;
  -   } else {
  -   /* Assign default attributes */
  -   attrs = ul_map_attr | (DSP_MAPVIRTUALADDR |
 DSP_MAPELEMSIZE16);
  -   }
  -   /* Take mapping properties */
  -   if (attrs  DSP_MAPBIGENDIAN)
  -   hw_attrs.endianism = HW_BIG_ENDIAN;
  -   else
  -   hw_attrs.endianism = HW_LITTLE_ENDIAN;
  -
  -   hw_attrs.mixed_size = (enum hw_mmu_mixed_size_t)
  -   ((attrs  DSP_MAPMIXEDELEMSIZE)  2);
  -   /* Ignore element_size if mixed_size is enabled */
  -   if (hw_attrs.mixed_size == 0) {
  -   if (attrs  DSP_MAPELEMSIZE8) {
  -   /* Size is 8 bit */
  -   hw_attrs.element_size = HW_ELEM_SIZE8BIT;
  -   } else if (attrs  DSP_MAPELEMSIZE16) {
  -   /* Size is 16 bit */
  -   hw_attrs.element_size = HW_ELEM_SIZE16BIT;
  -   } else if (attrs  DSP_MAPELEMSIZE32) {
  -   /* Size is 32 bit */
  -   hw_attrs.element_size = HW_ELEM_SIZE32BIT;
  -   } else if (attrs  DSP_MAPELEMSIZE64) {
  -   /* Size is 64 bit */
  -   hw_attrs.element_size = HW_ELEM_SIZE64BIT;
  -   } else {
  -

Re: [PATCHv2 1/7] pwm: Add pwm core driver

Arun MURTHY arun.mur...@stericsson.com writes:

[...]

 
 I suggest that you work on Kevin's comments before making any code
 changes though.

 This pwm driver also supports the Davinci pwm driver as suggested by
 Kelvin.

My concern isn't whether it supports davinci or not.  Adapting existing
drivers is the easy part.

My concern is that there are now two proposals for a generic PWM
framework, and I would prefer to see that those projects are aligned
before anything merges.

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

Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers

2010-10-06 Thread Alan Stern

On Wed, 6 Oct 2010, Kevin Hilman wrote:

  I think I can live with the above restrictions (the _irq methods failing
  unless they can immediately run.)  For the rare corner cases I've
  currently run into, this will work fine as they happen because of a
  wakeup IRQ, where we know the device is RPM_SUSPENDED.
 
  Then what will the driver do if it gets a wakeup IRQ but it can't
  resume the device because some other thread is in the middle of a
  suspend or resume?
 
 In those cases, I guess it will have to return IRQ_NONE, and print some
 sort of error.

Without handling the IRQ?  I guess if the transient state (SUSPENDING
or RESUMING) ends quickly enough then the kernel won't permanently
disable the IRQ line (although getting hundreds of repeated error
messages in the system log might prove daunting).  Would you want to 
rely on that?

  Alternatively, it could fall back to the high-latency
 case of masking the IRQ and doing an asynchronous call then call the ISR
 in the runtime_resume callback.

Yes, this probably would be acceptable since it wouldn't happen very 
often.  Still, having two different pathways (one of which is very low 
probability) usually isn't a good idea.

 For the corner cases that I've run into, other transitions will not be
 in progress because system has just woken up (so no threads are in the
 middle of suspends or resumes) and the IRQ fires as soon as pm_idle
 enables interrupts, and before there's a chance to schedule anything
 else.

Ah, but once you integrate the runtime PM framework into your driver, 
you run the risk of resumes occurring for reasons that aren't under 
your control.  For example, the user can force a runtime-suspended 
device to resume by writing on to the device's power/control sysfs 
attribute.  What would happen if a wakeup IRQ arrived just as the 
resume was starting?

(Actually, this particular failure mode shouldn't concern you very much
since it applies only to SMP systems.  But it's important to think of
the future -- I can imagine SMP OMAPs coming out before too long.)

On the whole, I don't see any striking reason for the PM core not to 
busy-wait during a concurrent state change.  Refusing to wake up a 
suspended parent ... okay, maybe that's a little more defensible.  
Especially since in many or most cases the parent (if there is one) 
will probably be runtime-PM-disabled anyway.

Alan Stern

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

Re: [PATCH 0/4] omap4: pandaboard: machine cleanups

* Tony Lindgren t...@atomide.com [100927 15:22]:
 * David Anders x0132...@ti.com [100921 14:15]:
  PandaBoard machine file related cleanups.
  
  David Anders (4):
omap4: pandaboard: remove unused hsmmc definition
omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
omap4: pandaboard: Adding card detect support for MMC1
omap4: pandaboard: enable the ehci port on pandaboard
  
   arch/arm/mach-omap2/board-omap4panda.c |   76 
  +---
   1 files changed, 69 insertions(+), 7 deletions(-)
 
 David, please repost this series one more time with linux-arm-kernel
 list also Cc'd in addition to the linux-omap list.

Ping, we're starting to run out of time!

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/4] omap4: pandaboard: machine cleanups


Tony,

must have missed this request, i'll repost now

thanks
Dave

On 10/06/2010 03:56 PM, Tony Lindgren wrote:

* Tony Lindgrent...@atomide.com  [100927 15:22]:
   

* David Andersx0132...@ti.com  [100921 14:15]:
 

PandaBoard machine file related cleanups.

David Anders (4):
   omap4: pandaboard: remove unused hsmmc definition
   omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
   omap4: pandaboard: Adding card detect support for MMC1
   omap4: pandaboard: enable the ehci port on pandaboard

  arch/arm/mach-omap2/board-omap4panda.c |   76 +---
  1 files changed, 69 insertions(+), 7 deletions(-)
   

David, please repost this series one more time with linux-arm-kernel
list also Cc'd in addition to the linux-omap list.
 

Ping, we're starting to run out of time!

Tony
   


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

[PATCH 4/4] omap4: pandaboard: enable the ehci port on pandaboard

The OMAP4 PandaBoard has EHCI port1 hooked up to an external
SMSC3320 transciever. GPIO 1 is used to power on the transceiver
and GPIO 62 for reset on the transceiver.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |   54 
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 94e819c..6163a59 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -39,6 +39,8 @@
 #include plat/mmc.h
 #include hsmmc.h
 
+#define GPIO_HUB_POWER 1
+#define GPIO_HUB_NRESET62
 
 static void __init omap4_panda_init_irq(void)
 {
@@ -280,6 +282,57 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
 }
+
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+   .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .phy_reset  = false,
+   .reset_gpio_port[0]  = -EINVAL,
+   .reset_gpio_port[1]  = -EINVAL,
+   .reset_gpio_port[2]  = -EINVAL
+};
+
+static void __init omap4_ehci_init(void)
+{
+   int ret;
+
+
+   /* disable the power to the usb hub prior to init */
+   ret = gpio_request(GPIO_HUB_POWER, hub_power);
+   if (ret) {
+   pr_err(Cannot request GPIO %d\n, GPIO_HUB_POWER);
+   goto error1;
+   }
+   gpio_export(GPIO_HUB_POWER, 0);
+   gpio_direction_output(GPIO_HUB_POWER, 0);
+   gpio_set_value(GPIO_HUB_POWER, 0);
+
+   /* reset phy+hub */
+   ret = gpio_request(GPIO_HUB_NRESET, hub_nreset);
+   if (ret) {
+   pr_err(Cannot request GPIO %d\n, GPIO_HUB_NRESET);
+   goto error2;
+   }
+   gpio_export(GPIO_HUB_NRESET, 0);
+   gpio_direction_output(GPIO_HUB_NRESET, 0);
+   gpio_set_value(GPIO_HUB_NRESET, 0);
+   gpio_set_value(GPIO_HUB_NRESET, 1);
+
+   usb_ehci_init(ehci_pdata);
+
+   /* enable power to hub */
+   gpio_set_value(GPIO_HUB_POWER, 1);
+   return;
+
+error2:
+   gpio_free(GPIO_HUB_POWER);
+error1:
+   pr_err(Unable to initialize EHCI power/reset\n);
+   return;
+
+}
+
 static void __init omap4_panda_init(void)
 {
omap4_panda_i2c_init();
@@ -287,6 +340,7 @@ static void __init omap4_panda_init(void)
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
+   omap4_ehci_init();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
-- 
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/4] omap4: pandaboard: machine cleanups

PandaBoard machine file related cleanups.

David Anders (4):
  omap4: pandaboard: remove unused hsmmc definition
  omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
  omap4: pandaboard: Adding card detect support for MMC1
  omap4: pandaboard: enable the ehci port on pandaboard

 arch/arm/mach-omap2/board-omap4panda.c |   76 +---
 1 files changed, 69 insertions(+), 7 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/4] omap4: pandaboard: remove unused hsmmc definition

remove the second hsmmc definition as it is only used on the
expansion header of the PandaBoard and can be mux for other
functions.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 96f5bbb..093d13b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -67,10 +67,6 @@ static struct regulator_consumer_supply 
omap4_panda_vmmc_supply[] = {
.supply = vmmc,
.dev_name = mmci-omap-hs.0,
},
-   {
-   .supply = vmmc,
-   .dev_name = mmci-omap-hs.1,
-   },
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
@@ -156,7 +152,7 @@ static struct regulator_init_data omap4_panda_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 2,
+   .num_consumer_supplies  = 1,
.consumer_supplies  = omap4_panda_vmmc_supply,
 };
 
-- 
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/4] omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set

Avoid possible crash if CONFIG_MMC_OMAP_HS is not set.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 093d13b..697c0bd 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -85,7 +85,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
 
 static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
 {
-   struct omap_mmc_platform_data *pdata = dev-platform_data;
+   struct omap_mmc_platform_data *pdata;
+
+   /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+   if (!dev) {
+   pr_err(Failed omap4_twl6030_hsmmc_set_late_init\n);
+   return;
+   }
+   pdata = dev-platform_data;
 
pdata-init =   omap4_twl6030_hsmmc_late_init;
 }
-- 
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/4] omap4: pandaboard: Adding card detect support for MMC1

Adding card detect callback function and card detect configuration
function for MMC1 Controller.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---

patch depends on https://patchwork.kernel.org/patch/189952/

 arch/arm/mach-omap2/board-omap4panda.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 697c0bd..94e819c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -77,9 +77,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
 
/* Setting MMC1 Card detect Irq */
-   if (pdev-id == 0)
+   if (pdev-id == 0) {
+   ret = twl6030_mmc_card_detect_config();
+   if (ret)
+   pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+   pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+   }
return ret;
 }
 
-- 
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/4] omap4: pandaboard: Adding card detect support for MMC1

Adding card detect callback function and card detect configuration
function for MMC1 Controller.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---

patch depends on https://patchwork.kernel.org/patch/189952/

 arch/arm/mach-omap2/board-omap4panda.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 697c0bd..94e819c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -77,9 +77,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
 
/* Setting MMC1 Card detect Irq */
-   if (pdev-id == 0)
+   if (pdev-id == 0) {
+   ret = twl6030_mmc_card_detect_config();
+   if (ret)
+   pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+   pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+   }
return ret;
 }
 
-- 
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/4] omap4: pandaboard: enable the ehci port on pandaboard

The OMAP4 PandaBoard has EHCI port1 hooked up to an external
SMSC3320 transciever. GPIO 1 is used to power on the transceiver
and GPIO 62 for reset on the transceiver.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |   54 
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 94e819c..6163a59 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -39,6 +39,8 @@
 #include plat/mmc.h
 #include hsmmc.h
 
+#define GPIO_HUB_POWER 1
+#define GPIO_HUB_NRESET62
 
 static void __init omap4_panda_init_irq(void)
 {
@@ -280,6 +282,57 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
 }
+
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+   .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+   .phy_reset  = false,
+   .reset_gpio_port[0]  = -EINVAL,
+   .reset_gpio_port[1]  = -EINVAL,
+   .reset_gpio_port[2]  = -EINVAL
+};
+
+static void __init omap4_ehci_init(void)
+{
+   int ret;
+
+
+   /* disable the power to the usb hub prior to init */
+   ret = gpio_request(GPIO_HUB_POWER, hub_power);
+   if (ret) {
+   pr_err(Cannot request GPIO %d\n, GPIO_HUB_POWER);
+   goto error1;
+   }
+   gpio_export(GPIO_HUB_POWER, 0);
+   gpio_direction_output(GPIO_HUB_POWER, 0);
+   gpio_set_value(GPIO_HUB_POWER, 0);
+
+   /* reset phy+hub */
+   ret = gpio_request(GPIO_HUB_NRESET, hub_nreset);
+   if (ret) {
+   pr_err(Cannot request GPIO %d\n, GPIO_HUB_NRESET);
+   goto error2;
+   }
+   gpio_export(GPIO_HUB_NRESET, 0);
+   gpio_direction_output(GPIO_HUB_NRESET, 0);
+   gpio_set_value(GPIO_HUB_NRESET, 0);
+   gpio_set_value(GPIO_HUB_NRESET, 1);
+
+   usb_ehci_init(ehci_pdata);
+
+   /* enable power to hub */
+   gpio_set_value(GPIO_HUB_POWER, 1);
+   return;
+
+error2:
+   gpio_free(GPIO_HUB_POWER);
+error1:
+   pr_err(Unable to initialize EHCI power/reset\n);
+   return;
+
+}
+
 static void __init omap4_panda_init(void)
 {
omap4_panda_i2c_init();
@@ -287,6 +340,7 @@ static void __init omap4_panda_init(void)
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
+   omap4_ehci_init();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(musb_board_data);
-- 
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/4] omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set

Avoid possible crash if CONFIG_MMC_OMAP_HS is not set.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 093d13b..697c0bd 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -85,7 +85,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device *dev)
 
 static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
 {
-   struct omap_mmc_platform_data *pdata = dev-platform_data;
+   struct omap_mmc_platform_data *pdata;
+
+   /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+   if (!dev) {
+   pr_err(Failed omap4_twl6030_hsmmc_set_late_init\n);
+   return;
+   }
+   pdata = dev-platform_data;
 
pdata-init =   omap4_twl6030_hsmmc_late_init;
 }
-- 
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/4] omap4: pandaboard: machine cleanups

PandaBoard machine file related cleanups.

David Anders (4):
  omap4: pandaboard: remove unused hsmmc definition
  omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
  omap4: pandaboard: Adding card detect support for MMC1
  omap4: pandaboard: enable the ehci port on pandaboard

 arch/arm/mach-omap2/board-omap4panda.c |   76 +---
 1 files changed, 69 insertions(+), 7 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/4] omap4: pandaboard: remove unused hsmmc definition

remove the second hsmmc definition as it is only used on the
expansion header of the PandaBoard and can be mux for other
functions.

Signed-off-by: David Anders x0132...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 96f5bbb..093d13b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -67,10 +67,6 @@ static struct regulator_consumer_supply 
omap4_panda_vmmc_supply[] = {
.supply = vmmc,
.dev_name = mmci-omap-hs.0,
},
-   {
-   .supply = vmmc,
-   .dev_name = mmci-omap-hs.1,
-   },
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
@@ -156,7 +152,7 @@ static struct regulator_init_data omap4_panda_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 2,
+   .num_consumer_supplies  = 1,
.consumer_supplies  = omap4_panda_vmmc_supply,
 };
 
-- 
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 [0/4] perf: clean-up of power events API

2010-10-06 Thread Thomas Renninger

Hi,

On Monday 04 October 2010 17:20:57 Jean Pihet wrote:
 Here is a re-spin of the patches after discussion.

what is going to happen here now?

Is this supposed to go through Ingo's tree?

Ingo: do you mind commenting on this.

I see 3 possibilities:
  1) Power (or all) perf events are never going to change.
  
  If they are going to change, then now is the right time and
  2) Backward compatibility is provided in some way for some time.

  3) The power events get cleaned up without compatibility to
 former kernels versions.

There are patches for 2. and 3., for 1. there obviously are no
needed.
For 2., the patches (mine or Jeans), need some polishing. IMO
these double events inside of general code aren't that bad.
I trust Jean, that it's not that easy with all the include magic
and macros, partly realized that myself already and it's not worth
it to dig further for a temporary solution.

Votes so far:
1. Arjan
2. Myself, Jean
3. Peter Zijlstra and Mathieu Desnoyers

Jean's work got successfully blocked for weeks now.
If there would be a final decision by a maintainer who is going to
merge Jean's work, that would be great and it would finally be worth
to send updated patches again which hopefully some day find their way into
a linux-next kernel...

Thanks,

  Thomas
--
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] PM: add synchronous runtime interface for interrupt handlers

2010-10-06 Thread Rafael J. Wysocki

On Wednesday, October 06, 2010, Alan Stern wrote:
 On Wed, 6 Oct 2010, Kevin Hilman wrote:
 
   I think I can live with the above restrictions (the _irq methods failing
   unless they can immediately run.)  For the rare corner cases I've
   currently run into, this will work fine as they happen because of a
   wakeup IRQ, where we know the device is RPM_SUSPENDED.
  
   Then what will the driver do if it gets a wakeup IRQ but it can't
   resume the device because some other thread is in the middle of a
   suspend or resume?
  
  In those cases, I guess it will have to return IRQ_NONE, and print some
  sort of error.
 
 Without handling the IRQ?  I guess if the transient state (SUSPENDING
 or RESUMING) ends quickly enough then the kernel won't permanently
 disable the IRQ line (although getting hundreds of repeated error
 messages in the system log might prove daunting).  Would you want to 
 rely on that?
 
   Alternatively, it could fall back to the high-latency
  case of masking the IRQ and doing an asynchronous call then call the ISR
  in the runtime_resume callback.
 
 Yes, this probably would be acceptable since it wouldn't happen very 
 often.  Still, having two different pathways (one of which is very low 
 probability) usually isn't a good idea.
 
  For the corner cases that I've run into, other transitions will not be
  in progress because system has just woken up (so no threads are in the
  middle of suspends or resumes) and the IRQ fires as soon as pm_idle
  enables interrupts, and before there's a chance to schedule anything
  else.
 
 Ah, but once you integrate the runtime PM framework into your driver, 
 you run the risk of resumes occurring for reasons that aren't under 
 your control.  For example, the user can force a runtime-suspended 
 device to resume by writing on to the device's power/control sysfs 
 attribute.  What would happen if a wakeup IRQ arrived just as the 
 resume was starting?

Defer the resume.  That's the only thing you can do in any case, whether you're
going to busy loop or just use a workqueue.

 (Actually, this particular failure mode shouldn't concern you very much
 since it applies only to SMP systems.  But it's important to think of
 the future -- I can imagine SMP OMAPs coming out before too long.)
 
 On the whole, I don't see any striking reason for the PM core not to 
 busy-wait during a concurrent state change.

I do.  That shouldn't happen in a fast path and we're talking about one,
aren't we?  Besides, I don't like busy waiting as a rule.

 Refusing to wake up a 
 suspended parent ... okay, maybe that's a little more defensible.  
 Especially since in many or most cases the parent (if there is one) 
 will probably be runtime-PM-disabled anyway.

Either we do that, or we _must_ require that the parent's resume be irq-safe
(and the same for all the parents up in the device chain).

Overall, we seem to have a corner case to cover and we're considering doing
intrusive changes to the framework because of that, even though that changes
may not be really necessary in practice.  I think we should focus more on the
corner case instead.

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

Re: [PATCH 3/4] omap4: pandaboard: Adding card detect support for MMC1

David Anders x0132...@ti.com writes:

 Adding card detect callback function and card detect configuration
 function for MMC1 Controller.

 Signed-off-by: David Anders x0132...@ti.com
 Signed-off-by: Anand Gadiyar gadi...@ti.com
 ---

 patch depends on https://patchwork.kernel.org/patch/189952/

This link is for v2 of that patch, and the latest was v4.  Has this been
tested with v4?

Kevin

  arch/arm/mach-omap2/board-omap4panda.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index 697c0bd..94e819c 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -77,9 +77,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
 *dev)
   struct omap_mmc_platform_data *pdata = dev-platform_data;
  
   /* Setting MMC1 Card detect Irq */
 - if (pdev-id == 0)
 + if (pdev-id == 0) {
 + ret = twl6030_mmc_card_detect_config();
 + if (ret)
 + pr_err(Failed configuring MMC1 card detect\n);
   pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
   MMCDETECT_INTR_OFFSET;
 + pdata-slots[0].card_detect = twl6030_mmc_card_detect;
 + }
   return ret;
  }
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] omap4: pandaboard: enable the ehci port on pandaboard

David Anders x0132...@ti.com writes:

 The OMAP4 PandaBoard has EHCI port1 hooked up to an external
 SMSC3320 transciever. GPIO 1 is used to power on the transceiver
 and GPIO 62 for reset on the transceiver.

 Signed-off-by: David Anders x0132...@ti.com
 Signed-off-by: Anand Gadiyar gadi...@ti.com

This one fails to apply to current l-o master.

Kevin


 ---
  arch/arm/mach-omap2/board-omap4panda.c |   54 
 
  1 files changed, 54 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index 94e819c..6163a59 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -39,6 +39,8 @@
  #include plat/mmc.h
  #include hsmmc.h
  
 +#define GPIO_HUB_POWER   1
 +#define GPIO_HUB_NRESET  62
  
  static void __init omap4_panda_init_irq(void)
  {
 @@ -280,6 +282,57 @@ static int __init omap4_panda_i2c_init(void)
   omap_register_i2c_bus(4, 400, NULL, 0);
   return 0;
  }
 +
 +static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
 + .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
 + .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
 + .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
 + .phy_reset  = false,
 + .reset_gpio_port[0]  = -EINVAL,
 + .reset_gpio_port[1]  = -EINVAL,
 + .reset_gpio_port[2]  = -EINVAL
 +};
 +
 +static void __init omap4_ehci_init(void)
 +{
 + int ret;
 +
 +
 + /* disable the power to the usb hub prior to init */
 + ret = gpio_request(GPIO_HUB_POWER, hub_power);
 + if (ret) {
 + pr_err(Cannot request GPIO %d\n, GPIO_HUB_POWER);
 + goto error1;
 + }
 + gpio_export(GPIO_HUB_POWER, 0);
 + gpio_direction_output(GPIO_HUB_POWER, 0);
 + gpio_set_value(GPIO_HUB_POWER, 0);
 +
 + /* reset phy+hub */
 + ret = gpio_request(GPIO_HUB_NRESET, hub_nreset);
 + if (ret) {
 + pr_err(Cannot request GPIO %d\n, GPIO_HUB_NRESET);
 + goto error2;
 + }
 + gpio_export(GPIO_HUB_NRESET, 0);
 + gpio_direction_output(GPIO_HUB_NRESET, 0);
 + gpio_set_value(GPIO_HUB_NRESET, 0);
 + gpio_set_value(GPIO_HUB_NRESET, 1);
 +
 + usb_ehci_init(ehci_pdata);
 +
 + /* enable power to hub */
 + gpio_set_value(GPIO_HUB_POWER, 1);
 + return;
 +
 +error2:
 + gpio_free(GPIO_HUB_POWER);
 +error1:
 + pr_err(Unable to initialize EHCI power/reset\n);
 + return;
 +
 +}
 +
  static void __init omap4_panda_init(void)
  {
   omap4_panda_i2c_init();
 @@ -287,6 +340,7 @@ static void __init omap4_panda_init(void)
   omap4_twl6030_hsmmc_init(mmc);
   /* OMAP4 Panda uses internal transceiver so register nop transceiver */
   usb_nop_xceiv_register();
 + omap4_ehci_init();
   /* FIXME: allow multi-omap to boot until musb is updated for omap4 */
   if (!cpu_is_omap44xx())
   usb_musb_init(musb_board_data);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] omap4: pandaboard: Adding card detect support for MMC1

* David Anders x0132...@ti.com [101006 14:06]:
 Adding card detect callback function and card detect configuration
 function for MMC1 Controller.

This one would be best merged into this patch from Kishore:

https://patchwork.kernel.org/patch/189952/

Kishore, care to update your patch with this one and then send
the updated version to Samuel? I think there may have been some
other pending comments too.

The other three look OK to me to queue.

Regards,

Tony

 
 Signed-off-by: David Anders x0132...@ti.com
 Signed-off-by: Anand Gadiyar gadi...@ti.com
 ---
 
 patch depends on https://patchwork.kernel.org/patch/189952/
 
  arch/arm/mach-omap2/board-omap4panda.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index 697c0bd..94e819c 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -77,9 +77,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
 *dev)
   struct omap_mmc_platform_data *pdata = dev-platform_data;
  
   /* Setting MMC1 Card detect Irq */
 - if (pdev-id == 0)
 + if (pdev-id == 0) {
 + ret = twl6030_mmc_card_detect_config();
 + if (ret)
 + pr_err(Failed configuring MMC1 card detect\n);
   pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
   MMCDETECT_INTR_OFFSET;
 + pdata-slots[0].card_detect = twl6030_mmc_card_detect;
 + }
   return ret;
  }
  
 -- 
 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
--
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/4] omap4: pandaboard: machine cleanups

David Anders x0132...@ti.com writes:

 PandaBoard machine file related cleanups.

 David Anders (4):
   omap4: pandaboard: remove unused hsmmc definition
   omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
   omap4: pandaboard: Adding card detect support for MMC1
   omap4: pandaboard: enable the ehci port on pandaboard

Hi David,

Thanks for updating.

Note that the LAKML mailing-list address has changed.  Correct address
is

   linux-arm-ker...@lists.infradead.org

Please fixup patch 4 to apply against current l-o master, and drop patch
3 for now so that Kishore can fold it into his, then re-post including
LAKML.

FWIW, I tested patches 1, 2 and 4 (after manual fixup) on my es2.0 panda
and MMC is working, so feel free to add 

Tested-by: Kevin Hilman khil...@deeprootsystems.com

to patches 1, 2 and 4.  At least MMC boot will work, and we'll have to
wait for Kishore to get the card detect merged.

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

Re: [PATCH] ARM: Check for is_smp for tlb_ops and cache_ops boardcast

2010-10-06 Thread Russell King - ARM Linux

On Wed, Oct 06, 2010 at 07:44:14AM -0700, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [101005 15:24]:
  On Tue, Oct 05, 2010 at 03:19:52PM -0700, Tony Lindgren wrote:
   * Tony Lindgren t...@atomide.com [100907 20:04]:
This should not be needed when running on UP systems.

Additionally we will also get an undefined instruction on ARM cores
without the extended CPUID registers with CONFIG_SMP_ON_UP.

Also, we can now remove the is_smp() test from mmu.c.
   
   Just FYI, I've updated this one more time with to use cpus_empty
   instead of !smp_on_up() here as well.
  
  What's the rationale?
 
 With CPU hotplug if the other SMP cores are unplugged for PM or
 other reasons, no need to do the broadcast.

Yes, but why this expensive test when the smp_on_up() is much cheaper?

smp_call_function_many() already takes care of the no other CPUs
case, which is used by on_each_cpu_mask() and on_each_cpu(), which
means these functions won't broadcast the operations to other CPUs
when they're offline.

In any case, if you think that we broadcast every operation to all
CPUs, you're mistaken - TLB and cache ops are broadcast to only
those CPUs which the thread is running on, or in the case of non-MM
specific, to all online CPUs.

So the only thing we have to worry about is is there an ID register
available which is covered by the is_smp() test.  Checking the CPU
mask is far more expensive and imho ends up needlessly adding to the
complexity.
--
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: Check for is_smp for tlb_ops and cache_ops boardcast

* Russell King - ARM Linux li...@arm.linux.org.uk [101006 15:25]:
 On Wed, Oct 06, 2010 at 07:44:14AM -0700, Tony Lindgren wrote:
  * Russell King - ARM Linux li...@arm.linux.org.uk [101005 15:24]:
   On Tue, Oct 05, 2010 at 03:19:52PM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [100907 20:04]:
 This should not be needed when running on UP systems.
 
 Additionally we will also get an undefined instruction on ARM cores
 without the extended CPUID registers with CONFIG_SMP_ON_UP.
 
 Also, we can now remove the is_smp() test from mmu.c.

Just FYI, I've updated this one more time with to use cpus_empty
instead of !smp_on_up() here as well.
   
   What's the rationale?
  
  With CPU hotplug if the other SMP cores are unplugged for PM or
  other reasons, no need to do the broadcast.
 
 Yes, but why this expensive test when the smp_on_up() is much cheaper?
 
 smp_call_function_many() already takes care of the no other CPUs
 case, which is used by on_each_cpu_mask() and on_each_cpu(), which
 means these functions won't broadcast the operations to other CPUs
 when they're offline.
 
 In any case, if you think that we broadcast every operation to all
 CPUs, you're mistaken - TLB and cache ops are broadcast to only
 those CPUs which the thread is running on, or in the case of non-MM
 specific, to all online CPUs.

OK thanks, that's what I was missing.
 
 So the only thing we have to worry about is is there an ID register
 available which is covered by the is_smp() test.  Checking the CPU
 mask is far more expensive and imho ends up needlessly adding to the
 complexity.

OK. In that case, the patch to use is the previous one:

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6429/1

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

g_ether broken on musb

2010-10-06 Thread Grazvydas Ignotas

Hi,

pulled today's linux-next and g_ether is acting strange on my pandora board:
# ping pnd
PING pnd (10.0.1.2) 56(84) bytes of data.
64 bytes from pnd (10.0.1.2): icmp_seq=2 ttl=64 time=2018 ms
64 bytes from pnd (10.0.1.2): icmp_seq=1 ttl=64 time=5036 ms
64 bytes from pnd (10.0.1.2): icmp_seq=8 ttl=64 time=1019 ms
64 bytes from pnd (10.0.1.2): icmp_seq=6 ttl=64 time=4030 ms
64 bytes from pnd (10.0.1.2): icmp_seq=10 ttl=64 time=4025 ms
64 bytes from pnd (10.0.1.2): icmp_seq=16 ttl=64 time=18.2 ms
64 bytes from pnd (10.0.1.2): icmp_seq=15 ttl=64 time=2019 ms
64 bytes from pnd (10.0.1.2): icmp_seq=14 ttl=64 time=4022 ms

Looks like the transfers get mixed somehow? Curiously after replugging
the cable several times it starts working properly, however the
problem comes back reliably after each reboot.
--
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] PM: add synchronous runtime interface for interrupt handlers

Alan Stern st...@rowland.harvard.edu writes:

On Wed, 6 Oct 2010, Kevin Hilman wrote:

I think I can live with the above restrictions (the _irq methods failing
unless they can immediately run.) For the rare corner cases I've
currently run into, this will work fine as they happen because of a
wakeup IRQ, where we know the device is RPM_SUSPENDED.

Then what will the driver do if it gets a wakeup IRQ but it can't
resume the device because some other thread is in the middle of a
suspend or resume?

In those cases, I guess it will have to return IRQ_NONE, and print some
sort of error.

Without handling the IRQ? I guess if the transient state (SUSPENDING
or RESUMING) ends quickly enough then the kernel won't permanently
disable the IRQ line (although getting hundreds of repeated error
messages in the system log might prove daunting). Would you want to
rely on that?

Probably not, I think the delayed approach is better.

Alternatively, it could fall back to the high-latency
case of masking the IRQ and doing an asynchronous call then call the ISR
in the runtime_resume callback.

Yes, this probably would be acceptable since it wouldn't happen very
often. Still, having two different pathways (one of which is very low
probability) usually isn't a good idea.

For the corner cases that I've run into, other transitions will not be
in progress because system has just woken up (so no threads are in the
middle of suspends or resumes) and the IRQ fires as soon as pm_idle
enables interrupts, and before there's a chance to schedule anything
else.

Ah, but once you integrate the runtime PM framework into your driver,
you run the risk of resumes occurring for reasons that aren't under
your control. For example, the user can force a runtime-suspended
device to resume by writing on to the device's power/control sysfs
attribute. What would happen if a wakeup IRQ arrived just as the
resume was starting?

I guess the mask-IRQ, pm_runtime_get(), return approach would work
here too. But I agree with you about the drivers having to handle both
of these cases is not the greatest.

(Actually, this particular failure mode shouldn't concern you very much
since it applies only to SMP systems. But it's important to think of
the future -- I can imagine SMP OMAPs coming out before too long.)

It already concerns me since I'm working on SMP OMAPs too. The OMAP4 is
a dual ARM Cortex A9[1].

On the whole, I don't see any striking reason for the PM core not to
busy-wait during a concurrent state change. Refusing to wake up a
suspended parent ... okay, maybe that's a little more defensible.
Especially since in many or most cases the parent (if there is one)
will probably be runtime-PM-disabled anyway.

Not sure I follow where you're going with this last paragraph. Of
course, calls from ISR context cannot busy wait.

Kevin

[1]
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12842contentId=53247
--
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: Fix HWCAP_TLS flag for ARM11MPCore/Cortex-A9

Commit 14eff1812679c76564b775aa95cdd378965f6cfb added proper
detection for ARM11MPCore/Cortex-A9 instead of detecting them
as ARMv7. However, it was missing the HWCAP_TLS flags.

HWCAP_TLS is needed if support for earlier ARMv6 is compiled
into the same kernel. Without HWCAP_TLS flags the userspace
won't work unless nosmp is specified:

Kernel panic - not syncing: Attempted to kill init!
CPU0: stopping
c005d5e4] (unwind_backtrace+0x0/0xec) from [c004c2f8] (do_IPI+0xfc/0x184)
c004c2f8] (do_IPI+0xfc/0x184) from [c03f25bc] (__irq_svc+0x9c/0x160)
Exception stack(0xc0565f80 to 0xc0565fc8)
5f80: 0001 c05772a0  3a61 c0564000 c05cf500 c003603c c0578600
5fa0: 80033ef0 410fc091 001f   c0565fc8 c00b91f8 c0057cb4
5fc0: 2013 
[c03f25bc] (__irq_svc+0x9c/0x160) from [c0057cb4] (default_idle+0x30/0x38)
[c0057cb4] (default_idle+0x30/0x38) from [c005829c] (cpu_idle+0x9c/0xf8)
[c005829c] (cpu_idle+0x9c/0xf8) from [c0008d48] (start_kernel+0x2a4/0x300)
[c0008d48] (start_kernel+0x2a4/0x300) from [80008084] (0x80008084)

Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index df422fe..8370960 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -372,7 +372,7 @@ __v7_ca9mp_proc_info:
b   __v7_ca9mp_setup
.long   cpu_arch_name
.long   cpu_elf_name
-   .long   HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP
+   .long   
HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_TLS
.long   cpu_v7_name
.long   v7_processor_functions
.long   v7wbi_tlb_fns
--
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: NOTE: hwmod changes merged to linux-omap master for testing