Re: [PATCH 1/2] omap4: 4430sdp: drop ehci support

2011-02-16 Thread Felipe Balbi
On Wed, Feb 16, 2011 at 04:47:19PM +0530, Anand Gadiyar wrote:
> Most revisions of the OMAP4 Blaze/SDP platform do not have
> the EHCI signals routed by default. The pads are routed
> for the alternate HSI functionality instead, and explicit
> board modifications are needed to route the signals to
> the USB PHY on the board.
> 
> Also, turning on the PHY connected to the EHCI port causes
> a board reboot during bootup due to an unintended short
> on the rails - this affects many initial revisions of the
> board, and needs a minor board mod to fix (or as a
> workaround, one should not attempt to power on the
> USB PHY).
> 
> Given that these boards need explicit board mods to even
> get EHCI working (separate from the accidental short above),
> we should not attempt to enable EHCI by default.
> 
> So drop the EHCI support from the board files for the
> Blaze/SDP platforms.
> 
> Signed-off-by: Anand Gadiyar 
> Cc: Keshava Munegowda 
> Cc: Tony Lindgren 

applied, thanks.

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


Re: [PATCH 1/2] omap4: 4430sdp: drop ehci support

2011-02-16 Thread Felipe Balbi
On Wed, Feb 16, 2011 at 05:42:10PM -0800, Tony Lindgren wrote:
> * Felipe Balbi  [110216 03:25]:
> > On Wed, Feb 16, 2011 at 04:47:19PM +0530, Anand Gadiyar wrote:
> > > Most revisions of the OMAP4 Blaze/SDP platform do not have
> > > the EHCI signals routed by default. The pads are routed
> > > for the alternate HSI functionality instead, and explicit
> > > board modifications are needed to route the signals to
> > > the USB PHY on the board.
> > > 
> > > Also, turning on the PHY connected to the EHCI port causes
> > > a board reboot during bootup due to an unintended short
> > > on the rails - this affects many initial revisions of the
> > > board, and needs a minor board mod to fix (or as a
> > > workaround, one should not attempt to power on the
> > > USB PHY).
> > > 
> > > Given that these boards need explicit board mods to even
> > > get EHCI working (separate from the accidental short above),
> > > we should not attempt to enable EHCI by default.
> > > 
> > > So drop the EHCI support from the board files for the
> > > Blaze/SDP platforms.
> > > 
> > > Signed-off-by: Anand Gadiyar 
> > > Cc: Keshava Munegowda 
> > > Cc: Tony Lindgren 
> > 
> > Tony, if you want to queue this one directly, here's my:
> > 
> > Acked-by: Felipe Balbi 
> > 
> > if you wish, I can send you a pull request as well. I already have
> > another patch for you anyway.
> 
> OK if you have more I'd rather pull.

ok. Taken.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe 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: [3/4] OMAP: DSS2: Adding macro for DISPC_DIVISOR register

2011-02-16 Thread Raghuveer Murthy

On Wednesday 16 February 2011 09:13 PM, Valkeinen, Tomi wrote:

On Thu, 2011-02-03 at 14:09 +, Raghuveer Murthy wrote:

Added macro for DISPC_DIVISOR. This is different from DISPC_DIVISOR1 and
DISPC_DIVISOR2. OMAP4 supports all the above 3 registers.

DISPC_DIVISOR1 and DISPC_DIVISOR2 registers are accessed through
DISPC_DIVISORo(ch) macro

Signed-off-by: Raghuveer Murthy

---
drivers/video/omap2/dss/dispc.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e52a413..6225d12 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -132,6 +132,17 @@ struct dispc_reg { u16 idx; };

  #define DISPC_VID_PRELOAD(n)  DISPC_REG(0x230 + (n)*0x04)

+/*
+ * The OMAP4 DISPC_DIVISOR1 is backward compatible to OMAP3xxx DISPC_DIVISOR.
+ * However DISPC_DIVISOR is also provided in OMAP4, to control DISPC_CORE_CLK.
+ * This allows DISPC_CORE_CLK to be independent of logical clock dividers (lcd)
+ * of LCD1 (primary) and LCD2 (secondary) displays.
+ *
+ * To derive pixel clocks for Primary and Secondary LCD channels, configure the
+ * lcd and pcd in DISPC_DIVISOR1 and DISPC_DIVISOR2 respectively, using the
+ * DISPC_DIVISORo(ch).
+ */
+#define DISPC_DIVISOR  DISPC_REG(0x0804)

  #define DISPC_IRQ_MASK_ERROR(DISPC_IRQ_GFX_FIFO_UNDERFLOW | \
 DISPC_IRQ_OCP_ERR | \


See my comment about comments in previous mail.

I think you should merge this and the next patch. There's not much point
in adding a single line define, which is not used (yet).

How about the debug output from debug/omapdss/clk file? Does it print
sensible things on OMAP4 after these patches?


Will verify this.


  Tomi




Acknowledge the comments for patch 2/4 and 3/4. Will merge them and post 
a new series.


Regards,
Raghuveer
--
To unsubscribe from this list: send the line "unsubscribe 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/6 v8] OMAP4430: hwmod data: Adding USBOTG

2011-02-16 Thread Hema HK
OMAP4 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.

Signed-off-by: Cousson, Benoit 
Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   93 +
 1 file changed, 93 insertions(+)

Index: linux-2.6/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ linux-2.6/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -55,6 +55,7 @@ static struct omap_hwmod omap44xx_l4_per
 static struct omap_hwmod omap44xx_l4_wkup_hwmod;
 static struct omap_hwmod omap44xx_mpu_hwmod;
 static struct omap_hwmod omap44xx_mpu_private_hwmod;
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
 
 /*
  * Interconnects omap_hwmod structures
@@ -286,12 +287,21 @@ static struct omap_hwmod_ocp_if omap44xx
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* usb_otg_hs -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = {
+   .master = &omap44xx_usb_otg_hs_hwmod,
+   .slave  = &omap44xx_l3_main_2_hwmod,
+   .clk= "l3_div_ck",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_2 slave ports */
 static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
&omap44xx_dma_system__l3_main_2,
&omap44xx_iva__l3_main_2,
&omap44xx_l3_main_1__l3_main_2,
&omap44xx_l4_cfg__l3_main_2,
+   &omap44xx_usb_otg_hs__l3_main_2,
 };
 
 static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
@@ -2001,6 +2011,87 @@ static struct omap_hwmod omap44xx_wd_tim
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+/*
+ * 'usb_otg_hs' class
+ * high-speed on-the-go universal serial bus (usb_otg_hs) controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
+   .rev_offs   = 0x0400,
+   .sysc_offs  = 0x0404,
+   .syss_offs  = 0x0408,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+ SYSC_HAS_ENAWAKEUP | 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 omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = {
+   .name = "usb_otg_hs",
+   .sysc = &omap44xx_usb_otg_hs_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = {
+   { .name = "mc", .irq = 92 + OMAP44XX_IRQ_GIC_START },
+   { .name = "dma", .irq = 93 + OMAP44XX_IRQ_GIC_START },
+};
+
+/* usb_otg_hs master ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = {
+   &omap44xx_usb_otg_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
+   {
+   .pa_start   = OMAP44XX_HSUSB_OTG_BASE,
+   .pa_end = OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_cfg -> usb_otg_hs */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = {
+   .master = &omap44xx_l4_cfg_hwmod,
+   .slave  = &omap44xx_usb_otg_hs_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap44xx_usb_otg_hs_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_usb_otg_hs_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* usb_otg_hs slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = {
+   &omap44xx_l4_cfg__usb_otg_hs,
+};
+
+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
+   { .role = "xclk", .clk = "otg_60m_gfclk_ck" },
+};
+
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
+   .name   = "usb_otg_hs",
+   .class  = &omap44xx_usb_otg_hs_hwmod_class,
+   .mpu_irqs   = omap44xx_usb_otg_hs_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_usb_otg_hs_irqs),
+   .main_clk   = "usb_otg_hs_ick",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
+   },
+   },
+   .opt_clks   = usb_otg_hs_opt_clks,
+   .opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks),
+   .slaves = omap44xx_usb_otg_hs_slaves,
+   .slaves_cnt  

[PATCH 6/6 v8] usb: musb: Using runtime pm APIs for musb.

2011-02-16 Thread Hema HK
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings.

Enable clock, configure no-idle/standby when active and configure force 
idle/standby
and disable clock when idled. This is taken care by the runtime framework when
driver calls the pm_runtime_get_sync and pm_runtime_put_sync APIs.
Need to configure MUSB into force standby and force idle mode when usb not used

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---
 drivers/usb/musb/musb_core.h |2 -
 drivers/usb/musb/omap2430.c  |   80 +++
 2 files changed, 23 insertions(+), 59 deletions(-)

Index: linux-2.6/drivers/usb/musb/musb_core.h
===
--- linux-2.6.orig/drivers/usb/musb/musb_core.h
+++ linux-2.6/drivers/usb/musb/musb_core.h
@@ -360,7 +360,7 @@ struct musb_context_registers {
 
 #if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
 defined(CONFIG_ARCH_OMAP4)
-   u32 otg_sysconfig, otg_forcestandby;
+   u32 otg_forcestandby;
 #endif
u8 power;
u16 intrtxe, intrrxe;
Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "musb_core.h"
 #include "omap2430.h"
@@ -40,7 +42,6 @@
 struct omap2430_glue {
struct device   *dev;
struct platform_device  *musb;
-   struct clk  *clk;
 };
 #define glue_to_musb(g)platform_get_drvdata(g->musb)
 
@@ -216,20 +217,12 @@ static inline void omap2430_low_level_ex
l = musb_readl(musb->mregs, OTG_FORCESTDBY);
l |= ENABLEFORCE;   /* enable MSTANDBY */
musb_writel(musb->mregs, OTG_FORCESTDBY, l);
-
-   l = musb_readl(musb->mregs, OTG_SYSCONFIG);
-   l |= ENABLEWAKEUP;  /* enable wakeup */
-   musb_writel(musb->mregs, OTG_SYSCONFIG, l);
 }
 
 static inline void omap2430_low_level_init(struct musb *musb)
 {
u32 l;
 
-   l = musb_readl(musb->mregs, OTG_SYSCONFIG);
-   l &= ~ENABLEWAKEUP; /* disable wakeup */
-   musb_writel(musb->mregs, OTG_SYSCONFIG, l);
-
l = musb_readl(musb->mregs, OTG_FORCESTDBY);
l &= ~ENABLEFORCE;  /* disable MSTANDBY */
musb_writel(musb->mregs, OTG_FORCESTDBY, l);
@@ -309,21 +302,6 @@ static int omap2430_musb_init(struct mus
 
omap2430_low_level_init(musb);
 
-   l = musb_readl(musb->mregs, OTG_SYSCONFIG);
-   l &= ~ENABLEWAKEUP; /* disable wakeup */
-   l &= ~NOSTDBY;  /* remove possible nostdby */
-   l |= SMARTSTDBY;/* enable smart standby */
-   l &= ~AUTOIDLE; /* disable auto idle */
-   l &= ~NOIDLE;   /* remove possible noidle */
-   l |= SMARTIDLE; /* enable smart idle */
-   /*
-* MUSB AUTOIDLE don't work in 3430.
-* Workaround by Richard Woodruff/TI
-*/
-   if (!cpu_is_omap3430())
-   l |= AUTOIDLE;  /* enable auto idle */
-   musb_writel(musb->mregs, OTG_SYSCONFIG, l);
-
l = musb_readl(musb->mregs, OTG_INTERFSEL);
 
if (data->interface_type == MUSB_INTERFACE_UTMI) {
@@ -386,7 +364,7 @@ static int __init omap2430_probe(struct 
struct musb_hdrc_platform_data  *pdata = pdev->dev.platform_data;
struct platform_device  *musb;
struct omap2430_glue*glue;
-   struct clk  *clk;
+   int status = 0;
 
int ret = -ENOMEM;
 
@@ -402,26 +380,12 @@ static int __init omap2430_probe(struct 
goto err1;
}
 
-   clk = clk_get(&pdev->dev, "ick");
-   if (IS_ERR(clk)) {
-   dev_err(&pdev->dev, "failed to get clock\n");
-   ret = PTR_ERR(clk);
-   goto err2;
-   }
-
-   ret = clk_enable(clk);
-   if (ret) {
-   dev_err(&pdev->dev, "failed to enable clock\n");
-   goto err3;
-   }
-
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask  = &omap2430_dmamask;
musb->dev.coherent_dma_mask = omap2430_dmamask;
 
glue->dev   = &pdev->dev;
glue->musb  = musb;
-   glue->clk   = clk;
 
pdata->platform_ops = &omap2430_ops;
 
@@ -431,29 +395,32 @@ static int __init omap2430_probe(struct 
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
-   goto err4;
+   goto err2;
}
 
ret = platform_device_add_data(musb, pdata

[PATCH 5/6 v8] OMAP2+: musb: hwmod adaptation for musb registration

2011-02-16 Thread Hema HK
Using omap_device_build API instead of platform_device_register for
OMAP2430,OMAP3xxx, OMAP4430 and AM35x musb device registration.
The device specific resources defined in centralized
database will be used.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---
 arch/arm/mach-omap2/usb-musb.c |   82 -
 1 file changed, 40 insertions(+), 42 deletions(-)

Index: linux-2.6/arch/arm/mach-omap2/usb-musb.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-2.6/arch/arm/mach-omap2/usb-musb.c
@@ -30,25 +30,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
 
-static struct resource musb_resources[] = {
-   [0] = { /* start and end set dynamically */
-   .flags  = IORESOURCE_MEM,
-   },
-   [1] = { /* general IRQ */
-   .start  = INT_243X_HS_USB_MC,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "mc",
-   },
-   [2] = { /* DMA IRQ */
-   .start  = INT_243X_HS_USB_DMA,
-   .flags  = IORESOURCE_IRQ,
-   .name   = "dma",
-   },
-};
-
 static struct musb_hdrc_config musb_config = {
.multipoint = 1,
.dyn_fifo   = 1,
@@ -76,35 +61,23 @@ static struct musb_hdrc_platform_data mu
 
 static u64 musb_dmamask = DMA_BIT_MASK(32);
 
-static struct platform_device musb_device = {
-   .name   = "musb-omap2430",
-   .id = -1,
-   .dev = {
-   .dma_mask   = &musb_dmamask,
-   .coherent_dma_mask  = DMA_BIT_MASK(32),
-   .platform_data  = &musb_plat,
+static struct omap_device_pm_latency omap_musb_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
-   .num_resources  = ARRAY_SIZE(musb_resources),
-   .resource   = musb_resources,
 };
 
 void __init usb_musb_init(struct omap_musb_board_data *board_data)
 {
-   if (cpu_is_omap243x()) {
-   musb_resources[0].start = OMAP243X_HS_BASE;
-   } else if (cpu_is_omap3517() || cpu_is_omap3505()) {
-   musb_device.name = "musb-am35x";
-   musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
-   musb_resources[1].start = INT_35XX_USBOTG_IRQ;
-   } else if (cpu_is_omap34xx()) {
-   musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
-   } else if (cpu_is_omap44xx()) {
-   musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
-   musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
-   musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
-   }
-   musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
-
+   struct omap_hwmod *oh;
+   struct omap_device *od;
+   struct platform_device *pdev;
+   struct device   *dev;
+   int bus_id = -1;
+   const char *oh_name, *name;
+   struct musb_hdrc_platform_data *pdata;
/*
 * REVISIT: This line can be removed once all the platforms using
 * musb_core.c have been converted to use use clkdev.
@@ -115,8 +88,33 @@ void __init usb_musb_init(struct omap_mu
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
 
-   if (platform_device_register(&musb_device) < 0)
-   printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n");
+   if (cpu_is_omap3517() || cpu_is_omap3505()) {
+   oh_name = "am35x_otg_hs";
+   name = "musb-am35x";
+   } else {
+   oh_name = "usb_otg_hs";
+   name = "musb-omap2430";
+   }
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh) {
+   pr_err("Could not look up %s\n", oh_name);
+   return;
+   }
+
+   od = omap_device_build(name, bus_id, oh, &musb_plat,
+  sizeof(*pdata), omap_musb_latency,
+  ARRAY_SIZE(omap_musb_latency), false);
+   if (IS_ERR(od)) {
+   pr_err("Could not build omap_device for %s %s\n",
+   name, oh_name);
+   return;
+   }
+   pdev = &od->pdev;
+   dev = &pdev->dev;
+   get_device(dev);
+   dev->dma_mask = &musb_dmamask;
+   dev->coherent_dma_mask = musb_dmamask;
+   put_device(dev);
 }
 
 #else
--
To unsubscribe from this list: send the line "unsubscribe 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/6 v8] OMAP3xxx: hwmod data: Add USBOTG

2011-02-16 Thread Hema HK
OMAP3 hwmod data structures are populated for USBOTG with base address,
L3 and L4 interface clocks, IRQs and sysconfig register details.
This is applicable for OMAP3430 amd OMAP3630.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  101 +
 1 file changed, 101 insertions(+)

Index: linux-2.6/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ linux-2.6/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -107,6 +107,15 @@ static struct omap_hwmod omap3xxx_uart1_
 static struct omap_hwmod omap3xxx_uart2_hwmod;
 static struct omap_hwmod omap3xxx_uart3_hwmod;
 static struct omap_hwmod omap3xxx_uart4_hwmod;
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod;
+
+/* l3_core -> usbhsotg interface */
+static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = {
+   .master = &omap3xxx_usbhsotg_hwmod,
+   .slave  = &omap3xxx_l3_main_hwmod,
+   .clk= "core_l3_ick",
+   .user   = OCP_USER_MPU,
+};
 
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
@@ -301,6 +310,36 @@ static struct omap_hwmod_ocp_if omap3_l4
.user   = OCP_USER_MPU,
 };
 
+/*
+* usbhsotg interface data
+*/
+
+static struct omap_hwmod_addr_space omap3xxx_usbhsotg_addrs[] = {
+   {
+   .pa_start   = OMAP34XX_HSUSB_OTG_BASE,
+   .pa_end = OMAP34XX_HSUSB_OTG_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -> usbhsotg  */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__usbhsotg = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &omap3xxx_usbhsotg_hwmod,
+   .clk= "l4_ick",
+   .addr   = omap3xxx_usbhsotg_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_usbhsotg_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_masters[] = {
+   &omap3xxx_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = {
+   &omap3xxx_l4_core__usbhsotg,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
&omap3xxx_l3_main__l4_core,
@@ -1356,6 +1395,64 @@ static struct omap_hwmod omap36xx_sr2_hw
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
 };
 
+/*
+ * usbhsotg
+ */
+static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = {
+   .rev_offs   = 0x0400,
+   .sysc_offs  = 0x0404,
+   .syss_offs  = 0x0408,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+ SYSC_HAS_ENAWAKEUP | 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 omap_hwmod_class usbotg_class = {
+   .name = "usbotg",
+   .sysc = &omap3xxx_usbhsotg_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap3xxx_usbhsotg_mpu_irqs[] = {
+
+   { .name = "mc", .irq = 92 },
+   { .name = "dma", .irq = 93 },
+};
+
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
+   .name   = "usb_otg_hs",
+   .mpu_irqs   = omap3xxx_usbhsotg_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_usbhsotg_mpu_irqs),
+   .main_clk   = "hsotgusb_ick",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP3430_EN_HSOTGUSB_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT,
+   .idlest_stdby_bit = OMAP3430ES2_ST_HSOTGUSB_STDBY_SHIFT
+   },
+   },
+   .masters= omap3xxx_usbhsotg_masters,
+   .masters_cnt= ARRAY_SIZE(omap3xxx_usbhsotg_masters),
+   .slaves = omap3xxx_usbhsotg_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_usbhsotg_slaves),
+   .class  = &usbotg_class,
+
+   /*
+* Erratum ID: i479  idle_req / idle_ack mechanism potentially
+* broken when autoidle is enabled
+* workaround is to disable th

[PATCH 3/6 v8] AM35xx: hwmod data: Add USBOTG

2011-02-16 Thread Hema HK
AM35xx hwmod data structures are populated for USBOTG with base address,
L3 and L4 interface clocks and IRQ.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---

Index: linux-2.6/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ linux-2.6/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -28,6 +28,7 @@
 #include "prm-regbits-34xx.h"
 #include "cm-regbits-34xx.h"
 #include "wd_timer.h"
+#include 
 
 /*
  * OMAP3xxx hardware module integration data
@@ -55,6 +56,8 @@ static struct omap_hwmod omap3xxx_gpio5_
 static struct omap_hwmod omap3xxx_gpio6_hwmod;
 static struct omap_hwmod omap34xx_sr1_hwmod;
 static struct omap_hwmod omap34xx_sr2_hwmod;
+static struct omap_hwmod am35xx_usbhsotg_hwmod;
+
 
 static struct omap_hwmod omap3xxx_dma_system_hwmod;
 
@@ -117,6 +120,13 @@ static struct omap_hwmod_ocp_if omap3xxx
.user   = OCP_USER_MPU,
 };
 
+/* l3_core -> am35xx_usbhsotg interface */
+static struct omap_hwmod_ocp_if am35xx_usbhsotg__l3 = {
+   .master = &am35xx_usbhsotg_hwmod,
+   .slave  = &omap3xxx_l3_main_hwmod,
+   .clk= "core_l3_ick",
+   .user   = OCP_USER_MPU,
+};
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
.master = &omap3xxx_l4_core_hwmod,
@@ -340,6 +350,31 @@ static struct omap_hwmod_ocp_if *omap3xx
&omap3xxx_l4_core__usbhsotg,
 };
 
+static struct omap_hwmod_addr_space am35xx_usbhsotg_addrs[] = {
+   {
+   .pa_start   = AM35XX_IPSS_USBOTGSS_BASE,
+   .pa_end = AM35XX_IPSS_USBOTGSS_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -> usbhsotg  */
+static struct omap_hwmod_ocp_if am35xx_l4_core__usbhsotg = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &am35xx_usbhsotg_hwmod,
+   .clk= "l4_ick",
+   .addr   = am35xx_usbhsotg_addrs,
+   .addr_cnt   = ARRAY_SIZE(am35xx_usbhsotg_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *am35xx_usbhsotg_masters[] = {
+   &am35xx_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *am35xx_usbhsotg_slaves[] = {
+   &am35xx_l4_core__usbhsotg,
+};
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
&omap3xxx_l3_main__l4_core,
@@ -1452,6 +1487,33 @@ static struct omap_hwmod omap3xxx_usbhso
| HWMOD_SWSUP_MSTANDBY,
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
 };
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info am35xx_usbhsotg_mpu_irqs[] = {
+
+   { .name = "mc", .irq = 71 },
+};
+
+static struct omap_hwmod_class am35xx_usbotg_class = {
+   .name = "am35xx_usbotg",
+   .sysc = NULL,
+};
+
+static struct omap_hwmod am35xx_usbhsotg_hwmod = {
+   .name   = "am35x_otg_hs",
+   .mpu_irqs   = am35xx_usbhsotg_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(am35xx_usbhsotg_mpu_irqs),
+   .main_clk   = NULL,
+   .prcm = {
+   .omap2 = {
+   },
+   },
+   .masters= am35xx_usbhsotg_masters,
+   .masters_cnt= ARRAY_SIZE(am35xx_usbhsotg_masters),
+   .slaves = am35xx_usbhsotg_slaves,
+   .slaves_cnt = ARRAY_SIZE(am35xx_usbhsotg_slaves),
+   .class  = &am35xx_usbotg_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1)
+};
 
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
@@ -1488,6 +1550,9 @@ static __initdata struct omap_hwmod *oma
/* usbotg class */
&omap3xxx_usbhsotg_hwmod,
 
+   /* usbotg for am35x */
+   &am35xx_usbhsotg_hwmod,
+
NULL,
 };
 
--
To unsubscribe from this list: send the line "unsubscribe 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/6 v8] OMAP2430: hwmod data: Add USBOTG

2011-02-16 Thread Hema HK
OMAP2430 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and off-mode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when suspended.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   98 +
 1 file changed, 98 insertions(+)

Index: linux-2.6/arch/arm/mach-omap2/omap_hwmod_2430_data.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ linux-2.6/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -89,6 +89,16 @@ static struct omap_hwmod omap2430_uart3_
 static struct omap_hwmod omap2430_i2c1_hwmod;
 static struct omap_hwmod omap2430_i2c2_hwmod;
 
+static struct omap_hwmod omap2430_usbhsotg_hwmod;
+
+/* l3_core -> usbhsotg  interface */
+static struct omap_hwmod_ocp_if omap2430_usbhsotg__l3 = {
+   .master = &omap2430_usbhsotg_hwmod,
+   .slave  = &omap2430_l3_main_hwmod,
+   .clk= "core_l3_ck",
+   .user   = OCP_USER_MPU,
+};
+
 /* I2C IP block address space length (in bytes) */
 #define OMAP2_I2C_AS_LEN   128
 
@@ -189,6 +199,35 @@ static struct omap_hwmod_ocp_if omap2_l4
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/*
+* usbhsotg interface data
+*/
+static struct omap_hwmod_addr_space omap2430_usbhsotg_addrs[] = {
+   {
+   .pa_start   = OMAP243X_HS_BASE,
+   .pa_end = OMAP243X_HS_BASE + SZ_4K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/*  l4_core ->usbhsotg  interface */
+static struct omap_hwmod_ocp_if omap2430_l4_core__usbhsotg = {
+   .master = &omap2430_l4_core_hwmod,
+   .slave  = &omap2430_usbhsotg_hwmod,
+   .clk= "usb_l4_ick",
+   .addr   = omap2430_usbhsotg_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_usbhsotg_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *omap2430_usbhsotg_masters[] = {
+   &omap2430_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *omap2430_usbhsotg_slaves[] = {
+   &omap2430_l4_core__usbhsotg,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = {
&omap2430_l3_main__l4_core,
@@ -919,6 +958,62 @@ static struct omap_hwmod omap2430_dma_sy
.flags  = HWMOD_NO_IDLEST,
 };
 
+/*
+ * usbhsotg
+ */
+static struct omap_hwmod_class_sysconfig omap2430_usbhsotg_sysc = {
+   .rev_offs   = 0x0400,
+   .sysc_offs  = 0x0404,
+   .syss_offs  = 0x0408,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+ SYSC_HAS_ENAWAKEUP | 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 omap_hwmod_class usbotg_class = {
+   .name = "usbotg",
+   .sysc = &omap2430_usbhsotg_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap2430_usbhsotg_mpu_irqs[] = {
+
+   { .name = "mc", .irq = 92 },
+   { .name = "dma", .irq = 93 },
+};
+
+static struct omap_hwmod omap2430_usbhsotg_hwmod = {
+   .name   = "usb_otg_hs",
+   .mpu_irqs   = omap2430_usbhsotg_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_usbhsotg_mpu_irqs),
+   .main_clk   = "usbhs_ick",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP2430_EN_USBHS_MASK,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP2430_ST_USBHS_SHIFT,
+   },
+   },
+   .masters= omap2430_usbhsotg_masters,
+   .masters_cnt= ARRAY_SIZE(omap2430_usbhsotg_masters),
+   .slaves = omap2430_usbhsotg_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_usbhsotg_slaves),
+   .class  = &usbotg_class,
+   /*
+* Erratum ID: i479  idle_req / idle_ack mechanism potentially
+* broken when autoidle is enabled
+* workaround is to disable the autoidle bit at module level.
+*/
+   .flags  = HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
+   | HWMOD_SWSUP_MSTANDBY,
+   .omap_chip  = OMAP_CHIP_INIT(

[PATCH 0/6 v8]usb: musb: hwmod and runtime pm support for musb

2011-02-16 Thread Hema HK
This patch series makes OMAP2PLUS and AM35x musb module implemented
in HWMOD FW way. It also implements musb driver to
use the runtime pm apis for OMAP2PLUS.

As per the OMAP usbotg specification[1] musb sysconfig register
has to be set to force idle and force standby when not used
and set smart idle/standby or no idle/standby during operation.
otherwise core-off will be prevented by musb.

[1]: http://focus.ti.com/pdfs/wtbu/SWPU223D_Final_EPDF_06_07_2010.pdf

This patch series is based on V2.6.38-rc4 + [1] +[2] + [3]

[1] https://patchwork.kernel.org/patch/513461
[2] http://www.spinics.net/lists/linux-usb/msg40575.html
[3] https://patchwork.kernel.org/patch/566751/

With this patch series tested musb functionality like testusb, masstorage
OMAP4430SDP, OMAP3430SDP, and OMAP3630 zoom3.Boot and basic usb tested on AM35x.

Tested global suspend resume for offmode and retention on OMAP3630Zoom3.
Idle path retention and offmode validation is not done with these patch series.


Version History:
---

Version V8

Fixed minor comments from Sergei Shtylyov.

Version V7

Added the hwmod for AM35x.
Fixed the comments from Felipe and Kevin.

Version V6

Calling runtime_pm_suspend in the pm_ops function was not effective.
So using the bus runtime methods directly in the pm_ops suspend/resume
functions.

Version V5:

Fixed review comments from Felipe.


Version V4:

Rebased the changes based on the re-orgnized patches submitted by Felipe.
Fixed review comments received for V3.
Dropped the idlepath  power management patch with this series.

Some of the links for V3 review comments:

https://patchwork.kernel.org/patch/199482/
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35488.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33201.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35387.html

Version V3

Added the patch for adding the hwmod database for OMAP2430.
Re-arranged the patches in such a way that first migrate the musb driver
to use the runtime PM apis and then added a patch to support offmode in idle 
path.
Calling the runtime PM apis before disbaling the interupts in the idle path.
Added the #ifdef CONFIG_PM_RUNTIME  check in the musb core driver for calling 
the runtime PM APIs as non-omap platforms may not have the runtime pm enabled
and clk_enable/disable should be called for them.

Optimized the context save restore of musb registers only if the next state is
going to offmode and previous state was offmode.

Some of the links for V2 review comments

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34068.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32024.html
http://www.spinics.net/lists/linux-usb/msg35562.html
http://www.spinics.net/lists/linux-usb/msg35720.html

Vesrion v2:

Fixed review comments.
Removed the omap_hwmod.h inclusion from musb.h file which was 
breaking the non-omap platform build.
Using the runtime pm apis in the idle path(interrupts disabled).
Added the omap4 hwmod data base.

Version v1:
initial version of the patch series.

Some of the links for v1


http://www.spinics.net/lists/linux-usb/msg34570.html
http://www.spinics.net/lists/linux-omap/msg34568.html
http://www.spinics.net/lists/linux-usb/msg34544.html
http://www.spinics.net/lists/linux-usb/msg34540.html
http://www.spinics.net/lists/linux-usb/msg34589.html
http://www.spinics.net/lists/linux-usb/msg34554.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32973.html

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 
---

Cousson, Benoit (1):
   OMAP4430: hwmod data: Adding USBOTG

Hema HK (5):
  OMAP2430: hwmod data: Add USBOTG
  OMAP3xxx: hwmod data: Add USBOTG
  AM35xx: hwmod data: Add USBOTG
  OMAP2+: musb: hwmod adaptation for musb.
  usb: musb: Using runtime pm APIs for musb.
  

 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   98 +++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  101 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   93 +
 arch/arm/mach-omap2/usb-musb.c |   76 +++--
 drivers/usb/musb/musb_core.h   |2 +-
 drivers/usb/musb/omap2430.c|   79 ++
 6 files changed, 369 insertions(+), 80 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


[6/7 v4] usb: otg: TWL6030 Save the last event in otg_transceiver

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

Save the last event in the otg_transceiver so that it can used in the
musb driver and gadget driver to configure the musb and enable the 
vbus for host mode and OTG mode, if the device is connected during boot.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
[Reusing some part of the patch[1] posted by Arnaud Mandy]
[1] http://permalink.gmane.org/gmane.linux.usb.general/37123
---
 drivers/usb/otg/twl6030-usb.c |3 +++
 include/linux/usb/otg.h   |1 +
 2 files changed, 4 insertions(+)

Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -262,11 +262,13 @@ static irqreturn_t twl6030_usb_irq(int i
twl->otg.default_a = false;
twl->otg.state = OTG_STATE_B_IDLE;
twl->linkstat = status;
+   twl->otg.last_event = status;
blocking_notifier_call_chain(&twl->otg.notifier,
status, twl->otg.gadget);
} else {
status = USB_EVENT_NONE;
twl->linkstat = status;
+   twl->otg.last_event = status;
blocking_notifier_call_chain(&twl->otg.notifier,
status, twl->otg.gadget);
if (twl->asleep) {
@@ -299,6 +301,7 @@ static irqreturn_t twl6030_usbotg_irq(in
twl->otg.default_a = true;
twl->otg.state = OTG_STATE_A_IDLE;
twl->linkstat = status;
+   twl->otg.last_event = status;
blocking_notifier_call_chain(&twl->otg.notifier, status,
twl->otg.gadget);
} else  {
Index: linux-2.6/include/linux/usb/otg.h
===
--- linux-2.6.orig/include/linux/usb/otg.h
+++ linux-2.6/include/linux/usb/otg.h
@@ -66,6 +66,7 @@ struct otg_transceiver {
 
u8  default_a;
enum usb_otg_state  state;
+   enum usb_xceiv_events   last_event;
 
struct usb_bus  *host;
struct usb_gadget   *gadget;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[7/7 v4] usb: musb: OMAP4430: Fix usb device detection if connected during boot

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

OMAP4430 is embedded with UTMI PHY. This PHY does not support the
OTG features like ID pin detection and VBUS detection. This function
is exported to an external companion chip TWL6030. Software must retrieve
the OTG HNP and SRP status from the TWL6030 and configure the bits inside
the control module that drive the related USBOTGHS UTMI interface signals.
It must also read back the UTMI signals needed to configure the TWL6030 
OTG module.

Can find more details in the TRM[1].
[1]:http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf

In OMAP4430 musb driver VBUS and ID notifications are received from the
transceiver driver. If the cable/device is connected during boot,
notifications from transceiver driver will be missed till musb driver
is loaded.
Patch to configure the transceiver in the platform_enable/disable
functions and enable the vbus in the gadget driver based on the 
last_event of the otg_transceiver.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
drivers/usb/musb/musb_gadget.c |4 +++
 drivers/usb/musb/musb_gadget.c |4 +++
 drivers/usb/musb/omap2430.c|   53 +
 2 files changed, 52 insertions(+), 5 deletions(-)

Index: linux-2.6/drivers/usb/musb/musb_gadget.c
===
--- linux-2.6.orig/drivers/usb/musb/musb_gadget.c
+++ linux-2.6/drivers/usb/musb/musb_gadget.c
@@ -1855,6 +1855,10 @@ int usb_gadget_probe_driver(struct usb_g
} else {
hcd->self.uses_pio_for_control = 1;
}
+
+   if ((musb->xceiv->last_event == USB_EVENT_ID)
+   && musb->xceiv->set_vbus)
+   otg_set_vbus(musb->xceiv, 1);
}
}
 
Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c
@@ -328,16 +328,56 @@ static int omap2430_musb_init(struct mus
if (status)
DBG(1, "notification register failed\n");
 
-   /* check whether cable is already connected */
-   if (musb->xceiv->state ==OTG_STATE_B_IDLE)
-   musb_otg_notifications(&musb->nb, 1,
-   musb->xceiv->gadget);
-
setup_timer(&musb_idle_timer, musb_do_idle, (unsigned long) musb);
 
return 0;
 }
 
+static void omap2430_musb_enable(struct musb *musb)
+{
+   u8  devctl;
+   unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+   struct device *dev = musb->controller;
+   struct musb_hdrc_platform_data *pdata = dev->platform_data;
+   struct omap_musb_board_data *data = pdata->board_data;
+
+   switch (musb->xceiv->last_event) {
+
+   case USB_EVENT_ID:
+   otg_init(musb->xceiv);
+   if (data->interface_type == MUSB_INTERFACE_UTMI) {
+   devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+   /* start the session */
+   devctl |= MUSB_DEVCTL_SESSION;
+   musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
+   while (musb_readb(musb->mregs, MUSB_DEVCTL) &
+   MUSB_DEVCTL_BDEVICE) {
+   cpu_relax();
+
+   if (time_after(jiffies, timeout)) {
+   dev_err(musb->controller,
+   "configured as A device timeout");
+   break;
+   }
+   }
+   }
+   break;
+
+   case USB_EVENT_VBUS:
+   otg_init(musb->xceiv);
+   break;
+
+   default:
+   break;
+   }
+}
+
+static void omap2430_musb_disable(struct musb *musb)
+{
+   if (musb->xceiv->last_event)
+   otg_shutdown(musb->xceiv);
+}
+
 static int omap2430_musb_exit(struct musb *musb)
 {
 
@@ -355,6 +395,9 @@ static const struct musb_platform_ops om
.try_idle   = omap2430_musb_try_idle,
 
.set_vbus   = omap2430_musb_set_vbus,
+
+   .enable = omap2430_musb_enable,
+   .disable= omap2430_musb_disable,
 };
 
 static u64 omap2430_dmamask = DMA_BIT_MASK(32);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[3/7 v4] usb: otg: OMAP4430: Add phy_suspend function pointer to twl4030_usb_data

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

Declare the .phy_suspend function pointer to twl4030_usb_data structure.
OMAP internal phy suspend function will be hooked though this function
pointer to use in the transceiver driver.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
 include/linux/i2c/twl.h |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6/include/linux/i2c/twl.h
===
--- linux-2.6.orig/include/linux/i2c/twl.h
+++ linux-2.6/include/linux/i2c/twl.h
@@ -600,6 +600,8 @@ struct twl4030_usb_data {
int (*phy_power)(struct device *dev, int iD, int on);
/* enable/disable  phy clocks */
int (*phy_set_clock)(struct device *dev, int on);
+   /* suspend/resume of phy */
+   int (*phy_suspend)(struct device *dev, int suspend);
 };
 
 struct twl4030_ins {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[4/7 v4] usb: otg: OMAP4430: Introducing suspend function for power management

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

Introduced the suspend/resume function for the OMAP4430 internal PHY.
This will be used by the twl6030-usb transceiver driver.
Moved the clock enable/disable function calls and power on/off of the PHY
code from power on/off functions to suspend/resume function.

Pass the suspend function through board data for OMAP4430sdp and OMAP4panda.
This will be used by the twl6030-usb transceiver driver.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
arch/arm/mach-omap2/omap_phy_internal.c |   22 +++---
 arch/arm/mach-omap2/board-4430sdp.c |1 +
 arch/arm/mach-omap2/board-omap4panda.c  |1 +
 arch/arm/mach-omap2/omap_phy_internal.c |   22 +++---
 arch/arm/plat-omap/include/plat/usb.h   |1 +
 4 files changed, 18 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/omap_phy_internal.c
+++ linux-2.6/arch/arm/mach-omap2/omap_phy_internal.c
@@ -104,13 +104,6 @@ int omap4430_phy_set_clk(struct device *
 int omap4430_phy_power(struct device *dev, int ID, int on)
 {
if (on) {
-   /* enabled the clocks */
-   omap4430_phy_set_clk(dev, 1);
-   /* power on the phy */
-   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
-   __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-   mdelay(200);
-   }
if (ID)
/* enable VBUS valid, IDDIG groung */
__raw_writel(AVALID | VBUSVALID, ctrl_base +
@@ -126,10 +119,25 @@ int omap4430_phy_power(struct device *de
/* Enable session END and IDIG to high impedence. */
__raw_writel(SESSEND | IDDIG, ctrl_base +
USBOTGHS_CONTROL);
+   }
+   return 0;
+}
+
+int omap4430_phy_suspend(struct device *dev, int suspend)
+{
+   if (suspend) {
/* Disable the clocks */
omap4430_phy_set_clk(dev, 0);
/* Power down the phy */
__raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+   } else {
+   /* Enable the internel phy clcoks */
+   omap4430_phy_set_clk(dev, 1);
+   /* power on the phy */
+   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
+   __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
+   mdelay(200);
+   }
}
 
return 0;
Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
===
--- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
@@ -88,6 +88,7 @@ extern int omap4430_phy_power(struct dev
 extern int omap4430_phy_set_clk(struct device *dev, int on);
 extern int omap4430_phy_init(struct device *dev);
 extern int omap4430_phy_exit(struct device *dev);
+extern int omap4430_phy_suspend(struct device *dev, int suspend);
 
 #endif
 
Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
@@ -272,6 +272,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit   = omap4430_phy_exit,
.phy_power  = omap4430_phy_power,
.phy_set_clock  = omap4430_phy_set_clk,
+   .phy_suspend= omap4430_phy_suspend,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
+++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
@@ -153,6 +153,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit   = omap4430_phy_exit,
.phy_power  = omap4430_phy_power,
.phy_set_clock  = omap4430_phy_set_clk,
+   .phy_suspend= omap4430_phy_suspend,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[5/7 v4] usb: otg: TWL6030: Introduce the twl6030_phy_suspend function.

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

Introduce the twl6030_phy_suspend function and assign to otg.set_suspend
function pointer.
This function is used by the musb-omap2430 platform driver
during suspend/resume.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
drivers/usb/otg/twl6030-usb.c |   16 
 drivers/usb/otg/twl6030-usb.c |   13 +
 1 file changed, 13 insertions(+)

Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -177,6 +177,17 @@ static void twl6030_phy_shutdown(struct 
pdata->phy_power(twl->dev, 0, 0);
 }
 
+static int twl6030_phy_suspend(struct otg_transceiver *x, int suspend)
+{
+   struct twl6030_usb *twl = xceiv_to_twl(x);
+   struct device *dev = twl->dev;
+   struct twl4030_usb_data *pdata = dev->platform_data;
+
+   pdata->phy_suspend(dev, suspend);
+
+   return 0;
+}
+
 static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
 {
 
@@ -388,6 +399,7 @@ static int __devinit twl6030_usb_probe(s
twl->otg.set_vbus   = twl6030_set_vbus;
twl->otg.init   = twl6030_phy_init;
twl->otg.shutdown   = twl6030_phy_shutdown;
+   twl->otg.set_suspend= twl6030_phy_suspend;
 
/* init spinlock for workqueue */
spin_lock_init(&twl->lock);
@@ -432,6 +444,7 @@ static int __devinit twl6030_usb_probe(s
 
twl->asleep = 0;
pdata->phy_init(dev);
+   twl6030_phy_suspend(&twl->otg, 0);
twl6030_enable_irq(&twl->otg);
dev_info(&pdev->dev, "Initialized TWL6030 USB module\n");
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[1/7 v4] usb: otg: enable regulator only on cable/device connect

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

Remove the regulator enable while driver loading and enable it only when
the cable/device is connected and disable it when disconnected.

Remove the configuration of config_state and config_trans register
configuration as these registers are programmed when regulator 
enable/disable is called.

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
drivers/usb/otg/twl6030-usb.c |   27 ---
 drivers/usb/otg/twl6030-usb.c |   27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -158,8 +158,6 @@ static int twl6030_phy_init(struct otg_t
dev  = twl->dev;
pdata = dev->platform_data;
 
-   regulator_enable(twl->usb3v3);
-
hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
 
if (hw_state & STS_USB_ID)
@@ -180,7 +178,6 @@ static void twl6030_phy_shutdown(struct 
dev  = twl->dev;
pdata = dev->platform_data;
pdata->phy_power(twl->dev, 0, 0);
-   regulator_disable(twl->usb3v3);
 }
 
 static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
@@ -199,16 +196,6 @@ static int twl6030_usb_ldo_init(struct t
if (IS_ERR(twl->usb3v3))
return -ENODEV;
 
-   regulator_enable(twl->usb3v3);
-
-   /* Program the VUSB_CFG_TRANS for ACTIVE state. */
-   twl6030_writeb(twl, TWL_MODULE_PM_RECEIVER, 0x3F,
-   VUSB_CFG_TRANS);
-
-   /* Program the VUSB_CFG_STATE register to ON on all groups. */
-   twl6030_writeb(twl, TWL_MODULE_PM_RECEIVER, 0xE1,
-   VUSB_CFG_STATE);
-
/* Program the USB_VBUS_CTRL_SET and set VBUS_ACT_COMP bit */
twl6030_writeb(twl, TWL_MODULE_USB, 0x4, USB_VBUS_CTRL_SET);
 
@@ -261,16 +248,23 @@ static irqreturn_t twl6030_usb_irq(int i
CONTROLLER_STAT1);
if (!(hw_state & STS_USB_ID)) {
if (vbus_state & VBUS_DET) {
+   regulator_enable(twl->usb3v3);
+   twl->asleep = 1;
status = USB_EVENT_VBUS;
twl->otg.default_a = false;
twl->otg.state = OTG_STATE_B_IDLE;
+   twl->linkstat = status;
+   blocking_notifier_call_chain(&twl->otg.notifier,
+   status, twl->otg.gadget);
} else {
status = USB_EVENT_NONE;
-   }
-   if (status >= 0) {
twl->linkstat = status;
blocking_notifier_call_chain(&twl->otg.notifier,
status, twl->otg.gadget);
+   if (twl->asleep) {
+   regulator_disable(twl->usb3v3);
+   twl->asleep = 0;
+   }
}
}
sysfs_notify(&twl->dev->kobj, NULL, "vbus");
@@ -288,6 +282,8 @@ static irqreturn_t twl6030_usbotg_irq(in
 
if (hw_state & STS_USB_ID) {
 
+   regulator_enable(twl->usb3v3);
+   twl->asleep = 1;
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_EN_HI_CLR, 0x1);
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_EN_HI_SET,
0x10);
@@ -437,6 +433,7 @@ static int __devinit twl6030_usb_probe(s
return status;
}
 
+   twl->asleep = 0;
pdata->phy_init(dev);
twl6030_enable_irq(&twl->otg);
dev_info(&pdev->dev, "Initialized TWL6030 USB module\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[2/7 v4] usb: otg: Remove one unnecessary I2C read request.

2011-02-16 Thread Hema HK
From: Kalliguddi, Hema 

To get the ID status there was an I2C read transfer. Removed this I2C
read transfer as this info can be used from existing variable(linkstat).

Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
drivers/usb/otg/twl6030-usb.c |7 ++-
 drivers/usb/otg/twl6030-usb.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

Index: linux-2.6/drivers/usb/otg/twl6030-usb.c
===
--- linux-2.6.orig/drivers/usb/otg/twl6030-usb.c
+++ linux-2.6/drivers/usb/otg/twl6030-usb.c
@@ -149,7 +149,6 @@ static int twl6030_set_phy_clk(struct ot
 
 static int twl6030_phy_init(struct otg_transceiver *x)
 {
-   u8 hw_state;
struct twl6030_usb *twl;
struct device *dev;
struct twl4030_usb_data *pdata;
@@ -158,9 +157,7 @@ static int twl6030_phy_init(struct otg_t
dev  = twl->dev;
pdata = dev->platform_data;
 
-   hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
-
-   if (hw_state & STS_USB_ID)
+   if (twl->linkstat == USB_EVENT_ID)
pdata->phy_power(twl->dev, 1, 1);
else
pdata->phy_power(twl->dev, 0, 1);
@@ -290,6 +287,7 @@ static irqreturn_t twl6030_usbotg_irq(in
status = USB_EVENT_ID;
twl->otg.default_a = true;
twl->otg.state = OTG_STATE_A_IDLE;
+   twl->linkstat = status;
blocking_notifier_call_chain(&twl->otg.notifier, status,
twl->otg.gadget);
} else  {
@@ -299,7 +297,6 @@ static irqreturn_t twl6030_usbotg_irq(in
0x1);
}
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_LATCH_CLR, status);
-   twl->linkstat = status;
 
return IRQ_HANDLED;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/5] OMAP2+: clock: remove the DPLL rate tolerance code

2011-02-16 Thread Paul Walmsley
Remove the DPLL rate tolerance code that is called during rate
rounding.  As far as I know, this code is never used, since it's been
more important for callers of the DPLL round_rate()/set_rate()
functions to obtain an exact rate than it is to save a relatively
small amount of power.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/clkt_dpll.c |   91 ---
 arch/arm/mach-omap2/clock.h |4 -
 arch/arm/mach-omap2/clock2420_data.c|1 
 arch/arm/mach-omap2/clock2430_data.c|1 
 arch/arm/mach-omap2/clock3xxx_data.c|6 --
 arch/arm/plat-omap/include/plat/clock.h |7 --
 6 files changed, 24 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 337392c..17735e7 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -178,12 +178,11 @@ void omap2_init_dpll_parent(struct clk *clk)
if (!dd)
return;
 
-   /* Return bypass rate if DPLL is bypassed */
v = __raw_readl(dd->control_reg);
v &= dd->enable_mask;
v >>= __ffs(dd->enable_mask);
 
-   /* Reparent in case the dpll is in bypass */
+   /* Reparent the struct clk in case the dpll is in bypass */
if (cpu_is_omap24xx()) {
if (v == OMAP2XXX_EN_DPLL_LPBYPASS ||
v == OMAP2XXX_EN_DPLL_FRBYPASS)
@@ -260,50 +259,22 @@ u32 omap2_get_dpll_rate(struct clk *clk)
 /* DPLL rate rounding code */
 
 /**
- * omap2_dpll_set_rate_tolerance: set the error tolerance during rate rounding
- * @clk: struct clk * of the DPLL
- * @tolerance: maximum rate error tolerance
- *
- * Set the maximum DPLL rate error tolerance for the rate rounding
- * algorithm.  The rate tolerance is an attempt to balance DPLL power
- * saving (the least divider value "n") vs. rate fidelity (the least
- * difference between the desired DPLL target rate and the rounded
- * rate out of the algorithm).  So, increasing the tolerance is likely
- * to decrease DPLL power consumption and increase DPLL rate error.
- * Returns -EINVAL if provided a null clock ptr or a clk that is not a
- * DPLL; or 0 upon success.
- */
-int omap2_dpll_set_rate_tolerance(struct clk *clk, unsigned int tolerance)
-{
-   if (!clk || !clk->dpll_data)
-   return -EINVAL;
-
-   clk->dpll_data->rate_tolerance = tolerance;
-
-   return 0;
-}
-
-/**
  * omap2_dpll_round_rate - round a target rate for an OMAP DPLL
  * @clk: struct clk * for a DPLL
  * @target_rate: desired DPLL clock rate
  *
- * Given a DPLL, a desired target rate, and a rate tolerance, round
- * the target rate to a possible, programmable rate for this DPLL.
- * Rate tolerance is assumed to be set by the caller before this
- * function is called.  Attempts to select the minimum possible n
- * within the tolerance to reduce power consumption.  Stores the
- * computed (m, n) in the DPLL's dpll_data structure so set_rate()
- * will not need to call this (expensive) function again.  Returns ~0
- * if the target rate cannot be rounded, either because the rate is
- * too low or because the rate tolerance is set too tightly; or the
- * rounded rate upon success.
+ * Given a DPLL and a desired target rate, round the target rate to a
+ * possible, programmable rate for this DPLL.  Attempts to select the
+ * minimum possible n.  Stores the computed (m, n) in the DPLL's
+ * dpll_data structure so set_rate() will not need to call this
+ * (expensive) function again.  Returns ~0 if the target rate cannot
+ * be rounded, or the rounded rate upon success.
  */
 long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate)
 {
-   int m, n, r, e, scaled_max_m;
-   unsigned long scaled_rt_rp, new_rate;
-   int min_e = -1, min_e_m = -1, min_e_n = -1;
+   int m, n, r, scaled_max_m;
+   unsigned long scaled_rt_rp;
+   unsigned long new_rate = 0;
struct dpll_data *dd;
 
if (!clk || !clk->dpll_data)
@@ -311,8 +282,8 @@ long omap2_dpll_round_rate(struct clk *clk, unsigned long 
target_rate)
 
dd = clk->dpll_data;
 
-   pr_debug("clock: starting DPLL round_rate for clock %s, target rate "
-"%ld\n", clk->name, target_rate);
+   pr_debug("clock: %s: starting DPLL round_rate, target rate %ld\n",
+clk->name, target_rate);
 
scaled_rt_rp = target_rate / (dd->clk_ref->rate / DPLL_SCALE_FACTOR);
scaled_max_m = dd->max_multiplier * DPLL_SCALE_FACTOR;
@@ -347,39 +318,23 @@ long omap2_dpll_round_rate(struct clk *clk, unsigned long 
target_rate)
if (r == DPLL_MULT_UNDERFLOW)
continue;
 
-   e = target_rate - new_rate;
-   pr_debug("clock: n = %d: m = %d: rate error is %d "
-"(new_rate = %ld)\n", n, m, e, new_rate);
-
-   if (min_e == -1 ||
-   min_e >= (int)(abs(e) - dd->rate_tolerance)) {
-   

[PATCH 4/5] OMAP: clock: bail out early if arch_clock functions not implemented

2011-02-16 Thread Paul Walmsley
Bail out before we take the clockfw_lock spinlock if the corresponding
OMAP1 or OMAP2+ clock function is not defined.  The intention is to
reduce and simplify the work that is done inside the spinlock.

Signed-off-by: Paul Walmsley 
---
 arch/arm/plat-omap/clock.c |   66 +---
 1 files changed, 38 insertions(+), 28 deletions(-)

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 2770ddd..c9122dd 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -37,14 +37,16 @@ static struct clk_functions *arch_clock;
 int clk_enable(struct clk *clk)
 {
unsigned long flags;
-   int ret = 0;
+   int ret;
 
if (clk == NULL || IS_ERR(clk))
return -EINVAL;
 
+   if (!arch_clock || !arch_clock->clk_enable)
+   return -EINVAL;
+
spin_lock_irqsave(&clockfw_lock, flags);
-   if (arch_clock->clk_enable)
-   ret = arch_clock->clk_enable(clk);
+   ret = arch_clock->clk_enable(clk);
spin_unlock_irqrestore(&clockfw_lock, flags);
 
return ret;
@@ -58,6 +60,9 @@ void clk_disable(struct clk *clk)
if (clk == NULL || IS_ERR(clk))
return;
 
+   if (!arch_clock || !arch_clock->clk_disable)
+   return;
+
spin_lock_irqsave(&clockfw_lock, flags);
if (clk->usecount == 0) {
pr_err("Trying disable clock %s with 0 usecount\n",
@@ -66,8 +71,7 @@ void clk_disable(struct clk *clk)
goto out;
}
 
-   if (arch_clock->clk_disable)
-   arch_clock->clk_disable(clk);
+   arch_clock->clk_disable(clk);
 
 out:
spin_unlock_irqrestore(&clockfw_lock, flags);
@@ -77,7 +81,7 @@ EXPORT_SYMBOL(clk_disable);
 unsigned long clk_get_rate(struct clk *clk)
 {
unsigned long flags;
-   unsigned long ret = 0;
+   unsigned long ret;
 
if (clk == NULL || IS_ERR(clk))
return 0;
@@ -97,14 +101,16 @@ EXPORT_SYMBOL(clk_get_rate);
 long clk_round_rate(struct clk *clk, unsigned long rate)
 {
unsigned long flags;
-   long ret = 0;
+   long ret;
 
if (clk == NULL || IS_ERR(clk))
-   return ret;
+   return 0;
+
+   if (!arch_clock || !arch_clock->clk_round_rate)
+   return 0;
 
spin_lock_irqsave(&clockfw_lock, flags);
-   if (arch_clock->clk_round_rate)
-   ret = arch_clock->clk_round_rate(clk, rate);
+   ret = arch_clock->clk_round_rate(clk, rate);
spin_unlock_irqrestore(&clockfw_lock, flags);
 
return ret;
@@ -119,14 +125,13 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
if (clk == NULL || IS_ERR(clk))
return ret;
 
+   if (!arch_clock || !arch_clock->clk_set_rate)
+   return ret;
+
spin_lock_irqsave(&clockfw_lock, flags);
-   if (arch_clock->clk_set_rate)
-   ret = arch_clock->clk_set_rate(clk, rate);
-   if (ret == 0) {
-   if (clk->recalc)
-   clk->rate = clk->recalc(clk);
+   ret = arch_clock->clk_set_rate(clk, rate);
+   if (ret == 0)
propagate_rate(clk);
-   }
spin_unlock_irqrestore(&clockfw_lock, flags);
 
return ret;
@@ -141,15 +146,14 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
if (clk == NULL || IS_ERR(clk) || parent == NULL || IS_ERR(parent))
return ret;
 
+   if (!arch_clock || !arch_clock->clk_set_parent)
+   return ret;
+
spin_lock_irqsave(&clockfw_lock, flags);
if (clk->usecount == 0) {
-   if (arch_clock->clk_set_parent)
-   ret = arch_clock->clk_set_parent(clk, parent);
-   if (ret == 0) {
-   if (clk->recalc)
-   clk->rate = clk->recalc(clk);
+   ret = arch_clock->clk_set_parent(clk, parent);
+   if (ret == 0)
propagate_rate(clk);
-   }
} else
ret = -EBUSY;
spin_unlock_irqrestore(&clockfw_lock, flags);
@@ -399,9 +403,11 @@ void clk_init_cpufreq_table(struct cpufreq_frequency_table 
**table)
 {
unsigned long flags;
 
+   if (!arch_clock || !arch_clock->clk_init_cpufreq_table)
+   return;
+
spin_lock_irqsave(&clockfw_lock, flags);
-   if (arch_clock->clk_init_cpufreq_table)
-   arch_clock->clk_init_cpufreq_table(table);
+   arch_clock->clk_init_cpufreq_table(table);
spin_unlock_irqrestore(&clockfw_lock, flags);
 }
 
@@ -409,9 +415,11 @@ void clk_exit_cpufreq_table(struct cpufreq_frequency_table 
**table)
 {
unsigned long flags;
 
+   if (!arch_clock || !arch_clock->clk_exit_cpufreq_table)
+   return;
+
spin_lock_irqsave(&clockfw_lock, flags);
-   if (arch_clock->clk_exit_cpufreq_table)
-   arch_clock->clk_exit

[PATCH 3/5] OMAP2xxx: clock: fix interface clocks and clockdomains for modules in the WKUP domain

2011-02-16 Thread Paul Walmsley
The parent of the interface clocks for GPTIMER1, MPU_WDT,
SYNCTIMER_32K, SCM, WDT1, and the ICR (2430 only) were all listed as
being l4_ck.  This isn't accurate; these modules exist inside the WKUP
domain, and the interface clock to these modules runs at the SYS_CLK
rate rather than the CORE L4 rate.

So, create a new clock "wu_l4_ick", similar to the OMAP3
"wkup_l4_ick", that serves as the parent for these clocks.

Also, these clocks were listed as existing inside core_l4_clkdm;
wkup_clkdm is probably more accurate.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/clock2420_data.c |   33 +++---
 arch/arm/mach-omap2/clock2430_data.c |   37 +-
 2 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index fd5ba90..6e9d20d 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -826,6 +826,14 @@ static struct clk dss_54m_fck = {  /* Alt clk used in 
power management */
.recalc = &followparent_recalc,
 };
 
+static struct clk wu_l4_ick = {
+   .name   = "wu_l4_ick",
+   .ops= &clkops_null,
+   .parent = &sys_ck,
+   .clkdm_name = "wkup_clkdm",
+   .recalc = &followparent_recalc,
+};
+
 /*
  * CORE power domain ICLK & FCLK defines.
  * Many of the these can have more than one possible parent. Entries
@@ -847,8 +855,8 @@ static const struct clksel omap24xx_gpt_clksel[] = {
 static struct clk gpt1_ick = {
.name   = "gpt1_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
-   .clkdm_name = "core_l4_clkdm",
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_GPT1_SHIFT,
.recalc = &followparent_recalc,
@@ -1300,8 +1308,8 @@ static struct clk uart3_fck = {
 static struct clk gpios_ick = {
.name   = "gpios_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
-   .clkdm_name = "core_l4_clkdm",
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_GPIOS_SHIFT,
.recalc = &followparent_recalc,
@@ -1320,8 +1328,8 @@ static struct clk gpios_fck = {
 static struct clk mpu_wdt_ick = {
.name   = "mpu_wdt_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
-   .clkdm_name = "core_l4_clkdm",
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_MPU_WDT_SHIFT,
.recalc = &followparent_recalc,
@@ -1340,9 +1348,9 @@ static struct clk mpu_wdt_fck = {
 static struct clk sync_32k_ick = {
.name   = "sync_32k_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.flags  = ENABLE_ON_INIT,
-   .clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_32KSYNC_SHIFT,
.recalc = &followparent_recalc,
@@ -1351,8 +1359,8 @@ static struct clk sync_32k_ick = {
 static struct clk wdt1_ick = {
.name   = "wdt1_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
-   .clkdm_name = "core_l4_clkdm",
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_WDT1_SHIFT,
.recalc = &followparent_recalc,
@@ -1361,9 +1369,9 @@ static struct clk wdt1_ick = {
 static struct clk omapctrl_ick = {
.name   = "omapctrl_ick",
.ops= &clkops_omap2_iclk_dflt_wait,
-   .parent = &l4_ck,
+   .parent = &wu_l4_ick,
+   .clkdm_name = "wkup_clkdm",
.flags  = ENABLE_ON_INIT,
-   .clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
.enable_bit = OMAP24XX_EN_OMAPCTRL_SHIFT,
.recalc = &followparent_recalc,
@@ -1825,6 +1833,7 @@ static struct omap_clk omap2420_clks[] = {
/* L4 domain clocks */
CLK(NULL,   "l4_ck",&l4_ck, CK_242X),
CLK(NULL,   "ssi_l4_ick",   &ssi_l4_ick,CK_242X),
+   CLK(NULL,   "wu_l4_ick",&wu_l4_ick, CK_242X),
/* virtual meta-group clock */
CLK(NULL,   "virt_prcm_set", &virt_prcm_set, CK_2

[PATCH 2/5] OMAP2xxx: clock: fix low-frequency oscillator clock rate

2011-02-16 Thread Paul Walmsley
The OMAP2420/2430 external 32-kHz low-frequency oscillator is a 32768
Hz oscillator, not a 32,000 Hz oscillator[1][2].  Fix this in the clock
tree.

Signed-off-by: Paul Walmsley 

1. OMAP2420/22 Multimedia Processor Data Manual, Version P [SWPS019P],
   section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
   a "32.768-kHz" clock; this presumably should be "32.768-KHz")

2. OMAP2430 Multimedia Processor ES2.1 Data Manual, Version V [SWPS023V],
   section 5.1.4 "External 32-kHz CMOS Clock" (note that it refers to
   a "32.768-kHz" clock; this presumably should be "32.768-KHz")
---
 arch/arm/mach-omap2/clock2420_data.c |2 +-
 arch/arm/mach-omap2/clock2430_data.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index 693a0a8..fd5ba90 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -55,7 +55,7 @@
 static struct clk func_32k_ck = {
.name   = "func_32k_ck",
.ops= &clkops_null,
-   .rate   = 32000,
+   .rate   = 32768,
.clkdm_name = "wkup_clkdm",
 };
 
diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index f00f52e..0d069ef 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -55,7 +55,7 @@
 static struct clk func_32k_ck = {
.name   = "func_32k_ck",
.ops= &clkops_null,
-   .rate   = 32000,
+   .rate   = 32768,
.clkdm_name = "wkup_clkdm",
 };
 


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


[PATCH 0/5] OMAP: clock: miscellaneous fixes and dead code removal for 2.6.39

2011-02-16 Thread Paul Walmsley
Hello,

This series contains some OMAP clock patches for 2.6.39.  The patches
in this series fix some long-standing inaccuracies in the OMAP2xxx clock trees,
prepare for some clock framework locking changes, and remove some
DPLL rate rounding code that I don't think anyone is using.

Dynamic idle entry and exit has been tested on an OMAP3530 Beagleboard, and
the "before" and "after" clock trees have been verified on an N800.


- Paul

---

clk_b_2.6.39
   textdata bss dec hex filename
3697449  229488 5390028 9316965  8e2a65 vmlinux.n800.orig
3697325  229584 5390028 9316937  8e2a49 vmlinux.n800.patched

Paul Walmsley (5):
  OMAP2xxx: clock: fix parents for L3-derived clocks
  OMAP2xxx: clock: fix low-frequency oscillator clock rate
  OMAP2xxx: clock: fix interface clocks and clockdomains for modules in the 
WKUP domain
  OMAP: clock: bail out early if arch_clock functions not implemented
  OMAP2+: clock: remove the DPLL rate tolerance code


 arch/arm/mach-omap2/clkt_dpll.c |   91 ---
 arch/arm/mach-omap2/clock.h |4 -
 arch/arm/mach-omap2/clock2420_data.c|   38 -
 arch/arm/mach-omap2/clock2430_data.c|   46 +---
 arch/arm/mach-omap2/clock3xxx_data.c|6 --
 arch/arm/plat-omap/clock.c  |   66 +-
 arch/arm/plat-omap/include/plat/clock.h |7 --
 7 files changed, 112 insertions(+), 146 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/5] OMAP2xxx: clock: fix parents for L3-derived clocks

2011-02-16 Thread Paul Walmsley
Several clocks are listed as having the core L4 clock as their parent,
when they are actually derived from the L3 clock.  Fix these.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/clock2420_data.c |2 +-
 arch/arm/mach-omap2/clock2430_data.c |6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index 68c0369..693a0a8 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1614,7 +1614,7 @@ static struct clk sdma_fck = {
 static struct clk sdma_ick = {
.name   = "sdma_ick",
.ops= &clkops_omap2_iclk_idle_only,
-   .parent = &l4_ck,
+   .parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP24XX_AUTO_SDMA_SHIFT,
diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index 34daed9..f00f52e 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1652,7 +1652,7 @@ static struct clk sdma_fck = {
 static struct clk sdma_ick = {
.name   = "sdma_ick",
.ops= &clkops_omap2_iclk_idle_only,
-   .parent = &l4_ck,
+   .parent = &core_l3_ck,
.clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP24XX_AUTO_SDMA_SHIFT,
@@ -1662,9 +1662,9 @@ static struct clk sdma_ick = {
 static struct clk sdrc_ick = {
.name   = "sdrc_ick",
.ops= &clkops_omap2_iclk_idle_only,
-   .parent = &l4_ck,
+   .parent = &core_l3_ck,
.flags  = ENABLE_ON_INIT,
-   .clkdm_name = "core_l4_clkdm",
+   .clkdm_name = "core_l3_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN3),
.enable_bit = OMAP2430_EN_SDRC_SHIFT,
.recalc = &followparent_recalc,


--
To unsubscribe from this list: send the line "unsubscribe 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: omap3evm does not boot after 2.6.38-rc1

2011-02-16 Thread Anand Gadiyar
Tony Lindgren wrote:
> * Sung Hee Park  [110216 14:18]:
> > Hi all,
> >
> > I'm having a problem with booting the linux kernel on my omap3evm. It
> > halts after saying "Uncompressing Linux... done, booting the kernel."
> > on boot. I had a similar problem with 2.6.37, but after changing the
> > name of the serial port devices from /dev/ttyS* to /dev/ttyO*, it
> > worked. Does anyone experiencing this problem again with 2.6.38
> > kernels? Please let me know if you have any idea what might have gone
> > wrong.
>
> If you have 2.6.38-rc1 booting, maybe try running git bisect on it
> to find out where it breaks?
>
> Tony

Enable CONFIG_EARLY_PRINTK, and add the word earlyprintk to your bootargs.
This should help get some prints on the debug UART which might help
debug this.

- 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


linux-next: manual merge of the omap_dss2 tree with the omap tree

2011-02-16 Thread Stephen Rothwell
Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/omap_hwmod_2420_data.c between commit
eb969b4f07175960fa0b325e6c9bd2093ab49645 ("OMAP2420: hwmod data: Add
McSPI") from the omap tree and commit
e9ca66e751e89d2d5323d809ecb2b54f4e255d8d ("OMAP2420: hwmod data: add DSS
DISPC RFBI VENC") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 7fffd34,21014de..000
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@@ -18,8 -18,8 +18,9 @@@
  #include 
  #include 
  #include 
 +#include 
- 
+ #include 
+ #include 
  #include "omap_hwmod_common_data.h"
  
  #include "cm-regbits-24xx.h"
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


linux-next: manual merge of the omap_dss2 tree with the omap tree

2011-02-16 Thread Stephen Rothwell
Hi Tomi,

Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/omap_hwmod_2430_data.c between commit
1ae9e33689d1346f7f85845857639a923e0796e3 ("OMAP2430: hwmod data: Add
McSPI") from the omap tree and commit
452e3eed4ee6eb8d61b290dad53d48508a3438d8 ("OMAP2430: hwmod data: add DSS
DISPC RFBI VENC") from the omap_dss2 tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 60fe4aa,1ef3f3f..000
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@@ -18,7 -18,7 +18,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include "omap_hwmod_common_data.h"
  
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap3evm does not boot after 2.6.38-rc1

2011-02-16 Thread Tony Lindgren
* Sung Hee Park  [110216 14:18]:
> Hi all,
> 
> I'm having a problem with booting the linux kernel on my omap3evm. It
> halts after saying "Uncompressing Linux... done, booting the kernel."
> on boot. I had a similar problem with 2.6.37, but after changing the
> name of the serial port devices from /dev/ttyS* to /dev/ttyO*, it
> worked. Does anyone experiencing this problem again with 2.6.38
> kernels? Please let me know if you have any idea what might have gone
> wrong.

If you have 2.6.38-rc1 booting, maybe try running git bisect on it
to find out where it breaks?

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/6] trivial compile warning fixes

2011-02-16 Thread Tony Lindgren
* Felipe Balbi  [110216 11:46]:
> On Wed, Feb 16, 2011 at 09:30:33AM -0800, Tony Lindgren wrote:
> > * Felipe Balbi  [110215 04:47]:
> > > Hi Tony,
> > > 
> > > following are a few compile warning fixes for your
> > > consideration.
> > 
> > I already got youre previous set queued in devel-cleanup
> > branch. Care to see if that needs further patching?
> 
> attached patch is needed.

OK thanks applying.

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 1/2] omap4: 4430sdp: drop ehci support

2011-02-16 Thread Tony Lindgren
* Felipe Balbi  [110216 03:25]:
> On Wed, Feb 16, 2011 at 04:47:19PM +0530, Anand Gadiyar wrote:
> > Most revisions of the OMAP4 Blaze/SDP platform do not have
> > the EHCI signals routed by default. The pads are routed
> > for the alternate HSI functionality instead, and explicit
> > board modifications are needed to route the signals to
> > the USB PHY on the board.
> > 
> > Also, turning on the PHY connected to the EHCI port causes
> > a board reboot during bootup due to an unintended short
> > on the rails - this affects many initial revisions of the
> > board, and needs a minor board mod to fix (or as a
> > workaround, one should not attempt to power on the
> > USB PHY).
> > 
> > Given that these boards need explicit board mods to even
> > get EHCI working (separate from the accidental short above),
> > we should not attempt to enable EHCI by default.
> > 
> > So drop the EHCI support from the board files for the
> > Blaze/SDP platforms.
> > 
> > Signed-off-by: Anand Gadiyar 
> > Cc: Keshava Munegowda 
> > Cc: Tony Lindgren 
> 
> Tony, if you want to queue this one directly, here's my:
> 
> Acked-by: Felipe Balbi 
> 
> if you wish, I can send you a pull request as well. I already have
> another patch for you anyway.

OK if you have more I'd rather pull.

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/6] CBUS Third try

2011-02-16 Thread Tony Lindgren
* Felipe Balbi  [110216 11:59]:
> Hi Tony,
> 
> here are the fixes for CBUS RETU.
> 
> Just one patch added, no other differences. My cbus
> branch has been updated for convenience:
> 
> git://gitorious.org/usb/usb.git cbus
> 
> (I'm starting to think usb.git isn't a good name for that tree)

I guess that does not matter :) Seems to boot now, pulling them in.

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/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx

2011-02-16 Thread Paul Walmsley
On Wed, 16 Feb 2011, Rajendra Nayak wrote:

> Boot-tested on 3430sdp/4430sdp, with CONFIG_PM and with !CONFIG_PM.
> suspend-offmode tested on 3430sdp and suspend-retmode on 4430sdp (with
> some out-of-tree patches)

Thanks, will add Tested-by:s.

> Dynamic idle testing on 3430sdp showed me some very jerky debug console 
> the moment a 'echo 1 > /debug/pm_debug/sleep_while_idle' is done. This 
> however seems to be the case even on 2.6.38-rc4 and not related to the 
> current patch series.

Does enabling CONFIG_OMAP2_DSS resolve the problem you're seeing?

> Will debug further, but seems to some 3430sdp specific issue, since you 
> did not see it on Beagleboard and seems it is not seen on OMAP3 zoom's 
> either. Just out of curiosity, what dynamic-idle state where you able to 
> achieve on Beagle?

Full chip off.  I use omap2plus_defconfig, sometimes with CONFIG_OMAP2_DSS 
depending on personal mood and what's being tested.  I boot to a shell and 
run the commands at the end of this message (some of which are probably 
superfluous).


- Paul


echo 1 > /debug/pm_debug/sleep_while_idle
echo 1 > /debug/pm_debug/enable_off_mode
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo enabled > /sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup
echo enabled > /sys/devices/platform/omap/omap_uart.1/tty/ttyO1/power/wakeup
echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup


--
To unsubscribe from this list: send the line "unsubscribe 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 5/7] omap: dpll: Enable all OMAP3/4 dpll autoidle late at boot

2011-02-16 Thread Paul Walmsley

Hi

After Rajendra's E-mail here:

   http://marc.info/?l=linux-arm-kernel&m=129785498406128&w=2

upon looking further, mach-omap2/pm.c is compiled in for !CONFIG_PM.  
This will be dealt with in a separate patch, but in the meantime, I 
propose we enable clock autoidle if CONFIG_OMAP_RESET_CLOCKS is set.  
(Really this config option should be called CONFIG_OMAP_DONT_BREAK_CLOCKFW 
or CONFIG_OMAP_MAKE_POWER_MANAGEMENT_WORK, but all that, too, is a matter 
for another patch.)

Here's what I'm proposing to use as a replacement; comments welcome.  The 
clk_autoidle_a_2.6.39 branch has been updated accordingly.


- Paul

From: Paul Walmsley 
Date: Mon, 14 Feb 2011 09:39:11 -0700
Subject: [PATCH] OMAP2+: clock: autoidle as many clocks as possible if 
CONFIG_OMAP_RESET_CLOCKS

Attempt to enable autoidle for as many clocks as possible in the
OMAP2+-common CONFIG_OMAP_RESET_CLOCKS code.  Currently, this only
enables DPLL autoidle for OMAP3/4 DPLLs; but future patches will
enable autoidle for other clocks and the OMAP2 DPLL/APLLs.

In the long run, we should probably get rid of
CONFIG_OMAP_RESET_CLOCKS, and unconditionally run the code that it
selects.  Otherwise, the state of the clock tree won't match the
hardware state - this could result in clocks being enabled or disabled
unpredictably.

Based on a patch by Rajendra Nayak  that did this in
the pm34xx.c/pm44xx.c code.

Signed-off-by: Paul Walmsley 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/pm34xx.c |   17 -
 arch/arm/plat-omap/clock.c   |1 +
 2 files changed, 1 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2f864e4..1fe2e73 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -814,23 +814,6 @@ static void __init prcm_setup_regs(void)
omap_ctrl_writel(OMAP3430_AUTOIDLE_MASK, OMAP2_CONTROL_SYSCONFIG);
 
/*
-* Set all plls to autoidle. This is needed until autoidle is
-* enabled by clockfw
-*/
-   omap2_cm_write_mod_reg(1 << OMAP3430_AUTO_IVA2_DPLL_SHIFT,
-OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
-   omap2_cm_write_mod_reg(1 << OMAP3430_AUTO_MPU_DPLL_SHIFT,
-MPU_MOD,
-CM_AUTOIDLE2);
-   omap2_cm_write_mod_reg((1 << OMAP3430_AUTO_PERIPH_DPLL_SHIFT) |
-(1 << OMAP3430_AUTO_CORE_DPLL_SHIFT),
-PLL_MOD,
-CM_AUTOIDLE);
-   omap2_cm_write_mod_reg(1 << OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT,
-PLL_MOD,
-CM_AUTOIDLE2);
-
-   /*
 * Enable control of expternal oscillator through
 * sys_clkreq. In the long run clock framework should
 * take care of this.
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 0ae0eae..2770ddd 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -446,6 +446,7 @@ static int __init clk_disable_unused(void)
return 0;
 }
 late_initcall(clk_disable_unused);
+late_initcall(omap_clk_enable_autoidle_all);
 #endif
 
 int __init clk_init(struct clk_functions * custom_clocks)
-- 
1.7.2.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


omap3evm does not boot after 2.6.38-rc1

2011-02-16 Thread Sung Hee Park
Hi all,

I'm having a problem with booting the linux kernel on my omap3evm. It
halts after saying "Uncompressing Linux... done, booting the kernel."
on boot. I had a similar problem with 2.6.37, but after changing the
name of the serial port devices from /dev/ttyS* to /dev/ttyO*, it
worked. Does anyone experiencing this problem again with 2.6.38
kernels? Please let me know if you have any idea what might have gone
wrong.

Regards,
Sung Hee Park
--
To unsubscribe from this list: send the line "unsubscribe 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/11] OMAP2+: clock: add clockfw autoidle for iclks, OMAP2xxx

2011-02-16 Thread Paul Walmsley
Hi Rajendra

On Wed, 16 Feb 2011, Rajendra Nayak wrote:

> > -Original Message-
> > From: linux-arm-kernel-boun...@lists.infradead.org
> [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf
> > Of Paul Walmsley
> > Sent: Wednesday, February 16, 2011 12:23 PM
> >
> > This series also ensures that all clock autoidle is disabled during
> > boot and only re-enabled if CONFIG_PM is enabled.
> 
> This does not seem to be the case. Maybe something like the
> below patch is what is missing..

Thanks for the review, you are absolutely right.  Rather than the patch 
you sent, and since mach-omap2/pm.c is compiled in even if !CONFIG_PM, 
I'd propose a different approach.  Until we can sort out the 
CONFIG_PM/pm.c issue, probably it would make more sense to move the 
autoidle-enable as part of CONFIG_OMAP_RESET_CLOCKS.  Will send a patch in 
reply to the original thread.


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


[PATCH 6/6 v2] cbus: retu: set pm_power_off to NULL when removing retu

2011-02-16 Thread Felipe Balbi
we need to clear pm_power_off otherwise we
will have kernel trying to call an unexistent
function.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index a4c565b..0ca58b7 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -489,6 +489,7 @@ static int __init retu_probe(struct platform_device *pdev)
return 0;
 
 err2:
+   pm_power_off = NULL;
__retu_write_reg(retu, RETU_REG_IMR, 0x);
free_irq(retu->irq, retu);
 
@@ -504,13 +505,15 @@ static int __exit retu_remove(struct platform_device 
*pdev)
 {
struct retu *retu = platform_get_drvdata(pdev);
 
+   pm_power_off = NULL;
+   the_retu = NULL;
+
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
 
free_irq(retu->irq, retu);
retu_irq_exit(retu);
kfree(retu);
-   the_retu = NULL;
 
return 0;
 }
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL

2011-02-16 Thread Felipe Balbi
We don't want non-GPL retu children, so force
all exported symbols to be GPL-only.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index af4d96a..4c8a7ea 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -106,7 +106,7 @@ int retu_read_reg(struct device *child, unsigned reg)
 
return __retu_read_reg(retu, reg);
 }
-EXPORT_SYMBOL(retu_read_reg);
+EXPORT_SYMBOL_GPL(retu_read_reg);
 
 /**
  * retu_write_reg - Write a value to a register in Retu
@@ -122,7 +122,7 @@ void retu_write_reg(struct device *child, unsigned reg, u16 
val)
 
__retu_write_reg(retu, reg, val);
 }
-EXPORT_SYMBOL(retu_write_reg);
+EXPORT_SYMBOL_GPL(retu_write_reg);
 
 /**
  * retu_set_clear_reg_bits - helper function to read/set/clear bits
@@ -185,7 +185,7 @@ int retu_read_adc(struct device *child, int channel)
 
return res;
 }
-EXPORT_SYMBOL(retu_read_adc);
+EXPORT_SYMBOL_GPL(retu_read_adc);
 
 static irqreturn_t retu_irq_handler(int irq, void *_retu)
 {
-- 
1.7.4.rc2

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


[PATCH 5/6 v2] cbus: retu: tabify retu initialization

2011-02-16 Thread Felipe Balbi
and while at that, save a register and drop
the irq variable which is used right before
initializing it to retu->irq.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |   27 +++
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 4c8a7ea..a4c565b 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -438,7 +438,6 @@ static int __init retu_probe(struct platform_device *pdev)
 
int ret = -ENOMEM;
int rev;
-   int irq;
 
retu = kzalloc(sizeof(*retu), GFP_KERNEL);
if (!retu) {
@@ -447,16 +446,14 @@ static int __init retu_probe(struct platform_device *pdev)
}
 
platform_set_drvdata(pdev, retu);
-   the_retu = retu;
 
-   mutex_init(&retu->mutex);
-
-   irq = platform_get_irq(pdev, 0);
+   retu->irq   = platform_get_irq(pdev, 0);
+   retu->irq_base  = pdata->irq_base;
+   retu->irq_end   = pdata->irq_end;
+   retu->devid = pdata->devid;
+   the_retu= retu;
 
-   retu->irq = irq;
-   retu->irq_base = pdata->irq_base;
-   retu->irq_end = pdata->irq_end;
-   retu->devid = pdata->devid;
+   mutex_init(&retu->mutex);
 
retu_irq_init(retu);
 
@@ -471,14 +468,14 @@ static int __init retu_probe(struct platform_device *pdev)
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
 
-   ret = request_threaded_irq(irq, NULL, retu_irq_handler, 0,
+   ret = request_threaded_irq(retu->irq, NULL, retu_irq_handler, 0,
  "retu", retu);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register IRQ handler\n");
goto err1;
}
 
-   set_irq_wake(irq, 1);
+   set_irq_wake(retu->irq, 1);
 
/* Register power off function */
pm_power_off = retu_power_off;
@@ -493,7 +490,7 @@ static int __init retu_probe(struct platform_device *pdev)
 
 err2:
__retu_write_reg(retu, RETU_REG_IMR, 0x);
-   free_irq(irq, retu);
+   free_irq(retu->irq, retu);
 
 err1:
kfree(retu);
@@ -506,13 +503,11 @@ err0:
 static int __exit retu_remove(struct platform_device *pdev)
 {
struct retu *retu = platform_get_drvdata(pdev);
-   int irq;
-
-   irq = platform_get_irq(pdev, 0);
 
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
-   free_irq(irq, retu);
+
+   free_irq(retu->irq, retu);
retu_irq_exit(retu);
kfree(retu);
the_retu = NULL;
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: headset: don't save pdev pointer

2011-02-16 Thread Felipe Balbi
... and save instead a device pointer. Generally
we only need a device pointer as we don't need
to poke with the platform_device that often and
if we do, we can always to_platform_device(dev).

Drop the pdev from the headset structure and
save dev instead.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-headset.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c
index d0b39a7..3b8e138 100644
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -38,7 +38,7 @@
 struct retu_headset {
spinlock_t  lock;
struct mutexmutex;
-   struct platform_device  *pdev;
+   struct device   *dev;
struct input_dev*idev;
unsignedbias_enabled;
unsigneddetection_enabled;
@@ -51,13 +51,13 @@ struct retu_headset {
 static void retu_headset_set_bias(struct retu_headset *hs, int enable)
 {
if (enable) {
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR,
(1 << 0) | (1 << 1), 0);
msleep(2);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR,
1 << 3, 0);
} else {
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR, 0,
(1 << 0) | (1 << 1) | (1 << 3));
}
 }
@@ -87,7 +87,7 @@ static void retu_headset_det_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->detection_enabled) {
hs->detection_enabled = 1;
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1,
(1 << 10) | (1 << 8), 0);
}
mutex_unlock(&hs->mutex);
@@ -106,7 +106,7 @@ static void retu_headset_det_disable(struct retu_headset 
*hs)
if (hs->pressed)
input_report_key(hs->idev, RETU_HEADSET_KEY, 0);
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1, 0,
(1 << 10) | (1 << 8));
}
mutex_unlock(&hs->mutex);
@@ -193,7 +193,7 @@ static irqreturn_t retu_headset_hook_interrupt(int irq, 
void *_hs)
input_report_key(hs->idev, RETU_HEADSET_KEY, 1);
}
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1, 0,
(1 << 10) | (1 << 8));
mod_timer(&hs->enable_timer, jiffies + msecs_to_jiffies(50));
 
@@ -204,7 +204,7 @@ static void retu_headset_enable_timer(unsigned long arg)
 {
struct retu_headset *hs = (struct retu_headset *) arg;
 
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1,
(1 << 10) | (1 << 8), 0);
mod_timer(&hs->detect_timer, jiffies + msecs_to_jiffies(350));
 }
@@ -232,7 +232,7 @@ static int __init retu_headset_probe(struct platform_device 
*pdev)
if (hs == NULL)
return -ENOMEM;
 
-   hs->pdev = pdev;
+   hs->dev = &pdev->dev;
 
hs->idev = input_allocate_device();
if (hs->idev == NULL) {
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: pass the child device pointer to all retu functions

2011-02-16 Thread Felipe Balbi
Throught the child device pointer, we can fetch
our needed struct retu simply by dev_get_drvdata(child->parent)

By using that trick, we can get really close to getting
rid of the global struct retu pointer.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-headset.c   |   31 ++-
 drivers/cbus/retu-pwrbutton.c |2 +-
 drivers/cbus/retu-rtc.c   |   28 ++--
 drivers/cbus/retu-wdt.c   |7 +++
 drivers/cbus/retu.c   |   37 +++--
 drivers/cbus/retu.h   |9 +
 6 files changed, 68 insertions(+), 46 deletions(-)

diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c
index acf5cbe7..d0b39a7 100644
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -48,15 +48,16 @@ struct retu_headset {
int irq;
 };
 
-static void retu_headset_set_bias(int enable)
+static void retu_headset_set_bias(struct retu_headset *hs, int enable)
 {
if (enable) {
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
(1 << 0) | (1 << 1), 0);
msleep(2);
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR, 1 << 3, 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   1 << 3, 0);
} else {
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR, 0,
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR, 0,
(1 << 0) | (1 << 1) | (1 << 3));
}
 }
@@ -66,7 +67,7 @@ static void retu_headset_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->bias_enabled) {
hs->bias_enabled = 1;
-   retu_headset_set_bias(1);
+   retu_headset_set_bias(hs, 1);
}
mutex_unlock(&hs->mutex);
 }
@@ -76,7 +77,7 @@ static void retu_headset_disable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (hs->bias_enabled) {
hs->bias_enabled = 0;
-   retu_headset_set_bias(0);
+   retu_headset_set_bias(hs, 0);
}
mutex_unlock(&hs->mutex);
 }
@@ -86,7 +87,8 @@ static void retu_headset_det_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->detection_enabled) {
hs->detection_enabled = 1;
-   retu_set_clear_reg_bits(RETU_REG_CC1, (1 << 10) | (1 << 8), 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   (1 << 10) | (1 << 8), 0);
}
mutex_unlock(&hs->mutex);
 }
@@ -104,7 +106,8 @@ static void retu_headset_det_disable(struct retu_headset 
*hs)
if (hs->pressed)
input_report_key(hs->idev, RETU_HEADSET_KEY, 0);
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(RETU_REG_CC1, 0, (1 << 10) | (1 << 8));
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   (1 << 10) | (1 << 8));
}
mutex_unlock(&hs->mutex);
 }
@@ -115,7 +118,7 @@ static ssize_t retu_headset_hookdet_show(struct device *dev,
 {
int val;
 
-   val = retu_read_adc(RETU_ADC_CHANNEL_HOOKDET);
+   val = retu_read_adc(dev, RETU_ADC_CHANNEL_HOOKDET);
return sprintf(buf, "%d\n", val);
 }
 
@@ -190,7 +193,8 @@ static irqreturn_t retu_headset_hook_interrupt(int irq, 
void *_hs)
input_report_key(hs->idev, RETU_HEADSET_KEY, 1);
}
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(RETU_REG_CC1, 0, (1 << 10) | (1 << 8));
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   (1 << 10) | (1 << 8));
mod_timer(&hs->enable_timer, jiffies + msecs_to_jiffies(50));
 
return IRQ_HANDLED;
@@ -200,7 +204,8 @@ static void retu_headset_enable_timer(unsigned long arg)
 {
struct retu_headset *hs = (struct retu_headset *) arg;
 
-   retu_set_clear_reg_bits(RETU_REG_CC1, (1 << 10) | (1 << 8), 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   (1 << 10) | (1 << 8), 0);
mod_timer(&hs->detect_timer, jiffies + msecs_to_jiffies(350));
 }
 
@@ -309,7 +314,7 @@ static int retu_headset_suspend(struct platform_device 
*pdev,
 
mutex_lock(&hs->mutex);
if (hs->bias_enabled)
-   retu_headset_set_bias(0);
+   retu_headset_set_bias(hs, 0);
mutex_unlock(&hs->mutex);
 
return 0;
@@ -321,7 +326,7 @@ static int retu_headset_resume(struct platform_device *pdev)
 
mutex_lock(&hs->mutex);
if (hs->bias_enabled)
-   retu_headset_set_bias(1);
+   retu_headset_set_bias(hs, 1);
mutex_unlock(&hs->mutex);
 
  

[PATCH 1/6] cbus: retu: wdt: save dev in retu_wdt_dev

2011-02-16 Thread Felipe Balbi
commit 6b8074b00d90b191227dc875b90b272c51f7d6eb
(cbus: Make retu watchdog behave like a standard
Linux watchdog) introduced struct retu_wdt_dev
with a field to save struct device *dev, but never
got the point of saving the pointer into that
structure.

Fix this very old bug so we can actually start
passing child device pointers to retu read/write
operations.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-wdt.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c
index 423216c..f6ff9ad 100644
--- a/drivers/cbus/retu-wdt.c
+++ b/drivers/cbus/retu-wdt.c
@@ -258,6 +258,7 @@ static int __init retu_wdt_probe(struct platform_device 
*pdev)
if (!wdev)
return -ENOMEM;
 
+   wdev->dev = &pdev->dev;
wdev->users = 0;
 
ret = device_create_file(&pdev->dev, &dev_attr_period);
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] CBUS Third try

2011-02-16 Thread Felipe Balbi
Hi Tony,

here are the fixes for CBUS RETU.

Just one patch added, no other differences. My cbus
branch has been updated for convenience:

git://gitorious.org/usb/usb.git cbus

(I'm starting to think usb.git isn't a good name for that tree)

Felipe Balbi (6):
  cbus: retu: wdt: save dev in retu_wdt_dev
  cbus: retu: pass the child device pointer to all retu functions
  cbus: retu: headset: don't save pdev pointer
  cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
  cbus: retu: tabify retu initialization
  cbus: retu: set pm_power_off to NULL when removing retu

 drivers/cbus/retu-headset.c   |   35 +++
 drivers/cbus/retu-pwrbutton.c |2 +-
 drivers/cbus/retu-rtc.c   |   28 
 drivers/cbus/retu-wdt.c   |8 ++--
 drivers/cbus/retu.c   |   73 
 drivers/cbus/retu.h   |9 +++--
 6 files changed, 88 insertions(+), 67 deletions(-)

-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 6/6] cbus: retu: set pm_power_off to NULL when removing retu

2011-02-16 Thread Felipe Balbi
On Wed, Feb 16, 2011 at 09:42:30PM +0200, Felipe Balbi wrote:
> we need to clear pm_power_off otherwise we
> will have kernel trying to call an unexistent
> function.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/cbus/retu.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
> index d0454bd..0ca58b7 100644
> --- a/drivers/cbus/retu.c
> +++ b/drivers/cbus/retu.c
> @@ -489,6 +489,7 @@ static int __init retu_probe(struct platform_device *pdev)
>   return 0;
>  
>  err2:
> + pm_power_off = NULL;
>   __retu_write_reg(retu, RETU_REG_IMR, 0x);
>   free_irq(retu->irq, retu);
>  
> @@ -504,7 +505,8 @@ static int __exit retu_remove(struct platform_device 
> *pdev)
>  {
>   struct retu *retu = platform_get_drvdata(pdev);
>  
> - irq = platform_get_irq(pdev, 0);
> + pm_power_off = NULL;
> + the_retu = NULL;

there it goes, I commited that hunk to the wrong patch. Sorry about
that.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe 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] cbus: retu: tabify retu initialization

2011-02-16 Thread Felipe Balbi
Hi,

On Wed, Feb 16, 2011 at 09:42:29PM +0200, Felipe Balbi wrote:
> @@ -506,13 +503,13 @@ err0:
>  static int __exit retu_remove(struct platform_device *pdev)
>  {
>   struct retu *retu = platform_get_drvdata(pdev);
> - int irq;
>  
>   irq = platform_get_irq(pdev, 0);

this should have been deleted. I compiled this.. oh well, I'm sending
another version of this.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe 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/6] trivial compile warning fixes

2011-02-16 Thread Felipe Balbi
On Wed, Feb 16, 2011 at 09:30:33AM -0800, Tony Lindgren wrote:
> * Felipe Balbi  [110215 04:47]:
> > Hi Tony,
> > 
> > following are a few compile warning fixes for your
> > consideration.
> 
> I already got youre previous set queued in devel-cleanup
> branch. Care to see if that needs further patching?

attached patch is needed.

-- 
balbi
>From b1487889dc0e6d3c328d658e5d6730373785a49c Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Sun, 16 Jan 2011 13:22:03 +0200
Subject: [PATCH] arm: omap2: clksel: fix compile warning
Organization: Texas Instruments\n

Fix the following compile warning:
arch/arm/mach-omap2/clkt_clksel.c: In function '_get_div_and_fieldval':
arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
used uninitialized in this function

Acked-by: Paul Walmsley 
Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/clkt_clksel.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c
index a781cd6..e25364d 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -97,7 +97,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
 u32 *field_val)
 {
 	const struct clksel *clks;
-	const struct clksel_rate *clkr, *max_clkr;
+	const struct clksel_rate *clkr, *max_clkr = NULL;
 	u8 max_div = 0;
 
 	clks = _get_clksel_by_parent(clk, src_clk);
-- 
1.7.4.rc2



Re: [PATCH v2] OMAP: PM: DMA: Enable runtime pm

2011-02-16 Thread Kevin Hilman
"G, Manjunath Kondaiah"  writes:

> Hi Kevin,
>
> On Mon, Feb 14, 2011 at 02:06:53PM -0800, Kevin Hilman wrote:
>> "G, Manjunath Kondaiah"  writes:
>> 
>> > From: Manjunath G Kondaiah 
>> >
>> > Enable runtime pm and use pm_runtime_get_sync and 
>> > pm_runtime_put_autosuspend
>> > for OMAP DMA driver.
>> >
>> > The DMA driver uses auto suspend feature of runtime pm framework through
>> > which the clock gets disabled automatically if there is no activity for
>> > more than one second.
>> >
>> > Testing:
>> > Compile: omap1_defconfig and omap2plus_defconfig
>> > Boot: OMAP1710(H3), OMAP2420(H4), OMAP3630(Zoom3), OMAP4(Blaze)
>> 
>> The normal DMA tests should also be run on these platforms.  Based on
>> the above, I can't tell any DMA tests were run.   Based on my tests,
>> this isn't working for chained xfers.
>> 
>> Using the runtime PM sysfs interface, you can check the runtime status
>> of the device:
>> 
>> # cat /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status  
>> 
>> 
>> It should show 'active' during transfer, and after timeout expires it
>> will show 'suspended'.
>> 
>> Doing some tests using my dmatest module:
>> 
>>   git://gitorious.org/omap-test/dmatest.git
>> 
>> I noticed that it gets stuck in 'active' and never gets suspended when I
>> used DMA channel linking (load module using 'linking=1' as load-time option)
>> 
>> I'm not sure exactly why, but I will guess that the reason is that there
>> is an imbalance in get/put calls when using chaining, since 'get' is
>> only called once upon omap_start_dma() but 'put' is called for every
>> channel in the callback.
>
> Even I noticed this after running chaining test case and checking
> runtime status. But, I am wondering even with 'active' runtime status, 
> the core hits off and retention.

Probably because system DMA is auto-idle and clocked by the core_l3_iclk

> The complete log which has all the sequences of running chaining tests,
> enabling off mode and checking runtime status is available at:
> http://pastebin.com/YEHMEXUP
>
> Though I agree on the point that, it is mismatch with get/put calls with
> DMA chaining, I still need to analyze this in detail.

Yes.  The mismatch highlights an underlying problem.

> The other thing which is not considered here is, the get_sync is called
> inside start_dma only(request_dma will call get_sync and put after the
> getting requested channel). After request_dma and start_dma, there are
> API's called by user(dma_set_params, priority etc) which also require
> get_sync since those API's will access configuration registers. I am
> wondering if have get_sync and put in all the API's, this might result
> in over loading. 

I'm not sure what you mean by over loading.

You need to have all register accesses inside get/put calls.  As long as
they are balanced, this should not leed to problems.

>> 
>> > On zoom3 core retention is tested with following steps:
>> > echo 1 > /debug/pm_debug/sleep_while_idle
>> > echo 1 > /debug/pm_debug/enable_off_mode
>> > echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>> > echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>> > echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>> > echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>> >
>> > It is observed that(on pm branch), core retention count gets increasing if 
>> > the
>> > board is left idle for more than 5 seconds. However, it doesnot enter off 
>> > mode
>> > (even without DMA runtime changes).
>> 
>> What silicon rev is on your Zoom3?  
> It's 3630 ES1.0. 
>> Mainline kernels now disable core off-mode for 3630 revs < ES2.1 due to 
>> erratum 
>>i583.
>> 
>> If this happens, you should see something like this on the console:
>> 
>>Core OFF disabled due to errata i583
>> 
> We can observe above message in mainline after enabling cpu idle in
> omap2plus_defconfig.
>
> I switched to zoom2 and able to hit core retention and
> off mode with mainline.

OK, good. 

Thanks for clarifying.


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


[PATCH 6/6] cbus: retu: set pm_power_off to NULL when removing retu

2011-02-16 Thread Felipe Balbi
we need to clear pm_power_off otherwise we
will have kernel trying to call an unexistent
function.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index d0454bd..0ca58b7 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -489,6 +489,7 @@ static int __init retu_probe(struct platform_device *pdev)
return 0;
 
 err2:
+   pm_power_off = NULL;
__retu_write_reg(retu, RETU_REG_IMR, 0x);
free_irq(retu->irq, retu);
 
@@ -504,7 +505,8 @@ static int __exit retu_remove(struct platform_device *pdev)
 {
struct retu *retu = platform_get_drvdata(pdev);
 
-   irq = platform_get_irq(pdev, 0);
+   pm_power_off = NULL;
+   the_retu = NULL;
 
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
@@ -512,7 +514,6 @@ static int __exit retu_remove(struct platform_device *pdev)
free_irq(retu->irq, retu);
retu_irq_exit(retu);
kfree(retu);
-   the_retu = NULL;
 
return 0;
 }
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: wdt: save dev in retu_wdt_dev

2011-02-16 Thread Felipe Balbi
commit 6b8074b00d90b191227dc875b90b272c51f7d6eb
(cbus: Make retu watchdog behave like a standard
Linux watchdog) introduced struct retu_wdt_dev
with a field to save struct device *dev, but never
got the point of saving the pointer into that
structure.

Fix this very old bug so we can actually start
passing child device pointers to retu read/write
operations.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-wdt.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c
index 423216c..f6ff9ad 100644
--- a/drivers/cbus/retu-wdt.c
+++ b/drivers/cbus/retu-wdt.c
@@ -258,6 +258,7 @@ static int __init retu_wdt_probe(struct platform_device 
*pdev)
if (!wdev)
return -ENOMEM;
 
+   wdev->dev = &pdev->dev;
wdev->users = 0;
 
ret = device_create_file(&pdev->dev, &dev_attr_period);
-- 
1.7.4.rc2

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


[PATCH 5/6] cbus: retu: tabify retu initialization

2011-02-16 Thread Felipe Balbi
and while at that, save a register and drop
the irq variable which is used right before
initializing it to retu->irq.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |   25 +++--
 1 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 4c8a7ea..d0454bd 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -438,7 +438,6 @@ static int __init retu_probe(struct platform_device *pdev)
 
int ret = -ENOMEM;
int rev;
-   int irq;
 
retu = kzalloc(sizeof(*retu), GFP_KERNEL);
if (!retu) {
@@ -447,16 +446,14 @@ static int __init retu_probe(struct platform_device *pdev)
}
 
platform_set_drvdata(pdev, retu);
-   the_retu = retu;
 
-   mutex_init(&retu->mutex);
-
-   irq = platform_get_irq(pdev, 0);
+   retu->irq   = platform_get_irq(pdev, 0);
+   retu->irq_base  = pdata->irq_base;
+   retu->irq_end   = pdata->irq_end;
+   retu->devid = pdata->devid;
+   the_retu= retu;
 
-   retu->irq = irq;
-   retu->irq_base = pdata->irq_base;
-   retu->irq_end = pdata->irq_end;
-   retu->devid = pdata->devid;
+   mutex_init(&retu->mutex);
 
retu_irq_init(retu);
 
@@ -471,14 +468,14 @@ static int __init retu_probe(struct platform_device *pdev)
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
 
-   ret = request_threaded_irq(irq, NULL, retu_irq_handler, 0,
+   ret = request_threaded_irq(retu->irq, NULL, retu_irq_handler, 0,
  "retu", retu);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register IRQ handler\n");
goto err1;
}
 
-   set_irq_wake(irq, 1);
+   set_irq_wake(retu->irq, 1);
 
/* Register power off function */
pm_power_off = retu_power_off;
@@ -493,7 +490,7 @@ static int __init retu_probe(struct platform_device *pdev)
 
 err2:
__retu_write_reg(retu, RETU_REG_IMR, 0x);
-   free_irq(irq, retu);
+   free_irq(retu->irq, retu);
 
 err1:
kfree(retu);
@@ -506,13 +503,13 @@ err0:
 static int __exit retu_remove(struct platform_device *pdev)
 {
struct retu *retu = platform_get_drvdata(pdev);
-   int irq;
 
irq = platform_get_irq(pdev, 0);
 
/* Mask all RETU interrupts */
__retu_write_reg(retu, RETU_REG_IMR, 0x);
-   free_irq(irq, retu);
+
+   free_irq(retu->irq, retu);
retu_irq_exit(retu);
kfree(retu);
the_retu = NULL;
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL

2011-02-16 Thread Felipe Balbi
We don't want non-GPL retu children, so force
all exported symbols to be GPL-only.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index af4d96a..4c8a7ea 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -106,7 +106,7 @@ int retu_read_reg(struct device *child, unsigned reg)
 
return __retu_read_reg(retu, reg);
 }
-EXPORT_SYMBOL(retu_read_reg);
+EXPORT_SYMBOL_GPL(retu_read_reg);
 
 /**
  * retu_write_reg - Write a value to a register in Retu
@@ -122,7 +122,7 @@ void retu_write_reg(struct device *child, unsigned reg, u16 
val)
 
__retu_write_reg(retu, reg, val);
 }
-EXPORT_SYMBOL(retu_write_reg);
+EXPORT_SYMBOL_GPL(retu_write_reg);
 
 /**
  * retu_set_clear_reg_bits - helper function to read/set/clear bits
@@ -185,7 +185,7 @@ int retu_read_adc(struct device *child, int channel)
 
return res;
 }
-EXPORT_SYMBOL(retu_read_adc);
+EXPORT_SYMBOL_GPL(retu_read_adc);
 
 static irqreturn_t retu_irq_handler(int irq, void *_retu)
 {
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: headset: don't save pdev pointer

2011-02-16 Thread Felipe Balbi
... and save instead a device pointer. Generally
we only need a device pointer as we don't need
to poke with the platform_device that often and
if we do, we can always to_platform_device(dev).

Drop the pdev from the headset structure and
save dev instead.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-headset.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c
index d0b39a7..3b8e138 100644
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -38,7 +38,7 @@
 struct retu_headset {
spinlock_t  lock;
struct mutexmutex;
-   struct platform_device  *pdev;
+   struct device   *dev;
struct input_dev*idev;
unsignedbias_enabled;
unsigneddetection_enabled;
@@ -51,13 +51,13 @@ struct retu_headset {
 static void retu_headset_set_bias(struct retu_headset *hs, int enable)
 {
if (enable) {
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR,
(1 << 0) | (1 << 1), 0);
msleep(2);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR,
1 << 3, 0);
} else {
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_AUDTXR, 0,
(1 << 0) | (1 << 1) | (1 << 3));
}
 }
@@ -87,7 +87,7 @@ static void retu_headset_det_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->detection_enabled) {
hs->detection_enabled = 1;
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1,
(1 << 10) | (1 << 8), 0);
}
mutex_unlock(&hs->mutex);
@@ -106,7 +106,7 @@ static void retu_headset_det_disable(struct retu_headset 
*hs)
if (hs->pressed)
input_report_key(hs->idev, RETU_HEADSET_KEY, 0);
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1, 0,
(1 << 10) | (1 << 8));
}
mutex_unlock(&hs->mutex);
@@ -193,7 +193,7 @@ static irqreturn_t retu_headset_hook_interrupt(int irq, 
void *_hs)
input_report_key(hs->idev, RETU_HEADSET_KEY, 1);
}
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1, 0,
(1 << 10) | (1 << 8));
mod_timer(&hs->enable_timer, jiffies + msecs_to_jiffies(50));
 
@@ -204,7 +204,7 @@ static void retu_headset_enable_timer(unsigned long arg)
 {
struct retu_headset *hs = (struct retu_headset *) arg;
 
-   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   retu_set_clear_reg_bits(hs->dev, RETU_REG_CC1,
(1 << 10) | (1 << 8), 0);
mod_timer(&hs->detect_timer, jiffies + msecs_to_jiffies(350));
 }
@@ -232,7 +232,7 @@ static int __init retu_headset_probe(struct platform_device 
*pdev)
if (hs == NULL)
return -ENOMEM;
 
-   hs->pdev = pdev;
+   hs->dev = &pdev->dev;
 
hs->idev = input_allocate_device();
if (hs->idev == NULL) {
-- 
1.7.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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/6] cbus: retu: pass the child device pointer to all retu functions

2011-02-16 Thread Felipe Balbi
Throught the child device pointer, we can fetch
our needed struct retu simply by dev_get_drvdata(child->parent)

By using that trick, we can get really close to getting
rid of the global struct retu pointer.

Signed-off-by: Felipe Balbi 
---
 drivers/cbus/retu-headset.c   |   31 ++-
 drivers/cbus/retu-pwrbutton.c |2 +-
 drivers/cbus/retu-rtc.c   |   28 ++--
 drivers/cbus/retu-wdt.c   |7 +++
 drivers/cbus/retu.c   |   37 +++--
 drivers/cbus/retu.h   |9 +
 6 files changed, 68 insertions(+), 46 deletions(-)

diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c
index acf5cbe7..d0b39a7 100644
--- a/drivers/cbus/retu-headset.c
+++ b/drivers/cbus/retu-headset.c
@@ -48,15 +48,16 @@ struct retu_headset {
int irq;
 };
 
-static void retu_headset_set_bias(int enable)
+static void retu_headset_set_bias(struct retu_headset *hs, int enable)
 {
if (enable) {
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR,
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
(1 << 0) | (1 << 1), 0);
msleep(2);
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR, 1 << 3, 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR,
+   1 << 3, 0);
} else {
-   retu_set_clear_reg_bits(RETU_REG_AUDTXR, 0,
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_AUDTXR, 0,
(1 << 0) | (1 << 1) | (1 << 3));
}
 }
@@ -66,7 +67,7 @@ static void retu_headset_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->bias_enabled) {
hs->bias_enabled = 1;
-   retu_headset_set_bias(1);
+   retu_headset_set_bias(hs, 1);
}
mutex_unlock(&hs->mutex);
 }
@@ -76,7 +77,7 @@ static void retu_headset_disable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (hs->bias_enabled) {
hs->bias_enabled = 0;
-   retu_headset_set_bias(0);
+   retu_headset_set_bias(hs, 0);
}
mutex_unlock(&hs->mutex);
 }
@@ -86,7 +87,8 @@ static void retu_headset_det_enable(struct retu_headset *hs)
mutex_lock(&hs->mutex);
if (!hs->detection_enabled) {
hs->detection_enabled = 1;
-   retu_set_clear_reg_bits(RETU_REG_CC1, (1 << 10) | (1 << 8), 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   (1 << 10) | (1 << 8), 0);
}
mutex_unlock(&hs->mutex);
 }
@@ -104,7 +106,8 @@ static void retu_headset_det_disable(struct retu_headset 
*hs)
if (hs->pressed)
input_report_key(hs->idev, RETU_HEADSET_KEY, 0);
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(RETU_REG_CC1, 0, (1 << 10) | (1 << 8));
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   (1 << 10) | (1 << 8));
}
mutex_unlock(&hs->mutex);
 }
@@ -115,7 +118,7 @@ static ssize_t retu_headset_hookdet_show(struct device *dev,
 {
int val;
 
-   val = retu_read_adc(RETU_ADC_CHANNEL_HOOKDET);
+   val = retu_read_adc(dev, RETU_ADC_CHANNEL_HOOKDET);
return sprintf(buf, "%d\n", val);
 }
 
@@ -190,7 +193,8 @@ static irqreturn_t retu_headset_hook_interrupt(int irq, 
void *_hs)
input_report_key(hs->idev, RETU_HEADSET_KEY, 1);
}
spin_unlock_irqrestore(&hs->lock, flags);
-   retu_set_clear_reg_bits(RETU_REG_CC1, 0, (1 << 10) | (1 << 8));
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1, 0,
+   (1 << 10) | (1 << 8));
mod_timer(&hs->enable_timer, jiffies + msecs_to_jiffies(50));
 
return IRQ_HANDLED;
@@ -200,7 +204,8 @@ static void retu_headset_enable_timer(unsigned long arg)
 {
struct retu_headset *hs = (struct retu_headset *) arg;
 
-   retu_set_clear_reg_bits(RETU_REG_CC1, (1 << 10) | (1 << 8), 0);
+   retu_set_clear_reg_bits(&hs->pdev->dev, RETU_REG_CC1,
+   (1 << 10) | (1 << 8), 0);
mod_timer(&hs->detect_timer, jiffies + msecs_to_jiffies(350));
 }
 
@@ -309,7 +314,7 @@ static int retu_headset_suspend(struct platform_device 
*pdev,
 
mutex_lock(&hs->mutex);
if (hs->bias_enabled)
-   retu_headset_set_bias(0);
+   retu_headset_set_bias(hs, 0);
mutex_unlock(&hs->mutex);
 
return 0;
@@ -321,7 +326,7 @@ static int retu_headset_resume(struct platform_device *pdev)
 
mutex_lock(&hs->mutex);
if (hs->bias_enabled)
-   retu_headset_set_bias(1);
+   retu_headset_set_bias(hs, 1);
mutex_unlock(&hs->mutex);
 
  

[PATCH 0/6] CBUS Second try

2011-02-16 Thread Felipe Balbi
Hi Tony,

here are the fixes for CBUS RETU.

Just one patch added, no other differences. My cbus
branch has been updated for convenience:

git://gitorious.org/usb/usb.git cbus

(I'm starting to think usb.git isn't a good name for that tree)

Felipe Balbi (6):
  cbus: retu: wdt: save dev in retu_wdt_dev
  cbus: retu: pass the child device pointer to all retu functions
  cbus: retu: headset: don't save pdev pointer
  cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
  cbus: retu: tabify retu initialization
  cbus: retu: set pm_power_off to NULL when removing retu

 drivers/cbus/retu-headset.c   |   35 +++
 drivers/cbus/retu-pwrbutton.c |2 +-
 drivers/cbus/retu-rtc.c   |   28 
 drivers/cbus/retu-wdt.c   |8 ++--
 drivers/cbus/retu.c   |   73 
 drivers/cbus/retu.h   |9 +++--
 6 files changed, 88 insertions(+), 67 deletions(-)

-- 
1.7.4.rc2

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


[PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling

2011-02-16 Thread David Cohen
Add support to register an isr for IOMMU fault situations and adapt it
to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
module might want to be informed when errors happen in order to debug it
or react.

Signed-off-by: David Cohen 
---
 arch/arm/mach-omap2/iommu2.c|   17 +-
 arch/arm/plat-omap/include/plat/iommu.h |   14 -
 arch/arm/plat-omap/iommu.c  |   52 ++-
 3 files changed, 65 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 49a1e5e..adb083e 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -146,18 +146,31 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool 
on)
 static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
 {
u32 stat, da;
+   u32 errs = 0;
 
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat &= MMU_IRQ_MASK;
-   if (!stat)
+   if (!stat) {
+   *ra = 0;
return 0;
+   }
 
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
 
+   if (stat & MMU_IRQ_TLBMISS)
+   errs |= OMAP_IOMMU_ERR_TLB_MISS;
+   if (stat & MMU_IRQ_TRANSLATIONFAULT)
+   errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+   if (stat & MMU_IRQ_EMUMISS)
+   errs |= OMAP_IOMMU_ERR_EMU_MISS;
+   if (stat & MMU_IRQ_TABLEWALKFAULT)
+   errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+   if (stat & MMU_IRQ_MULTIHITFAULT)
+   errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
 
-   return stat;
+   return errs;
 }
 
 static void omap2_tlb_read_cr(struct iommu *obj, struct cr_regs *cr)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..174f1b9 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk  *clk;
void __iomem*regbase;
struct device   *dev;
+   void*isr_priv;
 
unsigned intrefcount;
struct mutexiommu_lock; /* global for this whole object */
@@ -47,7 +48,7 @@ struct iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
 
-   int (*isr)(struct iommu *obj);
+   int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
 
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -109,6 +110,13 @@ struct iommu_platform_data {
u32 da_end;
 };
 
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS(1 << 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1)
+#define OMAP_IOMMU_ERR_EMU_MISS(1 << 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT   (1 << 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT  (1 << 4)
+
 #if defined(CONFIG_ARCH_OMAP1)
 #error "iommu for this processor not implemented yet"
 #else
@@ -161,6 +169,10 @@ extern size_t iopgtable_clear_entry(struct iommu *obj, u32 
iova);
 extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
 extern struct iommu *iommu_get(const char *name);
 extern void iommu_put(struct iommu *obj);
+extern int iommu_set_isr(const char *name,
+int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
+   void *priv),
+void *isr_priv);
 
 extern void iommu_save_ctx(struct iommu *obj);
 extern void iommu_restore_ctx(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index f55f458..b0e0efc 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -780,25 +780,19 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
  */
 static irqreturn_t iommu_fault_handler(int irq, void *data)
 {
-   u32 stat, da;
+   u32 da, errs;
u32 *iopgd, *iopte;
-   int err = -EIO;
struct iommu *obj = data;
 
if (!obj->refcount)
return IRQ_NONE;
 
-   /* Dynamic loading TLB or PTE */
-   if (obj->isr)
-   err = obj->isr(obj);
-
-   if (!err)
-   return IRQ_HANDLED;
-
clk_enable(obj->clk);
-   stat = iommu_report_fault(obj, &da);
+   errs = iommu_report_fault(obj, &da);
clk_disable(obj->clk);
-   if (!stat)
+
+   /* Fault callback or TLB/PTE Dynamic loading */
+   if (obj->isr && !obj->isr(obj, da, errs, obj->isr_priv))
return IRQ_HANDLED;
 
iommu_disable(obj);
@@ -806,15 +800,16 @@ static irqreturn_t iommu_fault_handler(int irq, void 
*data)
iopgd = iopgd_offset(obj, da);
 
if (!iopgd_is_table(*iopgd)) {
-   dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x\n", obj->name,
-   da, iopgd, *iopgd);
+   dev_err(obj->dev, "%s: errs:0x%08x da:0x%08x pgd:0x%p "
+ 

[PATCH v3 1/2] OMAP2+: IOMMU: don't print fault warning on specific layer

2011-02-16 Thread David Cohen
IOMMU upper layer and user are responsible to handle a fault and to
define whether it will end up as an error or not. OMAP2+ specific
layer should not print anything in such case.

Signed-off-by: David Cohen 
---
 arch/arm/mach-omap2/iommu2.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..49a1e5e 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -145,15 +145,7 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool on)
 
 static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
 {
-   int i;
u32 stat, da;
-   const char *err_msg[] = {
-   "tlb miss",
-   "translation fault",
-   "emulation miss",
-   "table walk fault",
-   "multi hit fault",
-   };
 
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat &= MMU_IRQ_MASK;
@@ -163,14 +155,6 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 
*ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
 
-   dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
-
-   for (i = 0; i < ARRAY_SIZE(err_msg); i++) {
-   if (stat & (1 << i))
-   printk("%s ", err_msg[i]);
-   }
-   printk("\n");
-
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
 
return stat;
-- 
1.7.2.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 v3 0/2] OMAP: IOMMU fault callback support

2011-02-16 Thread David Cohen
Hi,

This patch set adapts current (*isr)() to be used as fault callback.
IOMMU faults might be very difficult to reproduce and then to figure out
the source of the problem. Currently IOMMU driver prints not so useful
debug message and does not notice user about such issue.
With a fault callback, IOMMU user may debug much more useful information
and/or react to go back to a valid state.

Br,

David
---

David Cohen (2):
  OMAP2+: IOMMU: don't print fault warning on specific layer
  OMAP: IOMMU: add support to callback during fault handling

 arch/arm/mach-omap2/iommu2.c|   33 +---
 arch/arm/plat-omap/include/plat/iommu.h |   14 -
 arch/arm/plat-omap/iommu.c  |   52 ++-
 3 files changed, 65 insertions(+), 34 deletions(-)

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


Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Daniel Morsing
On Wed, 2011-02-16 at 17:58 +0200, Tomi Valkeinen wrote:
> On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:
> > On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:
> 
> > > And I found:
> > > 
> > > http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
> > > 
> > > It looks like 24bpp display.
> > > 
> > 
> > Ok I looked through the datasheet and it looks to me that i got
> > the .config field right. Only thing that's vague from that sheet is
> > which pixel clock edge the v-sync and h-sync are driven low and the
> > color distortion is still there with either option.
> > 
> > > What kind of color distortion do you see? Perhaps the problem is
> > > somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> > > signal setting in .config field. This info should be in the panel
> > > datasheet, but it usually takes some deciphering to understand it =).
> > > 
> > >  Tomi
> > > 
> > 
> > I'm seeing a light cyan tint to everything when running at 24bpp. Using
> > 16 datalines causes a heavy blue tint.
> 
> But with 24 datalines and 16 bpp it works? Sounds strange =). 
> 
> One thing to check are the pinmuxings (or pad configuration, as it's
> called in omap3 trm).
> 
> Are you using 2.6.37 or newer kernel?
> 
> Is this also happening with other devkit8000 devices, so it's not just a
> broken device?
> 
> Have you tried with an image with full red, green and blue areas, to see
> if only certain colors are affected? 
> 
> And the last option is of course get a scope and see what's going on in
> the datalines.
> 
>  Tomi
> 
> 

Ok I've done some more testing, the result being that I'm a bit of an
idiot.

The cyan tint only appears on console text. Running any sort of program
that actually used the display worked as intended. Setting the bpp as 16
actually made all the colors muted when you actually used the display,
so it is clearly the wrong "solution".

Since no one actually uses a hardware tty on a device like this, the
issue is kinda pointless. So I'm gonna resend the panel adding patch
without the bpp hack and with the correct name.

Regards,
Daniel Morsing



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


Re: [PATCH 00/15] More cleanups

2011-02-16 Thread Felipe Balbi
Hi,

On Wed, 2011-02-16 at 10:07 -0800, Tony Lindgren wrote:
> As based on a quick test this one will oops:
> 
> [2.925170] Internal error: Oops: 5 [#1] SMP
> [2.929656] last sysfs file:
> [2.932800] Modules linked in:
> [2.936035] CPU: 0Not tainted  (2.6.38-rc4-00101-gbbb5d46 #113)
> [2.942657] PC is at retu_write_reg+0x8/0x24
> [2.947143] LR is at _retu_modify_counter+0x28/0x34
> [2.952301] pc : []lr : []psr: a013
> [2.952331] sp : c7825ee8  ip :   fp : 
> [2.964355] r10:   r9 :   r8 : c0b4e6f0
> [2.969848] r7 : c05f5598  r6 :   r5 : 003f  r4 : 0017
> [2.976715] r3 : c0b4e6f0  r2 : 003f  r1 : 0017  r0 : 
> [2.983581] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kernel
> [2.991271] Control: 00c5387d  Table: 80004000  DAC: 0017
> [2.997314] Process swapper (pid: 1, stack limit = 0xc78242f8)
> [3.003448] Stack: (0xc7825ee8 to 0xc7826000)
> [3.008056] 5ee0:   c05f5598 003f  c032a23c 
> c05f5598 c032a278
> [3.016693] 5f00: c7a96ea0 c7898008  c002ceb0 c7898008 c7898008 
> c05f55ac c7a96f20
> [3.025299] 5f20: c05e8b60 c0296c40 c7898008 c0295da8 c7898008 c789803c 
> c05f55ac c0295ed0
> [3.033905] 5f40:  c0295e68 c05f55ac c02955c8 c7819658 c78bb790 
> c05f5598 c05f55ac
> [3.042541] 5f60: c05f55ac c0294efc c0532916 0468  c05f5598 
> c059aaf8 c05f55ac
> [3.051147] 5f80: 0013 c002cdb4  c02961c8 c05f5598 c059aaf8 
> c059aaf0 0013
> [3.059753] 5fa0: c002cdb4 c0297048 c0034930 c059aaf8 c059aaf0 c0052554 
>  
> [3.068389] 5fc0: c0500122 01a2 c059aaf8 c0034930 c059aaf8 c059aaf0 
> 0013 
> [3.076995] 5fe0:  c00084f4  c00083a4 c005dd64 c005dd64 
>  
> [3.085632] [] (retu_write_reg+0x8/0x24) from [] 
> (_retu_modify_counter+0x28/0x34)
> [3.095367] [] (_retu_modify_counter+0x28/0x34) from 
> [] (retu_modify_counter+0x30/0x44)
> [3.105651] [] (retu_modify_counter+0x30/0x44) from [] 
> (retu_wdt_probe+0xe8/0x160)
> [3.115447] [] (retu_wdt_probe+0xe8/0x160) from [] 
> (platform_drv_probe+0x18/0x
> [3.125183] [] (platform_drv_probe+0x18/0x1c) from [] 
> (driver_probe_device+0xc8/0x188)
> [3.135375] [] (driver_probe_device+0xc8/0x188) from 
> [] (__driver_attach+0x68/0x8c)
> [3.145263] [] (__driver_attach+0x68/0x8c) from [] 
> (bus_for_each_dev+0x44/0x74)
> [3.154815] [] (bus_for_each_dev+0x44/0x74) from [] 
> (bus_add_driver+0xa0/0x228)
> [3.164337] [] (bus_add_driver+0xa0/0x228) from [] 
> (driver_register+0xa8/0x130)
> [3.173889] [] (driver_register+0xa8/0x130) from [] 
> (platform_driver_probe+0x18/0x8c)
> [3.183990] [] (platform_driver_probe+0x18/0x8c) from 
> [] (do_one_initcall+0xc8/0x1a0)
> [3.194061] [] (do_one_initcall+0xc8/0x1a0) from [] 
> (kernel_init+0x150/0x218)
> [3.203430] [] (kernel_init+0x150/0x218) from [] 
> (kernel_thread_exit+0x0/0x8)
> [3.212768] Code: e8bd41f0 ea035b8e e92d4070 e1a04001 (e590)
> [3.219451] ---[ end trace 5cc53738ab810194 ]---

found the problem, commit 6b8074b00d90b191227dc875b90b272c51f7d6eb
never got to the point of saving struct device * in struct retu_wdt_dev.

Since it was there already, I was assuming it was working. Silly
mistake. The remaining patches are coming in a few minutes.

-- 
balbi

--
To unsubscribe from this list: send the line "unsubscribe 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 2/2] hwmon: twl4030: Hwmon Driver for TWL4030 MADC

2011-02-16 Thread Guenter Roeck
On Wed, Feb 16, 2011 at 12:59:52PM -0500, J, KEERTHY wrote:
> Hello Guenter,
> 
> On Wed, Feb 16, 2011 at 9:39 PM, Guenter Roeck
>  wrote:
> > On Wed, Feb 16, 2011 at 07:56:57AM -0500, Keerthy wrote:
> >> This driver exposes the sysfs nodes of the TWL4030 MADC module.
> >> All the channel values are expressed in terms of mV. Channel 13
> >> and channel 14 are reserved. There are channels which represent
> >> temperature and current. Even they output raw voltage in mV.
> >>
> > Why ?
> 
> The conversion to current and temperature in case of MADC depends
> on a register in the battery module. Hence battery driver can expose the
> converted value. So providing the raw voltage here.

Not a good reason.

You could create an API to let you retrieve the register values.
You could read the respective registers directly.
You could provide the register values in platform data.
If there will always be just one instance of the driver, you could provide
the register values via module parameters.
You could present the raw temperature/current values and correct it
with sensors3.conf.

Either case, I don't think it is a good idea to present known temperatures
or currents as voltage.

Guenter

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


Re: [PATCH 00/15] More cleanups

2011-02-16 Thread Tony Lindgren
Hi,

* Felipe Balbi  [110215 00:44]:
> We're almost there. retu.c looks very nice now.
> 
> The bulk effort is now on its children:
> 
> . retu-headset.c
>   . should use jack framework
>   . should use dev_pm_ops
>   . some cleanups wouldn't hurt
> 
> . retu-rtc.c
>   . needs suspend/resume (?)
> 
> . retu-wdt.c
>   . needs suspend/resume (?)
> 
> patches also available at [1] for convenience
> 
> [1] git://gitorious.org/usb/usb.git cbus
> 
> Felipe Balbi (15):
>   cbus: retu: drop retu_get_status
>   cbus: retu: replace BUG_ON with WARN
>   cbus: retu: drop the unnecessary spinlock_t
>   cbus: retu: drop unused PFX macro
>   arm: omap: cbus: add IDs for Retu and Tahvo
>   arm: omap: pass Retu ID via platform_data
>   cbus: retu: use the devid from platform_data
>   cbus: retu: introduce internal read/write functions
>   cbus: retu: search and replace
>   cbus: retu: pwrbutton: save device pointer on our structure

Looks like some did not make it to the list. But pulled
and did a git reset --hard at the patch above.

>   cbus: retu: pass the child device pointer to all retu functions

As based on a quick test this one will oops:

[2.925170] Internal error: Oops: 5 [#1] SMP
[2.929656] last sysfs file:
[2.932800] Modules linked in:
[2.936035] CPU: 0Not tainted  (2.6.38-rc4-00101-gbbb5d46 #113)
[2.942657] PC is at retu_write_reg+0x8/0x24
[2.947143] LR is at _retu_modify_counter+0x28/0x34
[2.952301] pc : []lr : []psr: a013
[2.952331] sp : c7825ee8  ip :   fp : 
[2.964355] r10:   r9 :   r8 : c0b4e6f0
[2.969848] r7 : c05f5598  r6 :   r5 : 003f  r4 : 0017
[2.976715] r3 : c0b4e6f0  r2 : 003f  r1 : 0017  r0 : 
[2.983581] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[2.991271] Control: 00c5387d  Table: 80004000  DAC: 0017
[2.997314] Process swapper (pid: 1, stack limit = 0xc78242f8)
[3.003448] Stack: (0xc7825ee8 to 0xc7826000)
[3.008056] 5ee0:   c05f5598 003f  c032a23c 
c05f5598 c032a278
[3.016693] 5f00: c7a96ea0 c7898008  c002ceb0 c7898008 c7898008 
c05f55ac c7a96f20
[3.025299] 5f20: c05e8b60 c0296c40 c7898008 c0295da8 c7898008 c789803c 
c05f55ac c0295ed0
[3.033905] 5f40:  c0295e68 c05f55ac c02955c8 c7819658 c78bb790 
c05f5598 c05f55ac
[3.042541] 5f60: c05f55ac c0294efc c0532916 0468  c05f5598 
c059aaf8 c05f55ac
[3.051147] 5f80: 0013 c002cdb4  c02961c8 c05f5598 c059aaf8 
c059aaf0 0013
[3.059753] 5fa0: c002cdb4 c0297048 c0034930 c059aaf8 c059aaf0 c0052554 
 
[3.068389] 5fc0: c0500122 01a2 c059aaf8 c0034930 c059aaf8 c059aaf0 
0013 
[3.076995] 5fe0:  c00084f4  c00083a4 c005dd64 c005dd64 
 
[3.085632] [] (retu_write_reg+0x8/0x24) from [] 
(_retu_modify_counter+0x28/0x34)
[3.095367] [] (_retu_modify_counter+0x28/0x34) from [] 
(retu_modify_counter+0x30/0x44)
[3.105651] [] (retu_modify_counter+0x30/0x44) from [] 
(retu_wdt_probe+0xe8/0x160)
[3.115447] [] (retu_wdt_probe+0xe8/0x160) from [] 
(platform_drv_probe+0x18/0x
[3.125183] [] (platform_drv_probe+0x18/0x1c) from [] 
(driver_probe_device+0xc8/0x188)
[3.135375] [] (driver_probe_device+0xc8/0x188) from [] 
(__driver_attach+0x68/0x8c)
[3.145263] [] (__driver_attach+0x68/0x8c) from [] 
(bus_for_each_dev+0x44/0x74)
[3.154815] [] (bus_for_each_dev+0x44/0x74) from [] 
(bus_add_driver+0xa0/0x228)
[3.164337] [] (bus_add_driver+0xa0/0x228) from [] 
(driver_register+0xa8/0x130)
[3.173889] [] (driver_register+0xa8/0x130) from [] 
(platform_driver_probe+0x18/0x8c)
[3.183990] [] (platform_driver_probe+0x18/0x8c) from [] 
(do_one_initcall+0xc8/0x1a0)
[3.194061] [] (do_one_initcall+0xc8/0x1a0) from [] 
(kernel_init+0x150/0x218)
[3.203430] [] (kernel_init+0x150/0x218) from [] 
(kernel_thread_exit+0x0/0x8)
[3.212768] Code: e8bd41f0 ea035b8e e92d4070 e1a04001 (e590)
[3.219451] ---[ end trace 5cc53738ab810194 ]---

>   cbus: retu: headset: don't save pdev pointer
>   cbus: retu: replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL
>   cbus: retu: tabify retu initialization
>   cbus: retu: set pm_power_off to NULL when removing retu

So left these out too.

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 2/2] hwmon: twl4030: Hwmon Driver for TWL4030 MADC

2011-02-16 Thread J, KEERTHY
Hello Guenter,

On Wed, Feb 16, 2011 at 9:39 PM, Guenter Roeck
 wrote:
> On Wed, Feb 16, 2011 at 07:56:57AM -0500, Keerthy wrote:
>> This driver exposes the sysfs nodes of the TWL4030 MADC module.
>> All the channel values are expressed in terms of mV. Channel 13
>> and channel 14 are reserved. There are channels which represent
>> temperature and current. Even they output raw voltage in mV.
>>
> Why ?

The conversion to current and temperature in case of MADC depends
on a register in the battery module. Hence battery driver can expose the
converted value. So providing the raw voltage here.
>
>> Signed-off-by: Keerthy 
>> ---
>>
>> The previous discussion concluded in keeping the generic ADC
>> functionality and the hwmon separate. The discussion can be found here:
>>
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html
>>
>>  Documentation/hwmon/twl4030-madc-hwmon |   45 +
>>  drivers/hwmon/Kconfig                  |   10 ++
>>  drivers/hwmon/Makefile                 |    1 +
>>  drivers/hwmon/twl4030-madc-hwmon.c     |  155 
>> 
>>  4 files changed, 211 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/hwmon/twl4030-madc-hwmon
>>  create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c
>>
>> diff --git a/Documentation/hwmon/twl4030-madc-hwmon 
>> b/Documentation/hwmon/twl4030-madc-hwmon
>> new file mode 100644
>> index 000..2cf1cc2
>> --- /dev/null
>> +++ b/Documentation/hwmon/twl4030-madc-hwmon
>> @@ -0,0 +1,45 @@
>> +Kernel driver twl4030-madc
>> +=
>> +
>> +Supported chips:
>> +     * Texas Instruments TWL4030
>> +     Prefix: 'twl4030-madc'
>> +
>> +
>> +Authors:
>> +     J Keerthy 
>> +
>> +Description
>> +---
>> +
>> +The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among
>> +other things it contains a 10-bit A/D converter MADC. The converter has 16
>> +channels which can be used in different modes.
>> +
>> +
>> +See this table for the meaning of the different channels
>> +
>> +Channel Signal
>> +--
>> +0    Battery type(BTYPE)
>> +1    BCI: Battery temperature (BTEMP)
>> +2    GP analog input
>> +3    GP analog input
>> +4    GP analog input
>> +5    GP analog input
>> +6    GP analog input
>> +7    GP analog input
>> +8    BCI: VBUS voltage(VBUS)
>> +9    Backup Battery voltage (VBKP)
>> +10   BCI: Battery charger current (ICHG)
>> +11   BCI: Battery charger voltage (VCHG)
>> +12   BCI: Main battery voltage (VBAT)
>> +13   Reserved
>> +14   Reserved
>> +15   VRUSB Supply/Speaker left/Speaker right polarization level
>> +
>> +
>> +The Sysfs nodes will represent the voltage in the units of mV,
>> +the temperature channel shows the converted raw voltage in mV.
>> +The Battery charging current channel represents raw voltage mV.
>
> Doesn't really make sense to me to export values known to be current and 
> temperature
> as voltages. You'll have to add a lot more information for that to make sense.
>

As mentioned earlier the raw voltage to current conversion depends on the CGAIN
bit of the BCICTL1 battery register. Hence i preferrd not to include
the conversion
here.

>> +Channel 13 and 14 are reserved.
>
> You already said that above.

Ok i will remove this.
>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 773e484..11ddde3 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -940,6 +940,16 @@ config SENSORS_TMP421
>>         This driver can also be built as a module.  If so, the module
>>         will be called tmp421.
>>
>> +config SENSORS_TWL4030_MADC
>> +     tristate "Texas Instruments TWL4030 MADC Hwmon"
>> +     depends on TWL4030_MADC
>> +     help
>> +     This driver provides hwmon support for triton TWL4030-MADC.
>> +     This driver can be built as part of kernel or can be built
>> +     as a module.
>
>        Kernel is obvious. Please stick with the usual text
>

Ok.
>        "This driver can also be built as a module.  If so, the module
>         will be called "
>
> At least please tell users how the module is named.
>

Ok. I will add it.
>> +             This driver exposes the various voltage values to
>> +     the user space.
>> +
> Not sure if this provides any value. Either case, it should be before "built 
> as module".
>

Ok.
>>  config SENSORS_VIA_CPUTEMP
>>       tristate "VIA CPU temperature sensor"
>>       depends on X86
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index dde02d9..bc7d740 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -102,6 +102,7 @@ obj-$(CONFIG_SENSORS_THMC50)      += thmc50.o
>>  obj-$(CONFIG_SENSORS_TMP102) += tmp102.o
>>  obj-$(CONFIG_SENSORS_TMP401) += tmp401.o
>>  obj-$(CONFIG_SENSORS_TMP421) += tmp421.o
>> +obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o
>>  obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
>>  obj-$(CONFIG_SENSORS_VIA686A)        += via686a.o
>>  obj-$

Re: [PATCH 0/6] trivial compile warning fixes

2011-02-16 Thread Tony Lindgren
* Felipe Balbi  [110215 04:47]:
> Hi Tony,
> 
> following are a few compile warning fixes for your
> consideration.

I already got youre previous set queued in devel-cleanup
branch. Care to see if that needs further patching?

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] omap: Move omap2_check_revision and omap_sram_init out of map_io

2011-02-16 Thread Tony Lindgren
* Tony Lindgren  [110214 17:52]:
> * Tony Lindgren  [110214 15:51]:
> > With the early init changes we just want to map IO in map_io.
> > Both omap2_check_revision and omap_sram_init can be moved to
> > happen later in omap2_init_common_infrastructure.
> > 
> > Note that now we can now remove _omap2_map_common_io and remove
> > the extra flushes too as devicemaps_init will take care of it.
> 
> Hmm this one seems to need a bit more work, won't work on 2420.

That's because calling iotable_init after bootmem_init will skip
calling arm_bootmem_init and the new memblock_region we never
call reserve_bootmem on the new entry. So let's skip this for now.

If we want to do SoC detection and SRAM init later during the
boot, we'd have to allocate SRAM the same way as dma-mapping
and ioremap code does.

Regards,

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


[PATCH] TI816X: Update to use init_early

2011-02-16 Thread Tony Lindgren
* Tony Lindgren  [110215 10:04]:
> * Russell King - ARM Linux  [110215 10:00]:
> > On Tue, Feb 15, 2011 at 11:06:08PM +0530, Hemant Pedanekar wrote:
> > > +static void __init ti8168_evm_init_irq(void)
> > > +{
> > > + omap_board_config = ti8168_evm_config;
> > > + omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> > > + omap2_init_common_infrastructure();
> > > + omap2_init_common_devices(NULL, NULL);
> > > + omap_init_irq();
> > > +}
> > 
> > What here can use the new init_early hook in the machine record?
> 
> I can fix this up for the init_early changes when I merge the branches
> together.

Here's the patch to do that.

Tony

From: Tony Lindgren 
Date: Wed, 16 Feb 2011 08:45:46 -0800
Subject: [PATCH] TI816X: Update to use init_early

Update to use init_early

Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -27,12 +27,16 @@
 static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
 };
 
-static void __init ti8168_evm_init_irq(void)
+static void __init ti8168_init_early(void)
 {
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
omap2_init_common_infrastructure();
omap2_init_common_devices(NULL, NULL);
+}
+
+static void __init ti8168_evm_init_irq(void)
+{
omap_init_irq();
 }
 
@@ -51,6 +55,7 @@ MACHINE_START(TI8168EVM, "ti8168evm")
/* Maintainer: Texas Instruments */
.boot_params= 0x8100,
.map_io = ti8168_evm_map_io,
+   .init_early = ti8168_init_early,
.init_irq   = ti8168_evm_init_irq,
.timer  = &omap_timer,
.init_machine   = ti8168_evm_init,
--
To unsubscribe from this list: send the line "unsubscribe 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: Avoid discarding sections that might have SMP_ON_UP fixups

2011-02-16 Thread Dave Martin
Hi,

On Fri, Feb 11, 2011 at 04:32:47PM +, Russell King - ARM Linux wrote:

[...]

> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 45b5651..343d29f 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -21,6 +21,12 @@
>  #define ARM_CPU_KEEP(x)
>  #endif
>  
> +#if defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)
> +#define ARM_EXIT_KEEP(x) x
> +#else
> +#define ARM_EXIT_KEEP(x)
> +#endif
> +
>  OUTPUT_ARCH(arm)
>  ENTRY(stext)
>  
> @@ -43,6 +49,7 @@ SECTIONS
>   _sinittext = .;
>   HEAD_TEXT
>   INIT_TEXT
> + ARM_EXIT_KEEP(EXIT_TEXT)
>   _einittext = .;
>   ARM_CPU_DISCARD(PROC_INFO)
>   __arch_info_begin = .;
> @@ -71,6 +78,7 @@ SECTIONS
>  #ifndef CONFIG_XIP_KERNEL
>   __init_begin = _stext;
>   INIT_DATA
> + ARM_EXIT_KEEP(EXIT_DATA)
>  #endif
>   }
>  
> @@ -166,6 +174,7 @@ SECTIONS
>   . = ALIGN(PAGE_SIZE);
>   __init_begin = .;
>   INIT_DATA
> + ARM_EXIT_KEEP(EXIT_DATA)
>   . = ALIGN(PAGE_SIZE);
>   __init_end = .;
>  #endif
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This works for me in a case known to fail without the patch.

Tested-by: Dave Martin 

I still don't quite understand the intricacies of how vmlinux
is laid out, but the patch looks sensible.

Do you need anything more from me on this?  If not, I will
throw away my patch and replace it with yours.

Cheers
---Dave
--
To unsubscribe from this list: send the line "unsubscribe 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: DSS2: Adding fclk support for DPI interface

2011-02-16 Thread Cousson, Benoit

Hi Murthy,

On 2/16/2011 9:57 AM, Murthy, Raghuveer wrote:

On Monday 14 February 2011 09:32 PM, Valkeinen, Tomi wrote:

Hi,

On Thu, 2011-02-03 at 07:56 -0600, Murthy, Raghuveer wrote:

- Adding dss_feature for DPLL fclk
- Enabling pixel clock generation for DPI interface


A bit more description what the patch set is about would be nice. Also,
one line patch descriptions are a bit too short for anything else than
the most trivial patches.

Now to the actual patch contents:

DPLL is not a feature of the DSS, and I don't think we should have
dss_features for that. In fact, I think the whole DPLL code should be
moved from DSS to somewhere under arch/arm.

In a perfect world DSS could just set the dss_fck to whatever rate it
requires, but as the clock rate can only be set to certain rates, and we
need a precise control for the rate, some other method has to be in
place.

I am not sure what this method should be. Perhaps there is something in
the clock framework that could help us here, or perhaps we just need a
bunch of function pointers in the DSS's platform data which can be used
to configure the clock.

   Tomi




Hi Paul, Benoit,

DPLL_PER post divider output for DSS core functional clock can be
changed in OMAP3xxx and OMAP4430, based on the requested pixel clock for
a given display resolution.

Additionally, the number of dividers available for DPLL_PER post
dividors for DSS has increased from 16 to 32, from OMAP3630 onwards.

Both these are added as dss_features.

Given the above comments from Tomi, can the same be included as part of
the clock framework?


Yes, I do agree with Tomi, this code has nothing to do in the DSS driver.
We do have similar issue with clock rate that can be changed by 2 
successive clock nodes (DPLL and HS divider for example).


But it might be tricky to handle in a generic manner. We need to tie 
these two clock nodes and thus ensuring that there is no other 
descendant for the parent node and then force a parent rate change if 
the clock rate cannot be achieve by the descendant.


Maybe Paul has some idea about that.

Regards,
Benoit

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


Re: [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault handling

2011-02-16 Thread David Cohen
On Tue, Feb 15, 2011 at 5:10 PM, David Cohen  wrote:
> On Tue, Feb 15, 2011 at 4:48 PM, Hiroshi DOYU  wrote:
>> Hi David,
>
> Hi Hiroshi,
>
>>
>> Sorry for a bit late reply
>
> You're just in time. :)
>
>>
>> From: David Cohen 
>> Subject: [PATCH v2 1/1] OMAP: IOMMU: add support to callback during fault 
>> handling
>> Date: Tue, 15 Feb 2011 16:36:31 +0200
>>
>>> Add support to register a callback for IOMMU fault situations. Drivers using
>>> IOMMU module might want to be informed when such errors happen in order to
>>> debug it or react.
>>>
>>> Signed-off-by: David Cohen 
>>> ---
>>>  arch/arm/mach-omap2/iommu2.c            |   21 +--
>>>  arch/arm/plat-omap/include/plat/iommu.h |   15 ++-
>>>  arch/arm/plat-omap/iommu.c              |   41 
>>> ---
>>>  3 files changed, 69 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>>> index 14ee686..504310d 100644
>>> --- a/arch/arm/mach-omap2/iommu2.c
>>> +++ b/arch/arm/mach-omap2/iommu2.c
>>> @@ -143,10 +143,10 @@ static void omap2_iommu_set_twl(struct iommu *obj, 
>>> bool on)
>>>       __iommu_set_twl(obj, false);
>>>  }
>>>
>>> -static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
>>> +static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 
>>> *iommu_errs)
>>>  {
>>>       int i;
>>> -     u32 stat, da;
>>> +     u32 stat, da, errs;
>>>       const char *err_msg[] = {
>>>               "tlb miss",
>>>               "translation fault",
>>> @@ -157,8 +157,10 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, 
>>> u32 *ra)
>>>
>>>       stat = iommu_read_reg(obj, MMU_IRQSTATUS);
>>>       stat &= MMU_IRQ_MASK;
>>> -     if (!stat)
>>> +     if (!stat) {
>>> +             *iommu_errs = 0;
>>>               return 0;
>>> +     }
>>>
>>>       da = iommu_read_reg(obj, MMU_FAULT_AD);
>>>       *ra = da;
>>> @@ -171,6 +173,19 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, 
>>> u32 *ra)
>>>       }
>>>       printk("\n");
>>>
>>> +     errs = 0;
>>> +     if (stat & MMU_IRQ_TLBMISS)
>>> +             errs |= OMAP_IOMMU_ERR_TLB_MISS;
>>> +     if (stat & MMU_IRQ_TRANSLATIONFAULT)
>>> +             errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
>>> +     if (stat & MMU_IRQ_EMUMISS)
>>> +             errs |= OMAP_IOMMU_ERR_EMU_MISS;
>>> +     if (stat & MMU_IRQ_TABLEWALKFAULT)
>>> +             errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
>>> +     if (stat & MMU_IRQ_MULTIHITFAULT)
>>> +             errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
>>> +     *iommu_errs = errs;
>>> +
>>>       iommu_write_reg(obj, stat, MMU_IRQSTATUS);
>>>
>>>       return stat;
>>> diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
>>> b/arch/arm/plat-omap/include/plat/iommu.h
>>> index 19cbb5e..5a2475f 100644
>>> --- a/arch/arm/plat-omap/include/plat/iommu.h
>>> +++ b/arch/arm/plat-omap/include/plat/iommu.h
>>> @@ -31,6 +31,7 @@ struct iommu {
>>>       struct clk      *clk;
>>>       void __iomem    *regbase;
>>>       struct device   *dev;
>>> +     void            *fault_cb_priv;
>>>
>>>       unsigned int    refcount;
>>>       struct mutex    iommu_lock;     /* global for this whole object */
>>> @@ -48,6 +49,7 @@ struct iommu {
>>>       struct mutex            mmap_lock; /* protect mmap */
>>>
>>>       int (*isr)(struct iommu *obj);
>>> +     void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void 
>>> *priv);
>>
>> What about making use of (*isr)() for fault call back as well?
>>
>> Basic concept is that, client can decide how to deal with iommu
>> fault. For example, for advanced case, client wants daynamic loading of
>> TLB(or PTE), or for ISP case, clients just want more appropriate fault
>> reporting. This (*isr)() could be used in such flexibility.
>
> In this case, it seems we can re-use it.
>
>>
>>   785   *      Device IOMMU generic operations
>>   786   */
>>   787  static irqreturn_t iommu_fault_handler(int irq, void *data)
>>   788  {
>>   789          u32 stat, da;
>>   790          u32 *iopgd, *iopte;
>>   791          int err = -EIO;
>>   792          struct iommu *obj = data;
>>   793
>>   794          if (!obj->refcount)
>>   795                  return IRQ_NONE;
>>   796
>>   797          /* Dynamic loading TLB or PTE */
>>   798          if (obj->isr)
>>   799                  err = obj->isr(obj);
>>   800
>>   801          if (!err)
>>   802                  return IRQ_HANDLED;
>>   803
>>   804          clk_enable(obj->clk);
>>   805          stat = iommu_report_fault(obj, &da);
>>   806          clk_disable(obj->clk);
>>   807          if (!stat)
>>   808                  return IRQ_HANDLED;
>>   809
>>   810          iommu_disable(obj);
>>
>> I guess that this modifying the above code could make (*isr)()
>> flexible to be used for any purpose for clients? For me, having both
>> following may be a bit residual.
>

There are few possible issues in this case. (*isr)() is meant to
replace the generic fault handler on iommu, but the

Re: [PATCH 2/2] hwmon: twl4030: Hwmon Driver for TWL4030 MADC

2011-02-16 Thread Guenter Roeck
On Wed, Feb 16, 2011 at 07:56:57AM -0500, Keerthy wrote:
> This driver exposes the sysfs nodes of the TWL4030 MADC module.
> All the channel values are expressed in terms of mV. Channel 13
> and channel 14 are reserved. There are channels which represent
> temperature and current. Even they output raw voltage in mV.
> 
Why ?

> Signed-off-by: Keerthy 
> ---
> 
> The previous discussion concluded in keeping the generic ADC
> functionality and the hwmon separate. The discussion can be found here:
> 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html
> 
>  Documentation/hwmon/twl4030-madc-hwmon |   45 +
>  drivers/hwmon/Kconfig  |   10 ++
>  drivers/hwmon/Makefile |1 +
>  drivers/hwmon/twl4030-madc-hwmon.c |  155 
> 
>  4 files changed, 211 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/hwmon/twl4030-madc-hwmon
>  create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c
> 
> diff --git a/Documentation/hwmon/twl4030-madc-hwmon 
> b/Documentation/hwmon/twl4030-madc-hwmon
> new file mode 100644
> index 000..2cf1cc2
> --- /dev/null
> +++ b/Documentation/hwmon/twl4030-madc-hwmon
> @@ -0,0 +1,45 @@
> +Kernel driver twl4030-madc
> +=
> +
> +Supported chips:
> + * Texas Instruments TWL4030
> + Prefix: 'twl4030-madc'
> +
> +
> +Authors:
> + J Keerthy 
> +
> +Description
> +---
> +
> +The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among
> +other things it contains a 10-bit A/D converter MADC. The converter has 16
> +channels which can be used in different modes.
> +
> +
> +See this table for the meaning of the different channels
> +
> +Channel Signal
> +--
> +0Battery type(BTYPE)
> +1BCI: Battery temperature (BTEMP)
> +2GP analog input
> +3GP analog input
> +4GP analog input
> +5GP analog input
> +6GP analog input
> +7GP analog input
> +8BCI: VBUS voltage(VBUS)
> +9Backup Battery voltage (VBKP)
> +10   BCI: Battery charger current (ICHG)
> +11   BCI: Battery charger voltage (VCHG)
> +12   BCI: Main battery voltage (VBAT)
> +13   Reserved
> +14   Reserved
> +15   VRUSB Supply/Speaker left/Speaker right polarization level
> +
> +
> +The Sysfs nodes will represent the voltage in the units of mV,
> +the temperature channel shows the converted raw voltage in mV.
> +The Battery charging current channel represents raw voltage mV.

Doesn't really make sense to me to export values known to be current and 
temperature
as voltages. You'll have to add a lot more information for that to make sense.

> +Channel 13 and 14 are reserved.

You already said that above.

> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 773e484..11ddde3 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -940,6 +940,16 @@ config SENSORS_TMP421
> This driver can also be built as a module.  If so, the module
> will be called tmp421.
>  
> +config SENSORS_TWL4030_MADC
> + tristate "Texas Instruments TWL4030 MADC Hwmon"
> + depends on TWL4030_MADC
> + help
> + This driver provides hwmon support for triton TWL4030-MADC.
> + This driver can be built as part of kernel or can be built
> + as a module.

Kernel is obvious. Please stick with the usual text

"This driver can also be built as a module.  If so, the module
 will be called "

At least please tell users how the module is named.

> + This driver exposes the various voltage values to
> + the user space.
> +
Not sure if this provides any value. Either case, it should be before "built as 
module".

>  config SENSORS_VIA_CPUTEMP
>   tristate "VIA CPU temperature sensor"
>   depends on X86
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index dde02d9..bc7d740 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -102,6 +102,7 @@ obj-$(CONFIG_SENSORS_THMC50)  += thmc50.o
>  obj-$(CONFIG_SENSORS_TMP102) += tmp102.o
>  obj-$(CONFIG_SENSORS_TMP401) += tmp401.o
>  obj-$(CONFIG_SENSORS_TMP421) += tmp421.o
> +obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o
>  obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
>  obj-$(CONFIG_SENSORS_VIA686A)+= via686a.o
>  obj-$(CONFIG_SENSORS_VT1211) += vt1211.o
> diff --git a/drivers/hwmon/twl4030-madc-hwmon.c 
> b/drivers/hwmon/twl4030-madc-hwmon.c
> new file mode 100644
> index 000..4a61e8a
> --- /dev/null
> +++ b/drivers/hwmon/twl4030-madc-hwmon.c
> @@ -0,0 +1,155 @@
> +/*
> + *
> + * TWL4030 MADC Hwmon driver-This driver monitors the real time
> + * conversion of analog signals like battery temperature,
> + * battery type, battery level etc. User can ask for the conversion on a
> + * particular channel using the sysfs nodes.
> + *
> + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/

2011 ?

> + * J Kee

Re: [PATCH 0/2] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Tomi Valkeinen
On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:
> On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:

> > And I found:
> > 
> > http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
> > 
> > It looks like 24bpp display.
> > 
> 
> Ok I looked through the datasheet and it looks to me that i got
> the .config field right. Only thing that's vague from that sheet is
> which pixel clock edge the v-sync and h-sync are driven low and the
> color distortion is still there with either option.
> 
> > What kind of color distortion do you see? Perhaps the problem is
> > somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> > signal setting in .config field. This info should be in the panel
> > datasheet, but it usually takes some deciphering to understand it =).
> > 
> >  Tomi
> > 
> 
> I'm seeing a light cyan tint to everything when running at 24bpp. Using
> 16 datalines causes a heavy blue tint.

But with 24 datalines and 16 bpp it works? Sounds strange =). 

One thing to check are the pinmuxings (or pad configuration, as it's
called in omap3 trm).

Are you using 2.6.37 or newer kernel?

Is this also happening with other devkit8000 devices, so it's not just a
broken device?

Have you tried with an image with full red, green and blue areas, to see
if only certain colors are affected? 

And the last option is of course get a scope and see what's going on in
the datalines.

 Tomi


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


RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption

2011-02-16 Thread Santosh Shilimkar
> -Original Message-
> From: catalin.mari...@gmail.com [mailto:catalin.mari...@gmail.com]
> On Behalf Of Catalin Marinas
> Sent: Wednesday, February 16, 2011 9:24 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Andrei Warkentin; Kevin
> Hilman; t...@atomide.com; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way
> operation can cause data corruption
>
> On 15 February 2011 07:14, Santosh Shilimkar
>  wrote:
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
> >
> >  config PL310_ERRATA_588369
> >        bool "Clean & Invalidate maintenance operations do not
> invalidate
> > clean lines"
> > -       depends on CACHE_L2X0 && ARCH_OMAP4
> > +       depends on CACHE_L2X0 && CACHE_PL310
>
> It can just depend on CACHE_PL310 as this depends on CACHE_L2X0.
>
Ok.
> > +config PL310_ERRATA_727915
> > +       bool "Background Clean & Invalidate by Way operation can
> cause
> > data corruption"
> > +       depends on CACHE_L2X0 && CACHE_PL310
>
> Same here.
>
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -45,7 +45,10 @@ config ARCH_OMAP4
> >        select CPU_V7
> >        select ARM_GIC
> >        select LOCAL_TIMERS
> > +       select CACHE_L2X0
>
> CACHE_L2X0 has a long dependency list. You could add ARCH_OMAP4 in
> there or just change the other platforms to select a
> HAVE_CACHE_L2X0.
> Ideally we would like this option to be selectable in config just in
> case you want to debug some issues.
>
I will add ARCH_OMAP4 under CACHE_L2X0.

> > --- a/arch/arm/mach-omap2/omap4-common.c
> > +++ b/arch/arm/mach-omap2/omap4-common.c
> > @@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)
> >        omap_smc1(0x102, 0x0);
> >  }
> >
> > +static void omap4_l2x0_set_debug(unsigned long val)
> > +{
> > +       /* Program PL310 L2 Cache controller debug register */
> > +       omap_smc1(0x100, val);
> > +}
>
> This part together with the Kconfig changes for OMAP4 could be a
> separate patch, OMAP-specific.
>
Agree. I will split this patch and repost.

> The rest seems fine.

Thanks for the feedback.

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


Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption

2011-02-16 Thread Catalin Marinas
On 15 February 2011 07:14, Santosh Shilimkar  wrote:
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
>
>  config PL310_ERRATA_588369
>        bool "Clean & Invalidate maintenance operations do not invalidate
> clean lines"
> -       depends on CACHE_L2X0 && ARCH_OMAP4
> +       depends on CACHE_L2X0 && CACHE_PL310

It can just depend on CACHE_PL310 as this depends on CACHE_L2X0.

> +config PL310_ERRATA_727915
> +       bool "Background Clean & Invalidate by Way operation can cause
> data corruption"
> +       depends on CACHE_L2X0 && CACHE_PL310

Same here.

> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -45,7 +45,10 @@ config ARCH_OMAP4
>        select CPU_V7
>        select ARM_GIC
>        select LOCAL_TIMERS
> +       select CACHE_L2X0

CACHE_L2X0 has a long dependency list. You could add ARCH_OMAP4 in
there or just change the other platforms to select a HAVE_CACHE_L2X0.
Ideally we would like this option to be selectable in config just in
case you want to debug some issues.

> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)
>        omap_smc1(0x102, 0x0);
>  }
>
> +static void omap4_l2x0_set_debug(unsigned long val)
> +{
> +       /* Program PL310 L2 Cache controller debug register */
> +       omap_smc1(0x100, val);
> +}

This part together with the Kconfig changes for OMAP4 could be a
separate patch, OMAP-specific.

The rest seems fine.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe 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: [3/4] OMAP: DSS2: Adding macro for DISPC_DIVISOR register

2011-02-16 Thread Tomi Valkeinen
On Thu, 2011-02-03 at 14:09 +, Raghuveer Murthy wrote:
> Added macro for DISPC_DIVISOR. This is different from DISPC_DIVISOR1 and
> DISPC_DIVISOR2. OMAP4 supports all the above 3 registers.
> 
> DISPC_DIVISOR1 and DISPC_DIVISOR2 registers are accessed through
> DISPC_DIVISORo(ch) macro
> 
> Signed-off-by: Raghuveer Murthy 
> 
> ---
> drivers/video/omap2/dss/dispc.c |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index e52a413..6225d12 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -132,6 +132,17 @@ struct dispc_reg { u16 idx; };
>  
>  #define DISPC_VID_PRELOAD(n) DISPC_REG(0x230 + (n)*0x04)
>  
> +/*
> + * The OMAP4 DISPC_DIVISOR1 is backward compatible to OMAP3xxx DISPC_DIVISOR.
> + * However DISPC_DIVISOR is also provided in OMAP4, to control 
> DISPC_CORE_CLK.
> + * This allows DISPC_CORE_CLK to be independent of logical clock dividers 
> (lcd)
> + * of LCD1 (primary) and LCD2 (secondary) displays.
> + *
> + * To derive pixel clocks for Primary and Secondary LCD channels, configure 
> the
> + * lcd and pcd in DISPC_DIVISOR1 and DISPC_DIVISOR2 respectively, using the
> + * DISPC_DIVISORo(ch).
> + */
> +#define DISPC_DIVISORDISPC_REG(0x0804)
>  
>  #define DISPC_IRQ_MASK_ERROR(DISPC_IRQ_GFX_FIFO_UNDERFLOW | \
>DISPC_IRQ_OCP_ERR | \

See my comment about comments in previous mail.

I think you should merge this and the next patch. There's not much point
in adding a single line define, which is not used (yet).

How about the debug output from debug/omapdss/clk file? Does it print
sensible things on OMAP4 after these patches?

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe 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] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Daniel Morsing
On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:
> On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:
> > Hi Tomi
> > 
> > On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> > > Hi,
> > > 
> > > On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > > > The panel added is the 4.3 inch display that is sold with the
> > > > Devkit8000.
> > > 
> > > Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> > > board file. Why do you want to use 16 bpp format for that?
> > > 
> > >  Tomi
> > > 
> > 
> > Running the panel at 24 bpp or specifying 16 datalines causes color
> > distortion.
> > 
> > The only way I've been able to run the panel without color distortion,
> > is with 24 datalines and 16 bpp.
> > 
> > I'm not well versed in displays, so I might be making a mistake
> > somewhere. The BSP for the devkit8000 doesn't include a datasheet for
> > the panel, so I can't look into what's causing this weirdness.
> 
> I don't think I'll add a feature which doesn't make sense, to fix a
> problem we don't understand =).
> 
> A datasheet I found mentions
> 
> "One 4.3” TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
> Model)"
> 
> And I found:
> 
> http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf
> 
> It looks like 24bpp display.
> 

Ok I looked through the datasheet and it looks to me that i got
the .config field right. Only thing that's vague from that sheet is
which pixel clock edge the v-sync and h-sync are driven low and the
color distortion is still there with either option.

> What kind of color distortion do you see? Perhaps the problem is
> somewhere else, like wrong horizontal sync, vertical sync or pixel clock
> signal setting in .config field. This info should be in the panel
> datasheet, but it usually takes some deciphering to understand it =).
> 
>  Tomi
> 

I'm seeing a light cyan tint to everything when running at 24bpp. Using
16 datalines causes a heavy blue tint.

Regards,
Daniel Morsing




--
To unsubscribe from this list: send the line "unsubscribe 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: [2/4] OMAP: DSS2: Renaming register macro DISPC_DIVISOR(ch)

2011-02-16 Thread Tomi Valkeinen
Hi,

On Thu, 2011-02-03 at 14:09 +, Raghuveer Murthy wrote:
> Renamed DISPC_DIVISOR(ch) to DISPC_DIVISORo(ch), to facilitate introduction
> of DISPC_DIVISOR register, which is specific for OMAP4. OMAP4 has 3 registers
> DISPC_DIVISOR, DISPC_DIVISOR1 and DISPC_DIVISOR2.
> 
> Also updated, all the usages of DISPC_DIVISOR(ch) to DISPC_DIVISORo(ch).
> 
> OMAP4 TRM uses DISPC_DIVISORo generically to refer to DISPC_DIVISOR1 and
> DISPC_DIVISOR2
> 
> Signed-off-by: Raghuveer Murthy 
> 
> ---
> drivers/video/omap2/dss/dispc.c |   31 ++-
>  1 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index cc58208..e52a413 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -72,7 +72,12 @@ struct dispc_reg { u16 idx; };
>  #define DISPC_TIMING_H(ch)   DISPC_REG(ch != 2 ? 0x0064 : 0x0400)
>  #define DISPC_TIMING_V(ch)   DISPC_REG(ch != 2 ? 0x0068 : 0x0404)
>  #define DISPC_POL_FREQ(ch)   DISPC_REG(ch != 2 ? 0x006C : 0x0408)
> -#define DISPC_DIVISOR(ch)DISPC_REG(ch != 2 ? 0x0070 : 0x040C)
> +/*
> + * Use DISPC_DIVISORo(ch) when DISPC_DIVISOR1 or DISPC_DIVISOR2 has to be
> + * configured. OMAP4 TRM uses DISPC_DIVISORo generically to refer 
> DISPC_DIVISOR1
> + * and DISPC_DIVISOR2
> + */

While comments are good, I think this is extra. The purpose of the
register is clear from TRM. I like to keep the code clean of
trivialities =). The same goes for the register comment in the next
patch also.

You could mention this in the patch description though, so that patch
reviewing is easier.

And about DISPC_DIVISORo, I think the TRM writer has typoed it, he meant
to write DISPC_DIVISORi =). But let's stick with the naming from TRM.

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe 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 2/2] omap3: devkit8000: Add and use 4.3 inch display

2011-02-16 Thread Thomas Weber
Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:
> This patch adds a generic panel entry for the 4.3 inch display that is
> sold with the devkit8000 and modifies the board file to use this
> display.
> 
> Signed-off-by: Daniel Morsing 
> ---
> Note that this patch depends on the previous one in the series.
> 
>  arch/arm/mach-omap2/board-devkit8000.c   |2 +-
>  drivers/video/omap2/displays/panel-generic-dpi.c |   26 
> ++
>  2 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
> b/arch/arm/mach-omap2/board-devkit8000.c
> index 9a2a31e..6dab13e 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -148,7 +148,7 @@ static struct regulator_consumer_supply 
> devkit8000_vio_supply =
>   REGULATOR_SUPPLY("vcc", "spi2.0");
>  
>  static struct panel_generic_dpi_data lcd_panel = {
> - .name   = "generic",
> + .name   = "devkit_43",
>   .platform_enable= devkit8000_panel_enable_lcd,
>   .platform_disable   = devkit8000_panel_disable_lcd,
>  };
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
> b/drivers/video/omap2/displays/panel-generic-dpi.c
> index b52a28f..ee9e7ea 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -83,6 +83,32 @@ static struct panel_config generic_dpi_panels[] = {
>   .name   = "generic",
>   },
>  
> + /* Devkit8000 4.3 Inch display */
> + {
> + {
> + .x_res  = 480,
> + .y_res  = 272,
> +
> + .pixel_clock= 1,
> +
> + .hfp= 2,
> + .hsw= 41,
> + .hbp= 2,
> +
> + .vfp= 2,
> + .vsw= 10,
> + .vbp= 2,
> + },
> + .acbi   = 0x0,
> + .acb= 0x0,
> + .recommended_bpp= 16,
> + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS,
> + .power_on_delay = 50,
> + .power_off_delay= 100,
> + .name   = "devkit_43",
> + },
> +
>   /* Sharp LQ043T1DG01 */
>   {
>   {

can you try these settings.
I have these settings from other users of the 4.3 inch display.
I think only the pixel clock is a little bit slower.


//.name = "4.3inch_LCD",
.x_res  = 480,
.y_res  = 272,
.hsw= 41,   /* hsync_len (4) - 1 */
.hfp= 2,/* right_margin (4) - 1 */
.hbp= 2,/* left_margin (40) - 1 */
.vsw= 10,   /* vsync_len (2) - 1 */
.vfp= 2,/* lower_margin */
.vbp= 2,/* upper_margin (8) - 1 */
.pixel_clock= 9600,

Regards,
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 0/2] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Tomi Valkeinen
On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:
> Hi Tomi
> 
> On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> > Hi,
> > 
> > On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > > The panel added is the 4.3 inch display that is sold with the
> > > Devkit8000.
> > 
> > Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> > board file. Why do you want to use 16 bpp format for that?
> > 
> >  Tomi
> > 
> 
> Running the panel at 24 bpp or specifying 16 datalines causes color
> distortion.
> 
> The only way I've been able to run the panel without color distortion,
> is with 24 datalines and 16 bpp.
> 
> I'm not well versed in displays, so I might be making a mistake
> somewhere. The BSP for the devkit8000 doesn't include a datasheet for
> the panel, so I can't look into what's causing this weirdness.

I don't think I'll add a feature which doesn't make sense, to fix a
problem we don't understand =).

A datasheet I found mentions

"One 4.3” TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
Model)"

And I found:

http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf

It looks like 24bpp display.

What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).

 Tomi


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


Re: [PATCH v2] OMAP: PM: DMA: Enable runtime pm

2011-02-16 Thread G, Manjunath Kondaiah
Hi Kevin,

On Mon, Feb 14, 2011 at 02:06:53PM -0800, Kevin Hilman wrote:
> "G, Manjunath Kondaiah"  writes:
> 
> > From: Manjunath G Kondaiah 
> >
> > Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put_autosuspend
> > for OMAP DMA driver.
> >
> > The DMA driver uses auto suspend feature of runtime pm framework through
> > which the clock gets disabled automatically if there is no activity for
> > more than one second.
> >
> > Testing:
> > Compile: omap1_defconfig and omap2plus_defconfig
> > Boot: OMAP1710(H3), OMAP2420(H4), OMAP3630(Zoom3), OMAP4(Blaze)
> 
> The normal DMA tests should also be run on these platforms.  Based on
> the above, I can't tell any DMA tests were run.   Based on my tests,
> this isn't working for chained xfers.
> 
> Using the runtime PM sysfs interface, you can check the runtime status
> of the device:
> 
> # cat /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status   
>
> 
> It should show 'active' during transfer, and after timeout expires it
> will show 'suspended'.
> 
> Doing some tests using my dmatest module:
> 
>   git://gitorious.org/omap-test/dmatest.git
> 
> I noticed that it gets stuck in 'active' and never gets suspended when I
> used DMA channel linking (load module using 'linking=1' as load-time option)
> 
> I'm not sure exactly why, but I will guess that the reason is that there
> is an imbalance in get/put calls when using chaining, since 'get' is
> only called once upon omap_start_dma() but 'put' is called for every
> channel in the callback.

Even I noticed this after running chaining test case and checking
runtime status. But, I am wondering even with 'active' runtime status, 
the core hits off and retention.

The complete log which has all the sequences of running chaining tests,
enabling off mode and checking runtime status is available at:
http://pastebin.com/YEHMEXUP

Though I agree on the point that, it is mismatch with get/put calls with
DMA chaining, I still need to analyze this in detail.

The other thing which is not considered here is, the get_sync is called
inside start_dma only(request_dma will call get_sync and put after the
getting requested channel). After request_dma and start_dma, there are
API's called by user(dma_set_params, priority etc) which also require
get_sync since those API's will access configuration registers. I am
wondering if have get_sync and put in all the API's, this might result
in over loading. 

> 
> > On zoom3 core retention is tested with following steps:
> > echo 1 > /debug/pm_debug/sleep_while_idle
> > echo 1 > /debug/pm_debug/enable_off_mode
> > echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> > echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> > echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> > echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
> >
> > It is observed that(on pm branch), core retention count gets increasing if 
> > the
> > board is left idle for more than 5 seconds. However, it doesnot enter off 
> > mode
> > (even without DMA runtime changes).
> 
> What silicon rev is on your Zoom3?  
It's 3630 ES1.0. 
> Mainline kernels now disable core off-mode for 3630 revs < ES2.1 due to 
> erratum 
>i583.
> 
> If this happens, you should see something like this on the console:
> 
>Core OFF disabled due to errata i583
> 
We can observe above message in mainline after enabling cpu idle in
omap2plus_defconfig.

I switched to zoom2 and able to hit core retention and
off mode with mainline.

-Manjunath

--
To unsubscribe from this list: send the line "unsubscribe 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] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Daniel Morsing
Hi Tomi

On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:
> Hi,
> 
> On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> > The panel added is the 4.3 inch display that is sold with the
> > Devkit8000.
> 
> Hmm. Devkit8000's panel is connected with 24 datalines, according to the
> board file. Why do you want to use 16 bpp format for that?
> 
>  Tomi
> 

Running the panel at 24 bpp or specifying 16 datalines causes color
distortion.

The only way I've been able to run the panel without color distortion,
is with 24 datalines and 16 bpp.

I'm not well versed in displays, so I might be making a mistake
somewhere. The BSP for the devkit8000 doesn't include a datasheet for
the panel, so I can't look into what's causing this weirdness.

Regards,
Daniel Morsing

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


Re: [RESEND][PATCH v2] OMAP: DSS: Adding two APIs for panel-taal: check_timings and set_timings

2011-02-16 Thread Tomi Valkeinen
Hi,

On Wed, 2011-02-16 at 07:54 -0600, Janorkar, Mayuresh wrote:
> check_timings and set_timings APIS are not present for panel-taal.
> 
> OMAPFB provides a bootarg omapfb.mode for setting mode parameters which 
> include display,
> resolution, bits-per-pixel.
> 
> OMAPFB expects panel driver to have check_timings and set_timings APIs.
> These are checked by omapfb in case we wish to set default mode through 
> bootargs.
> e.g.: omapfb.mode="lcd:864x480-16" (display device:width X height - bits per 
> pixel)
> 
> omapfb_set_def_mode function in omapfb-main.c essentially needs these 
> functions
> otherwise it would return -EINVAL and default mode sent through bootargs
> would be ignored.

I don't like this patch. You cannot change the timings for Taal, so
those added functions look quite hacky.

The reason for this patch isn't clear from the description (it should).
If I guess correctly, the point of the patch is to be able to change the
default color format via boot arguments when using taal panel?

If so, I think the change should be in the omapfb driver. Perhaps the
omapfb driver should:

1. check if check_timings & set_timings exist
2. if they do exist, do the same thing as the code does now
3. if they don't, use get_timings to verify that the given resolution is
correct

That wouldn't be perfect either, but I guess it should do the job. But
this is again something where FB framework and OMAP HW do not quite
match, and we end up with hacky solution, no matter what we do. But we
can try to keep the hacks in the omapfb driver =).

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe 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: [4/7 v2] usb: otg: OMAP4430: Add phy_suspend function pointer to

2011-02-16 Thread Hema Kalliguddi
Hi,

>-Original Message-
>From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
>Sent: Wednesday, February 16, 2011 5:07 PM
>To: Hema Kalliguddi
>Cc: Sergei Shtylyov; linux-...@vger.kernel.org;
>linux-omap@vger.kernel.org; Felipe Balbi; Tony Lindgren
>Subject: Re: [4/7 v2] usb: otg: OMAP4430: Add phy_suspend
>function pointer to
>
>Hello.
>
>On 16-02-2011 8:14, Hema Kalliguddi wrote:
>
 From: Kalliguddi, Hema
>
 Introduce the .phy_suspend function pointer to
>>> twl4030_usb_data structure.
 assign the function to it for both sdp board and panda boards.
 This will be used by the twl6030-usb transceiver driver.
>
 Signed-off-by: Hema HK
 Cc: Felipe Balbi
 Cc: Tony Lindgren
>
>>> [...]
>
 Index: linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
 ===
 --- linux-2.6.orig/arch/arm/mach-omap2/board-4430sdp.c
 +++ linux-2.6/arch/arm/mach-omap2/board-4430sdp.c
 @@ -272,6 +272,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit   = omap4430_phy_exit,
.phy_power  = omap4430_phy_power,
.phy_set_clock  = omap4430_phy_set_clk,
 +  .phy_suspend= omap4430_phy_suspend,
};

static struct omap2_hsmmc_info mmc[] = {
 Index: linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
 ===
 --- linux-2.6.orig/arch/arm/mach-omap2/board-omap4panda.c
 +++ linux-2.6/arch/arm/mach-omap2/board-omap4panda.c
 @@ -153,6 +153,7 @@ static struct twl4030_usb_data omap4_usb
.phy_exit   = omap4430_phy_exit,
.phy_power  = omap4430_phy_power,
.phy_set_clock  = omap4430_phy_set_clk,
 +  .phy_suspend= omap4430_phy_suspend,
};

static struct omap2_hsmmc_info mmc[] = {
 Index: linux-2.6/arch/arm/plat-omap/include/plat/usb.h
 ===
 --- linux-2.6.orig/arch/arm/plat-omap/include/plat/usb.h
 +++ linux-2.6/arch/arm/plat-omap/include/plat/usb.h
 @@ -88,6 +88,7 @@ extern int omap4430_phy_power(struct dev
extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
 +extern int omap4430_phy_suspend(struct device *dev, int suspend);
>
>>> I think this *extern* declaration should be a part of the
>>> previous patch.
>
>> What is the problem if extern when using?
>
>I think 'extern' declaration should be in the same place
>where this
>function is defined, else you're just defining an unused
>function. Same goes
>for the 'phy_suspend' initializers...
>
#endif

 Index: linux-2.6/include/linux/i2c/twl.h
 ===
 --- linux-2.6.orig/include/linux/i2c/twl.h
 +++ linux-2.6/include/linux/i2c/twl.h
 @@ -600,6 +600,8 @@ struct twl4030_usb_data {
int (*phy_power)(struct device
>*dev, int iD, int on);
/* enable/disable  phy clocks */
int (*phy_set_clock)(struct device
>*dev, int on);
 +  /* suspend/resume of phy */
 +  int (*phy_suspend)(struct device *dev, int suspend);
};
>
>>> I'd make the above the only change in this patch, and add
>>> all the other
>>> changes into the previous patch (which then I'd change places
>>> with that one).
>
>> No. if I do that git bisect fails.
>
>How in the world it will fail?
>
>> Initializer does not make any sense without function
>poointer declaration.
>
>I said "which then I'd changed places with that one", i.e.
>put this patch
>first and the previous patch second. Otherwise, you're just
>doing things
>beckwards: first you define the method implementation, and
>then you declare
>the method itself... it should be vice versa.
>

I understand that. I will change it and send the patches.

Regards,
Hema

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


RE: [PATCH 0/3] OMAP2+ hwmod fixes

2011-02-16 Thread Rajendra Nayak
Hi Benoit,

> -Original Message-
> From: Cousson, Benoit [mailto:b-cous...@ti.com]
> Sent: Wednesday, February 16, 2011 6:37 PM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; p...@pwsan.com;
linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/3] OMAP2+ hwmod fixes
>
> Hi Rajendra,
>
> On 2/16/2011 1:11 PM, Nayak, Rajendra wrote:
> > This series fixes some hwmod api return values
> > and also adds some state checks.
> > The hwmod iterator functions are made to
> > continue and not break if one of the
> > callback functions ends up with an error.
>
> By doing that, you change the behavior of this function.
> I'm not sure I fully understand why.
> Could you elaborate on the use case?

Since these functions iterate over all hwmods
calling a common callback function, there might
be cases wherein the callback function for *some*
hwmods might fail. For instance, if you run through
all hwmods and try to clear the context registers
for all of them, for some hwmods which might
not have context registers the callback function
might return a -EINVAL, however that should not
stop you from attempting to clear the context
registers for the rest of the hwmods which have
them and abort the function midway, no?
This is more hypothetical, however the real usecase
that prompted me with this patch was when I
had some wrong state check in _setup function,
and the iterator would stop with the first failure
and not even attempt to setup the rest of the
hwmods.

>
> To avoid that behavior in the past, I was just returning
> 0 in case of failure to avoid stopping the iteration.
> It looks like you do not want to stop the iteration but still
> retrieve the error.
> I do not see in this series what you plan to do with the
> error at the end of the iteration.

Most users of these iterators would just use the non-zero
return value to throw an error/warning out stating there
were failures running through all the callback functions.
That does not change with this patch, and they can still
do it.

Regards,
Rajendra

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


[RESEND][PATCH v2] OMAP: DSS: Adding two APIs for panel-taal: check_timings and set_timings

2011-02-16 Thread Mayuresh Janorkar
check_timings and set_timings APIS are not present for panel-taal.

OMAPFB provides a bootarg omapfb.mode for setting mode parameters which include 
display,
resolution, bits-per-pixel.

OMAPFB expects panel driver to have check_timings and set_timings APIs.
These are checked by omapfb in case we wish to set default mode through 
bootargs.
e.g.: omapfb.mode="lcd:864x480-16" (display device:width X height - bits per 
pixel)

omapfb_set_def_mode function in omapfb-main.c essentially needs these functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.

Signed-off-by: Mayuresh Janorkar 
---
 drivers/video/omap2/displays/panel-taal.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 61026f9..aded08c 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,31 @@ static void taal_get_timings(struct omap_dss_device 
*dssdev,
*timings = dssdev->panel.timings;
 }
 
+static void taal_set_timings(struct omap_dss_device *dssdev,
+   struct omap_video_timings *timings)
+{
+   /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+   dssdev->panel.timings.x_res = timings->x_res;
+   dssdev->panel.timings.y_res = timings->y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+   struct omap_video_timings *timings)
+{
+   /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+   if (!timings || timings->x_res != dssdev->panel.timings.x_res ||
+   timings->y_res != dssdev->panel.timings.y_res)
+   return -EINVAL;
+
+   return 0;
+}
+
 static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
 {
@@ -1563,6 +1588,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
 
.get_timings= taal_get_timings,
+   .set_timings= taal_set_timings,
+   .check_timings  = taal_check_timings,
 
.driver = {
.name   = "taal",
-- 
1.7.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 0/2] Add recommended bpp for omap dss2 generic dpi panels

2011-02-16 Thread Tomi Valkeinen
Hi,

On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:
> This series adds a mechanism for specifying a recommended bpp for
> generic dss2 dpi panels and adds a panel that uses this feature.
> 
> The panel added is the 4.3 inch display that is sold with the
> Devkit8000.

Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe 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/3] OMAP2+ hwmod fixes

2011-02-16 Thread Cousson, Benoit

Hi Rajendra,

On 2/16/2011 1:11 PM, Nayak, Rajendra wrote:

This series fixes some hwmod api return values
and also adds some state checks.
The hwmod iterator functions are made to
continue and not break if one of the
callback functions ends up with an error.


By doing that, you change the behavior of this function.
I'm not sure I fully understand why.
Could you elaborate on the use case?

To avoid that behavior in the past, I was just returning
0 in case of failure to avoid stopping the iteration.
It looks like you do not want to stop the iteration but still
retrieve the error.
I do not see in this series what you plan to do with the
error at the end of the iteration.

Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe 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 2/2] OMAP: PM: implement devices wakeup latency constraints APIs

2011-02-16 Thread Pihet-XID, Jean
Hi Vishwa,

On Wed, Feb 16, 2011 at 11:49 AM, Vishwanath Sripathy
 wrote:
>> -Original Message-
>> From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
>> Sent: Tuesday, February 15, 2011 7:22 PM
>> To: Vishwanath Sripathy
>> Cc: Kevin Hilman; p...@pwsan.com; Vibhore Vardhan; Santosh
>> Shilimkar; Rajendra Nayak; linux-omap@vger.kernel.org; Jean Pihet-XID
>> Subject: Re: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
>> constraints APIs
>>
>> Hi Vishwa,
>>
>> On Tue, Feb 15, 2011 at 10:35 AM, Vishwanath Sripathy
>>  wrote:
>> >> -Original Message-
>> >> From: jean.pi...@newoldbits.com
>> [mailto:jean.pi...@newoldbits.com]
>> >> Sent: Friday, February 11, 2011 12:53 AM
>> >> To: khil...@ti.com; p...@pwsan.com; Vibhore Vardhan; Santosh
>> >> Shilimkar; Vishwanath BS; rna...@ti.com
>> >> Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
>> >> Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
>> >> constraints APIs
>> >>
>> >> From: Jean Pihet 
>> >>
>> >> Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API
>> by
>> >> creating similar APIs at the omap_device and omap_hwmod levels.
>> The
>> >> omap_hwmod level call is the layer with access to the powerdomain
>> >> core, so it is the place where the powerdomain is queried to set and
>> >> release the constraints.
>> >>
>> >> NOTE: only works for devices which have been converted to use
>> >>       omap_device/omap_hwmod.
>> >>
>> >> Longer term, we could possibly remove this API from the OMAP PM
>> layer,
>> >> and instead directly use the omap_device level API.
>> >>
>> >> Based on Vibhore's original patch , adapted to omap_device and
>> >> omap_hwmod frameworks.
>> >>
>> >> Signed-off-by: Jean Pihet 
>> >> Cc: Vibhore Vardhan 
>> >> ---
>> >>  arch/arm/mach-omap2/omap_hwmod.c              |   62
>> +-
>> >>  arch/arm/mach-omap2/powerdomain.c             |  176
>> >> -
>> >>  arch/arm/mach-omap2/powerdomain.h             |   31 +
>> >>  arch/arm/mach-omap2/powerdomains3xxx_data.c   |   60
>> >> +
>> >>  arch/arm/plat-omap/include/plat/omap_device.h |    2 +
>> >>  arch/arm/plat-omap/include/plat/omap_hwmod.h  |    2 +
>> >>  arch/arm/plat-omap/omap-pm-constraints.c      |  101 ++
>> -
>> >>  arch/arm/plat-omap/omap_device.c              |   28 
>> >>  8 files changed, 399 insertions(+), 63 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-
>> >> omap2/omap_hwmod.c
>> >> index e282e35..0dc096f 100644
>> >> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> >> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> >> @@ -142,6 +142,7 @@
>> >>  #include "powerdomain.h"
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>  #include 
>> >>
>> >>  #include "cm2xxx_3xxx.h"
>> >> @@ -2198,10 +2199,69 @@ ohsps_unlock:
>> >>  }
>> >>
>> >>  /**
>> >> + * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
>> >> constraint
>> >> + * @oh: struct omap_hwmod *
>> >> + * @req_oh: struct omap_hwmod *
>> > Need to explain what this parameters mean.
>> Ok, will add a description here. Basically oh corresponds to the
>> device (and so the power domain) to set a constraint on and req_oh is
>> the constraint requester. oh is used to determine which power domain
>> to set a constraint on, req_oh is used to record the requester for
>> later update or removal of a constraint.
>>
>> >> + * @t: wakeup latency constraint (us). -1 removes the existing
>> >> constraint
>> >> + *
>> >> + * Query the powerdomain of @oh to set/release the wake-up
>> >> constraint
>> >> + *
>> >> + * Returns -EINVAL if @oh or @req_oh have no power domain, or
>> the
>> >> return
>> >> + * code from the pwrdm function
>> >> (pwrdm_wakeuplat_set/release_constraint)
>> >> + * of the powerdomain assocated with @oh.
>> >> + */
>> >> +int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
>> >> *req_oh,
>> >> +                                   struct omap_hwmod *oh, long t)
>> >> +{
>> >> +     struct device *req_dev;
>> >> +     struct platform_device *pdev;
>> >> +     struct powerdomain *pwrdm;
>> >> +     int ret = 0;
>> >> +
>> >> +     pwrdm = omap_hwmod_get_pwrdm(oh);
>> >> +
>> >> +     /* Catch devices with undefined powerdomains */
>> >> +     if (!pwrdm) {
>> >> +             pr_err("omap_hwmod: Error: could not find parent "
>> >> +                     "powerdomain for %s\n", oh->name);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +
>> >> +     pdev = &(req_oh->od->pdev);
>> >> +     if (pdev == NULL) {
>> >> +             pr_err("omap_hwmod: Error: pdev not found for oh
>> %s\n",
>> >> +                    oh->name);
>> >> +             return -EINVAL;
>> >> +     }
>> >> +
>> >> +     req_dev = &(pdev->dev);
>> >> +     if (req_dev == NULL) {
>> >> +             pr_err("omap_hwmod: Error: device not found for oh
>> >> %s\n",
>> >> +                    oh->name);
>> >> +             return -EINVAL;
>> >> +     }
>> > If I understand correctly, req_dev

[PATCH v10 02/11] OMAP2420: hwmod data: add dmtimer

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Add dmtimer data.

Signed-off-by: Thara Gopinath 
Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  634 
 arch/arm/plat-omap/include/plat/dmtimer.h  |   11 +
 2 files changed, 645 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 7fffd34..837c9df 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 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -318,6 +319,625 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
 };
 
+/* Timer Common */
+static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_timer_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap2420_timer_sysc,
+   .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap2420_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer1_mpu_irqs[] = {
+   { .irq = 37, },
+};
+
+static struct omap_hwmod_addr_space omap2420_timer1_addrs[] = {
+   {
+   .pa_start   = 0x48028000,
+   .pa_end = 0x48028000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__timer1 = {
+   .master = &omap2420_l4_wkup_hwmod,
+   .slave  = &omap2420_timer1_hwmod,
+   .clk= "gpt1_ick",
+   .addr   = omap2420_timer1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_timer1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2420_timer1_slaves[] = {
+   &omap2420_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap2420_timer1_hwmod = {
+   .name   = "timer1",
+   .mpu_irqs   = omap2420_timer1_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_timer1_mpu_irqs),
+   .main_clk   = "gpt1_fck",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+   .module_offs = WKUP_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+   },
+   },
+   .slaves = omap2420_timer1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_timer1_slaves),
+   .class  = &omap2420_timer_hwmod_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
+};
+
+/* timer2 */
+static struct omap_hwmod omap2420_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2420_timer2_mpu_irqs[] = {
+   { .irq = 38, },
+};
+
+static struct omap_hwmod_addr_space omap2420_timer2_addrs[] = {
+   {
+   .pa_start   = 0x4802a000,
+   .pa_end = 0x4802a000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -> timer2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__timer2 = {
+   .master = &omap2420_l4_core_hwmod,
+   .slave  = &omap2420_timer2_hwmod,
+   .clk= "gpt2_ick",
+   .addr   = omap2420_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap2420_timer2_slaves[] = {
+   &omap2420_l4_core__timer2,
+};
+
+/* timer2 hwmod */
+static struct omap_hwmod omap2420_timer2_hwmod = {
+   .name   = "timer2",
+   .mpu_irqs   = omap2420_timer2_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_timer2_mpu_irqs),
+   .main_clk   = "gpt2_fck",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_GPT2_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
+   },
+   },
+   .slaves = omap2420_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_timer2_slaves),
+   .class  = &omap2420_timer_hwmod_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2

[PATCH v10 06/11] OMAP1: dmtimer: conversion to platform devices

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Convert OMAP1 dmtimers into a platform devices and then registers with
device model framework so that it can be bound to corresponding driver.

Signed-off-by: Thara Gopinath 
Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap1/Makefile  |2 +-
 arch/arm/mach-omap1/dmtimer.c |  214 +
 arch/arm/mach-omap1/timer32k.c|4 -
 arch/arm/plat-omap/dmtimer.c  |   64 +
 arch/arm/plat-omap/include/plat/dmtimer.h |   24 +++-
 5 files changed, 246 insertions(+), 62 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dmtimer.c

diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index af98117..a0ae35f 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := io.o id.o sram.o time.o irq.o mux.o flash.o serial.o devices.o dma.o
-obj-y += clock.o clock_data.o opp_data.o reset.o
+obj-y += clock.o clock_data.o opp_data.o reset.o dmtimer.o
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
diff --git a/arch/arm/mach-omap1/dmtimer.c b/arch/arm/mach-omap1/dmtimer.c
new file mode 100644
index 000..d1e17fe
--- /dev/null
+++ b/arch/arm/mach-omap1/dmtimer.c
@@ -0,0 +1,214 @@
+/**
+ * OMAP1 Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which internally
+ * generates timer device information and registers with linux
+ * device model. It also has low level function to chnage the timer
+ * input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma 
+ * Thara Gopinath 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define OMAP1610_GPTIMER1_BASE 0xfffb1400
+#define OMAP1610_GPTIMER2_BASE 0xfffb1c00
+#define OMAP1610_GPTIMER3_BASE 0xfffb2400
+#define OMAP1610_GPTIMER4_BASE 0xfffb2c00
+#define OMAP1610_GPTIMER5_BASE 0xfffb3400
+#define OMAP1610_GPTIMER6_BASE 0xfffb3c00
+#define OMAP1610_GPTIMER7_BASE 0xfffb7400
+#define OMAP1610_GPTIMER8_BASE 0xfffbd400
+
+#define OMAP1_DM_TIMER_COUNT   8
+
+#define OMAP_TIMER_OCP_CFG_REG 0x10
+#define OMAP_TIMER_SYS_STAT_REG0x14
+#define OMAP_TIMER_IF_CTRL_REG 0x40
+
+static int omap1_dm_timer_set_src(struct platform_device *pdev,
+   int source)
+{
+   int n = (pdev->id - 1) << 1;
+   u32 l;
+
+   l = omap_readl(MOD_CONF_CTRL_1) & ~(0x03 << n);
+   l |= source << n;
+   omap_writel(l, MOD_CONF_CTRL_1);
+
+   return 0;
+}
+
+static void omap1_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
+{
+   int c;
+   struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+
+   c = 0;
+   while (!(pdata->dm_timer_read_reg(timer, OMAP_TIMER_SYS_STAT_REG) & 1)) 
{
+   c++;
+   if (c > 10) {
+   printk(KERN_ERR "Timer failed to reset.\n");
+   return;
+   }
+   }
+}
+
+static void omap1_dm_timer_reset(struct omap_dm_timer *timer)
+{
+   u32 l;
+   struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+
+   if (timer->pdev->id != 1) {
+   pdata->dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+   omap1_dm_timer_wait_for_reset(timer);
+   }
+
+   l = pdata->dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG);
+   l |= 0x02 << 3;  /* Set to smart-idle mode */
+   l |= 0x2 << 8;   /* Set clock activity to perserve f-clock on idle */
+   pdata->dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l);
+}
+
+int __init omap1_dm_timer_init(void)
+{
+   int i;
+   int ret;
+   struct dmtimer_platform_data *pdata;
+   struct platform_device *pdev;
+
+   if (!cpu_is_omap16xx())
+   return 0;
+
+   for (i = 1; i <= OMAP1_DM_TIMER_COUNT; i++) {
+   struct resource res[2];
+   u32 base, irq;
+
+   switch (i) {
+   case 1:
+   base = OMAP1610_GPTIMER1_BASE;
+   irq = INT_1610_GPTIMER1;
+   break;
+   case 2:
+   base = OMAP1610_GPTIMER2_BASE;
+   irq = INT_1610_GPTIMER2;
+   break;
+   case 3:
+   base = OMAP161

[PATCH v10 07/11] OMAP2+: dmtimer: convert to platform devices

2011-02-16 Thread Tarun Kanti DebBarma
Add routines to converts dmtimers to platform devices. The device data
is obtained from hwmod database of respective platform and is registered
to device model after successful binding to driver. It also provides
provision to access timers during early boot when pm_runtime framework
is not completely up and running.

Signed-off-by: Tarun Kanti DebBarma 
Signed-off-by: Thara Gopinath 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/Makefile  |2 +-
 arch/arm/mach-omap2/dmtimer.c |  199 +
 2 files changed, 200 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dmtimer.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 742ca67..ce46e3d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o gpio.o dma.o wd_timer.o
+common.o gpio.o dma.o wd_timer.o dmtimer.o
 
 omap-2-3-common= irq.o sdrc.o
 hwmod-common   = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
new file mode 100644
index 000..00cebe9
--- /dev/null
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -0,0 +1,199 @@
+/**
+ * OMAP2+ Dual-Mode Timers - platform device registration
+ *
+ * Contains first level initialization routines which extracts timers
+ * information from hwmod database and registers with linux device model.
+ * It also has low level function to change the timer input clock source.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Tarun Kanti DebBarma 
+ * Thara Gopinath 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * OMAP4 IP revision has different register offsets
+ * for interrupt registers and functional registers.
+ */
+#define VERSION2_TIMER_WAKEUP_EN_REG_OFFSET0x14
+#define VERSION2_TIMER_STAT_REG_OFFSET 0x10
+
+static int early_timer_count __initdata = 1;
+
+struct dm_timer_data {
+   struct omap_device *od;
+   struct dmtimer_platform_data *pdata;
+   struct list_head node;
+};
+
+static __initdata LIST_HEAD(dm_timer_data_list);
+
+/**
+ * omap2_dm_timer_set_src - change the timer input clock source
+ * @pdev:  timer platform device pointer
+ * @timer_clk: current clock source
+ * @source:array index of parent clock source
+ */
+static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
+{
+   int ret;
+   struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
+   struct clk *fclk = clk_get(&pdev->dev, "fck");
+   struct clk *new_fclk;
+   char *fclk_name = "32k_ck"; /* default name */
+
+   switch (source) {
+   case OMAP_TIMER_SRC_SYS_CLK:
+   fclk_name = "sys_ck";
+   break;
+
+   case OMAP_TIMER_SRC_32_KHZ:
+   fclk_name = "32k_ck";
+   break;
+
+   case OMAP_TIMER_SRC_EXT_CLK:
+   if (pdata->timer_ip_type == OMAP_TIMER_IP_VERSION_1) {
+   fclk_name = "alt_ck";
+   break;
+   }
+   dev_err(&pdev->dev, "%s: %d: invalid clk src.\n",
+   __func__, __LINE__);
+   return -EINVAL;
+   }
+
+   if (IS_ERR_OR_NULL(fclk)) {
+   dev_err(&pdev->dev, "%s: %d: clk_get() FAILED\n",
+   __func__, __LINE__);
+   return -EINVAL;
+   }
+
+   new_fclk = clk_get(&pdev->dev, fclk_name);
+   if (IS_ERR_OR_NULL(new_fclk)) {
+   dev_err(&pdev->dev, "%s: %d: clk_get() %s FAILED\n",
+   __func__, __LINE__, fclk_name);
+   clk_put(fclk);
+   return -EINVAL;
+   }
+
+   ret = clk_set_parent(fclk, new_fclk);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(&pdev->dev, "%s: clk_set_parent() to %s FAILED\n",
+   __func__, fclk_name);
+   ret = -EINVAL;
+   }
+
+   clk_put(new_fclk);
+   clk_put(fclk);
+
+   return ret;
+}
+
+struct omap_device_pm_latency omap2_dmtimer_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
+
+/**
+ * omap_timer_init - build and register timer device with an
+ * associated time

[PATCH v10 08/11] OMAP: dmtimer: platform driver

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Add dmtimer platform driver functions which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function

Signed-off-by: Tarun Kanti DebBarma 
Signed-off-by: Thara Gopinath 
Acked-by: Cousson, Benoit 
---
 arch/arm/plat-omap/dmtimer.c  |  167 -
 arch/arm/plat-omap/include/plat/dmtimer.h |2 +
 2 files changed, 168 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 1bfaf09..bfe6fd3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -257,7 +260,8 @@ static struct omap_dm_timer *dm_timers;
 static const char **dm_source_names;
 static struct clk **dm_source_clocks;
 
-static spinlock_t dm_timer_lock;
+static LIST_HEAD(omap_timer_list);
+static DEFINE_SPINLOCK(dm_timer_lock);
 
 /*
  * Reads timer registers in posted and non-posted mode. The posted mode bit
@@ -689,6 +693,167 @@ int omap_dm_timers_active(void)
 }
 EXPORT_SYMBOL_GPL(omap_dm_timers_active);
 
+/**
+ * omap_dm_timer_probe - probe function called for every registered device
+ * @pdev:  pointer to current timer platform device
+ *
+ * Called by driver framework at the end of device registration for all
+ * timer devices.
+ */
+static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
+{
+   int ret;
+   unsigned long flags;
+   struct omap_dm_timer *timer;
+   struct resource *mem, *irq, *ioarea;
+   struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
+
+   if (!pdata) {
+   dev_err(&pdev->dev, "%s: no platform data\n", __func__);
+   return -ENODEV;
+   }
+
+   spin_lock_irqsave(&dm_timer_lock, flags);
+   list_for_each_entry(timer, &omap_timer_list, node)
+   if (!pdata->is_early_init && timer->id == pdev->id) {
+   timer->pdev = pdev;
+   spin_unlock_irqrestore(&dm_timer_lock, flags);
+   dev_dbg(&pdev->dev, "Regular Probed\n");
+   return 0;
+   }
+   spin_unlock_irqrestore(&dm_timer_lock, flags);
+
+   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (unlikely(!irq)) {
+   dev_err(&pdev->dev, "%s: no IRQ resource\n", __func__);
+   ret = -ENODEV;
+   goto err_free_pdev;
+   }
+
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (unlikely(!mem)) {
+   dev_err(&pdev->dev, "%s: no memory resource\n", __func__);
+   ret = -ENODEV;
+   goto err_free_pdev;
+   }
+
+   ioarea = request_mem_region(mem->start, resource_size(mem),
+   pdev->name);
+   if (!ioarea) {
+   dev_err(&pdev->dev, "%s: region already claimed\n", __func__);
+   ret = -EBUSY;
+   goto err_free_pdev;
+   }
+
+   timer = kzalloc(sizeof(struct omap_dm_timer), GFP_KERNEL);
+   if (!timer) {
+   dev_err(&pdev->dev, "%s: no memory for omap_dm_timer\n",
+   __func__);
+   ret = -ENOMEM;
+   goto err_release_ioregion;
+   }
+
+   timer->io_base = ioremap(mem->start, resource_size(mem));
+   if (!timer->io_base) {
+   dev_err(&pdev->dev, "%s: ioremap failed\n", __func__);
+   ret = -ENOMEM;
+   goto err_free_mem;
+   }
+
+   /*
+* Following func pointers are required by OMAP1's reset code
+* in mach-omap1/dmtimer.c to access to low level read/write.
+*/
+   if (pdata->is_omap16xx) {
+   pdata->dm_timer_read_reg = omap_dm_timer_read_reg;
+   pdata->dm_timer_write_reg = omap_dm_timer_write_reg;
+   pdata->is_early_init = 0;
+   }
+
+   timer->id = pdev->id;
+   timer->irq = irq->start;
+   timer->pdev = pdev;
+   timer->reserved = 0;
+
+   /* add the timer element to the list */
+   spin_lock_irqsave(&dm_timer_lock, flags);
+   list_add_tail(&timer->node, &omap_timer_list);
+   spin_unlock_irqrestore(&dm_timer_lock, flags);
+
+   dev_dbg(&pdev->dev, "Early Probed\n");
+
+   return 0;
+
+err_free_mem:
+   kfree(timer);
+
+err_release_ioregion:
+   release_mem_region(mem->start, resource_size(mem));
+
+err_free_pdev:
+   kfree(pdata);
+   platform_device_unregister(pdev);
+
+   return ret;
+}
+
+/**
+ * omap_dm_timer_remove - cleanup a registered timer device
+ * @pdev:  pointer to current timer platform device
+ *
+ * Called by driver framework whenever a timer device is unregistered.
+ * In addition to freeing platform resources it also deletes the timer
+ * entry from the local list.
+ */
+static int __devexit omap_dm_timer_remove(struct platform_device *pdev)
+{

[PATCH v10 09/11] OMAP: dmtimer: switch-over to platform device driver

2011-02-16 Thread Tarun Kanti DebBarma
switch-over to platform device driver through following changes:
(a) call to dmtimer initialization routine from timer-gp.c is
removed (b) initiate dmtimer early initialization from omap2_init_common_hw
in io.c (c) modify plat-omap/dmtimer routines to use new register map and
platform data.

Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/clock2420_data.c  |2 +-
 arch/arm/mach-omap2/clock2430_data.c  |2 +-
 arch/arm/mach-omap2/clock3xxx_data.c  |2 +-
 arch/arm/mach-omap2/clock44xx_data.c  |2 +-
 arch/arm/mach-omap2/dmtimer.c |   61 +
 arch/arm/mach-omap2/dmtimer.h |   30 +++
 arch/arm/mach-omap2/io.c  |3 +
 arch/arm/mach-omap2/timer-gp.c|1 -
 arch/arm/plat-omap/dmtimer.c  |  350 -
 arch/arm/plat-omap/include/plat/dmtimer.h |5 +-
 10 files changed, 190 insertions(+), 268 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dmtimer.h

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index ee93d3c..390d6aa 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1801,7 +1801,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL,   "virt_prcm_set", &virt_prcm_set, CK_242X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL,   "gpt1_ick", &gpt1_ick,  CK_242X),
-   CLK(NULL,   "gpt1_fck", &gpt1_fck,  CK_242X),
+   CLK("omap_timer.1", "fck",  &gpt1_fck,  CK_242X),
CLK(NULL,   "gpt2_ick", &gpt2_ick,  CK_242X),
CLK("omap_timer.2", "fck",  &gpt2_fck,  CK_242X),
CLK(NULL,   "gpt3_ick", &gpt3_ick,  CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index 24553ce..7a3e5a4 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1905,7 +1905,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL,   "virt_prcm_set", &virt_prcm_set, CK_243X),
/* general l4 interface ck, multi-parent functional clk */
CLK(NULL,   "gpt1_ick", &gpt1_ick,  CK_243X),
-   CLK(NULL,   "gpt1_fck", &gpt1_fck,  CK_243X),
+   CLK("omap_timer.1", "fck",  &gpt1_fck,  CK_243X),
CLK(NULL,   "gpt2_ick", &gpt2_ick,  CK_243X),
CLK("omap_timer.2", "fck",  &gpt2_fck,  CK_243X),
CLK(NULL,   "gpt3_ick", &gpt3_ick,  CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 524d995..f318115 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3374,7 +3374,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   "usbhost_ick",  &usbhost_ick,   CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK("ehci-omap.0",  "usbhost_ick",  &usbhost_ick,   CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
CLK(NULL,   "usim_fck", &usim_fck,  CK_3430ES2PLUS | 
CK_36XX),
-   CLK(NULL,   "gpt1_fck", &gpt1_fck,  CK_3XXX),
+   CLK("omap_timer.1", "fck",  &gpt1_fck,  CK_3XXX),
CLK(NULL,   "wkup_32k_fck", &wkup_32k_fck,  CK_3XXX),
CLK(NULL,   "gpio1_dbck",   &gpio1_dbck,CK_3XXX),
CLK("omap_wdt", "fck",  &wdt2_fck,  CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 11997a3..8f8b010 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3181,7 +3181,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   "smartreflex_core_fck", &smartreflex_core_fck,  
CK_443X),
CLK(NULL,   "smartreflex_iva_fck",  &smartreflex_iva_fck,   
CK_443X),
CLK(NULL,   "smartreflex_mpu_fck",  &smartreflex_mpu_fck,   
CK_443X),
-   CLK(NULL,   "gpt1_fck", &timer1_fck,
CK_443X),
+   CLK("omap_timer.1", "fck",  &timer1_fck,
CK_443X),
CLK("omap_timer.10","fck",  &timer10_fck,   
CK_443X),
CLK("omap_timer.11","fck",  &timer11_fck,   
CK_443X),
CLK("omap_timer.2", "fck",  &timer2_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/dmtimer.c b/arch/arm/mach-omap2/dmtimer.c
index 00cebe9..63d5ae7 100644
--- a/arch/arm/mach-omap2/dmtimer.c
+++ b/arch/arm/mach-omap2/dmtimer.c
@@ -197,3 +197,64 @@ static int __init omap_timer_init(struct omap_hwmod *oh, 
void *unused)
 
return ret;
 }
+
+/**
+ * omap2_dm_timer_early_init - top level early timer initialization
+ * called in the last part of omap2_init_common_hw
+ *
+ * Uses dedicated hwmod api to parse through hwmod database for
+ * given class name and then build

[PATCH v10 05/11] OMAP4: hwmod data: add dmtimer

2011-02-16 Thread Tarun Kanti DebBarma
From: Cousson, Benoit 

Add dmtimer data.

Signed-off-by: Cousson, Benoit 
Signed-off-by: Tarun Kanti DebBarma 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  623 
 arch/arm/plat-omap/include/plat/dmtimer.h  |2 +
 2 files changed, 625 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 873e976..6014a16 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -1900,6 +1901,615 @@ static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod 
= {
 };
 
 /*
+ * 'timer' class
+ * general purpose timer module with accurate 1ms tick
+ * This class contains several variants: ['timer_1ms', 'timer']
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+  SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_timer_1ms_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap44xx_timer_1ms_sysc,
+   .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  SIDLE_SMART_WKUP),
+   .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_timer_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap44xx_timer_sysc,
+   .rev = OMAP_TIMER_IP_VERSION_2,
+};
+
+/* timer1 */
+static struct omap_hwmod omap44xx_timer1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer1_irqs[] = {
+   { .irq = 37 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer1_addrs[] = {
+   {
+   .pa_start   = 0x4a318000,
+   .pa_end = 0x4a31807f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__timer1 = {
+   .master = &omap44xx_l4_wkup_hwmod,
+   .slave  = &omap44xx_timer1_hwmod,
+   .clk= "l4_wkup_clk_mux_ck",
+   .addr   = omap44xx_timer1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_timer1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
+   &omap44xx_l4_wkup__timer1,
+};
+
+static struct omap_hwmod omap44xx_timer1_hwmod = {
+   .name   = "timer1",
+   .class  = &omap44xx_timer_1ms_hwmod_class,
+   .mpu_irqs   = omap44xx_timer1_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_timer1_irqs),
+   .main_clk   = "timer1_fck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_WKUP_TIMER1_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_timer1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_timer1_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* timer2 */
+static struct omap_hwmod omap44xx_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_timer2_irqs[] = {
+   { .irq = 38 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_timer2_addrs[] = {
+   {
+   .pa_start   = 0x48032000,
+   .pa_end = 0x4803207f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_per -> timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__timer2 = {
+   .master = &omap44xx_l4_per_hwmod,
+   .slave  = &omap44xx_timer2_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap44xx_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_timer2_slaves[] = {
+   &omap44xx_l4_per__timer2,
+};
+
+static struct omap_hwmod omap44xx_timer2_hwmod = {
+   .name   = "timer2",
+   .class  = &omap44xx_timer_1ms_hwmod_class,
+   .mpu_irqs   = omap44xx_timer2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_timer2_irqs),
+   .main_clk   = "timer2_fck",
+   .prcm =

[PATCH v10 11/11] OMAP: dmtimer: add timeout to low-level routines

2011-02-16 Thread Tarun Kanti DebBarma
The low-level read and write access routines wait on
write-pending register in posted mode to make sure that
previous write is complete on respective registers.
This waiting is done in an infinite while loop. Now it
is being modified to use timeout instead.

Signed-off-by: Tarun Kanti DebBarma 
Reviewed-by: Varadarajan, Charulatha 
Acked-by: Cousson, Benoit 
---
 arch/arm/plat-omap/dmtimer.c |   33 +
 1 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index fcac422..a39d5ba 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* register offsets */
 #define _OMAP_TIMER_ID_OFFSET  0x00
@@ -153,6 +154,8 @@
 #define OMAP_TIMER_TICK_INT_MASK_COUNT_REG \
(_OMAP_TIMER_TICK_INT_MASK_COUNT_OFFSET | (WP_TOWR << WPSHIFT))
 
+#define MAX_WRITE_PEND_WAIT1 /* 10ms timeout delay */
+
 static LIST_HEAD(omap_timer_list);
 static DEFINE_SPINLOCK(dm_timer_lock);
 
@@ -168,16 +171,23 @@ static DEFINE_SPINLOCK(dm_timer_lock);
 static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, u32 reg)
 {
struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+   int i = 0;
 
if (reg >= OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata->func_offset;
else if (reg >= OMAP_TIMER_STAT_REG)
reg += pdata->intr_offset;
 
-   if (timer->posted)
-   while (readl(timer->io_base + (OMAP_TIMER_WRITE_PEND_REG & 
0xff))
-   & (reg >> WPSHIFT))
-   cpu_relax();
+   if (timer->posted) {
+   omap_test_timeout(!(readl(timer->io_base +
+   ((OMAP_TIMER_WRITE_PEND_REG +
+   pdata->func_offset) & 0xff)) & (reg >> WPSHIFT)),
+   MAX_WRITE_PEND_WAIT, i);
+
+   if (WARN_ON_ONCE(i == MAX_WRITE_PEND_WAIT))
+   pr_err(": read timeout\n");
+   }
+
return readl(timer->io_base + (reg & 0xff));
 }
 
@@ -195,16 +205,23 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer 
*timer, u32 reg,
u32 value)
 {
struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+   int i = 0;
 
if (reg >= OMAP_TIMER_WAKEUP_EN_REG)
reg += pdata->func_offset;
else if (reg >= OMAP_TIMER_STAT_REG)
reg += pdata->intr_offset;
 
-   if (timer->posted)
-   while (readl(timer->io_base + (OMAP_TIMER_WRITE_PEND_REG & 
0xff))
-   & (reg >> WPSHIFT))
-   cpu_relax();
+   if (timer->posted) {
+   omap_test_timeout(!(readl(timer->io_base +
+   ((OMAP_TIMER_WRITE_PEND_REG +
+   pdata->func_offset) & 0xff)) & (reg >> WPSHIFT)),
+   MAX_WRITE_PEND_WAIT, i);
+
+   if (WARN_ON(i == MAX_WRITE_PEND_WAIT))
+   pr_err(": write timeout\n");
+   }
+
writel(value, timer->io_base + (reg & 0xff));
 }
 
-- 
1.6.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 6/6 v7] usb: musb: Using runtime pm APIs for musb.

2011-02-16 Thread Sergei Shtylyov

Hello.

On 16-02-2011 15:28, Hema HK wrote:


Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings.



Enable clock, configure no-idle/standby when active and configure force 
idle/standby
and disable clock when idled. This is taken care by the runtime framework when
driver calls the pm_runtime_get_sync and pm_runtime_put_sync APIs.
Need to configure MUSB into force standby and force idle mode when usb not used



Signed-off-by: Hema HK 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Kevin Hilman 
Cc: Cousson, Benoit 
Cc: Paul Walmsley 

[...]


Index: linux-2.6/drivers/usb/musb/omap2430.c
===
--- linux-2.6.orig/drivers/usb/musb/omap2430.c
+++ linux-2.6/drivers/usb/musb/omap2430.c

[...]

@@ -498,8 +463,10 @@ static int omap2430_suspend(struct devic
omap2430_low_level_exit(musb);
otg_set_suspend(musb->xceiv, 1);
omap2430_save_context(musb);
-   clk_disable(glue->clk);

+   if (!pm_runtime_suspended(dev))
+   if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_suspend)


   Could be collapsed into single *if*...


+   dev->bus->pm->runtime_suspend(dev);


   The above line is over-indented.


return 0;
  }

@@ -507,13 +474,10 @@ static int omap2430_resume(struct device
  {
struct omap2430_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
-   int ret;

-   ret = clk_enable(glue->clk);
-   if (ret) {
-   dev_err(dev, "faled to enable clock\n");
-   return ret;
-   }
+   if (!pm_runtime_suspended(dev))
+   if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_resume)


   Could be collapsed into single *if*...


+   dev->bus->pm->runtime_resume(dev);

omap2430_low_level_init(musb);
omap2430_restore_context(musb);


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


[PATCH v10 04/11] OMAP3: hwmod data: add dmtimer

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Add dmtimer data.

Signed-off-by: Thara Gopinath 
Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  649 
 1 files changed, 649 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 800eda4..3b36cf8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -422,6 +423,640 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
 };
 
+/* timer class */
+static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+   SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap3xxx_timer_1ms_sysc,
+   .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
+  SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_timer_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap3xxx_timer_sysc,
+   .rev =  OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap3xxx_timer1_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_timer1_mpu_irqs[] = {
+   { .irq = 37, },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_timer1_addrs[] = {
+   {
+   .pa_start   = 0x48318000,
+   .pa_end = 0x48318000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__timer1 = {
+   .master = &omap3xxx_l4_wkup_hwmod,
+   .slave  = &omap3xxx_timer1_hwmod,
+   .clk= "gpt1_ick",
+   .addr   = omap3xxx_timer1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_timer1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap3xxx_timer1_slaves[] = {
+   &omap3xxx_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap3xxx_timer1_hwmod = {
+   .name   = "timer1",
+   .mpu_irqs   = omap3xxx_timer1_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_timer1_mpu_irqs),
+   .main_clk   = "gpt1_fck",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP3430_EN_GPT1_SHIFT,
+   .module_offs = WKUP_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP3430_ST_GPT1_SHIFT,
+   },
+   },
+   .slaves = omap3xxx_timer1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_timer1_slaves),
+   .class  = &omap3xxx_timer_1ms_hwmod_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
+/* timer2 */
+static struct omap_hwmod omap3xxx_timer2_hwmod;
+static struct omap_hwmod_irq_info omap3xxx_timer2_mpu_irqs[] = {
+   { .irq = 38, },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_timer2_addrs[] = {
+   {
+   .pa_start   = 0x49032000,
+   .pa_end = 0x49032000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_per -> timer2 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_per__timer2 = {
+   .master = &omap3xxx_l4_per_hwmod,
+   .slave  = &omap3xxx_timer2_hwmod,
+   .clk= "gpt2_ick",
+   .addr   = omap3xxx_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap3xxx_timer2_slaves[] = {
+   &omap3xxx_l4_per__timer2,
+};
+
+/* timer2 hwmod */
+static struct omap_hwmod omap3xxx_timer2_hwmod = {
+   .name   = "timer2",
+   .mpu_irqs   = omap3xxx_timer2_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_timer2_mpu_irqs),
+   .main_clk

[PATCH v10 10/11] OMAP: dmtimer: pm_runtime support

2011-02-16 Thread Tarun Kanti DebBarma
Add pm_runtime support to dmtimer. Since dmtimer is used during
early boot before pm_runtime is initialized completely there are
provisions to enable/disable clocks directly in the code during
early boot.

Signed-off-by: Tarun Kanti DebBarma 
[p-bas...@ti.com: added pm_runtime logic in probe()]
Signed-off-by: Partha Basak 
Reviewed-by: Varadarajan, Charulatha 
Acked-by: Cousson, Benoit 
---
 arch/arm/plat-omap/dmtimer.c |   63 --
 1 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 53f5205..fcac422 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -211,13 +212,16 @@ static void omap_dm_timer_prepare(struct omap_dm_timer 
*timer)
 {
struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
 
-   timer->fclk = clk_get(&timer->pdev->dev, "fck");
-   if (WARN_ON_ONCE(IS_ERR_OR_NULL(timer->fclk))) {
-   dev_err(&timer->pdev->dev, ": No fclk handle.\n");
-   return;
+   if (!pdata->is_omap16xx) {
+   timer->fclk = clk_get(&timer->pdev->dev, "fck");
+   if (WARN_ON_ONCE(IS_ERR_OR_NULL(timer->fclk))) {
+   dev_err(&timer->pdev->dev, ": No fclk handle.\n");
+   return;
+   }
}
 
-   omap_dm_timer_enable(timer);
+   if (!pdata->is_omap16xx)
+   omap_dm_timer_enable(timer);
 
if (pdata->dm_timer_reset)
pdata->dm_timer_reset(timer);
@@ -292,10 +296,22 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_free);
 
 void omap_dm_timer_enable(struct omap_dm_timer *timer)
 {
+   struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+
if (timer->enabled)
return;
 
-   clk_enable(timer->fclk);
+   if (unlikely(pdata->is_early_init)) {
+   clk_enable(timer->fclk);
+   timer->enabled = 1;
+   return;
+   }
+
+   if (pm_runtime_get_sync(&timer->pdev->dev) < 0) {
+   dev_err(&timer->pdev->dev, "%s: pm_runtime_get_sync() FAILED\n",
+   __func__);
+   return;
+   }
 
timer->enabled = 1;
 }
@@ -303,10 +319,22 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
 
 void omap_dm_timer_disable(struct omap_dm_timer *timer)
 {
+   struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
+
if (!timer->enabled)
return;
 
-   clk_disable(timer->fclk);
+   if (unlikely(pdata->is_early_init)) {
+   clk_disable(timer->fclk);
+   timer->enabled = 0;
+   return;
+   }
+
+   if (pm_runtime_put_sync(&timer->pdev->dev) < 0) {
+   dev_err(&timer->pdev->dev, "%s: pm_runtime_put_sync() FAILED\n",
+   __func__);
+   return;
+   }
 
timer->enabled = 0;
 }
@@ -425,10 +453,12 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
if (source < 0 || source >= 3)
return -EINVAL;
 
-   omap_dm_timer_disable(timer);
+   if (!pdata->is_omap16xx)
+   omap_dm_timer_disable(timer);
/* change the timer clock source */
ret = pdata->set_timer_src(timer->pdev, source);
-   omap_dm_timer_enable(timer);
+   if (!pdata->is_omap16xx)
+   omap_dm_timer_enable(timer);
 
/*
 * When the functional clock disappears, too quick writes seem
@@ -600,11 +630,26 @@ static int __devinit omap_dm_timer_probe(struct 
platform_device *pdev)
return -ENODEV;
}
 
+   /*
+* OMAP2+
+* Early timers are already registered and in list.
+* What we need to do during second phase of probe
+* is to assign the newly allocated/configured pdev
+* to timer->pdev. We also call pm_runtime_enable()
+* for each device because it could not be called
+* during early boot because pm_runtime framework
+* was not yet up and running.
+*/
spin_lock_irqsave(&dm_timer_lock, flags);
list_for_each_entry(timer, &omap_timer_list, node)
if (!pdata->is_early_init && timer->id == pdev->id) {
timer->pdev = pdev;
spin_unlock_irqrestore(&dm_timer_lock, flags);
+   pm_runtime_enable(&pdev->dev);
+   /* update PM runtime for active early timers */
+   if (timer->reserved)
+   pm_runtime_get_sync(&pdev->dev);
+
dev_dbg(&pdev->dev, "Regular Probed\n");
return 0;
}
-- 
1.6.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
M

[PATCH v10 03/11] OMAP2430: hwmod data: add dmtimer

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Add dmtimer data.

Signed-off-by: Thara Gopinath 
Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  633 
 1 files changed, 633 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 60fe4aa..728ea0d 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 
 #include 
 #include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -336,6 +337,624 @@ static struct omap_hwmod omap2430_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
 };
 
+/* Timer Common */
+static struct omap_hwmod_class_sysconfig omap2430_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_timer_hwmod_class = {
+   .name = "timer",
+   .sysc = &omap2430_timer_sysc,
+   .rev = OMAP_TIMER_IP_VERSION_1,
+};
+
+/* timer1 */
+static struct omap_hwmod omap2430_timer1_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer1_mpu_irqs[] = {
+   { .irq = 37, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer1_addrs[] = {
+   {
+   .pa_start   = 0x49018000,
+   .pa_end = 0x49018000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -> timer1 */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__timer1 = {
+   .master = &omap2430_l4_wkup_hwmod,
+   .slave  = &omap2430_timer1_hwmod,
+   .clk= "gpt1_ick",
+   .addr   = omap2430_timer1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_timer1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer1 slave port */
+static struct omap_hwmod_ocp_if *omap2430_timer1_slaves[] = {
+   &omap2430_l4_wkup__timer1,
+};
+
+/* timer1 hwmod */
+static struct omap_hwmod omap2430_timer1_hwmod = {
+   .name   = "timer1",
+   .mpu_irqs   = omap2430_timer1_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_timer1_mpu_irqs),
+   .main_clk   = "gpt1_fck",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_GPT1_SHIFT,
+   .module_offs = WKUP_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_GPT1_SHIFT,
+   },
+   },
+   .slaves = omap2430_timer1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_timer1_slaves),
+   .class  = &omap2430_timer_hwmod_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
+/* timer2 */
+static struct omap_hwmod omap2430_timer2_hwmod;
+static struct omap_hwmod_irq_info omap2430_timer2_mpu_irqs[] = {
+   { .irq = 38, },
+};
+
+static struct omap_hwmod_addr_space omap2430_timer2_addrs[] = {
+   {
+   .pa_start   = 0x4802a000,
+   .pa_end = 0x4802a000 + SZ_1K - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_core -> timer2 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__timer2 = {
+   .master = &omap2430_l4_core_hwmod,
+   .slave  = &omap2430_timer2_hwmod,
+   .clk= "gpt2_ick",
+   .addr   = omap2430_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* timer2 slave port */
+static struct omap_hwmod_ocp_if *omap2430_timer2_slaves[] = {
+   &omap2430_l4_core__timer2,
+};
+
+/* timer2 hwmod */
+static struct omap_hwmod omap2430_timer2_hwmod = {
+   .name   = "timer2",
+   .mpu_irqs   = omap2430_timer2_mpu_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_timer2_mpu_irqs),
+   .main_clk   = "gpt2_fck",
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP24XX_EN_GPT2_SHIFT,
+   .module_offs = CORE_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
+   },
+   },
+   .slaves = omap2430_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_timer2_slaves),
+   .class  = &omap2430_timer_hwmod_class,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
+/* timer3 */
+static struct omap_hwmod om

[PATCH v10 01/11] OMAP2+: dmtimer: add device names to flck nodes

2011-02-16 Thread Tarun Kanti DebBarma
From: Thara Gopinath 

Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.

NOTE: gpt1_fck is modified in patch-10 when we switch to platform device
driver. This is to make sure that each patch compiles and boots.

Signed-off-by: Tarun Kanti DebBarma 
Acked-by: Cousson, Benoit 
---
 arch/arm/mach-omap2/clock2420_data.c |   58 +++--
 arch/arm/mach-omap2/clock2430_data.c |   58 +++--
 arch/arm/mach-omap2/clock3xxx_data.c |   46 --
 arch/arm/mach-omap2/clock44xx_data.c |   42 ++--
 4 files changed, 161 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index 0a992bc..ee93d3c 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1803,27 +1803,27 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL,   "gpt1_ick", &gpt1_ick,  CK_242X),
CLK(NULL,   "gpt1_fck", &gpt1_fck,  CK_242X),
CLK(NULL,   "gpt2_ick", &gpt2_ick,  CK_242X),
-   CLK(NULL,   "gpt2_fck", &gpt2_fck,  CK_242X),
+   CLK("omap_timer.2", "fck",  &gpt2_fck,  CK_242X),
CLK(NULL,   "gpt3_ick", &gpt3_ick,  CK_242X),
-   CLK(NULL,   "gpt3_fck", &gpt3_fck,  CK_242X),
+   CLK("omap_timer.3", "fck",  &gpt3_fck,  CK_242X),
CLK(NULL,   "gpt4_ick", &gpt4_ick,  CK_242X),
-   CLK(NULL,   "gpt4_fck", &gpt4_fck,  CK_242X),
+   CLK("omap_timer.4", "fck",  &gpt4_fck,  CK_242X),
CLK(NULL,   "gpt5_ick", &gpt5_ick,  CK_242X),
-   CLK(NULL,   "gpt5_fck", &gpt5_fck,  CK_242X),
+   CLK("omap_timer.5", "fck",  &gpt5_fck,  CK_242X),
CLK(NULL,   "gpt6_ick", &gpt6_ick,  CK_242X),
-   CLK(NULL,   "gpt6_fck", &gpt6_fck,  CK_242X),
+   CLK("omap_timer.6", "fck",  &gpt6_fck,  CK_242X),
CLK(NULL,   "gpt7_ick", &gpt7_ick,  CK_242X),
-   CLK(NULL,   "gpt7_fck", &gpt7_fck,  CK_242X),
+   CLK("omap_timer.7", "fck",  &gpt7_fck,  CK_242X),
CLK(NULL,   "gpt8_ick", &gpt8_ick,  CK_242X),
-   CLK(NULL,   "gpt8_fck", &gpt8_fck,  CK_242X),
+   CLK("omap_timer.8", "fck",  &gpt8_fck,  CK_242X),
CLK(NULL,   "gpt9_ick", &gpt9_ick,  CK_242X),
-   CLK(NULL,   "gpt9_fck", &gpt9_fck,  CK_242X),
+   CLK("omap_timer.9", "fck",  &gpt9_fck,  CK_242X),
CLK(NULL,   "gpt10_ick",&gpt10_ick, CK_242X),
-   CLK(NULL,   "gpt10_fck",&gpt10_fck, CK_242X),
+   CLK("omap_timer.10","fck",  &gpt10_fck, CK_242X),
CLK(NULL,   "gpt11_ick",&gpt11_ick, CK_242X),
-   CLK(NULL,   "gpt11_fck",&gpt11_fck, CK_242X),
+   CLK("omap_timer.11","fck",  &gpt11_fck, CK_242X),
CLK(NULL,   "gpt12_ick",&gpt12_ick, CK_242X),
-   CLK(NULL,   "gpt12_fck",&gpt12_fck, CK_242X),
+   CLK("omap_timer.12","fck",  &gpt12_fck, CK_242X),
CLK("omap-mcbsp.1", "ick",  &mcbsp1_ick,CK_242X),
CLK("omap-mcbsp.1", "fck",  &mcbsp1_fck,CK_242X),
CLK("omap-mcbsp.2", "ick",  &mcbsp2_ick,CK_242X),
@@ -1878,6 +1878,42 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL,   "pka_ick",  &pka_ick,   CK_242X),
CLK(NULL,   "usb_fck",  &usb_fck,   CK_242X),
CLK("musb-hdrc","fck",  &osc_ck,CK_242X),
+   CLK("omap_timer.1", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.2", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.3", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.4", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.5", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.6", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.7", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.8", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.9", "32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.10","32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.11","32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.12","32k_ck",   &func_32k_ck,   CK_243X),
+   CLK("omap_timer.1", "sys_ck",   &sys_ck,CK_243X),
+   CLK("omap_timer.2", "sys_ck",   &sys_ck,CK_243X),
+   CLK("omap_timer.3", "sys_ck",   &sys_ck,CK_243X),
+   CLK("omap_timer.4", "sys_ck",   &sys_ck,CK_243X),
+   CLK("omap_timer.5"

[PATCH v10 00/11] dmtimer adaptation to platform_driver

2011-02-16 Thread Tarun Kanti DebBarma
dmtimer adaptation to platform_driver.

This patch series is adaptation of dmtimer code to platform driver
using omap_device and omap_hwmod abstraction.

Baseline:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Branch: master

Test Platforms:
OMAP1710
OMAP2420
OMAP2430
OMAP3430
OMAP3630
OMAP4430

Test Info:
(1) Tested request, enable, disable, clock source configuration, start,
stop, free of timers.
(2) Verified outputs of following commands
cat /sys/devices/platform/omap/omap_timer.*/power/runtime_status
cat /sys/devices/platform/omap/omap_timer.*/power/runtime_active_time
(2) OMAP3: Tested Retention and Off modes.
(3) Boot test on OMAP1710.

v10:
(1) Update PM runtime for active early timers so that PM runtime userspace
info is correct.
(2) Include code to configure timers to POSTED mode which got missed in
the previous version.
(3) Remove pm runtime_enable from OMAP1 specific code since this is not
applicable.

v9:
(1) In OMAP3 hwmod database, added entry for timer12 which was missing.
Beagle board uses timer12 as its millisecond timer.
(2) In OMAP3 hwmod database, rectified in-correct prcm configurations
for timer10 and timer11.
From:
   .prcm   = {
   .module_bit = OMAP24XX_EN_GPT10_SHIFT,
   .idlest_idle_bit = OMAP24XX_ST_GPT10_SHIFT,
   },
To:
   .prcm   = {
   .module_bit = OMAP3430_EN_GPT10_SHIFT,
   .idlest_idle_bit = OMAP3430_ST_GPT10_SHIFT,
   },
(3) In OMAP3 hwmod database, removed timer master port entry for all
timers because it is not supported.

static struct omap_hwmod_ocp_if *omap3xxx_timer7_masters[] = {
   &omap3xxx_l4_per__timer7,
};

(4) In OMAP4 hwmod database, added SIDLE_SMART_WKUP flag for
non-millisecond timers.
(5) In OMAP3 hwmod database, rectified sysconfig configuration for
non-millisecond timers.
From: omap_hwmod_sysc_type2 To: omap_hwmod_sysc_type1.
This was preventing system to go to RETENTION and OFF modes.

v8:
(1) Baselined on Tony's tree in omap-for-linus branch
(2) The last patch in v7 series has been removed because it is fixed
by following patch:
commit: 78f26e872f77b6312273216de1a8f836c6f2e143
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable

v7:
(1) In omap1_dm_timer_set_src(), the computation of shift value to respective
dmtimer clock source was corrected:
From:
int n = (pdev->id) << 1;
To:
int n = (pdev->id - 1) << 1;
This change is needed because dmtimer is indexed from 1 now instead of 0.
(2) In  omap1_dm_timer_init(void) memory resource end address chnaged:
From:
res[0].end = base + 0xff;
To:
res[0].end = base + 0x46;
This was causing request_mem_region() failure in driver probe().
(3) In the export APIs there are some calls which are not applicable to OMAP1.
They have been made conditional now. They include following calls:

timer->fclk = clk_get(&timer->pdev->dev, "fck");
omap_dm_timer_enable()
omap_dm_timer_disable()

(4) Remove usage of cpu_is_omap16xx() and instead a flag has been added in
struct dmtimer_platform_data {
...
u32 is_omap16xx:1;
}
This flag is set to 1 in mach-omap1/dmtimer.c and set to 0 in 
mach-omap2/dmtimer.c
This flag is used in plat-omap/dmtimer.c wherever it needs to distiguish 
omap16xx.
(5) Remove #include  from mach-omap1/dmtimer.c
(6) Instead of using macros like INT_24XX_GPTIMERx, use the numbers
directly in OMAP2420, OMAP2430 and OMAP3xxx hwmod database.
(7) pm_runtime_get_sync() and pm_runtime_put_sync() return value check modified
from positive to negative value:
if (pm_runtime_get_sync(...) < 0) {
...
}

v6:
(1) Removed reset functions to mach-omap1/dmtimer.c.
Access to reset function from plat-omap/dmtimer.c is provided by means
of function pointer.
(2) Remove multiple calls to omap_device_build() for registering timer devices
during early and regular initialization. Regular device registration is now done
by reading data from temporary list. This list is populated during early init
where timer data is read from hwmod database and corresponding memory allocated.
(3) kfree(pdata) under error condition since platform_device_unregister does
not free its pdata.
(4) Removed extra header inclusion in mach-omap2 and plat-omap
NOTE: omap_dm_timer. field could not be removed because during regular boot
there is no mechanism to match the current pdev with corresponding entry in the
timer list which was partially initialized during early boot.

v5:
(1) In mach-omap2/dmtimer.c merged the merged two different init functions
into a single one, viz: omap_timer_init(*oh, *user). Now this function is
used both during early init and later. The distinction is between the two
is made thriugh the *user field.
(2) Added timeout to low-level access routines in place of infinite while
loop which waits on write-pend register bit.
(3) Modified devices names from "omap-timer.x" to "omap_timer.x"
(4) Modified module description from "OMAP DUAL MODE TIMER DRIVER" to:
MODULE_DESCRIPTION("OMAP 

[PATCH 2/2] hwmon: twl4030: Hwmon Driver for TWL4030 MADC

2011-02-16 Thread Keerthy
This driver exposes the sysfs nodes of the TWL4030 MADC module.
All the channel values are expressed in terms of mV. Channel 13
and channel 14 are reserved. There are channels which represent
temperature and current. Even they output raw voltage in mV.

Signed-off-by: Keerthy 
---

The previous discussion concluded in keeping the generic ADC
functionality and the hwmon separate. The discussion can be found here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html

 Documentation/hwmon/twl4030-madc-hwmon |   45 +
 drivers/hwmon/Kconfig  |   10 ++
 drivers/hwmon/Makefile |1 +
 drivers/hwmon/twl4030-madc-hwmon.c |  155 
 4 files changed, 211 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/hwmon/twl4030-madc-hwmon
 create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c

diff --git a/Documentation/hwmon/twl4030-madc-hwmon 
b/Documentation/hwmon/twl4030-madc-hwmon
new file mode 100644
index 000..2cf1cc2
--- /dev/null
+++ b/Documentation/hwmon/twl4030-madc-hwmon
@@ -0,0 +1,45 @@
+Kernel driver twl4030-madc
+=
+
+Supported chips:
+   * Texas Instruments TWL4030
+   Prefix: 'twl4030-madc'
+
+
+Authors:
+   J Keerthy 
+
+Description
+---
+
+The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among
+other things it contains a 10-bit A/D converter MADC. The converter has 16
+channels which can be used in different modes.
+
+
+See this table for the meaning of the different channels
+
+Channel Signal
+--
+0  Battery type(BTYPE)
+1  BCI: Battery temperature (BTEMP)
+2  GP analog input
+3  GP analog input
+4  GP analog input
+5  GP analog input
+6  GP analog input
+7  GP analog input
+8  BCI: VBUS voltage(VBUS)
+9  Backup Battery voltage (VBKP)
+10 BCI: Battery charger current (ICHG)
+11 BCI: Battery charger voltage (VCHG)
+12 BCI: Main battery voltage (VBAT)
+13 Reserved
+14 Reserved
+15 VRUSB Supply/Speaker left/Speaker right polarization level
+
+
+The Sysfs nodes will represent the voltage in the units of mV,
+the temperature channel shows the converted raw voltage in mV.
+The Battery charging current channel represents raw voltage mV.
+Channel 13 and 14 are reserved.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 773e484..11ddde3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -940,6 +940,16 @@ config SENSORS_TMP421
  This driver can also be built as a module.  If so, the module
  will be called tmp421.
 
+config SENSORS_TWL4030_MADC
+   tristate "Texas Instruments TWL4030 MADC Hwmon"
+   depends on TWL4030_MADC
+   help
+   This driver provides hwmon support for triton TWL4030-MADC.
+   This driver can be built as part of kernel or can be built
+   as a module.
+   This driver exposes the various voltage values to
+   the user space.
+
 config SENSORS_VIA_CPUTEMP
tristate "VIA CPU temperature sensor"
depends on X86
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index dde02d9..bc7d740 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_SENSORS_THMC50)+= thmc50.o
 obj-$(CONFIG_SENSORS_TMP102)   += tmp102.o
 obj-$(CONFIG_SENSORS_TMP401)   += tmp401.o
 obj-$(CONFIG_SENSORS_TMP421)   += tmp421.o
+obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o
 obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
 obj-$(CONFIG_SENSORS_VIA686A)  += via686a.o
 obj-$(CONFIG_SENSORS_VT1211)   += vt1211.o
diff --git a/drivers/hwmon/twl4030-madc-hwmon.c 
b/drivers/hwmon/twl4030-madc-hwmon.c
new file mode 100644
index 000..4a61e8a
--- /dev/null
+++ b/drivers/hwmon/twl4030-madc-hwmon.c
@@ -0,0 +1,155 @@
+/*
+ *
+ * TWL4030 MADC Hwmon driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc. User can ask for the conversion on a
+ * particular channel using the sysfs nodes.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy 
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * sysfs hook 

[PATCH 1/2] mfd: twl4030: Driver for twl4030 madc module

2011-02-16 Thread Keerthy
Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring
ADC. This driver monitors the real time conversion of analog signals like
battery temperature, battery type, battery level etc.

Signed-off-by: Keerthy 

---
The previous discussion concluded in keeping the generic ADC
functionality and the hwmon separate. The discussion can be found here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html

 drivers/mfd/Kconfig  |   10 +
 drivers/mfd/Makefile |1 +
 drivers/mfd/twl4030-madc.c   |  723 ++
 include/linux/i2c/twl4030-madc.h |  132 +++
 4 files changed, 866 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/twl4030-madc.c
 create mode 100644 include/linux/i2c/twl4030-madc.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..7d36882 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -167,6 +167,16 @@ config TWL4030_CORE
  high speed USB OTG transceiver, an audio codec (on most
  versions) and many other features.
 
+config TWL4030_MADC
+   tristate "Texas Instruments TWL4030 MADC"
+   depends on TWL4030_CORE
+   help
+   This driver provides support for triton TWL4030-MADC. The
+   driver supports both RT and SW conversion methods.
+
+   This driver can be built as part of kernel or can be built
+   as a module.
+
 config TWL4030_POWER
bool "Support power resources on TWL4030 family chips"
depends on TWL4030_CORE && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a54e2c7..2922cc2 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
 obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
+obj-$(CONFIG_TWL4030_MADC)  += twl4030-madc.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
 obj-$(CONFIG_TWL6030_PWM)  += twl6030-pwm.o
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
new file mode 100644
index 000..711bfff
--- /dev/null
+++ b/drivers/mfd/twl4030-madc.c
@@ -0,0 +1,723 @@
+/*
+ *
+ * TWL4030 MADC module driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy 
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen 
+ *
+ * Amit Kucheria 
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * struct twl4030_madc_data - a container for madc info
+ * @dev - pointer to device structure for madc
+ * @lock - mutex protecting this data structire
+ * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @imr - Interrupt mask register of MADC
+ * @isr - Interrupt status register of MADC
+ */
+struct twl4030_madc_data {
+   struct device *dev;
+   struct mutex lock;  /* mutex protecting this data structire */
+   struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   int imr;
+   int isr;
+};
+
+static struct twl4030_madc_data *twl4030_madc;
+
+struct twl4030_prescale_divider_ratios {
+   s16 numerator;
+   s16 denominator;
+};
+
+static const struct twl4030_prescale_divider_ratios
+twl4030_divider_ratios[16] = {
+   {1, 1}, /* CHANNEL 0 No Prescaler */
+   {1, 1}, /* CHANNEL 1 No Prescaler */
+   {6, 10},/* CHANNEL 2 */
+   {6, 10},/* CHANNEL 3 */
+   {6, 10},/* CHANNEL 4 */
+   {6, 10},/* CHANNEL 5 */
+   {6, 10},/* CHANNEL 6 */
+   {6, 10},/* CHANNEL 7 */
+   {3, 14},/* CHANNEL 8 */
+   {1, 3}, /* CHANNEL 9 */
+   {1, 1}, /* CHANNEL 10 NA */
+   {15, 100},  /* CHANNEL 11 */
+   {1, 4}, /* CHANNEL 12 */
+   {1, 1}, /* CHANNEL 13 NA */
+   {1, 1}, /* CHANNEL 14 NA */
+   {5, 11},/* CHANNEL 15 */
+};
+
+/*
+ * Structure containing the registers
+ * of different conversion methods supported by MADC.
+ * Hardware or RT real 

[PATCH 0/2] twl4030-madc driver

2011-02-16 Thread Keerthy
MADC(Monitoring ADC) driver enables monitoring analog signals using
analog-to-digital conversion (ADC) on the input source.
The previous discussion concluded in keeping the generic ADC
functionality and the hwmon separate. The discussion can be found here:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html

Keerthy (2):
  mfd: twl4030: Driver for twl4030 madc module
  hwmon: twl4030: Hwmon Driver for TWL4030 MADC

 Documentation/hwmon/twl4030-madc-hwmon |   45 ++
 drivers/hwmon/Kconfig  |   10 +
 drivers/hwmon/Makefile |1 +
 drivers/hwmon/twl4030-madc-hwmon.c |  155 +++
 drivers/mfd/Kconfig|   10 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/twl4030-madc.c |  723 
 include/linux/i2c/twl4030-madc.h   |  132 ++
 8 files changed, 1077 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/hwmon/twl4030-madc-hwmon
 create mode 100644 drivers/hwmon/twl4030-madc-hwmon.c
 create mode 100644 drivers/mfd/twl4030-madc.c
 create mode 100644 include/linux/i2c/twl4030-madc.h

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


  1   2   >