RE: [PATCH 3/5] OMAP4: clocks: Update clock tree for ES2

2010-09-21 Thread Nayak, Rajendra
Hi Paul,

> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, September 22, 2010 10:34 AM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Kevin Hilman
> Subject: Re: [PATCH 3/5] OMAP4: clocks: Update clock tree for ES2
> 
> Hello Rajendra, Benoît,
> 
> On Thu, 16 Sep 2010, Rajendra Nayak wrote:
> 
> > This patch updates the clock tree with all the
> > changes in OMAP4430 ES2.
> >
> > clock nodes added
> > -1- tie_low_clock_ck
> > -2- abe_dpll_bypass_clk_mux_ck
> >
> > clock nodes deleted
> > -1- dpll_sys_ref_clk
> > -2- per_sgx_fclk
> > -3- usbphyocp2scp_ick
> >
> > Signed-off-by: Rajendra Nayak 
> > Signed-off-by: Benoît Cousson 
> 
> UTF-8 problem again here...
> 
> > Cc: Paul Walmsley 
> > Cc: Kevin Hilman 
> 
> The clock tree resulting from this patch doesn't match the output from
> the current OMAP4 clock autogen script.  Seems like it should.  Could you
> help me understand that?

I guess that's mainly because of fixes in the autogen scripts, the patches for 
which 
have not yet made it to the list.

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


Re: [PATCH v2 2/6] OMAP1: Add support for SoC camera interface

2010-09-21 Thread Guennadi Liakhovetski
That's up to the platform maintainer to review / apply this one, but if 
you like, a couple of nit-picks from me:

On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:

> This patch adds support for SoC camera interface to OMAP1 devices.
> 
> Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
> 
> For successfull compilation, requires a header file provided by PATCH 1/6 
> from 
> this series, "SoC Camera: add driver for OMAP1 camera interface".
> 
> Signed-off-by: Janusz Krzysztofik 
> ---
> v1->v2 changes:
> - no functional changes,
> - refreshed against linux-2.6.36-rc3
> 
> 
>  arch/arm/mach-omap1/devices.c |   43 
> ++
>  arch/arm/mach-omap1/include/mach/camera.h |8 +
>  2 files changed, 51 insertions(+)
> 
> 
> diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 
> linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
> --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c   2010-09-03 
> 22:29:00.0 +0200
> +++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c2010-09-09 
> 18:42:30.0 +0200
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -25,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

You might want to try to group headers according to their location, i.e., 
put  higher - together with , also it helps to have 
headers alphabetically ordered.

>  
>  /*-*/
>  
> @@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
>  }
>  #endif
>  
> +
> +#define OMAP1_CAMERA_BASE0xfffb6800
> +
> +static struct resource omap1_camera_resources[] = {
> + [0] = {
> + .start  = OMAP1_CAMERA_BASE,
> + .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
> + .flags  = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start  = INT_CAMERA,
> + .flags  = IORESOURCE_IRQ,
> + },
> +};
> +
> +static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
> +
> +static struct platform_device omap1_camera_device = {
> + .name   = "omap1-camera",
> + .id = 0, /* This is used to put cameras on this interface */
> + .dev= {
> + .dma_mask   = &omap1_camera_dma_mask,
> + .coherent_dma_mask  = DMA_BIT_MASK(32),
> + },
> + .num_resources  = ARRAY_SIZE(omap1_camera_resources),
> + .resource   = omap1_camera_resources,
> +};
> +
> +void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
> +{
> + struct platform_device *dev = &omap1_camera_device;
> + int ret;
> +
> + dev->dev.platform_data = info;
> +
> + ret = platform_device_register(dev);
> + if (ret)
> + dev_err(&dev->dev, "unable to register device: %d\n", ret);
> +}
> +
> +
>  /*-*/
>  
>  static inline void omap_init_sti(void) {}
> diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h 
> linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
> --- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h   
> 2010-09-03 
> 22:34:03.0 +0200
> +++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
> 2010-09-09 
> 18:42:30.0 +0200
> @@ -0,0 +1,8 @@
> +#ifndef __ASM_ARCH_CAMERA_H_
> +#define __ASM_ARCH_CAMERA_H_
> +
> +#include 
> +
> +extern void omap1_set_camera_info(struct omap1_cam_platform_data *);

function declarations don't need an "extern" - something I've also been 
doing needlessly for a few years...

> +
> +#endif /* __ASM_ARCH_CAMERA_H_ */

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe 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/5] OMAP4: PM: Update PRCM register bitshits and masks for ES2

2010-09-21 Thread Nayak, Rajendra


> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, September 22, 2010 11:47 AM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Kevin Hilman
> Subject: Re: [PATCH 1/5] OMAP4: PM: Update PRCM register bitshits and masks 
> for
> ES2
> 
> Hi Rajendra
> 
> On Thu, 16 Sep 2010, Rajendra Nayak wrote:
> 
> > This patch updates the PRM and CM register bitshifts and masks
> > for OMAP4430 ES2.0.
> >
> > Signed-off-by: Rajendra Nayak 
> > Signed-off-by: Benoît Cousson 
> > Cc: Paul Walmsley 
> > Cc: Kevin Hilman 
> 
> Thanks, queued for 2.6.37 (with the UTF-8 fix in the patch description).
> 
> One other note:
> 
> >  #define OMAP4430_IDLEST_MASK   
> > BITFIELD(16,
> 17)
> 
> We should really get rid of all these 'BITFIELD' defines, and just replace
> them with simple bitshifts.  Care to spin a patch to do that during the
> 2.6.38 timeframe?

Sure, there's already a patch for this which I guess Benoit should be posting 
pretty soon.

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


RE: [PATCH 2/5] OMAP4: PM: Define additional registers for ES2

2010-09-21 Thread Nayak, Rajendra


> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, September 22, 2010 11:48 AM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Kevin Hilman
> Subject: Re: [PATCH 2/5] OMAP4: PM: Define additional registers for ES2
> 
> On Thu, 16 Sep 2010, Rajendra Nayak wrote:
> 
> > 4430 ES2 has a few new registers added and a few modified
> > from ES1. This patch adds all the register changes in PRM
> > and CM for OMAP4430 ES2.
> >
> > Signed-off-by: Rajendra Nayak 
> > Signed-off-by: Benoît Cousson 
> 
> Thanks, queued for 2.6.37  (with the UTF-8 fixed here; please fix this on
> your end)

Thanks Paul, I'll get the encoding issue fixed.

> 
> - Paul
> 
> > Cc: Paul Walmsley 
> > Cc: Kevin Hilman 
> > ---
> >  arch/arm/mach-omap2/cm44xx.h  |   90
> -
> >  arch/arm/mach-omap2/prm44xx.h |   14 ---
> >  2 files changed, 96 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
> > index 336d948..3c35a87 100644
> > --- a/arch/arm/mach-omap2/cm44xx.h
> > +++ b/arch/arm/mach-omap2/cm44xx.h
> > @@ -195,6 +195,42 @@
> >  #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET  0x0088
> >  #define OMAP4430_CM1_ABE_WDT3_CLKCTRL
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_MOD, 0x0088)
> >
> > +/* CM1.RESTORE_CM1 register offsets */
> > +#define OMAP4_CM_CLKSEL_CORE_RESTORE_OFFSET0x
> > +#define OMAP4430_CM_CLKSEL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x)
> > +#define OMAP4_CM_DIV_M2_DPLL_CORE_RESTORE_OFFSET   0x0004
> > +#define OMAP4430_CM_DIV_M2_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0004)
> > +#define OMAP4_CM_DIV_M3_DPLL_CORE_RESTORE_OFFSET   0x0008
> > +#define OMAP4430_CM_DIV_M3_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0008)
> > +#define OMAP4_CM_DIV_M4_DPLL_CORE_RESTORE_OFFSET   0x000c
> > +#define OMAP4430_CM_DIV_M4_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x000c)
> > +#define OMAP4_CM_DIV_M5_DPLL_CORE_RESTORE_OFFSET   0x0010
> > +#define OMAP4430_CM_DIV_M5_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0010)
> > +#define OMAP4_CM_DIV_M6_DPLL_CORE_RESTORE_OFFSET   0x0014
> > +#define OMAP4430_CM_DIV_M6_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0014)
> > +#define OMAP4_CM_DIV_M7_DPLL_CORE_RESTORE_OFFSET   0x0018
> > +#define OMAP4430_CM_DIV_M7_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0018)
> > +#define OMAP4_CM_CLKSEL_DPLL_CORE_RESTORE_OFFSET   0x001c
> > +#define OMAP4430_CM_CLKSEL_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x001c)
> > +#define OMAP4_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE_OFFSET   0x0020
> > +#define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0020)
> > +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE_OFFSET   0x0024
> > +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0024)
> > +#define OMAP4_CM_CLKMODE_DPLL_CORE_RESTORE_OFFSET  0x0028
> > +#define OMAP4430_CM_CLKMODE_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0028)
> > +#define OMAP4_CM_SHADOW_FREQ_CONFIG2_RESTORE_OFFSET0x002c
> > +#define OMAP4430_CM_SHADOW_FREQ_CONFIG2_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x002c)
> > +#define OMAP4_CM_SHADOW_FREQ_CONFIG1_RESTORE_OFFSET0x0030
> > +#define OMAP4430_CM_SHADOW_FREQ_CONFIG1_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0030)
> > +#define OMAP4_CM_AUTOIDLE_DPLL_CORE_RESTORE_OFFSET 0x0034
> > +#define OMAP4430_CM_AUTOIDLE_DPLL_CORE_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0034)
> > +#define OMAP4_CM_MPU_CLKSTCTRL_RESTORE_OFFSET  0x0038
> > +#define OMAP4430_CM_MPU_CLKSTCTRL_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0038)
> > +#define OMAP4_CM_CM1_PROFILING_CLKCTRL_RESTORE_OFFSET  0x003c
> > +#define OMAP4430_CM_CM1_PROFILING_CLKCTRL_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x003c)
> > +#define OMAP4_CM_DYN_DEP_PRESCAL_RESTORE_OFFSET0x0040
> > +#define OMAP4430_CM_DYN_DEP_PRESCAL_RESTORE
>   OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0040)
> > +
> >  /* CM2 */
> >
> >  /* CM2.OCP_SOCKET_CM2 register offsets */
> > @@ -252,8 +288,6 @@
> >  #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_PER
>   OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0068)
> >  #define OMAP4_CM_SSC_MODFREQDIV_DPLL_PER_OFFSET0x006c
> >  #define OMAP4430_CM_SSC_MODFREQDIV_DPLL_PER
>   OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x006c)
> > -#define OMAP4_CM_EMU_OVERRIDE_DPLL_PER_OFFSET  0x0070
> > -#define OMAP4430_CM_EMU_OVERRIDE_DPLL_PER
>   OMAP44XX_CM2_RE

RE: [PATCH 5/5] OMAP4: powerdomain: add context_offset field

2010-09-21 Thread Shilimkar, Santosh
> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, September 22, 2010 11:43 AM
> To: Nayak, Rajendra; Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; Cousson, Benoit; Kevin Hilman
> Subject: Re: [PATCH 5/5] OMAP4: powerdomain: add context_offset field
> 
> Hello Santosh, Rajendra,
> 
> a few comments on this patch:
> 
> On Thu, 16 Sep 2010, Rajendra Nayak wrote:
> 
> > From: Santosh Shilimkar 
> >
> > Context register in various power domain is not at same offset
> > on OMAP4. Mainly the CPUx context resgiters againts rest of
> > them. This patch adds a field in power-domain strucures to handle
> > this.
> >
> > This will be needed to make "pwrdm_clear_all_prev_pwrst" API work on
> > OMAP4.
> 
> Is the powerdomain.c code that uses context_offset ready yet?  If not,
> it seems best to submit this together with the code that uses it?
> 
It's the next series what Rajendra is doing. We can add this one as
part of that series if you like.

> > Signed-off-by: Santosh Shilimkar 
> > Signed-off-by: Rajendra Nayak 
> > Signed-off-by: Benoit Cousson 
> > Cc: Paul Walmsley 
> > Cc: Kevin Hilman 
> > ---
> >  arch/arm/mach-omap2/powerdomains44xx.h|   14 ++
> >  arch/arm/plat-omap/include/plat/powerdomain.h |1 +
> >  2 files changed, 15 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/powerdomains44xx.h b/arch/arm/mach-
> omap2/powerdomains44xx.h
> > index 9c01b55..65e919b 100644
> > --- a/arch/arm/mach-omap2/powerdomains44xx.h
> > +++ b/arch/arm/mach-omap2/powerdomains44xx.h
> > @@ -40,6 +40,7 @@ static struct powerdomain core_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks= 5,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF,  /* core_nret_bank */
> > [1] = PWRSTS_OFF_RET,   /* core_ocmram */
> > @@ -64,6 +65,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
> > .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > .pwrsts   = PWRSTS_OFF_ON,
> > .banks= 1,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF,  /* gfx_mem */
> > },
> > @@ -81,6 +83,7 @@ static struct powerdomain abe_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRDM_POWER_OFF,
> > .banks= 2,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_RET,  /* aessmem */
> > [1] = PWRDM_POWER_OFF,  /* periphmem */
> > @@ -100,6 +103,7 @@ static struct powerdomain dss_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF,
> > .banks= 1,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF,  /* dss_mem */
> > },
> > @@ -117,6 +121,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks= 3,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_RET,  /* tesla_edma */
> > [1] = PWRSTS_OFF_RET,   /* tesla_l1 */
> > @@ -137,6 +142,7 @@ static struct powerdomain wkup_44xx_pwrdm = {
> > .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > .pwrsts   = PWRSTS_ON,
> > .banks= 1,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF,  /* wkup_bank */
> > },
> > @@ -153,6 +159,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks= 1,
> > +   .context_offset   = 0x18,
> > .pwrsts_mem_ret = {
> > [0] = PWRSTS_OFF_RET,   /* cpu0_l1 */
> > },
> > @@ -169,6 +176,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks= 1,
> > +   .context_offset   = 0x18,
> > .pwrsts_mem_ret = {
> > [0] = PWRSTS_OFF_RET,   /* cpu1_l1 */
> > },
> > @@ -184,6 +192,7 @@ static struct powerdomain emu_44xx_pwrdm = {
> > .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> > .pwrsts   = PWRSTS_OFF_ON,
> > .banks= 1,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRDM_POWER_OFF,  /* emu_bank */
> > },
> > @@ -200,6 +209,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
> > .pwrsts   = PWRSTS_OFF_RET_ON,
> > .pwrsts_logic_ret = PWRSTS_OFF_RET,
> > .banks= 3,
> > +   .context_offset   = 0x24,
> > .pwrsts_mem_ret = {
> > [0] = PWRSTS_OFF_RET,   /* mpu_l1 */
> > [1] = PWRSTS_OFF_RET,   /* mpu_l2 */
> > @@ -220,6 +2

Re: [PATCH 4/5] OMAP4: powerdomain: Update DSS logic state for ES2

2010-09-21 Thread Paul Walmsley
Hi Rajendra,

On Thu, 16 Sep 2010, Rajendra Nayak wrote:

> DSS on ES2 supports only OSWR, hence remove the support
> for CSWR from the powerdomain framework.
> 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Benoît Cousson 
> Cc: Paul Walmsley 
> Cc: Kevin Hilman 

Thanks, queued for 2.6.37 (with Benoît's name fixed)

- Paul

Re: [PATCH 2/5] OMAP4: PM: Define additional registers for ES2

2010-09-21 Thread Paul Walmsley
On Thu, 16 Sep 2010, Rajendra Nayak wrote:

> 4430 ES2 has a few new registers added and a few modified
> from ES1. This patch adds all the register changes in PRM
> and CM for OMAP4430 ES2.
> 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Benoît Cousson 

Thanks, queued for 2.6.37  (with the UTF-8 fixed here; please fix this on 
your end)

- Paul

> Cc: Paul Walmsley 
> Cc: Kevin Hilman 
> ---
>  arch/arm/mach-omap2/cm44xx.h  |   90 
> -
>  arch/arm/mach-omap2/prm44xx.h |   14 ---
>  2 files changed, 96 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cm44xx.h b/arch/arm/mach-omap2/cm44xx.h
> index 336d948..3c35a87 100644
> --- a/arch/arm/mach-omap2/cm44xx.h
> +++ b/arch/arm/mach-omap2/cm44xx.h
> @@ -195,6 +195,42 @@
>  #define OMAP4_CM1_ABE_WDT3_CLKCTRL_OFFSET0x0088
>  #define OMAP4430_CM1_ABE_WDT3_CLKCTRL
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_ABE_MOD, 0x0088)
>  
> +/* CM1.RESTORE_CM1 register offsets */
> +#define OMAP4_CM_CLKSEL_CORE_RESTORE_OFFSET  0x
> +#define OMAP4430_CM_CLKSEL_CORE_RESTORE  
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x)
> +#define OMAP4_CM_DIV_M2_DPLL_CORE_RESTORE_OFFSET 0x0004
> +#define OMAP4430_CM_DIV_M2_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0004)
> +#define OMAP4_CM_DIV_M3_DPLL_CORE_RESTORE_OFFSET 0x0008
> +#define OMAP4430_CM_DIV_M3_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0008)
> +#define OMAP4_CM_DIV_M4_DPLL_CORE_RESTORE_OFFSET 0x000c
> +#define OMAP4430_CM_DIV_M4_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x000c)
> +#define OMAP4_CM_DIV_M5_DPLL_CORE_RESTORE_OFFSET 0x0010
> +#define OMAP4430_CM_DIV_M5_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0010)
> +#define OMAP4_CM_DIV_M6_DPLL_CORE_RESTORE_OFFSET 0x0014
> +#define OMAP4430_CM_DIV_M6_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0014)
> +#define OMAP4_CM_DIV_M7_DPLL_CORE_RESTORE_OFFSET 0x0018
> +#define OMAP4430_CM_DIV_M7_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0018)
> +#define OMAP4_CM_CLKSEL_DPLL_CORE_RESTORE_OFFSET 0x001c
> +#define OMAP4430_CM_CLKSEL_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x001c)
> +#define OMAP4_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE_OFFSET 0x0020
> +#define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0020)
> +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE_OFFSET 0x0024
> +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE_RESTORE 
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0024)
> +#define OMAP4_CM_CLKMODE_DPLL_CORE_RESTORE_OFFSET0x0028
> +#define OMAP4430_CM_CLKMODE_DPLL_CORE_RESTORE
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0028)
> +#define OMAP4_CM_SHADOW_FREQ_CONFIG2_RESTORE_OFFSET  0x002c
> +#define OMAP4430_CM_SHADOW_FREQ_CONFIG2_RESTORE  
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x002c)
> +#define OMAP4_CM_SHADOW_FREQ_CONFIG1_RESTORE_OFFSET  0x0030
> +#define OMAP4430_CM_SHADOW_FREQ_CONFIG1_RESTORE  
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0030)
> +#define OMAP4_CM_AUTOIDLE_DPLL_CORE_RESTORE_OFFSET   0x0034
> +#define OMAP4430_CM_AUTOIDLE_DPLL_CORE_RESTORE   
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0034)
> +#define OMAP4_CM_MPU_CLKSTCTRL_RESTORE_OFFSET0x0038
> +#define OMAP4430_CM_MPU_CLKSTCTRL_RESTORE
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0038)
> +#define OMAP4_CM_CM1_PROFILING_CLKCTRL_RESTORE_OFFSET0x003c
> +#define OMAP4430_CM_CM1_PROFILING_CLKCTRL_RESTORE
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x003c)
> +#define OMAP4_CM_DYN_DEP_PRESCAL_RESTORE_OFFSET  0x0040
> +#define OMAP4430_CM_DYN_DEP_PRESCAL_RESTORE  
> OMAP44XX_CM1_REGADDR(OMAP4430_CM1_RESTORE_MOD, 0x0040)
> +
>  /* CM2 */
>  
>  /* CM2.OCP_SOCKET_CM2 register offsets */
> @@ -252,8 +288,6 @@
>  #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_PER  
> OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0068)
>  #define OMAP4_CM_SSC_MODFREQDIV_DPLL_PER_OFFSET  0x006c
>  #define OMAP4430_CM_SSC_MODFREQDIV_DPLL_PER  
> OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x006c)
> -#define OMAP4_CM_EMU_OVERRIDE_DPLL_PER_OFFSET0x0070
> -#define OMAP4430_CM_EMU_OVERRIDE_DPLL_PER
> OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0070)
>  #define OMAP4_CM_CLKMODE_DPLL_USB_OFFSET 0x0080
>  #define OMAP4430_CM_CLKMODE_DPLL_USB 
> OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CKGEN_MOD, 0x0080)
>  #define OMAP4_CM_IDLEST_DPLL_USB_OFFSET  0x0084
> @@ -296,6 +330,8 @@
>  #define OMAP4430_CM_ALWON_SR_IVA_CLKCTRL  

Re: [PATCH 1/5] OMAP4: PM: Update PRCM register bitshits and masks for ES2

2010-09-21 Thread Paul Walmsley
Hi Rajendra

On Thu, 16 Sep 2010, Rajendra Nayak wrote:

> This patch updates the PRM and CM register bitshifts and masks
> for OMAP4430 ES2.0.
> 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Benoît Cousson 
> Cc: Paul Walmsley 
> Cc: Kevin Hilman 

Thanks, queued for 2.6.37 (with the UTF-8 fix in the patch description).

One other note:

>  #define OMAP4430_IDLEST_MASK BITFIELD(16, 17)

We should really get rid of all these 'BITFIELD' defines, and just replace 
them with simple bitshifts.  Care to spin a patch to do that during the 
2.6.38 timeframe?


- Paul

Re: [PATCH 5/5] OMAP4: powerdomain: add context_offset field

2010-09-21 Thread Paul Walmsley
Hello Santosh, Rajendra,

a few comments on this patch:

On Thu, 16 Sep 2010, Rajendra Nayak wrote:

> From: Santosh Shilimkar 
> 
> Context register in various power domain is not at same offset
> on OMAP4. Mainly the CPUx context resgiters againts rest of
> them. This patch adds a field in power-domain strucures to handle
> this.
> 
> This will be needed to make "pwrdm_clear_all_prev_pwrst" API work on
> OMAP4.

Is the powerdomain.c code that uses context_offset ready yet?  If not, 
it seems best to submit this together with the code that uses it?

> Signed-off-by: Santosh Shilimkar 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Benoit Cousson 
> Cc: Paul Walmsley 
> Cc: Kevin Hilman 
> ---
>  arch/arm/mach-omap2/powerdomains44xx.h|   14 ++
>  arch/arm/plat-omap/include/plat/powerdomain.h |1 +
>  2 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/powerdomains44xx.h 
> b/arch/arm/mach-omap2/powerdomains44xx.h
> index 9c01b55..65e919b 100644
> --- a/arch/arm/mach-omap2/powerdomains44xx.h
> +++ b/arch/arm/mach-omap2/powerdomains44xx.h
> @@ -40,6 +40,7 @@ static struct powerdomain core_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF_RET,
>   .banks= 5,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* core_nret_bank */
>   [1] = PWRSTS_OFF_RET,   /* core_ocmram */
> @@ -64,6 +65,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
>   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>   .pwrsts   = PWRSTS_OFF_ON,
>   .banks= 1,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* gfx_mem */
>   },
> @@ -81,6 +83,7 @@ static struct powerdomain abe_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRDM_POWER_OFF,
>   .banks= 2,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_RET,  /* aessmem */
>   [1] = PWRDM_POWER_OFF,  /* periphmem */
> @@ -100,6 +103,7 @@ static struct powerdomain dss_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF,
>   .banks= 1,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* dss_mem */
>   },
> @@ -117,6 +121,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF_RET,
>   .banks= 3,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_RET,  /* tesla_edma */
>   [1] = PWRSTS_OFF_RET,   /* tesla_l1 */
> @@ -137,6 +142,7 @@ static struct powerdomain wkup_44xx_pwrdm = {
>   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>   .pwrsts   = PWRSTS_ON,
>   .banks= 1,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* wkup_bank */
>   },
> @@ -153,6 +159,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF_RET,
>   .banks= 1,
> + .context_offset   = 0x18,
>   .pwrsts_mem_ret = {
>   [0] = PWRSTS_OFF_RET,   /* cpu0_l1 */
>   },
> @@ -169,6 +176,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF_RET,
>   .banks= 1,
> + .context_offset   = 0x18,
>   .pwrsts_mem_ret = {
>   [0] = PWRSTS_OFF_RET,   /* cpu1_l1 */
>   },
> @@ -184,6 +192,7 @@ static struct powerdomain emu_44xx_pwrdm = {
>   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>   .pwrsts   = PWRSTS_OFF_ON,
>   .banks= 1,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* emu_bank */
>   },
> @@ -200,6 +209,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRSTS_OFF_RET,
>   .banks= 3,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRSTS_OFF_RET,   /* mpu_l1 */
>   [1] = PWRSTS_OFF_RET,   /* mpu_l2 */
> @@ -220,6 +230,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
>   .pwrsts   = PWRSTS_OFF_RET_ON,
>   .pwrsts_logic_ret = PWRDM_POWER_OFF,
>   .banks= 4,
> + .context_offset   = 0x24,
>   .pwrsts_mem_ret = {
>   [0] = PWRDM_POWER_OFF,  /* hwa_mem */
>   [1] = PWRSTS_OFF_RET,   /* sl2_mem */
> @@ -242,6 +253,7 @@ static struct powerdomain cam_44xx_pwrdm = {
>   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>   .pwr

Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

2010-09-21 Thread Guennadi Liakhovetski
On Wed, 22 Sep 2010, hermann pitton wrote:

> Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
> > On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > 
> > > This is a V4L2 driver for TI OMAP1 SoC camera interface.
> 
> [snip]
> 
> > > +
> > > + } else {
> > > + dev_warn(dev, "%s: unhandled camera interrupt, status == "
> > > + "0x%0x\n", __func__, it_status);
> > 
> > Please, don't split strings
> 
> sorry for any OT interference.
> 
> But, are there any new rules out?
> 
> Maybe I missed them.
> 
> Either way, the above was forced during the last three years.
> 
> Not at all ?

No. Splitting print strings has always been discouraged, because it makes 
tracking back kernel logs difficult. The reason for this has been the 80 
character line length limit, which has now been effectively lifted. I'm 
sure you can find enough links on the internet for any of these topics.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP4: clocks: Update clock tree for ES2

2010-09-21 Thread Paul Walmsley
Hello Rajendra, Benoît,

On Thu, 16 Sep 2010, Rajendra Nayak wrote:

> This patch updates the clock tree with all the
> changes in OMAP4430 ES2.
> 
> clock nodes added
> -1- tie_low_clock_ck
> -2- abe_dpll_bypass_clk_mux_ck
> 
> clock nodes deleted
> -1- dpll_sys_ref_clk
> -2- per_sgx_fclk
> -3- usbphyocp2scp_ick
> 
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Benoît Cousson 

UTF-8 problem again here...

> Cc: Paul Walmsley 
> Cc: Kevin Hilman 

The clock tree resulting from this patch doesn't match the output from 
the current OMAP4 clock autogen script.  Seems like it should.  Could you 
help me understand that?


thanks

- Paul

RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset

2010-09-21 Thread Sripathy, Vishwanath
Hi Paul,

> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, September 22, 2010 6:37 AM
> To: Sripathy, Vishwanath
> Cc: Reddy, Teerth; linux-omap@vger.kernel.org
> Subject: RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall 
> in
> SDRC after a Warm-reset
> 
> Hello Vishwa,
> 
> Thanks for the info.
> 
> a few quick questions:
> 
> On Thu, 16 Sep 2010, Sripathy, Vishwanath wrote:
> 
> > > -Original Message-
> > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > Sent: Thursday, September 16, 2010 3:05 AM
> > >
> > > On Tue, 25 May 2010, Reddy, Teerth wrote:
> > >
> > > > > -Original Message-
> > > > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > > > Sent: Wednesday, May 19, 2010 6:03 AM
> > > > > To: Reddy, Teerth
> > > > >
> > > > > On Fri, 23 Apr 2010, Reddy, Teerth wrote:
> > > > >
> > > > > > From: Teerth Reddy 
> > > > > >
> > > > > > This patch has the workaround for errata 1.176.
> > >
> > > What's the current status of this patch?  Still waiting for an updated
> > > version.
> >
> > We have realized that this errata is not applicable if reset is
> > triggered via dpll3 reset. The rootcasuse of the issues was that incase
> > of warm reset, SDRC is not sensitive to the warm reset, but the
> > interconect is reset on the fly, thus causing a misalignment between
> > SDRC logic, interconect logic and DDR memory state. Hence the workaround
> > was proposed. However, incase of dpll3 reset, sdrc also gets reset. In
> > omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this
> > WA is not applicable.
> 
> 
> 1. So by "warm reset," are you referring to the software warm reset
> triggered by GLOBAL_SW_RST, or by another mechanism?
> Yes, warm reset by means of GLOBAL_SW_RST.

> 2. If GLOBAL_SW_RST, what do you think about adding a brief comment in the
> code warning people not to use GLOBAL_SW_RST unless they implement the
> Errata 1.176 sequence?
Yes, a note can be added. I will send a patch with this comment.

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


Re: [PATCH 1/2 v3]Update broken web addresses.

2010-09-21 Thread Justin P. Mattock

On 09/21/2010 08:25 PM, Finn Thain wrote:


On Tue, 21 Sep 2010, Justin P. Mattock wrote:


Below is an update from the original, with changes to the broken web
addresses and removal of archive.org and moved to a seperate patch for
you guys to decide if you want to use this and/or just leave the old url
in and leave it at that..
Please dont apply this to anything just comments and fixes for now,


You can use [RFC] in the Subject line instead of [PATCH] to indicate this.



alright..




diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
index 8f06408..234d9ee 100644
--- a/arch/m68k/mac/macboing.c
+++ b/arch/m68k/mac/macboing.c
@@ -114,7 +114,8 @@ static void mac_init_asc( void )
 *   16-bit I/O functionality.  The PowerBook 500 
series computers
 *   support 16-bit stereo output, but only mono input."
 *
-*   
http://til.info.apple.com/techinfo.nsf/artnum/n16405
+*   Article number 16405:
+*   http://support.apple.com/kb/TA32601
 *
 * --David Kilzer
 */


"TIL article number 16405" would allow people to find the document by
number...



so putting this "TIL article number 16405" is correct instead of Article 
number 16405:





diff --git a/arch/m68k/q40/README b/arch/m68k/q40/README
index 6bdbf48..92806c0 100644
--- a/arch/m68k/q40/README
+++ b/arch/m68k/q40/README
@@ -3,7 +3,7 @@ Linux for the Q40

  You may try http://www.geocities.com/SiliconValley/Bay/2602/ for
  some up to date information. Booter and other tools will be also
-available from this place or ftp.uni-erlangen.de/linux/680x0/q40/
+available from this place or http://www.linux-m68k.org/mail.html
  and mirrors.

  Hints to documentation usually refer to the linux source tree in


No. We already discussed this change. Please refer back to my review of
the first version of the patch. You got it right in the second version
(that I also reviewed), but now you've gone back to the first version...

Finn



pretty bad.. I don't know what happened there..


Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe 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 v3]Update broken web addresses.

2010-09-21 Thread Finn Thain

On Tue, 21 Sep 2010, Justin P. Mattock wrote:

> Below is an update from the original, with changes to the broken web 
> addresses and removal of archive.org and moved to a seperate patch for 
> you guys to decide if you want to use this and/or just leave the old url 
> in and leave it at that..
> Please dont apply this to anything just comments and fixes for now,

You can use [RFC] in the Subject line instead of [PATCH] to indicate this.


> diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
> index 8f06408..234d9ee 100644
> --- a/arch/m68k/mac/macboing.c
> +++ b/arch/m68k/mac/macboing.c
> @@ -114,7 +114,8 @@ static void mac_init_asc( void )
>*   16-bit I/O functionality.  The PowerBook 500 
> series computers
>*   support 16-bit stereo output, but only mono input."
>*
> -  *   
> http://til.info.apple.com/techinfo.nsf/artnum/n16405
> +  *   Article number 16405:
> +  *   http://support.apple.com/kb/TA32601 
>*
>* --David Kilzer
>*/

"TIL article number 16405" would allow people to find the document by 
number...


> diff --git a/arch/m68k/q40/README b/arch/m68k/q40/README
> index 6bdbf48..92806c0 100644
> --- a/arch/m68k/q40/README
> +++ b/arch/m68k/q40/README
> @@ -3,7 +3,7 @@ Linux for the Q40
>  
>  You may try http://www.geocities.com/SiliconValley/Bay/2602/ for
>  some up to date information. Booter and other tools will be also
> -available from this place or ftp.uni-erlangen.de/linux/680x0/q40/
> +available from this place or http://www.linux-m68k.org/mail.html 
>  and mirrors.
>  
>  Hints to documentation usually refer to the linux source tree in

No. We already discussed this change. Please refer back to my review of 
the first version of the patch. You got it right in the second version 
(that I also reviewed), but now you've gone back to the first version...

Finn
--
To unsubscribe from this list: send the line "unsubscribe 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] mfd: speedup twl4030 irq response time and decrease irq disable time

2010-09-21 Thread tom . leiming
From: Ming Lei 

This patch sets scheduler policy of twl4030 irq thread
(twl4030_irq_thread) as SCHED_FIFO to speedup irq response
time, just like taken by kernel threaded irq in irq_thread
(kernel/irq/manage.c). Also higher priority than that of
threaded irq is taken to avoid preemption from twl4030
subchips's threaded irq handler, so pih irq disable time may
be decreased.

The pih irq is disabled in handle_twl4030_pih which may
wakeup twl4030 irq thread, and the pih irq will be enabled
again until complete of all sih irqs' handling in twl4030
irq thread.

Also for each one interrupt line of twl4030 subchip, only
two irq events can be buffered by twl4030(4.4.2.3 of TPS65950 TRM).

Signed-off-by: Ming Lei 
Cc: Samuel Ortiz 
Cc: Santosh Shilimkar 
Cc: Balaji T K 
Cc: Rajendra Nayak 
Cc: Kevin Hilman 
Cc: linux-ker...@vger.kernel.org
---
 drivers/mfd/twl4030-irq.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 097f24d..d1e0d80 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -286,8 +286,16 @@ static int twl4030_irq_thread(void *data)
long irq = (long)data;
static unsigned i2c_errors;
static const unsigned max_i2c_errors = 100;
-
-
+   struct sched_param param = {
+   .sched_priority = MAX_USER_RT_PRIO/2 + 10,
+   };
+
+   /* Take higher priority than threaded irq to make us immune of
+* preemption from twl4030 subchips's threaded irq handler, then
+* we can complete all SIH irqs' handling and enable PIH irq
+* again asap.
+* */
+   sched_setscheduler(current, SCHED_FIFO, ¶m);
current->flags |= PF_NOFREEZE;
 
while (!kthread_should_stop()) {
-- 
1.6.2.5

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


[PATCH 2/2 v3]Update broken web addresses archive dot org only.

2010-09-21 Thread Justin P. Mattock
Below is a patch consisting of only the broken web addresses using 
webarchive.org. 
Please have a look and let me know if you want to go on with using these and/or 
just 
leave the old links in there.
Note: the address needs to have an %2A added to it due to webarchive.org
using a "*" for it's searching capabilities.
Please dont apply this to anything, just comments and changes for now, then
at the right time I'll bunch everything into one patch.

Signed-off-by: Justin P. Mattock 
Cc: Finn Thain 

---
 arch/arm/mach-footbridge/Kconfig  |2 +-
 arch/arm/mach-omap1/Kconfig   |4 ++--
 arch/arm/mach-pxa/idp.c   |4 ++--
 arch/arm/mach-pxa/include/mach/idp.h  |4 ++--
 arch/arm/mach-sa1100/Kconfig  |2 +-
 arch/h8300/Kconfig.cpu|2 +-
 arch/h8300/README |3 ++-
 arch/ia64/include/asm/machvec_sn2.h   |2 +-
 arch/ia64/include/asm/numa.h  |2 +-
 arch/ia64/kernel/acpi.c   |2 +-
 arch/ia64/lib/idiv32.S|2 +-
 arch/ia64/lib/idiv64.S|2 +-
 arch/ia64/sn/kernel/setup.c   |2 +-
 arch/ia64/sn/kernel/sn2/timer_interrupt.c |2 +-
 arch/m68k/Kconfig |2 +-
 arch/m68k/mac/via.c   |5 ++---
 arch/m68k/q40/README  |4 ++--
 arch/sh/cchips/Kconfig|2 +-
 arch/um/os-Linux/start_up.c   |2 +-
 arch/x86/kernel/cpu/amd.c |2 +-
 arch/x86/kernel/cpu/cpufreq/powernow-k8.c |2 +-
 arch/x86/math-emu/README  |2 +-
 22 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index bdd2579..fa30857 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -29,7 +29,7 @@ config ARCH_PERSONAL_SERVER
  There are no product plans beyond the current research
  prototypes at this time.  Information is available at:
 
- 
+ 

 
  If you have any questions or comments about the  Compaq Personal
  Server, send e-mail to .
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5f64963..e3cf9f4 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -118,8 +118,8 @@ config MACH_OMAP_PALMZ71
depends on ARCH_OMAP1 && ARCH_OMAP15XX
help
 Support for the Palm Zire71 PDA. To boot the kernel,
-you'll need a PalmOS compatible bootloader; check out
-http://hackndev.com/palm/z71 for more information.
+you'll need a PalmOS compatible bootloader; For information
+http://web.archive.org/web/%2A/http://old.hackndev.com/palm/z71 
 Say Y here if you have such a PDA, say N otherwise.
 
 config MACH_OMAP_PALMTT
diff --git a/arch/arm/mach-pxa/idp.c b/arch/arm/mach-pxa/idp.c
index bc78c4d..b521a64 100644
--- a/arch/arm/mach-pxa/idp.c
+++ b/arch/arm/mach-pxa/idp.c
@@ -11,8 +11,8 @@
  *  Initial code
  *
  *  2005-02-15: Cliff Brake 
- *  
- *  Updated for 2.6 kernel
+ *  
+ *  Updated for 2.6 kernel
  *
  */
 
diff --git a/arch/arm/mach-pxa/include/mach/idp.h 
b/arch/arm/mach-pxa/include/mach/idp.h
index 5eff96f..d1a3d5d 100644
--- a/arch/arm/mach-pxa/include/mach/idp.h
+++ b/arch/arm/mach-pxa/include/mach/idp.h
@@ -11,8 +11,8 @@
  * Initial code
  *
  * 2005-02-15: Cliff Brake 
- *  
- * Changes for 2.6 kernel.
+ *  
+ *  Changes for 2.6 kernel.
  */
 
 
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index 5da8c35..11bc60f 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -108,7 +108,7 @@ config SA1100_HACKKIT
select CPU_FREQ_SA1100
help
  Say Y here to support the HackKit Core CPU Board
- ;
+ ;
 
 config SA1100_LART
bool "LART"
diff --git a/arch/h8300/Kconfig.cpu b/arch/h8300/Kconfig.cpu
index 8de966a..49d55ba 100644
--- a/arch/h8300/Kconfig.cpu
+++ b/arch/h8300/Kconfig.cpu
@@ -20,7 +20,7 @@ config H8300H_AKI3068NET
  
  AE-3068/69 Evaluation Board Support
  More Information.
- 
+ 


[PATCH 1/2 v3]Update broken web addresses.

2010-09-21 Thread Justin P. Mattock
Below is an update from the original, with changes to the broken web addresses 
and removal of 
archive.org and moved to a seperate patch for you guys to decide if you want to 
use this and/or
just leave the old url in and leave it at that..
Please dont apply this to anything just comments and fixes for now,
then when the time is right, I can bunch everything all into one big patch.
 
Signed-off-by: Justin P. Mattock 
Cc: Maciej W. Rozycki 
Cc: Finn Thain 
Cc: Randy Dunlap 

---
 arch/arm/Kconfig |4 ++--
 arch/arm/common/icst.c   |2 +-
 arch/arm/include/asm/hardware/icst.h |2 +-
 arch/arm/mach-at91/Kconfig   |6 +++---
 arch/arm/mach-omap1/Kconfig  |2 +-
 arch/arm/mach-pxa/am200epd.c |2 +-
 arch/arm/mach-pxa/am300epd.c |2 +-
 arch/arm/mach-s3c2440/mach-at2440evb.c   |2 +-
 arch/arm/mach-sa1100/Kconfig |6 +++---
 arch/arm/mach-sa1100/cpu-sa1100.c|2 +-
 arch/arm/mm/Kconfig  |2 +-
 arch/arm/mm/proc-xscale.S|2 +-
 arch/arm/nwfpe/milieu.h  |4 ++--
 arch/arm/nwfpe/softfloat-macros  |4 ++--
 arch/arm/nwfpe/softfloat-specialize  |4 ++--
 arch/arm/nwfpe/softfloat.c   |4 ++--
 arch/arm/nwfpe/softfloat.h   |4 ++--
 arch/arm/plat-samsung/include/plat/adc.h |2 +-
 arch/avr32/Kconfig   |2 +-
 arch/h8300/Kconfig.cpu   |   12 ++--
 arch/h8300/README|6 +++---
 arch/m32r/Kconfig|2 +-
 arch/m68k/mac/macboing.c |3 ++-
 arch/m68k/q40/README |2 +-
 arch/mips/Kconfig|   12 
 arch/mips/math-emu/cp1emu.c  |1 -
 arch/mips/math-emu/dp_add.c  |1 -
 arch/mips/math-emu/dp_cmp.c  |1 -
 arch/mips/math-emu/dp_div.c  |1 -
 arch/mips/math-emu/dp_fint.c |1 -
 arch/mips/math-emu/dp_flong.c|1 -
 arch/mips/math-emu/dp_frexp.c|1 -
 arch/mips/math-emu/dp_fsp.c  |1 -
 arch/mips/math-emu/dp_logb.c |1 -
 arch/mips/math-emu/dp_modf.c |1 -
 arch/mips/math-emu/dp_mul.c  |1 -
 arch/mips/math-emu/dp_scalb.c|1 -
 arch/mips/math-emu/dp_simple.c   |1 -
 arch/mips/math-emu/dp_sqrt.c |1 -
 arch/mips/math-emu/dp_sub.c  |1 -
 arch/mips/math-emu/dp_tint.c |1 -
 arch/mips/math-emu/dp_tlong.c|1 -
 arch/mips/math-emu/ieee754.c |1 -
 arch/mips/math-emu/ieee754.h |1 -
 arch/mips/math-emu/ieee754d.c|1 -
 arch/mips/math-emu/ieee754dp.c   |1 -
 arch/mips/math-emu/ieee754dp.h   |1 -
 arch/mips/math-emu/ieee754int.h  |1 -
 arch/mips/math-emu/ieee754m.c|1 -
 arch/mips/math-emu/ieee754sp.c   |1 -
 arch/mips/math-emu/ieee754sp.h   |1 -
 arch/mips/math-emu/ieee754xcpt.c |1 -
 arch/mips/math-emu/sp_add.c  |1 -
 arch/mips/math-emu/sp_cmp.c  |1 -
 arch/mips/math-emu/sp_div.c  |1 -
 arch/mips/math-emu/sp_fdp.c  |1 -
 arch/mips/math-emu/sp_fint.c |1 -
 arch/mips/math-emu/sp_flong.c|1 -
 arch/mips/math-emu/sp_frexp.c|1 -
 arch/mips/math-emu/sp_logb.c |1 -
 arch/mips/math-emu/sp_modf.c |1 -
 arch/mips/math-emu/sp_mul.c  |1 -
 arch/mips/math-emu/sp_scalb.c|1 -
 arch/mips/math-emu/sp_simple.c   |1 -
 arch/mips/math-emu/sp_sqrt.c |1 -
 arch/mips/math-emu/sp_sub.c  |1 -
 arch/mips/math-emu/sp_tint.c |1 -
 arch/mips/math-emu/sp_tlong.c|1 -
 arch/powerpc/include/asm/hydra.h |2 +-
 arch/x86/kernel/apm_32.c |4 ++--
 arch/x86/kernel/microcode_core.c |2 +-
 arch/x86/kernel/microcode_intel.c|2 +-
 72 files changed, 55 insertions(+), 93 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 553b7cf..c562c68 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -647,7 +647,7 @@ config ARCH_S3C2410
select HAVE_S3C2410_I2C
help
  Samsung S3C2410X CPU based systems, such as the Simtec Electronics
- BAST (), the IPAQ 1940 or
+ BAST (), the IPAQ 1940 or
  the Samsung SMDK2410 development board (and derivatives).
 
  Note, the S3C2416 and the S3C2450 are so close that they even share
@@ -1162,7 +1162,7 @@ config SMP
 
  See also ,
   and the SMP-HOWTO available at
- 

RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset

2010-09-21 Thread Paul Walmsley
Hello Vishwa,

Thanks for the info.

a few quick questions:

On Thu, 16 Sep 2010, Sripathy, Vishwanath wrote:

> > -Original Message-
> > From: Paul Walmsley [mailto:p...@pwsan.com]
> > Sent: Thursday, September 16, 2010 3:05 AM
> > 
> > On Tue, 25 May 2010, Reddy, Teerth wrote:
> > 
> > > > -Original Message-
> > > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > > Sent: Wednesday, May 19, 2010 6:03 AM
> > > > To: Reddy, Teerth
> > > >
> > > > On Fri, 23 Apr 2010, Reddy, Teerth wrote:
> > > >
> > > > > From: Teerth Reddy 
> > > > >
> > > > > This patch has the workaround for errata 1.176.
> > 
> > What's the current status of this patch?  Still waiting for an updated
> > version.
>
> We have realized that this errata is not applicable if reset is 
> triggered via dpll3 reset. The rootcasuse of the issues was that incase 
> of warm reset, SDRC is not sensitive to the warm reset, but the 
> interconect is reset on the fly, thus causing a misalignment between 
> SDRC logic, interconect logic and DDR memory state. Hence the workaround 
> was proposed. However, incase of dpll3 reset, sdrc also gets reset. In 
> omap_prcm_arch_reset, system reset is triggered via dpll3 reset, so this 
> WA is not applicable.


1. So by "warm reset," are you referring to the software warm reset 
triggered by GLOBAL_SW_RST, or by another mechanism?

2. If GLOBAL_SW_RST, what do you think about adding a brief comment in the 
code warning people not to use GLOBAL_SW_RST unless they implement the 
Errata 1.176 sequence?


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


Re: [PATCH v6 0/7] OMAP: WDT: Implement WDT in hwmod way

2010-09-21 Thread Paul Walmsley
On Mon, 20 Sep 2010, Tony Lindgren wrote:

> * Kevin Hilman  [100920 13:40]:
> > Tony Lindgren  writes:
> > 
> > > So let's get all the dependencies out of the way and pull them into 
> > > linux-omap
> > > master branch for testing. Sounds like we should base this on Paul's core
> > > hwmod branch and your pm-next.
> > 
> > Yes, those two branches are required as the bare minimum.

Just a quick note - the branch

git://git.pwsan.com/linux-2.6 hwmod_2.6.37

contains the current set of hwmod core patches that I'd like to get 
upstream for 2.6.37.  Will send a pull request tomorrow.

I plan to have a few more branches for 2.6.37 with some SCM, SDRC, clock, 
clockdomain, and powerdomain patches.  Will post those separately and also 
assemble a composite 'for_2.6.37' branch with both the hwmod and the 
clock/clockdomain/powerdomain/SCM/SDRC patches.

regards,


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


Re: [PATCH] OMAP: HWMOD: Handle opt clocks using clk_add_alias

2010-09-21 Thread Paul Walmsley

For the archives:

On Wed, 25 Aug 2010, Cousson, Benoit wrote:

> Re-sent to loml, the original email was sent to lkml...
> 
> On 8/25/2010 1:30 PM, Cousson, Benoit wrote:
> > On 8/25/2010 12:45 PM, Basak, Partha wrote:
> > > 
> > > > From: Cousson, Benoit
> > > > Sent: Tuesday, August 24, 2010 1:45 AM
> > > > 
> > > > Hi Partha,
> > > > 
> > > > On 8/23/2010 5:44 PM, Basak, Partha wrote:
> > > > > From: Basak, Partha
> > > > > 
> > > > > For every optional clock present per hwmod per omap-device, this
> > > > function
> > > > > adds an entry in the clocks list of the form > > > id=role>,
> > > > > if an entry is already present in the list of the form > > > > con-
> > > > id=role>.

A modified version of this patch was queued for merging for 2.6.37; 
details here:

http://www.spinics.net/lists/linux-omap/msg36805.html

Thanks Benoît for reposting the original.


- Paul

Re: [PATCH v2 1/6] SoC Camera: add driver for OMAP1 camera interface

2010-09-21 Thread hermann pitton
Hi,

Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
> On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> 
> > This is a V4L2 driver for TI OMAP1 SoC camera interface.

[snip]

> > +
> > +   } else {
> > +   dev_warn(dev, "%s: unhandled camera interrupt, status == "
> > +   "0x%0x\n", __func__, it_status);
> 
> Please, don't split strings

sorry for any OT interference.

But, are there any new rules out?

Maybe I missed them.

Either way, the above was forced during the last three years.

Not at all ?

Cheers,
Hermann



--
To unsubscribe from this list: send the line "unsubscribe 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: hwmod: Fix softreset for modules with optional clocks

2010-09-21 Thread Paul Walmsley
On Tue, 21 Sep 2010, Benoit Cousson wrote:

> Some modules (like GPIO, DSS...) require optionals clock to be enabled
> in order to complete the sofreset properly.
> Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
> to be enabled before reset. Disabled them once the reset is done.
> 
> TODO:
> For the moment it is very hard to understand from the HW spec, which
> optional clock is needed and which one is not. So the current approach
> will enable all the optional clocks.
> Paul proposed a much finer approach that will allow to tag only the needed
> clock in the optional clock table. This might be doable as soon as we have
> a clear understanding of these dependencies.
> 
> Reported-by: Partha Basak 
> Signed-off-by: Benoit Cousson 
> Cc: Paul Walmsley 
> Cc: Kevin Hilman 

Thanks, queued for 2.6.37 with the pr_debug() change.


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


Re: [PATCH] OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

2010-09-21 Thread Paul Walmsley
On Tue, 21 Sep 2010, Benoit Cousson wrote:

> In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
> Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
> use the SYSC softreset bit to provide the status.
> 
> Other cases might exist:
> - Some IPs like McBSP does have a softreset control but no reset status.
> - Some IPs that represent subsystem, like the DSS, can contains
> a reset status without softreset control. The status is the aggregation
> of all the sub modules reset status.
> 
> - Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
> and replace the previous SYSS_MISSING, that was used to flag IP with
> softreset control but without the SYSSTATUS register, with a specific
> SYSS_HAS_RESET_STATUS flag.
> 
> - MCSPI and MMC contains both programming models, so the legacy one
> will be prevented by removing the syss offset field that become useless.

Thanks, queued this for 2.6.37.


- 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 5/5] OMAP: hwmod: improve documentation, clean up function names

2010-09-21 Thread Paul Walmsley
This patch:

- adds more documentation to the hwmod code

- fixes some documentation typos elsewhere in the file

- changes the _sysc_*() function names to appear in (verb, noun) order,
  to match the rest of the function names.

This patch should not result in any functional change.

Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Benoît Cousson 
---
 arch/arm/mach-omap2/omap_hwmod.c |  141 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   11 +-
 2 files changed, 123 insertions(+), 29 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3f3d61a..52f2fb9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -13,10 +13,102 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  *
- * This code manages "OMAP modules" (on-chip devices) and their
- * integration with Linux device driver and bus code.
- *
- * References:
+ * Introduction
+ * 
+ * One way to view an OMAP SoC is as a collection of largely unrelated
+ * IP blocks connected by interconnects.  The IP blocks include
+ * devices such as ARM processors, audio serial interfaces, UARTs,
+ * etc.  Some of these devices, like the DSP, are created by TI;
+ * others, like the SGX, largely originate from external vendors.  In
+ * TI's documentation, on-chip devices are referred to as "OMAP
+ * modules."  Some of these IP blocks are identical across several
+ * OMAP versions.  Others are revised frequently.
+ *
+ * These OMAP modules are tied together by various interconnects.
+ * Most of the address and data flow between modules is via OCP-based
+ * interconnects such as the L3 and L4 buses; but there are other
+ * interconnects that distribute the hardware clock tree, handle idle
+ * and reset signaling, supply power, and connect the modules to
+ * various pads or balls on the OMAP package.
+ *
+ * OMAP hwmod provides a consistent way to describe the on-chip
+ * hardware blocks and their integration into the rest of the chip.
+ * This description can be automatically generated from the TI
+ * hardware database.  OMAP hwmod provides a standard, consistent API
+ * to reset, enable, idle, and disable these hardware blocks.  And
+ * hwmod provides a way for other core code, such as the Linux device
+ * code or the OMAP power management and address space mapping code,
+ * to query the hardware database.
+ *
+ * Using hwmod
+ * ---
+ * Drivers won't call hwmod functions directly.  That is done by the
+ * omap_device code, and in rare occasions, by custom integration code
+ * in arch/arm/ *omap*.  The omap_device code includes functions to
+ * build a struct platform_device using omap_hwmod data, and that is
+ * currently how hwmod data is communicated to drivers and to the
+ * Linux driver model.  Most drivers will call omap_hwmod functions only
+ * indirectly, via pm_runtime*() functions.
+ *
+ * From a layering perspective, here is where the OMAP hwmod code
+ * fits into the kernel software stack:
+ *
+ *+---+
+ *|  Device driver code   |
+ *|  (e.g., drivers/) |
+ *+---+
+ *|  Linux driver model   |
+ *| (platform_device /|
+ *|  platform_driver data/code)   |
+ *+---+
+ *| OMAP core-driver integration  |
+ *|(arch/arm/mach-omap2/devices.c)|
+ *+---+
+ *|  omap_device code |
+ *| (../plat-omap/omap_device.c)  |
+ *+---+
+ *   >|omap_hwmod code/data   |<-
+ *| (../mach-omap2/omap_hwmod*)   |
+ *+---+
+ *| OMAP clock/PRCM/register fns  |
+ *| (__raw_{read,write}l, clk*)   |
+ *+---+
+ *
+ * Device drivers should not contain any OMAP-specific code or data in
+ * them.  They should only contain code to operate the IP block that
+ * the driver is responsible for.  This is because these IP blocks can
+ * also appear in other SoCs, either from TI (such as DaVinci) or from
+ * other manufacturers; and drivers should be reusable across other
+ * platforms.
+ *
+ * The OMAP hwmod code also will attempt to reset and idle all on-chip
+ * devices upon boot.  The goal here is for the kernel to be
+ * completely self-reliant and independent from bootloaders.  This is
+ * to ensure a repeatable configuration, both to ensure consistent
+ * runtime behavior, and to make it easier for others to reproduce
+ * bugs.
+ *
+ * OMAP module activity states
+ * ---
+ * The hwmod code considers modules to be in one of several activity
+ * states.  IP blocks start out 

[PATCH 2/5] OMAP: hwmod: Fix softreset for modules with optional clocks

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.

Reported-by: Partha Basak 
Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |   51 +++---
 arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5027879..f320cfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -546,6 +546,36 @@ static int _disable_clocks(struct omap_hwmod *oh)
return 0;
 }
 
+static void _enable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_debug("omap_hwmod: enable %s:%s\n", oc->role,
+oc->_clk->name);
+   clk_enable(oc->_clk);
+   }
+}
+
+static void _disable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_debug("omap_hwmod: disable %s:%s\n", oc->role,
+oc->_clk->name);
+   clk_disable(oc->_clk);
+   }
+}
+
 /**
  * _find_mpu_port_index - find hwmod OCP slave port ID intended for MPU use
  * @oh: struct omap_hwmod *
@@ -976,8 +1006,9 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
  */
 static int _reset(struct omap_hwmod *oh)
 {
-   u32 r, v;
+   u32 v;
int c = 0;
+   int ret = 0;
 
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
@@ -990,12 +1021,16 @@ static int _reset(struct omap_hwmod *oh)
return -EINVAL;
}
 
+   /* For some modules, all optionnal clocks need to be enabled as well */
+   if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _enable_optional_clocks(oh);
+
pr_debug("omap_hwmod: %s: resetting\n", oh->name);
 
v = oh->_sysc_cache;
-   r = _set_softreset(oh, &v);
-   if (r)
-   return r;
+   ret = _set_softreset(oh, &v);
+   if (ret)
+   goto dis_opt_clks;
_write_sysconfig(v, oh);
 
if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
@@ -1020,7 +1055,13 @@ static int _reset(struct omap_hwmod *oh)
 * _wait_target_ready() or _reset()
 */
 
-   return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+   ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+
+dis_opt_clks:
+   if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _disable_optional_clocks(oh);
+
+   return ret;
 }
 
 /**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index faa0827..ee53758 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -369,6 +369,10 @@ struct omap_hwmod_omap4_prcm {
  * HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
  * HWMOD_NO_IDLEST : this module does not have idle status - this is the case
  * only for few initiator modules on OMAP2 & 3.
+ * HWMOD_CONTROL_OPT_CLKS_IN_RESET: Enable all optional clocks during reset.
+ * This is needed for devices like DSS that require optional clocks enabled
+ * in order to complete the reset. Optional clocks will be disabled
+ * again after the reset.
  */
 #define HWMOD_SWSUP_SIDLE  (1 << 0)
 #define HWMOD_SWSUP_MSTANDBY   (1 << 1)
@@ -377,6 +381,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_OCP_AUTOIDLE  (1 << 4)
 #define HWMOD_SET_DEFAULT_CLOCKACT (1 << 5)
 #define HWMOD_NO_IDLEST(1 << 6)
+#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
 
 /*
  * omap_hwmod._int_flags definitions


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the bod

[PATCH 4/5] OMAP: hwmod: Handle opt clocks node using clk_add_alias

2010-09-21 Thread Paul Walmsley
From: Partha Basak 

For every optional clock present per hwmod per omap-device, this function
adds an entry in the clocks list of the form ,
if an entry is already present in the list of the form .

The function is called from within the framework inside omap_device_build_ss(),
after omap_device_register.

This allows drivers to get a pointer to its optional clocks based on its role
by calling clk_get(, ).

Link to discussions related to this patch:
http://www.spinics.net/lists/linux-omap/msg34809.html

Signed-off-by: Charulatha V 
Signed-off-by: Partha Basak 
Signed-off-by: Benoit Cousson 
Signed-off-by: Rajendra Nayak 
[p...@pwsan.com: simplified loop iterator; removed the superfluous clk_get(),
 using the clk_get() in clk_add_alias() instead]
Signed-off-by: Paul Walmsley 
Acked-by: Kevin Hilman 
---
 arch/arm/plat-omap/omap_device.c |   43 +-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..ceba58a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -82,6 +82,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -243,6 +244,44 @@ static inline struct omap_device *_find_by_pdev(struct 
platform_device *pdev)
return container_of(pdev, struct omap_device, pdev);
 }
 
+/**
+ * _add_optional_clock_alias - Add clock alias for hwmod optional clocks
+ * @od: struct omap_device *od
+ *
+ * For every optional clock present per hwmod per omap_device, this function
+ * adds an entry in the clocks list of the form 
+ * if an entry is already present in it with the form 
+ *
+ * The function is called from inside omap_device_build_ss(), after
+ * omap_device_register.
+ *
+ * This allows drivers to get a pointer to its optional clocks based on its 
role
+ * by calling clk_get(, ).
+ *
+ * No return value.
+ */
+static void _add_optional_clock_alias(struct omap_device *od,
+ struct omap_hwmod *oh)
+{
+   int i;
+
+   for (i = 0; i < oh->opt_clks_cnt; i++) {
+   struct omap_hwmod_opt_clk *oc;
+   int r;
+
+   oc = &oh->opt_clks[i];
+
+   if (!oc->_clk)
+   continue;
+
+   r = clk_add_alias(oc->role, dev_name(&od->pdev.dev),
+ (char *)oc->clk, &od->pdev.dev);
+   if (r)
+   pr_err("omap_device: %s: clk_add_alias for %s failed\n",
+  dev_name(&od->pdev.dev), oc->role);
+   }
+}
+
 
 /* Public functions for use by core code */
 
@@ -421,8 +460,10 @@ struct omap_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
else
ret = omap_device_register(od);
 
-   for (i = 0; i < oh_cnt; i++)
+   for (i = 0; i < oh_cnt; i++) {
hwmods[i]->od = od;
+   _add_optional_clock_alias(od, hwmods[i]);
+   }
 
if (ret)
goto odbs_exit4;


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


[PATCH 3/5] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Paul Walmsley
From: Rajendra Nayak 

If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.

The thread "[PATCH 7/8] : Hwmod api changes" archived here:

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

has additional technical information on the rationale of this patch.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Partha Basak 
Signed-off-by: Benoît Cousson 
[p...@pwsan.com: revised patch description]
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f320cfb..3f3d61a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -691,8 +691,6 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_module_autoidle(oh, idlemode, &v);
}
 
-   /* XXX OCP ENAWAKEUP bit? */
-
/*
 * XXX The clock framework should handle this, by
 * calling into this code.  But this must wait until the
@@ -703,6 +701,10 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
 
_write_sysconfig(v, oh);
+
+   /* If slave is in SMARTIDLE, also enable wakeup */
+   if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
+   _enable_wakeup(oh);
 }
 
 /**


--
To unsubscribe from this list: send the line "unsubscribe 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: hwmod: second set of core patches for 2.6.37

2010-09-21 Thread Paul Walmsley
Hello,

Here are a few more hwmod core patches, intended for merging via
Tony's tree for 2.6.37.

I've added these patches to the existing hwmod core series, available
via git at

git://git.pwsan.com/linux-2.6 hwmod_2.6.37

based on v2.6.36-rc5.


regards,

- Paul

---

Benoit Cousson (2):
  OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs
  OMAP: hwmod: Fix softreset for modules with optional clocks

Partha Basak (1):
  OMAP: hwmod: Handle opt clocks node using clk_add_alias

Paul Walmsley (1):
  OMAP: hwmod: improve documentation, clean up function names

Rajendra Nayak (1):
  OMAP: hwmod: Enable module wakeup if in smartidle


 arch/arm/mach-omap2/omap_hwmod.c |  220 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   19 +-
 arch/arm/plat-omap/omap_device.c |   43 +
 3 files changed, 239 insertions(+), 43 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] OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.

Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.

- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.

- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.

Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/omap_hwmod.c |   22 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |3 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8c27923..5027879 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -967,6 +967,12 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
  * enabled for this to work.  Returns -EINVAL if the hwmod cannot be
  * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
  * the module did not reset in time, or 0 upon success.
+ *
+ * In OMAP3 a specific SYSSTATUS register is used to get the reset status.
+ * Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
+ * use the SYSCONFIG softreset bit to provide the status.
+ *
+ * Note that some IP like McBSP does have a reset control but no reset status.
  */
 static int _reset(struct omap_hwmod *oh)
 {
@@ -974,8 +980,7 @@ static int _reset(struct omap_hwmod *oh)
int c = 0;
 
if (!oh->class->sysc ||
-   !(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET) ||
-   (oh->class->sysc->sysc_flags & SYSS_MISSING))
+   !(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
return -EINVAL;
 
/* clocks must be on for this operation */
@@ -993,9 +998,16 @@ static int _reset(struct omap_hwmod *oh)
return r;
_write_sysconfig(v, oh);
 
-   omap_test_timeout((omap_hwmod_readl(oh, oh->class->sysc->syss_offs) &
-  SYSS_RESETDONE_MASK),
- MAX_MODULE_SOFTRESET_WAIT, c);
+   if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
+   omap_test_timeout((omap_hwmod_readl(oh,
+   oh->class->sysc->syss_offs)
+  & SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+   else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS)
+   omap_test_timeout(!(omap_hwmod_readl(oh,
+oh->class->sysc->sysc_offs)
+  & SYSC_TYPE2_SOFTRESET_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
 
if (c == MAX_MODULE_SOFTRESET_WAIT)
pr_warning("omap_hwmod: %s: softreset failed (waited %d 
usec)\n",
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7fde44d..faa0827 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -251,8 +251,9 @@ struct omap_hwmod_ocp_if {
 #define SYSC_HAS_CLOCKACTIVITY (1 << 4)
 #define SYSC_HAS_SIDLEMODE (1 << 5)
 #define SYSC_HAS_MIDLEMODE (1 << 6)
-#define SYSS_MISSING   (1 << 7)
+#define SYSS_HAS_RESET_STATUS  (1 << 7)
 #define SYSC_NO_CACHE  (1 << 8)  /* XXX SW flag, belongs elsewhere */
+#define SYSC_HAS_RESET_STATUS  (1 << 9)
 
 /* omap_hwmod_sysconfig.clockact flags */
 #define CLOCKACT_TEST_BOTH 0x0


--
To unsubscribe from this list: send the line "unsubscribe 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 v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way

2010-09-21 Thread Kevin Hilman
Kevin Hilman  writes:

> Kevin Hilman  writes:
>
>> "Varadarajan, Charulatha"  writes:
>>
 
 "Varadarajan, Charulatha"  writes:
 
 > This patch series makes OMAP2PLUS specific GPIO implemented in hwmod
 > FW way. This is done by implementing GPIO module in platform device
 model.
 >
 > This patch series is generated on "origin/pm-wip/pm-core" which
 > has Kevin's pm-next series, the runtime PM core patch series,
 > and a collection of hwmod fixes that Paul/Benoit have lined up
 > for 2.6.37.
 >
 > Tested on OMAP2430, OMAP44430, OMAP3430 SDP and zoom3 boards.
 > Also verified that this patch series does not break the OMAP1 build.
 >
 > This patch series is created on top of the following patches:
 > 1. OMAP: HWMOD: Handle opt clocks using clk_add_alias
 > [https://patchwork.kernel.org/patch/124531/]
 > 2. OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
 > [https://patchwork.kernel.org/patch/176172/]
 > 3. OMAP: CPUIDLE: Enable IRQs during device activity check and idle
 management
 > by Kevin
 >
 > This series is tested on OMAP4430 ES2 using the below series
 > http://www.spinics.net/lists/linux-omap/msg36023.html
 
 Hi Charu,
 
 I haven't been fully through the series, but here's some quick feedback
 based on what I tried today.
 
 Basically, I got stuck because the first board I tried it on was the
 35xx-based OMAP3EVM platform, which uses a GPIO-based interrupt for the
 network.  My setup uses DHCP + nfsroot, so the GPIO IRQ must be working
 during boot.
 
 The first thing I noticed, is that GPIO interrupts are not firing during
 boot, so neither the DHCP or the nfsroot works during boot.  I haven't
 been able to fully debug this, but the 3430SDP should have the same
 issue for its smc91x if you set it up for DHCP + nfsroot.  This is
 working fine on my pm-wip/idle-reorg branch which has the prerequisites
 you mentioned, but didn't work when I applied the clk_alias patch plus
 this series.
>>>
>>> I tested this GPIO series in pm-wip/idle-reorg branch with clock
>>> add alias patch and I did not see any issues. I tested with DHCP + nfsroot
>>> on SDP3430. Please provide me some more info on this.
>>
>> Hmm, I don't have many more details yet.  All I can see is that the GPIO
>> bank that has the smc91x interrupt (GPIO6) is loosing interrupts, and
>> thus preventing DHCP and nfsroot from working.
>>
>> Can you test using omap3_defconfig plus 
>>
>> # CONFIG_CPU_FREQ is not set
>> CONFIG_CPU_IDLE=y
>
> Some more details.  I tried on two different 35xx platforms and it works
> on one (es3.1) and not on the other (es2.1):
>
> [0.00] Machine: Gumstix Overo 
>   
> [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
>   
>
> but not on omap3evm:
>
> [0.00] Machine: OMAP3 EVM 
>   
> [0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
>   
>
>
> Is there any chance you could get your hands on an es2.1 EVM and try
> there?
>
> Please contact Sanjeev Premi in TII and I think he should be able to
> find one for you to use temporarily.

I also just tested on n900 which has lots of GPIOs configured.  On this
platform, suspend doesn't hit RET because both GPIO3 and GPIO4 are still
enabled.  

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


Re: [PATCH] i2c-omap: Make sure i2c bus is free before setting it to idle

2010-09-21 Thread Ben Dooks
On Thu, Sep 16, 2010 at 03:40:50PM -0700, Tony Lindgren wrote:
> * Felipe Balbi  [100826 00:34]:
> > Hi,
> > 
> > On Thu, Aug 26, 2010 at 09:36:44AM +0200, Nyman Mathias (Nokia-MS/Helsinki) 
> > wrote:
> > >If the i2c bus receives an interrupt with both BB (bus busy) and
> > >ARDY (register access ready) statuses set during the tranfer of the last 
> > >message
> > >the bus was put to idle while still busy.
> > >
> > >This caused bus to timeout.
> > >
> > >Signed-off-by: Mathias Nyman 
> > 
> > adding linux-i2c and Ben Dooks to Cc list.
> 
> Ben, can you please take this? The patchwork.kernel.org link is:

thanks, added to for-linus/2636-rc6-i2c

-- 
Ben

Q:  What's a light-year?
A:  One-third less calories than a regular year.

--
To unsubscribe from this list: send the line "unsubscribe 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 v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way

2010-09-21 Thread Kevin Hilman
Kevin Hilman  writes:

> "Varadarajan, Charulatha"  writes:
>
>>> 
>>> "Varadarajan, Charulatha"  writes:
>>> 
>>> > This patch series makes OMAP2PLUS specific GPIO implemented in hwmod
>>> > FW way. This is done by implementing GPIO module in platform device
>>> model.
>>> >
>>> > This patch series is generated on "origin/pm-wip/pm-core" which
>>> > has Kevin's pm-next series, the runtime PM core patch series,
>>> > and a collection of hwmod fixes that Paul/Benoit have lined up
>>> > for 2.6.37.
>>> >
>>> > Tested on OMAP2430, OMAP44430, OMAP3430 SDP and zoom3 boards.
>>> > Also verified that this patch series does not break the OMAP1 build.
>>> >
>>> > This patch series is created on top of the following patches:
>>> > 1. OMAP: HWMOD: Handle opt clocks using clk_add_alias
>>> > [https://patchwork.kernel.org/patch/124531/]
>>> > 2. OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
>>> > [https://patchwork.kernel.org/patch/176172/]
>>> > 3. OMAP: CPUIDLE: Enable IRQs during device activity check and idle
>>> management
>>> > by Kevin
>>> >
>>> > This series is tested on OMAP4430 ES2 using the below series
>>> > http://www.spinics.net/lists/linux-omap/msg36023.html
>>> 
>>> Hi Charu,
>>> 
>>> I haven't been fully through the series, but here's some quick feedback
>>> based on what I tried today.
>>> 
>>> Basically, I got stuck because the first board I tried it on was the
>>> 35xx-based OMAP3EVM platform, which uses a GPIO-based interrupt for the
>>> network.  My setup uses DHCP + nfsroot, so the GPIO IRQ must be working
>>> during boot.
>>> 
>>> The first thing I noticed, is that GPIO interrupts are not firing during
>>> boot, so neither the DHCP or the nfsroot works during boot.  I haven't
>>> been able to fully debug this, but the 3430SDP should have the same
>>> issue for its smc91x if you set it up for DHCP + nfsroot.  This is
>>> working fine on my pm-wip/idle-reorg branch which has the prerequisites
>>> you mentioned, but didn't work when I applied the clk_alias patch plus
>>> this series.
>>
>> I tested this GPIO series in pm-wip/idle-reorg branch with clock
>> add alias patch and I did not see any issues. I tested with DHCP + nfsroot
>> on SDP3430. Please provide me some more info on this.
>
> Hmm, I don't have many more details yet.  All I can see is that the GPIO
> bank that has the smc91x interrupt (GPIO6) is loosing interrupts, and
> thus preventing DHCP and nfsroot from working.
>
> Can you test using omap3_defconfig plus 
>
> # CONFIG_CPU_FREQ is not set
> CONFIG_CPU_IDLE=y

Some more details.  I tried on two different 35xx platforms and it works
on one (es3.1) and not on the other (es2.1):

[0.00] Machine: Gumstix Overo   
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )  

but not on omap3evm:

[0.00] Machine: OMAP3 EVM   
[0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )  


Is there any chance you could get your hands on an es2.1 EVM and try
there?

Please contact Sanjeev Premi in TII and I think he should be able to
find one for you to use temporarily.

Thanks,

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


Re: [PATCH v6 07/13] OMAP3: hwmod data: Add GPIO

2010-09-21 Thread Kevin Hilman
"Varadarajan, Charulatha"  writes:

> Add GPIO hwmod data for OMAP3 chip
>
> Signed-off-by: Charulatha V 
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  364 
> 
>  1 files changed, 364 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 5d8eb58..43ed2ab 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "omap_hwmod_common_data.h"
>  
> @@ -36,6 +37,12 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
>  static struct omap_hwmod omap3xxx_l3_main_hwmod;
>  static struct omap_hwmod omap3xxx_l4_core_hwmod;
>  static struct omap_hwmod omap3xxx_l4_per_hwmod;
> +static struct omap_hwmod omap3xxx_gpio1_hwmod;
> +static struct omap_hwmod omap3xxx_gpio2_hwmod;
> +static struct omap_hwmod omap3xxx_gpio3_hwmod;
> +static struct omap_hwmod omap3xxx_gpio4_hwmod;
> +static struct omap_hwmod omap3xxx_gpio5_hwmod;
> +static struct omap_hwmod omap3xxx_gpio6_hwmod;
>  
>  /* L3 -> L4_CORE interface */
>  static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
> @@ -197,6 +204,357 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
>   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
>  };
>  
> +/* l4_wkup -> gpio1 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio1_addrs[] = {
> + {
> + .pa_start   = 0x4831,
> + .pa_end = 0x483101ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__gpio1 = {
> + .master = &omap3xxx_l4_wkup_hwmod,
> + .slave  = &omap3xxx_gpio1_hwmod,
> + .clk= "gpio1_ick",
> + .addr   = omap3xxx_gpio1_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio1_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* l4_per -> gpio2 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio2_addrs[] = {
> + {
> + .pa_start   = 0x4905,
> + .pa_end = 0x490501ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio2 = {
> + .master = &omap3xxx_l4_per_hwmod,
> + .slave  = &omap3xxx_gpio2_hwmod,
> + .clk= "gpio2_ick",
> + .addr   = omap3xxx_gpio2_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio2_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* l4_per -> gpio3 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio3_addrs[] = {
> + {
> + .pa_start   = 0x49052000,
> + .pa_end = 0x490521ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio3 = {
> + .master = &omap3xxx_l4_per_hwmod,
> + .slave  = &omap3xxx_gpio3_hwmod,
> + .clk= "gpio3_ick",
> + .addr   = omap3xxx_gpio3_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio3_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* l4_per -> gpio4 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
> + {
> + .pa_start   = 0x49054000,
> + .pa_end = 0x490541ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio4 = {
> + .master = &omap3xxx_l4_per_hwmod,
> + .slave  = &omap3xxx_gpio4_hwmod,
> + .clk= "gpio4_ick",
> + .addr   = omap3xxx_gpio4_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio4_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* l4_per -> gpio5 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio5_addrs[] = {
> + {
> + .pa_start   = 0x49056000,
> + .pa_end = 0x490561ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio5 = {
> + .master = &omap3xxx_l4_per_hwmod,
> + .slave  = &omap3xxx_gpio5_hwmod,
> + .clk= "gpio5_ick",
> + .addr   = omap3xxx_gpio5_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap3xxx_gpio5_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* l4_per -> gpio6 */
> +static struct omap_hwmod_addr_space omap3xxx_gpio6_addrs[] = {
> + {
> + .pa_start   = 0x49058000,
> + .pa_end = 0x490581ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_per__gpio6 = {
> + .master = &omap3xxx_l4_per_hwmod,
> + .slave  = &omap3xxx_gpi

Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Kevin Hilman
Paul Walmsley  writes:

> On Tue, 21 Sep 2010, Kevin Hilman wrote:
>
>> Paul Walmsley  writes:
>> 
>> > On Tue, 21 Sep 2010, Kevin Hilman wrote:
>> >
>> >> FWIW
>> >> 
>> >> Acked-by: Kevin Hilman 
>> >> 
>> >> as I'm using this for testing the various hwmod conversions.
>> >
>> > Thanks Kevin, added that in.  I know you've been testing some of the other 
>> > patches here too, so please let me know if you would like Tested-by:'s or 
>> > Acked-by:'s there.
>> 
>> I guess you can put a Tested-by for me on everything in your
>> hwmod_2.6.37 branch as I've been staging and testing those for a bit
>> now.
>
> OK, sounds good.  How about the updated hardreset code - have you given 
> that a try?

I just rebased onto your hwmod_2.6.37 branch, so testing it today.

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


Re: [PATCH v7 4/6] OMAP4: hwmod data: Add watchdog timer

2010-09-21 Thread Cousson, Benoit

Hi Charu,

On 9/21/2010 3:37 PM, Varadarajan, Charulatha wrote:

From: Benoit Cousson

Add watchdog timer hwmod data for OMAP4 chip

Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  135 
  1 files changed, 135 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 e20b0ee..8660fea 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,136 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
  };

+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_SOFTRESET),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields=&omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+   .name = "wd_timer",
+   .sysc =&omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+   { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+   {
+   .pa_start   = 0x4a314000,
+   .pa_end = 0x4a31407f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup ->  wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+   .master =&omap44xx_l4_wkup_hwmod,
+   .slave  =&omap44xx_wd_timer2_hwmod,
+   .clk= "l4_wkup_clk_mux_ck",
+   .addr   = omap44xx_wd_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+   &omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+   .name   = "wd_timer2",
+   .class  =&omap44xx_wd_timer_hwmod_class,
+   .mpu_irqs   = omap44xx_wd_timer2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+   .main_clk   = "wd_timer2_fck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_wd_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* wd_timer3 */
+static struct omap_hwmod omap44xx_wd_timer3_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer3_irqs[] = {
+   { .irq = 36 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer3_addrs[] = {
+   {
+   .pa_start   = 0x4013,
+   .pa_end = 0x4013007f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_abe ->  wd_timer3 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__wd_timer3 = {
+   .master =&omap44xx_l4_abe_hwmod,
+   .slave  =&omap44xx_wd_timer3_hwmod,
+   .clk= "ocp_abe_iclk",
+   .addr   = omap44xx_wd_timer3_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_wd_timer3_addrs),
+   .user   = OCP_USER_MPU,
+};
+
+/* l4_abe ->  wd_timer3 (dma) */
+static struct omap_hwmod_addr_space omap44xx_wd_timer3_dma_addrs[] = {
+   {
+   .pa_start   = 0x4903,
+   .pa_end = 0x4903007f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__wd_timer3_dma = {
+   .master =&omap44xx_l4_abe_hwmod,
+   .slave  =&omap44xx_wd_timer3_hwmod,
+   .clk= "ocp_abe_iclk",
+   .addr   = omap44xx_wd_timer3_dma_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_wd_timer3_dma_addrs),
+   .user   = OCP_USER_SDMA,
+};
+
+/* wd_timer3 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer3_slaves[] = {
+   &omap44xx_l4_abe__wd_timer3,
+   &omap44xx_l4_abe__wd_timer3_dma,
+};
+
+static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
+   .name   = "wd_timer3",
+   .class  =&omap44xx_wd_timer_hwmod_class,
+   .mpu_irqs   = omap44xx_wd_timer3_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_wd_timer3_irqs),
+   .main_clk   = "wd_timer3_fck",
+   .prcm = {
+   .omap4 =

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

2010-09-21 Thread David Anders
The OMAP4 PandaBoard has EHCI port1 hooked up to an external
SMSC3320 transciever. GPIO 1 is used to power on the transceiver
and GPIO 62 for reset on the transceiver.

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

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

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


[PATCH 1/4] omap4: pandaboard: remove unused hsmmc definition

2010-09-21 Thread David Anders
remove the second hsmmc definition as it is only used on the
expansion header of the PandaBoard and can be mux for other
functions.

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

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 96f5bbb..093d13b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -67,10 +67,6 @@ static struct regulator_consumer_supply 
omap4_panda_vmmc_supply[] = {
.supply = "vmmc",
.dev_name = "mmci-omap-hs.0",
},
-   {
-   .supply = "vmmc",
-   .dev_name = "mmci-omap-hs.1",
-   },
 };
 
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
@@ -156,7 +152,7 @@ static struct regulator_init_data omap4_panda_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 2,
+   .num_consumer_supplies  = 1,
.consumer_supplies  = omap4_panda_vmmc_supply,
 };
 
-- 
1.7.0.4

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


[PATCH 2/4] omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set

2010-09-21 Thread David Anders
Avoid possible crash if CONFIG_MMC_OMAP_HS is not set.

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

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

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


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

2010-09-21 Thread David Anders
Adding card detect callback function and card detect configuration
function for MMC1 Controller.

Signed-off-by: David Anders 
Signed-off-by: Anand Gadiyar 
---

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

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

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

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


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

2010-09-21 Thread David Anders
PandaBoard machine file related cleanups.

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

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

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


Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Paul Walmsley
On Tue, 21 Sep 2010, Kevin Hilman wrote:

> Paul Walmsley  writes:
> 
> > On Tue, 21 Sep 2010, Kevin Hilman wrote:
> >
> >> FWIW
> >> 
> >> Acked-by: Kevin Hilman 
> >> 
> >> as I'm using this for testing the various hwmod conversions.
> >
> > Thanks Kevin, added that in.  I know you've been testing some of the other 
> > patches here too, so please let me know if you would like Tested-by:'s or 
> > Acked-by:'s there.
> 
> I guess you can put a Tested-by for me on everything in your
> hwmod_2.6.37 branch as I've been staging and testing those for a bit
> now.

OK, sounds good.  How about the updated hardreset code - have you given 
that a try?

> Also, one other thing I noticed in that branch: the locking patch from
> me:
> 
>OMAP: hwmod: separate list locking and hwmod hardware locking
> 
> has a stray '[PATCH]' in the shortlog which should probably be removed
> as well.

Thanks, fixed.


- 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] OMAP4: clock: Add optional clock nodes

2010-09-21 Thread Benoit Cousson
OMAP4 IP optional clocks require explicit enable in module CTRLCLK
register. In order to allow that we have to create artificial clock
nodes that represent this clock inputs in the IP.

Signed-off-by: Benoit Cousson 
Cc: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/clock44xx_data.c |  893 --
 1 files changed, 625 insertions(+), 268 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index a0e369e..e2cffcc 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1283,6 +1283,16 @@ static struct clk aess_fck = {
.recalc = &followparent_recalc,
 };
 
+static struct clk bandgap_fclk = {
+   .name   = "bandgap_fclk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_BGAP_32K_SHIFT,
+   .clkdm_name = "l4_wkup_clkdm",
+   .parent = &sys_32k_ck,
+   .recalc = &followparent_recalc,
+};
+
 static struct clk des3des_fck = {
.name   = "des3des_fck",
.ops= &clkops_omap2_dflt,
@@ -1343,6 +1353,46 @@ static struct clk dsp_fck = {
.recalc = &followparent_recalc,
 };
 
+static struct clk dss_sys_clk = {
+   .name   = "dss_sys_clk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT,
+   .clkdm_name = "l3_dss_clkdm",
+   .parent = &syc_clk_div_ck,
+   .recalc = &followparent_recalc,
+};
+
+static struct clk dss_tv_clk = {
+   .name   = "dss_tv_clk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_TV_CLK_SHIFT,
+   .clkdm_name = "l3_dss_clkdm",
+   .parent = &extalt_clkin_ck,
+   .recalc = &followparent_recalc,
+};
+
+static struct clk dss_dss_clk = {
+   .name   = "dss_dss_clk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_DSSCLK_SHIFT,
+   .clkdm_name = "l3_dss_clkdm",
+   .parent = &dpll_per_m5_ck,
+   .recalc = &followparent_recalc,
+};
+
+static struct clk dss_48mhz_clk = {
+   .name   = "dss_48mhz_clk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_48MHZ_CLK_SHIFT,
+   .clkdm_name = "l3_dss_clkdm",
+   .parent = &func_48mc_fclk,
+   .recalc = &followparent_recalc,
+};
+
 static struct clk dss_fck = {
.name   = "dss_fck",
.ops= &clkops_omap2_dflt,
@@ -1416,6 +1466,16 @@ static struct clk fpka_fck = {
.recalc = &followparent_recalc,
 };
 
+static struct clk gpio1_dbclk = {
+   .name   = "gpio1_dbclk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
+   .clkdm_name = "l4_wkup_clkdm",
+   .parent = &sys_32k_ck,
+   .recalc = &followparent_recalc,
+};
+
 static struct clk gpio1_ick = {
.name   = "gpio1_ick",
.ops= &clkops_omap2_dflt,
@@ -1426,6 +1486,16 @@ static struct clk gpio1_ick = {
.recalc = &followparent_recalc,
 };
 
+static struct clk gpio2_dbclk = {
+   .name   = "gpio2_dbclk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_L4PER_GPIO2_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
+   .clkdm_name = "l4_per_clkdm",
+   .parent = &sys_32k_ck,
+   .recalc = &followparent_recalc,
+};
+
 static struct clk gpio2_ick = {
.name   = "gpio2_ick",
.ops= &clkops_omap2_dflt,
@@ -1436,6 +1506,16 @@ static struct clk gpio2_ick = {
.recalc = &followparent_recalc,
 };
 
+static struct clk gpio3_dbclk = {
+   .name   = "gpio3_dbclk",
+   .ops= &clkops_omap2_dflt,
+   .enable_reg = OMAP4430_CM_L4PER_GPIO3_CLKCTRL,
+   .enable_bit = OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
+   .clkdm_name = "l4_per_clkdm",
+   .parent = &sys_32k_ck,
+   .recalc = &followparent_recalc,
+};
+
 static struct clk gpio3_ick = {
.name   = "gpio3_ick",
.ops= &clkops_omap2_dflt,
@@ -1446,6 +1526,16 @@ static struct clk gpio3_ick = {
.recalc = &followparent_recalc,
 };
 
+static struct clk gpio4_dbclk = {
+   .name   = "gpio4_dbclk",
+   .ops= &clkops_omap2_dflt,
+   

[PATCH] OMAP4: clock: Fix missing optional clocks

2010-09-21 Thread Benoit Cousson
Hi Paul,

The previous OMAP4 clock data did not contain the nodes to allow the modules
to enable the proper bit in the CLKCTRL register.

This patch is based on kevin/pm-wip/hwmods-omap4 rebased on top of your 
hwmod_hardreset_dev branch + my reset-fixes series + Partha's patch...
...and that's all.

This is also available here:
git://gitorious.org/omap-pm/linux.git pm-wip/hwmods-clocks

The pm-wip/hwmods-omap4-full will be then rebased on this branch.

Please note that the diff is pretty bad for the clock table. It looks like
everything has changed. I don't know if there is a way to have a better diff
with git.

Thanks,
Benoit


Benoit Cousson (1):
  OMAP4: clock: Add optional clock nodes

 arch/arm/mach-omap2/clock44xx_data.c |  893 --
 1 files changed, 625 insertions(+), 268 deletions(-)

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


Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Kevin Hilman
Paul Walmsley  writes:

> On Tue, 21 Sep 2010, Kevin Hilman wrote:
>
>> FWIW
>> 
>> Acked-by: Kevin Hilman 
>> 
>> as I'm using this for testing the various hwmod conversions.
>
> Thanks Kevin, added that in.  I know you've been testing some of the other 
> patches here too, so please let me know if you would like Tested-by:'s or 
> Acked-by:'s there.

I guess you can put a Tested-by for me on everything in your
hwmod_2.6.37 branch as I've been staging and testing those for a bit
now.

Also, one other thing I noticed in that branch: the locking patch from
me:

   OMAP: hwmod: separate list locking and hwmod hardware locking

has a stray '[PATCH]' in the shortlog which should probably be removed
as well.

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


Re: [PATCH] OMAP: hwmod: Handle opt clocks node using clk_add_alias

2010-09-21 Thread Paul Walmsley
Hi Partha, Benoît,

On Tue, 21 Sep 2010, Benoit Cousson wrote:

> From: Basak, Partha 
> 
> For every optional clock present per hwmod per omap-device, this function
> adds an entry in the clocks list of the form ,
> if an entry is already present in the list of the form  con-id=role>.
> 
> The function is called from within the framework inside 
> omap_device_build_ss(),
> after omap_device_register.
> 
> This allows drivers to get a pointer to its optional clocks based on its role
> by calling clk_get(, ).
> 
> Link to discussions related to this patch:
> http://www.spinics.net/lists/linux-omap/msg34809.html

I've queued a modified version of this patch for 2.6.37 with a few 
changes.  The modified version is below.  Could you please test 
it at your earliest opportunity and also comment as to your opinion on the 
changes?

The major changes are:

- Remove the secondary index in the for() and convert to an array index in 
the loop body (I once was bit by a difficult-to-find bug with pointer 
arithmetic with a secondary index, so am a little gun-shy of such code; 
plus I think the array index is easier to read)

- Walk the omap_hwmod_opt_clks in order, rather than in reverse

- Remove the clk_get() test, since clk_add_alias() does it for us if the 
'dev' parameter is supplied

- Supply a 'dev' parameter for clk_add_alias() (see the above)

- Continue iterating the loop even if one of the opt clks was not 
resolved during init, rather than bailing out immediately


- Paul


From: Basak, Partha 
Date: Tue, 21 Sep 2010 19:23:04 +0200
Subject: [PATCH] OMAP: hwmod: Handle opt clocks node using clk_add_alias

For every optional clock present per hwmod per omap-device, this function
adds an entry in the clocks list of the form ,
if an entry is already present in the list of the form .

The function is called from within the framework inside omap_device_build_ss(),
after omap_device_register.

This allows drivers to get a pointer to its optional clocks based on its role
by calling clk_get(, ).

Link to discussions related to this patch:
http://www.spinics.net/lists/linux-omap/msg34809.html

Signed-off-by: Charulatha V 
Signed-off-by: Basak, Partha 
Signed-off-by: Benoit Cousson 
Signed-off-by: Rajendra Nayak 
[p...@pwsan.com: simplified loop iterator; removed the superfluous clk_get(),
 using the clk_get() in clk_add_alias() instead]
Signed-off-by: Paul Walmsley 
Acked-by: Kevin Hilman 
---
 arch/arm/plat-omap/omap_device.c |   43 +-
 1 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..ceba58a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -82,6 +82,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -243,6 +244,44 @@ static inline struct omap_device *_find_by_pdev(struct 
platform_device *pdev)
return container_of(pdev, struct omap_device, pdev);
 }
 
+/**
+ * _add_optional_clock_alias - Add clock alias for hwmod optional clocks
+ * @od: struct omap_device *od
+ *
+ * For every optional clock present per hwmod per omap_device, this function
+ * adds an entry in the clocks list of the form 
+ * if an entry is already present in it with the form 
+ *
+ * The function is called from inside omap_device_build_ss(), after
+ * omap_device_register.
+ *
+ * This allows drivers to get a pointer to its optional clocks based on its 
role
+ * by calling clk_get(, ).
+ *
+ * No return value.
+ */
+static void _add_optional_clock_alias(struct omap_device *od,
+ struct omap_hwmod *oh)
+{
+   int i;
+
+   for (i = 0; i < oh->opt_clks_cnt; i++) {
+   struct omap_hwmod_opt_clk *oc;
+   int r;
+
+   oc = &oh->opt_clks[i];
+
+   if (!oc->_clk)
+   continue;
+
+   r = clk_add_alias(oc->role, dev_name(&od->pdev.dev),
+ (char *)oc->clk, &od->pdev.dev);
+   if (r)
+   pr_err("omap_device: %s: clk_add_alias for %s failed\n",
+  dev_name(&od->pdev.dev), oc->role);
+   }
+}
+
 
 /* Public functions for use by core code */
 
@@ -421,8 +460,10 @@ struct omap_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
else
ret = omap_device_register(od);
 
-   for (i = 0; i < oh_cnt; i++)
+   for (i = 0; i < oh_cnt; i++) {
hwmods[i]->od = od;
+   _add_optional_clock_alias(od, hwmods[i]);
+   }
 
if (ret)
goto odbs_exit4;
-- 
1.7.1

Re: [PATCH] usb: omap: ohci: Missing driver unregister in module exit

2010-09-21 Thread Greg KH
On Fri, Sep 17, 2010 at 09:43:16AM +0300, Felipe Balbi wrote:
> On Thu, Sep 16, 2010 at 06:39:20AM -0500, Munegowda, Keshava wrote:
> >>-Original Message-
> >>From: Munegowda, Keshava
> >>Sent: Tuesday, September 14, 2010 4:40 AM
> >>To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
> >>Cc: Gadiyar, Anand; Kamat, Nishant; Munegowda, Keshava
> >>Subject: [PATCH] usb: omap: ohci: Missing driver unregister in module exit
> >>
> >>The un-registration of OHCI driver was not done in
> >>the ohci_hcd_mod_exit function. This was affecting rmmod command not
> >>to work for OMAP3 platforms.
> >>The platform driver un-registration for OMAP3 platforms is perfomed
> >>while removing the OHCI module from kernel.
> >>
> >>Signed-off-by: Keshava Munegowda 
> >>---
> >> drivers/usb/host/ohci-hcd.c |3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >>Index: linux-2.6/drivers/usb/host/ohci-hcd.c
> >>===
> >>--- linux-2.6.orig/drivers/usb/host/ohci-hcd.c
> >>+++ linux-2.6/drivers/usb/host/ohci-hcd.c
> >>@@ -1270,6 +1270,9 @@ static void __exit ohci_hcd_mod_exit(voi
> >> #ifdef PLATFORM_DRIVER
> >>platform_driver_unregister(&PLATFORM_DRIVER);
> >> #endif
> >>+#ifdef OMAP3_PLATFORM_DRIVER
> >>+   platform_driver_unregister(&OMAP3_PLATFORM_DRIVER);
> >>+#endif
> >> #ifdef PS3_SYSTEM_BUS_DRIVER
> >>ps3_ohci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
> >> #endif
> >
> >Hi Greg,
> >Do you any comments on this patch?
> 
> my missing S-O-B, maybe. Here it goes:
> 
> Signed-of-by: Felipe Balbi 

Yup, all good now.

thanks,

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


Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Paul Walmsley
On Tue, 21 Sep 2010, Kevin Hilman wrote:

> FWIW
> 
> Acked-by: Kevin Hilman 
> 
> as I'm using this for testing the various hwmod conversions.

Thanks Kevin, added that in.  I know you've been testing some of the other 
patches here too, so please let me know if you would like Tested-by:'s or 
Acked-by:'s there.


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


Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Kevin Hilman
Paul Walmsley  writes:

> Hi Rajendra,
>
> On Tue, 21 Sep 2010, Rajendra Nayak wrote:
>
>> If a module's OCP slave port is programmed to be in smartidle,
>> its also necessary that they have module level wakeup enabled.
>> Update _sysc_enable in hwmod framework to do this.
>
> Thanks, queued for 2.6.37 with a slightly modified changelog.  One brief 
> comment:
>
>> Signed-off-by: Rajendra Nayak 
>> Signed-off-by: Partha Basak 
>> Signed-off-by: Benot Cousson 
>
> Looks like something in your mail path is mangling 8-bit characters... 
> fixed in the queued version.
>
>
> - Paul
>
>
> From: Rajendra Nayak 
> Date: Tue, 21 Sep 2010 19:58:30 +0530
> Subject: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> If a module's OCP slave port is programmed to be in smartidle,
> its also necessary that they have module level wakeup enabled.
> Update _sysc_enable in hwmod framework to do this.
>
> The thread "[PATCH 7/8] : Hwmod api changes" archived here:
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html
>
> has additional technical information on the rationale of this patch.
>
> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Partha Basak 
> Signed-off-by: Benoît Cousson 
> [p...@pwsan.com: revised patch description]
> Signed-off-by: Paul Walmsley 
> Cc: Kevin Hilman 

FWIW

Acked-by: Kevin Hilman 

as I'm using this for testing the various hwmod conversions.

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


Re: [PATCH 00/11] OMAP: Serial: Add omap-serial driver with platform support

2010-09-21 Thread Kevin Hilman
Govindraj  writes:

> 
>
> Also the patch series updates various low level platform specific
> serial data to support omap-uarts with hwmod framework and adds support
> for uart4 on OMAP3630.

 This series is missing a couple things to work more broadly on all
 boards, specifically 3630-based boards.

 First, due to the current UART idle code base, you need to enable all
 OMAP UARTs 36xx.  Enabling less than all OMAP UARTs will break the
 current idle code.  As we discussed, the next phase we will move the
 idle management from this serial.c hackery into the omap-serial driver
 iteself.  Until then, you need to call omap_serial_init() on
 Zoom2/Zoom3.  Patch below[1]

 Also, you previously had a patch that updated omap_uart_idle_init() to
 handle 36xx and specifically UART4.  Without that, struct
 omap_uart_state is not setup correctly for UART4, and thus cannot be
 properly idled on 3630.
>>>
>>> ok fine, I will I incorporate initialize all uarts patch for zoom boards.
>>>
>>> Are you referring to this patch?
>>> https://patchwork.kernel.org/patch/108066/
>>>
>>> Is this still needed if we have initialized all uarts?
>>> This patch might not needed if we have initialized all uarts right?
>>
>> Right.  We don't need the above patchwork patch if all UARTs are
>> initialized.
>>
>> The other patch I was referring to was the one that added UART4 support
>> to omap_uart_idle_init() (added the wk_en, wk_st, padconf etc.)  I had a
>> pending request for you to drop the muxmode from that patch, but the
>> rest of it was still needed.
>>

 Also, it's been a while since I tested this on OMAP2.  Please re-test on
 OMAP2 with the whole series.  Also, please report here the other
 platforms this was tested on.  The final needs to be tested on OMAP2, 3
 and 4 before merge.
>>>
>>> Yes Sure,
>>>
>>> Just FYI this patch series was also tested on omap2,3,4.
>>>
>>
>> OK, be sure to test Zoom3, because my testing on Zoom3 led to a crash as
>> soon as idle was enabled due to the missing init of all UARTs.
>
>
> This patch series applied on top of pm-core branch
>
> commit 4c1f85cdc189d41ee53c1bc3957a908c91cffc00
> Merge: ca1684b 96c4e27
> Author: Kevin Hilman 
> Date:   Thu Sep 16 15:29:06 2010 -0700
>
> with below changes:
>
> 1) if (uart->timeout)
> uart->timeout = (30 * HZ);
>
> 2) #define DEFAULT_TIMEOUT 5 [temporary change for timeout]

Doing this masks the problem.  If you do 1 without 2, you'll see that
UART4 can never go idle.

Please test without this change and use the sysfs files to enable the
timeouts:

  echo 5 > /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout 
  echo 5 > /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout 
  echo 5 > /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout 
  echo 5 > /sys/devices/platform/omap/omap-hsuart.3/sleep_timeout 

> I see ret count getting incremented on ZOOM3 even without "UART4 support
> to omap_uart_idle_init()" patch.
>
> I dont see any crash.

It has to do more than not crash for this to be acceptable.   All UARTs
need to have the same capabilities.

Currently, UART4 has no padconf, wk_en, or wk_st fields set.  This means
1) it's sysfs entry  doesn't get a 'sleep_timeout' file so it cannot be
made changed and 2) wakeups on UART4 cannot work.

As I said before, you had all this stuff in a previous series.  I only
requested you drop the 'muxmode' stuff from that patch, but everything
else (padconf, wk_en, wk_st) was fine.

Please add this back to the series.

Kevin

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


Re: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Paul Walmsley
Hi Rajendra,

On Tue, 21 Sep 2010, Rajendra Nayak wrote:

> If a module's OCP slave port is programmed to be in smartidle,
> its also necessary that they have module level wakeup enabled.
> Update _sysc_enable in hwmod framework to do this.

Thanks, queued for 2.6.37 with a slightly modified changelog.  One brief 
comment:

> Signed-off-by: Rajendra Nayak 
> Signed-off-by: Partha Basak 
> Signed-off-by: Benot Cousson 

Looks like something in your mail path is mangling 8-bit characters... 
fixed in the queued version.


- Paul


From: Rajendra Nayak 
Date: Tue, 21 Sep 2010 19:58:30 +0530
Subject: [PATCH] OMAP: hwmod: Enable module wakeup if in smartidle
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.

The thread "[PATCH 7/8] : Hwmod api changes" archived here:

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

has additional technical information on the rationale of this patch.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Partha Basak 
Signed-off-by: Benoît Cousson 
[p...@pwsan.com: revised patch description]
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8c27923..d3431bf 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -661,8 +661,6 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_module_autoidle(oh, idlemode, &v);
}
 
-   /* XXX OCP ENAWAKEUP bit? */
-
/*
 * XXX The clock framework should handle this, by
 * calling into this code.  But this must wait until the
@@ -673,6 +671,10 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
 
_write_sysconfig(v, oh);
+
+   /* If slave is in SMARTIDLE, also enable wakeup */
+   if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
+   _enable_wakeup(oh);
 }
 
 /**
-- 
1.7.1


Re: [PATCH v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way

2010-09-21 Thread Kevin Hilman
"Varadarajan, Charulatha"  writes:

>> 
>> "Varadarajan, Charulatha"  writes:
>> 
>> > This patch series makes OMAP2PLUS specific GPIO implemented in hwmod
>> > FW way. This is done by implementing GPIO module in platform device
>> model.
>> >
>> > This patch series is generated on "origin/pm-wip/pm-core" which
>> > has Kevin's pm-next series, the runtime PM core patch series,
>> > and a collection of hwmod fixes that Paul/Benoit have lined up
>> > for 2.6.37.
>> >
>> > Tested on OMAP2430, OMAP44430, OMAP3430 SDP and zoom3 boards.
>> > Also verified that this patch series does not break the OMAP1 build.
>> >
>> > This patch series is created on top of the following patches:
>> > 1. OMAP: HWMOD: Handle opt clocks using clk_add_alias
>> > [https://patchwork.kernel.org/patch/124531/]
>> > 2. OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
>> > [https://patchwork.kernel.org/patch/176172/]
>> > 3. OMAP: CPUIDLE: Enable IRQs during device activity check and idle
>> management
>> > by Kevin
>> >
>> > This series is tested on OMAP4430 ES2 using the below series
>> > http://www.spinics.net/lists/linux-omap/msg36023.html
>> 
>> Hi Charu,
>> 
>> I haven't been fully through the series, but here's some quick feedback
>> based on what I tried today.
>> 
>> Basically, I got stuck because the first board I tried it on was the
>> 35xx-based OMAP3EVM platform, which uses a GPIO-based interrupt for the
>> network.  My setup uses DHCP + nfsroot, so the GPIO IRQ must be working
>> during boot.
>> 
>> The first thing I noticed, is that GPIO interrupts are not firing during
>> boot, so neither the DHCP or the nfsroot works during boot.  I haven't
>> been able to fully debug this, but the 3430SDP should have the same
>> issue for its smc91x if you set it up for DHCP + nfsroot.  This is
>> working fine on my pm-wip/idle-reorg branch which has the prerequisites
>> you mentioned, but didn't work when I applied the clk_alias patch plus
>> this series.
>
> I tested this GPIO series in pm-wip/idle-reorg branch with clock
> add alias patch and I did not see any issues. I tested with DHCP + nfsroot
> on SDP3430. Please provide me some more info on this.

Hmm, I don't have many more details yet.  All I can see is that the GPIO
bank that has the smc91x interrupt (GPIO6) is loosing interrupts, and
thus preventing DHCP and nfsroot from working.

Can you test using omap3_defconfig plus 

# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y

Thanks,

Kevin


>> 
>> The other change when debugging I made was to make the
>> 'workaround_enable' hack bank specific.  Now that the bank idles can be
>> called independetly, this would get cleared as soon as one of the banks
>> clears it.  It should be a per-bank flag[1]
>
> Agreed. Even I was wondering why this was not bank specific in the
> original code. Will do this in the next series after we get the above
> issue fixed.

ok

>> 
>> Another thing I noticed was that ENWAKEUP is no longer set in the
>> SYSCONFIG register for each bank, as it was before.  To avoid this kind
>> of functional change, I did[2]

What about this one?  I see Rajendra just posted a fix that should take
care of this in a different manner.

Kevin


>> I'll get back to digging a bit tomorrow, but hopefully you can debug
>> this further before I get to it.
>> 
>> Kevin
>> 
>> 
>> [1]
>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
>> index 2f5c1eb..3b60418 100644
>> --- a/arch/arm/plat-omap/gpio.c
>> +++ b/arch/arm/plat-omap/gpio.c
>> @@ -170,6 +170,7 @@ struct gpio_bank {
>>  struct omap_gpio_regs gpio_context;
>>  struct powerdomain *pwrdm;
>>  bool dbck_flag;
>> +int workaround_enabled;
>>  };
>> 
>>  static void omap_gpio_save_context(struct device *dev);
>> @@ -1830,8 +1831,6 @@ static int omap_gpio_resume(struct device *dev)
>>  return 0;
>>  }
>> 
>> -static int workaround_enabled;
>> -
>>  static int gpio_bank_runtime_suspend(struct device *dev)
>>  {
>>  struct platform_device *pdev = to_platform_device(dev);
>> @@ -1887,7 +1886,7 @@ static int gpio_bank_runtime_suspend(struct device
>> *dev)
>>  __raw_writel(l2, bank->base + OMAP4_GPIO_RISINGDETECT);
>>  }
>> 
>> -workaround_enabled = 1;
>> +bank->workaround_enabled = 1;
>> 
>>  return 0;
>>  }
>> @@ -1900,7 +1899,7 @@ static int gpio_bank_runtime_resume(struct device
>> *dev)
>>  if (bank->dbck_enable_mask)
>>  clk_enable(bank->dbck);
>> 
>> -if ((!workaround_enabled) || (!(bank->enabled_non_wakeup_gpios)))
>> +if ((!bank->workaround_enabled) || (!(bank-
>> >enabled_non_wakeup_gpios)))
>>  return 0;
>> 
>>  if (bank->method == METHOD_GPIO_24XX) {
>> @@ -2110,11 +2109,11 @@ void omap2_gpio_prepare_for_idle(void)
>>  {
>>  int i;
>> 
>> -workaround_enabled = 0;
>> -
>>  for (i = 0; i < gpio_bank_count; i++) {
>>  struct gpio_bank *bank = &gpio_bank[i];
>> 
>> +bank->workaround_enabled = 0;
>> +
>>  

[PATCH] OMAP: hwmod: Handle opt clocks node using clk_add_alias

2010-09-21 Thread Benoit Cousson
From: Basak, Partha 

For every optional clock present per hwmod per omap-device, this function
adds an entry in the clocks list of the form ,
if an entry is already present in the list of the form .

The function is called from within the framework inside omap_device_build_ss(),
after omap_device_register.

This allows drivers to get a pointer to its optional clocks based on its role
by calling clk_get(, ).

Link to discussions related to this patch:
http://www.spinics.net/lists/linux-omap/msg34809.html

Signed-off-by: Charulatha V 
Signed-off-by: Basak, Partha 
Signed-off-by: Benoit Cousson 
Signed-off-by: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/plat-omap/omap_device.c |   39 +-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..d876cec 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -82,6 +82,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -243,6 +244,40 @@ static inline struct omap_device *_find_by_pdev(struct 
platform_device *pdev)
return container_of(pdev, struct omap_device, pdev);
 }
 
+/**
+ * _add_optional_clock_alias - Add clock alias for hwmod optional clocks
+ * @od: struct omap_device *od
+ *
+ * For every optional clock present per hwmod per omap_device, this function
+ * adds an entry in the clocks list of the form 
+ * if an entry is already present in it with the form 
+ *
+ * The function is called from inside omap_device_build_ss(), after
+ * omap_device_register.
+ *
+ * This allows drivers to get a pointer to its optional clocks based on its 
role
+ * by calling clk_get(, ).
+ */
+static void _add_optional_clock_alias(struct omap_device *od,
+ struct omap_hwmod *oh)
+{
+   int i;
+   struct omap_hwmod_opt_clk *oc;
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
+   int ret;
+
+   if (!oc->_clk || !IS_ERR(clk_get(&od->pdev.dev, oc->role)))
+   return;
+
+   ret = clk_add_alias(oc->role, dev_name(&od->pdev.dev),
+   (char *)oc->clk, NULL);
+   if (ret)
+   pr_err("omap_device: clk_add_alias for %s failed\n",
+  oc->role);
+   }
+}
+
 
 /* Public functions for use by core code */
 
@@ -421,8 +456,10 @@ struct omap_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
else
ret = omap_device_register(od);
 
-   for (i = 0; i < oh_cnt; i++)
+   for (i = 0; i < oh_cnt; i++) {
hwmods[i]->od = od;
+   _add_optional_clock_alias(od, hwmods[i]);
+   }
 
if (ret)
goto odbs_exit4;
-- 
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] OMAP: hwmod: softreset fixes with opt clocks

2010-09-21 Thread Cousson, Benoit

On 9/21/2010 7:05 PM, Paul Walmsley wrote:

Hi Benoît,

On Tue, 21 Sep 2010, Benoit Cousson wrote:


Here are some fixes for the softreset issues that were highlighted
on some IPs like GPIO or DSS.

For the moment they are still based on your previous series:
git://git.pwsan.com/linux-2.6 hwmod_hardreset_dev

If you are OK with these, I'll rebase that on top of your latest submission to 
l-o / linux-arm-kernel.


Just took a quick look at them; they both look fine to me.  I do have one
minor comment on the optional clock patch; I will post it as a reply to
that message.

That hwmod_hardreset_dev branch is almost identical to the hwmod_2.6.37
branch.  Maybe I should just add your patches to the hwmod_2.6.37 branch,
along with Rajendra's ENAWAKEUP patch, and post those three to lakml, if
you are okay with that?


OK, I'm fine with that.

I think I should as well re-send the one from Partha:  OMAP: hwmod: 
Handle opt clocks node using clk_add_alias.

That one is fine for me, but I didn't see much comment on it.
The GPIO series has a dependency on it as well.

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] OMAP: hwmod: Fix softreset for modules with optional clocks

2010-09-21 Thread Cousson, Benoit

On 9/21/2010 7:07 PM, Paul Walmsley wrote:

Hi Benoit,

one minor comment here -

On Tue, 21 Sep 2010, Benoit Cousson wrote:


Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.

Reported-by: Partha Basak
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
---
  arch/arm/mach-omap2/omap_hwmod.c |   51 +++---
  arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
  2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8c27923..4309107 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -546,6 +546,36 @@ static int _disable_clocks(struct omap_hwmod *oh)
return 0;
  }

+static void _enable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i>  0; i--, oc++)
+   if (oc->_clk) {
+   pr_warning("omap_hwmod: enable %s:%s\n", oc->role,
+  oc->_clk->name);


What do you think about maybe converting this to a pr_debug() (and the
same in the disable code below)?  If you are happy with that, I can make
the change here when I pull the patch in.


Oops... yes, sure, that was the intent... I've just cleaned the other 
ones, but missed these two.

Thanks for catching that.

Regards,
Benoit




+   clk_enable(oc->_clk);
+   }
+}
+
+static void _disable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i>  0; i--, oc++)
+   if (oc->_clk) {
+   pr_warning("omap_hwmod: disable %s:%s\n", oc->role,
+  oc->_clk->name);
+   clk_disable(oc->_clk);
+   }
+}
+
  /**
   * _find_mpu_port_index - find hwmod OCP slave port ID intended for MPU use
   * @oh: struct omap_hwmod *
@@ -970,8 +1000,9 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
   */
  static int _reset(struct omap_hwmod *oh)
  {
-   u32 r, v;
+   u32 v;
int c = 0;
+   int ret = 0;

if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags&  SYSC_HAS_SOFTRESET) ||
@@ -985,12 +1016,16 @@ static int _reset(struct omap_hwmod *oh)
return -EINVAL;
}

+   /* For some modules, all optionnal clocks need to be enabled as well */
+   if (oh->flags&  HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _enable_optional_clocks(oh);
+
pr_debug("omap_hwmod: %s: resetting\n", oh->name);

v = oh->_sysc_cache;
-   r = _set_softreset(oh,&v);
-   if (r)
-   return r;
+   ret = _set_softreset(oh,&v);
+   if (ret)
+   goto dis_opt_clks;
_write_sysconfig(v, oh);

omap_test_timeout((omap_hwmod_readl(oh, oh->class->sysc->syss_offs)&
@@ -1008,7 +1043,13 @@ static int _reset(struct omap_hwmod *oh)
 * _wait_target_ready() or _reset()
 */

-   return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+   ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+
+dis_opt_clks:
+   if (oh->flags&  HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _disable_optional_clocks(oh);
+
+   return ret;
  }

  /**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7fde44d..878f919 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -368,6 +368,10 @@ struct omap_hwmod_omap4_prcm {
   * HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
   * HWMOD_NO_IDLEST : this module does not have idle status - this is the case
   * only for few initiator modules on OMAP2&  3.
+ * HWMOD_CONTROL_OPT_CLKS_IN_RESET: Enable all optional clocks during reset.
+ * This is needed for devices like DSS that require optional clocks enabled
+ * in order to complete the reset. Optional clocks will be disabled
+ * again after the reset.
   */
  #define HWMOD_SWSUP_SIDLE (1<<  0)
  #define HWMOD_SWSUP_MST

Re: [PATCH] OMAP: hwmod: Fix softreset for modules with optional clocks

2010-09-21 Thread Paul Walmsley
Hi Benoit,

one minor comment here -

On Tue, 21 Sep 2010, Benoit Cousson wrote:

> Some modules (like GPIO, DSS...) require optionals clock to be enabled
> in order to complete the sofreset properly.
> Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
> to be enabled before reset. Disabled them once the reset is done.
> 
> TODO:
> For the moment it is very hard to understand from the HW spec, which
> optional clock is needed and which one is not. So the current approach
> will enable all the optional clocks.
> Paul proposed a much finer approach that will allow to tag only the needed
> clock in the optional clock table. This might be doable as soon as we have
> a clear understanding of these dependencies.
> 
> Reported-by: Partha Basak 
> Signed-off-by: Benoit Cousson 
> Cc: Paul Walmsley 
> Cc: Kevin Hilman 
> ---
>  arch/arm/mach-omap2/omap_hwmod.c |   51 
> +++---
>  arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 8c27923..4309107 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -546,6 +546,36 @@ static int _disable_clocks(struct omap_hwmod *oh)
>   return 0;
>  }
>  
> +static void _enable_optional_clocks(struct omap_hwmod *oh)
> +{
> + struct omap_hwmod_opt_clk *oc;
> + int i;
> +
> + pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
> +
> + for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
> + if (oc->_clk) {
> + pr_warning("omap_hwmod: enable %s:%s\n", oc->role,
> +oc->_clk->name);

What do you think about maybe converting this to a pr_debug() (and the 
same in the disable code below)?  If you are happy with that, I can make 
the change here when I pull the patch in.

> + clk_enable(oc->_clk);
> + }
> +}
> +
> +static void _disable_optional_clocks(struct omap_hwmod *oh)
> +{
> + struct omap_hwmod_opt_clk *oc;
> + int i;
> +
> + pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
> +
> + for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
> + if (oc->_clk) {
> + pr_warning("omap_hwmod: disable %s:%s\n", oc->role,
> +oc->_clk->name);
> + clk_disable(oc->_clk);
> + }
> +}
> +
>  /**
>   * _find_mpu_port_index - find hwmod OCP slave port ID intended for MPU use
>   * @oh: struct omap_hwmod *
> @@ -970,8 +1000,9 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
> char *name)
>   */
>  static int _reset(struct omap_hwmod *oh)
>  {
> - u32 r, v;
> + u32 v;
>   int c = 0;
> + int ret = 0;
>  
>   if (!oh->class->sysc ||
>   !(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET) ||
> @@ -985,12 +1016,16 @@ static int _reset(struct omap_hwmod *oh)
>   return -EINVAL;
>   }
>  
> + /* For some modules, all optionnal clocks need to be enabled as well */
> + if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
> + _enable_optional_clocks(oh);
> +
>   pr_debug("omap_hwmod: %s: resetting\n", oh->name);
>  
>   v = oh->_sysc_cache;
> - r = _set_softreset(oh, &v);
> - if (r)
> - return r;
> + ret = _set_softreset(oh, &v);
> + if (ret)
> + goto dis_opt_clks;
>   _write_sysconfig(v, oh);
>  
>   omap_test_timeout((omap_hwmod_readl(oh, oh->class->sysc->syss_offs) &
> @@ -1008,7 +1043,13 @@ static int _reset(struct omap_hwmod *oh)
>* _wait_target_ready() or _reset()
>*/
>  
> - return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
> + ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
> +
> +dis_opt_clks:
> + if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
> + _disable_optional_clocks(oh);
> +
> + return ret;
>  }
>  
>  /**
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 7fde44d..878f919 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -368,6 +368,10 @@ struct omap_hwmod_omap4_prcm {
>   * HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
>   * HWMOD_NO_IDLEST : this module does not have idle status - this is the case
>   * only for few initiator modules on OMAP2 & 3.
> + * HWMOD_CONTROL_OPT_CLKS_IN_RESET: Enable all optional clocks during reset.
> + * This is needed for devices like DSS that require optional clocks 
> enabled
> + * in order to complete the reset. Optional clocks will be disabled
> + * again after the reset.
>   */
>  #define HWMOD_SWSUP_SIDLE(1 << 0)
>  #define HWMOD_SWSUP_MSTANDBY (1 << 1)

Re: [PATCH] OMAP: hwmod: softreset fixes with opt clocks

2010-09-21 Thread Paul Walmsley
Hi Benoît,

On Tue, 21 Sep 2010, Benoit Cousson wrote:

> Here are some fixes for the softreset issues that were highlighted
> on some IPs like GPIO or DSS.
> 
> For the moment they are still based on your previous series:
> git://git.pwsan.com/linux-2.6 hwmod_hardreset_dev
> 
> If you are OK with these, I'll rebase that on top of your latest submission 
> to l-o / linux-arm-kernel.

Just took a quick look at them; they both look fine to me.  I do have one 
minor comment on the optional clock patch; I will post it as a reply to 
that message.

That hwmod_hardreset_dev branch is almost identical to the hwmod_2.6.37 
branch.  Maybe I should just add your patches to the hwmod_2.6.37 branch, 
along with Rajendra's ENAWAKEUP patch, and post those three to lakml, if 
you are okay with that?


- Paul

Re: [PATCH] OMAP: hwmod: softreset fixes with opt clocks

2010-09-21 Thread Cousson, Benoit

On 9/21/2010 6:57 PM, Cousson, Benoit wrote:

Hi Paul,

Here are some fixes for the softreset issues that were highlighted
on some IPs like GPIO or DSS.

For the moment they are still based on your previous series:
git://git.pwsan.com/linux-2.6 hwmod_hardreset_dev

If you are OK with these, I'll rebase that on top of your latest submission to 
l-o / linux-arm-kernel.

Thanks,
Benoit


Benoit Cousson (2):
   OMAP: hwmod: Fix softreset for modules with optional clocks
   OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

  arch/arm/mach-omap2/omap_hwmod.c |   73 ++
  arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +++-
  2 files changed, 70 insertions(+), 11 deletions(-)



Oops, I forgot... The patches are available here:

git://gitorious.org/omap-pm/linux.git pm-wip/hwmods-reset-fixes

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 03/10] OMAP3: PM: move device-specific special cases from PM core into CPUidle

2010-09-21 Thread Kevin Hilman
Paul Walmsley  writes:

> Hi Kevin,
>
> On Wed, 15 Sep 2010, Kevin Hilman wrote:
>
>> In an effort to simplify the core idle path, move any device-specific
>> special case handling from the core PM idle path into the CPUidle
>> pre-idle checking path.
>> 
>> This keeps the core, interrupts-disabled idle path streamlined and
>> independent of any device-specific handling, and also allows CPUidle
>> to do the checking only for certain C-states as needed.  This patch
>> has the device checks in place for all states with the CHECK_BM flag,
>> namely all states >= C2.
>> 
>> This patch was inspired by a similar patch written by Tero Kristo as
>> part of a larger series to add INACTIVE state support.
>
> As with the original patch, I don't quite understand the improvement 
> here.  In particular, this part:
>
>> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
>> b/arch/arm/mach-omap2/cpuidle34xx.c
>> index 3d3d035..0923b82 100644
>> --- a/arch/arm/mach-omap2/cpuidle34xx.c
>> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
>> @@ -233,14 +234,54 @@ static int omap3_enter_idle_bm(struct cpuidle_device 
>> *dev,
>> struct cpuidle_state *state)
>>  {
>>  struct cpuidle_state *new_state = next_valid_state(dev, state);
>> +u32 core_next_state, per_next_state = 0, per_saved_state = 0;
>> +u32 cam_state;
>> +struct omap3_processor_cx *cx;
>> +int ret;
>>  
>>  if ((state->flags & CPUIDLE_FLAG_CHECK_BM) && omap3_idle_bm_check()) {
>>  BUG_ON(!dev->safe_state);
>>  new_state = dev->safe_state;
>> +goto select_state;
>> +}
>> +
>> +cx = cpuidle_get_statedata(state);
>> +core_next_state = cx->core_state;
>> +
>> +/*
>> + * Prevent idle completely if CAM is active.
>> + * CAM does not have wakeup capability in OMAP3.
>> + */
>> +cam_state = pwrdm_read_pwrst(cam_pd);
>> +if (cam_state == PWRDM_POWER_ON) {
>> +new_state = dev->safe_state;
>> +goto select_state;
>>  }
>>  
>> +/*
>> + * Prevent PER off if CORE is not in retention or off as this
>> + * would disable PER wakeups completely.
>> + */
>> +per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
>> +if ((per_next_state == PWRDM_POWER_OFF) &&
>> +(core_next_state > PWRDM_POWER_RET)) {
>> +per_next_state = PWRDM_POWER_RET;
>> +pwrdm_set_next_pwrst(per_pd, per_next_state);
>> +}
>> +
>> +/* Are we changing PER target state? */
>> +if (per_next_state != per_saved_state)
>> +pwrdm_set_next_pwrst(per_pd, per_next_state);
>
> In this case, the PER / CORE constraints don't have anything to do with 
> the MPU or CPUIdle, so they don't seem to belong in the CPUIdle code.  The 
> extra comments are certainly nice -- they make it more clear as to what is 
> going on here -- but maybe those can just be added to pm34xx.c ?

CPUidle currently manages MPU and CORE powerdomains, so the CORE
constraints seem to make perfect sense here (at least to me.)

The question is probably more about the PER constraints.

The basic goal of this is to streamline the core idle (omap_sram_idle())
to be the minimum streamline idle, and to move all the constraint
checking and activity checking to higher layers (like CPUidle.)
Specifically, I'm working towards moving the device-specific idle
constraints out of the core idle path (omap_sram_idle()) and move them
into higher layers where we're checking for activity etc.

This is just a baby step towards moving the device-idle out of CPUidle
completely to a place where it can be managed by the driver themeselves
using runtime PM or by using constraints instead of these hard-coded
hacks.

Kevin


>> +
>> +select_state:
>>  dev->last_state = new_state;
>> -return omap3_enter_idle(dev, new_state);
>> +ret = omap3_enter_idle(dev, new_state);
>> +
>> +/* Restore original PER state if it was modified */
>> +if (per_next_state != per_saved_state)
>> +pwrdm_set_next_pwrst(per_pd, per_saved_state);
>> +
>> +return ret;
>>  }
>>  
>>  DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
>> @@ -328,7 +369,8 @@ void omap_init_power_states(void)
>>  cpuidle_params_table[OMAP3_STATE_C2].threshold;
>>  omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
>>  omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
>> -omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
>> +omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
>> +CPUIDLE_FLAG_CHECK_BM;
>>  
>>  /* C3 . MPU CSWR + Core inactive */
>>  omap3_power_states[OMAP3_STATE_C3].valid =
>> @@ -426,6 +468,8 @@ int __init omap3_idle_init(void)
>>  
>>  mpu_pd = pwrdm_lookup("mpu_pwrdm");
>>  core_pd = pwrdm_lookup("core_pwrdm");
>> +per_pd = pwrdm_lookup("per_pwrdm");
>> +cam_pd = pwrdm_lookup("cam_pwrdm");
>>  
>>   

[PATCH] OMAP: hwmod: softreset fixes with opt clocks

2010-09-21 Thread Benoit Cousson
Hi Paul,

Here are some fixes for the softreset issues that were highlighted
on some IPs like GPIO or DSS.

For the moment they are still based on your previous series:
git://git.pwsan.com/linux-2.6 hwmod_hardreset_dev

If you are OK with these, I'll rebase that on top of your latest submission to 
l-o / linux-arm-kernel.

Thanks,
Benoit


Benoit Cousson (2):
  OMAP: hwmod: Fix softreset for modules with optional clocks
  OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

 arch/arm/mach-omap2/omap_hwmod.c |   73 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +++-
 2 files changed, 70 insertions(+), 11 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] OMAP: hwmod: Fix softreset for modules with optional clocks

2010-09-21 Thread Benoit Cousson
Some modules (like GPIO, DSS...) require optionals clock to be enabled
in order to complete the sofreset properly.
Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks
to be enabled before reset. Disabled them once the reset is done.

TODO:
For the moment it is very hard to understand from the HW spec, which
optional clock is needed and which one is not. So the current approach
will enable all the optional clocks.
Paul proposed a much finer approach that will allow to tag only the needed
clock in the optional clock table. This might be doable as soon as we have
a clear understanding of these dependencies.

Reported-by: Partha Basak 
Signed-off-by: Benoit Cousson 
Cc: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |   51 +++---
 arch/arm/plat-omap/include/plat/omap_hwmod.h |5 +++
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8c27923..4309107 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -546,6 +546,36 @@ static int _disable_clocks(struct omap_hwmod *oh)
return 0;
 }
 
+static void _enable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_warning("omap_hwmod: enable %s:%s\n", oc->role,
+  oc->_clk->name);
+   clk_enable(oc->_clk);
+   }
+}
+
+static void _disable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_warning("omap_hwmod: disable %s:%s\n", oc->role,
+  oc->_clk->name);
+   clk_disable(oc->_clk);
+   }
+}
+
 /**
  * _find_mpu_port_index - find hwmod OCP slave port ID intended for MPU use
  * @oh: struct omap_hwmod *
@@ -970,8 +1000,9 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
  */
 static int _reset(struct omap_hwmod *oh)
 {
-   u32 r, v;
+   u32 v;
int c = 0;
+   int ret = 0;
 
if (!oh->class->sysc ||
!(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET) ||
@@ -985,12 +1016,16 @@ static int _reset(struct omap_hwmod *oh)
return -EINVAL;
}
 
+   /* For some modules, all optionnal clocks need to be enabled as well */
+   if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _enable_optional_clocks(oh);
+
pr_debug("omap_hwmod: %s: resetting\n", oh->name);
 
v = oh->_sysc_cache;
-   r = _set_softreset(oh, &v);
-   if (r)
-   return r;
+   ret = _set_softreset(oh, &v);
+   if (ret)
+   goto dis_opt_clks;
_write_sysconfig(v, oh);
 
omap_test_timeout((omap_hwmod_readl(oh, oh->class->sysc->syss_offs) &
@@ -1008,7 +1043,13 @@ static int _reset(struct omap_hwmod *oh)
 * _wait_target_ready() or _reset()
 */
 
-   return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+   ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
+
+dis_opt_clks:
+   if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _disable_optional_clocks(oh);
+
+   return ret;
 }
 
 /**
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7fde44d..878f919 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -368,6 +368,10 @@ struct omap_hwmod_omap4_prcm {
  * HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
  * HWMOD_NO_IDLEST : this module does not have idle status - this is the case
  * only for few initiator modules on OMAP2 & 3.
+ * HWMOD_CONTROL_OPT_CLKS_IN_RESET: Enable all optional clocks during reset.
+ * This is needed for devices like DSS that require optional clocks enabled
+ * in order to complete the reset. Optional clocks will be disabled
+ * again after the reset.
  */
 #define HWMOD_SWSUP_SIDLE  (1 << 0)
 #define HWMOD_SWSUP_MSTANDBY   (1 << 1)
@@ -376,6 +380,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_OCP_AUTOIDLE  (1 << 4)
 #define HWMOD_SET_DEFAULT_CLOCKACT (1 << 5)
 #define HWMOD_NO_IDLEST(1 << 6)
+#define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1 << 7)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.6.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the bod

[PATCH] OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs

2010-09-21 Thread Benoit Cousson
In OMAP3 a specific SYSSTATUS register was used to get the softreset status.
Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
use the SYSC softreset bit to provide the status.

Other cases might exist:
- Some IPs like McBSP does have a softreset control but no reset status.
- Some IPs that represent subsystem, like the DSS, can contains
a reset status without softreset control. The status is the aggregation
of all the sub modules reset status.

- Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model
and replace the previous SYSS_MISSING, that was used to flag IP with
softreset control but without the SYSSTATUS register, with a specific
SYSS_HAS_RESET_STATUS flag.

- MCSPI and MMC contains both programming models, so the legacy one
will be prevented by removing the syss offset field that become useless.

Signed-off-by: Benoit Cousson 
Cc: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/omap_hwmod.c |   22 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |3 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4309107..4819a49 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -997,6 +997,12 @@ static int _read_hardreset(struct omap_hwmod *oh, const 
char *name)
  * enabled for this to work.  Returns -EINVAL if the hwmod cannot be
  * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
  * the module did not reset in time, or 0 upon success.
+ *
+ * In OMAP3 a specific SYSSTATUS register is used to get the reset status.
+ * Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
+ * use the SYSCONFIG softreset bit to provide the status.
+ *
+ * Note that some IP like McBSP does have a reset control but no reset status.
  */
 static int _reset(struct omap_hwmod *oh)
 {
@@ -1005,8 +1011,7 @@ static int _reset(struct omap_hwmod *oh)
int ret = 0;
 
if (!oh->class->sysc ||
-   !(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET) ||
-   (oh->class->sysc->sysc_flags & SYSS_MISSING))
+   !(oh->class->sysc->sysc_flags & SYSC_HAS_SOFTRESET))
return -EINVAL;
 
/* clocks must be on for this operation */
@@ -1028,9 +1033,16 @@ static int _reset(struct omap_hwmod *oh)
goto dis_opt_clks;
_write_sysconfig(v, oh);
 
-   omap_test_timeout((omap_hwmod_readl(oh, oh->class->sysc->syss_offs) &
-  SYSS_RESETDONE_MASK),
- MAX_MODULE_SOFTRESET_WAIT, c);
+   if (oh->class->sysc->sysc_flags & SYSS_HAS_RESET_STATUS)
+   omap_test_timeout((omap_hwmod_readl(oh,
+   oh->class->sysc->syss_offs)
+  & SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+   else if (oh->class->sysc->sysc_flags & SYSC_HAS_RESET_STATUS)
+   omap_test_timeout(!(omap_hwmod_readl(oh,
+oh->class->sysc->sysc_offs)
+  & SYSC_TYPE2_SOFTRESET_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
 
if (c == MAX_MODULE_SOFTRESET_WAIT)
pr_warning("omap_hwmod: %s: softreset failed (waited %d 
usec)\n",
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 878f919..ee53758 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -251,8 +251,9 @@ struct omap_hwmod_ocp_if {
 #define SYSC_HAS_CLOCKACTIVITY (1 << 4)
 #define SYSC_HAS_SIDLEMODE (1 << 5)
 #define SYSC_HAS_MIDLEMODE (1 << 6)
-#define SYSS_MISSING   (1 << 7)
+#define SYSS_HAS_RESET_STATUS  (1 << 7)
 #define SYSC_NO_CACHE  (1 << 8)  /* XXX SW flag, belongs elsewhere */
+#define SYSC_HAS_RESET_STATUS  (1 << 9)
 
 /* omap_hwmod_sysconfig.clockact flags */
 #define CLOCKACT_TEST_BOTH 0x0
-- 
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


[PATCH 05/11] [PATCH] OMAP: hwmod: separate list locking and hwmod hardware locking

2010-09-21 Thread Paul Walmsley
From: Kevin Hilman 

Currently omap_hwmod_mutex is being used to protect both the list
access/modification and concurrent access to hwmod functions.  This
patch separates these two types of locking.

First, omap_hwmod_mutex is used only to protect access and
modification of omap_hwmod_list.  Also cleaned up some comments
referring to this mutex that are no longer needed.

Then, for protecting concurrent access to hwmod functions, use a
per-hwmod mutex.  This protects concurrent access to a single hwmod,
but would allow concurrent access to different hwmods.

Signed-off-by: Kevin Hilman 
[p...@pwsan.com: added structure documentation; changed mutex variable
 name]
Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/omap_hwmod.c |   62 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +
 2 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 100115f..3084409 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -767,10 +767,10 @@ static struct omap_hwmod *_lookup(const char *name)
  * @data: not used; pass NULL
  *
  * Called by omap_hwmod_late_init() (after omap2_clk_init()).
- * Resolves all clock names embedded in the hwmod.  Must be called
- * with omap_hwmod_mutex held.  Returns -EINVAL if the omap_hwmod
- * has not yet been registered or if the clocks have already been
- * initialized, 0 on success, or a non-zero error on failure.
+ * Resolves all clock names embedded in the hwmod.  Returns -EINVAL if
+ * the omap_hwmod has not yet been registered or if the clocks have
+ * already been initialized, 0 on success, or a non-zero error on
+ * failure.
  */
 static int _init_clocks(struct omap_hwmod *oh, void *data)
 {
@@ -838,10 +838,9 @@ static int _wait_target_ready(struct omap_hwmod *oh)
  * @oh: struct omap_hwmod *
  *
  * Resets an omap_hwmod @oh via the OCP_SYSCONFIG bit.  hwmod must be
- * enabled for this to work.  Must be called with omap_hwmod_mutex
- * held.  Returns -EINVAL if the hwmod cannot be reset this way or if
- * the hwmod is in the wrong state, -ETIMEDOUT if the module did not
- * reset in time, or 0 upon success.
+ * enabled for this to work.  Returns -EINVAL if the hwmod cannot be
+ * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
+ * the module did not reset in time, or 0 upon success.
  */
 static int _reset(struct omap_hwmod *oh)
 {
@@ -891,9 +890,8 @@ static int _reset(struct omap_hwmod *oh)
  * @oh: struct omap_hwmod *
  *
  * Enables an omap_hwmod @oh such that the MPU can access the hwmod's
- * register target.  Must be called with omap_hwmod_mutex held.
- * Returns -EINVAL if the hwmod is in the wrong state or passes along
- * the return value of _wait_target_ready().
+ * register target.  Returns -EINVAL if the hwmod is in the wrong
+ * state or passes along the return value of _wait_target_ready().
  */
 int _omap_hwmod_enable(struct omap_hwmod *oh)
 {
@@ -1004,11 +1002,10 @@ static int _shutdown(struct omap_hwmod *oh)
  * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
  *
  * Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register.  Must be called with omap_hwmod_mutex held.
- * @skip_setup_idle is intended to be used on a system that will not
- * call omap_hwmod_enable() to enable devices (e.g., a system without
- * PM runtime).  Returns -EINVAL if the hwmod is in the wrong state or
- * returns 0.
+ * OCP_SYSCONFIG register.  @skip_setup_idle is intended to be used on
+ * a system that will not call omap_hwmod_enable() to enable devices
+ * (e.g., a system without PM runtime).  Returns -EINVAL if the hwmod
+ * is in the wrong state or returns 0.
  */
 static int _setup(struct omap_hwmod *oh, void *data)
 {
@@ -1038,6 +1035,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
}
}
 
+   mutex_init(&oh->_mutex);
oh->_state = _HWMOD_STATE_INITIALIZED;
 
r = _omap_hwmod_enable(oh);
@@ -1323,9 +1321,9 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
-   mutex_lock(&omap_hwmod_mutex);
+   mutex_lock(&oh->_mutex);
r = _omap_hwmod_enable(oh);
-   mutex_unlock(&omap_hwmod_mutex);
+   mutex_unlock(&oh->_mutex);
 
return r;
 }
@@ -1343,9 +1341,9 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
-   mutex_lock(&omap_hwmod_mutex);
+   mutex_lock(&oh->_mutex);
_omap_hwmod_idle(oh);
-   mutex_unlock(&omap_hwmod_mutex);
+   mutex_unlock(&oh->_mutex);
 
return 0;
 }
@@ -1363,9 +1361,9 @@ int omap_hwmod_shutdown(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
-   mutex_lock(&omap_hwmod_mutex);
+   mutex_lock(&oh->_mutex);
_shutdown(oh);
-   mutex_unlock(&omap_hwmod_mutex);
+   mutex_unlock(&oh->_mutex);
 

[PATCH 03/11] OMAP: hwmod: Fix omap_hwmod_reset wrong state test

2010-09-21 Thread Paul Walmsley
From: Liam Girdwood 

The reset function wrongly used the state flag as a bit mask and was trying
to re-enable after a reset.

hwmod is still enabled for the PRCM point of view after a softreset
so there is no need to re-enable.

Remove the state check from omap_hwmod_reset since the _reset
function is checking that as well and in addition can generate
a warning

Signed-off-by: Liam Girdwood 
[b-cous...@ti.com: remove the wrong test, remove the re-enable]
Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/omap_hwmod.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5bb25e3..100115f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1434,19 +1434,17 @@ void omap_hwmod_ocp_barrier(struct omap_hwmod *oh)
  *
  * Under some conditions, a driver may wish to reset the entire device.
  * Called from omap_device code.  Returns -EINVAL on error or passes along
- * the return value from _reset()/_enable().
+ * the return value from _reset().
  */
 int omap_hwmod_reset(struct omap_hwmod *oh)
 {
int r;
 
-   if (!oh || !(oh->_state & _HWMOD_STATE_ENABLED))
+   if (!oh)
return -EINVAL;
 
mutex_lock(&omap_hwmod_mutex);
r = _reset(oh);
-   if (!r)
-   r = _omap_hwmod_enable(oh);
mutex_unlock(&omap_hwmod_mutex);
 
return r;


--
To unsubscribe from this list: send the line "unsubscribe 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 02/11] OMAP: hwmod: Do not disable clocks if hwmod already in idle

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

The disable function was disabling clocks and dependencies
from both enable and idle state. Since idle function is already
disabling both, an enable -> idle -> disable sequence will
try to disable twice the clocks and thus generate a
"Trying disable clock XXX with 0 usecount" warning.

Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8bf19a7..5bb25e3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -982,9 +982,13 @@ static int _shutdown(struct omap_hwmod *oh)
 
if (oh->class->sysc)
_sysc_shutdown(oh);
-   _del_initiator_dep(oh, mpu_oh);
-   /* XXX what about the other system initiators here? DMA, tesla, d2d */
-   _disable_clocks(oh);
+
+   /* clocks and deps are already disabled in idle */
+   if (oh->_state == _HWMOD_STATE_ENABLED) {
+   _del_initiator_dep(oh, mpu_oh);
+   /* XXX what about the other system initiators here? dma, dsp */
+   _disable_clocks(oh);
+   }
/* XXX Should this code also force-disable the optional clocks? */
 
/* XXX mux any associated balls to safe mode */


--
To unsubscribe from this list: send the line "unsubscribe 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 11/11] OMAP: hwmod: add an hardreset API for use by other core code

2010-09-21 Thread Paul Walmsley
Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod.  This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.

Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
---
 arch/arm/mach-omap2/omap_hwmod.c |   78 ++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +
 2 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3e90984..8c27923 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1829,6 +1829,84 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
 }
 
 /**
+ * omap_hwmod_assert_hardreset - assert the HW reset line of submodules
+ * contained in the hwmod module.
+ * @oh: struct omap_hwmod *
+ * @name: name of the reset line to lookup and assert
+ *
+ * Some IP like dsp, ipu or iva contain processor that require
+ * an HW reset line to be assert / deassert in order to enable fully
+ * the IP.  Returns -EINVAL if @oh is null or if the operation is not
+ * yet supported on this OMAP; otherwise, passes along the return value
+ * from _assert_hardreset().
+ */
+int omap_hwmod_assert_hardreset(struct omap_hwmod *oh, const char *name)
+{
+   int ret;
+
+   if (!oh)
+   return -EINVAL;
+
+   mutex_lock(&oh->_mutex);
+   ret = _assert_hardreset(oh, name);
+   mutex_unlock(&oh->_mutex);
+
+   return ret;
+}
+
+/**
+ * omap_hwmod_deassert_hardreset - deassert the HW reset line of submodules
+ * contained in the hwmod module.
+ * @oh: struct omap_hwmod *
+ * @name: name of the reset line to look up and deassert
+ *
+ * Some IP like dsp, ipu or iva contain processor that require
+ * an HW reset line to be assert / deassert in order to enable fully
+ * the IP.  Returns -EINVAL if @oh is null or if the operation is not
+ * yet supported on this OMAP; otherwise, passes along the return value
+ * from _deassert_hardreset().
+ */
+int omap_hwmod_deassert_hardreset(struct omap_hwmod *oh, const char *name)
+{
+   int ret;
+
+   if (!oh)
+   return -EINVAL;
+
+   mutex_lock(&oh->_mutex);
+   ret = _deassert_hardreset(oh, name);
+   mutex_unlock(&oh->_mutex);
+
+   return ret;
+}
+
+/**
+ * omap_hwmod_read_hardreset - read the HW reset line state of submodules
+ * contained in the hwmod module
+ * @oh: struct omap_hwmod *
+ * @name: name of the reset line to look up and read
+ *
+ * Return the current state of the hwmod @oh's reset line named @name:
+ * returns -EINVAL upon parameter error or if this operation
+ * is unsupported on the current OMAP; otherwise, passes along the return
+ * value from _read_hardreset().
+ */
+int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const char *name)
+{
+   int ret;
+
+   if (!oh)
+   return -EINVAL;
+
+   mutex_lock(&oh->_mutex);
+   ret = _read_hardreset(oh, name);
+   mutex_unlock(&oh->_mutex);
+
+   return ret;
+}
+
+
+/**
  * omap_hwmod_for_each_by_class - call @fn for each hwmod of class @classname
  * @classname: struct omap_hwmod_class name to search for
  * @fn: callback function pointer to call for each hwmod in class @classname
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 590bfae..7fde44d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -512,6 +512,10 @@ int omap_hwmod_idle(struct omap_hwmod *oh);
 int _omap_hwmod_idle(struct omap_hwmod *oh);
 int omap_hwmod_shutdown(struct omap_hwmod *oh);
 
+int omap_hwmod_assert_hardreset(struct omap_hwmod *oh, const char *name);
+int omap_hwmod_deassert_hardreset(struct omap_hwmod *oh, const char *name);
+int omap_hwmod_read_hardreset(struct omap_hwmod *oh, const char *name);
+
 int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
 int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
 


--
To unsubscribe from this list: send the line "unsubscribe 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 06/11] OMAP4: prcm: Add temporarily helper functions for rmw and read inside the PRM

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.

Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/prcm.c |   24 
 arch/arm/plat-omap/include/plat/prcm.h |2 ++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 96f4616..d4388d3 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -216,6 +216,30 @@ u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
return v;
 }
 
+/* Read a PRM register, AND it, and shift the result down to bit 0 */
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask)
+{
+   u32 v;
+
+   v = __raw_readl(reg);
+   v &= mask;
+   v >>= __ffs(mask);
+
+   return v;
+}
+
+/* Read-modify-write a register in a PRM module. Caller must lock */
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg)
+{
+   u32 v;
+
+   v = __raw_readl(reg);
+   v &= ~mask;
+   v |= bits;
+   __raw_writel(v, reg);
+
+   return v;
+}
 /* Read a register in a CM module */
 u32 cm_read_mod_reg(s16 module, u16 idx)
 {
diff --git a/arch/arm/plat-omap/include/plat/prcm.h 
b/arch/arm/plat-omap/include/plat/prcm.h
index 9fbd914..ab77442 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -38,6 +38,8 @@ u32 prm_read_mod_reg(s16 module, u16 idx);
 void prm_write_mod_reg(u32 val, s16 module, u16 idx);
 u32 prm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);
 u32 prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
+u32 omap4_prm_read_bits_shift(void __iomem *reg, u32 mask);
+u32 omap4_prm_rmw_reg_bits(u32 mask, u32 bits, void __iomem *reg);
 u32 cm_read_mod_reg(s16 module, u16 idx);
 void cm_write_mod_reg(u32 val, s16 module, u16 idx);
 u32 cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module, s16 idx);


--
To unsubscribe from this list: send the line "unsubscribe 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 10/11] OMAP: hwmod: Force a softreset during _setup

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.

Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f4a569c..3e90984 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -980,8 +980,8 @@ static int _reset(struct omap_hwmod *oh)
 
/* clocks must be on for this operation */
if (oh->_state != _HWMOD_STATE_ENABLED) {
-   WARN(1, "omap_hwmod: %s: reset can only be entered from "
-"enabled state\n", oh->name);
+   pr_warning("omap_hwmod: %s: reset can only be entered from "
+  "enabled state\n", oh->name);
return -EINVAL;
}
 
@@ -998,8 +998,8 @@ static int _reset(struct omap_hwmod *oh)
  MAX_MODULE_SOFTRESET_WAIT, c);
 
if (c == MAX_MODULE_SOFTRESET_WAIT)
-   WARN(1, "omap_hwmod: %s: softreset failed (waited %d usec)\n",
-oh->name, MAX_MODULE_SOFTRESET_WAIT);
+   pr_warning("omap_hwmod: %s: softreset failed (waited %d 
usec)\n",
+  oh->name, MAX_MODULE_SOFTRESET_WAIT);
else
pr_debug("omap_hwmod: %s: softreset in %d usec\n", oh->name, c);
 
@@ -1198,12 +1198,12 @@ static int _setup(struct omap_hwmod *oh, void *data)
}
 
if (!(oh->flags & HWMOD_INIT_NO_RESET)) {
+   _reset(oh);
+
/*
-* XXX Do the OCP_SYSCONFIG bits need to be
-* reprogrammed after a reset?  If not, then this can
-* be removed.  If they do, then probably the
-* _omap_hwmod_enable() function should be split to avoid the
-* rewrite of the OCP_SYSCONFIG register.
+* OCP_SYSCONFIG bits need to be reprogrammed after a softreset.
+* The _omap_hwmod_enable() function should be split to
+* avoid the rewrite of the OCP_SYSCONFIG register.
 */
if (oh->class->sysc) {
_update_sysc_cache(oh);


--
To unsubscribe from this list: send the line "unsubscribe 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 09/11] OMAP: hwmod: Add hardreset management support

2010-09-21 Thread Paul Walmsley
From: Benoît Cousson 

Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2...
Since this granularity is needed by the driver, we have to ensure
than one hwmod exist for each hardreset line.

- Store reset lines as hwmod resources that a driver can query by name like
  an irq or sdma line.

- Add two functions for asserting / deasserting reset lines in hwmods
  processor that require manual reset control.
- Add one functions to get the current reset state.
- If an hwmod contains only one line, an automatic assertion / de-assertion
  is done.
  -> de-assert the hardreset line only during enable from disable transition
  -> assert the hardreset line only during shutdown

Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be
kept in INITIALIZED state.
They can be properly enabled only if the hardreset line is de-asserted
before.

For information here is the list of IPs with HW reset control
on an OMAP4430 device:

RM_DSP_RSTCTRL
  1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control'
  0,0,'RST1','RW','1','DSP - DSP reset control'

RM_IVA_RSTCTRL
  2,2,'RST3','RW','1','IVA logic and SL2 reset control'
  1,1,'RST2','RW','1','IVA Sequencer2 reset control'
  0,0,'RST1','RW','1','IVA sequencer1 reset control'

RM_IPU_RSTCTRL
  2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.'
  1,1,'RST2','RW','1','IPU Cortex M3 CPU2  reset control.'
  0,0,'RST1','RW','1','IPU Cortex M3 CPU1  reset control.'

PRM_RSTCTRL
  1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.'
  0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.'

RM_CPU0_CPU0_RSTCTRL
RM_CPU1_CPU1_RSTCTRL
  0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control'

Signed-off-by: Benoit Cousson 
[p...@pwsan.com: made the hardreset functions static; moved the register
 twiddling into prm*.c functions in previous patches; changed the
 function names to conform with hwmod practice]
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/omap_hwmod.c |  168 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   17 +++
 2 files changed, 177 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 3084409..f4a569c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -50,11 +50,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cm.h"
+#include "prm.h"
 
-/* Maximum microseconds to wait for OMAP module to reset */
-#define MAX_MODULE_RESET_WAIT  1
+/* Maximum microseconds to wait for OMAP module to softreset */
+#define MAX_MODULE_SOFTRESET_WAIT  1
 
 /* Name of the OMAP hwmod for the MPU */
 #define MPU_INITIATOR_NAME "mpu"
@@ -834,6 +836,130 @@ static int _wait_target_ready(struct omap_hwmod *oh)
 }
 
 /**
+ * _lookup_hardreset - return the register bit shift for this hwmod/reset line
+ * @oh: struct omap_hwmod *
+ * @name: name of the reset line in the context of this hwmod
+ *
+ * Return the bit position of the reset line that match the
+ * input name. Return -ENOENT if not found.
+ */
+static u8 _lookup_hardreset(struct omap_hwmod *oh, const char *name)
+{
+   int i;
+
+   for (i = 0; i < oh->rst_lines_cnt; i++) {
+   const char *rst_line = oh->rst_lines[i].name;
+   if (!strcmp(rst_line, name)) {
+   u8 shift = oh->rst_lines[i].rst_shift;
+   pr_debug("omap_hwmod: %s: _lookup_hardreset: %s: %d\n",
+oh->name, rst_line, shift);
+
+   return shift;
+   }
+   }
+
+   return -ENOENT;
+}
+
+/**
+ * _assert_hardreset - assert the HW reset line of submodules
+ * contained in the hwmod module.
+ * @oh: struct omap_hwmod *
+ * @name: name of the reset line to lookup and assert
+ *
+ * Some IP like dsp, ipu or iva contain processor that require
+ * an HW reset line to be assert / deassert in order to enable fully
+ * the IP.
+ */
+static int _assert_hardreset(struct omap_hwmod *oh, const char *name)
+{
+   u8 shift;
+
+   if (!oh)
+   return -EINVAL;
+
+   shift = _lookup_hardreset(oh, name);
+   if (IS_ERR_VALUE(shift))
+   return shift;
+
+   if (cpu_is_omap24xx() || cpu_is_omap34xx())
+   return omap2_prm_assert_hardreset(oh->prcm.omap2.module_offs,
+ shift);
+   else if (cpu_is_omap44xx())
+   return omap4_prm_assert_hardreset(oh->prcm.omap4.rstctrl_reg,
+ shift);
+   else
+   return -EINVAL;
+}
+
+/**
+ * _deassert_ha

[PATCH 07/11] OMAP4: PRM: add module hard reset support

2010-09-21 Thread Paul Walmsley
From: Benoît Cousson 

Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
under the control of the PRM.  This patch adds an API for this purpose
for OMAP4 devices:

int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);

This API is intended to be used only by the hwmod code - a subsequent
patch will add that support to hwmod.

This patch is a collaboration between Benoît Cousson 
and Paul Walmsley .

Signed-off-by: Paul Walmsley 
Signed-off-by: Benoît Cousson 
---
 arch/arm/mach-omap2/Makefile  |2 -
 arch/arm/mach-omap2/prm.h |   13 -
 arch/arm/mach-omap2/prm44xx.c |  116 +
 3 files changed, 129 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prm44xx.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..c0da784 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -15,7 +15,7 @@ clock-common  = clock.o 
clock_common_data.o \
 
 obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
 obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
-obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) $(hwmod-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common) prm44xx.o $(hwmod-common)
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index 588873b..bc7e6e6 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -5,7 +5,7 @@
  * OMAP2/3 Power/Reset Management (PRM) register definitions
  *
  * Copyright (C) 2007-2009 Texas Instruments, Inc.
- * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2010 Nokia Corporation
  *
  * Written by Paul Walmsley
  *
@@ -246,6 +246,10 @@ static inline u32 prm_clear_mod_reg_bits(u32 bits, s16 
module, s16 idx)
return prm_rmw_mod_reg_bits(bits, 0x0, module, idx);
 }
 
+int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
+int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
+int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
+
 #endif
 
 /*
@@ -398,4 +402,11 @@ static inline u32 prm_clear_mod_reg_bits(u32 bits, s16 
module, s16 idx)
 #define OMAP_POWERSTATE_MASK   (0x3 << 0)
 
 
+/*
+ * MAX_MODULE_HARDRESET_WAIT: Maximum microseconds to wait for an OMAP
+ * submodule to exit hardreset
+ */
+#define MAX_MODULE_HARDRESET_WAIT  1
+
+
 #endif
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
new file mode 100644
index 000..a1ff918
--- /dev/null
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -0,0 +1,116 @@
+/*
+ * OMAP4 PRM module functions
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ * Benoît Cousson
+ * Paul Walmsley
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "prm.h"
+#include "prm-regbits-44xx.h"
+
+/*
+ * Address offset (in bytes) between the reset control and the reset
+ * status registers: 4 bytes on OMAP4
+ */
+#define OMAP4_RST_CTRL_ST_OFFSET   4
+
+/**
+ * omap4_prm_is_hardreset_asserted - read the HW reset line state of
+ * submodules contained in the hwmod module
+ * @rstctrl_reg: RM_RSTCTRL register address for this module
+ * @shift: register bit shift corresponding to the reset line to check
+ *
+ * Returns 1 if the (sub)module hardreset line is currently asserted,
+ * 0 if the (sub)module hardreset line is not currently asserted, or
+ * -EINVAL upon parameter error.
+ */
+int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift)
+{
+   if (!cpu_is_omap44xx() || !rstctrl_reg)
+   return -EINVAL;
+
+   return omap4_prm_read_bits_shift(rstctrl_reg, (1 << shift));
+}
+
+/**
+ * omap4_prm_assert_hardreset - assert the HW reset line of a submodule
+ * @rstctrl_reg: RM_RSTCTRL register address for this module
+ * @shift: register bit shift corresponding to the reset line to assert
+ *
+ * Some IPs like dsp, ipu or iva contain processors that require an HW
+ * reset line to be asserted / deasserted in order to fully enable the
+ * IP.  These modules may have multiple hard-reset lines that reset
+ * different 'submodules' inside the IP block.  This function will
+ * place the submodule into reset.  Returns 0 upon success or -EINVAL
+ * upon an argument error.
+ */
+int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift)
+{
+   u32 mask;
+
+   if (!cpu_is_omap44xx() || !rstctrl_reg)
+   return -EINVAL;
+
+   mask = 1 << shift;
+   omap4_p

[PATCH 04/11] OMAP4: prcm: Fix global warm reset bit position

2010-09-21 Thread Paul Walmsley
From: Rajeev Kulkarni 

OMAP4 platform has different register bits for Warm and Cold Resets.
Write one into appropriate bits.

Signed-off-by: Rajeev Kulkarni 
Cc: Leed Aguilar 
[b-cous...@ti.com: Change the define with the proper one from omap4 headers]
Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/prcm.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index c201374..96f4616 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -33,6 +33,7 @@
 #include "cm.h"
 #include "prm.h"
 #include "prm-regbits-24xx.h"
+#include "prm-regbits-44xx.h"
 
 static void __iomem *prm_base;
 static void __iomem *cm_base;
@@ -161,8 +162,8 @@ void omap_prcm_arch_reset(char mode, const char *cmd)
prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
 OMAP2_RM_RSTCTRL);
if (cpu_is_omap44xx())
-   prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs,
-OMAP4_RM_RSTCTRL);
+   prm_set_mod_reg_bits(OMAP4430_RST_GLOBAL_WARM_SW_MASK,
+prcm_offs, OMAP4_RM_RSTCTRL);
 }
 
 static inline u32 __omap_prcm_read(void __iomem *base, s16 module, u16 reg)


--
To unsubscribe from this list: send the line "unsubscribe 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 08/11] OMAP2/3: PRM: add module hard reset support

2010-09-21 Thread Paul Walmsley
This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
developed in the previous patch.

This patch is a collaboration between Benoît Cousson 
and Paul Walmsley .

Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
---
 arch/arm/mach-omap2/Makefile   |2 -
 arch/arm/mach-omap2/prm.h  |5 ++
 arch/arm/mach-omap2/prm2xxx_3xxx.c |  110 
 3 files changed, 116 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prm2xxx_3xxx.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c0da784..eb2504a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,7 +5,7 @@
 # Common support
 obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
 
-omap-2-3-common= irq.o sdrc.o
+omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
 hwmod-common   = omap_hwmod.o \
  omap_hwmod_common_data.o
 prcm-common= prcm.o powerdomain.o
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index bc7e6e6..7be040b 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -246,6 +246,11 @@ static inline u32 prm_clear_mod_reg_bits(u32 bits, s16 
module, s16 idx)
return prm_rmw_mod_reg_bits(bits, 0x0, module, idx);
 }
 
+/* These omap2_ PRM functions apply to both OMAP2 and 3 */
+int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift);
+int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
+int omap2_prm_deassert_hardreset(s16 prm_mod, u8 shift);
+
 int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
 int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
 int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c 
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
new file mode 100644
index 000..421771e
--- /dev/null
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -0,0 +1,110 @@
+/*
+ * OMAP2/3 PRM module functions
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ * Benoît Cousson
+ * Paul Walmsley
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "prm.h"
+#include "prm-regbits-24xx.h"
+#include "prm-regbits-34xx.h"
+
+/**
+ * omap2_prm_is_hardreset_asserted - read the HW reset line state of
+ * submodules contained in the hwmod module
+ * @prm_mod: PRM submodule base (e.g. CORE_MOD)
+ * @shift: register bit shift corresponding to the reset line to check
+ *
+ * Returns 1 if the (sub)module hardreset line is currently asserted,
+ * 0 if the (sub)module hardreset line is not currently asserted, or
+ * -EINVAL if called while running on a non-OMAP2/3 chip.
+ */
+int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8 shift)
+{
+   if (!(cpu_is_omap24xx() || cpu_is_omap34xx()))
+   return -EINVAL;
+
+   return prm_read_mod_bits_shift(prm_mod, OMAP2_RM_RSTCTRL,
+  (1 << shift));
+}
+
+/**
+ * omap2_prm_assert_hardreset - assert the HW reset line of a submodule
+ * @prm_mod: PRM submodule base (e.g. CORE_MOD)
+ * @shift: register bit shift corresponding to the reset line to assert
+ *
+ * Some IPs like dsp or iva contain processors that require an HW
+ * reset line to be asserted / deasserted in order to fully enable the
+ * IP.  These modules may have multiple hard-reset lines that reset
+ * different 'submodules' inside the IP block.  This function will
+ * place the submodule into reset.  Returns 0 upon success or -EINVAL
+ * upon an argument error.
+ */
+int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift)
+{
+   u32 mask;
+
+   if (!(cpu_is_omap24xx() || cpu_is_omap34xx()))
+   return -EINVAL;
+
+   mask = 1 << shift;
+   prm_rmw_mod_reg_bits(mask, mask, prm_mod, OMAP2_RM_RSTCTRL);
+
+   return 0;
+}
+
+/**
+ * omap2_prm_deassert_hardreset - deassert a submodule hardreset line and wait
+ * @prm_mod: PRM submodule base (e.g. CORE_MOD)
+ * @shift: register bit shift corresponding to the reset line to deassert
+ *
+ * Some IPs like dsp or iva contain processors that require an HW
+ * reset line to be asserted / deasserted in order to fully enable the
+ * IP.  These modules may have multiple hard-reset lines that reset
+ * different 'submodules' inside the IP block.  This function will
+ * take the submodule out of reset and wait until the PRCM indicates
+ * that the reset has completed before returning.  Returns 0 upon success or
+ * -EINVAL upon an argument error, -EEXIST if

[PATCH 01/11] OMAP: hwmod: Rename dma_ch to dma_req

2010-09-21 Thread Paul Walmsley
From: Benoit Cousson 

The dma request line attribute was named dma channel, which leads
to confusion with the real dma channel definition.

Signed-off-by: Benoit Cousson 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |   10 +-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   12 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cb911d7..8bf19a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1468,7 +1468,7 @@ int omap_hwmod_count_resources(struct omap_hwmod *oh)
 {
int ret, i;
 
-   ret = oh->mpu_irqs_cnt + oh->sdma_chs_cnt;
+   ret = oh->mpu_irqs_cnt + oh->sdma_reqs_cnt;
 
for (i = 0; i < oh->slaves_cnt; i++)
ret += oh->slaves[i]->addr_cnt;
@@ -1501,10 +1501,10 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh, 
struct resource *res)
r++;
}
 
-   for (i = 0; i < oh->sdma_chs_cnt; i++) {
-   (res + r)->name = (oh->sdma_chs + i)->name;
-   (res + r)->start = (oh->sdma_chs + i)->dma_ch;
-   (res + r)->end = (oh->sdma_chs + i)->dma_ch;
+   for (i = 0; i < oh->sdma_reqs_cnt; i++) {
+   (res + r)->name = (oh->sdma_reqs + i)->name;
+   (res + r)->start = (oh->sdma_reqs + i)->dma_req;
+   (res + r)->end = (oh->sdma_reqs + i)->dma_req;
(res + r)->flags = IORESOURCE_DMA;
r++;
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index a4e508d..5506d80 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -96,7 +96,7 @@ struct omap_hwmod_irq_info {
 /**
  * struct omap_hwmod_dma_info - DMA channels used by the hwmod
  * @name: name of the DMA channel (module local name)
- * @dma_ch: DMA channel ID
+ * @dma_req: DMA request ID
  *
  * @name should be something short, e.g., "tx" or "rx".  It is for use
  * by platform_get_resource_byname().  It is defined locally to the
@@ -104,7 +104,7 @@ struct omap_hwmod_irq_info {
  */
 struct omap_hwmod_dma_info {
const char  *name;
-   u16 dma_ch;
+   u16 dma_req;
 };
 
 /**
@@ -410,7 +410,7 @@ struct omap_hwmod_class {
  * @class: struct omap_hwmod_class * to the class of this hwmod
  * @od: struct omap_device currently associated with this hwmod (internal use)
  * @mpu_irqs: ptr to an array of MPU IRQs (see also mpu_irqs_cnt)
- * @sdma_chs: ptr to an array of SDMA channel IDs (see also sdma_chs_cnt)
+ * @sdma_reqs: ptr to an array of System DMA request IDs (see sdma_reqs_cnt)
  * @prcm: PRCM data pertaining to this hwmod
  * @main_clk: main clock: OMAP clock name
  * @_clk: pointer to the main struct clk (filled in at runtime)
@@ -424,7 +424,7 @@ struct omap_hwmod_class {
  * @msuspendmux_reg_id: CONTROL_MSUSPENDMUX register ID (1-6)
  * @msuspendmux_shift: CONTROL_MSUSPENDMUX register bit shift
  * @mpu_irqs_cnt: number of @mpu_irqs
- * @sdma_chs_cnt: number of @sdma_chs
+ * @sdma_reqs_cnt: number of @sdma_reqs
  * @opt_clks_cnt: number of @opt_clks
  * @master_cnt: number of @master entries
  * @slaves_cnt: number of @slave entries
@@ -448,7 +448,7 @@ struct omap_hwmod {
struct omap_hwmod_class *class;
struct omap_device  *od;
struct omap_hwmod_irq_info  *mpu_irqs;
-   struct omap_hwmod_dma_info  *sdma_chs;
+   struct omap_hwmod_dma_info  *sdma_reqs;
union {
struct omap_hwmod_omap2_prcm omap2;
struct omap_hwmod_omap4_prcm omap4;
@@ -468,7 +468,7 @@ struct omap_hwmod {
u8  msuspendmux_shift;
u8  response_lat;
u8  mpu_irqs_cnt;
-   u8  sdma_chs_cnt;
+   u8  sdma_reqs_cnt;
u8  opt_clks_cnt;
u8  masters_cnt;
u8  slaves_cnt;


--
To unsubscribe from this list: send the line "unsubscribe 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 00/11] OMAP: hwmod: core patches for 2.6.37

2010-09-21 Thread Paul Walmsley
Hello,

This series contains hwmod core fixes and improvements, and is intended for
merging via Tony's tree for 2.6.37.

The patches in this series are also available via git at

git://git.pwsan.com/linux-2.6 hwmod_2.6.37

based on v2.6.36-rc5.


regards,

- Paul

---

hwmod_2.6.37
   textdata bss dec  hex filename
6531587  455008 5615992 12602587  c04cdb vmlinux.omap2plus.orig
6533467  456160 5615992 12605619  c058b3 vmlinux.omap2plus.patched


Benoit Cousson (4):
  OMAP: hwmod: Rename dma_ch to dma_req
  OMAP: hwmod: Do not disable clocks if hwmod already in idle
  OMAP4: prcm: Add temporarily helper functions for rmw and read inside the 
PRM
  OMAP: hwmod: Force a softreset during _setup

Benoît Cousson (2):
  OMAP4: PRM: add module hard reset support
  OMAP: hwmod: Add hardreset management support

Kevin Hilman (1):
  OMAP: hwmod: separate list locking and hwmod hardware locking

Liam Girdwood (1):
  OMAP: hwmod: Fix omap_hwmod_reset wrong state test

Paul Walmsley (2):
  OMAP2/3: PRM: add module hard reset support
  OMAP: hwmod: add an hardreset API for use by other core code

Rajeev Kulkarni (1):
  OMAP4: prcm: Fix global warm reset bit position


 arch/arm/mach-omap2/Makefile |4 
 arch/arm/mach-omap2/omap_hwmod.c |  348 ++
 arch/arm/mach-omap2/prcm.c   |   29 ++
 arch/arm/mach-omap2/prm.h|   18 +
 arch/arm/mach-omap2/prm2xxx_3xxx.c   |  110 
 arch/arm/mach-omap2/prm44xx.c|  116 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h |   36 ++-
 arch/arm/plat-omap/include/plat/prcm.h   |2 
 8 files changed, 593 insertions(+), 70 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prm2xxx_3xxx.c
 create mode 100644 arch/arm/mach-omap2/prm44xx.c

--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: Keypad: Fix failure exit path in probe

2010-09-21 Thread Dmitry Torokhov
Hi,

On Tue, Sep 21, 2010 at 07:11:01PM +0530, G, Manjunath Kondaiah wrote:
> 
> Hi,
> 
> > -Original Message-
> > From: Ameya Palande [mailto:ameya.pala...@nokia.com] 
> > Sent: Tuesday, September 21, 2010 7:04 PM
> > To: G, Manjunath Kondaiah
> > Cc: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org; 
> > Dmitry Torokhov; linux-arm-ker...@lists.infradead.org; Tony Lindgren
> > Subject: Re: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe
> > 
> > Hi Manjunath,
> > 
> > On Tue, 2010-09-21 at 13:49 +0200, ext G, Manjunath Kondaiah wrote:
> > > The failure exit paths seems to be wrong in probe function.
> > > This patch corrects exit failure paths for error handling cases.
> > 

And also adds memory leak...


> > https://patchwork.kernel.org/patch/160551/
> > Any comments on this?
> 
> Looks fine. Sorry, I didn't look at the change. This version seems to 
> be better. 
> 

I do not understand why we need to separate memory allocations. It looks
like the minimal patch should be like one below.

Thanks.

-- 
Dmitry


Input: twl4030_keypad - fix error handling path

From: Dmitry Torokhov 

We should not try to call free_irq() when request_irq() failed.

Reported-by: G, Manjunath Kondaiah 
Signed-off-by: Dmitry Torokhov 
---

 drivers/input/keyboard/twl4030_keypad.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)


diff --git a/drivers/input/keyboard/twl4030_keypad.c 
b/drivers/input/keyboard/twl4030_keypad.c
index fb16b5e..09bef79 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -406,23 +406,22 @@ static int __devinit twl4030_kp_probe(struct 
platform_device *pdev)
if (error) {
dev_info(kp->dbg_dev, "request_irq failed for irq no=%d\n",
kp->irq);
-   goto err3;
+   goto err2;
}
 
/* Enable KP and TO interrupts now. */
reg = (u8) ~(KEYP_IMR1_KP | KEYP_IMR1_TO);
if (twl4030_kpwrite_u8(kp, reg, KEYP_IMR1)) {
error = -EIO;
-   goto err4;
+   goto err3;
}
 
platform_set_drvdata(pdev, kp);
return 0;
 
-err4:
+err3:
/* mask all events - we don't care about the result */
(void) twl4030_kpwrite_u8(kp, 0xff, KEYP_IMR1);
-err3:
free_irq(kp->irq, NULL);
 err2:
input_unregister_device(input);
--
To unsubscribe from this list: send the line "unsubscribe 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] omap3: cm-t3517: add support for usb host.

2010-09-21 Thread Gadiyar, Anand
On Tue, Sep 21, 2010 at 9:33 PM, Igor Grinberg  wrote:
> add support for hsusb host ports 1, 2 and on-module usb hub.
>
> Signed-off-by: Igor Grinberg 
> ---
>  arch/arm/mach-omap2/board-cm-t3517.c |   50 
> ++

...

> @@ -100,6 +102,47 @@ static void __init cm_t3517_init_rtc(void)
>  static inline void cm_t3517_init_rtc(void) {}
>  #endif
>
> +#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)

Hi Igor,


Do we really need to make these conditional on the driver being built?

The hardware is present on the board at all times, right?
It should be okay to execute this code independent of whether
the driver is built or not. The device registration can be unconditional
and if there is no driver present, we won't probe anyway.

(I see some similar logic in usb-ehci.c - probably a good idea to remove
it as well).

- Anand

> +#define HSUSB1_RESET_GPIO      (146)
> +#define HSUSB2_RESET_GPIO      (147)
> +#define USB_HUB_RESET_GPIO     (152)
> +
> +static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
> +       .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
> +       .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
> +       .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
> +
> +       .phy_reset  = true,
> +       .reset_gpio_port[0]  = HSUSB1_RESET_GPIO,
> +       .reset_gpio_port[1]  = HSUSB2_RESET_GPIO,
> +       .reset_gpio_port[2]  = -EINVAL,
> +};
> +
> +static int cm_t3517_init_usbh(void)
> +{
> +       int err;
> +
> +       err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
> +       if (err) {
> +               pr_err("CM-T3517: usb hub rst gpio request failed: %d\n", 
> err);
> +       } else {
> +               gpio_direction_output(USB_HUB_RESET_GPIO, 0);
> +               udelay(10);
> +               gpio_set_value(USB_HUB_RESET_GPIO, 1);
> +               msleep(1);
> +       }
> +
> +       usb_ehci_init(&cm_t3517_ehci_pdata);
> +
> +       return 0;
> +}
> +#else
> +static inline int cm_t3517_init_usbh(void)
> +{
> +       return 0;
> +}
> +#endif
> +
--
To unsubscribe from this list: send the line "unsubscribe 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: Handle __flush_icache_all for CONFIG_SMP_ON_UP

2010-09-21 Thread Tony Lindgren
* Tony Lindgren  [100914 12:04]:
> 
> Here's a patch for __flush_icache_all. I believe this is the last
> remaining patch we need.
> 
> The only other thing I can think of are the conflicts with
> CONFIG_CPU_32v6K, on early ARM1136 and later ARM11 systems if somebody
> wants to compile a kernel that supports both. But that's not needed for
> omap2, so we can boot now omap2, 3 and 4 with a single defconfig :)

Here's an updated version with a typo fix s/fluch/flush/ from Anand.

Regards,

Tony

From: Tony Lindgren 
Date: Mon, 20 Sep 2010 16:37:16 -0700
Subject: [PATCH] ARM: Handle __flush_icache_all for CONFIG_SMP_ON_UP

Do this by adding flush_icache_all to cache_fns for ARMv6 and 7.
As flush_icache_all may neeed to be called from flush_kern_cache_all,
add it as the first entry in the cache_fns.

Note that now we can remove the ARM_ERRATA_411920 dependency
to !SMP so it can be selected on UP ARMv6 processors, such
as omap2.

Signed-off-by: Tony Lindgren 
Signed-off-by: Anand Gadiyar 

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1017,7 +1017,7 @@ endif
 
 config ARM_ERRATA_411920
bool "ARM errata: Invalidation of the Instruction Cache operation can 
fail"
-   depends on CPU_V6 && !SMP
+   depends on CPU_V6
help
  Invalidation of the Instruction Cache operation can
  fail. This erratum is present in 1136 (before r1p4), 1156 and 1176.
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -156,6 +156,12 @@
  * Please note that the implementation of these, and the required
  * effects are cache-type (VIVT/VIPT/PIPT) specific.
  *
+ * flush_icache_all()
+ *
+ * Unconditionally clean and invalidate the entire icache.
+ * Currently only needed for cache-v6.S and cache-v7.S, see
+ * __flush_icache_all for the generic implementation.
+ *
  * flush_kern_all()
  *
  * Unconditionally clean and invalidate the entire cache.
@@ -206,6 +212,7 @@
  */
 
 struct cpu_cache_fns {
+   void (*flush_icache_all)(void);
void (*flush_kern_all)(void);
void (*flush_user_all)(void);
void (*flush_user_range)(unsigned long, unsigned long, unsigned int);
@@ -227,6 +234,7 @@ struct cpu_cache_fns {
 
 extern struct cpu_cache_fns cpu_cache;
 
+#define __cpuc_flush_icache_allcpu_cache.flush_icache_all
 #define __cpuc_flush_kern_all  cpu_cache.flush_kern_all
 #define __cpuc_flush_user_all  cpu_cache.flush_user_all
 #define __cpuc_flush_user_rangecpu_cache.flush_user_range
@@ -246,6 +254,7 @@ extern struct cpu_cache_fns cpu_cache;
 
 #else
 
+#define __cpuc_flush_icache_all__glue(_CACHE,_flush_icache_all)
 #define __cpuc_flush_kern_all  __glue(_CACHE,_flush_kern_cache_all)
 #define __cpuc_flush_user_all  __glue(_CACHE,_flush_user_cache_all)
 #define __cpuc_flush_user_range
__glue(_CACHE,_flush_user_cache_range)
@@ -253,6 +262,7 @@ extern struct cpu_cache_fns cpu_cache;
 #define __cpuc_coherent_user_range __glue(_CACHE,_coherent_user_range)
 #define __cpuc_flush_dcache_area   __glue(_CACHE,_flush_kern_dcache_area)
 
+extern void __cpuc_flush_icache_all(void);
 extern void __cpuc_flush_kern_all(void);
 extern void __cpuc_flush_user_all(void);
 extern void __cpuc_flush_user_range(unsigned long, unsigned long, unsigned 
int);
@@ -291,6 +301,37 @@ extern void copy_to_user_page(struct vm_area_struct *, 
struct page *,
 /*
  * Convert calls to our calling convention.
  */
+
+/* Invalidate I-cache */
+#define __flush_icache_all_generic()   \
+   asm("mcrp15, 0, %0, c7, c5, 0"  \
+   : : "r" (0));
+
+/* Invalidate I-cache inner shareable */
+#define __flush_icache_all_v7_smp()\
+   asm("mcrp15, 0, %0, c7, c1, 0"  \
+   : : "r" (0));
+
+/*
+ * Optimized __flush_icache_all for the common cases. Note that UP ARMv7
+ * will fall through to use __flush_icache_all_generic.
+ */
+#if (defined(CONFIG_CPU_V7) && defined(CONFIG_CPU_V6)) ||  \
+   defined(CONFIG_SMP_ON_UP)
+#define __flush_icache_preferred   __cpuc_flush_icache_all
+#elif __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
+#define __flush_icache_preferred   __flush_icache_all_v7_smp
+#elif __LINUX_ARM_ARCH__ == 6 && defined(CONFIG_ARM_ERRATA_411920)
+#define __flush_icache_preferred   __cpuc_flush_icache_all
+#else
+#define __flush_icache_preferred   __flush_icache_all_generic
+#endif
+
+static inline void __flush_icache_all(void)
+{
+   __flush_icache_preferred();
+}
+
 #define flush_cache_all()  __cpuc_flush_kern_all()
 
 static inline void vivt_flush_cache_mm(struct mm_struct *mm)
@@ -366,21 +407,6 @@ extern void flush_cache_page(struct vm_area_struct *vma, 
unsigned long user_addr
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
 exte

Re: [PATCH 0/3] OMAP: hwmod: Add hardreset and softreset management

2010-09-21 Thread Paul Walmsley
Hi Benoît,

On Tue, 21 Sep 2010, Cousson, Benoit wrote:

> That's really good. The low level reset does indeed belong to PRM more than
> the hwmod core code.
> Thanks for the OMAP2/3 stuff as well, IVA people were starting to ping me for
> that support.
> 
> I've just rebased my OMAP4 hwmods series on top on this one, and it work fine.

Cool.

> Are you targeting that series for 2.6.37?

Yep, I'll send those patches to the linux-arm-kernel mailing list today, 
along with the other hwmod base patches; I'd like to get those in for 
2.6.37.

> I have a couple of patches on top of that code that will fix the softreset
> with optional clocks. This code is fixing the GPIO reset issue that I observed
> in the past.
> 
> I'll send you that soon.

OK, sounds good.  If you cc the linux-arm-kernel mailing list when you 
send them out, that will make it easier to add those to the 2.6.37 queue 
if they arrive on time.

Thanks for the review and for the comments,


- Paul

Re: [PATCH] ARM: fix build break due to typo in cacheflush.h

2010-09-21 Thread Tony Lindgren
* Anand Gadiyar  [100921 08:57]:
> commit 9d85ac1e6 introduced a small typo. This causes the build
> to break when CONFIG_CPU_V7 is set and CONFIG_CPU_V6 and
> CONFIG_SMP_ON_UP are not. (log below)
> 
>   CC  init/main.o
> In file included from include/linux/highmem.h:9,
>  from include/linux/pagemap.h:10,
>  from include/linux/mempolicy.h:70,
>  from init/main.c:50:
> arch/arm/include/asm/cacheflush.h: In function '__flush_icache_all':
> arch/arm/include/asm/cacheflush.h:332: error: implicit declaration of 
> function '__flush_icache_preferred'
> make[1]: *** [init/main.o] Error 1
> make: *** [init] Error 2
> 
> Signed-off-by: Anand Gadiyar 
> Cc: Tony Lindgren 
> ---
>  arch/arm/include/asm/cacheflush.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-omap-2.6/arch/arm/include/asm/cacheflush.h
> ===
> --- linux-omap-2.6.orig/arch/arm/include/asm/cacheflush.h
> +++ linux-omap-2.6/arch/arm/include/asm/cacheflush.h
> @@ -324,7 +324,7 @@ extern void copy_to_user_page(struct vm_
>  #elif __LINUX_ARM_ARCH__ == 6 && defined(CONFIG_ARM_ERRATA_411920)
>  #define __flush_icache_preferred __cpuc_flush_icache_all
>  #else
> -#define __fluch_icache_preferred __flush_icache_all_generic
> +#define __flush_icache_preferred __flush_icache_all_generic
>  #endif
>  
>  static inline void __flush_icache_all(void)

Thanks, will merge that into the original patch with your S-O-B
and repost.

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] ARM: fix build break due to typo in cacheflush.h

2010-09-21 Thread Anand Gadiyar
commit 9d85ac1e6 introduced a small typo. This causes the build
to break when CONFIG_CPU_V7 is set and CONFIG_CPU_V6 and
CONFIG_SMP_ON_UP are not. (log below)

  CC  init/main.o
In file included from include/linux/highmem.h:9,
 from include/linux/pagemap.h:10,
 from include/linux/mempolicy.h:70,
 from init/main.c:50:
arch/arm/include/asm/cacheflush.h: In function '__flush_icache_all':
arch/arm/include/asm/cacheflush.h:332: error: implicit declaration of function 
'__flush_icache_preferred'
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2

Signed-off-by: Anand Gadiyar 
Cc: Tony Lindgren 
---
 arch/arm/include/asm/cacheflush.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-omap-2.6/arch/arm/include/asm/cacheflush.h
===
--- linux-omap-2.6.orig/arch/arm/include/asm/cacheflush.h
+++ linux-omap-2.6/arch/arm/include/asm/cacheflush.h
@@ -324,7 +324,7 @@ extern void copy_to_user_page(struct vm_
 #elif __LINUX_ARM_ARCH__ == 6 && defined(CONFIG_ARM_ERRATA_411920)
 #define __flush_icache_preferred   __cpuc_flush_icache_all
 #else
-#define __fluch_icache_preferred   __flush_icache_all_generic
+#define __flush_icache_preferred   __flush_icache_all_generic
 #endif
 
 static inline void __flush_icache_all(void)
--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP: hwmod: Add hardreset and softreset management

2010-09-21 Thread Cousson, Benoit

Hi Paul,

On 9/21/2010 7:03 AM, Paul Walmsley wrote:

Hi Benoît,

I regret the delay -


Considering the job you did on that reset series, you are already 
forgiven :-)




On Thu, 5 Aug 2010, Benoit Cousson wrote:


Here are a reset management series.

- The first patch will be removed as soon as we will have the proper
   OMAP4 support for the prm_xxx accessors.
- The second one is adding hardreset support in order to allow
   syslink driver to manage properly the DSP and IPU processor
   reset.
- The last one is forcing a sofreset after the first init.
   Some IP might require sofreset after each wakeup
   from power domain OFF mode. That still needs to be confirm.


I've reviewed these patches and made a few changes.  The PRM register
twiddling has been moved out into a prm44xx.c file.  I also added OMAP2/3
hardreset support, based on your code.  Could you take a quick look at the
updated series (in subsequent E-mails, or the git branch below) and let me
know if you are okay with it?  I took some liberties in preserving your
changelogs and Signed-off-by's across the changes, so please let me know
if you'd like any changes in that regard.


That's really good. The low level reset does indeed belong to PRM more 
than the hwmod core code.
Thanks for the OMAP2/3 stuff as well, IVA people were starting to ping 
me for that support.


I've just rebased my OMAP4 hwmods series on top on this one, and it work 
fine.


Are you targeting that series for 2.6.37?
I have a couple of patches on top of that code that will fix the 
softreset with optional clocks. This code is fixing the GPIO reset issue 
that I observed in the past.


I'll send you that soon.

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


[PATCH 2/5] omap3: cm-t3517: add support for v3020 rtc.

2010-09-21 Thread Igor Grinberg
add support for v3020 rtc.

Signed-off-by: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t3517.c |   36 ++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 507d2d5..2b41c6d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -69,6 +70,35 @@ static void __init cm_t3517_init_leds(void)
 static inline void cm_t3517_init_leds(void) {}
 #endif
 
+#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
+#define RTC_IO_GPIO(153)
+#define RTC_WR_GPIO(154)
+#define RTC_RD_GPIO(160)
+#define RTC_CS_GPIO(163)
+
+struct v3020_platform_data cm_t3517_v3020_pdata = {
+   .use_gpio   = 1,
+   .gpio_cs= RTC_CS_GPIO,
+   .gpio_wr= RTC_WR_GPIO,
+   .gpio_rd= RTC_RD_GPIO,
+   .gpio_io= RTC_IO_GPIO,
+};
+
+static struct platform_device cm_t3517_rtc_device = {
+   .name   = "v3020",
+   .id = -1,
+   .dev= {
+   .platform_data = &cm_t3517_v3020_pdata,
+   }
+};
+
+static void __init cm_t3517_init_rtc(void)
+{
+   platform_device_register(&cm_t3517_rtc_device);
+}
+#else
+static inline void cm_t3517_init_rtc(void) {}
+#endif
 
 static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
 };
@@ -86,6 +116,11 @@ static void __init cm_t3517_init_irq(void)
 static struct omap_board_mux board_mux[] __initdata = {
/* GPIO186 - Green LED */
OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+   /* RTC GPIOs: IO, WR#, RD#, CS# */
+   OMAP3_MUX(MCBSP4_DR, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+   OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+   OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+   OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
 
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
@@ -95,6 +130,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+   cm_t3517_init_rtc();
 }
 
 MACHINE_START(CM_T3517, "Compulab CM-T3517")
-- 
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


[PATCH 4/5] omap3: cm-t3517: add support for NAND flash

2010-09-21 Thread Igor Grinberg
add support for NAND flash.

Signed-off-by: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t3517.c |   54 ++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2c7082d..4c26cf5 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -29,6 +29,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -38,6 +41,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mux.h"
 
@@ -143,6 +148,54 @@ static inline int cm_t3517_init_usbh(void)
 }
 #endif
 
+#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition cm_t3517_nand_partitions[] = {
+   {
+   .name   = "xloader",
+   .offset = 0,/* Offset = 0x0 */
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE
+   },
+   {
+   .name   = "uboot",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 15 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "uboot environment",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x26 */
+   .size   = 2 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "linux",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "rootfs",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x68 */
+   .size   = MTDPART_SIZ_FULL,
+   },
+};
+
+static struct omap_nand_platform_data cm_t3517_nand_data = {
+   .parts  = cm_t3517_nand_partitions,
+   .nr_parts   = ARRAY_SIZE(cm_t3517_nand_partitions),
+   .dma_channel= -1,   /* disable DMA in OMAP NAND driver */
+   .cs = 0,
+};
+
+static void __init cm_t3517_init_nand(void)
+{
+   if (gpmc_nand_init(&cm_t3517_nand_data) < 0)
+   pr_err("CM-T3517: NAND initialization failed\n");
+}
+#else
+static inline void cm_t3517_init_nand(void) {}
+#endif
+
 static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
 };
 
@@ -179,6 +232,7 @@ static void __init cm_t3517_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
cm_t3517_init_leds();
+   cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
 }
-- 
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


[PATCH 5/5] omap3: cm-t3517: add support for TI HECC

2010-09-21 Thread Igor Grinberg
add support for TI HECC.

Signed-off-by: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t3517.c |   45 ++
 1 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 4c26cf5..1115b8a 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -44,6 +45,8 @@
 #include 
 #include 
 
+#include 
+
 #include "mux.h"
 
 #if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
@@ -77,6 +80,47 @@ static void __init cm_t3517_init_leds(void)
 static inline void cm_t3517_init_leds(void) {}
 #endif
 
+#if defined(CONFIG_CAN_TI_HECC) || defined(CONFIG_CAN_TI_HECC_MODULE)
+static struct resource cm_t3517_hecc_resources[] = {
+   {
+   .start  = AM35XX_IPSS_HECC_BASE,
+   .end= AM35XX_IPSS_HECC_BASE + SZ_16K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_HECC0_IRQ,
+   .end= INT_35XX_HECC0_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct ti_hecc_platform_data cm_t3517_hecc_pdata = {
+   .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+   .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+   .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+   .mbx_offset = AM35XX_HECC_MBOX_OFFSET,
+   .int_line   = AM35XX_HECC_INT_LINE,
+   .version= AM35XX_HECC_VERSION,
+};
+
+static struct platform_device cm_t3517_hecc_device = {
+   .name   = "ti_hecc",
+   .id = 1,
+   .num_resources  = ARRAY_SIZE(cm_t3517_hecc_resources),
+   .resource   = cm_t3517_hecc_resources,
+   .dev= {
+   .platform_data  = &cm_t3517_hecc_pdata,
+   },
+};
+
+static void cm_t3517_init_hecc(void)
+{
+   platform_device_register(&cm_t3517_hecc_device);
+}
+#else
+static inline void cm_t3517_init_hecc(void) {}
+#endif
+
 #if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
 #define RTC_IO_GPIO(153)
 #define RTC_WR_GPIO(154)
@@ -235,6 +279,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_nand();
cm_t3517_init_rtc();
cm_t3517_init_usbh();
+   cm_t3517_init_hecc();
 }
 
 MACHINE_START(CM_T3517, "Compulab CM-T3517")
-- 
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


[PATCH 1/5] omap3: Introduce CompuLab CM-T3517 module.

2010-09-21 Thread Igor Grinberg
Add basic suppot, enable uart and led.

Signed-off-by: Igor Grinberg 
---
 arch/arm/mach-omap2/Kconfig  |7 ++
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-cm-t3517.c |  109 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 118 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index bb85f24..9ceb72b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -216,6 +216,13 @@ config MACH_CM_T35
select OMAP_PACKAGE_CUS
select OMAP_MUX
 
+config MACH_CM_T3517
+   bool "CompuLab CM-T3517 module"
+   depends on ARCH_OMAP3
+   default y
+   select OMAP_PACKAGE_CBB
+   select OMAP_MUX
+
 config MACH_IGEP0020
bool "IGEP v2 board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..7d991d0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_MACH_OMAP_3630SDP) += 
board-3630sdp.o \
   hsmmc.o
 obj-$(CONFIG_MACH_CM_T35)  += board-cm-t35.o \
   hsmmc.o
+obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
 obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
   hsmmc.o
 obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
new file mode 100644
index 000..507d2d5
--- /dev/null
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -0,0 +1,109 @@
+/*
+ * linux/arch/arm/mach-omap2/board-cm-t3517.c
+ *
+ * Support for the CompuLab CM-T3517 modules
+ *
+ * Copyright (C) 2010 CompuLab, Ltd.
+ * Author: Igor Grinberg 
+ *
+ * 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 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "mux.h"
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+static struct gpio_led cm_t3517_leds[] = {
+   [0] = {
+   .gpio   = 186,
+   .name   = "cm-t3517:green",
+   .default_trigger= "heartbeat",
+   .active_low = 0,
+   },
+};
+
+static struct gpio_led_platform_data cm_t3517_led_pdata = {
+   .num_leds   = ARRAY_SIZE(cm_t3517_leds),
+   .leds   = cm_t3517_leds,
+};
+
+static struct platform_device cm_t3517_led_device = {
+   .name   = "leds-gpio",
+   .id = -1,
+   .dev= {
+   .platform_data  = &cm_t3517_led_pdata,
+   },
+};
+
+static void __init cm_t3517_init_leds(void)
+{
+   platform_device_register(&cm_t3517_led_device);
+}
+#else
+static inline void cm_t3517_init_leds(void) {}
+#endif
+
+
+static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
+};
+
+static void __init cm_t3517_init_irq(void)
+{
+   omap_board_config = cm_t3517_config;
+   omap_board_config_size = ARRAY_SIZE(cm_t3517_config);
+
+   omap2_init_common_hw(NULL, NULL);
+   omap_init_irq();
+   omap_gpio_init();
+}
+
+static struct omap_board_mux board_mux[] __initdata = {
+   /* GPIO186 - Green LED */
+   OMAP3_MUX(SYS_CLKOUT2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+static void __init cm_t3517_init(void)
+{
+   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+   omap_serial_init();
+   cm_t3517_init_leds();
+}
+
+MACHINE_START(CM_T3517, "Compulab CM-T3517")
+   .phys_io= 0x4800,
+   .io_pg_offst= ((0xd800) >> 18) & 0xfffc,
+   .boot_params= 0x8100,
+   .map_io = omap3_map_io,
+   .reserve= omap_reserve,
+   .init_irq   = cm_t3517_init_irq,
+   .init_machine   = cm_t3517_init,
+   .timer  = &omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index ddf723b..4f637b5 100644
--- a/arch/arm/plat-omap/include/plat/un

[PATCH 0/5] Support for CompuLab CM-T3517 modules

2010-09-21 Thread Igor Grinberg
CompuLab CM-T3517 module is based on AM3517 (Sitara) SoC.
CM-T3517 supports on-board 256/128MB DDR2 DRAM, 512/128MB NAND flash,
WIFI-BlueTooth combo chip, USB HUB, AC97 Codec,
TouchScreen controller, RTC.

This patch series add a basic support for CM-T3517
and some of its peripheral devices.

Based on:
commit 44ed8ecfeb1f639c59897de3f551f50e3f0fd52e
Merge: 96542e6 0cbe681
Author: Tony Lindgren 
Date:   Mon Sep 20 15:14:25 2010 -0700

Linux-omap rebuilt: Merged in the smp-on-up patches for testing


Igor Grinberg (5):
  omap3: Introduce CompuLab CM-T3517 module.
  omap3: cm-t3517: add support for v3020 rtc.
  omap3: cm-t3517: add support for usb host.
  omap3: cm-t3517: add support for NAND flash
  omap3: cm-t3517: add support for TI HECC

 arch/arm/mach-omap2/Kconfig  |7 +
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-cm-t3517.c |  294 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 303 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-cm-t3517.c

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


[PATCH 3/5] omap3: cm-t3517: add support for usb host.

2010-09-21 Thread Igor Grinberg
add support for hsusb host ports 1, 2 and on-module usb hub.

Signed-off-by: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t3517.c |   50 ++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 2b41c6d..2c7082d 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 
@@ -100,6 +102,47 @@ static void __init cm_t3517_init_rtc(void)
 static inline void cm_t3517_init_rtc(void) {}
 #endif
 
+#if defined(CONFIG_USB_EHCI_HCD) || defined(CONFIG_USB_EHCI_HCD_MODULE)
+#define HSUSB1_RESET_GPIO  (146)
+#define HSUSB2_RESET_GPIO  (147)
+#define USB_HUB_RESET_GPIO (152)
+
+static struct ehci_hcd_omap_platform_data cm_t3517_ehci_pdata __initdata = {
+   .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+   .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+   .phy_reset  = true,
+   .reset_gpio_port[0]  = HSUSB1_RESET_GPIO,
+   .reset_gpio_port[1]  = HSUSB2_RESET_GPIO,
+   .reset_gpio_port[2]  = -EINVAL,
+};
+
+static int cm_t3517_init_usbh(void)
+{
+   int err;
+
+   err = gpio_request(USB_HUB_RESET_GPIO, "usb hub rst");
+   if (err) {
+   pr_err("CM-T3517: usb hub rst gpio request failed: %d\n", err);
+   } else {
+   gpio_direction_output(USB_HUB_RESET_GPIO, 0);
+   udelay(10);
+   gpio_set_value(USB_HUB_RESET_GPIO, 1);
+   msleep(1);
+   }
+
+   usb_ehci_init(&cm_t3517_ehci_pdata);
+
+   return 0;
+}
+#else
+static inline int cm_t3517_init_usbh(void)
+{
+   return 0;
+}
+#endif
+
 static struct omap_board_config_kernel cm_t3517_config[] __initdata = {
 };
 
@@ -121,6 +164,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(MCBSP4_DX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(MCBSP_CLKS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+   /* HSUSB1 RESET */
+   OMAP3_MUX(UART2_TX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+   /* HSUSB2 RESET */
+   OMAP3_MUX(UART2_RX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+   /* CM-T3517 USB HUB nRESET */
+   OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
@@ -131,6 +180,7 @@ static void __init cm_t3517_init(void)
omap_serial_init();
cm_t3517_init_leds();
cm_t3517_init_rtc();
+   cm_t3517_init_usbh();
 }
 
 MACHINE_START(CM_T3517, "Compulab CM-T3517")
-- 
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 00/11] OMAP: Serial: Add omap-serial driver with platform support

2010-09-21 Thread Govindraj


 Also the patch series updates various low level platform specific
 serial data to support omap-uarts with hwmod framework and adds support
 for uart4 on OMAP3630.
>>>
>>> This series is missing a couple things to work more broadly on all
>>> boards, specifically 3630-based boards.
>>>
>>> First, due to the current UART idle code base, you need to enable all
>>> OMAP UARTs 36xx.  Enabling less than all OMAP UARTs will break the
>>> current idle code.  As we discussed, the next phase we will move the
>>> idle management from this serial.c hackery into the omap-serial driver
>>> iteself.  Until then, you need to call omap_serial_init() on
>>> Zoom2/Zoom3.  Patch below[1]
>>>
>>> Also, you previously had a patch that updated omap_uart_idle_init() to
>>> handle 36xx and specifically UART4.  Without that, struct
>>> omap_uart_state is not setup correctly for UART4, and thus cannot be
>>> properly idled on 3630.
>>
>> ok fine, I will I incorporate initialize all uarts patch for zoom boards.
>>
>> Are you referring to this patch?
>> https://patchwork.kernel.org/patch/108066/
>>
>> Is this still needed if we have initialized all uarts?
>> This patch might not needed if we have initialized all uarts right?
>
> Right.  We don't need the above patchwork patch if all UARTs are
> initialized.
>
> The other patch I was referring to was the one that added UART4 support
> to omap_uart_idle_init() (added the wk_en, wk_st, padconf etc.)  I had a
> pending request for you to drop the muxmode from that patch, but the
> rest of it was still needed.
>
>>>
>>> Also, it's been a while since I tested this on OMAP2.  Please re-test on
>>> OMAP2 with the whole series.  Also, please report here the other
>>> platforms this was tested on.  The final needs to be tested on OMAP2, 3
>>> and 4 before merge.
>>
>> Yes Sure,
>>
>> Just FYI this patch series was also tested on omap2,3,4.
>>
>
> OK, be sure to test Zoom3, because my testing on Zoom3 led to a crash as
> soon as idle was enabled due to the missing init of all UARTs.


This patch series applied on top of pm-core branch

commit 4c1f85cdc189d41ee53c1bc3957a908c91cffc00
Merge: ca1684b 96c4e27
Author: Kevin Hilman 
Date:   Thu Sep 16 15:29:06 2010 -0700

with below changes:

1) if (uart->timeout)
uart->timeout = (30 * HZ);

2) #define DEFAULT_TIMEOUT 5 [temporary change for timeout]

I see ret count getting incremented on ZOOM3 even without "UART4 support
to omap_uart_idle_init()" patch.

I dont see any crash.

Logs Snip:

/ # mount -t debugfs debugfs /debug
/ #
/ #
/ # echo 1 > /debug/pm_debug/sleep_while_idle

/ # cat /debug/pm_debug/count
usbhost_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_pwrdm (ON),OFF:0,RET:773,INA:0,ON:774,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm 
(ON),OFF:0,RET:794,INA:0,ON:795,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
neon_pwrdm (ON),OFF:0,RET:796,INA:0,ON:797,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:796,INA:0,ON:797,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm 
(RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
per_clkdm->per_pwrdm (11)
usbhost_clkdm->usbhost_pwrdm (0)
cam_clkdm->cam_pwrdm (0)
dss_clkdm->dss_pwrdm (0)
core_l4_clkdm->core_pwrdm (9)
core_l3_clkdm->core_pwrdm (5)
d2d_clkdm->core_pwrdm (0)
sgx_clkdm->sgx_pwrdm (0)
iva2_clkdm->iva2_pwrdm (0)
neon_clkdm->neon_pwrdm (0)
mpu_clkdm->mpu_pwrdm (0)
prm_clkdm->wkup_pwrdm (0)
cm_clkdm->core_pwrdm (0)



-- 
---
Regards,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe 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: SMP_ON_UP? - Build break with custom minimal defconfig

2010-09-21 Thread Gadiyar, Anand
>>   CC      init/main.o
>> In file included from include/linux/highmem.h:9,
>>                  from include/linux/pagemap.h:10,
>>                  from include/linux/mempolicy.h:70,
>>                  from init/main.c:50:
>> /home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:
>> In function '__flush_icache_all':
>> /home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:332:
>> error: implicit declaration of function '__flush_icache_preferred'
>> make[1]: *** [init/main.o] Error 1
>> make: *** [init] Error 2
>>
>> I think this is related to the recent SMP_ON_UP patches.
>>
>> The reduced .config I'm using (generated using `make savedefconfig`) is 
>> below.
>>
>> I'll try and debug in a while, but just reporting for now.
>
> Yes that sounds like a bug in a smp_on_up related patch. Will try your
> defconfig here too.
>

Found it - it's due to a typo in the defines.

Patch coming up in a few minutes.

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


Re: SMP_ON_UP? - Build break with custom minimal defconfig

2010-09-21 Thread Tony Lindgren
* Gadiyar, Anand  [100921 08:41]:
> Hi all,
> 
> I was trying to use current linux-omap master to put together a custom
> minimal defconfig for a beagleboard, and I'm seeing a compile error:
> 
>   CC  init/main.o
> In file included from include/linux/highmem.h:9,
>  from include/linux/pagemap.h:10,
>  from include/linux/mempolicy.h:70,
>  from init/main.c:50:
> /home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:
> In function '__flush_icache_all':
> /home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:332:
> error: implicit declaration of function '__flush_icache_preferred'
> make[1]: *** [init/main.o] Error 1
> make: *** [init] Error 2
> 
> I think this is related to the recent SMP_ON_UP patches.
> 
> The reduced .config I'm using (generated using `make savedefconfig`) is below.
> 
> I'll try and debug in a while, but just reporting for now.

Yes that sounds like a bug in a smp_on_up related patch. Will try your
defconfig here too.

Thanks,

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


SMP_ON_UP? - Build break with custom minimal defconfig

2010-09-21 Thread Gadiyar, Anand
Hi all,

I was trying to use current linux-omap master to put together a custom
minimal defconfig for a beagleboard, and I'm seeing a compile error:

  CC  init/main.o
In file included from include/linux/highmem.h:9,
 from include/linux/pagemap.h:10,
 from include/linux/mempolicy.h:70,
 from init/main.c:50:
/home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:
In function '__flush_icache_all':
/home/userdata/a0393673/kernels/tony/linux-omap-2.6/arch/arm/include/asm/cacheflush.h:332:
error: implicit declaration of function '__flush_icache_preferred'
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2

I think this is related to the recent SMP_ON_UP patches.

The reduced .config I'm using (generated using `make savedefconfig`) is below.

I'll try and debug in a while, but just reporting for now.

- Anand

== CUT HERE ==
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_BLK_DEV_INITRD=y
CONFIG_EMBEDDED=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_OMAP=y
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_DM_TIMER=y
# CONFIG_ARCH_OMAP2PLUS_TYPICAL is not set
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_OMAP3_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
CONFIG_ARM_THUMBEE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_AEABI=y
CONFIG_LEDS=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyS2,115200"
CONFIG_KEXEC=y
CONFIG_FPE_NWFPE=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_BINFMT_MISC=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_MTD=y
CONFIG_MTD_CONCAT=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_OOPS=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_OMAP2=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_EEPROM_LEGACY=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_SCAN_ASYNC=y
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_TWL4030_PWRBUTTON=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_HW_RANDOM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_OMAP=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_TWL4030=y
CONFIG_WATCHDOG=y
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
CONFIG_TWL4030_CORE=y
CONFIG_TWL4030_POWER=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_FILE_STORAGE=m
CONFIG_TWL4030_USB=y
CONFIG_MMC=y
CONFIG_MMC_UNSAFE_RESUME=y
CONFIG_SDIO_UART=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_TWL4030=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_QUOTA=y
CONFIG_QFMT_V2=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_SUMMARY=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RUBIN=y
CONFIG_UBIFS_FS=y
CONFIG_CRAMFS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_KEYS=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_MD5=y
CONFI

Re: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode support

2010-09-21 Thread Tony Lindgren
* Ghorai, Sukumar  [100918 11:16]:
> > 
> > This handler should be in gpmc.c as it may be needed for other GPMC
> > connected devices on the same system. You can use chained irq handlers
> > to allow all the drivers to use the interrupt then.
> 
> [Ghorai] 
> You mean as this function used the gpmc-irq number in nand file, so handler 
> should move to gpmc.c file? 

Yes, other GPMC connected drivers may want to use it too for their chip selects.

>   1. For that we need to add one io-struct (to keep io buffer status) in 
> gpmc.c; 
>
>   2. Also need help how to sync between gpmc.c/omap_nand_irq() and 
> omap2.c/omap_write_buf_irq_pref(), men how read/write function know that work 
> done in interrupt-context? Or you prefer to move the complete IO function 
> (omap_read/write_buf_irq_pref) to gpmc.c?
> 
>   3. gpmc does not now about the read and write address that's applicable 
> for NAND. So how to pass the IO address from omap2.c to gpmc.c, interrupt 
> handler?

Hmm, I don't follow you. You can have the interrupt handler
both in gpmc.c and in the nand driver with set_irq_chained_handler()
and set_irq_data(). We are doing that already in lots of places,
like gpio.c and twl4030-irq.c. 
 
> So, please let me know your suggestion again such that I can post this time 
> itself. Otherwise again it will miss from coming release, this was 
> posted/reviewed for last release too. And suggest to void repeating of 
> missing release window again.

Yes would be nice to get this patch in, to me it seems that this
issue is the only blocker. It should be pretty easy change to
make.

Regards,

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


Re: [PATCH] OMAP4: HSMMC cmd line reset change

2010-09-21 Thread Tony Lindgren
* Madhusudhan  [100920 09:06]:
> > 
> > Please don't use cpu_is_omap tests in the drivers, drivers
> > should be generic.
> > 
> > Instead, just pass a feature flag in the platform_data for this
> > feature like HSMMC_REVERSE_RESET_LOGIC or similar.
> > 
> 
> This is not a feature. It is like an ERRATA fix. I am yet to receive an
> errata number though. How about dealing with this like an errata fix similar
> to the way in arch/mach-omap2/serial.c done for the uart case? 

Yes setting some HSMMC_ERRATA_XYZ flag works too.
 
> The mmc ip revision will not help because it really does not change to
> distinguish such issues.

OK. Then I guess your only option is to pass the errata flag in
the platform_data.

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] OMAP: hwmod: Enable module wakeup if in smartidle

2010-09-21 Thread Rajendra Nayak
If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Partha Basak 
Signed-off-by: Benoît Cousson 
Cc: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cb911d7..d82e7e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -659,8 +659,6 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_module_autoidle(oh, idlemode, &v);
}
 
-   /* XXX OCP ENAWAKEUP bit? */
-
/*
 * XXX The clock framework should handle this, by
 * calling into this code.  But this must wait until the
@@ -671,6 +669,10 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_clockactivity(oh, oh->class->sysc->clockact, &v);
 
_write_sysconfig(v, oh);
+
+   /* If slave is in SMARTIDLE, also enable wakeup */
+   if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE))
+   _enable_wakeup(oh);
 }
 
 /**
-- 
1.7.0.4

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


[PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's

2010-09-21 Thread Rajendra Nayak
This patch converts the i2c driver to use PM runtime apis

Signed-off-by: Rajendra Nayak 
Cc: Kevin Hilman 
Cc: Paul Walmsley 
---
 drivers/i2c/busses/i2c-omap.c |   67 +
 1 files changed, 21 insertions(+), 46 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7674efb..126bde9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* I2C controller revisions */
 #define OMAP_I2C_REV_2 0x20
@@ -175,8 +176,6 @@ struct omap_i2c_dev {
void __iomem*base;  /* virtual */
int irq;
int reg_shift;  /* bit shift for I2C register 
addresses */
-   struct clk  *iclk;  /* Interface clock */
-   struct clk  *fclk;  /* Functional clock */
struct completion   cmd_complete;
struct resource *ioarea;
u32 latency;/* maximum mpu wkup latency */
@@ -265,45 +264,18 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev 
*i2c_dev, int reg)
(i2c_dev->regs[reg] << i2c_dev->reg_shift));
 }
 
-static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static void omap_i2c_unidle(struct omap_i2c_dev *dev)
 {
-   int ret;
+   struct platform_device *pdev;
+   struct omap_i2c_bus_platform_data *pdata;
 
-   dev->iclk = clk_get(dev->dev, "ick");
-   if (IS_ERR(dev->iclk)) {
-   ret = PTR_ERR(dev->iclk);
-   dev->iclk = NULL;
-   return ret;
-   }
+   WARN_ON(!dev->idle);
 
-   dev->fclk = clk_get(dev->dev, "fck");
-   if (IS_ERR(dev->fclk)) {
-   ret = PTR_ERR(dev->fclk);
-   if (dev->iclk != NULL) {
-   clk_put(dev->iclk);
-   dev->iclk = NULL;
-   }
-   dev->fclk = NULL;
-   return ret;
-   }
+   pdev = to_platform_device(dev->dev);
+   pdata = pdev->dev.platform_data;
 
-   return 0;
-}
+   pm_runtime_get_sync(&pdev->dev);
 
-static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
-{
-   clk_put(dev->fclk);
-   dev->fclk = NULL;
-   clk_put(dev->iclk);
-   dev->iclk = NULL;
-}
-
-static void omap_i2c_unidle(struct omap_i2c_dev *dev)
-{
-   WARN_ON(!dev->idle);
-
-   clk_enable(dev->iclk);
-   clk_enable(dev->fclk);
if (cpu_is_omap34xx()) {
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
@@ -326,10 +298,15 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
 
 static void omap_i2c_idle(struct omap_i2c_dev *dev)
 {
+   struct platform_device *pdev;
+   struct omap_i2c_bus_platform_data *pdata;
u16 iv;
 
WARN_ON(dev->idle);
 
+   pdev = to_platform_device(dev->dev);
+   pdata = pdev->dev.platform_data;
+
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
if (dev->rev >= OMAP_I2C_REV_ON_4430)
omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
@@ -345,8 +322,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
dev->idle = 1;
-   clk_disable(dev->fclk);
-   clk_disable(dev->iclk);
+
+   pm_runtime_put_sync(&pdev->dev);
 }
 
 static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -356,6 +333,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long fclk_rate = 1200;
unsigned long timeout;
unsigned long internal_clk = 0;
+   struct clk *fclk;
 
if (dev->rev >= OMAP_I2C_REV_2) {
/* Disable I2C controller before soft reset */
@@ -414,7 +392,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 * always returns 12MHz for the functional clock, we can
 * do this bit unconditionally.
 */
-   fclk_rate = clk_get_rate(dev->fclk);
+   fclk = clk_get(dev->dev, "fck");
+   fclk_rate = clk_get_rate(fclk);
 
/* TRM for 5912 says the I2C clock must be prescaled to be
 * between 7 - 12 MHz. The XOR input clock is typically
@@ -443,7 +422,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
internal_clk = 9600;
else
internal_clk = 4000;
-   fclk_rate = clk_get_rate(dev->fclk) / 1000;
+   fclk = clk_get(dev->dev, "fck");
+   fclk_rate = clk_get_rate(fclk) / 1000;
 
/* Compute prescaler divisor */
psc = fclk_rate / internal_clk;
@@ -1046,14 +1026,12 @@ omap_i2c_probe(struct platform_device *pdev)
else
dev->reg_shift = 2;
 

[PATCH v3 1/5] OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430

2010-09-21 Thread Rajendra Nayak
From: Paul Walmsley 

Add hwmod structures for I2C controllers on OMAP2420/2430.

Signed-off-by: Paul Walmsley 
Signed-off-by: Rajendra Nayak 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/cm-regbits-24xx.h  |4 +
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  140 +-
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  154 +++-
 3 files changed, 294 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/cm-regbits-24xx.h 
b/arch/arm/mach-omap2/cm-regbits-24xx.h
index da51cc3..5986e2b 100644
--- a/arch/arm/mach-omap2/cm-regbits-24xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-24xx.h
@@ -126,8 +126,12 @@
 #define OMAP24XX_ST_HDQ_MASK   (1 << 23)
 #define OMAP2420_ST_I2C2_SHIFT 20
 #define OMAP2420_ST_I2C2_MASK  (1 << 20)
+#define OMAP2430_ST_I2CHS1_SHIFT   20
+#define OMAP2430_ST_I2CHS1_MASK(1 << 20)
 #define OMAP2420_ST_I2C1_SHIFT 19
 #define OMAP2420_ST_I2C1_MASK  (1 << 19)
+#define OMAP2430_ST_I2CHS2_SHIFT   19
+#define OMAP2430_ST_I2CHS2_MASK(1 << 19)
 #define OMAP24XX_ST_MCBSP2_SHIFT   16
 #define OMAP24XX_ST_MCBSP2_MASK(1 << 16)
 #define OMAP24XX_ST_MCBSP1_SHIFT   15
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 3cc768e..d5e1c9d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,9 +15,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
+#include "cm-regbits-24xx.h"
 #include "prm-regbits-24xx.h"
 
 /*
@@ -71,6 +74,8 @@ static struct omap_hwmod omap2420_l3_main_hwmod = {
 };
 
 static struct omap_hwmod omap2420_l4_wkup_hwmod;
+static struct omap_hwmod omap2420_i2c1_hwmod;
+static struct omap_hwmod omap2420_i2c2_hwmod;
 
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -79,6 +84,45 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* I2C IP block address space length (in bytes) */
+#define OMAP2_I2C_AS_LEN   128
+
+/* L4 CORE -> I2C1 interface */
+static struct omap_hwmod_addr_space omap2420_i2c1_addr_space[] = {
+   {
+   .pa_start   = 0x4807,
+   .pa_end = 0x4807 + OMAP2_I2C_AS_LEN - 1,
+   .flags  = ADDR_TYPE_RT,
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c1 = {
+   .master = &omap2420_l4_core_hwmod,
+   .slave  = &omap2420_i2c1_hwmod,
+   .clk= "i2c1_ick",
+   .addr   = omap2420_i2c1_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_i2c1_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE -> I2C2 interface */
+static struct omap_hwmod_addr_space omap2420_i2c2_addr_space[] = {
+   {
+   .pa_start   = 0x48072000,
+   .pa_end = 0x48072000 + OMAP2_I2C_AS_LEN - 1,
+   .flags  = ADDR_TYPE_RT,
+   },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__i2c2 = {
+   .master = &omap2420_l4_core_hwmod,
+   .slave  = &omap2420_i2c2_hwmod,
+   .clk= "i2c2_ick",
+   .addr   = omap2420_i2c2_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap2420_i2c2_addr_space),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
&omap2420_l3_main__l4_core,
@@ -87,6 +131,8 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = 
{
 /* Master interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
&omap2420_l4_core__l4_wkup,
+   &omap2420_l4_core__i2c1,
+   &omap2420_l4_core__i2c2
 };
 
 /* L4 CORE */
@@ -165,12 +211,104 @@ static struct omap_hwmod omap2420_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420)
 };
 
+/* I2C common */
+static struct omap_hwmod_class_sysconfig i2c_sysc = {
+   .rev_offs   = 0x00,
+   .sysc_offs  = 0x20,
+   .syss_offs  = 0x10,
+   .sysc_flags = SYSC_HAS_SOFTRESET,
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class i2c_class = {
+   .name   = "i2c",
+   .sysc   = &i2c_sysc,
+};
+
+static struct omap_i2c_dev_attr i2c_dev_attr;
+
+/* I2C1 */
+
+static struct omap_hwmod_irq_info i2c1_mpu_irqs[] = {
+   { .irq = INT_24XX_I2C1_IRQ, },
+};
+
+static struct omap_hwmod_dma_info i2c1_sdma_reqs[] = {
+   { .name = "tx", .dma_req = OMAP24XX_

[PATCH v3 3/5] OMAP4: hwmod: add I2C hwmods for OMAP4430

2010-09-21 Thread Rajendra Nayak
Add hwmod structures for I2C controllers on OMAP4430.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Benoit Cousson 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  237 
 1 files changed, 237 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 e20b0ee..2cb63fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -383,6 +383,238 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
 };
 
 /*
+ * 'i2c' class
+ * multimaster high-speed i2c controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_i2c_sysc = {
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0090,
+   .sysc_flags = (SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_i2c_hwmod_class = {
+   .name = "i2c",
+   .sysc = &omap44xx_i2c_sysc,
+};
+
+/* i2c1 */
+static struct omap_hwmod omap44xx_i2c1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_i2c1_irqs[] = {
+   { .irq = 56 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_i2c1_sdma_reqs[] = {
+   { .name = "tx", .dma_req = 26 + OMAP44XX_DMA_REQ_START },
+   { .name = "rx", .dma_req = 27 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_i2c1_addrs[] = {
+   {
+   .pa_start   = 0x4807,
+   .pa_end = 0x480700ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_per -> i2c1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__i2c1 = {
+   .master = &omap44xx_l4_per_hwmod,
+   .slave  = &omap44xx_i2c1_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap44xx_i2c1_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_i2c1_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* i2c1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_i2c1_slaves[] = {
+   &omap44xx_l4_per__i2c1,
+};
+
+static struct omap_hwmod omap44xx_i2c1_hwmod = {
+   .name   = "i2c1",
+   .class  = &omap44xx_i2c_hwmod_class,
+   .flags  = HWMOD_INIT_NO_RESET,
+   .mpu_irqs   = omap44xx_i2c1_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_i2c1_irqs),
+   .sdma_reqs  = omap44xx_i2c1_sdma_reqs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap44xx_i2c1_sdma_reqs),
+   .main_clk   = "i2c1_fck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_L4PER_I2C1_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_i2c1_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_i2c1_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* i2c2 */
+static struct omap_hwmod omap44xx_i2c2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_i2c2_irqs[] = {
+   { .irq = 57 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_i2c2_sdma_reqs[] = {
+   { .name = "tx", .dma_req = 28 + OMAP44XX_DMA_REQ_START },
+   { .name = "rx", .dma_req = 29 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_i2c2_addrs[] = {
+   {
+   .pa_start   = 0x48072000,
+   .pa_end = 0x480720ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_per -> i2c2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__i2c2 = {
+   .master = &omap44xx_l4_per_hwmod,
+   .slave  = &omap44xx_i2c2_hwmod,
+   .clk= "l4_div_ck",
+   .addr   = omap44xx_i2c2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_i2c2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* i2c2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_i2c2_slaves[] = {
+   &omap44xx_l4_per__i2c2,
+};
+
+static struct omap_hwmod omap44xx_i2c2_hwmod = {
+   .name   = "i2c2",
+   .class  = &omap44xx_i2c_hwmod_class,
+   .flags  = HWMOD_INIT_NO_RESET,
+   .mpu_irqs   = omap44xx_i2c2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_i2c2_irqs),
+   .sdma_reqs  = omap44xx_i2c2_sdma_reqs,
+   .sdma_reqs_cnt  = ARRAY_SIZE(omap44xx_i2c2_sdma_reqs),
+   .main_clk   = "i2c2_fck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_L4PER_I2C2_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_i2c2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_i2c2_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* i2c3 */
+static struct omap_hwmod omap44xx_i2

[PATCH v3 4/5] OMAP: I2C: split device registration and convert OMAP2+ to omap_device

2010-09-21 Thread Rajendra Nayak
From: Paul Walmsley 

Split the OMAP1 and OMAP2+ platform_device build and register code.
Convert the OMAP2+ variant to use omap_device.

This patch was developed in collaboration with Rajendra Nayak
.

Signed-off-by: Paul Walmsley 
Signed-off-by: Rajendra Nayak 
Cc: Kevin Hilman 
---
 arch/arm/plat-omap/i2c.c |  124 ++
 include/linux/i2c-omap.h |5 ++
 2 files changed, 54 insertions(+), 75 deletions(-)

diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5ce4f0..a5bff9c 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -27,18 +27,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #define OMAP_I2C_SIZE  0x3f
 #define OMAP1_I2C_BASE 0xfffb3800
-#define OMAP2_I2C_BASE10x4807
-#define OMAP2_I2C_BASE20x48072000
-#define OMAP2_I2C_BASE30x4806
-#define OMAP4_I2C_BASE40x4835
 
 static const char name[] = "i2c_omap";
 
@@ -55,15 +55,6 @@ static const char name[] = "i2c_omap";
 
 static struct resource i2c_resources[][2] = {
{ I2C_RESOURCE_BUILDER(0, 0) },
-#ifdefined(CONFIG_ARCH_OMAP2PLUS)
-   { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE2, 0) },
-#endif
-#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-   { I2C_RESOURCE_BUILDER(OMAP2_I2C_BASE3, 0) },
-#endif
-#ifdefined(CONFIG_ARCH_OMAP4)
-   { I2C_RESOURCE_BUILDER(OMAP4_I2C_BASE4, 0) },
-#endif
 };
 
 #define I2C_DEV_BUILDER(bus_id, res, data) \
@@ -77,18 +68,11 @@ static struct resource i2c_resources[][2] = {
},  \
}
 
-static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
+#define MAX_OMAP_I2C_HWMOD_NAME_LEN16
+#define OMAP_I2C_MAX_CONTROLLERS 4
+static struct omap_i2c_bus_platform_data i2c_pdata[OMAP_I2C_MAX_CONTROLLERS];
 static struct platform_device omap_i2c_devices[] = {
I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
-#ifdefined(CONFIG_ARCH_OMAP2PLUS)
-   I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
-#endif
-#ifdefined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-   I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
-#endif
-#ifdefined(CONFIG_ARCH_OMAP4)
-   I2C_DEV_BUILDER(4, i2c_resources[3], &i2c_pdata[3]),
-#endif
 };
 
 #define OMAP_I2C_CMDLINE_SETUP (BIT(31))
@@ -109,35 +93,20 @@ static int __init omap_i2c_nr_ports(void)
return ports;
 }
 
-/* Shared between omap2 and 3 */
-static resource_size_t omap2_i2c_irq[3] __initdata = {
-   INT_24XX_I2C1_IRQ,
-   INT_24XX_I2C2_IRQ,
-   INT_34XX_I2C3_IRQ,
-};
-
-static resource_size_t omap4_i2c_irq[4] __initdata = {
-   OMAP44XX_IRQ_I2C1,
-   OMAP44XX_IRQ_I2C2,
-   OMAP44XX_IRQ_I2C3,
-   OMAP44XX_IRQ_I2C4,
-};
-
-static inline int omap1_i2c_add_bus(struct platform_device *pdev, int bus_id)
+static inline int omap1_i2c_add_bus(int bus_id)
 {
-   struct omap_i2c_bus_platform_data *pd;
-   struct resource *res;
-
-   pd = pdev->dev.platform_data;
-   res = pdev->resource;
-   res[0].start = OMAP1_I2C_BASE;
-   res[0].end = res[0].start + OMAP_I2C_SIZE;
-   res[1].start = INT_I2C;
+   struct platform_device *pdev;
+   struct omap_i2c_bus_platform_data *pdata;
+
omap1_i2c_mux_pins(bus_id);
 
+   pdev = &omap_i2c_devices[bus_id - 1];
+   pdata = &i2c_pdata[bus_id - 1];
+
return platform_device_register(pdev);
 }
 
+
 /*
  * XXX This function is a temporary compatibility wrapper - only
  * needed until the I2C driver can be converted to call
@@ -148,52 +117,57 @@ static void omap_pm_set_max_mpu_wakeup_lat_compat(struct 
device *dev, long t)
omap_pm_set_max_mpu_wakeup_lat(dev, t);
 }
 
-static inline int omap2_i2c_add_bus(struct platform_device *pdev, int bus_id)
-{
-   struct resource *res;
-   resource_size_t *irq;
+static struct omap_device_pm_latency omap_i2c_latency[] = {
+   [0] = {
+   .deactivate_func= omap_device_idle_hwmods,
+   .activate_func  = omap_device_enable_hwmods,
+   .flags  = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
 
-   res = pdev->resource;
+static inline int omap2_i2c_add_bus(int bus_id)
+{
+   int l;
+   struct omap_hwmod *oh;
+   struct omap_device *od;
+   char oh_name[MAX_OMAP_I2C_HWMOD_NAME_LEN];
+   struct omap_i2c_bus_platform_data *pdata;
 
-   if (!cpu_is_omap44xx())
-   irq = omap2_i2c_irq;
-   else
-   irq = omap4_i2c_irq;
+   omap2_i2c_mux_pins(bus_id);
 
-   if (bus_id == 1) {
-   res[0].start = OMAP2_I2C_BASE1;
-   res[0].end = res[0].start + OMAP_I2C_SIZE;
+   l = snprintf(oh_name, MAX_OMAP_I2C_HWMOD_NAME_LEN, "i2c%d", bus_id);
+   WARN(l >= MAX_OMAP_I2

[PATCH v3 2/5] OMAP3: hwmod: add I2C hwmods for OMAP3430

2010-09-21 Thread Rajendra Nayak
Add hwmod structures for I2C controllers on OMAP3430.

This patch was developed in collaboration with Paul Walmsley .

Signed-off-by: Rajendra Nayak 
Signed-off-by: Paul Walmsley 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  232 
 arch/arm/mach-omap2/prm-regbits-34xx.h |3 +
 arch/arm/plat-omap/include/plat/i2c.h  |   16 ++
 arch/arm/plat-omap/include/plat/l4_3xxx.h  |   24 +++
 4 files changed, 275 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..a3ccab7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -17,6 +17,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "omap_hwmod_common_data.h"
 
@@ -36,6 +39,9 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
 static struct omap_hwmod omap3xxx_l3_main_hwmod;
 static struct omap_hwmod omap3xxx_l4_core_hwmod;
 static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_i2c1_hwmod;
+static struct omap_hwmod omap3xxx_i2c2_hwmod;
+static struct omap_hwmod omap3xxx_i2c3_hwmod;
 
 /* L3 -> L4_CORE interface */
 static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -90,6 +96,85 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+
+/* I2C IP block address space length (in bytes) */
+#define OMAP2_I2C_AS_LEN   128
+
+/* L4 CORE -> I2C1 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c1_addr_space[] = {
+   {
+   .pa_start   = 0x4807,
+   .pa_end = 0x4807 + OMAP2_I2C_AS_LEN - 1,
+   .flags  = ADDR_TYPE_RT,
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c1 = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &omap3xxx_i2c1_hwmod,
+   .clk= "i2c1_ick",
+   .addr   = omap3xxx_i2c1_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_i2c1_addr_space),
+   .fw = {
+   .omap2 = {
+   .l4_fw_region  = OMAP3_L4_CORE_FW_I2C1_REGION,
+   .l4_prot_group = 7,
+   .flags  = OMAP_FIREWALL_L4,
+   }
+   },
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE -> I2C2 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c2_addr_space[] = {
+   {
+   .pa_start   = 0x48072000,
+   .pa_end = 0x48072000 + OMAP2_I2C_AS_LEN - 1,
+   .flags  = ADDR_TYPE_RT,
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c2 = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &omap3xxx_i2c2_hwmod,
+   .clk= "i2c2_ick",
+   .addr   = omap3xxx_i2c2_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_i2c2_addr_space),
+   .fw = {
+   .omap2 = {
+   .l4_fw_region  = OMAP3_L4_CORE_FW_I2C2_REGION,
+   .l4_prot_group = 7,
+   .flags = OMAP_FIREWALL_L4,
+   }
+   },
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE -> I2C3 interface */
+static struct omap_hwmod_addr_space omap3xxx_i2c3_addr_space[] = {
+   {
+   .pa_start   = 0x4806,
+   .pa_end = 0x4806 + OMAP2_I2C_AS_LEN - 1,
+   .flags  = ADDR_TYPE_RT,
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
+   .master = &omap3xxx_l4_core_hwmod,
+   .slave  = &omap3xxx_i2c3_hwmod,
+   .clk= "i2c3_ick",
+   .addr   = omap3xxx_i2c3_addr_space,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_i2c3_addr_space),
+   .fw = {
+   .omap2 = {
+   .l4_fw_region  = OMAP3_L4_CORE_FW_I2C3_REGION,
+   .l4_prot_group = 7,
+   .flags = OMAP_FIREWALL_L4,
+   }
+   },
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
&omap3xxx_l3_main__l4_core,
@@ -98,6 +183,9 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = 
{
 /* Master interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
&omap3xxx_l4_core__l4_wkup,
+   &omap3_l4_core__i2c1,
+   &omap3_l4_core__i2c2,
+   &omap3_l4_core__i2c3,
 };
 
 /* L4 CORE */
@@ -197,6 +285,147 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
 };
 
+
+/* I2C common */
+static struct omap_hwmod_class_sysconfig 

[PATCH v3 0/5] Convert I2C driver to use omap_device/runtime PM

2010-09-21 Thread Rajendra Nayak
This series makes I2C device registration use hwmod and omap_device api's
and converts the I2C driver to use runtime PM api's.

Patches apply on the pm-core branch from Kevin's tree.

v3 has minor review comment fixes over v2
The series is boot tested on a 2430sdp platform along with being tested
on 3430sdp and 4430sdp.

4430sdp tests are done using the below series 
http://www.spinics.net/lists/linux-omap/msg36023.html

Paul Walmsley (2):
  OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
  OMAP: I2C: split device registration and convert OMAP2+ to
omap_device

Rajendra Nayak (3):
  OMAP3: hwmod: add I2C hwmods for OMAP3430
  OMAP4: hwmod: add I2C hwmods for OMAP4430
  OMAP: I2C: Convert i2c driver to use PM runtime api's

 arch/arm/mach-omap2/cm-regbits-24xx.h  |4 +
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  140 -
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  154 ++-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  232 +++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  237 
 arch/arm/mach-omap2/prm-regbits-34xx.h |3 +
 arch/arm/plat-omap/i2c.c   |  124 ++-
 arch/arm/plat-omap/include/plat/i2c.h  |   16 ++
 arch/arm/plat-omap/include/plat/l4_3xxx.h  |   24 +++
 drivers/i2c/busses/i2c-omap.c  |   67 +++--
 include/linux/i2c-omap.h   |5 +
 11 files changed, 881 insertions(+), 125 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h

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


RE: [PATCH v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way

2010-09-21 Thread Varadarajan, Charulatha


> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Tuesday, September 21, 2010 5:37 AM
> To: Varadarajan, Charulatha
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson,
> Benoit; Nayak, Rajendra; Basak, Partha
> Subject: Re: [PATCH v6 00/13] OMAP: GPIO: Implement GPIO in hwmod way
> 
> "Varadarajan, Charulatha"  writes:
> 
> > This patch series makes OMAP2PLUS specific GPIO implemented in hwmod
> > FW way. This is done by implementing GPIO module in platform device
> model.
> >
> > This patch series is generated on "origin/pm-wip/pm-core" which
> > has Kevin's pm-next series, the runtime PM core patch series,
> > and a collection of hwmod fixes that Paul/Benoit have lined up
> > for 2.6.37.
> >
> > Tested on OMAP2430, OMAP44430, OMAP3430 SDP and zoom3 boards.
> > Also verified that this patch series does not break the OMAP1 build.
> >
> > This patch series is created on top of the following patches:
> > 1. OMAP: HWMOD: Handle opt clocks using clk_add_alias
> > [https://patchwork.kernel.org/patch/124531/]
> > 2. OMAP2+: GPIO: move late PM out of interrupts-disabled idle path
> > [https://patchwork.kernel.org/patch/176172/]
> > 3. OMAP: CPUIDLE: Enable IRQs during device activity check and idle
> management
> > by Kevin
> >
> > This series is tested on OMAP4430 ES2 using the below series
> > http://www.spinics.net/lists/linux-omap/msg36023.html
> 
> Hi Charu,
> 
> I haven't been fully through the series, but here's some quick feedback
> based on what I tried today.
> 
> Basically, I got stuck because the first board I tried it on was the
> 35xx-based OMAP3EVM platform, which uses a GPIO-based interrupt for the
> network.  My setup uses DHCP + nfsroot, so the GPIO IRQ must be working
> during boot.
> 
> The first thing I noticed, is that GPIO interrupts are not firing during
> boot, so neither the DHCP or the nfsroot works during boot.  I haven't
> been able to fully debug this, but the 3430SDP should have the same
> issue for its smc91x if you set it up for DHCP + nfsroot.  This is
> working fine on my pm-wip/idle-reorg branch which has the prerequisites
> you mentioned, but didn't work when I applied the clk_alias patch plus
> this series.

I tested this GPIO series in pm-wip/idle-reorg branch with clock
add alias patch and I did not see any issues. I tested with DHCP + nfsroot
on SDP3430. Please provide me some more info on this.

> 
> The other change when debugging I made was to make the
> 'workaround_enable' hack bank specific.  Now that the bank idles can be
> called independetly, this would get cleared as soon as one of the banks
> clears it.  It should be a per-bank flag[1]

Agreed. Even I was wondering why this was not bank specific in the
original code. Will do this in the next series after we get the above
issue fixed.

> 
> Another thing I noticed was that ENWAKEUP is no longer set in the
> SYSCONFIG register for each bank, as it was before.  To avoid this kind
> of functional change, I did[2]
> 
> I'll get back to digging a bit tomorrow, but hopefully you can debug
> this further before I get to it.
> 
> Kevin
> 
> 
> [1]
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 2f5c1eb..3b60418 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -170,6 +170,7 @@ struct gpio_bank {
>   struct omap_gpio_regs gpio_context;
>   struct powerdomain *pwrdm;
>   bool dbck_flag;
> + int workaround_enabled;
>  };
> 
>  static void omap_gpio_save_context(struct device *dev);
> @@ -1830,8 +1831,6 @@ static int omap_gpio_resume(struct device *dev)
>   return 0;
>  }
> 
> -static int workaround_enabled;
> -
>  static int gpio_bank_runtime_suspend(struct device *dev)
>  {
>   struct platform_device *pdev = to_platform_device(dev);
> @@ -1887,7 +1886,7 @@ static int gpio_bank_runtime_suspend(struct device
> *dev)
>   __raw_writel(l2, bank->base + OMAP4_GPIO_RISINGDETECT);
>   }
> 
> - workaround_enabled = 1;
> + bank->workaround_enabled = 1;
> 
>   return 0;
>  }
> @@ -1900,7 +1899,7 @@ static int gpio_bank_runtime_resume(struct device
> *dev)
>   if (bank->dbck_enable_mask)
>   clk_enable(bank->dbck);
> 
> - if ((!workaround_enabled) || (!(bank->enabled_non_wakeup_gpios)))
> + if ((!bank->workaround_enabled) || (!(bank-
> >enabled_non_wakeup_gpios)))
>   return 0;
> 
>   if (bank->method == METHOD_GPIO_24XX) {
> @@ -2110,11 +2109,11 @@ void omap2_gpio_prepare_for_idle(void)
>  {
>   int i;
> 
> - workaround_enabled = 0;
> -
>   for (i = 0; i < gpio_bank_count; i++) {
>   struct gpio_bank *bank = &gpio_bank[i];
> 
> + bank->workaround_enabled = 0;
> +
>   /* If the gpio bank is not used, do nothing */
>   if ((!bank->pwrdm) || !(bank->mod_usage))
>   continue;
> 
> 
> [2]
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/m

  1   2   >