[PATCH v2] MFD: twl4030-codec: Update e-mail address

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi 
---

Hello,

Instead of keeping the old Nokia mail address, just change it to my new
email address in the author line.

 drivers/mfd/twl4030-codec.c   |4 ++--
 include/linux/mfd/twl4030-codec.h |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/twl4030-codec.c b/drivers/mfd/twl4030-codec.c
index c02fded..534cc2e 100644
--- a/drivers/mfd/twl4030-codec.c
+++ b/drivers/mfd/twl4030-codec.c
@@ -1,7 +1,7 @@
 /*
  * MFD driver for twl4030 codec submodule
  *
- * Author: Peter Ujfalusi 
+ * Author: Peter Ujfalusi 
  *
  * Copyright:   (C) 2009 Nokia Corporation
  *
@@ -270,6 +270,6 @@ static void __devexit twl4030_codec_exit(void)
 }
 module_exit(twl4030_codec_exit);
 
-MODULE_AUTHOR("Peter Ujfalusi ");
+MODULE_AUTHOR("Peter Ujfalusi ");
 MODULE_LICENSE("GPL");
 
diff --git a/include/linux/mfd/twl4030-codec.h 
b/include/linux/mfd/twl4030-codec.h
index 2ec317c..5cc16bb 100644
--- a/include/linux/mfd/twl4030-codec.h
+++ b/include/linux/mfd/twl4030-codec.h
@@ -1,7 +1,7 @@
 /*
  * MFD driver for twl4030 codec submodule
  *
- * Author: Peter Ujfalusi 
+ * Author: Peter Ujfalusi 
  *
  * Copyright:   (C) 2009 Nokia Corporation
  *
-- 
1.7.5.rc3

--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP2+: SR Layer Cleanup.

[Gulati, Shweta]

Hi,

On Tue, May 10, 2011 at 5:52 AM, Menon, Nishanth  wrote:
> might be a bit late, but seeing that Kevin has'nt picked this up yet,
> a couple of cosmetic comments
> I think it might be great if it could be folded into one of kevin's patches.
> else,
> $subject - OMAP3+ and could you drop the .?
Will correct the Subject line
> On Fri, Apr 8, 2011 at 01:14, Shweta Gulati  wrote:
>> As a part of Voltage Layer Cleanup Patches,
>> submitted by Kevin Hilman, Voltage domain
>> Information is removed from hwmod,
>> So the patch removes 'vdd_name' info from omap_hwmod
>> and adds that info into dev_attr as SR code uses vdd_name
>> to get voltagedomain sructure info.
> word wrap cleanup a bit, also please indicate the issue you see if the
> patch is not applied.
Would Rephrase the commit log.
> Regards,
> Nishanth Menon
>
>
>>
>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>
>> Signed-off-by: Shweta Gulati 
>
>
>
>> ---
>>  V2:
>>  Rebased on latest 'pm-wip/voltdm_a' branch.
>>
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |   17 +
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |   19 ---
>>  arch/arm/mach-omap2/smartreflex.h            |   10 ++
>>  arch/arm/mach-omap2/sr_device.c              |   11 +++
>>  arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 -
>>  5 files changed, 46 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
>> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> index 3cd91ac..6a704bd 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> @@ -29,6 +29,7 @@
>>
>>  #include "omap_hwmod_common_data.h"
>>
>> +#include "smartreflex.h"
>>  #include "prm-regbits-34xx.h"
>>  #include "cm-regbits-34xx.h"
>>  #include "wd_timer.h"
>> @@ -2904,6 +2905,10 @@ static struct omap_hwmod_class 
>> omap36xx_smartreflex_hwmod_class = {
>>  };
>>
>>  /* SR1 */
>> +static struct omap_sr_dev_attr sr1_dev_attr = {
>> +       .voltdm_name   = "mpu_iva",
>> +};
>> +
>>  static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
>>        &omap3_l4_core__sr1,
>>  };
>> @@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
>>        .name           = "sr1_hwmod",
>>        .class          = &omap34xx_smartreflex_hwmod_class,
>>        .main_clk       = "sr1_fck",
>> -       .vdd_name       = "mpu_iva",
>>        .prcm           = {
>>                .omap2 = {
>>                        .prcm_reg_id = 1,
>> @@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
>>        },
>>        .slaves         = omap3_sr1_slaves,
>>        .slaves_cnt     = ARRAY_SIZE(omap3_sr1_slaves),
>> +       .dev_attr       = &sr1_dev_attr,
>>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
>>                                        CHIP_IS_OMAP3430ES3_0 |
>>                                        CHIP_IS_OMAP3430ES3_1),
>> @@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
>>        .name           = "sr1_hwmod",
>>        .class          = &omap36xx_smartreflex_hwmod_class,
>>        .main_clk       = "sr1_fck",
>> -       .vdd_name       = "mpu_iva",
>>        .prcm           = {
>>                .omap2 = {
>>                        .prcm_reg_id = 1,
>> @@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
>>        },
>>        .slaves         = omap3_sr1_slaves,
>>        .slaves_cnt     = ARRAY_SIZE(omap3_sr1_slaves),
>> +       .dev_attr       = &sr1_dev_attr,
>>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
>>  };
>>
>>  /* SR2 */
>> +static struct omap_sr_dev_attr sr2_dev_attr = {
>> +       .voltdm_name    = "core",
>> +};
>> +
>>  static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
>>        &omap3_l4_core__sr2,
>>  };
>> @@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
>>        .name           = "sr2_hwmod",
>>        .class          = &omap34xx_smartreflex_hwmod_class,
>>        .main_clk       = "sr2_fck",
>> -       .vdd_name       = "core",
>>        .prcm           = {
>>                .omap2 = {
>>                        .prcm_reg_id = 1,
>> @@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
>>        },
>>        .slaves         = omap3_sr2_slaves,
>>        .slaves_cnt     = ARRAY_SIZE(omap3_sr2_slaves),
>> +       .dev_attr       = &sr2_dev_attr,
>>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
>>                                        CHIP_IS_OMAP3430ES3_0 |
>>                                        CHIP_IS_OMAP3430ES3_1),
>> @@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
>>        .name           = "sr2_hwmod",
>>        .class          = &omap36xx_smartreflex_hwmod_class,
>>        .main_clk       = "sr2_fck",
>> -       .vdd_name       = "core",
>>        .prcm           = {
>>                .omap2 = {
>>                        .prcm_reg_id = 1,
>> @@ -2992,6 +3000,7 @@ static stru

Re: [PATCH V2] OMAP2+: SR Layer Cleanup.

[Menon, Nishanth]

might be a bit late, but seeing that Kevin has'nt picked this up yet,
a couple of cosmetic comments
I think it might be great if it could be folded into one of kevin's patches.
else,
$subject - OMAP3+ and could you drop the .?

On Fri, Apr 8, 2011 at 01:14, Shweta Gulati  wrote:
> As a part of Voltage Layer Cleanup Patches,
> submitted by Kevin Hilman, Voltage domain
> Information is removed from hwmod,
> So the patch removes 'vdd_name' info from omap_hwmod
> and adds that info into dev_attr as SR code uses vdd_name
> to get voltagedomain sructure info.
word wrap cleanup a bit, also please indicate the issue you see if the
patch is not applied.

Regards,
Nishanth Menon


>
> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>
> Signed-off-by: Shweta Gulati 



> ---
>  V2:
>  Rebased on latest 'pm-wip/voltdm_a' branch.
>
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |   17 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |   19 ---
>  arch/arm/mach-omap2/smartreflex.h            |   10 ++
>  arch/arm/mach-omap2/sr_device.c              |   11 +++
>  arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 -
>  5 files changed, 46 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 3cd91ac..6a704bd 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -29,6 +29,7 @@
>
>  #include "omap_hwmod_common_data.h"
>
> +#include "smartreflex.h"
>  #include "prm-regbits-34xx.h"
>  #include "cm-regbits-34xx.h"
>  #include "wd_timer.h"
> @@ -2904,6 +2905,10 @@ static struct omap_hwmod_class 
> omap36xx_smartreflex_hwmod_class = {
>  };
>
>  /* SR1 */
> +static struct omap_sr_dev_attr sr1_dev_attr = {
> +       .voltdm_name   = "mpu_iva",
> +};
> +
>  static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
>        &omap3_l4_core__sr1,
>  };
> @@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
>        .name           = "sr1_hwmod",
>        .class          = &omap34xx_smartreflex_hwmod_class,
>        .main_clk       = "sr1_fck",
> -       .vdd_name       = "mpu_iva",
>        .prcm           = {
>                .omap2 = {
>                        .prcm_reg_id = 1,
> @@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
>        },
>        .slaves         = omap3_sr1_slaves,
>        .slaves_cnt     = ARRAY_SIZE(omap3_sr1_slaves),
> +       .dev_attr       = &sr1_dev_attr,
>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
>                                        CHIP_IS_OMAP3430ES3_0 |
>                                        CHIP_IS_OMAP3430ES3_1),
> @@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
>        .name           = "sr1_hwmod",
>        .class          = &omap36xx_smartreflex_hwmod_class,
>        .main_clk       = "sr1_fck",
> -       .vdd_name       = "mpu_iva",
>        .prcm           = {
>                .omap2 = {
>                        .prcm_reg_id = 1,
> @@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
>        },
>        .slaves         = omap3_sr1_slaves,
>        .slaves_cnt     = ARRAY_SIZE(omap3_sr1_slaves),
> +       .dev_attr       = &sr1_dev_attr,
>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
>  };
>
>  /* SR2 */
> +static struct omap_sr_dev_attr sr2_dev_attr = {
> +       .voltdm_name    = "core",
> +};
> +
>  static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
>        &omap3_l4_core__sr2,
>  };
> @@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
>        .name           = "sr2_hwmod",
>        .class          = &omap34xx_smartreflex_hwmod_class,
>        .main_clk       = "sr2_fck",
> -       .vdd_name       = "core",
>        .prcm           = {
>                .omap2 = {
>                        .prcm_reg_id = 1,
> @@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
>        },
>        .slaves         = omap3_sr2_slaves,
>        .slaves_cnt     = ARRAY_SIZE(omap3_sr2_slaves),
> +       .dev_attr       = &sr2_dev_attr,
>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
>                                        CHIP_IS_OMAP3430ES3_0 |
>                                        CHIP_IS_OMAP3430ES3_1),
> @@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
>        .name           = "sr2_hwmod",
>        .class          = &omap36xx_smartreflex_hwmod_class,
>        .main_clk       = "sr2_fck",
> -       .vdd_name       = "core",
>        .prcm           = {
>                .omap2 = {
>                        .prcm_reg_id = 1,
> @@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
>        },
>        .slaves         = omap3_sr2_slaves,
>        .slaves_cnt     = ARRAY_SIZE(omap3_sr2_slaves),
> +       .dev_attr       = &sr2_dev_attr,
>        .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),

Re: [PATCH 1/2] Initial B&N Nook Color (encore) support.

[Mark Brown]

On Sun, May 08, 2011 at 05:50:06PM -0400, gr...@linuxhacker.ru wrote:

> + /*
> +  * link regulators to MMC adapters ... we "know" the
> +  * regulators will be set up only *after* we return.
> +  */
> + encore_vmmc1_supply.dev = mmc[1].dev;

Just specify dev_name in the supply rather than doing this.
--
To unsubscribe from this list: send the line "unsubscribe 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/9] OMAP: DSS2: Change DSI platform device name from "omapdss_dsi1" to "omapdss_dsi"

[Mark Brown]

On Mon, May 09, 2011 at 06:34:34PM +0300, Tomi Valkeinen wrote:

> The first is that we want to avoid unnecessary board file changes, and
> as almost all boards configure the DSS powers the same way, it'd be nice
> to have a default config for these.

Right, makes sense.

> The second thing is that even if the power source for vdds_dsi may be
> configured differently on different boards, the same vdds_dsi goes to
> multiple DSS HW blocks inside OMAP, each represented by a separate
> omap_device. So it'd be much nicer to configure just the vdds_dsi power
> in the board file, but let the omap display code configure the
> regulators properly for all the DSS HW blocks in that particular OMAP.

For this I'd suggest setting up an arrangement with supplies where you
have one thing on the OMAP is supplied by board configuration and then
it has child supplies within the device but right now that's not so easy
to do.  I was just writing some stuff for that this afternoon but it'll
be next week before I can test it properly.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] OMAP: board file changes for DSS2 porting

[Tomi Valkeinen]

On Mon, 2011-05-09 at 10:36 +0300, Tomi Valkeinen wrote:
> Hi Tony,
> 
> I posted last week a patch set porting most of the old omapfb OMAP2/3 drivers
> to DSS2 (http://marc.info/?l=linux-fbdev&m=130451207802788&w=2). That patch 
> set
> contains changes to both the drivers and the board files, and it seems there 
> is
> already a minor conflict in them.
> 
> So I think it's simpler to divide the set into two parts, this one, which
> contains the board file changes, and another containing the driver changes.
> Merging will probably go easier if you can take this patch set via linux-omap,
> and I'll take the driver changes via dss2 tree.
> 
> Applying this set without the driver changes will obviously disable the
> displays of the affected boards until the drivers are also merged.

Tony, I updated the patches, adding one Ack and cleaning up the 2430sdp
a bit. The patches can be found from

git://gitorious.org/linux-omap-dss2/linux.git board-changes-for-tony

should you decide to pull them.

>  Tomi
> 
> 
> Tomi Valkeinen (6):
>   OMAP: RX51: Remove unused old omapfb stuff
>   OMAP: omap3touchbook: Remove unused lcd stuff
>   OMAP: 2420SDP: Port the display driver to new DSS2
>   OMAP: LDP: Port the display driver to new DSS2
>   OMAP: H4: Port the display driver to new DSS2
>   OMAP: Apollon: Port the display driver to new DSS2
> 
>  arch/arm/mach-omap2/board-2430sdp.c|   84 
> +++-
>  arch/arm/mach-omap2/board-apollon.c|   34 +++
>  arch/arm/mach-omap2/board-h4.c |   41 -
>  arch/arm/mach-omap2/board-ldp.c|   73 +---
>  arch/arm/mach-omap2/board-omap3touchbook.c |   18 --
>  arch/arm/mach-omap2/board-rx51.c   |   25 
>  6 files changed, 180 insertions(+), 95 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 3/6] OMAP: 2420SDP: Port the display driver to new DSS2

[Tomi Valkeinen]

On Mon, 2011-05-09 at 11:21 +0300, Igor Grinberg wrote:
> Hi Tomi,
> 
> On 05/09/11 10:36, Tomi Valkeinen wrote:
> 
> > Port the old omapfb panel driver to DSS2. This patch changes the board
> > file only, the driver is ported in separate patch.
> >
> > Signed-off-by: Tomi Valkeinen 
> > Cc: Hunyue Yau 



> > +static void __init sdp2430_display_init(void)
> > +{
> > +   int r;
> > +
> > +   r = gpio_request_one(SDP2430_LCD_PANEL_ENABLE_GPIO,
> > +   GPIOF_OUT_INIT_LOW, "LCD reset");
> > +   if (r) {
> > +   printk(KERN_ERR "failed to get LCD reset GPIO\n");
> > +   goto err0;
> > +   }
> > +
> > +   r = gpio_request_one(SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
> > +   GPIOF_OUT_INIT_LOW, "LCD Backlight");
> > +   if (r) {
> > +   printk(KERN_ERR "failed to get LCD backlight GPIO\n");
> 
> can both printks be pr_err?
> 
> > +   goto err1;
> > +   }
> > +
> > +   omap_display_init(&sdp2430_dss_data);
> > +
> > +   return;
> > +err1:
> > +   gpio_free(SDP2430_LCD_PANEL_ENABLE_GPIO);
> > +err0:
> > +   return;
> > +}
> 
> I think using gpio_request_array() will be much cleaner here...

Right, thanks. It turned out much cleaner:

+static void __init sdp2430_display_init(void)
+{
+   int r;
+
+   static struct gpio gpios[] __initdata = {
+   { SDP2430_LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
+   "LCD reset" },
+   { SDP2430_LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW,
+   "LCD Backlight" },
+   };
+
+   r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+   if (r) {
+   pr_err("Cannot request LCD GPIOs, error %d\n", r);
+   return;
+   }
+
+   omap_display_init(&sdp2430_dss_data);
+}

 Tomi



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

Re: [PATCH] OMAP2: avoid descending into disabled framebuffer dirs

[Tomi Valkeinen]

On Mon, 2011-05-09 at 10:40 -0400, Mike Frysinger wrote:
> Rather than always add the omap2 dirs to the build list (and thus
> force everyone to generate a useless built-in.o), bind the dirs to
> their relevant kconfig symbol.
> 
> Signed-off-by: Mike Frysinger 
> ---
>  drivers/video/omap2/Makefile |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
> index d853d05..5ddef12 100644
> --- a/drivers/video/omap2/Makefile
> +++ b/drivers/video/omap2/Makefile
> @@ -1,6 +1,6 @@
>  obj-$(CONFIG_OMAP2_VRAM) += vram.o
>  obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
>  
> -obj-y += dss/
> -obj-y += omapfb/
> +obj-$(CONFIG_OMAP2_DSS) += dss/
> +obj-$(CONFIG_FB_OMAP2) += omapfb/
>  obj-y += displays/

Looks fine to me, applying to DSS tree. Thanks!

 Tomi


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

Re: [PATCH 1/9] OMAP: DSS2: Change DSI platform device name from "omapdss_dsi1" to "omapdss_dsi"

[Tomi Valkeinen]

On Thu, 2011-05-05 at 14:02 +0100, Mark Brown wrote:
> On Thu, May 05, 2011 at 02:36:48PM +0300, Tomi Valkeinen wrote:
> 
> > So currently we have REGULATOR_SUPPLY defines for each board in all the
> > board files which support display. It would be much better to have an
> > overrideable standard setup for the DSS powers, but this would require
> > dynamically setting up the regulator_consumer_supplies. And I can't see
> > how this could be done, except dynamically creating the
> > regulator_consumer_supply array before initializing the TWL chip, but as
> > DSS is not the only user of those powers the end result could be quite a
> > mess with changes needed in every board file.
> 
> I'm not sure I see a problem that needs solving here?  This wiring is
> all totally system specific.  Once we have viable device tree for
> relevant platforms I'd expect to see these things mapped in the device
> tree for the system with a standard regulator API device tree mapping.

I think there are two things here:

The first is that we want to avoid unnecessary board file changes, and
as almost all boards configure the DSS powers the same way, it'd be nice
to have a default config for these.

The second thing is that even if the power source for vdds_dsi may be
configured differently on different boards, the same vdds_dsi goes to
multiple DSS HW blocks inside OMAP, each represented by a separate
omap_device. So it'd be much nicer to configure just the vdds_dsi power
in the board file, but let the omap display code configure the
regulators properly for all the DSS HW blocks in that particular OMAP.

I'm not familiar with the capabilities of the device tree, so it may
solve these neatly (at least from kernel's perspective). I guess Tony
just wants to try to minimize arch/arm changes wherever possible due to
the recent arch/arm dispute.

 Tomi


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

Re: [PATCH v2] omap: fix build when MTD_NAND_OMAP2 and TOUCHSCREEN_ADS7846 are disabled

[Tony Lindgren]

* Mike Rapoport  [110506 12:54]:
> Commits 5e6a64b36ce346b7a2d481ef9fa315290eb28e5e (omap: move detection of
> NAND CS to common-board-devices) and 96974a249b0cf3537f49115a59be67e2c54f315c
> (omap: consolidate touch screen initialization among different boards)
> break compilation when CONFIG_MTD_NAND_OMAP2 and
> CONFIG_TOUCHSCREEN_ADS7846 are not selected.
> Removing ifdefs and stubs from common-board-devices.h fixes the problem.
> 
> Signed-off-by: Mike Rapoport 
> CC: Oleg Drokin 
> ---
> Hope this one is better.

Thanks, I'll fold this into your original patch.

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 4/4] USB: TWL6025 allow different regulator name

[Mark Brown]

On Mon, May 09, 2011 at 04:51:26PM +0300, Felipe Balbi wrote:
> On Mon, May 09, 2011 at 03:35:43PM +0200, Mark Brown wrote:

> > -   twl->usb3v3 = regulator_get(twl->dev, "vusb");
> > +   twl->usb3v3 = regulator_get(twl->dev, regulator_name);
> > if (IS_ERR(twl->usb3v3))
> > return -ENODEV;

> then, imagine 5 years from now how that branch will look. How long do
> you think it'll take until someone decides to pass that name via
> platform_data to avoid growing that conditional ?

Probably way more than five years; frankly someone needs to yell at
whoever wrote the documentation and point out to them that VBUS is a
well known name that came from the spec.

In this particular case we actually shouldn't be worry about this at all
as it turns out that the consumer and supply are both internal to the
chip and hard wired together with no external users (the
regulator_init_data is part of the twl core not the board) so we
shouldn't be making this visible outside the drivers in the first place,
the name is totally irrelevant to anything except the twl drivers.  The
name is much more important if someone mapping out the regulators on a
board has to worry about it.

> > > We pass in the data of how regulators are wired at the board level and
> > > drivers would regulator_get(my_dev->dev, "whatever fancy name I want as
> > > it doesn't matter at all");

> > No, not at all.  Consumer drivers should be hard coding the strings they
> > request and the strings used should correspond to the pin names used on
> > the device.

> but that's the thing. Why do they need to depend on that string ?

They have to depend on *something* textual.  Even if you change it into
program code it's still going to have to be written down somewhere.

> > As Liam said this will just make the situation worse.  Users will have
> > to figure out what the names the driver authors assigned to the various
> > device supplies map onto in the physical system via an additional layer
> > of indirection which will at best be written down in comments in the
> > driver.

> My point is that the "name" shouldn't matter. Instead of matching a
> "name" match a "reference". Have something earlier in the boot assing
> regulators to devices, or something like that, so that drivers don't
> need to care about "names".

Unfortunately we write computer programs using text and that does rather
mean that things need names eventually, and that's going to have to
include the driver since whatever else does the mapping is going to need
to figure out what the driver is using to refer to a given regulator.

At some point these magic references are going to have to come from a
human in some form the human has a hope of comprehending.  The names
aren't really for the benefit of the driver, they're there so that a
human reading a schematic can work out which regulator to attach to
which supply and produce a mapping which other people can read and
understand.

> > Here you're apparently talking about something different - you're
> > talking about how we pass in the regulator init data for the regulators
> > supplied by the chip.  The patch being discussed changes the consumer
> > side for USB, not the regulator driver side.  The naming on the driver

> see above, how long do you think it'll take for someone to try and pass
> that name via pdata ? On the next name change, this is already likely to
> happen to prevent that conditional from growing.

People try to pass things as platform data all the time, usually as the
first thing they think of because they are having a hard time
distinguishing between the label the rail was given on the board and the
label the chip uses for the supply.  This isn't a problem, we just tell
them not to do that so that people can use the driver on other boards.

> > side is a particular problem for TWL devices since unlike most PMICs the
> > regulators aren't simply numbered but are instead assigned individual
> > names so you can't just use a big array indexed by number.

> why not ? The name shouldn't matter. In anycase, if you look into
> /sys/class/regulator/ all directories are regulator.:

>   dev_set_name(&rdev->dev, "regulator.%d",
>atomic_inc_return(®ulator_no) - 1);

That's not terribly useful for describing the relationships between
devices as the names come on a first come first served basis and are
therefore not at all stable.  We could try assiging base numbers to the
various regulator drivers but then you end up with a massive legibility
problem as nobody numbers the supplies on devices.

> > > What I was expecting to see, was a mechanism where we define how those
> shouldn't depend on strings at all in order to fetch the correct
> regulator. How many:

> if (xxx_features() & XXX_CLASS_IS_)
>   regulator_name = "my_first_name";
> else
>   regulator_name = "my_second_name";

> will have to pop in drivers until we figure that it won't scale ?

Note that the combination of _features a

[PATCH v3 4/4] OMAP: DSS: Add picodlp panel driver

[Mayuresh Janorkar]

picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.

i2c_client is required for sending commands to dpp (DLP Pico Projector).

The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the DPP2600
is stable, then PWRGOOD should be deactivated (Set to a logic high).
The DPP2600 will then perform a power-up initialization routine that will first
configure and lock its PLL followed by loading self configuration data from
external flash. DPP2600 would be activated and the EMU_DONE signal will be
driven high. After this once internal initialization routine,
which will take approximately 510ms, i2c commands can be sent.

To know more please visit: http://www.omappedia.org/wiki/PicoDLP_projector_guide

Signed-off-by: Mayuresh Janorkar 
---
Changes since v2:
Merged panel picodlp patches into a single patch
Introduced DMA_DONE polling between flash transfer
Changed GPIO handling
Reduced sleeps

 drivers/video/omap2/displays/Kconfig |7 +
 drivers/video/omap2/displays/Makefile|1 +
 drivers/video/omap2/displays/panel-picodlp.c |  627 ++
 3 files changed, 635 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-picodlp.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index 609a280..0b05593 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -30,6 +30,13 @@ config PANEL_NEC_NL8048HL11_01B
This NEC NL8048HL11-01B panel is TFT LCD
used in the Zoom2/3/3630 sdp boards.
 
+config PANEL_PICODLP
+   tristate "OMAP PICO DLP Panel"
+   depends on OMAP2_DSS
+   help
+   Projector Panel used in TI's SDP4430 and EVM boards
+   For more info please visit http://www.dlp.com/projector/
+
 config PANEL_TAAL
 tristate "Taal DSI Panel"
 depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index 0f601ab..d90f73c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += 
panel-sharp-ls037v7dw01.o
 obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
 
 obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_PICODLP) +=  panel-picodlp.o
 obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-picodlp.c 
b/drivers/video/omap2/displays/panel-picodlp.c
new file mode 100644
index 000..432f987
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -0,0 +1,627 @@
+/*
+
+ * picodlp panel driver
+ * picodlp_i2c_driver: i2c_client driver
+ *
+ * Copyright (C) 2009-2011 Texas Instruments
+ * Author: Mythri P K 
+ * Mayuresh Janorkar 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "panel-picodlp.h"
+
+#define DRIVER_NAME"picodlp_i2c_driver"
+
+/* This defines the minit of data which is allowed into single write block */
+#define MAX_I2C_WRITE_BLOCK_SIZE   32
+#define PICO_MAJOR 1 /* 2 bits */
+#define PICO_MINOR 1 /* 2 bits */
+#define MAX_TRIAL_VALUE50
+
+struct picodlp_data {
+   struct mutex lock;
+   struct i2c_client *picodlp_i2c_client;
+};
+
+static struct i2c_board_info picodlp_i2c_board_info = {
+   I2C_BOARD_INFO("picodlp_i2c_driver", 0x1b),
+};
+
+struct picodlp_i2c_data {
+   struct mutex xfer_lock;
+};
+
+struct i2c_device_id picodlp_i2c_id[] = {
+   { "picodlp_i2c_driver", 0 },
+};
+
+struct picodlp_i2c_command {
+   u8 reg;
+   u32 value;
+};
+
+static struct omap_video_timings pico_ls_timings = {
+   .x_res  = 864,
+   .y_res  = 480,
+   .hsw= 7,
+   .hfp= 11,
+   .hbp= 7,
+
+   .pixel_clock= 19200,
+
+   .vsw= 2,
+   .vfp= 3,
+   .vbp= 14,
+};
+
+static inline struct picodlp_panel_data
+   *get_panel_data(const struct omap_dss_device *dssdev)
+{
+   return

[PATCH v3 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file

[Mayuresh Janorkar]

An on-board projector named picodlp is available for OMAP4430 SDP.

Entry for this picodlp as a panel is being added in dss_devices array
to the board file.
It needs 4 GPIO pins for interfacing with host processor
and these are defined and two of them are configured in board file.
Two GPIOs power_on and display_select are configured here.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.

Signed-off-by: Mayuresh Janorkar 
Signed-off-by: Mythri P K 
---
Changes since v2:
 Changed GPIO names to power_on, emu_done and pwrgood

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

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 570e83f..060aded 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 #include "hsmmc.h"
@@ -52,6 +53,8 @@
 #define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
 #define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
 #define LCD_BL_GPIO27  /* LCD Backlight GPIO */
+#define OMAP4_DLP_POWER_ON_GPIO40
+#define OMAP4_DLP_DISPLAY_SELECT_GPIO  59
 /* PWM2 and TOGGLE3 register offsets */
 #define LED_PWM2ON 0x03
 #define LED_PWM2OFF0x04
@@ -812,9 +815,64 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.channel = OMAP_DSS_CHANNEL_DIGIT,
 };
 
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+   .picodlp_adapter_id = 2,
+   .emu_done_gpio  = 44,
+   .pwrgood_gpio   = 45,
+};
+
+static int sdp4430_panel_enable_picodlp(struct omap_dss_device *dssdev)
+{
+   int status;
+   struct gpio picodlp_gpios[] = {
+   {OMAP4_DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+   "DLP POWER ON"},
+   {OMAP4_DLP_DISPLAY_SELECT_GPIO, GPIOF_OUT_INIT_LOW,
+   "DLP DISPLAY SELECT"},
+   };
+
+   status = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+   if (status)
+   goto error1;
+
+   gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 1);
+   gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 1);
+
+   return 0;
+error1:
+   pr_err("Cannot request OMAP4_DLP_GPIOs, error %d\n", status);
+   return status;
+}
+
+static void sdp4430_panel_disable_picodlp(struct omap_dss_device *dssdev)
+{
+   struct gpio picodlp_gpios[] = {
+   {OMAP4_DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+   "DLP POWER ON"},
+   {OMAP4_DLP_DISPLAY_SELECT_GPIO, GPIOF_OUT_INIT_LOW,
+   "DLP DISPLAY SELECT"},
+   };
+   gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
+   gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
+
+   gpio_free_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+}
+
+static struct omap_dss_device sdp4430_picodlp_device = {
+   .name   = "picodlp",
+   .driver_name= "picodlp_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 24,
+   .channel= OMAP_DSS_CHANNEL_LCD2,
+   .platform_enable= sdp4430_panel_enable_picodlp,
+   .platform_disable   = sdp4430_panel_disable_picodlp,
+   .data   = &sdp4430_picodlp_pdata,
+};
+
 static struct omap_dss_device *sdp4430_dss_devices[] = {
&sdp4430_lcd_device,
&sdp4430_hdmi_device,
+   &sdp4430_picodlp_device,
 };
 
 static struct omap_dss_board_info sdp4430_dss_data = {
-- 
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 v3 2/4] OMAP: DSS: Adding a picodlp header file

[Mayuresh Janorkar]

From: Mythri P K 

picodlp is a projector connected supported by OMAP.

DLP used in OMAP4 is dpp2600 (DLP Pico Projector)
The DLP requires commands to be sent over i2c for configurations,
Commands are defined together in this header file

To know more about dpp2600 commands please visit:
https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403

Signed-off-by: Mythri P K 
Signed-off-by: Mayuresh Janorkar 
---
Changes since v2:
Added DMA_STATUS definition

Changes since v1: Nil

 drivers/video/omap2/displays/panel-picodlp.h |  288 ++
 1 files changed, 288 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-picodlp.h

diff --git a/drivers/video/omap2/displays/panel-picodlp.h 
b/drivers/video/omap2/displays/panel-picodlp.h
new file mode 100644
index 000..a34b431
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.h
@@ -0,0 +1,288 @@
+/*
+ * Header file required by picodlp panel driver
+ *
+ * Copyright (C) 2009-2011 Texas Instruments
+ * Author: Mythri P K 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+*/
+
+#ifndef __OMAP2_DISPLAY_PANEL_PICODLP_H
+#define __OMAP2_DISPLAY_PANEL_PICODLP_H
+
+/* Commands used for configuring picodlp panel */
+
+#define MAIN_STATUS0x03
+#define PBC_CONTROL0x08
+#define INPUT_SOURCE   0x0B
+#define INPUT_RESOLUTION   0x0C
+#define DATA_FORMAT0x0D
+#define IMG_ROTATION   0x0E
+#define LONG_FLIP  0x0F
+#define SHORT_FLIP 0x10
+#define TEST_PAT_SELECT0x11
+#define R_DRIVE_CURRENT0x12
+#define G_DRIVE_CURRENT0x13
+#define B_DRIVE_CURRENT0x14
+#define READ_REG_SELECT0x15
+#define RGB_DRIVER_ENABLE  0x16
+
+#define CPU_IF_MODE0x18
+#define FRAME_RATE 0x19
+#define CPU_IF_SYNC_METHOD 0x1A
+#define CPU_IF_SOF 0x1B
+#define CPU_IF_EOF 0x1C
+#define CPU_IF_SLEEP   0x1D
+
+#define SEQUENCE_MODE  0x1E
+#define SOFT_RESET 0x1F
+#define FRONT_END_RESET0x21
+#define AUTO_PWR_ENABLE0x22
+
+#define VSYNC_LINE_DELAY   0x23
+#define CPU_PI_HORIZ_START 0x24
+#define CPU_PI_VERT_START  0x25
+#define CPU_PI_HORIZ_WIDTH 0x26
+#define CPU_PI_VERT_HEIGHT 0x27
+
+#define PIXEL_MASK_CROP0x28
+#define CROP_FIRST_LINE0x29
+#define CROP_LAST_LINE 0x2A
+#define CROP_FIRST_PIXEL   0x2B
+#define CROP_LAST_PIXEL0x2C
+#define DMD_PARK_TRIGGER   0x2D
+
+#define MISC_REG   0x30
+
+/* AGC registers */
+#define AGC_CTRL   0x50
+#define AGC_CLIPPED_PIXS   0x55
+#define AGC_BRIGHT_PIXS0x56
+#define AGC_BG_PIXS0x57
+#define AGC_SAFETY_MARGIN  0x17
+
+/* Color Coordinate Adjustment registers */
+#define CCA_ENABLE 0x5E
+#define CCA_C1A0x5F
+#define CCA_C1B0x60
+#define CCA_C1C0x61
+#define CCA_C2A0x62
+#define CCA_C2B0x63
+#define CCA_C2C0x64
+#define CCA_C3A0x65
+#define CCA_C3B0x66
+#define CCA_C3C0x67
+#define CCA_C7A0x71
+#define CCA_C7B0x72
+#define CCA_C7C0x73
+
+/**
+ * DLP Pico Processor 2600 comes with flash
+ * We can do DMA operations from flash for accessing Look Up Tables
+ */
+#define DMA_STATUS 0x100
+#define FLASH_ADDR_BYTES   0x74
+#define FLASH_DUMMY_BYTES  0x75
+#define FLASH_WRITE_BYTES  0x76
+#define FLASH_READ_BYTES   0x77
+#define FLASH_OPCODE   0x78
+#define FLASH_START_ADDR   0x79
+#define FLASH_DUMMY2   0x7A
+#define FLASH_WRITE_DATA   0x7B
+
+#define TEMPORAL_DITH_DISABLE  0x7E
+#define SEQ_CONTROL  

[PATCH 1/4] OMAP: DSS: Adding a header file for picodlp data

[Mayuresh Janorkar]

picodlp is a TI projector supported by OMAP
picodlp is interfaced with host processor using pwrgood and emu_done pins.
In programming sequence it is required to send high to pwrgood to low
wait for a fraction of seconds and then wait for emu_done signal to go low.
picodlp would be ready to send/ receive i2c commands 500 mili-seconds after
emu_done goes low.

A new header file has been added for panel data and
picodlp_panel_data struct has been introduced

Signed-off-by: Mayuresh Janorkar 
---
Changes since v2:
Changed gpio names to emu_done_gpio and pwrgood_gpio

Changes since v1: Nil

 arch/arm/plat-omap/include/plat/panel-picodlp.h |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/panel-picodlp.h

diff --git a/arch/arm/plat-omap/include/plat/panel-picodlp.h 
b/arch/arm/plat-omap/include/plat/panel-picodlp.h
new file mode 100644
index 000..333f7d6
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-picodlp.h
@@ -0,0 +1,23 @@
+/*
+ * panel data for picodlp panel
+ *
+ * Copyright (C) 2011 Texas Instruments
+ *
+ * Author: Mayuresh Janorkar 
+ *
+ * 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.
+ */
+#ifndef __ARCH_ARM_PLAT_PANEL_PICODLP_H
+#define __ARCH_ARM_PLAT_PANEL_PICODLP_H
+/**
+ * struct : picodlp panel data
+ * picodlp_adapter_id: i2c_adapter number for picodlp
+ */
+struct picodlp_panel_data {
+   int picodlp_adapter_id;
+   int emu_done_gpio;
+   int pwrgood_gpio;
+};
+#endif /* __ARCH_ARM_PLAT_PANEL_PICODLP_H */
-- 
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 v3 0/7] picodlp projector driver

[Mayuresh Janorkar]

picodlp projector is supported by OMAP.
OMAP4430 SDP and EVM boards have an on board projector called as picodlp 
projector.
picodlp would be connected to display sub system as a display panel.
It has a dlp pico processor dpp2600.

The panel would be connected using 24 bit parallel interface.
GPIO pin 59 called as DISPLAY SELECT pin selects either secondary lcd
or picodlp.

It is a WVGA panel with 864 X 480 resolution.

To know more about picodlp please visit:
http://omappedia.org/wiki/PicoDLP_projector_guide

GPIO pin settings are required for powering_on the DLP and it is done in board 
file.
The programming sequence states that processor has to send LOW on PWRGOOD (GPIO 
45)
then wait for a fraction of seconds and then send HIGH.
EMU_DONE pin (GPIO 44) would be set to low once the DLP is ready for operation.

Configuartion of picodlp involves passing dpp2600 commands through i2c.
All these commands are defined in a panel header file.
And more info on the commands can be found at:
https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403

About DLP (Digital Light Processing):
DLP is Texas Instruments award-winning display technology which has powered
the worlds top projectors and displays, delivering pictures rich with color,
contrast, clarity and brightness to screens of all sizes.
Every DLP chip features an array of up to 2.2 million microscopic mirrors that
switch at ultra high speeds  an innovative advantage that remains cutting edge
and ideal for current and future applications alike. The results are
high-resolution, highly reliable, razor-sharp images, that even work with
fast motion video.
To learn more about DLP technology, please visit www.DLP.com

picodlp on OMAP4430 boards would make use of same technology.
picodlp makes use of i2c bus device at 0x1b address for sending configuration
commands to panel. In software picodlp panel driver has an i2c client.

To know more about picodlp configuration commands please visit:
http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
The link talks more about the timing specific things:
http://focus.ti.com/lit/ds/dlps019b/dlps019b.pdf

To know more about i2c_client model please visit:
http://lxr.linux.no/#linux+v2.6.38/Documentation/i2c/writing-clients

--
These patches have been developed on top of master branch of
Tomi's gitorious tree.

I am maintaining a gitorious tree for these patches and can be found at:
http://gitorious.org/~mayuresh/linux-omap-dss2/mayuresh-picodlp/commits/picodlp

The driver has been tested when compiled as a module.

Validated with a Penguin logos on OMAP4430 SDP ES2.1

Checkpatch.pl warnings:
WARNING: msleep < 20ms can sleep for up to 20ms; see 
Documentation/timers/timers-howto.txt
I think this warning can be ignored

New compilation warnings introduced: Nil

Changes since v2:
1. Merged picodlp panel patches into a single patch
2. Changed GPIO names and handling
3. Minimized sleep
4. DMA_DONE polling is introduced

-
Mayuresh Janorkar (3):
  OMAP: DSS: Adding a header file for picodlp panel data
  OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
  OMAP: DSS: Add picodlp panel driver

Mythri P K (1):
  OMAP: DSS: Adding a picodlp panel header file

 arch/arm/mach-omap2/board-4430sdp.c |   58 +++
 arch/arm/plat-omap/include/plat/panel-picodlp.h |   23 +
 drivers/video/omap2/displays/Kconfig|7 +
 drivers/video/omap2/displays/Makefile   |1 +
 drivers/video/omap2/displays/panel-picodlp.c|  627 +++
 drivers/video/omap2/displays/panel-picodlp.h|  288 +++
 6 files changed, 1004 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/panel-picodlp.h
 create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
 create mode 100644 drivers/video/omap2/displays/panel-picodlp.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 1/2 v2] OMAP2+: hwmod: Add API to enable IO ring wakeup.

[Paul Walmsley]

Hello Govindraj

On Mon, 9 May 2011, Govindraj.R wrote:

> Add API to enable IO pad wakeup capability based on mux dynamic pad and
> wake_up enable flag available from hwmod_mux initialization.
> 
> Use the wakeup_enable flag and enable wakeup capability
> for the given pads. Wakeup capability will be enabled/disabled
> during hmwod idle transition based on whether wakeup_flag is
> set or cleared.
> 
> Signed-off-by: Govindraj.R 
> ---
>  arch/arm/mach-omap2/omap_hwmod.c  |   51 
> +
>  arch/arm/plat-omap/include/plat/omap_device.h |2 +
>  arch/arm/plat-omap/include/plat/omap_hwmod.h  |3 +
>  arch/arm/plat-omap/omap_device.c  |   50 
>  4 files changed, 106 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
> b/arch/arm/mach-omap2/omap_hwmod.c
> index e034294..bbbe1ed 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2369,3 +2369,54 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
>  
>   return 0;
>  }
> +
> +static int omap_hwmod_configure_ioring_wakeup(struct omap_hwmod *oh, u16 val)

What about Todd's comments?

If this function is still valid after considering those comments -- 
perhaps by adding a 'mask' argument -- then lease change this function's 
name to simply _set_ioring_wakeup() and move it up towards the top of the 
file with the rest of the static functions.

> +{
> + struct omap_device_pad *pad;
> + int ret = -EINVAL, j;
> +
> + if (oh->mux->enabled) {
> + for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
> + pad = oh->mux->pads_dynamic[j];
> + if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
> + pad->idle = pad->enable | val;
> + ret = 0;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * set wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + /* Enable pad wake-up capability */
> + return omap_hwmod_configure_ioring_wakeup(oh, OMAP_WAKEUP_EN);
> +}
> +
> +/**
> + * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
> + * @oh: struct omap_hwmod *
> + *
> + * Traverse through dynamic pads, if pad is enabled then
> + * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
> + * will be set during hwmod idle transistion.
> + * Return error if pads are not enabled or not available.
> + */
> +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
> +{
> + u16 val = 0;
> +
> + /* Disable pad wakeup capability */
> + val &= ~OMAP_WAKEUP_EN;
> + return omap_hwmod_configure_ioring_wakeup(oh, val);
> +}
> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
> b/arch/arm/plat-omap/include/plat/omap_device.h
> index e4c349f..a377dd0 100644
> --- a/arch/arm/plat-omap/include/plat/omap_device.h
> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
> @@ -117,6 +117,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
>  int omap_device_disable_clocks(struct omap_device *od);
>  int omap_device_enable_clocks(struct omap_device *od);
>  
> +int omap_device_enable_ioring_wakeup(struct platform_device *pdev);
> +int omap_device_disable_ioring_wakeup(struct platform_device *pdev);
>  
>  /*
>   * Entries should be kept in latency order ascending
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index 1adea9c..7ef11a6 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -602,6 +602,9 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod 
> *oh);
>  
>  int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
>  
> +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh);
> +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh);
> +
>  /*
>   * Chip variant-specific hwmod init routines - XXX should be converted
>   * to use initcalls once the initial boot ordering is straightened out
> diff --git a/arch/arm/plat-omap/omap_device.c 
> b/arch/arm/plat-omap/omap_device.c
> index 9bbda9a..04a4f15 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -742,6 +742,56 @@ void __iomem *omap_device_get_rt_va(struct omap_device 
> *od)
>   return omap_hwmod_get_mpu_rt_va(od->hwmods[0]);
>  }
>  
> +/**
> + * omap_device_enable_ioring_wakeup - Set wakeup bit for iopad ring.
> + * @pdev: platform_device for which wakeup needs to be set.
> + *
> + * Caller should ensure this is called if device_may_wakeup(dev) is 

[PATCH] omap3: l3: Temporary fix to avoid the kernel hang with beagle board.

[sricharan]

Paul Walmsley reported a kernel hang issue with beagle board during
boot. This is an intermittent bug and the execution was found to be
stuck at the l3 interrupt handler.

This was due to a dss initiator agent timeout occuring during
the boot even when there is no actual interconnect access made by the
dss. since the reason for the dss timeout is not root caused yet,
the time out feature is disabled at the interconnect level.
Note that this is a temporary fix that should be removed once
the dss interconnect agent timeout issue is resolved.

Thanks to Paul Walmsley for reporting and helping in reproducing
this issue.

Signed-off-by: sricharan 
Cc: Paul Wamsley 
Cc: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap_l3_smx.c |   11 +++
 arch/arm/mach-omap2/omap_l3_smx.h |2 ++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_l3_smx.c 
b/arch/arm/mach-omap2/omap_l3_smx.c
index 4321e79..4ea7dcd 100644
--- a/arch/arm/mach-omap2/omap_l3_smx.c
+++ b/arch/arm/mach-omap2/omap_l3_smx.c
@@ -248,6 +248,17 @@ static int __init omap3_l3_probe(struct platform_device 
*pdev)
goto err2;
}
 
+   /*
+* FIX ME: dss interconnect timeout error.
+* Disable the l3 timeout reporting feature for all modules.
+* Also reset the dss initiator agent with which the error is seen
+* to clear the interrupt. This is a temporary fix and should be
+* removed after root causing the issue.
+*/
+   omap3_l3_writell(l3->rt, L3_RT_NETWORK_CONTROL, 0x0);
+   omap3_l3_writell(l3->rt + L3_DSS_IA_CONTROL, L3_AGENT_CONTROL, 0x1);
+   omap3_l3_writell(l3->rt + L3_DSS_IA_CONTROL, L3_AGENT_CONTROL, 0x0);
+
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
IRQF_DISABLED | IRQF_TRIGGER_RISING,
diff --git a/arch/arm/mach-omap2/omap_l3_smx.h 
b/arch/arm/mach-omap2/omap_l3_smx.h
index ba2ed9a..96fff9d 100644
--- a/arch/arm/mach-omap2/omap_l3_smx.h
+++ b/arch/arm/mach-omap2/omap_l3_smx.h
@@ -35,6 +35,8 @@
 #define L3_ERROR_LOG_SECONDARY (1 << 30)
 
 #define L3_ERROR_LOG_ADDR  0x060
+#define L3_RT_NETWORK_CONTROL  0x078
+#define L3_DSS_IA_CONTROL  0x5400
 
 /* Register definitions for Sideband Interconnect */
 #define L3_SI_CONTROL  0x020
-- 
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] OMAP2: avoid descending into disabled framebuffer dirs

[Mike Frysinger]

Rather than always add the omap2 dirs to the build list (and thus
force everyone to generate a useless built-in.o), bind the dirs to
their relevant kconfig symbol.

Signed-off-by: Mike Frysinger 
---
 drivers/video/omap2/Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index d853d05..5ddef12 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_OMAP2_VRAM) += vram.o
 obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
 
-obj-y += dss/
-obj-y += omapfb/
+obj-$(CONFIG_OMAP2_DSS) += dss/
+obj-$(CONFIG_FB_OMAP2) += omapfb/
 obj-y += displays/
-- 
1.7.5.rc3

--
To unsubscribe from this list: send the line "unsubscribe 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 RESEND] omap : nand : fix subpage ecc issue with prefetch

[Kishore Kadiyala]

When reading/writing a subpage (When HW ECC is not available/enabled)
for number of bytes not aligned to 4, the mis-aligned bytes are handled
first (by cpu copy method) before enabling the Prefetch engine to/from
'p'(start of buffer 'buf'). Then it reads/writes rest of the bytes with
the help of Prefetch engine, if available, or again using cpu copy method.
Currently, reading/writing of rest of bytes, is not done correctly since
its trying to read/write again to/from begining of buffer 'buf',
overwriting the mis-aligned bytes.

Read & write using prefetch engine got broken in commit '2c01946c'.
We never hit a scenario of not getting 'gpmc_prefetch_enable' call
success. So, problem did not get caught up.

Signed-off-by: Kishore Kadiyala 
Signed-off-by: Vimal Singh 
Reported-by: Bryan DE FARIA 
---
 drivers/mtd/nand/omap2.c |   12 +---
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..2c8040f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -263,11 +263,10 @@ static void omap_read_buf_pref(struct mtd_info *mtd, 
u_char *buf, int len)
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
-   omap_read_buf16(mtd, buf, len);
+   omap_read_buf16(mtd, (u_char *)p, len);
else
-   omap_read_buf8(mtd, buf, len);
+   omap_read_buf8(mtd, (u_char *)p, len);
} else {
-   p = (u32 *) buf;
do {
r_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
r_count = r_count >> 2;
@@ -293,7 +292,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
struct omap_nand_info, mtd);
uint32_t w_count = 0;
int i = 0, ret = 0;
-   u16 *p;
+   u16 *p = (u16 *)buf;
unsigned long tim, limit;
 
/* take care of subpage writes */
@@ -309,11 +308,10 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
-   omap_write_buf16(mtd, buf, len);
+   omap_write_buf16(mtd, (u_char *)p, len);
else
-   omap_write_buf8(mtd, buf, len);
+   omap_write_buf8(mtd, (u_char *)p, len);
} else {
-   p = (u16 *) buf;
while (len) {
w_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
w_count = w_count >> 1;
-- 
1.7.4.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 4/4] USB: TWL6025 allow different regulator name

[Felipe Balbi]

On Mon, May 09, 2011 at 03:35:43PM +0200, Mark Brown wrote:
> On Mon, May 09, 2011 at 04:07:07PM +0300, Felipe Balbi wrote:
> 
> > The thing is. We already had problems in the past with the Clock FW
> > because drivers were passing clock names on platform_data and I really
> > want to avoid the same on regulators. We need something clever.
> 
> Right, which is why you should *never* do that.  Any time I see anyone
> requesting a regulator based on anything other than a fixed string in
> the driver and the struct device for the consumer I push back very hard,
> and so should everyone else.

ok, so let's go back to the original patch:

> @@ -190,6 +190,12 @@ static int twl6030_phy_suspend(struct otg_transceiver 
> *x, int suspend)
>  
>  static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
>  {
> + char *regulator_name;
> +
> + if (twl_features() & TWL6025_SUBCLASS)
> + regulator_name = "ldousb";
> + else
> + regulator_name = "vusb";
>  
>   /* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
>   twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
> @@ -200,7 +206,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
>   /* Program MISC2 register and set bit VUSB_IN_VBAT */
>   twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
>  
> - twl->usb3v3 = regulator_get(twl->dev, "vusb");
> + twl->usb3v3 = regulator_get(twl->dev, regulator_name);
>   if (IS_ERR(twl->usb3v3))
>   return -ENODEV;

then, imagine 5 years from now how that branch will look. How long do
you think it'll take until someone decides to pass that name via
platform_data to avoid growing that conditional ?


> > We pass in the data of how regulators are wired at the board level and
> > drivers would regulator_get(my_dev->dev, "whatever fancy name I want as
> > it doesn't matter at all");
> 
> No, not at all.  Consumer drivers should be hard coding the strings they
> request and the strings used should correspond to the pin names used on
> the device.

but that's the thing. Why do they need to depend on that string ?

> > on the TRM. In other words, we should match on the functionality they
> > provide, not on the name.
> 
> As Liam said this will just make the situation worse.  Users will have
> to figure out what the names the driver authors assigned to the various
> device supplies map onto in the physical system via an additional layer
> of indirection which will at best be written down in comments in the
> driver.

My point is that the "name" shouldn't matter. Instead of matching a
"name" match a "reference". Have something earlier in the boot assing
regulators to devices, or something like that, so that drivers don't
need to care about "names".

> > Let's try to thing some 5 - 6 years ahead. With the current trend, we
> > will be working on support for the PMIC on OMAP10, imagine if each one
> > of those revisions decide to change the name of the regulator, because
> > this new HW engineer working on the PMIC design doesn't like the old
> > name. We will have X regulator pointers and X regulator name pointers in
> > our platform_data. It will be really cumbersome and prone to errors if
> > people continue on copy&pasting old code to "generate" a new driver.
> 
> Here you're apparently talking about something different - you're
> talking about how we pass in the regulator init data for the regulators
> supplied by the chip.  The patch being discussed changes the consumer
> side for USB, not the regulator driver side.  The naming on the driver

see above, how long do you think it'll take for someone to try and pass
that name via pdata ? On the next name change, this is already likely to
happen to prevent that conditional from growing.

> side is a particular problem for TWL devices since unlike most PMICs the
> regulators aren't simply numbered but are instead assigned individual
> names so you can't just use a big array indexed by number.

why not ? The name shouldn't matter. In anycase, if you look into
/sys/class/regulator/ all directories are regulator.:

dev_set_name(&rdev->dev, "regulator.%d",
 atomic_inc_return(®ulator_no) - 1);

> > What I was expecting to see, was a mechanism where we define how those
> > things are wired (it doesn't matter if the data uses DeviceTree or what)
> > at the HW level and we ask the framework to give us the regulator
> > connected to device X which provides a certain functionality. Just like
> > clkdev has managed to get close to. Currently drivers will:
> 
> This is preceisely what is happening.  A well written consumer driver
> asks the regulator core for the regulator supplying a given supply, with
> the supplies named in the same way as they are named in the datasheet.
> 
> You appear to be arging strongly for us to adopt the model which is
> already in use.

I guess I hasn't been clear enough then, my whole point is that drivers
shouldn't depend on string

Re: [PATCH 4/4] USB: TWL6025 allow different regulator name

[Mark Brown]

On Mon, May 09, 2011 at 04:07:07PM +0300, Felipe Balbi wrote:

> The thing is. We already had problems in the past with the Clock FW
> because drivers were passing clock names on platform_data and I really
> want to avoid the same on regulators. We need something clever.

Right, which is why you should *never* do that.  Any time I see anyone
requesting a regulator based on anything other than a fixed string in
the driver and the struct device for the consumer I push back very hard,
and so should everyone else.

> We pass in the data of how regulators are wired at the board level and
> drivers would regulator_get(my_dev->dev, "whatever fancy name I want as
> it doesn't matter at all");

No, not at all.  Consumer drivers should be hard coding the strings they
request and the strings used should correspond to the pin names used on
the device.

> If a driver has >1 regulator, you can distinguish them by which
> functionality they provide, no matter the name, they will be connected
> to a particular ball on the IC package which has a certain definition

Having more than one supply is the common case for devices; relatively
few devices have a single supply.

> on the TRM. In other words, we should match on the functionality they
> provide, not on the name.

As Liam said this will just make the situation worse.  Users will have
to figure out what the names the driver authors assigned to the various
device supplies map onto in the physical system via an additional layer
of indirection which will at best be written down in comments in the
driver.

> Let's try to thing some 5 - 6 years ahead. With the current trend, we
> will be working on support for the PMIC on OMAP10, imagine if each one
> of those revisions decide to change the name of the regulator, because
> this new HW engineer working on the PMIC design doesn't like the old
> name. We will have X regulator pointers and X regulator name pointers in
> our platform_data. It will be really cumbersome and prone to errors if
> people continue on copy&pasting old code to "generate" a new driver.

Here you're apparently talking about something different - you're
talking about how we pass in the regulator init data for the regulators
supplied by the chip.  The patch being discussed changes the consumer
side for USB, not the regulator driver side.  The naming on the driver
side is a particular problem for TWL devices since unlike most PMICs the
regulators aren't simply numbered but are instead assigned individual
names so you can't just use a big array indexed by number.

> What I was expecting to see, was a mechanism where we define how those
> things are wired (it doesn't matter if the data uses DeviceTree or what)
> at the HW level and we ask the framework to give us the regulator
> connected to device X which provides a certain functionality. Just like
> clkdev has managed to get close to. Currently drivers will:

This is preceisely what is happening.  A well written consumer driver
asks the regulator core for the regulator supplying a given supply, with
the supplies named in the same way as they are named in the datasheet.

You appear to be arging strongly for us to adopt the model which is
already in use.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] USB: TWL6025 allow different regulator name

[Liam Girdwood]

On Mon, 2011-05-09 at 15:16 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:
> > On Mon, 2011-05-09 at 12:03 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Sun, May 08, 2011 at 04:08:37PM +0100, Liam Girdwood wrote:
> > > > On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote:
> > > > > Hi,
> > > > > 
> > > > > On Wed, Apr 27, 2011 at 10:39:51AM +0100, Graeme Gregory wrote:
> > > > > > The twl6025 uses a different regulator for USB than the 6030 so 
> > > > > > select
> > > > > > the correct regulator name depending on the subclass of device.
> > > > > > 
> > > > > > Signed-off-by: Graeme Gregory 
> > > > > 
> > > > > I don't see the point of this patch. It's just a string. Use the same
> > > > > name and add a comment saying that on datasheet/TRM/documentation the
> > > > > name LDO is actually referred to as LDOUSB. It's the same 
> > > > > functionality
> > > > > anyway.
> > > > > 
> > > > 
> > > > I think for the avoidance of any doubt, it's probably best to use the
> > > > TWL6025 string name here as it will importantly match the TWL6025 TRM
> > > > and any schematics using the TWL6025. Getting this wrong during TWL6025
> > > > board integration has the potential for hardware damage.
> > > 
> > > I would rather have something that doesn't depend on a correct string
> > > and matches based on the device pointer instead. I agree that having the
> > > correct string makes it easier to reference schematics/trm and the like,
> > > but making the SW depend on the correct spelling of a simple string, is
> > > too much for me :-(
> > > 
> > > Specially when getting it wrong "has the potential for hardware damage"
> > > :-)
> > > 
> > 
> > I think it's the lesser evil though, especially for device integrators.
> > They will just match the regulator name from the schematics together
> > with the TRM name when creating their regulator constraints and having
> > different names here will definitely cause confusion.
> 
> Any chance Device Tree could be used to pass that data to kernel
> instead, together with regulator names and all needed data for each one
> of them ?
> 

Yes, I think this should be the long term aim, but atm we will have to
stick with current implementation until regulator has device tree
support.

Liam

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

Re: [PATCH 4/4] USB: TWL6025 allow different regulator name

[Felipe Balbi]

Hi,

On Mon, May 09, 2011 at 02:29:41PM +0200, Mark Brown wrote:
> On Mon, May 09, 2011 at 03:16:03PM +0300, Felipe Balbi wrote:
> > On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:
> 
> > > I think it's the lesser evil though, especially for device integrators.
> > > They will just match the regulator name from the schematics together
> > > with the TRM name when creating their regulator constraints and having
> > > different names here will definitely cause confusion.
> 
> > Any chance Device Tree could be used to pass that data to kernel
> > instead, together with regulator names and all needed data for each one
> > of them ?
> 
> I'm pretty sure that as soon as we have viable device tree support for
> relevant platforms in mainline we'll have regulator support, though I'm
> not sure that this will help too much with the naming as you'll still
> have to figure out what the consumer requests.  We shouldn't be passing
> in the consumer supply names from device tree (at least not a board
> specific one) as this breaks the model that the supply names correspond
> to the chip pins.

The thing is. We already had problems in the past with the Clock FW
because drivers were passing clock names on platform_data and I really
want to avoid the same on regulators. We need something clever.

We pass in the data of how regulators are wired at the board level and
drivers would regulator_get(my_dev->dev, "whatever fancy name I want as
it doesn't matter at all");

If a driver has >1 regulator, you can distinguish them by which
functionality they provide, no matter the name, they will be connected
to a particular ball on the IC package which has a certain definition
on the TRM. In other words, we should match on the functionality they
provide, not on the name.

Let's try to thing some 5 - 6 years ahead. With the current trend, we
will be working on support for the PMIC on OMAP10, imagine if each one
of those revisions decide to change the name of the regulator, because
this new HW engineer working on the PMIC design doesn't like the old
name. We will have X regulator pointers and X regulator name pointers in
our platform_data. It will be really cumbersome and prone to errors if
people continue on copy&pasting old code to "generate" a new driver.

What I was expecting to see, was a mechanism where we define how those
things are wired (it doesn't matter if the data uses DeviceTree or what)
at the HW level and we ask the framework to give us the regulator
connected to device X which provides a certain functionality. Just like
clkdev has managed to get close to. Currently drivers will:

clk_get(dev, "ick");
clk_get(dev, "fck");

etc...

and the name really doesn't matter. Clkdev still isn't perfect as it
uses device names, then when we want/need to change the device/driver
name (due to some re-factoring for example) we end up breaking things.
IMHO, struct device should point to its dependencies, be it a clock, be
it a regulator.

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

Re: [PATCH v3] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup

[Avinash.H.M.]

On Thu, May 05, 2011 at 03:58:56PM -0600, Paul Walmsley wrote:

Hi Paul ,

> > 
> > The patch is based on
> >  * git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> >  * master branch.
> >  * 9be20f0 commit. ( Linux-omap rebuilt: Updated to -rc5 )
> 
> Please base all your patches against mainline commits.  I suggest using 
> v2.6.39-rc6.

OK Paul. I will rebase against mainline, -rc6.

> 
> Also some comments:
> 
> > Changes from previous versions:
> > from v1:
> > - moved i2c specific things from hwmod files to i2c files.
> > - fixed comments from Paul.
> > - http://www.spinics.net/lists/linux-omap/msg49483.html
> > 
> > +
> > +/**
> > + * omap_i2c_reset- reset the omap i2c module.
> 
> Please put a space before the dash.

OK. I ll correct.

> 
> > + * @oh: struct omap_hwmod *
> > + *
> > + * The i2c moudle in omap2, omap3 had a special sequence to reset. The
> > + * sequence is:
> > + * - Disable the I2C.
> > + * - Write to SOFTRESET bit.
> > + * - Enable the I2C.
> > + * - Poll on the RESETDONE bit.
> > + * The sequence is implemented in below function. This is called for 2420,
> > + * 2430 and omap3.
> > + */
> > +int omap_i2c_reset(struct omap_hwmod *oh)
> > +{
> You're missing kerneldoc here.  Please add it.

OK. I ll add the kerneldoc.

> 
> > +void omap_hwmod_softreset(struct omap_hwmod *oh)
> > +{
> > +   u32 v;
> > +
> > +   /* Write to the SOFTRESET bit in SYSCONFIG */
> > +   v = oh->_sysc_cache;
> > +   v |= (0x1 << oh->class->sysc->sysc_fields->srst_shift);
> > +
> > +   oh->_sysc_cache = v;
> > +   omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
> > +}
> 
> This is a public function, so you need to validate your oh argument and 
> return an error if something isn't right.  Similarly, you should use the 
> existing function _set_softreset() to set the bit, because it also does 
> some errorchecking.
> 


I agree. I ll use _set_softreset to set the bit and check for the
argument sanity.

> > +
> >  /**
> >   * omap_hwmod_set_slave_idlemode - set the hwmod's OCP slave idlemode
> >   * @oh: struct omap_hwmod *
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
> > b/arch/arm/mach-omap2/omap_hwmod_2420_data.c

thanks for reviewing.

- Avinash
> 
> 
> - 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 1/2 v2] OMAP2+: hwmod: Add API to enable IO ring wakeup.

[Govindraj.R]

Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.

Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enabled/disabled
during hmwod idle transition based on whether wakeup_flag is
set or cleared.

Signed-off-by: Govindraj.R 
---
 arch/arm/mach-omap2/omap_hwmod.c  |   51 +
 arch/arm/plat-omap/include/plat/omap_device.h |2 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |3 +
 arch/arm/plat-omap/omap_device.c  |   50 
 4 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..bbbe1ed 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2369,3 +2369,54 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
 
return 0;
 }
+
+static int omap_hwmod_configure_ioring_wakeup(struct omap_hwmod *oh, u16 val)
+{
+   struct omap_device_pad *pad;
+   int ret = -EINVAL, j;
+
+   if (oh->mux->enabled) {
+   for (j = 0; j < oh->mux->nr_pads_dynamic; j++) {
+   pad = oh->mux->pads_dynamic[j];
+   if (pad->flags & OMAP_DEVICE_PAD_WAKEUP) {
+   pad->idle = pad->enable | val;
+   ret = 0;
+   }
+   }
+   }
+
+   return ret;
+}
+
+/**
+ * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * set wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh)
+{
+   /* Enable pad wake-up capability */
+   return omap_hwmod_configure_ioring_wakeup(oh, OMAP_WAKEUP_EN);
+}
+
+/**
+ * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad.
+ * @oh: struct omap_hwmod *
+ *
+ * Traverse through dynamic pads, if pad is enabled then
+ * clear wakeup enable bit flag for the mux pin. Wakeup pad bit
+ * will be set during hwmod idle transistion.
+ * Return error if pads are not enabled or not available.
+ */
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh)
+{
+   u16 val = 0;
+
+   /* Disable pad wakeup capability */
+   val &= ~OMAP_WAKEUP_EN;
+   return omap_hwmod_configure_ioring_wakeup(oh, val);
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..a377dd0 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -117,6 +117,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
 int omap_device_disable_clocks(struct omap_device *od);
 int omap_device_enable_clocks(struct omap_device *od);
 
+int omap_device_enable_ioring_wakeup(struct platform_device *pdev);
+int omap_device_disable_ioring_wakeup(struct platform_device *pdev);
 
 /*
  * Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..7ef11a6 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -602,6 +602,9 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod 
*oh);
 
 int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
 
+int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh);
+int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh);
+
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
  * to use initcalls once the initial boot ordering is straightened out
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9bbda9a..04a4f15 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -742,6 +742,56 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od)
return omap_hwmod_get_mpu_rt_va(od->hwmods[0]);
 }
 
+/**
+ * omap_device_enable_ioring_wakeup - Set wakeup bit for iopad ring.
+ * @pdev: platform_device for which wakeup needs to be set.
+ *
+ * Caller should ensure this is called if device_may_wakeup(dev) is true
+ * traverse through each hwmod and check each available pads
+ * if pad is enabled then set wakeup enable flag for the mux pin.
+ * Return error if pads are not enabled or not available.
+ * Wakeup enable flag will be we used during hwmod idle transistion.
+ */
+int omap_device_enable_ioring_wakeup(struct platform_device *pdev)
+{
+   int ret = -EINVAL, i;
+   struct omap_device *od;
+   struct omap_hwmod *oh;
+
+   od = _find_by_pdev(pdev);
+   for (i = 0; i < od->hwmods_cnt; i++) {
+   oh = od->hwmods[i];
+  

[PATCH 2/2 v2] OMAP2+: hwmod: Add API to check IO PAD wakeup status

[Govindraj.R]

Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.

Signed-off-by: Govindraj.R 
---
 arch/arm/mach-omap2/mux.c|   28 ++
 arch/arm/mach-omap2/mux.h|   13 
 arch/arm/mach-omap2/omap_hwmod.c |   14 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
 4 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index a4ab1e3..b40aebe 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -348,6 +348,34 @@ err1:
return NULL;
 }
 
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux:  Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup event is set for pad else false
+ * if wakeup is not occured or pads are not avialable.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+   int i;
+   unsigned int val;
+   u8 ret = false;
+
+   for (i = 0; i < hmux->nr_pads; i++) {
+   struct omap_device_pad *pad = &hmux->pads[i];
+
+   val = omap_mux_read(pad->partition,
+   pad->mux->reg_offset);
+   if (val & OMAP_WAKEUP_EVENT) {
+   ret = true;
+   break;
+   }
+   }
+
+   return ret;
+}
+
 /* Assumes the calling function takes care of locking */
 void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
 {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 137f321..86a0051 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int 
nr_pads);
  */
 void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
 
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux:  Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
 #else
 
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+   return 0;
+}
+
 static inline int omap_mux_init_gpio(int gpio, int val)
 {
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bbbe1ed..3311234 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2420,3 +2420,17 @@ int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod 
*oh)
val &= ~OMAP_WAKEUP_EN;
return omap_hwmod_configure_ioring_wakeup(oh, val);
 }
+
+/**
+ * omap_hwmod_pad_get_wakeup_status - get pad wakeup status if mux is 
available.
+ * @oh: struct omap_hwmod *
+ *
+ * Returns the wake_up status bit of available pad mux pin.
+ * return error if no mux pads are available.
+ */
+int omap_hmwod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+   if (oh->mux)
+   return omap_hwmod_mux_get_wake_status(oh->mux);
+   return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7ef11a6..664975c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -605,6 +605,7 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
 int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh);
 int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh);
 
+int omap_hmwod_pad_get_wakeup_status(struct omap_hwmod *oh);
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
  * to use initcalls once the initial boot ordering is straightened out
-- 
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 0/2 v2] OMAP2+: hwmod: Add hwmod's API's for pad wakeup

[Govindraj.R]

Add two API's to set IO Pad wakeup capability based on hwmod
mux pins available and also to check the status of IO Pad wakeup
event.

This two patches are separated from uart_runtime patches posted
earlier and uart_runtime adaptation relies on these two API's.

Based on 2.6.39-rc6

Changes from v1:
---
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg49141.html

Reference to Discussion:

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

Govindraj.R (2):
  OMAP2+: hwmod: Add API to enable IO ring wakeup.
  OMAP2+: hwmod: Add API to check IO PAD wakeup status

 arch/arm/mach-omap2/mux.c |   28 +++
 arch/arm/mach-omap2/mux.h |   13 +
 arch/arm/mach-omap2/omap_hwmod.c  |   65 +
 arch/arm/plat-omap/include/plat/omap_device.h |2 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |4 ++
 arch/arm/plat-omap/omap_device.c  |   50 +++
 6 files changed, 162 insertions(+), 0 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] OMAP3: set the core dpll clk rate in its set_rate function.

[Avinash.H.M]

The debug l3_ick/rate is not displaying the actual rate of the clock in
hardware. This is because, the core dpll set_rate function doesn't update the
clk.rate. After fixing, the l3_ick/rate is displaying proper values.

Signed-off-by: Shweta Gulati 
Signed-off-by: Avinash.H.M 
Cc: Rajendra Nayak 
Cc: Paul Wamsley 
---
* The patch is based on v2.6.39-rc6
* The patch is tested on zoom3.
* The patch is based on discussions from 
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg48518.html

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

diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b10d9ef..2a77faf 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -118,6 +118,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
  sdrc_cs0->rfr_ctrl, sdrc_cs0->actim_ctrla,
  sdrc_cs0->actim_ctrlb, sdrc_cs0->mr,
  0, 0, 0, 0);
+   clk->rate = rate;
 
return 0;
 }
-- 
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 4/4] USB: TWL6025 allow different regulator name

[Mark Brown]

On Mon, May 09, 2011 at 03:16:03PM +0300, Felipe Balbi wrote:
> On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:

> > I think it's the lesser evil though, especially for device integrators.
> > They will just match the regulator name from the schematics together
> > with the TRM name when creating their regulator constraints and having
> > different names here will definitely cause confusion.

> Any chance Device Tree could be used to pass that data to kernel
> instead, together with regulator names and all needed data for each one
> of them ?

I'm pretty sure that as soon as we have viable device tree support for
relevant platforms in mainline we'll have regulator support, though I'm
not sure that this will help too much with the naming as you'll still
have to figure out what the consumer requests.  We shouldn't be passing
in the consumer supply names from device tree (at least not a board
specific one) as this breaks the model that the supply names correspond
to the chip pins.
--
To unsubscribe from this list: send the line "unsubscribe 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 11/12] OMAP: Serial: Use resume call from prcm to enable uart

[Govindraj]

On Fri, May 6, 2011 at 9:25 PM, Kevin Hilman  wrote:
> Govindraj  writes:
>
>> On Thu, May 5, 2011 at 8:28 PM, Kevin Hilman  wrote:
>>> Govindraj  writes:
>>>
>>> [...]
>>>
>
> ... this is just putting back basically the same thing that was removed in
> patch 1.  IOW, this is now being checked for *every* PRCM wakeup, which
> is no different than having it in the idle path.
>
> I thought I understood that you had the SW IRQ triggering working, so
> this part should not be necessary.

 Actually I tried few experiments but couldn't get it working.
>>>
>>> What exactly is not working?   The interrupt is not firing at all?  The
>>> driver's ISR is not being called?
>>>
>>
>> It throws a oops as here
>>
>> http://pastebin.com/5bcPjAA0
>
> This doesn't help understand what exactly is not working.  This needs
> to be debugged further to understand the root cause.
>
> A quick glance at the oops shows a fault when accessing a *physical*
> address within the INTC.  The MMU is enabled here, and HW accesss should
> be using a virtual address.

Today we could get console_uart booted with irq_patches + uart_runtime
shared by Avinash [Irq_chaining + some local hacks, still not clean patches]

But AFAIK looks like still soft irq method is not generic as we dont
have any similar mechanism for omap4 so how to keep it consistent.

So Shall we retain resume method until we have a generic approach ?

--
Thanks,
Govindraj.R


>
> Also, early in the boot there are a pile of other errors coming from the
> clock framework suggesting that this kernel has some other basic
> problems as well.
>
>> Reproduced with below [EXP-1] change + below kernel.
>>
>> git://gitorious.org/uart_runtime/pm.git
>> [Has uart runtime patches based on pm-core branch]
>>
 Tried below but didn't help.

 
 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index 3960330..2c1dfc2 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -288,6 +288,16 @@ static irqreturn_t prcm_interrupt_handler (int
 irq, void *dev_id)
         do {
                 if (irqstatus_mpu & (OMAP3430_WKUP_ST_MASK |
                                      OMAP3430_IO_ST_MASK)) {
 +#if 1
 +                       /*
 +                        * EXP-1: SET UART1 SOFT IRQ BIT
 +                        * 3430 -SDP UART1 console.
 +                        * M_IRQ_72, INTCPS_ISR_SET
 +                        * 0x4820 0090 + (0x20 * n)
 +                        * bit-8 n = 2
 +                        */
 +                       __raw_writel(0x100 , 0x482000D0);
 +#endif
                         c = _prcm_int_handle_wakeup();

                         /*

 ---

 Currently we are planning to integrate irq_chaining patches
 on top uart_runtime patches which is work-in-progress.
 Will remove resume_idle once we have irq_chaining patches available.
>>>
>>> Well, I'm not OK with $SUBJECT patch as it is since it's just moving an
>>> ugly hack from serial.c to the PRCM ISR.  If the hack is going to stay,
>>> then it should stay where it is until it can be fixed for real.
>>
>> Now with runtime changes we are cutting clocks independently
>> whereas prior to this we where cutting clocks only in sram_idle path.
>>
>> With runtime changes:
>> 1.) Once we cut uart clocks and send a char to uart it directs wakeup_irq to
>> prcm_irq_handler the one way to wakeup uart from there was to check
>> uart mod wakeup status bits if wakeup event occurred then wakeup the
>> particular uart.
>> 2.) Moving this resume back to sram path will break module wakeup after
>> uart clocks are disabled(using put_sync)
>>
>> Thats the reason I have moved this to prcm_irq path to ensure
>> once auto-suspend happens after inactivity period we have resume_call
>> to wakeup uart port.
>
> I understand, but the point is that this approach is still the same as
> the previous hack (check for UART wakeup on *every* wakeup event.)
>
> What is needed is to further investigate using SW triggered IRQs can be
> done for these wakeup events so we can get away from the above approach
> all together.
>
> 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 4/4] USB: TWL6025 allow different regulator name

[Felipe Balbi]

Hi,

On Mon, May 09, 2011 at 12:43:49PM +0100, Liam Girdwood wrote:
> On Mon, 2011-05-09 at 12:03 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Sun, May 08, 2011 at 04:08:37PM +0100, Liam Girdwood wrote:
> > > On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Wed, Apr 27, 2011 at 10:39:51AM +0100, Graeme Gregory wrote:
> > > > > The twl6025 uses a different regulator for USB than the 6030 so select
> > > > > the correct regulator name depending on the subclass of device.
> > > > > 
> > > > > Signed-off-by: Graeme Gregory 
> > > > 
> > > > I don't see the point of this patch. It's just a string. Use the same
> > > > name and add a comment saying that on datasheet/TRM/documentation the
> > > > name LDO is actually referred to as LDOUSB. It's the same functionality
> > > > anyway.
> > > > 
> > > 
> > > I think for the avoidance of any doubt, it's probably best to use the
> > > TWL6025 string name here as it will importantly match the TWL6025 TRM
> > > and any schematics using the TWL6025. Getting this wrong during TWL6025
> > > board integration has the potential for hardware damage.
> > 
> > I would rather have something that doesn't depend on a correct string
> > and matches based on the device pointer instead. I agree that having the
> > correct string makes it easier to reference schematics/trm and the like,
> > but making the SW depend on the correct spelling of a simple string, is
> > too much for me :-(
> > 
> > Specially when getting it wrong "has the potential for hardware damage"
> > :-)
> > 
> 
> I think it's the lesser evil though, especially for device integrators.
> They will just match the regulator name from the schematics together
> with the TRM name when creating their regulator constraints and having
> different names here will definitely cause confusion.

Any chance Device Tree could be used to pass that data to kernel
instead, together with regulator names and all needed data for each one
of them ?

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

Re: [PATCH 4/4] USB: TWL6025 allow different regulator name

[Liam Girdwood]

On Mon, 2011-05-09 at 12:03 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Sun, May 08, 2011 at 04:08:37PM +0100, Liam Girdwood wrote:
> > On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Wed, Apr 27, 2011 at 10:39:51AM +0100, Graeme Gregory wrote:
> > > > The twl6025 uses a different regulator for USB than the 6030 so select
> > > > the correct regulator name depending on the subclass of device.
> > > > 
> > > > Signed-off-by: Graeme Gregory 
> > > 
> > > I don't see the point of this patch. It's just a string. Use the same
> > > name and add a comment saying that on datasheet/TRM/documentation the
> > > name LDO is actually referred to as LDOUSB. It's the same functionality
> > > anyway.
> > > 
> > 
> > I think for the avoidance of any doubt, it's probably best to use the
> > TWL6025 string name here as it will importantly match the TWL6025 TRM
> > and any schematics using the TWL6025. Getting this wrong during TWL6025
> > board integration has the potential for hardware damage.
> 
> I would rather have something that doesn't depend on a correct string
> and matches based on the device pointer instead. I agree that having the
> correct string makes it easier to reference schematics/trm and the like,
> but making the SW depend on the correct spelling of a simple string, is
> too much for me :-(
> 
> Specially when getting it wrong "has the potential for hardware damage"
> :-)
> 

I think it's the lesser evil though, especially for device integrators.
They will just match the regulator name from the schematics together
with the TRM name when creating their regulator constraints and having
different names here will definitely cause confusion.

Liam

--
To unsubscribe from this list: send the line "unsubscribe 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: usbhs: Fixed the crash during rmmod of ehci and ohci

[Munegowda, Keshava]

On Mon, May 9, 2011 at 3:06 PM, Felipe Balbi  wrote:
> Hi,
>
> On Mon, May 09, 2011 at 02:40:03PM +0530, Keshava Munegowda wrote:
>> From: Keshava Munegowda 
>>
>> the disabling of clocks and freeing GPIO are changed
>> to fix the occurence of the crash of rmmod of ehci and ohci
>> drivers
>>
>> Signed-off-by: Keshava Munegowda 
>
> NAK
>
>> ---
>>  drivers/mfd/omap-usb-host.c |   24 
>>  1 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 3ab9ffa..cda0797 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -939,6 +939,7 @@ static void usbhs_disable(struct device *dev)
>>       struct usbhs_hcd_omap           *omap = dev_get_drvdata(dev);
>>       struct usbhs_omap_platform_data *pdata = &omap->platdata;
>>       unsigned long                   flags = 0;
>> +     unsigned int                    halt = 0;
>
> you shouldn't need this.
>
>> @@ -994,24 +995,31 @@ static void usbhs_disable(struct device *dev)
>>                       dev_dbg(dev, "operation timed out\n");
>>       }
>>
>> -     if (pdata->ehci_data->phy_reset) {
>> -             if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
>> -                     gpio_free(pdata->ehci_data->reset_gpio_port[0]);
>> -
>> -             if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
>> -                     gpio_free(pdata->ehci_data->reset_gpio_port[1]);
>> +     if (is_omap_usbhs_rev2(omap)) {
>> +             if (is_ehci_tll_mode(pdata->port_mode[0]))
>> +                     clk_enable(omap->usbtll_p1_fck);
>> +             if (is_ehci_tll_mode(pdata->port_mode[1]))
>> +                     clk_enable(omap->usbtll_p2_fck);
>> +             clk_disable(omap->utmi_p2_fck);
>> +             clk_disable(omap->utmi_p1_fck);
>>       }
>>
>> -     clk_disable(omap->utmi_p2_fck);
>> -     clk_disable(omap->utmi_p1_fck);
>>       clk_disable(omap->usbtll_ick);
>>       clk_disable(omap->usbtll_fck);
>>       clk_disable(omap->usbhost_fs_fck);
>>       clk_disable(omap->usbhost_hs_fck);
>>       clk_disable(omap->usbhost_ick);
>> +     halt = 1;
>
> at least from this diff, you're always reaching that part of the code
> rendering this halt flag useless.

I you see only the patch ; its looks like variable halt is not needed;

If the code; it will be set only when the clocks are disabled;
Then after restoring irq, you will free the gpio based on this value.

The complete usbhs_disable code is follows:
static void usbhs_disable(struct device *dev)
{
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = &omap->platdata;
unsigned long   flags = 0;
unsigned inthalt = 0;
unsigned long   timeout;

dev_dbg(dev, "stopping TI HSUSB Controller\n");

spin_lock_irqsave(&omap->lock, flags);

if (omap->count == 0)
goto end_disble;

omap->count--;

if (omap->count != 0)
goto end_disble;

/* Reset OMAP modules for insmod/rmmod to work */
usbhs_write(omap->uhh_base, OMAP_UHH_SYSCONFIG,
is_omap_usbhs_rev2(omap) ?
OMAP4_UHH_SYSCONFIG_SOFTRESET :
OMAP_UHH_SYSCONFIG_SOFTRESET);

timeout = jiffies + msecs_to_jiffies(100);
while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
& (1 << 0))) {
cpu_relax();

if (time_after(jiffies, timeout))
dev_dbg(dev, "operation timed out\n");
}

while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
& (1 << 1))) {
cpu_relax();

if (time_after(jiffies, timeout))
dev_dbg(dev, "operation timed out\n");
}

while (!(usbhs_read(omap->uhh_base, OMAP_UHH_SYSSTATUS)
& (1 << 2))) {
cpu_relax();

if (time_after(jiffies, timeout))
dev_dbg(dev, "operation timed out\n");
}

usbhs_write(omap->tll_base, OMAP_USBTLL_SYSCONFIG, (1 << 1));

while (!(usbhs_read(omap->tll_base, OMAP_USBTLL_SYSSTATUS)
& (1 << 0))) {
cpu_relax();

if (time_after(jiffies, timeout))
dev_dbg(dev, "operation timed out\n");
}

if (is_omap_usbhs_rev2(omap)) {
if (is_ehci_tll_mode(pdata->port_mode[0]))
clk_enable(omap->usbtll_p1_fck);
if (is_ehci_tll_mode(pdata->port_mode[1]))
clk_enable(omap->usbtll_p2_fck);
clk_disable(omap->utmi_p2_fck);
clk_disable(omap->utmi_p1_fck);
}

clk_disable(o

[PATCH 4/4] OMAP3: cpuidle: change the power domains modes determination logic

[jean . pihet]

From: Jean Pihet 

The achievable power modes of the power domains in cpuidle
depends on the system wide 'enable_off_mode' knob in debugfs.
Upon changing enable_off_mode, do not change the C-states
'valid' field but instead dynamically restrict the power modes
when entering idle.

The C-states 'valid' field is just used to enable/disable some
C-states at init and shall not be changed later on.

Signed-off-by: Jean Pihet 
---
 arch/arm/mach-omap2/cpuidle34xx.c |   58 +++-
 arch/arm/mach-omap2/pm.h  |4 --
 arch/arm/mach-omap2/pm34xx.c  |   12 ---
 3 files changed, 24 insertions(+), 50 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index dd31e53..4bf6e6e 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -138,22 +138,40 @@ return_sleep_time:
 }
 
 /**
- * next_valid_state - Find next valid c-state
+ * next_valid_state - Find next valid C-state
  * @dev: cpuidle device
- * @state: Currently selected c-state
+ * @state: Currently selected C-state
  *
  * If the current state is valid, it is returned back to the caller.
  * Else, this function searches for a lower c-state which is still
  * valid.
+ *
+ * A state is valid if the 'valid' field is enabled and
+ * if it satisfies the enable_off_mode condition.
  */
 static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev,
  struct cpuidle_state *curr)
 {
struct cpuidle_state *next = NULL;
struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
+   u32 mpu_deepest_state = PWRDM_POWER_RET;
+   u32 core_deepest_state = PWRDM_POWER_RET;
+
+   if (enable_off_mode) {
+   mpu_deepest_state = PWRDM_POWER_OFF;
+   /*
+* Erratum i583: valable for ES rev < Es1.2 on 3630.
+* CORE OFF mode is not supported in a stable form, restrict
+* instead the CORE state to RET.
+*/
+   if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
+   core_deepest_state = PWRDM_POWER_OFF;
+   }
 
/* Check if current state is valid */
-   if (cx->valid) {
+   if ((cx->valid) &&
+   (cx->mpu_state >= mpu_deepest_state) &&
+   (cx->core_state >= core_deepest_state)) {
return curr;
} else {
int idx = OMAP3_NUM_STATES - 1;
@@ -176,7 +194,9 @@ static struct cpuidle_state *next_valid_state(struct 
cpuidle_device *dev,
idx--;
for (; idx >= 0; idx--) {
cx = cpuidle_get_statedata(&dev->states[idx]);
-   if (cx->valid) {
+   if ((cx->valid) &&
+   (cx->mpu_state >= mpu_deepest_state) &&
+   (cx->core_state >= core_deepest_state)) {
next = &dev->states[idx];
break;
}
@@ -259,31 +279,6 @@ select_state:
 
 DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
 
-/**
- * omap3_cpuidle_update_states() - Update the cpuidle states
- * @mpu_deepest_state: Enable states up to and including this for mpu domain
- * @core_deepest_state:Enable states up to and including this for core 
domain
- *
- * This goes through the list of states available and enables and disables the
- * validity of C states based on deepest state that can be achieved for the
- * variable domain
- */
-void omap3_cpuidle_update_states(u32 mpu_deepest_state, u32 core_deepest_state)
-{
-   int i;
-
-   for (i = 0; i < OMAP3_NUM_STATES; i++) {
-   struct omap3_idle_statedata *cx = &omap3_idle_data[i];
-
-   if ((cx->mpu_state >= mpu_deepest_state) &&
-   (cx->core_state >= core_deepest_state)) {
-   cx->valid = 1;
-   } else {
-   cx->valid = 0;
-   }
-   }
-}
-
 void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
 {
int i;
@@ -393,11 +388,6 @@ int __init omap3_idle_init(void)
cx->mpu_state = PWRDM_POWER_OFF;
cx->core_state = PWRDM_POWER_OFF;
 
-   if (enable_off_mode)
-   omap3_cpuidle_update_states(PWRDM_POWER_OFF, PWRDM_POWER_OFF);
-   else
-   omap3_cpuidle_update_states(PWRDM_POWER_RET, PWRDM_POWER_RET);
-
dev->state_count = OMAP3_NUM_STATES;
if (cpuidle_register_device(dev)) {
printk(KERN_ERR "%s: CPUidle register device failed\n",
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 32dbc13..45bcfce 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -78,10 +78,6 @@ extern u32 sleep_while_idle;
 #define sleep_while_idle 0
 #endif
 
-#if defined(CONFIG_CPU_IDLE)
-extern void omap3_cpuidle_update_states(u32, u32);
-#endif
-
 #if 

[PATCH 3/4] OMAP3: cpuidle: code rework for improved readability

[jean . pihet]

From: Jean Pihet 

- fix single and multi-lines comments format
- removed the omap3_idle_bm_check function and replaced the test
   in omap3_enter_idle_bm by the equivalent code
- re-organize omap3_enter_idle_bm code path, assign local variables
   only when needed
- reword some comments

Signed-off-by: Jean Pihet 
---
 arch/arm/mach-omap2/cpuidle34xx.c |   52 +---
 1 files changed, 19 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index f9c8676..dd31e53 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -71,13 +71,6 @@ struct omap3_idle_statedata 
omap3_idle_data[OMAP3_NUM_STATES];
 
 struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
 
-static int omap3_idle_bm_check(void)
-{
-   if (!omap3_can_sleep())
-   return 1;
-   return 0;
-}
-
 static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
struct clockdomain *clkdm)
 {
@@ -157,9 +150,7 @@ static struct cpuidle_state *next_valid_state(struct 
cpuidle_device *dev,
  struct cpuidle_state *curr)
 {
struct cpuidle_state *next = NULL;
-   struct omap3_idle_statedata *cx;
-
-   cx = cpuidle_get_statedata(curr);
+   struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
 
/* Check if current state is valid */
if (cx->valid) {
@@ -167,9 +158,7 @@ static struct cpuidle_state *next_valid_state(struct 
cpuidle_device *dev,
} else {
int idx = OMAP3_NUM_STATES - 1;
 
-   /*
-* Reach the current state starting at highest C-state
-*/
+   /* Reach the current state starting at highest C-state */
for (; idx >= 0; idx--) {
if (&dev->states[idx] == curr) {
next = &dev->states[idx];
@@ -177,9 +166,7 @@ static struct cpuidle_state *next_valid_state(struct 
cpuidle_device *dev,
}
}
 
-   /*
-* Should never hit this condition.
-*/
+   /* Should never hit this condition */
WARN_ON(next == NULL);
 
/*
@@ -214,29 +201,16 @@ static struct cpuidle_state *next_valid_state(struct 
cpuidle_device *dev,
 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 cpuidle_state *new_state;
+   u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
int ret;
 
-   if (omap3_idle_bm_check()) {
-   BUG_ON(!dev->safe_state);
+   if (!omap3_can_sleep()) {
new_state = dev->safe_state;
goto select_state;
}
 
-   cx = cpuidle_get_statedata(state);
-   core_next_state = cx->core_state;
-
-   /*
-* FIXME: we currently manage device-specific idle states
-*for PER and CORE in combination with CPU-specific
-*idle states.  This is wrong, and device-specific
-*idle management needs to be separated out into 
-*its own code.
-*/
-
/*
 * Prevent idle completely if CAM is active.
 * CAM does not have wakeup capability in OMAP3.
@@ -248,9 +222,19 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
}
 
/*
+* FIXME: we currently manage device-specific idle states
+*for PER and CORE in combination with CPU-specific
+*idle states.  This is wrong, and device-specific
+*idle management needs to be separated out into
+*its own code.
+*/
+
+   /*
 * Prevent PER off if CORE is not in retention or off as this
 * would disable PER wakeups completely.
 */
+   cx = cpuidle_get_statedata(state);
+   core_next_state = cx->core_state;
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))
@@ -260,6 +244,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
 
+   new_state = next_valid_state(dev, state);
+
 select_state:
dev->last_state = new_state;
ret = omap3_enter_idle(dev, new_state);
@@ -320,7 +306,7 @@ struct cpuidle_driver omap3_idle_driver = {
.owner =THIS_MODULE,
 };
 
-/* Fill in the state data from the mach tables and register the driver_data */
+/* Helper to fill the 

[PATCH 2/4] OMAP3: cpuidle: re-organize the C-states data

[jean . pihet]

From: Jean Pihet 

The current implementation defines an internal structure and a
C-states array. Using those structures is redundant to the
structs used by the cpuidle framework.

This patch provides a clean-up of the internal struct, removes the
internal C-states array, stores the data using the existing cpuidle
per C-state struct and registers the mach specific data to cpuidle
C-state driver_data (accessed using cpuidle_[gs]et_statedata).
Also removes unused macros, fields and code and compacts the repeating
code using an inline helper function.

The result is more compact and more readable code as well as
reduced data RAM usage.

Also retain C1 as the only always valid C-state and system safe state.

Signed-off-by: Jean Pihet 
---
 arch/arm/mach-omap2/cpuidle34xx.c |  305 -
 1 files changed, 101 insertions(+), 204 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index d7bc31a..f9c8676 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,35 +36,6 @@
 
 #ifdef CONFIG_CPU_IDLE
 
-#define OMAP3_MAX_STATES 7
-#define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */
-#define OMAP3_STATE_C2 1 /* C2 - MPU WFI + Core inactive */
-#define OMAP3_STATE_C3 2 /* C3 - MPU CSWR + Core inactive */
-#define OMAP3_STATE_C4 3 /* C4 - MPU OFF + Core iactive */
-#define OMAP3_STATE_C5 4 /* C5 - MPU RET + Core RET */
-#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core RET */
-#define OMAP3_STATE_C7 6 /* C7 - MPU OFF + Core OFF */
-
-#define OMAP3_STATE_MAX OMAP3_STATE_C7
-
-#define CPUIDLE_FLAG_CHECK_BM  0x1 /* use omap3_enter_idle_bm() */
-
-struct omap3_processor_cx {
-   u8 valid;
-   u8 type;
-   u32 exit_latency;
-   u32 mpu_state;
-   u32 core_state;
-   u32 target_residency;
-   u32 flags;
-   const char *desc;
-};
-
-struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
-struct omap3_processor_cx current_cx_state;
-struct powerdomain *mpu_pd, *core_pd, *per_pd;
-struct powerdomain *cam_pd;
-
 /*
  * The latencies/thresholds for various C states have
  * to be configured from the respective board files.
@@ -88,6 +59,17 @@ static struct cpuidle_params cpuidle_params_table[] = {
/* C7 */
{1 + 3, 30, 1},
 };
+#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
+
+/* Mach specific information to be recorded in the C-state driver_data */
+struct omap3_idle_statedata {
+   u32 mpu_state;
+   u32 core_state;
+   u8 valid;
+};
+struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
+
+struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
 
 static int omap3_idle_bm_check(void)
 {
@@ -121,12 +103,10 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
 static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_state *state)
 {
-   struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
+   struct omap3_idle_statedata *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
 
-   current_cx_state = *cx;
-
/* Used to keep track of the total time in idle */
getnstimeofday(&ts_preidle);
 
@@ -139,7 +119,8 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
 
-   if (cx->type == OMAP3_STATE_C1) {
+   /* Deny idle for C1 */
+   if (state == &dev->states[0]) {
pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
}
@@ -147,7 +128,8 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
/* Execute ARM wfi */
omap_sram_idle();
 
-   if (cx->type == OMAP3_STATE_C1) {
+   /* Re-allow idle for C1 */
+   if (state == &dev->states[0]) {
pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
}
@@ -169,26 +151,26 @@ return_sleep_time:
  *
  * If the current state is valid, it is returned back to the caller.
  * Else, this function searches for a lower c-state which is still
- * valid (as defined in omap3_power_states[]).
+ * valid.
  */
 static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev,
-   struct cpuidle_state *curr)
+ struct cpuidle_state *curr)
 {
struct cpuidle_state *next = NULL;
-   struct omap3_processor_cx *cx;
+   struct omap3_idle_statedata *cx;
 
-   cx = (struct omap3_processor_cx *)cpuidle_get_statedata(curr);
+   cx = cpuidle_get_statedata(curr);
 
/* Check if current state is valid */
if (cx->valid) {
return curr;
} else {
-   u8 idx

[PATCH 1/4] OMAP3: clean-up mach specific cpuidle data structures

[jean . pihet]

From: Jean Pihet 

- sleep_latency and wake_latency are not used, replace them by
  exit_latency which is used by cpuidle. exit_latency simply is
  the sum of sleep_latency and wake_latency,
- replace threshold by target_residency,
- changed the OMAP3 specific cpuidle code accordingly,
- changed the OMAP3 board code accordingly.

Signed-off-by: Jean Pihet 
---
 arch/arm/mach-omap2/board-rx51.c  |   18 ---
 arch/arm/mach-omap2/cpuidle34xx.c |  103 +++-
 arch/arm/mach-omap2/pm.h  |   13 +++--
 3 files changed, 63 insertions(+), 71 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index e964895..3629f9e 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -58,21 +58,25 @@ static struct platform_device leds_gpio = {
},
 };
 
+/*
+ * cpuidle C-states definition override from the default values.
+ * The 'exit_latency' field is the sum of sleep and wake-up latencies.
+ */
 static struct cpuidle_params rx51_cpuidle_params[] = {
/* C1 */
-   {1, 110, 162, 5},
+   {110 + 162, 5 , 1},
/* C2 */
-   {1, 106, 180, 309},
+   {106 + 180, 309, 1},
/* C3 */
-   {0, 107, 410, 46057},
+   {107 + 410, 46057, 0},
/* C4 */
-   {0, 121, 3374, 46057},
+   {121 + 3374, 46057, 0},
/* C5 */
-   {1, 855, 1146, 46057},
+   {855 + 1146, 46057, 1},
/* C6 */
-   {0, 7580, 4134, 484329},
+   {7580 + 4134, 484329, 0},
/* C7 */
-   {1, 7505, 15274, 484329},
+   {7505 + 15274, 484329, 1},
 };
 
 static struct omap_lcd_config rx51_lcd_config = {
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1c240ef..d7bc31a 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -52,11 +52,10 @@
 struct omap3_processor_cx {
u8 valid;
u8 type;
-   u32 sleep_latency;
-   u32 wakeup_latency;
+   u32 exit_latency;
u32 mpu_state;
u32 core_state;
-   u32 threshold;
+   u32 target_residency;
u32 flags;
const char *desc;
 };
@@ -75,19 +74,19 @@ struct powerdomain *cam_pd;
  */
 static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
-   {1, 2, 2, 5},
+   {2 + 2, 5, 1},
/* C2 */
-   {1, 10, 10, 30},
+   {10 + 10, 30, 1},
/* C3 */
-   {1, 50, 50, 300},
+   {50 + 50, 300, 1},
/* C4 */
-   {1, 1500, 1800, 4000},
+   {1500 + 1800, 4000, 1},
/* C5 */
-   {1, 2500, 7500, 12000},
+   {2500 + 7500, 12000, 1},
/* C6 */
-   {1, 3000, 8500, 15000},
+   {3000 + 8500, 15000, 1},
/* C7 */
-   {1, 1, 3, 30},
+   {1 + 3, 30, 1},
 };
 
 static int omap3_idle_bm_check(void)
@@ -330,12 +329,10 @@ void omap3_pm_init_cpuidle(struct cpuidle_params 
*cpuidle_board_params)
for (i = OMAP3_STATE_C1; i < OMAP3_MAX_STATES; i++) {
cpuidle_params_table[i].valid =
cpuidle_board_params[i].valid;
-   cpuidle_params_table[i].sleep_latency =
-   cpuidle_board_params[i].sleep_latency;
-   cpuidle_params_table[i].wake_latency =
-   cpuidle_board_params[i].wake_latency;
-   cpuidle_params_table[i].threshold =
-   cpuidle_board_params[i].threshold;
+   cpuidle_params_table[i].exit_latency =
+   cpuidle_board_params[i].exit_latency;
+   cpuidle_params_table[i].target_residency =
+   cpuidle_board_params[i].target_residency;
}
return;
 }
@@ -357,12 +354,10 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C1].valid =
cpuidle_params_table[OMAP3_STATE_C1].valid;
omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
-   omap3_power_states[OMAP3_STATE_C1].sleep_latency =
-   cpuidle_params_table[OMAP3_STATE_C1].sleep_latency;
-   omap3_power_states[OMAP3_STATE_C1].wakeup_latency =
-   cpuidle_params_table[OMAP3_STATE_C1].wake_latency;
-   omap3_power_states[OMAP3_STATE_C1].threshold =
-   cpuidle_params_table[OMAP3_STATE_C1].threshold;
+   omap3_power_states[OMAP3_STATE_C1].exit_latency =
+   cpuidle_params_table[OMAP3_STATE_C1].exit_latency;
+   omap3_power_states[OMAP3_STATE_C1].target_residency =
+   cpuidle_params_table[OMAP3_STATE_C1].target_residency;
omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
@@ -372,12 +367,10 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C2].valid =
 

[PATCH v3 0/4] OMAP: cpuidle code clean-up

[jean . pihet]

From: Jean Pihet 

Rework of the OMAP2+ cpuidle code

v3: rework after comments on linux-omap ML:
- renamed the C-state driver data variables as 'cx',
- retain C1 as the only always valid state and safe state,
- rework of the C-states definition.

v2: rework after comments on linux-omap ML:
- remove useless macros,
- replace the C-state common data fill-in helper macro by an inline
   function, for better readability,
- update commits description.

v1:
- optimize the cpuidle C-states data registration and storage,
- change the interaction with the debugfs 'enable_off_mode' knob
 and the use of the C-states 'valid' internal field,
- remove dead code,
- improve code readability.

Tested on Beagleboard B5 with cpuidle in RET and OFF modes.

Another 151 lines of OMAP code gone ;p

Notes:
1) the debugfs 'enable_off_mode' knob will be deprecated by the use
 of the devices constraints framework to restrict the power domains
 power modes.
2) the MPU and CORE power domains low power modes are controlled
 by cpuidle, based on the allowed overall sleep+wake-up latencies
 and the wake-up latency constraints on the MPU. This is incorrect.
 The devices constraints framework shall be used instead to control
 all power domains.

ToDo:
- integrate cpuidle with the devices constraints framework, when merged in,
- refine the latency figures and express them in term of available data
 from other frameworks (OMAP PM, constaints framework, omap_devices,
 new VC/VP voltage and DVFS code ...),

Rebased on khilman's for_2.6.40/pm-cleanup branch


Jean Pihet (4):
  OMAP3: clean-up mach specific cpuidle data structures
  OMAP3: cpuidle: re-organize the C-states data
  OMAP3: cpuidle: code rework for improved readability
  OMAP3: cpuidle: change the power domains modes determination logic

 arch/arm/mach-omap2/board-rx51.c  |   18 +-
 arch/arm/mach-omap2/cpuidle34xx.c |  436 +
 arch/arm/mach-omap2/pm.h  |   17 +-
 arch/arm/mach-omap2/pm34xx.c  |   12 -
 4 files changed, 166 insertions(+), 317 deletions(-)

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

Re: [PATCH] omap: usbhs: Fixed the crash during rmmod of ehci and ohci

[Felipe Balbi]

Hi,

On Mon, May 09, 2011 at 02:40:03PM +0530, Keshava Munegowda wrote:
> From: Keshava Munegowda 
> 
> the disabling of clocks and freeing GPIO are changed
> to fix the occurence of the crash of rmmod of ehci and ohci
> drivers
> 
> Signed-off-by: Keshava Munegowda 

NAK

> ---
>  drivers/mfd/omap-usb-host.c |   24 
>  1 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 3ab9ffa..cda0797 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -939,6 +939,7 @@ static void usbhs_disable(struct device *dev)
>   struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
>   struct usbhs_omap_platform_data *pdata = &omap->platdata;
>   unsigned long   flags = 0;
> + unsigned inthalt = 0;

you shouldn't need this.

> @@ -994,24 +995,31 @@ static void usbhs_disable(struct device *dev)
>   dev_dbg(dev, "operation timed out\n");
>   }
>  
> - if (pdata->ehci_data->phy_reset) {
> - if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
> - gpio_free(pdata->ehci_data->reset_gpio_port[0]);
> -
> - if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
> - gpio_free(pdata->ehci_data->reset_gpio_port[1]);
> + if (is_omap_usbhs_rev2(omap)) {
> + if (is_ehci_tll_mode(pdata->port_mode[0]))
> + clk_enable(omap->usbtll_p1_fck);
> + if (is_ehci_tll_mode(pdata->port_mode[1]))
> + clk_enable(omap->usbtll_p2_fck);
> + clk_disable(omap->utmi_p2_fck);
> + clk_disable(omap->utmi_p1_fck);
>   }
>  
> - clk_disable(omap->utmi_p2_fck);
> - clk_disable(omap->utmi_p1_fck);
>   clk_disable(omap->usbtll_ick);
>   clk_disable(omap->usbtll_fck);
>   clk_disable(omap->usbhost_fs_fck);
>   clk_disable(omap->usbhost_hs_fck);
>   clk_disable(omap->usbhost_ick);
> + halt = 1;

at least from this diff, you're always reaching that part of the code
rendering this halt flag useless.

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

[PATCH] omap: usbhs: Fixed the crash during rmmod of ehci and ohci

[Keshava Munegowda]

From: Keshava Munegowda 

the disabling of clocks and freeing GPIO are changed
to fix the occurence of the crash of rmmod of ehci and ohci
drivers

Signed-off-by: Keshava Munegowda 
---
 drivers/mfd/omap-usb-host.c |   24 
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 3ab9ffa..cda0797 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -939,6 +939,7 @@ static void usbhs_disable(struct device *dev)
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = &omap->platdata;
unsigned long   flags = 0;
+   unsigned inthalt = 0;
unsigned long   timeout;
 
dev_dbg(dev, "stopping TI HSUSB Controller\n");
@@ -994,24 +995,31 @@ static void usbhs_disable(struct device *dev)
dev_dbg(dev, "operation timed out\n");
}
 
-   if (pdata->ehci_data->phy_reset) {
-   if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
-   gpio_free(pdata->ehci_data->reset_gpio_port[0]);
-
-   if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
-   gpio_free(pdata->ehci_data->reset_gpio_port[1]);
+   if (is_omap_usbhs_rev2(omap)) {
+   if (is_ehci_tll_mode(pdata->port_mode[0]))
+   clk_enable(omap->usbtll_p1_fck);
+   if (is_ehci_tll_mode(pdata->port_mode[1]))
+   clk_enable(omap->usbtll_p2_fck);
+   clk_disable(omap->utmi_p2_fck);
+   clk_disable(omap->utmi_p1_fck);
}
 
-   clk_disable(omap->utmi_p2_fck);
-   clk_disable(omap->utmi_p1_fck);
clk_disable(omap->usbtll_ick);
clk_disable(omap->usbtll_fck);
clk_disable(omap->usbhost_fs_fck);
clk_disable(omap->usbhost_hs_fck);
clk_disable(omap->usbhost_ick);
+   halt = 1;
 
 end_disble:
spin_unlock_irqrestore(&omap->lock, flags);
+   if (halt && pdata->ehci_data->phy_reset) {
+   if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
+   gpio_free(pdata->ehci_data->reset_gpio_port[0]);
+
+   if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[1]))
+   gpio_free(pdata->ehci_data->reset_gpio_port[1]);
+   }
 }
 
 int omap_usbhs_enable(struct device *dev)
-- 
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 4/4] USB: TWL6025 allow different regulator name

[Felipe Balbi]

Hi,

On Sun, May 08, 2011 at 04:08:37PM +0100, Liam Girdwood wrote:
> On Wed, 2011-04-27 at 13:45 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Apr 27, 2011 at 10:39:51AM +0100, Graeme Gregory wrote:
> > > The twl6025 uses a different regulator for USB than the 6030 so select
> > > the correct regulator name depending on the subclass of device.
> > > 
> > > Signed-off-by: Graeme Gregory 
> > 
> > I don't see the point of this patch. It's just a string. Use the same
> > name and add a comment saying that on datasheet/TRM/documentation the
> > name LDO is actually referred to as LDOUSB. It's the same functionality
> > anyway.
> > 
> 
> I think for the avoidance of any doubt, it's probably best to use the
> TWL6025 string name here as it will importantly match the TWL6025 TRM
> and any schematics using the TWL6025. Getting this wrong during TWL6025
> board integration has the potential for hardware damage.

I would rather have something that doesn't depend on a correct string
and matches based on the device pointer instead. I agree that having the
correct string makes it easier to reference schematics/trm and the like,
but making the SW depend on the correct spelling of a simple string, is
too much for me :-(

Specially when getting it wrong "has the potential for hardware damage"
:-)

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

[PATCH] MFD: twl4030-codec: Update e-mail address

[Peter Ujfalusi]

Signed-off-by: Peter Ujfalusi 
---
 drivers/mfd/twl4030-codec.c   |3 ++-
 include/linux/mfd/twl4030-codec.h |1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-codec.c b/drivers/mfd/twl4030-codec.c
index c02fded..3641a6f 100644
--- a/drivers/mfd/twl4030-codec.c
+++ b/drivers/mfd/twl4030-codec.c
@@ -2,6 +2,7 @@
  * MFD driver for twl4030 codec submodule
  *
  * Author: Peter Ujfalusi 
+ * Contact:Peter Ujfalusi 
  *
  * Copyright:   (C) 2009 Nokia Corporation
  *
@@ -270,6 +271,6 @@ static void __devexit twl4030_codec_exit(void)
 }
 module_exit(twl4030_codec_exit);
 
-MODULE_AUTHOR("Peter Ujfalusi ");
+MODULE_AUTHOR("Peter Ujfalusi ");
 MODULE_LICENSE("GPL");
 
diff --git a/include/linux/mfd/twl4030-codec.h 
b/include/linux/mfd/twl4030-codec.h
index 2ec317c..89a6820 100644
--- a/include/linux/mfd/twl4030-codec.h
+++ b/include/linux/mfd/twl4030-codec.h
@@ -2,6 +2,7 @@
  * MFD driver for twl4030 codec submodule
  *
  * Author: Peter Ujfalusi 
+ * Contact:Peter Ujfalusi 
  *
  * Copyright:   (C) 2009 Nokia Corporation
  *
-- 
1.7.5.rc3

--
To unsubscribe from this list: send the line "unsubscribe 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/6] OMAP: 2420SDP: Port the display driver to new DSS2

[Igor Grinberg]

Hi Tomi,

On 05/09/11 10:36, Tomi Valkeinen wrote:

> Port the old omapfb panel driver to DSS2. This patch changes the board
> file only, the driver is ported in separate patch.
>
> Signed-off-by: Tomi Valkeinen 
> Cc: Hunyue Yau 
> ---
>  arch/arm/mach-omap2/board-2430sdp.c |   84 
> +--
>  1 files changed, 70 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
> b/arch/arm/mach-omap2/board-2430sdp.c
> index 1fa6bb8..9b6e987 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -38,6 +38,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "mux.h"
>  #include "hsmmc.h"
> @@ -98,20 +100,79 @@ static struct platform_device sdp2430_flash_device = {
>   .resource   = &sdp2430_flash_resource,
>  };
>  
> -static struct platform_device sdp2430_lcd_device = {
> - .name   = "sdp2430_lcd",
> - .id = -1,
> -};
> -
>  static struct platform_device *sdp2430_devices[] __initdata = {
>   &sdp2430_flash_device,
> +};
> +
> +/* LCD */
> +#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
> +#define SDP2430_LCD_PANEL_ENABLE_GPIO154
> +
> +static int sdp2430_panel_enable_lcd(struct omap_dss_device *dssdev)
> +{
> + gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 1);
> + gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 1);
> +
> + return 0;
> +}
> +
> +static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
> +{
> + gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 0);
> + gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 0);
> +}
> +
> +static struct panel_generic_dpi_data sdp2430_panel_data = {
> + .name   = "2430sdp",
> + .platform_enable= sdp2430_panel_enable_lcd,
> + .platform_disable   = sdp2430_panel_disable_lcd,
> +};
> +
> +static struct omap_dss_device sdp2430_lcd_device = {
> + .name   = "lcd",
> + .driver_name= "generic_dpi_panel",
> + .type   = OMAP_DISPLAY_TYPE_DPI,
> + .phy.dpi.data_lines = 16,
> + .data   = &sdp2430_panel_data,
> +};
> +
> +static struct omap_dss_device *sdp2430_dss_devices[] = {
>   &sdp2430_lcd_device,
>  };
>  
> -static struct omap_lcd_config sdp2430_lcd_config __initdata = {
> - .ctrl_name  = "internal",
> +static struct omap_dss_board_info sdp2430_dss_data = {
> + .num_devices= ARRAY_SIZE(sdp2430_dss_devices),
> + .devices= sdp2430_dss_devices,
> + .default_device = &sdp2430_lcd_device,
>  };
>  
> +static void __init sdp2430_display_init(void)
> +{
> + int r;
> +
> + r = gpio_request_one(SDP2430_LCD_PANEL_ENABLE_GPIO,
> + GPIOF_OUT_INIT_LOW, "LCD reset");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD reset GPIO\n");
> + goto err0;
> + }
> +
> + r = gpio_request_one(SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
> + GPIOF_OUT_INIT_LOW, "LCD Backlight");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD backlight GPIO\n");

can both printks be pr_err?

> + goto err1;
> + }
> +
> + omap_display_init(&sdp2430_dss_data);
> +
> + return;
> +err1:
> + gpio_free(SDP2430_LCD_PANEL_ENABLE_GPIO);
> +err0:
> + return;
> +}

I think using gpio_request_array() will be much cleaner here...

> +
>  #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
>  
>  static struct omap_smc91x_platform_data board_smc91x_data = {
> @@ -136,10 +197,6 @@ static inline void board_smc91x_init(void)
>  
>  #endif
>  
> -static struct omap_board_config_kernel sdp2430_config[] __initdata = {
> - {OMAP_TAG_LCD, &sdp2430_lcd_config},
> -};
> -
>  static void __init omap_2430sdp_init_early(void)
>  {
>   omap2_init_common_infrastructure();
> @@ -244,9 +301,6 @@ static void __init omap_2430sdp_init(void)
>  
>   omap2430_mux_init(board_mux, OMAP_PACKAGE_ZAC);
>  
> - omap_board_config = sdp2430_config;
> - omap_board_config_size = ARRAY_SIZE(sdp2430_config);
> -
>   omap2430_i2c_init();
>  
>   platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
> @@ -263,6 +317,8 @@ static void __init omap_2430sdp_init(void)
>   ret = gpio_request(SECONDARY_LCD_GPIO, "Secondary LCD backlight");
>   if (ret == 0)
>   gpio_direction_output(SECONDARY_LCD_GPIO, 0);
> +
> + sdp2430_display_init();
>  }
>  
>  static void __init omap_2430sdp_map_io(void)

-- 
Regards,
Igor.

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

Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2

[stanley.miao]

Acked-by: Stanley Miao 

Stanley.

Tomi Valkeinen wrote:

Port the old omapfb panel driver to DSS2i. This patch changes the board
file only, the driver is ported in separate patch.

Signed-off-by: Tomi Valkeinen 
Cc: Stanley Miao 
---
 arch/arm/mach-omap2/board-ldp.c |   73 +-
 1 files changed, 63 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index e2ba779..2fdfd7f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,8 @@
 
 #include 

 #include 
+#include 
+#include 
 
 #include "board-flash.h"

 #include "mux.h"
@@ -275,19 +277,71 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
 }
 
-static struct platform_device ldp_lcd_device = {

-   .name   = "ldp_lcd",
-   .id = -1,
+/* LCD */
+
+#define LCD_PANEL_BACKLIGHT_GPIO   (15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO  (7 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_RESET_GPIO   55
+#define LCD_PANEL_QVGA_GPIO56
+
+static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+   return 0;
+}
+
+static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data ldp_panel_data = {
+   .name   = "2430sdp",
+   .platform_enable= ldp_panel_enable_lcd,
+   .platform_disable   = ldp_panel_disable_lcd,
 };
 
-static struct omap_lcd_config ldp_lcd_config __initdata = {

-   .ctrl_name  = "internal",
+static struct omap_dss_device ldp_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "generic_dpi_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .data   = &ldp_panel_data,
 };
 
-static struct omap_board_config_kernel ldp_config[] __initdata = {

-   { OMAP_TAG_LCD, &ldp_lcd_config },
+static struct omap_dss_device *ldp_dss_devices[] = {
+   &ldp_lcd_device,
+};
+
+static struct omap_dss_board_info ldp_dss_data = {
+   .num_devices= ARRAY_SIZE(ldp_dss_devices),
+   .devices= ldp_dss_devices,
+   .default_device = &ldp_lcd_device,
 };
 
+static void __init ldp_display_init(void)

+{
+   int r;
+
+   struct gpio gpios[] = {
+   {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
+   {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
+   {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
+   {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
+   };
+
+   r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+   if (r) {
+   pr_err("Cannot request LCD GPIOs, error %d\n", r);
+   return;
+   }
+
+   omap_display_init(&ldp_dss_data);
+}
+
 static void __init omap_ldp_init_early(void)
 {
omap2_init_common_infrastructure();
@@ -390,7 +444,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {

&ldp_smsc911x_device,
-   &ldp_lcd_device,
&ldp_gpio_keys_device,
 };
 
@@ -441,8 +494,6 @@ static struct mtd_partition ldp_nand_partitions[] = {

 static void __init omap_ldp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
-   omap_board_config = ldp_config;
-   omap_board_config_size = ARRAY_SIZE(ldp_config);
ldp_init_smsc911x();
omap_i2c_init();
platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
@@ -459,6 +510,8 @@ static void __init omap_ldp_init(void)
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
ldp_vmmc1_supply.dev = mmc[0].dev;
+
+   ldp_display_init();
 }
 
 MACHINE_START(OMAP_LDP, "OMAP LDP board")

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

[PATCH 6/6] OMAP: Apollon: Port the display driver to new DSS2

[Tomi Valkeinen]

Port the old omapfb panel driver to DSS2. This patch changes the board
file only, the driver is ported in separate patch.

Signed-off-by: Tomi Valkeinen 
Cc: Kyungmin Park 
---
 arch/arm/mach-omap2/board-apollon.c |   34 ++
 1 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-apollon.c 
b/arch/arm/mach-omap2/board-apollon.c
index f4f8374..0414c17 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mux.h"
 #include "control.h"
@@ -149,11 +151,6 @@ static struct platform_device apollon_smc91x_device = {
.resource   = apollon_smc91x_resources,
 };
 
-static struct platform_device apollon_lcd_device = {
-   .name   = "apollon_lcd",
-   .id = -1,
-};
-
 static struct omap_led_config apollon_led_config[] = {
{
.cdev   = {
@@ -191,7 +188,6 @@ static struct platform_device apollon_led_device = {
 static struct platform_device *apollon_devices[] __initdata = {
&apollon_onenand_device,
&apollon_smc91x_device,
-   &apollon_lcd_device,
&apollon_led_device,
 };
 
@@ -266,12 +262,26 @@ static struct omap_usb_config apollon_usb_config 
__initdata = {
.pins[0]= 6,
 };
 
-static struct omap_lcd_config apollon_lcd_config __initdata = {
-   .ctrl_name  = "internal",
+static struct panel_generic_dpi_data apollon_panel_data = {
+   .name   = "apollon",
+};
+
+static struct omap_dss_device apollon_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "generic_dpi_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 18,
+   .data   = &apollon_panel_data,
 };
 
-static struct omap_board_config_kernel apollon_config[] __initdata = {
-   { OMAP_TAG_LCD, &apollon_lcd_config },
+static struct omap_dss_device *apollon_dss_devices[] = {
+   &apollon_lcd_device,
+};
+
+static struct omap_dss_board_info apollon_dss_data = {
+   .num_devices= ARRAY_SIZE(apollon_dss_devices),
+   .devices= apollon_dss_devices,
+   .default_device = &apollon_lcd_device,
 };
 
 static void __init omap_apollon_init_early(void)
@@ -317,8 +327,6 @@ static void __init omap_apollon_init(void)
u32 v;
 
omap2420_mux_init(board_mux, OMAP_PACKAGE_ZAC);
-   omap_board_config = apollon_config;
-   omap_board_config_size = ARRAY_SIZE(apollon_config);
 
apollon_init_smc91x();
apollon_led_init();
@@ -343,6 +351,8 @@ static void __init omap_apollon_init(void)
 */
platform_add_devices(apollon_devices, ARRAY_SIZE(apollon_devices));
omap_serial_init();
+
+   omap_display_init(&apollon_dss_data);
 }
 
 static void __init omap_apollon_map_io(void)
-- 
1.7.4.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/6] OMAP: LDP: Port the display driver to new DSS2

[Tomi Valkeinen]

Port the old omapfb panel driver to DSS2i. This patch changes the board
file only, the driver is ported in separate patch.

Signed-off-by: Tomi Valkeinen 
Cc: Stanley Miao 
---
 arch/arm/mach-omap2/board-ldp.c |   73 +-
 1 files changed, 63 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index e2ba779..2fdfd7f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "board-flash.h"
 #include "mux.h"
@@ -275,19 +277,71 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
 }
 
-static struct platform_device ldp_lcd_device = {
-   .name   = "ldp_lcd",
-   .id = -1,
+/* LCD */
+
+#define LCD_PANEL_BACKLIGHT_GPIO   (15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO  (7 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_RESET_GPIO   55
+#define LCD_PANEL_QVGA_GPIO56
+
+static int ldp_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+   return 0;
+}
+
+static void ldp_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data ldp_panel_data = {
+   .name   = "2430sdp",
+   .platform_enable= ldp_panel_enable_lcd,
+   .platform_disable   = ldp_panel_disable_lcd,
 };
 
-static struct omap_lcd_config ldp_lcd_config __initdata = {
-   .ctrl_name  = "internal",
+static struct omap_dss_device ldp_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "generic_dpi_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .data   = &ldp_panel_data,
 };
 
-static struct omap_board_config_kernel ldp_config[] __initdata = {
-   { OMAP_TAG_LCD, &ldp_lcd_config },
+static struct omap_dss_device *ldp_dss_devices[] = {
+   &ldp_lcd_device,
+};
+
+static struct omap_dss_board_info ldp_dss_data = {
+   .num_devices= ARRAY_SIZE(ldp_dss_devices),
+   .devices= ldp_dss_devices,
+   .default_device = &ldp_lcd_device,
 };
 
+static void __init ldp_display_init(void)
+{
+   int r;
+
+   struct gpio gpios[] = {
+   {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
+   {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
+   {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
+   {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
+   };
+
+   r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+   if (r) {
+   pr_err("Cannot request LCD GPIOs, error %d\n", r);
+   return;
+   }
+
+   omap_display_init(&ldp_dss_data);
+}
+
 static void __init omap_ldp_init_early(void)
 {
omap2_init_common_infrastructure();
@@ -390,7 +444,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
&ldp_smsc911x_device,
-   &ldp_lcd_device,
&ldp_gpio_keys_device,
 };
 
@@ -441,8 +494,6 @@ static struct mtd_partition ldp_nand_partitions[] = {
 static void __init omap_ldp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
-   omap_board_config = ldp_config;
-   omap_board_config_size = ARRAY_SIZE(ldp_config);
ldp_init_smsc911x();
omap_i2c_init();
platform_add_devices(ldp_devices, ARRAY_SIZE(ldp_devices));
@@ -459,6 +510,8 @@ static void __init omap_ldp_init(void)
omap2_hsmmc_init(mmc);
/* link regulators to MMC adapters */
ldp_vmmc1_supply.dev = mmc[0].dev;
+
+   ldp_display_init();
 }
 
 MACHINE_START(OMAP_LDP, "OMAP LDP board")
-- 
1.7.4.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/6] OMAP: H4: Port the display driver to new DSS2

[Tomi Valkeinen]

Port the old omapfb panel driver to DSS2. This patch changes the board
file only, the driver is ported in separate patch.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-h4.c |   41 ---
 1 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index bac7933..991e71e 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mux.h"
 #include "control.h"
@@ -157,17 +159,33 @@ static struct platform_device h4_kp_device = {
},
 };
 
-static struct platform_device h4_lcd_device = {
-   .name   = "lcd_h4",
-   .id = -1,
-};
-
 static struct platform_device *h4_devices[] __initdata = {
&h4_flash_device,
&h4_kp_device,
+};
+
+static struct panel_generic_dpi_data h4_panel_data = {
+   .name   = "h4",
+};
+
+static struct omap_dss_device h4_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "generic_dpi_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .data   = &h4_panel_data,
+};
+
+static struct omap_dss_device *h4_dss_devices[] = {
&h4_lcd_device,
 };
 
+static struct omap_dss_board_info h4_dss_data = {
+   .num_devices= ARRAY_SIZE(h4_dss_devices),
+   .devices= h4_dss_devices,
+   .default_device = &h4_lcd_device,
+};
+
 /* 2420 Sysboot setup (2430 is different) */
 static u32 get_sysboot_value(void)
 {
@@ -271,10 +289,6 @@ static void __init h4_init_flash(void)
h4_flash_resource.end   = base + SZ_64M - 1;
 }
 
-static struct omap_lcd_config h4_lcd_config __initdata = {
-   .ctrl_name  = "internal",
-};
-
 static struct omap_usb_config h4_usb_config __initdata = {
/* S1.10 OFF -- usb "download port"
 * usb0 switched to Mini-B port and isp1105 transceiver;
@@ -286,10 +300,6 @@ static struct omap_usb_config h4_usb_config __initdata = {
.hmc_mode   = 0x00, /* 0:dev|otg 1:disable 2:disable */
 };
 
-static struct omap_board_config_kernel h4_config[] __initdata = {
-   { OMAP_TAG_LCD, &h4_lcd_config },
-};
-
 static void __init omap_h4_init_early(void)
 {
omap2_init_common_infrastructure();
@@ -331,9 +341,6 @@ static void __init omap_h4_init(void)
 {
omap2420_mux_init(board_mux, OMAP_PACKAGE_ZAF);
 
-   omap_board_config = h4_config;
-   omap_board_config_size = ARRAY_SIZE(h4_config);
-
/*
 * Make sure the serial ports are muxed on at this point.
 * You have to mux them off in device drivers later on
@@ -372,6 +379,8 @@ static void __init omap_h4_init(void)
omap2_usbfs_init(&h4_usb_config);
omap_serial_init();
h4_init_flash();
+
+   omap_display_init(&h4_dss_data);
 }
 
 static void __init omap_h4_map_io(void)
-- 
1.7.4.1

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

[PATCH 3/6] OMAP: 2420SDP: Port the display driver to new DSS2

[Tomi Valkeinen]

Port the old omapfb panel driver to DSS2. This patch changes the board
file only, the driver is ported in separate patch.

Signed-off-by: Tomi Valkeinen 
Cc: Hunyue Yau 
---
 arch/arm/mach-omap2/board-2430sdp.c |   84 +--
 1 files changed, 70 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 1fa6bb8..9b6e987 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mux.h"
 #include "hsmmc.h"
@@ -98,20 +100,79 @@ static struct platform_device sdp2430_flash_device = {
.resource   = &sdp2430_flash_resource,
 };
 
-static struct platform_device sdp2430_lcd_device = {
-   .name   = "sdp2430_lcd",
-   .id = -1,
-};
-
 static struct platform_device *sdp2430_devices[] __initdata = {
&sdp2430_flash_device,
+};
+
+/* LCD */
+#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO   91
+#define SDP2430_LCD_PANEL_ENABLE_GPIO  154
+
+static int sdp2430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 1);
+   gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 1);
+
+   return 0;
+}
+
+static void sdp2430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_direction_output(SDP2430_LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_direction_output(SDP2430_LCD_PANEL_BACKLIGHT_GPIO, 0);
+}
+
+static struct panel_generic_dpi_data sdp2430_panel_data = {
+   .name   = "2430sdp",
+   .platform_enable= sdp2430_panel_enable_lcd,
+   .platform_disable   = sdp2430_panel_disable_lcd,
+};
+
+static struct omap_dss_device sdp2430_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "generic_dpi_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .data   = &sdp2430_panel_data,
+};
+
+static struct omap_dss_device *sdp2430_dss_devices[] = {
&sdp2430_lcd_device,
 };
 
-static struct omap_lcd_config sdp2430_lcd_config __initdata = {
-   .ctrl_name  = "internal",
+static struct omap_dss_board_info sdp2430_dss_data = {
+   .num_devices= ARRAY_SIZE(sdp2430_dss_devices),
+   .devices= sdp2430_dss_devices,
+   .default_device = &sdp2430_lcd_device,
 };
 
+static void __init sdp2430_display_init(void)
+{
+   int r;
+
+   r = gpio_request_one(SDP2430_LCD_PANEL_ENABLE_GPIO,
+   GPIOF_OUT_INIT_LOW, "LCD reset");
+   if (r) {
+   printk(KERN_ERR "failed to get LCD reset GPIO\n");
+   goto err0;
+   }
+
+   r = gpio_request_one(SDP2430_LCD_PANEL_BACKLIGHT_GPIO,
+   GPIOF_OUT_INIT_LOW, "LCD Backlight");
+   if (r) {
+   printk(KERN_ERR "failed to get LCD backlight GPIO\n");
+   goto err1;
+   }
+
+   omap_display_init(&sdp2430_dss_data);
+
+   return;
+err1:
+   gpio_free(SDP2430_LCD_PANEL_ENABLE_GPIO);
+err0:
+   return;
+}
+
 #if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
 
 static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -136,10 +197,6 @@ static inline void board_smc91x_init(void)
 
 #endif
 
-static struct omap_board_config_kernel sdp2430_config[] __initdata = {
-   {OMAP_TAG_LCD, &sdp2430_lcd_config},
-};
-
 static void __init omap_2430sdp_init_early(void)
 {
omap2_init_common_infrastructure();
@@ -244,9 +301,6 @@ static void __init omap_2430sdp_init(void)
 
omap2430_mux_init(board_mux, OMAP_PACKAGE_ZAC);
 
-   omap_board_config = sdp2430_config;
-   omap_board_config_size = ARRAY_SIZE(sdp2430_config);
-
omap2430_i2c_init();
 
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
@@ -263,6 +317,8 @@ static void __init omap_2430sdp_init(void)
ret = gpio_request(SECONDARY_LCD_GPIO, "Secondary LCD backlight");
if (ret == 0)
gpio_direction_output(SECONDARY_LCD_GPIO, 0);
+
+   sdp2430_display_init();
 }
 
 static void __init omap_2430sdp_map_io(void)
-- 
1.7.4.1

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

[PATCH 2/6] OMAP: omap3touchbook: Remove unused lcd stuff

[Tomi Valkeinen]

board-omap3touchbook.c adds an LCD device, but the kernel doesn't
contain a driver for the device. So let's remove the unneeded LCD
device.

Signed-off-by: Tomi Valkeinen 
Cc: Gregoire Gentil 
---
 arch/arm/mach-omap2/board-omap3touchbook.c |   18 --
 1 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c 
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 127cb17..1c717a4 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -115,15 +115,6 @@ static struct omap2_hsmmc_info mmc[] = {
{}  /* Terminator */
 };
 
-static struct platform_device omap3_touchbook_lcd_device = {
-   .name   = "omap3touchbook_lcd",
-   .id = -1,
-};
-
-static struct omap_lcd_config omap3_touchbook_lcd_config __initdata = {
-   .ctrl_name  = "internal",
-};
-
 static struct regulator_consumer_supply touchbook_vmmc1_supply = {
.supply = "vmmc",
 };
@@ -181,12 +172,10 @@ static struct twl4030_gpio_platform_data 
touchbook_gpio_data = {
 
 static struct regulator_consumer_supply touchbook_vdac_supply = {
.supply = "vdac",
-   .dev= &omap3_touchbook_lcd_device.dev,
 };
 
 static struct regulator_consumer_supply touchbook_vdvi_supply = {
.supply = "vdvi",
-   .dev= &omap3_touchbook_lcd_device.dev,
 };
 
 /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
@@ -403,10 +392,6 @@ static struct platform_device keys_gpio = {
},
 };
 
-static struct omap_board_config_kernel omap3_touchbook_config[] __initdata = {
-   { OMAP_TAG_LCD, &omap3_touchbook_lcd_config },
-};
-
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -429,7 +414,6 @@ static void __init omap3_touchbook_init_irq(void)
 }
 
 static struct platform_device *omap3_touchbook_devices[] __initdata = {
-   &omap3_touchbook_lcd_device,
&leds_gpio,
&keys_gpio,
 };
@@ -510,8 +494,6 @@ static struct omap_musb_board_data musb_board_data = {
 static void __init omap3_touchbook_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
-   omap_board_config = omap3_touchbook_config;
-   omap_board_config_size = ARRAY_SIZE(omap3_touchbook_config);
 
pm_power_off = omap3_touchbook_poweroff;
 
-- 
1.7.4.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/6] OMAP: RX51: Remove unused old omapfb stuff

[Tomi Valkeinen]

RX51 uses the new DSS2 display driver, but the board file still
contained some code for the old omapfb driver. The old code can be
removed.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-rx51.c |   25 -
 1 files changed, 0 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index e964895..116e19b 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -75,29 +75,6 @@ static struct cpuidle_params rx51_cpuidle_params[] = {
{1, 7505, 15274, 484329},
 };
 
-static struct omap_lcd_config rx51_lcd_config = {
-   .ctrl_name  = "internal",
-};
-
-static struct omap_fbmem_config rx51_fbmem0_config = {
-   .size = 752 * 1024,
-};
-
-static struct omap_fbmem_config rx51_fbmem1_config = {
-   .size = 752 * 1024,
-};
-
-static struct omap_fbmem_config rx51_fbmem2_config = {
-   .size = 752 * 1024,
-};
-
-static struct omap_board_config_kernel rx51_config[] = {
-   { OMAP_TAG_FBMEM,   &rx51_fbmem0_config },
-   { OMAP_TAG_FBMEM,   &rx51_fbmem1_config },
-   { OMAP_TAG_FBMEM,   &rx51_fbmem2_config },
-   { OMAP_TAG_LCD, &rx51_lcd_config },
-};
-
 static void __init rx51_init_early(void)
 {
struct omap_sdrc_params *sdrc_params;
@@ -124,8 +101,6 @@ static struct omap_musb_board_data musb_board_data = {
 static void __init rx51_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
-   omap_board_config = rx51_config;
-   omap_board_config_size = ARRAY_SIZE(rx51_config);
omap3_pm_init_cpuidle(rx51_cpuidle_params);
omap_serial_init();
usb_musb_init(&musb_board_data);
-- 
1.7.4.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 0/6] OMAP: board file changes for DSS2 porting

[Tomi Valkeinen]

Hi Tony,

I posted last week a patch set porting most of the old omapfb OMAP2/3 drivers
to DSS2 (http://marc.info/?l=linux-fbdev&m=130451207802788&w=2). That patch set
contains changes to both the drivers and the board files, and it seems there is
already a minor conflict in them.

So I think it's simpler to divide the set into two parts, this one, which
contains the board file changes, and another containing the driver changes.
Merging will probably go easier if you can take this patch set via linux-omap,
and I'll take the driver changes via dss2 tree.

Applying this set without the driver changes will obviously disable the
displays of the affected boards until the drivers are also merged.

 Tomi


Tomi Valkeinen (6):
  OMAP: RX51: Remove unused old omapfb stuff
  OMAP: omap3touchbook: Remove unused lcd stuff
  OMAP: 2420SDP: Port the display driver to new DSS2
  OMAP: LDP: Port the display driver to new DSS2
  OMAP: H4: Port the display driver to new DSS2
  OMAP: Apollon: Port the display driver to new DSS2

 arch/arm/mach-omap2/board-2430sdp.c|   84 +++-
 arch/arm/mach-omap2/board-apollon.c|   34 +++
 arch/arm/mach-omap2/board-h4.c |   41 -
 arch/arm/mach-omap2/board-ldp.c|   73 +---
 arch/arm/mach-omap2/board-omap3touchbook.c |   18 --
 arch/arm/mach-omap2/board-rx51.c   |   25 
 6 files changed, 180 insertions(+), 95 deletions(-)

-- 
1.7.4.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 1/2] Initial B&N Nook Color (encore) support.

[Igor Grinberg]

Hi Oleg,

On 05/09/11 00:50, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
>
> Bare-bones board file, comes with serial console, gpio keys,
> MMC/SDCard and USB support.
>
> Signed-off-by: Oleg Drokin 
> ---

In general, here you should write the version history of your patch...

>  arch/arm/mach-omap2/Kconfig  |5 +
>  arch/arm/mach-omap2/Makefile |2 +
>  arch/arm/mach-omap2/board-omap3encore.c  |  363 
> ++
>  arch/arm/plat-omap/include/plat/uncompress.h |1 +
>  arch/arm/tools/mach-types|2 +-
>  5 files changed, 372 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-omap3encore.c
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index b997a35..5370561 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO
>for full description please see the products webpage at
>
> http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
>  
> +config MACH_ENCORE
> +bool "Barnes & Noble Encore (Nook Color)"
> +depends on ARCH_OMAP3
> +select OMAP_PACKAGE_CBP
> +
>  config MACH_OVERO
>   bool "Gumstix Overo board"
>   depends on ARCH_OMAP3
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index a0c2cae..619e5ca 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM)  += 
> board-omap3logic.o \
>  hsmmc.o
>  obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
>  hsmmc.o
> +obj-$(CONFIG_MACH_ENCORE)+= board-omap3encore.o \
> +hsmmc.o
>  obj-$(CONFIG_MACH_OVERO) += board-overo.o \
>  hsmmc.o
>  obj-$(CONFIG_MACH_OMAP3EVM)  += board-omap3evm.o \
> diff --git a/arch/arm/mach-omap2/board-omap3encore.c 
> b/arch/arm/mach-omap2/board-omap3encore.c
> new file mode 100644
> index 000..6c044c0
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3encore.c
> @@ -0,0 +1,363 @@
> +/*
> + * Support for Barns&Noble Nook Color
> + *
> + * Loosely based on mach-omap2/board-zoom.c
> + * Copyright (C) 2008-2010 Texas Instruments Inc.
> + *
> + * 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.
> + *
> + * May 2011 Oleg Drokin  - Port to 2.6.39
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mux.h"
> +#include "hsmmc.h"
> +#include "sdram-hynix-h8mbx00u0mer-0em.h"

Are all the above includes needed? (spi? maybe some others)

> +
> +/* Encore-specific device-info and i2c addresses. */
> +/* Battery, bus 1 */
> +#define MAX17042_I2C_SLAVE_ADDRESS   0x36
> +#define MAX17042_GPIO_FOR_IRQ100
> +
> +/*addition of MAXIM8903/TI GPIO mapping WRT schematics */
> +#define MAX8903_UOK_GPIO_FOR_IRQ 115
> +#define MAX8903_DOK_GPIO_FOR_IRQ 114
> +#define MAX8903_GPIO_CHG_EN  110
> +#define MAX8903_GPIO_CHG_STATUS  111
> +#define MAX8903_GPIO_CHG_FLT 101
> +#define MAX8903_GPIO_CHG_IUSB102
> +#define MAX8903_GPIO_CHG_USUS104
> +#define MAX8903_GPIO_CHG_ILM 61
> +
> +/* TI WLAN */
> +#define ENCORE_WIFI_PMENA_GPIO   22
> +#define ENCORE_WIFI_IRQ_GPIO 15
> +#define ENCORE_WIFI_EN_POW   16
> +
> +/* Accelerometer i2c bus 1*/
> +#define KXTF9_I2C_SLAVE_ADDRESS  0x0F
> +#define KXTF9_GPIO_FOR_PWR   34
> +#define KXTF9_GPIO_FOR_IRQ   113
> +
> +/* Touch screen i2c bus 2*/
> +#define CYTTSP_I2C_SLAVEADDRESS  34
> +#define ENCORE_CYTTSP_GPIO   99
> +#define ENCORE_CYTTSP_RESET_GPIO 46
> +
> +/* Audio codec, i2c bus 2 */
> +#define AUDIO_CODEC_POWER_ENABLE_GPIO103
> +#define AUDIO_CODEC_RESET_GPIO   37
> +#define AUDIO_CODEC_IRQ_GPIO 59
> +#define AIC3100_I2CSLAVEADDRESS  0x18
> +
> +
> +/* Different HW revisions */
> +#define BOARD_ENCORE_REV_EVT1A   0x1
> +#define BOARD_ENCORE_REV_EVT1B   0x2
> +#define BOARD_ENCORE_REV_EVT20x3
> +#define BOARD_ENCORE_REV_DVT 0x4
> +#define BOARD_ENCORE_REV_PVT 0x5
> +#define BOARD_ENCORE_REV_UNKNOWN 0x6
> +
> +static inline int is_encore_board_evt2(void)
> +{
> + return (system_rev >= BOARD_ENCORE_REV_EVT2);

No need for parentheses

> +}
> +
> +static inline i