Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs

[Munegowda, Keshava]

On Thu, May 12, 2011 at 4:58 PM, Igor Grinberg  wrote:
>
>
> On 05/12/11 13:49, Premi, Sanjeev wrote:
>
>>> -Original Message-
>>> From: linux-omap-ow...@vger.kernel.org
>>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>>> Munegowda, Keshava
>>> Sent: Wednesday, May 11, 2011 7:35 PM
>>> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>>> Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand;
>>> part...@india.ti.com
>>> Subject: [PATCH 3/5] arm: omap: usb: device name change for
>>> the clk names of usbhs
>> [snip]...[snip]
>>
>>> --- a/drivers/mfd/omap-usb-host.c
>>> +++ b/drivers/mfd/omap-usb-host.c
>>> @@ -27,7 +27,7 @@
>>>  #include 
>>>  #include 
>>>
>>> -#define USBHS_DRIVER_NAME   "usbhs-omap"
>>> +#define USBHS_DRIVER_NAME   "usbhs_omap"
>>>  #define OMAP_EHCI_DEVICE    "ehci-omap"
>>>  #define OMAP_OHCI_DEVICE    "ohci-omap3"
>>
>> [sp] Shouldn't we be consistent in using minus/dash and
>>      underscore in the device names?
>
> Also, can't we avoid once again changing the clock names
> (at least for a while...)?
> Is that really necessary? Can't hwmod use current clock names?
> Because, Linus is sooo happy each time he sees that kind of changes
>

This was actually earlier comment saying use _ as the convention for
hwmod and runtime pm.
only usbhs_omap uses the hwmod; the ehci and ohci drivers are children
of usbhsh and they get the
data from usbhs. Hence the older name of ehci and ochi drivers are
retained as it is.
  if it is really needed,  to change ehci and ohci driver names , then
i can make it as another patch.


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

[PATCH V4] OMAP3+: SR Layer Cleanup

[Shweta Gulati]

To set sr ntarget values  for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.

Tested on OMAP3630 SDP and OMAP4430 SDP Board

Signed-off-by: Shweta Gulati 
Acked by: Nishanth Menon 
Cc: Benoit Cousson 
Cc: Paul Walmsley 
---

V4:
  Fixed comments like checking for NULL pointers
  and following conventions in naming the instances
  recommended by Todd Poynor and Benoit Cousson.

V3:
   Changed the Subject and Rephrased Commit log as reviewed
   by Nishanth Menon.
 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..b1b11de 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_smartreflex_dev_attr sr1_dev_attr = {
+   .sensor_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_smartreflex_dev_attr sr2_dev_attr = {
+   .sensor_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),
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3e88dd3..78b6860 100644
--- a/arch/arm/mach-omap2/o

Re: beagleboardxm 2.6.39rc4 mcbsp problems.

[Peter Ujfalusi]

On Thursday 12 May 2011 21:43:20 Steve Calfee wrote:
> Since it is set to 0xF0F, doesn't this set it as master?

Sorry, that is correct, McBSP is configured as msater.

> Also, spelunking the kernel sources, I cannot seem to find the source
> for mcbsp_data->regs -- do you know where it gets set initially?

They configured within sound/soc/omap/omap-pcm.c

Have you configured the clk source, and divider correctly for McBSP port from 
the machine driver (with snd_soc_dai_set_sysclk)?

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

Re: [PATCH v2 0/7] OMAP: DSS2: DSI2 for secondary lcd panel on OMAP4

[Tomi Valkeinen]

On Thu, 2011-05-12 at 17:26 +0530, Archit Taneja wrote:
> OMAP4 has a DSI2 module, whose lanes are connected to the secondary lcd panel 
> on
> blaze and 4430sdp.
> Modify dsi.c driver to register and work multiple DSI devices. Make the
> necessary changes needed to introduce DSI2 PLL clocks.
> 
> Changes since v1:
> -Rename functions used for getting dsidev
> -Remove FEAT_DSS_DSI2
> -Rework debugfs usage for dsi
> 
> Applies over:
> 
> https://gitorious.org/linux-omap-dss2/linux/commits/master
> 
> Archit Taneja (7):
>   OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions
> exported by dsi
>   OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init()
>   OMAP: DSS2: Pass platform_device as an argument in dsi functions
>   OMAP: DSS2: DSI: Use platform_device pointer to get dsi data
>   OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs
>   OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4
>   OMAP: DSS2: Taal: Use device name in backlight_device_register
> 
>  drivers/video/omap2/displays/panel-taal.c |  124 +-
>  drivers/video/omap2/dss/core.c|6 +-
>  drivers/video/omap2/dss/dispc.c   |   16 +-
>  drivers/video/omap2/dss/dpi.c |   36 +-
>  drivers/video/omap2/dss/dsi.c | 1783 
> +
>  drivers/video/omap2/dss/dss.c |   44 +-
>  drivers/video/omap2/dss/dss.h |   45 +-
>  drivers/video/omap2/dss/dss_features.c|2 +
>  drivers/video/omap2/dss/dss_features.h|1 +
>  include/video/omapdss.h   |   39 +-
>  10 files changed, 1261 insertions(+), 835 deletions(-)

Thanks, applied.

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

[Oleg Drokin]

Hello!

On May 9, 2011, at 3:03 AM, Igor Grinberg wrote:

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

umm, ok.
Do you think the history of the changes is important in this case, though?
I mean it's mostly the case of "kill unneeded includes, fix style, fix 
incorrect mux package type" and so on.
Nothing of real interest to anybody.

>> +static void __init omap_encore_init(void)
>> +{
>> +omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> 
> You select CBP package in Kconfig, but pass CBB here?

Ah, indeed, thanks for catching this.

>> -nookcolor   MACH_NOOKCOLOR  NOOKCOLOR   3284
>> +encore  MACH_ENCORE ENCORE  
>> 3284
>> hkdkc100 MACH_HKDKC100   HKDKC1003285
>> ts42xx   MACH_TS42XX TS42XX  
>> 3286
>> aebl MACH_AEBL   AEBL3287
> 
> You should contact Russell for this kind of stuff.

Yes, I already did.
I am carrying it as part of the patch so that it's actually buildable while
awaiting for the decision.

> I don't think you should be patching it directly...
> If you want to tell us that your patch should be applied with this
> change to mach-types, then it would be better to make a separate
> patch for it and describe it in your cover letter.

Hm, ok.

Thanks for the feedback.

Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP3: set the core dpll clk rate in its set_rate function.

[Paul Walmsley]

On Mon, 9 May 2011, Avinash.H.M wrote:

> 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 

Acked-by: Paul Walmsley 

Thanks, let's see if we can get this into an -rc.


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

RE: [PATCH] rtc-twl: Switch to using threaded irq

[John Stultz]

On Thu, 2011-05-05 at 07:51 +, ilkka.koski...@nokia.com wrote:
> Hi,
> 
> Tony and John: What would be the appropriate path for this patch?

I'd probably push it through omap maintainer path, as its hardware
specific and can be better tested there.

thanks
-john


> On Apr 13, 2011 Krishnamoorthy, Balaji T  wrote:
> >On Wed, Mar 16, 2011 at 9:37 PM, Ilkka Koskinen
>  wrote:
> >>
> >> The driver is accessing to i2c bus in interrupt handler.
> >> Therefore, it should use threaded irq.
> 
> >Acked-by: Balaji T K 
> 
> >>
> >> Signed-off-by: Ilkka Koskinen 
> >> ---
> >>  drivers/rtc/rtc-twl.c |2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
> >> index ed1b868..2715b96 100644
> >> --- a/drivers/rtc/rtc-twl.c
> >> +++ b/drivers/rtc/rtc-twl.c
> >> @@ -475,7 +475,7 @@ static int __devinit twl_rtc_probe(struct 
> >> platform_device *pdev)
> >>if (ret < 0)
> >>goto out1;
> >>
> >> -   ret = request_irq(irq, twl_rtc_interrupt,
> >> +   ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
> >>IRQF_TRIGGER_RISING,
> >>dev_name(&rtc->dev), rtc);
> >>if (ret < 0) {
> >> --
> >> 1.7.0.4
> >>


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

[PATCH 4/4] omap: drop board-igep0030.c

[Mike Rapoport]

since it is merged into board-igep0020.c

Signed-off-by: Mike Rapoport 
---
 arch/arm/mach-omap2/Kconfig  |1 +
 arch/arm/mach-omap2/Makefile |2 -
 arch/arm/mach-omap2/board-igep0030.c |  438 --
 3 files changed, 1 insertions(+), 440 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-igep0030.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..19d5891 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -288,6 +288,7 @@ config MACH_IGEP0030
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
+   select MACH_IGEP0020
 
 config MACH_SBC3530
bool "OMAP3 SBC STALKER board"
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a0c2cae..186f482 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,8 +229,6 @@ obj-$(CONFIG_MACH_CM_T35)   += board-cm-t35.o \
 obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
 obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
   hsmmc.o
-obj-$(CONFIG_MACH_IGEP0030)+= board-igep0030.o \
-  hsmmc.o
 obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
   hsmmc.o
 obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
diff --git a/arch/arm/mach-omap2/board-igep0030.c 
b/arch/arm/mach-omap2/board-igep0030.c
deleted file mode 100644
index 83f6be2..000
--- a/arch/arm/mach-omap2/board-igep0030.c
+++ /dev/null
@@ -1,438 +0,0 @@
-/*
- * Copyright (C) 2010 - ISEE 2007 SL
- *
- * Modified from mach-omap2/board-generic.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "mux.h"
-#include "hsmmc.h"
-#include "sdram-numonyx-m65kam.h"
-#include "common-board-devices.h"
-
-#define IGEP3_GPIO_LED0_GREEN  54
-#define IGEP3_GPIO_LED0_RED53
-#define IGEP3_GPIO_LED1_RED16
-
-#define IGEP3_GPIO_WIFI_NPD138
-#define IGEP3_GPIO_WIFI_NRESET 139
-#define IGEP3_GPIO_BT_NRESET   137
-
-#define IGEP3_GPIO_USBH_NRESET  183
-
-
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
-   defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
-
-#define ONENAND_MAP 0x2000
-
-/*
- * x2 Flash built-in COMBO POP MEMORY
- * Since the device is equipped with two DataRAMs, and two-plane NAND
- * Flash memory array, these two component enables simultaneous program
- * of 4KiB. Plane1 has only even blocks such as block0, block2, block4
- * while Plane2 has only odd blocks such as block1, block3, block5.
- * So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
- */
-
-static struct mtd_partition igep3_onenand_partitions[] = {
-   {
-   .name   = "X-Loader",
-   .offset = 0,
-   .size   = 2 * (64*(2*2048))
-   },
-   {
-   .name   = "U-Boot",
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 6 * (64*(2*2048)),
-   },
-   {
-   .name   = "Environment",
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 2 * (64*(2*2048)),
-   },
-   {
-   .name   = "Kernel",
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 12 * (64*(2*2048)),
-   },
-   {
-   .name   = "File System",
-   .offset = MTDPART_OFS_APPEND,
-   .size   = MTDPART_SIZ_FULL,
-   },
-};
-
-static struct omap_onenand_platform_data igep3_onenand_pdata = {
-   .parts = igep3_onenand_partitions,
-   .nr_parts = ARRAY_SIZE(igep3_onenand_partitions),
-   .onenand_setup = NULL,
-   .dma_channel= -1,   /* disable DMA in OMAP OneNAND driver */
-};
-
-static struct platform_device igep3_onenand_device = {
-   .name   = "omap2-onenand",
-   .id = -1,
-   .dev = {
-   .platform_data = &igep3_onenand_pdata,
-   },
-};
-
-static void __init igep3_flash_init(void)
-{
-   u8 cs = 0;
-   u8 onenandcs = GPMC_CS_NUM + 1;
-
-   for (cs = 0; cs < GPMC_CS_NUM; cs++) {
-   u32 ret;
-   ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
-
-   /* Check if NAND/oneNAND is configured */
-   if ((ret & 0xC00) == 0x800)
-   /* NAND found */
-   pr_err("IGEP3: Unsupported NAND found\n");
-

[PATCH 3/4] omap: igep0020: add support for IGEP3

[Mike Rapoport]

Add IGEP3 machine support to board-igep0020

Signed-off-by: Mike Rapoport 
---
 arch/arm/mach-omap2/board-igep0020.c |  103 ++
 1 files changed, 80 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index ea7cbc6..0d6d583 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -55,6 +55,11 @@
 #define IGEP2_RC_GPIO_WIFI_NRESET  139
 #define IGEP2_RC_GPIO_BT_NRESET137
 
+#define IGEP3_GPIO_LED0_GREEN  54
+#define IGEP3_GPIO_LED0_RED53
+#define IGEP3_GPIO_LED1_RED16
+#define IGEP3_GPIO_USBH_NRESET  183
+
 /*
  * IGEP2 Hardware Revision Table
  *
@@ -69,6 +74,7 @@
 
 #define IGEP2_BOARD_HWREV_B0
 #define IGEP2_BOARD_HWREV_C1
+#define IGEP3_BOARD_HWREV  2
 
 static u8 hwrev;
 
@@ -76,6 +82,11 @@ static void __init igep2_get_revision(void)
 {
u8 ret;
 
+   if (machine_is_igep0030()) {
+   hwrev = IGEP3_BOARD_HWREV;
+   return;
+   }
+
omap_mux_init_gpio(IGEP2_GPIO_LED1_RED, OMAP_PIN_INPUT);
 
if (gpio_request_one(IGEP2_GPIO_LED1_RED, GPIOF_IN, "GPIO_HW0_REV")) {
@@ -332,24 +343,40 @@ static struct platform_device igep_led_device = {
 
 static void __init igep_leds_init(void)
 {
-   igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
-   igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
-   igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+   if (machine_is_igep0020()) {
+   igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+   igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+   igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+   } else {
+   igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+   igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+   igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+   }
 
platform_device_register(&igep_led_device);
 }
 
 #else
 static struct gpio igep_gpio_leds[] __initdata = {
-   { IGEP2_GPIO_LED0_RED,   GPIOF_OUT_INIT_LOW, "gpio-led:red:d0"   },
-   { IGEP2_GPIO_LED0_GREEN, GPIOF_OUT_INIT_LOW, "gpio-led:green:d0" },
-   { IGEP2_GPIO_LED1_RED,   GPIOF_OUT_INIT_LOW, "gpio-led:red:d1"   },
+   { -EINVAL,  GPIOF_OUT_INIT_LOW, "gpio-led:red:d0"   },
+   { -EINVAL,  GPIOF_OUT_INIT_LOW, "gpio-led:green:d0" },
+   { -EINVAL,  GPIOF_OUT_INIT_LOW, "gpio-led:red:d1"   },
 };
 
 static inline void igep_leds_init(void)
 {
int i;
 
+   if (machine_is_igep0020()) {
+   igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+   igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+   igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+   } else {
+   igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+   igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+   igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+   }
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning("IGEP v2: Could not obtain leds gpios\n");
return;
@@ -386,6 +413,9 @@ static int igep_twl_gpio_setup(struct device *dev,
igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
 #endif
 
+   if (machine_is_igep0030())
+   return 0;
+
/*
 * REVISIT: need ehci-omap hooks for external VBUS
 * power switch and overcurrent detect
@@ -548,18 +578,20 @@ static void __init igep_i2c_init(void)
 {
int ret;
 
-   /*
-* Bus 3 is attached to the DVI port where devices like the pico DLP
-* projector don't work reliably with 400kHz
-*/
-   ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
-   ARRAY_SIZE(igep2_i2c3_boardinfo));
-   if (ret)
-   pr_warning("IGEP2: Could not register I2C3 bus (%d)\n", ret);
-
-   igep_twldata.codec  = &igep2_codec_data;
-   igep_twldata.keypad = &igep2_keypad_pdata;
-   igep_twldata.vpll2  = &igep2_vpll2;
+   if (machine_is_igep0020()) {
+   /*
+* Bus 3 is attached to the DVI port where devices like the
+* pico DLP projector don't work reliably with 400kHz
+*/
+   ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
+   ARRAY_SIZE(igep2_i2c3_boardinfo));
+   if (ret)
+   pr_warning("IGEP2: Could not register I2C3 bus (%d)\n", 
ret);
+
+   igep_twldata.codec  = &igep2_codec_data;
+   igep_twldata.keypad = &igep2_keypad_pdata;
+   igep_twldata.vpll2  = &igep2_vpll2;
+   }
 
omap3_pmic_init("twl4030", &igep_twldata);
 }
@@ -575,6 +607,17 @@ static const struct usbhs_omap_board_data 
igep2_usbhs_bdata __initconst = {
.reset_gpio_port[2] = -EINVAL,
 };
 
+static const struct usbhs_omap_board_data igep

[PATCH 2/4] omap: igep0020: minor refactoring

[Mike Rapoport]

to allow easy addition of IGEP3

Signed-off-by: Mike Rapoport 
---
 arch/arm/mach-omap2/board-igep0020.c |   57 ++
 1 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index ad20f7b..ea7cbc6 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
 static struct gpio_led igep_gpio_leds[] = {
[0] = {
.name   = "gpio-led:red:d0",
-   .gpio   = IGEP2_GPIO_LED0_RED,
.default_trigger= "default-off"
},
[1] = {
.name   = "gpio-led:green:d0",
-   .gpio   = IGEP2_GPIO_LED0_GREEN,
.default_trigger= "default-off",
},
[2] = {
.name   = "gpio-led:red:d1",
-   .gpio   = IGEP2_GPIO_LED1_RED,
.default_trigger= "default-off",
},
[3] = {
@@ -335,6 +332,10 @@ static struct platform_device igep_led_device = {
 
 static void __init igep_leds_init(void)
 {
+   igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+   igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+   igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+
platform_device_register(&igep_led_device);
 }
 
@@ -347,14 +348,15 @@ static struct gpio igep_gpio_leds[] __initdata = {
 
 static inline void igep_leds_init(void)
 {
+   int i;
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning("IGEP v2: Could not obtain leds gpios\n");
return;
}
 
-   gpio_export(IGEP2_GPIO_LED0_RED, 0);
-   gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
-   gpio_export(IGEP2_GPIO_LED1_RED, 0);
+   for (i = 0; i < ARRAY_SIZE(igep_gpio_leds); i++)
+   gpio_export(igep_gpio_leds[i].gpio, 0);
 }
 #endif
 
@@ -372,6 +374,18 @@ static int igep_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
 
+   /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
+#if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
+   ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
+  "gpio-led:green:d1");
+   if (ret == 0)
+   gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
+   else
+   pr_warning("IGEP: Could not obtain gpio GPIO_LED1_GREEN\n");
+#else
+   igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
+#endif
+
/*
 * REVISIT: need ehci-omap hooks for external VBUS
 * power switch and overcurrent detect
@@ -385,18 +399,6 @@ static int igep_twl_gpio_setup(struct device *dev,
if (ret < 0)
pr_err("IGEP2: Could not obtain gpio for USBH_CPEN");
 
-   /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
-#if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
-   ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
-  "gpio-led:green:d1");
-   if (ret == 0)
-   gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
-   else
-   pr_warning("IGEP: Could not obtain gpio GPIO_LED1_GREEN\n");
-#else
-   igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
-#endif
-
return 0;
 };
 
@@ -531,11 +533,8 @@ static struct twl4030_platform_data igep_twldata = {
 
/* platform_data for children goes here */
.usb= &igep_usb_data,
-   .codec  = &igep2_codec_data,
.gpio   = &igep_twl4030_gpio_pdata,
-   .keypad = &igep2_keypad_pdata,
.vmmc1  = &igep_vmmc1,
-   .vpll2  = &igep2_vpll2,
.vio= &igep_vio,
 };
 
@@ -549,8 +548,6 @@ static void __init igep_i2c_init(void)
 {
int ret;
 
-   omap3_pmic_init("twl4030", &igep_twldata);
-
/*
 * Bus 3 is attached to the DVI port where devices like the pico DLP
 * projector don't work reliably with 400kHz
@@ -559,6 +556,12 @@ static void __init igep_i2c_init(void)
ARRAY_SIZE(igep2_i2c3_boardinfo));
if (ret)
pr_warning("IGEP2: Could not register I2C3 bus (%d)\n", ret);
+
+   igep_twldata.codec  = &igep2_codec_data;
+   igep_twldata.keypad = &igep2_keypad_pdata;
+   igep_twldata.vpll2  = &igep2_vpll2;
+
+   omap3_pmic_init("twl4030", &igep_twldata);
 }
 
 static const struct usbhs_omap_board_data igep2_usbhs_bdata __initconst = {
@@ -630,15 +633,11 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
-   omap_display_init(

[PATCH 1/4] omap: igep0020: name refactoring for future merge with IGEP3

[Mike Rapoport]

IGEP2 and IGEP3 boards are very similar and can be merged into one file.
Start refactoring with changing igep2 to igep where applicable.

Signed-off-by: Mike Rapoport 
---
 arch/arm/mach-omap2/board-igep0020.c |  158 +-
 1 files changed, 79 insertions(+), 79 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index c62c297e..ad20f7b 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -112,7 +112,7 @@ static void __init igep2_get_revision(void)
  * So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
  */
 
-static struct mtd_partition igep2_onenand_partitions[] = {
+static struct mtd_partition igep_onenand_partitions[] = {
{
.name   = "X-Loader",
.offset = 0,
@@ -140,21 +140,21 @@ static struct mtd_partition igep2_onenand_partitions[] = {
},
 };
 
-static struct omap_onenand_platform_data igep2_onenand_data = {
-   .parts = igep2_onenand_partitions,
-   .nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
+static struct omap_onenand_platform_data igep_onenand_data = {
+   .parts = igep_onenand_partitions,
+   .nr_parts = ARRAY_SIZE(igep_onenand_partitions),
.dma_channel= -1,   /* disable DMA in OMAP OneNAND driver */
 };
 
-static struct platform_device igep2_onenand_device = {
+static struct platform_device igep_onenand_device = {
.name   = "omap2-onenand",
.id = -1,
.dev = {
-   .platform_data = &igep2_onenand_data,
+   .platform_data = &igep_onenand_data,
},
 };
 
-static void __init igep2_flash_init(void)
+static void __init igep_flash_init(void)
 {
u8 cs = 0;
u8 onenandcs = GPMC_CS_NUM + 1;
@@ -166,7 +166,7 @@ static void __init igep2_flash_init(void)
/* Check if NAND/oneNAND is configured */
if ((ret & 0xC00) == 0x800)
/* NAND found */
-   pr_err("IGEP2: Unsupported NAND found\n");
+   pr_err("IGEP: Unsupported NAND found\n");
else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
if ((ret & 0x3F) == (ONENAND_MAP >> 24))
@@ -176,18 +176,18 @@ static void __init igep2_flash_init(void)
}
 
if (onenandcs > GPMC_CS_NUM) {
-   pr_err("IGEP2: Unable to find configuration in GPMC\n");
+   pr_err("IGEP: Unable to find configuration in GPMC\n");
return;
}
 
-   igep2_onenand_data.cs = onenandcs;
+   igep_onenand_data.cs = onenandcs;
 
-   if (platform_device_register(&igep2_onenand_device) < 0)
-   pr_err("IGEP2: Unable to register OneNAND device\n");
+   if (platform_device_register(&igep_onenand_device) < 0)
+   pr_err("IGEP: Unable to register OneNAND device\n");
 }
 
 #else
-static void __init igep2_flash_init(void) {}
+static void __init igep_flash_init(void) {}
 #endif
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
@@ -211,11 +211,11 @@ static inline void __init igep2_init_smsc911x(void)
 static inline void __init igep2_init_smsc911x(void) { }
 #endif
 
-static struct regulator_consumer_supply igep2_vmmc1_supply =
+static struct regulator_consumer_supply igep_vmmc1_supply =
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0");
 
 /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
-static struct regulator_init_data igep2_vmmc1 = {
+static struct regulator_init_data igep_vmmc1 = {
.constraints = {
.min_uV = 185,
.max_uV = 315,
@@ -226,13 +226,13 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies  = 1,
-   .consumer_supplies  = &igep2_vmmc1_supply,
+   .consumer_supplies  = &igep_vmmc1_supply,
 };
 
-static struct regulator_consumer_supply igep2_vio_supply =
+static struct regulator_consumer_supply igep_vio_supply =
REGULATOR_SUPPLY("vmmc_aux", "omap_hsmmc.1");
 
-static struct regulator_init_data igep2_vio = {
+static struct regulator_init_data igep_vio = {
.constraints = {
.min_uV = 180,
.max_uV = 180,
@@ -244,34 +244,34 @@ static struct regulator_init_data igep2_vio = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies  = 1,
-   .consumer_supplies  = &igep2_vio_supply,
+   .consumer_supplies  = &igep_vio_supply,
 };
 
-static struct regulator_consumer_supply igep2_vmmc2_supply =
+static struct regulator_consumer_supply igep_vmmc2_supply =
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1");
 
-static struct regulator_init_data igep2_vmmc2 = {
+static st

[PATCH 0/4] omap: merge IGEP v2 and v3

[Mike Rapoport]

Hi Tony,

This is yet another attempt to reduce code duplication in the board files :)
Only build tested, since I don't have the hardware, so I belive an Ack from
Enric is required.

Mike Rapoport (4):
  omap: igep0020: name refactoring for future merge with IGEP3
  omap: igep0020: minor refactoring
  omap: igep0020: add support for IGEP3
  omap: drop board-igep0030.c

 arch/arm/mach-omap2/Kconfig  |1 +
 arch/arm/mach-omap2/Makefile |2 -
 arch/arm/mach-omap2/board-igep0020.c |  286 +-
 arch/arm/mach-omap2/board-igep0030.c |  438 --
 4 files changed, 174 insertions(+), 553 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-igep0030.c

-- 
1.7.3.1

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

Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled

[Nishanth Menon]

On 12:58-20110512, Todd Poynor wrote:
> On Fri, May 13, 2011 at 12:46:17AM +0530, Premi, Sanjeev wrote:
> > > -Original Message-
> > > From: Menon, Nishanth 
> ...
> > > Last I tried, with Vishwa's dvfs branch on panda without voltage
> > > registrations, things could crash :( if I get some time I will try to
> > > port Vishwa's series onto kevin's branch as well and test and provide
> > > any patches necessary.
> > 
> > [sp] I can try this on Panda. Will be able to get one tomorrow.
> 
> In case it helps, below is what I use for Panda.
> 
> ---
> ARM: OMAP2 voltage: Don't die if board does not register voltage params
> 
> This allows the DVFS patches to boot on boards not yet modified to
> register voltage params.
> 
> Signed-off-by: Todd Poynor 
> ---
>  arch/arm/mach-omap2/voltage.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> index dbc1cfe..8f23d95 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -617,6 +617,12 @@ static void __init omap4_vc_init(struct omap_vdd_info 
> *vdd)
>   struct clk *sys_ck;
>   u32 sys_clk_speed;
>  
> + if (!vdd->board_data) {
> + pr_warning("%s: No voltage board params registered for 
> vdd_%s\n",
> +__func__, vdd->voltdm.name);
> + return;
> + }
> +
>   sys_ck = clk_get(NULL, "sys_clkin_ck");
>   if (IS_ERR(sys_ck)) {
>   pr_warning("%s: Could not get the sys clk to calculate"
looks around the right place.. but, which branch is this based on?
cant see board_data on linus master..

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe 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:pm: Fix boot-time errors with debugfs disabled

[Todd Poynor]

On Fri, May 13, 2011 at 12:46:17AM +0530, Premi, Sanjeev wrote:
> > -Original Message-
> > From: Menon, Nishanth 
...
> > Last I tried, with Vishwa's dvfs branch on panda without voltage
> > registrations, things could crash :( if I get some time I will try to
> > port Vishwa's series onto kevin's branch as well and test and provide
> > any patches necessary.
> 
> [sp] I can try this on Panda. Will be able to get one tomorrow.

In case it helps, below is what I use for Panda.

---
ARM: OMAP2 voltage: Don't die if board does not register voltage params

This allows the DVFS patches to boot on boards not yet modified to
register voltage params.

Signed-off-by: Todd Poynor 
---
 arch/arm/mach-omap2/voltage.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index dbc1cfe..8f23d95 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -617,6 +617,12 @@ static void __init omap4_vc_init(struct omap_vdd_info *vdd)
struct clk *sys_ck;
u32 sys_clk_speed;
 
+   if (!vdd->board_data) {
+   pr_warning("%s: No voltage board params registered for 
vdd_%s\n",
+  __func__, vdd->voltdm.name);
+   return;
+   }
+
sys_ck = clk_get(NULL, "sys_clkin_ck");
if (IS_ERR(sys_ck)) {
pr_warning("%s: Could not get the sys clk to calculate"
-- 
1.7.3.1


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

RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled

[Premi, Sanjeev]

 

> -Original Message-
> From: Menon, Nishanth 
> Sent: Thursday, May 12, 2011 11:32 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] omap:pm: Fix boot-time errors with 
> debugfs disabled
> 
> On Thu, May 12, 2011 at 12:36, Sanjeev Premi  wrote:
> > There is an implicit assumption in current implementation that
> > debugfs is always enabled.
> thanks for doing this.
> >
> > When debugfs is disabled, these errors are noticed during boot:
> >  omap_voltage_late_init: Unable to create voltage debugfs main dir
> >  vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
> >  vdd_debugfs_init: Unable to create debugfs directory for vdd_core
> >
> > This patch fixes these errors by enclosing code related to debugfs
> > in #ifdef CONFIG_DEBUG_FS..#endif.
> 
> generic - couple of comments - I think the #defs should be isolated
> off to headers - maybe the right approach may be to move the debugfs

[sp] None of the code encapsulated here is "header" material.
 I guess you have seen the patch below.

> entries off to a separate file? or pm-debug.c??

[sp] I wish it was all debug code. It is "operational" code.
 Check the Kconfig in plat-omap. Smartreflex is not even expected
 to work without debugfs. Though I believe much of the data put in
 debugfs can be in local lists/structures.

 That was supposed to be my next set of patches - as I understand 
 the implementation better.
> 
> >
> > Boot tested on OMAP3EVM.
> >
> > Signed-off-by: Sanjeev Premi 
> > ---
> >  Patch was created and tested on the pm branch at commit:
> >   d695569 : rebuild PM from branches
> 
> Could I suggest Kevin's volt cleanup series - based off _c branch if
> there are cleanups to be done?

[sp] I didn't see it updated for 5 weeks. hence used this.
 but patch should apply cleanly...

> 
> >
> >  I am still finding my way around new code sructure. Haven't
> >  been able to verify if smartreflex and voltage layer are
> >  properly initialized. Though I do understand that smartreflex
> >  won't work without debugfs.
> >
> 
> Last I tried, with Vishwa's dvfs branch on panda without voltage
> registrations, things could crash :( if I get some time I will try to
> port Vishwa's series onto kevin's branch as well and test and provide
> any patches necessary.

[sp] I can try this on Panda. Will be able to get one tomorrow.

~sanjeev

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

DSS2: Simultaneous DSI and DPI panels

[Juha Kuikka]

Hello,

I was wondering if it would be possible to run DPI and DSI interfaces
simultaneously with OMAP3 (DM3730).

Limitations:
- DSI would have to be in video mode (data to DSI phy through video
port with H/VSYNC signaling, OMAP_DSS_PARALLELMODE_BYPASS)
- DSI PLL would need to be used for clock source
- Both the DPI and DSI panels would have to accept identical clocking
(PCLK, blanking intervals etc).
- Data lane # must match.
- And of course same data would go to both

I realize the current SW does not support this, but I'm more wondering
if it is possible from the HW point of view because it seems to me
that data out from DISPC is pretty much identical in both cases.

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

Re: [RFC PATCH v3] Consolidate SRAM support

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:45 Thu 12 May , Russell King - ARM Linux wrote:
> On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
> This is work in progress.
> 
> We have two SoCs using SRAM, both with their own allocation systems,
> and both with their own ways of copying functions into the SRAM.
> 
> Let's unify this before we have additional SoCs re-implementing this
> obviously common functionality themselves.
> 
> Unfortunately, we end up with code growth through doing this, but that
> will become a win when we have another SoC using this (which I know
> there's at least one in the pipeline).
> 
> One of the considerations here is that we can easily convert sram-pool.c
> to hook into device tree stuff, which can tell the sram allocator:
>   - physical address of sram
>   - size of sram
>   - allocation granularity
> and then we just need to ensure that it is appropriately mapped.
> 
> This uses the physical address, and unlike Davinci's dma address usage,
> it always wants to have the physical address, and will always return
> the corresponding physical address when passed that pointer.
> 
> OMAP could probably do with some more work to make the omapfb and other
> allocations use the sram allocator, rather than hooking in before the
> sram allocator is initialized - and then further cleanups so that we
> have an initialization function which just does
> 
> sram_create(phys, size)
>   virt = map sram(phys, size)
>   create sram pool(virt, phys, size, min_alloc_order)
> 
> Another question is whether we should allow multiple SRAM pools or not -
> this code does allow multiple pools, but so far we only have one pool
> per SoC.  Overdesign?  Maybe, but it prevents SoCs wanting to duplicate
> it if they want to partition the SRAM, or have peripheral-local SRAMs.
> 
> Lastly, uio_pruss should probably take the SRAM pool pointer via
> platform data so that it doesn't have to include Davinci specific
> includes.
> 
> Signed-off-by: Russell King 
> ---
> 
> This version fixes the davinci pm free, and adds updates for the
> davinci pcm driver.  As I don't know what's happening with Jean's
> patch tweaking the genpool allocator, I've kept my version.
> 
> This still suffers from the "only one region per pvpool" problem
> which I believe Jean's patch doesn't suffer.
yes excatly and on at91sam9263 I need this :(

Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe 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: beagleboardxm 2.6.39rc4 mcbsp problems.

[Steve Calfee]

On 05/12/11 04:01, Peter Ujfalusi wrote:
> On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
>> Of course for this you need to use omap as a master and codec as a
>> slave. One example for this is sound/soc/omap/omap3pandora.c.
>>
>>  static struct omap_board_mux board_mux[] __initdata = {
>> +OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> +OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +
> 
> I think the CLKX, FSX need to be input, since the config suggests,t that 
> McBSP1 is the slave port:
> 
>> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
> 

Hi, thanks for trying to help.

I already tried that, but it still did not xmit. Now I wonder about
master/slave. I thought that the omap is set up as a master. I looked at
PCR0 docs in the tech ref manual and I get:

11 FSXM Transmit Frame-Synchronization Mode RW 0x0
0x0: Frame-synchronization signal derived from an
external source
0x1: Frame synchronization is determined by the SRG
frame-synchronization mode bit FSGM in SRGR2.
10 FSRM Receive Frame-Synchronization Mode RW 0x0
0x0: Frame-Synchronization pulses generated by an
external device. FSR is an input pin.
0x1: Frame synchronization generated internally by SRG.
FSR is an output pin except when GSYNC=1 in SRGR.
Etc.

Since it is set to 0xF0F, doesn't this set it as master?

Also, spelunking the kernel sources, I cannot seem to find the source
for mcbsp_data->regs -- do you know where it gets set initially?


--
To unsubscribe from this list: send the line "unsubscribe 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:pm: Fix boot-time errors with debugfs disabled

[Menon, Nishanth]

On Thu, May 12, 2011 at 12:36, Sanjeev Premi  wrote:
> There is an implicit assumption in current implementation that
> debugfs is always enabled.
thanks for doing this.
>
> When debugfs is disabled, these errors are noticed during boot:
>  omap_voltage_late_init: Unable to create voltage debugfs main dir
>  vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
>  vdd_debugfs_init: Unable to create debugfs directory for vdd_core
>
> This patch fixes these errors by enclosing code related to debugfs
> in #ifdef CONFIG_DEBUG_FS..#endif.

generic - couple of comments - I think the #defs should be isolated
off to headers - maybe the right approach may be to move the debugfs
entries off to a separate file? or pm-debug.c??

>
> Boot tested on OMAP3EVM.
>
> Signed-off-by: Sanjeev Premi 
> ---
>  Patch was created and tested on the pm branch at commit:
>   d695569 : rebuild PM from branches

Could I suggest Kevin's volt cleanup series - based off _c branch if
there are cleanups to be done?

>
>  I am still finding my way around new code sructure. Haven't
>  been able to verify if smartreflex and voltage layer are
>  properly initialized. Though I do understand that smartreflex
>  won't work without debugfs.
>

Last I tried, with Vishwa's dvfs branch on panda without voltage
registrations, things could crash :( if I get some time I will try to
port Vishwa's series onto kevin's branch as well and test and provide
any patches necessary.


>  arch/arm/mach-omap2/smartreflex.c |   15 +++
>  arch/arm/mach-omap2/voltage.c     |    8 
>  2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c 
> b/arch/arm/mach-omap2/smartreflex.c
> index 2ce2fb7..b757632 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -54,7 +54,9 @@ struct omap_sr {
>        struct list_head                node;
>        struct omap_sr_nvalue_table     *nvalue_table;
>        struct voltagedomain            *voltdm;
> +#ifdef CONFIG_DEBUG_FS
>        struct dentry                   *dbg_dir;
> +#endif
>  };
>
>  /* sr_list contains all the instances of smartreflex module */
> @@ -826,7 +828,9 @@ static int __init omap_sr_probe(struct platform_device 
> *pdev)
>        struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
>        struct omap_sr_data *pdata = pdev->dev.platform_data;
>        struct resource *mem, *irq;
> +#ifdef CONFIG_DEBUG_FS
>        struct dentry *vdd_dbg_dir, *nvalue_dir;
> +#endif
>        struct omap_volt_data *volt_data;
>        int i, ret = 0;
>
> @@ -903,6 +907,7 @@ static int __init omap_sr_probe(struct platform_device 
> *pdev)
>         * If the voltage domain debugfs directory is not created, do
>         * not try to create rest of the debugfs entries.
>         */
> +#ifdef CONFIG_DEBUG_FS
>        vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info->voltdm);
>        if (!vdd_dbg_dir) {
>                ret = -EINVAL;
> @@ -952,14 +957,22 @@ static int __init omap_sr_probe(struct platform_device 
> *pdev)
>                (void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
>                                &(sr_info->nvalue_table[i].nvalue));
>        }
> +#else
> +       omap_voltage_get_volttable(sr_info->voltdm, &volt_data);
> +       if (!volt_data) {
> +               ret = -ENODATA;
> +       }
> +#endif /* CONFIG_DEBUG_FS */
>
>        return ret;
>
> +#ifdef CONFIG_DEBUG_FS
>  err_debugfs:
>        debugfs_remove_recursive(sr_info->dbg_dir);
>  err_iounmap:
>        list_del(&sr_info->node);
>        iounmap(sr_info->base);
> +#endif
>  err_release_region:
>        release_mem_region(mem->start, resource_size(mem));
>  err_free_devinfo:
> @@ -988,8 +1001,10 @@ static int __devexit omap_sr_remove(struct 
> platform_device *pdev)
>
>        if (sr_info->autocomp_active)
>                sr_stop_vddautocomp(sr_info);
> +#ifdef CONFIG_DEBUG_FS
>        if (sr_info->dbg_dir)
>                debugfs_remove_recursive(sr_info->dbg_dir);
> +#endif
>
>        list_del(&sr_info->node);
>        iounmap(sr_info->base);
> diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
> index 9ef3789..6153211 100644
> --- a/arch/arm/mach-omap2/voltage.c
> +++ b/arch/arm/mach-omap2/voltage.c
> @@ -250,6 +250,7 @@ static void __init vp_init(struct omap_vdd_info *vdd)
>        vdd->write_reg(vp_val, prm_mod_offs, vdd->vp_data->vlimitto);
>  }
>
> +#ifdef CONFIG_DEBUG_FS
>  static void __init vdd_debugfs_init(struct omap_vdd_info *vdd)
>  {
>        char *name;
> @@ -297,6 +298,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info 
> *vdd)
>                                vdd->debug_dir, (void *) vdd,
>                                &nom_volt_debug_fops);
>  }
> +#endif
>
>  /* Voltage scale and accessory APIs */
>  static int _pre_volt_scale(struct omap_vdd_info *vdd,
> @@ -980,6 +982,7 @@ int omap_voltage_register_pmic(struct voltagedomain 
> *voltdm,
>  * add any

[RFC PATCH v3] Consolidate SRAM support

[Russell King - ARM Linux]

On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote:
This is work in progress.

We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.

Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.

Unfortunately, we end up with code growth through doing this, but that
will become a win when we have another SoC using this (which I know
there's at least one in the pipeline).

One of the considerations here is that we can easily convert sram-pool.c
to hook into device tree stuff, which can tell the sram allocator:
- physical address of sram
- size of sram
- allocation granularity
and then we just need to ensure that it is appropriately mapped.

This uses the physical address, and unlike Davinci's dma address usage,
it always wants to have the physical address, and will always return
the corresponding physical address when passed that pointer.

OMAP could probably do with some more work to make the omapfb and other
allocations use the sram allocator, rather than hooking in before the
sram allocator is initialized - and then further cleanups so that we
have an initialization function which just does

sram_create(phys, size)
virt = map sram(phys, size)
create sram pool(virt, phys, size, min_alloc_order)

Another question is whether we should allow multiple SRAM pools or not -
this code does allow multiple pools, but so far we only have one pool
per SoC.  Overdesign?  Maybe, but it prevents SoCs wanting to duplicate
it if they want to partition the SRAM, or have peripheral-local SRAMs.

Lastly, uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.

Signed-off-by: Russell King 
---

This version fixes the davinci pm free, and adds updates for the
davinci pcm driver.  As I don't know what's happening with Jean's
patch tweaking the genpool allocator, I've kept my version.

This still suffers from the "only one region per pvpool" problem
which I believe Jean's patch doesn't suffer.

 arch/arm/Kconfig|2 +
 arch/arm/common/Kconfig |4 ++
 arch/arm/common/Makefile|1 +
 arch/arm/common/pv-pool.c   |   69 +++
 arch/arm/include/asm/pv-pool.h  |   20 
 arch/arm/mach-davinci/da850.c   |2 +-
 arch/arm/mach-davinci/dm355.c   |2 +-
 arch/arm/mach-davinci/dm365.c   |2 +-
 arch/arm/mach-davinci/dm644x.c  |2 +-
 arch/arm/mach-davinci/dm646x.c  |2 +-
 arch/arm/mach-davinci/include/mach/common.h |2 +-
 arch/arm/mach-davinci/include/mach/sram.h   |   13 +
 arch/arm/mach-davinci/pm.c  |   20 +++-
 arch/arm/mach-davinci/sram.c|   42 +++--
 arch/arm/plat-mxc/Kconfig   |2 +-
 arch/arm/plat-mxc/include/mach/iram.h   |   24 +++--
 arch/arm/plat-mxc/iram_alloc.c  |   50 +---
 arch/arm/plat-omap/include/plat/sram.h  |   17 ---
 arch/arm/plat-omap/sram.c   |   34 +-
 drivers/uio/uio_pruss.c |7 ++-
 sound/soc/davinci/davinci-pcm.c |9 ++--
 21 files changed, 182 insertions(+), 144 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 903c9c4..7a4a625 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -862,6 +862,7 @@ config ARCH_DAVINCI
bool "TI DaVinci"
select GENERIC_CLOCKEVENTS
select ARCH_REQUIRE_GPIOLIB
+   select PV_POOL
select ZONE_DMA
select HAVE_IDE
select CLKDEV_LOOKUP
@@ -875,6 +876,7 @@ config ARCH_OMAP
select HAVE_CLK
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+   select PV_POOL
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index ea5ee4d..abee3ca 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -39,3 +39,7 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
bool
+
+config PV_POOL
+   bool
+   select GENERIC_ALLOCATOR
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 6ea9b6f..4ae455e 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_ARCH_IXP2000)+= uengine.o
 obj-$(CONFIG_ARCH_IXP23XX) += uengine.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)  += timer-sp.o
+obj-$(CONFIG_PV_POOL)  += pv-pool.o
diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c
index e69de29..748367a 100644
--- a/arch/arm/common/pv-pool.c
+++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt 

Re: [PATCH V3] OMAP3+: SR Layer Cleanup

[Menon, Nishanth]

On Thu, May 12, 2011 at 04:50, Kevin Hilman  wrote:
> "Menon, Nishanth"  writes:
>
>> On Wed, May 11, 2011 at 04:12, Shweta Gulati  wrote:
>>> To set sr ntarget values  for all volt_domain,
>>> volt_table is retrieved by doing a look_up of 'vdd_name'
>>> field from omap_hwmod but voltage domain pointer does not
>>> belong to omap_hwmod and is not used anywhere else.
>>> As a part of voltage layer and SR Layer clean up volt
>>> pointer is removed from omap_hwmod and added in dev
>>> attributes of SR.
>>>
>>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>>
>>> Signed-off-by: Shweta Gulati 
>>> Cc: Nishanth Menon 
>>> ---
>>> V3:
>>>   Changed the Subject and Rephrased Commit log as reviewed
>>>   by Nishanth Menon.
>>>  V2:
>>>   Rebased on latest 'pm-wip/voltdm_a' branch.
>> thanks.. actually it applies on voltdm_c branch as well :)
>
> Can this be taken as an Ack?  if so, Shweta please add an Acked-by from
> Nishanth in your updated patch.  Thanks.
yep - will merge the next rev and do a dry run as well..

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe 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:pm: Fix boot-time errors with debugfs disabled

[Sanjeev Premi]

There is an implicit assumption in current implementation that
debugfs is always enabled.

When debugfs is disabled, these errors are noticed during boot:
  omap_voltage_late_init: Unable to create voltage debugfs main dir
  vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
  vdd_debugfs_init: Unable to create debugfs directory for vdd_core

This patch fixes these errors by enclosing code related to debugfs
in #ifdef CONFIG_DEBUG_FS..#endif.

Boot tested on OMAP3EVM.

Signed-off-by: Sanjeev Premi 
---
 Patch was created and tested on the pm branch at commit:
   d695569 : rebuild PM from branches

 I am still finding my way around new code sructure. Haven't
 been able to verify if smartreflex and voltage layer are
 properly initialized. Though I do understand that smartreflex
 won't work without debugfs.

 arch/arm/mach-omap2/smartreflex.c |   15 +++
 arch/arm/mach-omap2/voltage.c |8 
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex.c 
b/arch/arm/mach-omap2/smartreflex.c
index 2ce2fb7..b757632 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -54,7 +54,9 @@ struct omap_sr {
struct list_headnode;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain*voltdm;
+#ifdef CONFIG_DEBUG_FS
struct dentry   *dbg_dir;
+#endif
 };
 
 /* sr_list contains all the instances of smartreflex module */
@@ -826,7 +828,9 @@ static int __init omap_sr_probe(struct platform_device 
*pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev->dev.platform_data;
struct resource *mem, *irq;
+#ifdef CONFIG_DEBUG_FS
struct dentry *vdd_dbg_dir, *nvalue_dir;
+#endif
struct omap_volt_data *volt_data;
int i, ret = 0;
 
@@ -903,6 +907,7 @@ static int __init omap_sr_probe(struct platform_device 
*pdev)
 * If the voltage domain debugfs directory is not created, do
 * not try to create rest of the debugfs entries.
 */
+#ifdef CONFIG_DEBUG_FS
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info->voltdm);
if (!vdd_dbg_dir) {
ret = -EINVAL;
@@ -952,14 +957,22 @@ static int __init omap_sr_probe(struct platform_device 
*pdev)
(void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
&(sr_info->nvalue_table[i].nvalue));
}
+#else
+   omap_voltage_get_volttable(sr_info->voltdm, &volt_data);
+   if (!volt_data) {
+   ret = -ENODATA;
+   }
+#endif /* CONFIG_DEBUG_FS */
 
return ret;
 
+#ifdef CONFIG_DEBUG_FS
 err_debugfs:
debugfs_remove_recursive(sr_info->dbg_dir);
 err_iounmap:
list_del(&sr_info->node);
iounmap(sr_info->base);
+#endif
 err_release_region:
release_mem_region(mem->start, resource_size(mem));
 err_free_devinfo:
@@ -988,8 +1001,10 @@ static int __devexit omap_sr_remove(struct 
platform_device *pdev)
 
if (sr_info->autocomp_active)
sr_stop_vddautocomp(sr_info);
+#ifdef CONFIG_DEBUG_FS
if (sr_info->dbg_dir)
debugfs_remove_recursive(sr_info->dbg_dir);
+#endif
 
list_del(&sr_info->node);
iounmap(sr_info->base);
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 9ef3789..6153211 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -250,6 +250,7 @@ static void __init vp_init(struct omap_vdd_info *vdd)
vdd->write_reg(vp_val, prm_mod_offs, vdd->vp_data->vlimitto);
 }
 
+#ifdef CONFIG_DEBUG_FS
 static void __init vdd_debugfs_init(struct omap_vdd_info *vdd)
 {
char *name;
@@ -297,6 +298,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info 
*vdd)
vdd->debug_dir, (void *) vdd,
&nom_volt_debug_fops);
 }
+#endif
 
 /* Voltage scale and accessory APIs */
 static int _pre_volt_scale(struct omap_vdd_info *vdd,
@@ -980,6 +982,7 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
  * add any debug entry for a particular voltage domain. Returns NULL
  * in case of error.
  */
+#ifdef CONFIG_DEBUG_FS
 struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm)
 {
struct omap_vdd_info *vdd;
@@ -993,6 +996,7 @@ struct dentry *omap_voltage_get_dbgdir(struct voltagedomain 
*voltdm)
 
return vdd->debug_dir;
 }
+#endif
 
 /**
  * omap_change_voltscale_method() - API to change the voltage scaling method.
@@ -1078,16 +1082,20 @@ int __init omap_voltage_late_init(void)
return -EINVAL;
}
 
+#ifdef CONFIG_DEBUG_FS
voltage_dir = debugfs_create_dir("voltage", NULL);
if (IS_ERR(voltage_dir))
pr_err("%s: Unable to create voltage debugfs main dir\n",
__func__);
+#endif

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

[Janorkar, Mayuresh]

> -Original Message-
> From: Valkeinen, Tomi
> Sent: Thursday, May 12, 2011 6:57 PM
> To: Janorkar, Mayuresh
> Cc: linux-omap@vger.kernel.org; K, Mythri P
> Subject: Re: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP
> board file
> 
> On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
> > 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 v3:
> > All GPIOs are requested here and assigned to init value.
> >
> > Changes since v2:
> >  Changed GPIO names to power_on, emu_done and pwrgood
> >
> >  arch/arm/mach-omap2/board-4430sdp.c |   59
> +++
> >  1 files changed, 59 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
> > index 570e83f..7078037
> > --- 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,
> > +};
> 
> It's better to define all the gpio numbers with defines, like you do for
> the power_on and display_select gpios. And use the defines in the gpios
> array below.
> 
> > +
> > +static void sdp4430_picodlp_init(void)
> > +{
> > +   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"},
> > +   {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
> > +   "DLP EMU DONE"},
> > +   {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
> > +   "DLP PWRGOOD"},
> > +   };
> > +
> > +   status = gpio_request_array(picodlp_gpios,
> ARRAY_SIZE(picodlp_gpios));
> > +   if (status)
> > +   pr_err("Cannot request OMAP4_DLP_GPIOs, error %d\n", status);
> > +
> > +   gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
> > +   gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
> > +   gpio_set_value(sdp4430_picodlp_pdata.pwrgood_gpio, 1);
> 
> gpio_request_array already sets the gpio values as defined in the gpios
> array.
> 
> Why do you set pwrgood to 1?

Look fine. Even the spec says that this should be kept low in case of power 
down.

> 
>  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 v4 4/4] OMAP: DSS: Add picodlp panel driver

[Tomi Valkeinen]

On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
> 
> > -Original Message-
> > From: Valkeinen, Tomi
> > Sent: Thursday, May 12, 2011 7:58 PM
> > To: Janorkar, Mayuresh
> > Cc: linux-omap@vger.kernel.org; K, Mythri P
> > Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
> > 
> > On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
> > > 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).
> > >
> > > Based on original design from Mythri P K 
> > >
> > > The power-up sequence consists of:
> > > Setting PWRGOOD to a logic low state. Once power is stable and thus the
> > ++
> > >  3 files changed, 622 insertions(+), 0 deletions(-)
> > >  create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
> 
> 
> 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include "panel-picodlp.h"
> > > +
> > > +#define DRIVER_NAME  "picodlp_i2c_driver"
> > > +
> > > +#define MAX_TRIAL_VALUE  100
> > 
> > I'll repeat my comment from previous review round:
> > 
> > The name of this define is not descriptive and you use this define in
> > two places which have nothing to do with each other. I think it's better
> > just to use the value where it's needed.
> 
> I think it looks more readable if we have a MACRO.
> But as they are used at only couple of places I would remove these MACROs.

Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.

If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.

Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.

It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.

> > 
> > > +struct picodlp_data {
> > > + struct mutex lock;
> 
> 
> > > +static int picodlp_i2c_remove(struct i2c_client *client)
> > > +{
> > > + struct picodlp_i2c_data *picodlp_i2c_data =
> > > + i2c_get_clientdata(client);
> > > +
> > > + kfree(picodlp_i2c_data);
> > > + i2c_unregister_device(client);
> > 
> > You add the i2c device in the dss probe function, but unregister it in
> > i2c remove function. That's probably not right. These things should
> > usually be symmetric, and the unregister should be at the dss remove
> > function.
> > 
> Isnt it good to have a remove function removing i2c_client?

Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?

 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 4/6] OMAP: LDP: Port the display driver to new DSS2

[Tomi Valkeinen]

On Thu, 2011-05-12 at 20:20 +0530, Janorkar, Mayuresh wrote:
> 
> > -Original Message-
> > From: Valkeinen, Tomi
> > Sent: Thursday, May 12, 2011 8:17 PM
> > To: Janorkar, Mayuresh
> > Cc: Igor Grinberg; linux-omap@vger.kernel.org; Stanley Miao
> > Subject: RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> > 
> > On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote:
> > > > -Original Message-
> > > > From: Valkeinen, Tomi
> > > > Sent: Thursday, May 12, 2011 5:18 PM
> > > > To: Igor Grinberg
> > > > Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
> > > > Stanley Miao
> > > > Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new
> > DSS2
> > > >
> > > > On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
> > > >
> > > > > Right. Do both fixes make it work?
> > > > >
> > > > > If it is, then Tomi,
> > > > > will you add both fixes to the patch set with our SOBs?
> > > > > or do you want this to be sent properly as a follow up?
> > > >
> > > > Yes, I can add these all to the same patch and handle it through DSS
> > > > tree. Although due to the reluctance to make changes to
> > arch/arm/*omap*,
> > > > I guess we'll pass these patches in this merge window.
> > > >
> > > > Mayuresh, if you're able to test this and it works, can you send me
> > the
> > > > full diff so that I don't make any mistakes combining the code?
> > > >
> > > >  Tomi
> > > >
> > >
> > > Please find the patch below.
> > > I have also attached the same.
> > >
> > > There are formatting problems with this patch. But this can be used as a
> > reference.
> > >
> > > I have verified bootup with Penguins on LDP board.
> > 
> > Why did you create a new panel for LDP? The generic panel driver should
> > handle it well enough.
> > 
> > The attached panel driver is also quite messed up. It does things that
> > belong to the board file, and the timings are a bit high, giving refresh
> > rate of 120MHz. Does LDP have a 120MHz panel?
> 
> You can use that code as reference and not as a patch.
> Please take a look at changes in board file.
> There is no need to create a new panel. It can be added as a part of generic 
> panel.

Well, the board file is also rather messed up. The board file is using
gpios that are not reserved anywhere, it's missing Igor's TWL GPIO setup
code, the panel driver requests some of the GPIOs but doesn't check
error values, so we don't know if it succeeds or not. etc.

So the patch doesn't tell us much even if LDP display seems to work with
it.

But I'll try to cook up with a proper patch at some point.

 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 v4 4/4] OMAP: DSS: Add picodlp panel driver

[Janorkar, Mayuresh]

> -Original Message-
> From: Valkeinen, Tomi
> Sent: Thursday, May 12, 2011 7:58 PM
> To: Janorkar, Mayuresh
> Cc: linux-omap@vger.kernel.org; K, Mythri P
> Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
> 
> On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
> > 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).
> >
> > Based on original design from Mythri P K 
> >
> > The power-up sequence consists of:
> > Setting PWRGOOD to a logic low state. Once power is stable and thus the
> ++
> >  3 files changed, 622 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/video/omap2/displays/panel-picodlp.c



> > +
> > +#include 
> > +#include 
> > +
> > +#include "panel-picodlp.h"
> > +
> > +#define DRIVER_NAME"picodlp_i2c_driver"
> > +
> > +#define MAX_TRIAL_VALUE100
> 
> I'll repeat my comment from previous review round:
> 
> The name of this define is not descriptive and you use this define in
> two places which have nothing to do with each other. I think it's better
> just to use the value where it's needed.

I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.

> 
> > +struct picodlp_data {
> > +   struct mutex lock;


> > +static int picodlp_i2c_remove(struct i2c_client *client)
> > +{
> > +   struct picodlp_i2c_data *picodlp_i2c_data =
> > +   i2c_get_clientdata(client);
> > +
> > +   kfree(picodlp_i2c_data);
> > +   i2c_unregister_device(client);
> 
> You add the i2c device in the dss probe function, but unregister it in
> i2c remove function. That's probably not right. These things should
> usually be symmetric, and the unregister should be at the dss remove
> function.
> 
Isnt it good to have a remove function removing i2c_client?

I will add this sequence at dss_remove

> > +   return 0;
> > +}


> > +* then only i2c commands can be successfully sent to dpp2600
> > +*/
> > +   msleep(510);
> > +   if (omapdss_dpi_display_enable(dssdev)) {
> > +   dev_err(&dssdev->dev, "failed to enable DPI\n");
> > +   goto err;
> > +   }
> > +   dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> > +
> > +   picodlp_i2c_data =
> > +   i2c_get_clientdata(picod->picodlp_i2c_client);
> > +
> > +   if (!picodlp_i2c_data) {
> > +   dev_err(&dssdev->dev, "could not find picodlp i2c data\n");
> > +   goto err;
> 
> If you goto err here, you have to call dpi_display_disable.
> 
> I think it's simpler if you get the picodlp_i2c_data somewhere in the
> beginning of this function. That way you can bail out if it's NULL
> before doing any HW writes.

That looks to be the BEST approach.

> 
> > +   }
> > +   r = picodlp_i2c_init(picod->picodlp_i2c_client);
> > +   if (r)
> > +   goto err;
> 
> And same here.

Yes, I would add dpi_display_disable at err label.

> 
> > +
> > +   return r;
> > +err:
> > +   if (dssdev->platform_disable)
> > +   dssdev->platform_disable(dssdev);
> > +
> > +   return r;
> > +}
> > +
> > +static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
> > +{
> > +   struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
> > +
> > +   omapdss_dpi_display_disable(dssdev);


> > +
> > +   picod->picodlp_i2c_client = picodlp_i2c_client;
> > +
> > +   picodlp_i2c_data =
> > +   i2c_get_clientdata(picod->picodlp_i2c_client);
> > +
> > +   if (!picodlp_i2c_data) {
> > +   dev_err(&dssdev->dev, "could not fine picodlp i2c data");
> > +   r = -ENODEV;
> > +   goto err;
> > +   }
> 
> You shouldn't use picodlp_i2c_data here. You don't need it and there's
> no guarantee that the i2c probe has been ran yet.
> 
> It's enough to check it at power_on.

Looks fine.

> 
> > +   dev_set_drvdata(&dssdev->dev, picod);
> > +   return r;
> > +
> > +err:
> > +   kfree(picod);
> > +   return r;
> > +}
> > +
> > +static void picodlp_panel_remove(struct omap_dss_device *dssdev)
> > +{
> > +   struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
> > +
> > +   dev_set_drvdata(&dssdev->dev, NULL);
> > +   dev_dbg(&dssdev->dev, "removing picodlp panel\n");
> > +   return r;
> > +}
> > +
> > +static void __exit picodlp_exit(void)
> > +{
> > +   i2c_del_driver(&picodlp_i2c_driver);
> > +   omap_dss_unregister_driver(&picodlp_driver);
> > +}
> 
> These two could be the other way around. I'm not sure it affects the
> removal, but it's usually safer to do things in reverse order.

Looks fine.

> 
>  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 4/6] OMAP: LDP: Port the display driver to new DSS2

[Janorkar, Mayuresh]

> -Original Message-
> From: Valkeinen, Tomi
> Sent: Thursday, May 12, 2011 8:17 PM
> To: Janorkar, Mayuresh
> Cc: Igor Grinberg; linux-omap@vger.kernel.org; Stanley Miao
> Subject: RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> 
> On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote:
> > > -Original Message-
> > > From: Valkeinen, Tomi
> > > Sent: Thursday, May 12, 2011 5:18 PM
> > > To: Igor Grinberg
> > > Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
> > > Stanley Miao
> > > Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new
> DSS2
> > >
> > > On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
> > >
> > > > Right. Do both fixes make it work?
> > > >
> > > > If it is, then Tomi,
> > > > will you add both fixes to the patch set with our SOBs?
> > > > or do you want this to be sent properly as a follow up?
> > >
> > > Yes, I can add these all to the same patch and handle it through DSS
> > > tree. Although due to the reluctance to make changes to
> arch/arm/*omap*,
> > > I guess we'll pass these patches in this merge window.
> > >
> > > Mayuresh, if you're able to test this and it works, can you send me
> the
> > > full diff so that I don't make any mistakes combining the code?
> > >
> > >  Tomi
> > >
> >
> > Please find the patch below.
> > I have also attached the same.
> >
> > There are formatting problems with this patch. But this can be used as a
> reference.
> >
> > I have verified bootup with Penguins on LDP board.
> 
> Why did you create a new panel for LDP? The generic panel driver should
> handle it well enough.
> 
> The attached panel driver is also quite messed up. It does things that
> belong to the board file, and the timings are a bit high, giving refresh
> rate of 120MHz. Does LDP have a 120MHz panel?

You can use that code as reference and not as a patch.
Please take a look at changes in board file.
There is no need to create a new panel. It can be added as a part of generic 
panel.

I have taken timings info from: drivers/video/omap/lcd_ldp.c

#ifdef CONFIG_FB_OMAP_LCD_VGA
#define LCD_XRES480
#define LCD_YRES640
#define LCD_PIXCLOCK_MAX41700
#else
#define LCD_XRES240
#define LCD_YRES320
#define LCD_PIXCLOCK_MAX185186
#endif


> 
>  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 4/6] OMAP: LDP: Port the display driver to new DSS2

[Tomi Valkeinen]

On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote:
> > -Original Message-
> > From: Valkeinen, Tomi
> > Sent: Thursday, May 12, 2011 5:18 PM
> > To: Igor Grinberg
> > Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
> > Stanley Miao
> > Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> > 
> > On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
> > 
> > > Right. Do both fixes make it work?
> > >
> > > If it is, then Tomi,
> > > will you add both fixes to the patch set with our SOBs?
> > > or do you want this to be sent properly as a follow up?
> > 
> > Yes, I can add these all to the same patch and handle it through DSS
> > tree. Although due to the reluctance to make changes to arch/arm/*omap*,
> > I guess we'll pass these patches in this merge window.
> > 
> > Mayuresh, if you're able to test this and it works, can you send me the
> > full diff so that I don't make any mistakes combining the code?
> > 
> >  Tomi
> > 
> 
> Please find the patch below.
> I have also attached the same.
> 
> There are formatting problems with this patch. But this can be used as a 
> reference.
> 
> I have verified bootup with Penguins on LDP board.

Why did you create a new panel for LDP? The generic panel driver should
handle it well enough.

The attached panel driver is also quite messed up. It does things that
belong to the board file, and the timings are a bit high, giving refresh
rate of 120MHz. Does LDP have a 120MHz panel?

 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 4/6] OMAP: LDP: Port the display driver to new DSS2

[Janorkar, Mayuresh]

> -Original Message-
> From: Valkeinen, Tomi
> Sent: Thursday, May 12, 2011 5:18 PM
> To: Igor Grinberg
> Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
> Stanley Miao
> Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> 
> On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
> 
> > Right. Do both fixes make it work?
> >
> > If it is, then Tomi,
> > will you add both fixes to the patch set with our SOBs?
> > or do you want this to be sent properly as a follow up?
> 
> Yes, I can add these all to the same patch and handle it through DSS
> tree. Although due to the reluctance to make changes to arch/arm/*omap*,
> I guess we'll pass these patches in this merge window.
> 
> Mayuresh, if you're able to test this and it works, can you send me the
> full diff so that I don't make any mistakes combining the code?
> 
>  Tomi
> 

Please find the patch below.
I have also attached the same.

There are formatting problems with this patch. But this can be used as a 
reference.

I have verified bootup with Penguins on LDP board.

>From 1f3470d3d792721bf5aa4d060c1cf79f5a587497 Mon Sep 17 00:00:00 2001
From: Mayuresh Janorkar 
Date: Thu, 12 May 2011 18:53:46 +0530
Subject: [PATCH] LDP Tomi patch

---
 arch/arm/mach-omap2/board-ldp.c  |   87 ++--
 drivers/video/omap2/displays/Kconfig |5 +
 drivers/video/omap2/displays/Makefile|1 +
 drivers/video/omap2/displays/panel-ldp.c |  223 ++
 4 files changed, 305 insertions(+), 11 deletions(-)
 mode change 100644 => 100755 arch/arm/mach-omap2/board-ldp.c
 create mode 100755 drivers/video/omap2/displays/panel-ldp.c

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
old mode 100644
new mode 100755
index e2ba779..fa6327a
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 
 #include "board-flash.h"
 #include "mux.h"
@@ -53,6 +54,11 @@
 #define LDP_SMSC911X_GPIO  152
 #define DEBUG_BASE 0x0800
 #define LDP_ETHR_START DEBUG_BASE
+#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 struct resource ldp_smsc911x_resources[] = {
[0] = {
@@ -275,19 +281,78 @@ 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,
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO   8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO  5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+   printk(KERN_INFO "\n LDP:: sdp3430_display_init ");
+return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   int status;
+   return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   lcd_enabled = 0;
+
+   gpio_direction_output(enable_gpio, 0);
+   gpio_direction_output(backlight_gpio, 0);
+
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+}
+
+static struct omap_dss_device sdp3430_lcd_device = {
+   .name   = "lcd",
+   .driver_name= "ldp_panel",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .phy.dpi.data_lines = 16,
+   .platform_enable= sdp3430_panel_enable_lcd,
+   .platform_disable   = sdp3430_panel_disable_lcd,
 };
 
-static struct omap_lcd_config ldp_lcd_config __initdata = {
-   .ctrl_name  = "internal",
+static struct omap_dss_device *sdp3430_dss_devices[] = {
+   &sdp3430_lcd_device,
 };
 
-static struct omap_board_config_kernel ldp_config[] __initdata = {
-   { OMAP_TAG_LCD, &ldp_lcd_config },
+static struct omap_dss_board_info sdp3430_dss_data = {
+   .num_devices= ARRAY_SIZE(sdp3430_dss_devices),
+   .devices= sdp3430_dss_devices,
+   .default_device = &sdp3430_lcd_device,
 };
 
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
+REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
+REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
+
+static struct regulator_init_data sdp3430_vpll2 = {
+.constraints = {
+.name   = "VDVI",
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV   = true,
+.valid_modes_mask   = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHA

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

[Tomi Valkeinen]

On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
> 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).
> 
> Based on original design from Mythri P K 
> 
> 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 
> Signed-off-by: Mythri P K 
> ---
> Changes since v3:
>   msleep moved to appropriate place
>   gpio requests moved to board file
> 
> 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 |  614 
> ++
>  3 files changed, 622 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..8dd8651
> --- /dev/null
> +++ b/drivers/video/omap2/displays/panel-picodlp.c
> @@ -0,0 +1,614 @@
> +/*
> + * 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"
> +
> +#define MAX_TRIAL_VALUE  100

I'll repeat my comment from previous review round:

The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.

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

Re: [PATCH v2 1/4] MFD: TWL6025: add phoenix lite support to twl6030

[Mark Brown]

On Thu, May 12, 2011 at 02:27:55PM +0100, Graeme Gregory wrote:
> Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the
> same feature set of twl6030 but with small changes. The codec block has
> also been removed. It also has a new charger block and new features in
> its ADC block. VUSB handling also differs.

Reviewed-by: Mark Brown 

> + pdata->driver_data = (void *)features;
> +

You never need to cast to void, and doing needless casts can mask bugs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] REGULATOR: TWL6025: add support to twl-regulator

[Graeme Gregory]

Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.

The names of the regulators also changed.

The DCDCs of the 6025 are software controllable as well.

Since V1

Use the features variable passed via platform data instead of calling
global function.

Change the very switch like if statements to be a more readable
switch statement.

Signed-off-by: Graeme Gregory 
---
 drivers/regulator/twl-regulator.c |  414 +---
 1 files changed, 379 insertions(+), 35 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 2a808c2..51f28cc 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -51,8 +51,13 @@ struct twlreg_info {
u16 min_mV;
u16 max_mV;
 
+   u8  flags;
+
/* used by regulator core */
struct regulator_desc   desc;
+
+   /* chip specific features */
+   unsigned long   features;
 };
 
 
@@ -70,6 +75,7 @@ struct twlreg_info {
 #define VREG_TRANS 1
 #define VREG_STATE 2
 #define VREG_VOLTAGE   3
+#define VREG_VOLTAGE_DCDC  4
 /* TWL6030 Misc register offsets */
 #define VREG_BC_ALL1
 #define VREG_BC_REF2
@@ -87,6 +93,17 @@ struct twlreg_info {
 #define TWL6030_CFG_STATE_APP(v)   (((v) & TWL6030_CFG_STATE_APP_MASK) >>\
TWL6030_CFG_STATE_APP_SHIFT)
 
+/* Flags for DCDC Voltage reading */
+#define DCDC_OFFSET_EN BIT(0)
+#define DCDC_EXTENDED_EN   BIT(1)
+
+/* twl6025 SMPS EPROM values */
+#define TWL6030_SMPS_OFFSET0xB0
+#define TWL6030_SMPS_MULT  0xB3
+#define SMPS_MULTOFFSET_SMPS4  BIT(0)
+#define SMPS_MULTOFFSET_VIOBIT(1)
+#define SMPS_MULTOFFSET_SMPS3  BIT(6)
+
 static inline int
 twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
 {
@@ -144,11 +161,15 @@ static int twl6030reg_is_enabled(struct regulator_dev 
*rdev)
struct twlreg_info  *info = rdev_get_drvdata(rdev);
int grp, val;
 
-   grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
-   if (grp < 0)
-   return grp;
+   if (!(info->features & TWL6025_SUBCLASS)) {
+   grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+   if (grp < 0)
+   return grp;
 
-   grp &= P1_GRP_6030;
+   grp &= P1_GRP_6030;
+   } else {
+   grp = 1;
+   }
 
val = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_STATE);
val = TWL6030_CFG_STATE_APP(val);
@@ -159,19 +180,22 @@ static int twl6030reg_is_enabled(struct regulator_dev 
*rdev)
 static int twlreg_enable(struct regulator_dev *rdev)
 {
struct twlreg_info  *info = rdev_get_drvdata(rdev);
-   int grp;
-   int ret;
+   int grp = 0;
+   int ret = 0;
 
-   grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
-   if (grp < 0)
-   return grp;
+   if (!(twl_class_is_6030() && (info->features & TWL6025_SUBCLASS))) {
+   grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+   if (grp < 0)
+   return grp;
 
-   if (twl_class_is_4030())
-   grp |= P1_GRP_4030;
-   else
-   grp |= P1_GRP_6030;
+   if (twl_class_is_4030())
+   grp |= P1_GRP_4030;
+   else
+   grp |= P1_GRP_6030;
 
-   ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+   ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+   VREG_GRP, grp);
+   }
 
if (!ret && twl_class_is_6030())
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
@@ -186,29 +210,34 @@ static int twlreg_enable(struct regulator_dev *rdev)
 static int twlreg_disable(struct regulator_dev *rdev)
 {
struct twlreg_info  *info = rdev_get_drvdata(rdev);
-   int grp;
-   int ret;
-
-   grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
-   if (grp < 0)
-   return grp;
-
-   /* For 6030, set the off state for all grps enabled */
-   if (twl_class_is_6030()) {
-   ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
-   (grp & (P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030)) <<
-   TWL6030_CFG_STATE_GRP_SHIFT |
-   TWL6030_CFG_STATE_OFF);
+   int grp = 0;
+   int ret = 0;
+
+   if (!(twl_class_is_6030() && (info->featu

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

[Graeme Gregory]

The twl6025 uses a different regulator for USB than the 6030 so select
the correct regulator name depending on the subclass of device.

Since V1

Use features passed via platform data instead of global variable.

Signed-off-by: Graeme Gregory 
---
 drivers/usb/otg/twl6030-usb.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6e920de..2ad69a4 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -99,6 +99,7 @@ struct twl6030_usb {
u8  linkstat;
u8  asleep;
boolirq_enabled;
+   unsigned long   features;
 };
 
 #define xceiv_to_twl(x)container_of((x), struct twl6030_usb, 
otg)
@@ -190,6 +191,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 +207,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;
 
@@ -395,6 +402,7 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
twl->dev= &pdev->dev;
twl->irq1   = platform_get_irq(pdev, 0);
twl->irq2   = platform_get_irq(pdev, 1);
+   twl->features   = pdata->features;
twl->otg.dev= twl->dev;
twl->otg.label  = "twl6030";
twl->otg.set_host   = twl6030_set_host;
-- 
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 v2 1/4] MFD: TWL6025: add phoenix lite support to twl6030

[Graeme Gregory]

Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the
same feature set of twl6030 but with small changes. The codec block has
also been removed. It also has a new charger block and new features in
its ADC block. VUSB handling also differs.

Since V1

Pass the twl features variable to other drivers via platform data instead
of exporting a get function from a global variable.

Signed-off-by: Graeme Gregory 
---
 drivers/mfd/twl-core.c  |  190 +-
 include/linux/i2c/twl.h |   34 +
 2 files changed, 187 insertions(+), 37 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 2bd9e06..b8f2a4e 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -198,6 +198,7 @@
 #define TWL6030_BASEADD_GASGAUGE   0x00C0
 #define TWL6030_BASEADD_PIH0x00D0
 #define TWL6030_BASEADD_CHARGER0x00E0
+#define TWL6025_BASEADD_CHARGER0x00DA
 
 /* subchip/slave 2 0x4A - DFT */
 #define TWL6030_BASEADD_DIEID  0x00C0
@@ -331,6 +332,7 @@ static struct twl_mapping twl6030_map[] = {
 
{ SUB_CHIP_ID0, TWL6030_BASEADD_RTC },
{ SUB_CHIP_ID0, TWL6030_BASEADD_MEM },
+   { SUB_CHIP_ID1, TWL6025_BASEADD_CHARGER },
 };
 
 /*--*/
@@ -604,7 +606,7 @@ static inline struct device *add_child(unsigned chip, const 
char *name,
 static struct device *
 add_regulator_linked(int num, struct regulator_init_data *pdata,
struct regulator_consumer_supply *consumers,
-   unsigned num_consumers)
+   unsigned num_consumers, unsigned long features)
 {
unsigned sub_chip_id;
/* regulator framework demands init_data ... */
@@ -616,6 +618,8 @@ add_regulator_linked(int num, struct regulator_init_data 
*pdata,
pdata->num_consumer_supplies = num_consumers;
}
 
+   pdata->driver_data = (void *)features;
+
/* NOTE:  we currently ignore regulator IRQs, e.g. for short circuits */
sub_chip_id = twl_map[TWL_MODULE_PM_MASTER].sid;
return add_numbered_child(sub_chip_id, "twl_reg", num,
@@ -623,9 +627,10 @@ add_regulator_linked(int num, struct regulator_init_data 
*pdata,
 }
 
 static struct device *
-add_regulator(int num, struct regulator_init_data *pdata)
+add_regulator(int num, struct regulator_init_data *pdata,
+   unsigned long features)
 {
-   return add_regulator_linked(num, pdata, NULL, 0);
+   return add_regulator_linked(num, pdata, NULL, 0, features);
 }
 
 /*
@@ -705,17 +710,20 @@ add_children(struct twl4030_platform_data *pdata, 
unsigned long features)
};
 
child = add_regulator_linked(TWL4030_REG_VUSB1V5,
- &usb_fixed, &usb1v5, 1);
+ &usb_fixed, &usb1v5, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
 
child = add_regulator_linked(TWL4030_REG_VUSB1V8,
- &usb_fixed, &usb1v8, 1);
+ &usb_fixed, &usb1v8, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
 
child = add_regulator_linked(TWL4030_REG_VUSB3V1,
- &usb_fixed, &usb3v1, 1);
+ &usb_fixed, &usb3v1, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
 
@@ -740,9 +748,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned 
long features)
}
if (twl_has_usb() && pdata->usb && twl_class_is_6030()) {
 
-   static struct regulator_consumer_supply usb3v3 = {
-   .supply =   "vusb",
-   };
+   static struct regulator_consumer_supply usb3v3;
+   int regulator;
 
if (twl_has_regulator()) {
/* this is a template that gets copied */
@@ -755,12 +762,22 @@ add_children(struct twl4030_platform_data *pdata, 
unsigned long features)
| REGULATOR_CHANGE_STATUS,
};
 
-   child = add_regulator_linked(TWL6030_REG_VUSB,
- &usb_fixed, &usb3v3, 1);
+   if (features & TWL6025_SUBCLASS) {
+   usb3v3.supply = "ldousb";
+   regulator = TWL6025_REG_LDOUSB;
+   } else {
+

[PATCH v2 2/4] MFD: TWL6030: fix irq definitions

[Graeme Gregory]

The charger fault IRQs from the twl will in future patches be handled
by a seperate IRQ handler in the charger driver than the general charger
IRQ. Give them different IRQ numbers now to allow the charger driver to
be merged in the future.

Signed-off-by: Graeme Gregory 
---
 drivers/mfd/twl6030-irq.c |4 ++--
 include/linux/i2c/twl.h   |1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index dfbae34..eb3b5f8 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -76,8 +76,8 @@ static int twl6030_interrupt_mapping[24] = {
USBOTG_INTR_OFFSET, /* Bit 18   ID  */
USB_PRES_INTR_OFFSET,   /* Bit 19   VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20   CHRG_CTRL   */
-   CHARGER_INTR_OFFSET,/* Bit 21   EXT_CHRG*/
-   CHARGER_INTR_OFFSET,/* Bit 22   INT_CHRG*/
+   CHARGERFAULT_INTR_OFFSET,   /* Bit 21   EXT_CHRG*/
+   CHARGERFAULT_INTR_OFFSET,   /* Bit 22   INT_CHRG*/
RSV_INTR_OFFSET,/* Bit 23   Reserved*/
 };
 /*--*/
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index d70e704..ba4f886 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -91,6 +91,7 @@
 #define BCI_INTR_OFFSET2
 #define MADC_INTR_OFFSET   3
 #define USB_INTR_OFFSET4
+#define CHARGERFAULT_INTR_OFFSET 5
 #define BCI_PRES_INTR_OFFSET   9
 #define USB_PRES_INTR_OFFSET   10
 #define RTC_INTR_OFFSET11
-- 
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 v2 0/4] Add support for twl6025 PMIC

[Graeme Gregory]

This patch series starts to add support for the twl6025 chip to the
twl driver. This series contains patches for the MFD device and the
regulator device to support the twl6025.

Since V1

Series has been altered to pass features via platform data rather
than via a get function on a global variable.
Regulator style was change so some ifs were replaced with switch.
There has been some discussion about regulator definition and naming
and TI have agreed to take on the cleanup internally.

Graeme

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

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

[Tomi Valkeinen]

On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
> 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 v3:
>   All GPIOs are requested here and assigned to init value.
> 
> Changes since v2:
>Changed GPIO names to power_on, emu_done and pwrgood
> 
>  arch/arm/mach-omap2/board-4430sdp.c |   59 
> +++
>  1 files changed, 59 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 570e83f..7078037
> --- 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_GPIO  27  /* LCD Backlight GPIO */
> +#define OMAP4_DLP_POWER_ON_GPIO  40
> +#define OMAP4_DLP_DISPLAY_SELECT_GPIO59
>  /* PWM2 and TOGGLE3 register offsets */
>  #define LED_PWM2ON   0x03
>  #define LED_PWM2OFF  0x04
> @@ -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,
> +};

It's better to define all the gpio numbers with defines, like you do for
the power_on and display_select gpios. And use the defines in the gpios
array below.

> +
> +static void sdp4430_picodlp_init(void)
> +{
> + 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"},
> + {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
> + "DLP EMU DONE"},
> + {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
> + "DLP PWRGOOD"},
> + };
> +
> + status = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
> + if (status)
> + pr_err("Cannot request OMAP4_DLP_GPIOs, error %d\n", status);
> +
> + gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
> + gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
> + gpio_set_value(sdp4430_picodlp_pdata.pwrgood_gpio, 1);

gpio_request_array already sets the gpio values as defined in the gpios
array.

Why do you set pwrgood to 1?

 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 V3] OMAP3+: SR Layer Cleanup

[Gulati, Shweta]

Hi,

On Thu, May 12, 2011 at 6:19 PM, Gulati, Shweta  wrote:
> Hi,
>
> On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit  wrote:
>> Hi Shweta,
>>
>> On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
>>>
>>> To set sr ntarget values  for all volt_domain,
>>> volt_table is retrieved by doing a look_up of 'vdd_name'
>>> field from omap_hwmod but voltage domain pointer does not
>>> belong to omap_hwmod and is not used anywhere else.
>>> As a part of voltage layer and SR Layer clean up volt
>>> pointer is removed from omap_hwmod and added in dev
>>> attributes of SR.
>>>
>>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>>
>>> Signed-off-by: Shweta Gulati
>>> Cc: Nishanth Menon
>>> ---
>>> V3:
>>>    Changed the Subject and Rephrased Commit log as reviewed
>>>    by Nishanth Menon.
>>>  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 ---
>>
>> Since this patch is touching some hwmod files, it will be good to Cc Paul
>> and me. It is far from obvious from the subject that hwmod data are involved
>> in this patch.
> Will do
>>>  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",
>>> -   

Re: [PATCH RESEND] omap : nand : fix subpage ecc issue with prefetch

[Artem Bityutskiy]

On Wed, 2011-05-11 at 21:17 +0530, Kishore Kadiyala wrote:
> 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 
> Cc: sta...@kernel.org [2.6.35+]

Pushed to l2-mtd-2.6.git, thanks.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

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

[Gulati, Shweta]

Hi,

On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit  wrote:
> Hi Shweta,
>
> On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
>>
>> To set sr ntarget values  for all volt_domain,
>> volt_table is retrieved by doing a look_up of 'vdd_name'
>> field from omap_hwmod but voltage domain pointer does not
>> belong to omap_hwmod and is not used anywhere else.
>> As a part of voltage layer and SR Layer clean up volt
>> pointer is removed from omap_hwmod and added in dev
>> attributes of SR.
>>
>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>
>> Signed-off-by: Shweta Gulati
>> Cc: Nishanth Menon
>> ---
>> V3:
>>    Changed the Subject and Rephrased Commit log as reviewed
>>    by Nishanth Menon.
>>  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 ---
>
> Since this patch is touching some hwmod files, it will be good to Cc Paul
> and me. It is far from obvious from the subject that hwmod data are involved
> in this patch.
Will do
>>  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 om

Re: [PATCH V3] OMAP3+: SR Layer Cleanup

[Gulati, Shweta]

Kevin,

On Thu, May 12, 2011 at 3:20 PM, Kevin Hilman  wrote:
> "Menon, Nishanth"  writes:
>
>> On Wed, May 11, 2011 at 04:12, Shweta Gulati  wrote:
>>> To set sr ntarget values  for all volt_domain,
>>> volt_table is retrieved by doing a look_up of 'vdd_name'
>>> field from omap_hwmod but voltage domain pointer does not
>>> belong to omap_hwmod and is not used anywhere else.
>>> As a part of voltage layer and SR Layer clean up volt
>>> pointer is removed from omap_hwmod and added in dev
>>> attributes of SR.
>>>
>>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>>
>>> Signed-off-by: Shweta Gulati 
>>> Cc: Nishanth Menon 
>>> ---
>>> V3:
>>>   Changed the Subject and Rephrased Commit log as reviewed
>>>   by Nishanth Menon.
>>>  V2:
>>>   Rebased on latest 'pm-wip/voltdm_a' branch.
>> thanks.. actually it applies on voltdm_c branch as well :)
>
> Can this be taken as an Ack?  if so, Shweta please add an Acked-by from
> Nishanth in your updated patch.  Thanks.
>
>> might be
>> good if kevin where to roll it up
>
> Yes, I'll pick this one up (after Todd's comments are addressed.)
I would address all the comments and post updated version soon, thanks.
> Kevin
>
>



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

Re: [RFC PATCHv4 0/7] HSI framework and drivers

[Govindraj]

On Tue, Mar 22, 2011 at 3:20 PM, Carlos Chinea  wrote:
> Hi,
>
> On Mon, 2011-03-21 at 09:16 +0100, ext Linus Walleij wrote:
>> 2010/12/14 Carlos Chinea :
>>
>> > Here you have the fourth round of the HSI framework patches.
>>
>> I'd like to notify that this out-of-tree framework is also in use for
>> the ST-Ericsson
>> Ux500s, and we've had great success with it. You can add my:
>>
>> Acked-by: Linus Walleij 
>>
>

Hi Carlos,

Will you posting a next version of HSI framework.

I am planning to adapt omap-hsi driver to this framework.

--
Thanks,
Govindraj.R


> Thanks I will add the Ack to the next round of patches.
>
> We are currently working on the hsi_char module. Apart from addressing
> the comments from Alan,  we are planning to drop also the non-blocking
> support from it. The current version is not fully honoring the
> non-blocking behavior.
>
>> Possibly some ST-Ericsson people can add Tested-by tags as well.
>>
>> We will integrate Ux500 support whenever it's suitable, either after the 
>> merge
>> or as add-on patches for Carlos patch series. (If Carlos would like to keep
>> them in his series.)
>>
>
> Either way is fine, for me. Could you send the patches for review ?
>
> Br,
> Carlos
> --
> Carlos Chinea 
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 7/7] OMAP: DSS2: Taal: Use device name in backlight_device_register

[Archit Taneja]

Panel Taal driver uses the string "taal" to register for a backlight device.
This causes backlight_device_register() to fail when a second taal panel
is added. Use dev_name(&dssdev->dev) as a parameter instead of the string.

Note: This will break backlight related sysfs commands. Use the name as
generated by the DSS2 driver, in the form "displayi", which represents
the ith registered display device.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/displays/panel-taal.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 90d79c0..fdd5d4a 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1031,8 +1031,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
props.max_brightness = 127;
 
props.type = BACKLIGHT_RAW;
-   bldev = backlight_device_register("taal", &dssdev->dev, dssdev,
- &taal_bl_ops, &props);
+   bldev = backlight_device_register(dev_name(&dssdev->dev), &dssdev->dev,
+   dssdev, &taal_bl_ops, &props);
if (IS_ERR(bldev)) {
r = PTR_ERR(bldev);
goto err_bl;
-- 
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 v2 6/7] OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4

[Archit Taneja]

Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol
engine and DISPC Functional clock. Do the following:

- Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the
  dsi module number as an argument.
- Create debugfs files for dsi2, split the corresponding debugfs functions.
- Allow DPI to use these new clock sources.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/core.c |6 +-
 drivers/video/omap2/dss/dispc.c|8 ++
 drivers/video/omap2/dss/dpi.c  |6 ++-
 drivers/video/omap2/dss/dsi.c  |  117 +++-
 drivers/video/omap2/dss/dss.c  |   32 +++--
 drivers/video/omap2/dss/dss.h  |   15 +++-
 drivers/video/omap2/dss/dss_features.c |2 +
 include/video/omapdss.h|2 +
 8 files changed, 157 insertions(+), 31 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5fbf9e8..3da4267 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -127,8 +127,7 @@ static int dss_initialize_debugfs(void)
 #endif
 
 #if defined(CONFIG_OMAP2_DSS_DSI) && 
defined(CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS)
-   debugfs_create_file("dsi_irq", S_IRUGO, dss_debugfs_dir,
-   &dsi_dump_irqs, &dss_debug_fops);
+   dsi_create_debugfs_files_irq(dss_debugfs_dir, &dss_debug_fops);
 #endif
 
debugfs_create_file("dss", S_IRUGO, dss_debugfs_dir,
@@ -140,8 +139,7 @@ static int dss_initialize_debugfs(void)
&rfbi_dump_regs, &dss_debug_fops);
 #endif
 #ifdef CONFIG_OMAP2_DSS_DSI
-   debugfs_create_file("dsi", S_IRUGO, dss_debugfs_dir,
-   &dsi_dump_regs, &dss_debug_fops);
+   dsi_create_debugfs_files_reg(dss_debugfs_dir, &dss_debug_fops);
 #endif
 #ifdef CONFIG_OMAP2_DSS_VENC
debugfs_create_file("venc", S_IRUGO, dss_debugfs_dir,
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index df8c992..1a2d835 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2250,6 +2250,10 @@ unsigned long dispc_fclk_rate(void)
dsidev = dsi_get_dsidev_from_id(0);
r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
break;
+   case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
+   dsidev = dsi_get_dsidev_from_id(1);
+   r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
+   break;
default:
BUG();
}
@@ -2276,6 +2280,10 @@ unsigned long dispc_lclk_rate(enum omap_channel channel)
dsidev = dsi_get_dsidev_from_id(0);
r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
break;
+   case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
+   dsidev = dsi_get_dsidev_from_id(1);
+   r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
+   break;
default:
BUG();
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 4d661a9..ff6bd30 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -53,8 +53,12 @@ static bool dpi_use_dsi_pll(struct omap_dss_device *dssdev)
 {
if (dssdev->clocks.dispc.dispc_fclk_src ==
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
+   dssdev->clocks.dispc.dispc_fclk_src ==
+   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ||
dssdev->clocks.dispc.channel.lcd_clk_src ==
-   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC)
+   OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
+   dssdev->clocks.dispc.channel.lcd_clk_src ==
+   OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC)
return true;
else
return false;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 762b0fe..85ec3d6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1143,8 +1144,9 @@ static unsigned long dsi_get_txbyteclkhs(struct 
platform_device *dsidev)
 static unsigned long dsi_fclk_rate(struct platform_device *dsidev)
 {
unsigned long r;
+   int dsi_module = dsi_get_dsidev_id(dsidev);
 
-   if (dss_get_dsi_clk_source() == OMAP_DSS_CLK_SRC_FCK) {
+   if (dss_get_dsi_clk_source(dsi_module) == OMAP_DSS_CLK_SRC_FCK) {
/* DSI FCLK source is DSS_CLK_FCK */
r = dss_clk_get_rate(DSS_CLK_FCK);
} else {
@@ -1670,19 +1672,20 @@ void dsi_pll_uninit(struct platform_device *dsidev, 
bool disconnect_lanes)
DSSDBG("PLL uninit done\n");
 }
 
-void dsi_dump_clocks(struct seq_file *s)
+static void dsi_dump_dsidev_clocks(struct platform_device *dsidev,
+   struct seq_file *s)
 {
-   struct platform_device *dsidev = dsi_

[PATCH v2 5/7] OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs

[Archit Taneja]

dsi_packet_sent_handler_vp() and dsi_packet_sent_handler_l4() currently
receive the completion parameter as their argument. This is not sufficient
information to differentiate between DSI1 and DSI2 platform devices.

Pass the struct "dsi_packet_sent_handler_data" to the packet_sent_handler
isrs, these contain the platform_device pointer of the DSI device and the
pointer to the completion struct.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dsi.c |   43 +++-
 1 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 61ee3db..762b0fe 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -330,6 +330,11 @@ struct dsi_data {
unsigned scp_clk_refcount;
 };
 
+struct dsi_packet_sent_handler_data {
+   struct platform_device *dsidev;
+   struct completion *completion;
+};
+
 static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
 
 #ifdef DEBUG
@@ -2394,27 +2399,28 @@ static bool dsi_vc_is_enabled(struct platform_device 
*dsidev, int channel)
 
 static void dsi_packet_sent_handler_vp(void *data, u32 mask)
 {
-   struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
-   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   struct dsi_packet_sent_handler_data *vp_data =
+   (struct dsi_packet_sent_handler_data *) data;
+   struct dsi_data *dsi = dsi_get_dsidrv_data(vp_data->dsidev);
const int channel = dsi->update_channel;
u8 bit = dsi->te_enabled ? 30 : 31;
 
-   if (REG_GET(dsidev, DSI_VC_TE(channel), bit, bit) == 0)
-   complete((struct completion *)data);
+   if (REG_GET(vp_data->dsidev, DSI_VC_TE(channel), bit, bit) == 0)
+   complete(vp_data->completion);
 }
 
 static int dsi_sync_vc_vp(struct platform_device *dsidev, int channel)
 {
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   DECLARE_COMPLETION_ONSTACK(completion);
+   struct dsi_packet_sent_handler_data vp_data = { dsidev, &completion };
int r = 0;
u8 bit;
 
-   DECLARE_COMPLETION_ONSTACK(completion);
-
bit = dsi->te_enabled ? 30 : 31;
 
r = dsi_register_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &vp_data, DSI_VC_IRQ_PACKET_SENT);
if (r)
goto err0;
 
@@ -2429,34 +2435,35 @@ static int dsi_sync_vc_vp(struct platform_device 
*dsidev, int channel)
}
 
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &vp_data, DSI_VC_IRQ_PACKET_SENT);
 
return 0;
 err1:
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &vp_data, DSI_VC_IRQ_PACKET_SENT);
 err0:
return r;
 }
 
 static void dsi_packet_sent_handler_l4(void *data, u32 mask)
 {
-   struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
-   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   struct dsi_packet_sent_handler_data *l4_data =
+   (struct dsi_packet_sent_handler_data *) data;
+   struct dsi_data *dsi = dsi_get_dsidrv_data(l4_data->dsidev);
const int channel = dsi->update_channel;
 
-   if (REG_GET(dsidev, DSI_VC_CTRL(channel), 5, 5) == 0)
-   complete((struct completion *)data);
+   if (REG_GET(l4_data->dsidev, DSI_VC_CTRL(channel), 5, 5) == 0)
+   complete(l4_data->completion);
 }
 
 static int dsi_sync_vc_l4(struct platform_device *dsidev, int channel)
 {
-   int r = 0;
-
DECLARE_COMPLETION_ONSTACK(completion);
+   struct dsi_packet_sent_handler_data l4_data = { dsidev, &completion };
+   int r = 0;
 
r = dsi_register_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &l4_data, DSI_VC_IRQ_PACKET_SENT);
if (r)
goto err0;
 
@@ -2471,12 +2478,12 @@ static int dsi_sync_vc_l4(struct platform_device 
*dsidev, int channel)
}
 
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &l4_data, DSI_VC_IRQ_PACKET_SENT);
 
return 0;
 err1:
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
-   &completion, DSI_VC_IRQ_PACKET_SENT);
+   &l4_data, DSI_VC_IRQ_PACKET_SENT);
 err0:
return r;
 }
-- 
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 v2 4/7] OMAP: DSS2: DSI: Use platform_device pointer to get dsi data

[Archit Taneja]

The dsi related data structure currently creates one global instance of itself
which is accessed by dsi functions. Remove this global structure instance and
declare the struct as dsi_data. Modify dsi_init() to allocate a "dsi_data"
structure for each platform device instance. Link this data with the device's
platform_device pointer. Create the function dsi_get_dsidrv_data() which takes
the pdev and return a pointer to the device's dsi_data.

Make dsi_get_dsidev_id() return only 0 for now, this will be removed once the
name of the DSI platform device is changed to the device instance form, like
"omapdss_dsi.0" and "omapdss_dsi.1" etc.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dsi.c |  672 +
 1 files changed, 409 insertions(+), 263 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d03eb6..61ee3db 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -257,7 +258,7 @@ struct dsi_isr_tables {
struct dsi_isr_data isr_table_cio[DSI_MAX_NR_ISRS];
 };
 
-static struct dsi_data {
+struct dsi_data {
struct platform_device *pdev;
void __iomem*base;
int irq;
@@ -327,7 +328,7 @@ static struct dsi_data {
unsigned long lpdiv_max;
 
unsigned scp_clk_refcount;
-} dsi;
+};
 
 static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
 
@@ -336,6 +337,11 @@ static unsigned int dsi_perf;
 module_param_named(dsi_perf, dsi_perf, bool, 0644);
 #endif
 
+static inline struct dsi_data *dsi_get_dsidrv_data(struct platform_device 
*dsidev)
+{
+   return dev_get_drvdata(&dsidev->dev);
+}
+
 static inline struct platform_device *dsi_get_dsidev_from_dssdev(struct 
omap_dss_device *dssdev)
 {
return dsi_pdev_map[dssdev->phy.dsi.module];
@@ -346,16 +352,30 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
return dsi_pdev_map[module];
 }
 
+static int dsi_get_dsidev_id(struct platform_device *dsidev)
+{
+   /* TEMP: Pass 0 as the dsi module index till the time the dsi platform
+* device names aren't changed to the form "omapdss_dsi.0",
+* "omapdss_dsi.1" and so on */
+   BUG_ON(dsidev->id != -1);
+
+   return 0;
+}
+
 static inline void dsi_write_reg(struct platform_device *dsidev,
const struct dsi_reg idx, u32 val)
 {
-   __raw_writel(val, dsi.base + idx.idx);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+   __raw_writel(val, dsi->base + idx.idx);
 }
 
 static inline u32 dsi_read_reg(struct platform_device *dsidev,
const struct dsi_reg idx)
 {
-   return __raw_readl(dsi.base + idx.idx);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+   return __raw_readl(dsi->base + idx.idx);
 }
 
 
@@ -369,19 +389,27 @@ void dsi_restore_context(void)
 
 void dsi_bus_lock(struct omap_dss_device *dssdev)
 {
-   down(&dsi.bus_lock);
+   struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+   down(&dsi->bus_lock);
 }
 EXPORT_SYMBOL(dsi_bus_lock);
 
 void dsi_bus_unlock(struct omap_dss_device *dssdev)
 {
-   up(&dsi.bus_lock);
+   struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+   up(&dsi->bus_lock);
 }
 EXPORT_SYMBOL(dsi_bus_unlock);
 
 static bool dsi_bus_is_locked(struct platform_device *dsidev)
 {
-   return dsi.bus_lock.count == 0;
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+   return dsi->bus_lock.count == 0;
 }
 
 static void dsi_completion_handler(void *data, u32 mask)
@@ -405,16 +433,19 @@ static inline int wait_for_bit_change(struct 
platform_device *dsidev,
 #ifdef DEBUG
 static void dsi_perf_mark_setup(struct platform_device *dsidev)
 {
-   dsi.perf_setup_time = ktime_get();
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   dsi->perf_setup_time = ktime_get();
 }
 
 static void dsi_perf_mark_start(struct platform_device *dsidev)
 {
-   dsi.perf_start_time = ktime_get();
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   dsi->perf_start_time = ktime_get();
 }
 
 static void dsi_perf_show(struct platform_device *dsidev, const char *name)
 {
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
ktime_t t, setup_time, trans_time;
u32 total_bytes;
u32 setup_us, trans_us, total_us;
@@ -424,21 +455,21 @@ static void dsi_perf_show(struct platform_device *dsidev, 
const char *name)
 
t = ktime_get();
 
-   setup_time = ktime_sub(dsi.perf_start_time, dsi.perf_setup_time);
+   setup_time = ktime_sub(dsi->perf_start_time, dsi->perf_setup_time);
setup_us = (u32)ktime_to_us(setup_time);
if (setup_us == 0)
setup_us = 1;
 
-   tr

[PATCH v2 1/7] OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi

[Archit Taneja]

Add pointer to omap_dss_device struct as an argument in the functions which
are exported to dsi panel drivers. This argument will tell the DSI driver
which DSI interface's data it has to choose.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/displays/panel-taal.c |  120 ++--
 drivers/video/omap2/dss/dsi.c |   48 +++-
 include/video/omapdss.h   |   35 +---
 3 files changed, 110 insertions(+), 93 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index be230b3..90d79c0 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -271,7 +271,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8 
dcs_cmd, u8 *data)
int r;
u8 buf[1];
 
-   r = dsi_vc_dcs_read(td->channel, dcs_cmd, buf, 1);
+   r = dsi_vc_dcs_read(td->dssdev, td->channel, dcs_cmd, buf, 1);
 
if (r < 0)
return r;
@@ -283,7 +283,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8 
dcs_cmd, u8 *data)
 
 static int taal_dcs_write_0(struct taal_data *td, u8 dcs_cmd)
 {
-   return dsi_vc_dcs_write(td->channel, &dcs_cmd, 1);
+   return dsi_vc_dcs_write(td->dssdev, td->channel, &dcs_cmd, 1);
 }
 
 static int taal_dcs_write_1(struct taal_data *td, u8 dcs_cmd, u8 param)
@@ -291,7 +291,7 @@ static int taal_dcs_write_1(struct taal_data *td, u8 
dcs_cmd, u8 param)
u8 buf[2];
buf[0] = dcs_cmd;
buf[1] = param;
-   return dsi_vc_dcs_write(td->channel, buf, 2);
+   return dsi_vc_dcs_write(td->dssdev, td->channel, buf, 2);
 }
 
 static int taal_sleep_in(struct taal_data *td)
@@ -303,7 +303,7 @@ static int taal_sleep_in(struct taal_data *td)
hw_guard_wait(td);
 
cmd = DCS_SLEEP_IN;
-   r = dsi_vc_dcs_write_nosync(td->channel, &cmd, 1);
+   r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, &cmd, 1);
if (r)
return r;
 
@@ -409,7 +409,7 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (x2 >> 8) & 0xff;
buf[4] = (x2 >> 0) & 0xff;
 
-   r = dsi_vc_dcs_write_nosync(td->channel, buf, sizeof(buf));
+   r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, buf, sizeof(buf));
if (r)
return r;
 
@@ -419,11 +419,11 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (y2 >> 8) & 0xff;
buf[4] = (y2 >> 0) & 0xff;
 
-   r = dsi_vc_dcs_write_nosync(td->channel, buf, sizeof(buf));
+   r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, buf, sizeof(buf));
if (r)
return r;
 
-   dsi_vc_send_bta_sync(td->channel);
+   dsi_vc_send_bta_sync(td->dssdev, td->channel);
 
return r;
 }
@@ -507,7 +507,7 @@ static int taal_exit_ulps(struct omap_dss_device *dssdev)
if (r)
goto err;
 
-   omapdss_dsi_vc_enable_hs(td->channel, true);
+   omapdss_dsi_vc_enable_hs(dssdev, td->channel, true);
 
r = _taal_enable_te(dssdev, true);
if (r)
@@ -565,13 +565,13 @@ static int taal_bl_update_status(struct backlight_device 
*dev)
 
if (td->use_dsi_bl) {
if (td->enabled) {
-   dsi_bus_lock();
+   dsi_bus_lock(dssdev);
 
r = taal_wake_up(dssdev);
if (!r)
r = taal_dcs_write_1(td, DCS_BRIGHTNESS, level);
 
-   dsi_bus_unlock();
+   dsi_bus_unlock(dssdev);
} else {
r = 0;
}
@@ -632,13 +632,13 @@ static ssize_t taal_num_errors_show(struct device *dev,
mutex_lock(&td->lock);
 
if (td->enabled) {
-   dsi_bus_lock();
+   dsi_bus_lock(dssdev);
 
r = taal_wake_up(dssdev);
if (!r)
r = taal_dcs_read_1(td, DCS_READ_NUM_ERRORS, &errors);
 
-   dsi_bus_unlock();
+   dsi_bus_unlock(dssdev);
} else {
r = -ENODEV;
}
@@ -662,13 +662,13 @@ static ssize_t taal_hw_revision_show(struct device *dev,
mutex_lock(&td->lock);
 
if (td->enabled) {
-   dsi_bus_lock();
+   dsi_bus_lock(dssdev);
 
r = taal_wake_up(dssdev);
if (!r)
r = taal_get_id(td, &id1, &id2, &id3);
 
-   dsi_bus_unlock();
+   dsi_bus_unlock(dssdev);
} else {
r = -ENODEV;
}
@@ -728,7 +728,7 @@ static ssize_t store_cabc_mode(struct device *dev,
mutex_lock(&td->lock);
 
if (td->enabled) {
-   dsi_bus_lock();
+   dsi_bus_lock(dssdev);
 
if (!td->cabc_broken) {
r = taal_wake_up(dssdev);
@@ -740,7 +740,7 @@ static ssize_t store_cabc_mode(struct device 

[PATCH v2 2/7] OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init()

[Archit Taneja]

The function dsi_pll_init() has omap_dss_device argument which is
not used. Remove this argument.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dpi.c |2 +-
 drivers/video/omap2/dss/dsi.c |5 ++---
 drivers/video/omap2/dss/dss.h |3 +--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bec8c8a..3c988b6 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -189,7 +189,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device 
*dssdev)
 
if (dpi_use_dsi_pll(dssdev)) {
dss_clk_enable(DSS_CLK_SYSCK);
-   r = dsi_pll_init(dssdev, 0, 1);
+   r = dsi_pll_init(0, 1);
if (r)
goto err3;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6d71488..b2945fe 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1470,8 +1470,7 @@ err:
return r;
 }
 
-int dsi_pll_init(struct omap_dss_device *dssdev, bool enable_hsclk,
-   bool enable_hsdiv)
+int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv)
 {
int r = 0;
enum dsi_pll_power_state pwstate;
@@ -3745,7 +3744,7 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
 {
int r;
 
-   r = dsi_pll_init(dssdev, true, true);
+   r = dsi_pll_init(true, true);
if (r)
goto err0;
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index eea5c7d..40764e0 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -292,8 +292,7 @@ int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo);
 int dsi_pll_calc_clock_div_pck(bool is_tft, unsigned long req_pck,
struct dsi_clock_info *cinfo,
struct dispc_clock_info *dispc_cinfo);
-int dsi_pll_init(struct omap_dss_device *dssdev, bool enable_hsclk,
-   bool enable_hsdiv);
+int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv);
 void dsi_pll_uninit(bool disconnect_lanes);
 void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
u32 fifo_size, enum omap_burst_size *burst_size,
-- 
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 v2 0/7] OMAP: DSS2: DSI2 for secondary lcd panel on OMAP4

[Archit Taneja]

OMAP4 has a DSI2 module, whose lanes are connected to the secondary lcd panel on
blaze and 4430sdp.
Modify dsi.c driver to register and work multiple DSI devices. Make the
necessary changes needed to introduce DSI2 PLL clocks.

Changes since v1:
-Rename functions used for getting dsidev
-Remove FEAT_DSS_DSI2
-Rework debugfs usage for dsi

Applies over:

https://gitorious.org/linux-omap-dss2/linux/commits/master

Archit Taneja (7):
  OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions
exported by dsi
  OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init()
  OMAP: DSS2: Pass platform_device as an argument in dsi functions
  OMAP: DSS2: DSI: Use platform_device pointer to get dsi data
  OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs
  OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4
  OMAP: DSS2: Taal: Use device name in backlight_device_register

 drivers/video/omap2/displays/panel-taal.c |  124 +-
 drivers/video/omap2/dss/core.c|6 +-
 drivers/video/omap2/dss/dispc.c   |   16 +-
 drivers/video/omap2/dss/dpi.c |   36 +-
 drivers/video/omap2/dss/dsi.c | 1783 +
 drivers/video/omap2/dss/dss.c |   44 +-
 drivers/video/omap2/dss/dss.h |   45 +-
 drivers/video/omap2/dss/dss_features.c|2 +
 drivers/video/omap2/dss/dss_features.h|1 +
 include/video/omapdss.h   |   39 +-
 10 files changed, 1261 insertions(+), 835 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 4/6] OMAP: LDP: Port the display driver to new DSS2

[Tomi Valkeinen]

On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:

> Right. Do both fixes make it work?
> 
> If it is, then Tomi,
> will you add both fixes to the patch set with our SOBs?
> or do you want this to be sent properly as a follow up?

Yes, I can add these all to the same patch and handle it through DSS
tree. Although due to the reluctance to make changes to arch/arm/*omap*,
I guess we'll pass these patches in this merge window.

Mayuresh, if you're able to test this and it works, can you send me the
full diff so that I don't make any mistakes combining the code?

 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 V3] OMAP3+: SR Layer Cleanup

[Cousson, Benoit]

Hi Shweta,

On 5/11/2011 11:12 AM, Gulati, Shweta wrote:

To set sr ntarget values  for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.

Tested on OMAP3630 SDP and OMAP4430 SDP Board

Signed-off-by: Shweta Gulati
Cc: Nishanth Menon
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
  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 ---


Since this patch is touching some hwmod files, it will be good to Cc 
Paul and me. It is far from obvious from the subject that hwmod data are 
involved in this patch.



  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),
  };

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
inde

[PATCHv2 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage

[Tomi Valkeinen]

omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct
fb_ops allocated from stack. This caused the stack usage grow quite
high.

Use kzalloc to allocate the structs instead.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/omapfb/omapfb-main.c |   95 +++---
 1 files changed, 61 insertions(+), 34 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index 9a5b4bc..505bc12 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1996,9 +1996,9 @@ static int omapfb_create_framebuffers(struct 
omapfb2_device *fbdev)
 static int omapfb_mode_to_timings(const char *mode_str,
struct omap_video_timings *timings, u8 *bpp)
 {
-   struct fb_info fbi;
-   struct fb_var_screeninfo var;
-   struct fb_ops fbops;
+   struct fb_info *fbi;
+   struct fb_var_screeninfo *var;
+   struct fb_ops *fbops;
int r;
 
 #ifdef CONFIG_OMAP2_DSS_VENC
@@ -2016,39 +2016,66 @@ static int omapfb_mode_to_timings(const char *mode_str,
/* this is quite a hack, but I wanted to use the modedb and for
 * that we need fb_info and var, so we create dummy ones */
 
-   memset(&fbi, 0, sizeof(fbi));
-   memset(&var, 0, sizeof(var));
-   memset(&fbops, 0, sizeof(fbops));
-   fbi.fbops = &fbops;
-
-   r = fb_find_mode(&var, &fbi, mode_str, NULL, 0, NULL, 24);
-
-   if (r != 0) {
-   timings->pixel_clock = PICOS2KHZ(var.pixclock);
-   timings->hbp = var.left_margin;
-   timings->hfp = var.right_margin;
-   timings->vbp = var.upper_margin;
-   timings->vfp = var.lower_margin;
-   timings->hsw = var.hsync_len;
-   timings->vsw = var.vsync_len;
-   timings->x_res = var.xres;
-   timings->y_res = var.yres;
-
-   switch (var.bits_per_pixel) {
-   case 16:
-   *bpp = 16;
-   break;
-   case 24:
-   case 32:
-   default:
-   *bpp = 24;
-   break;
-   }
+   *bpp = 0;
+   fbi = NULL;
+   var = NULL;
+   fbops = NULL;
 
-   return 0;
-   } else {
-   return -EINVAL;
+   fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);
+   if (fbi == NULL) {
+   r = -ENOMEM;
+   goto err;
+   }
+
+   var = kzalloc(sizeof(*var), GFP_KERNEL);
+   if (var == NULL) {
+   r = -ENOMEM;
+   goto err;
+   }
+
+   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+   if (fbops == NULL) {
+   r = -ENOMEM;
+   goto err;
+   }
+
+   fbi->fbops = fbops;
+
+   r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
+   if (r == 0) {
+   r = -EINVAL;
+   goto err;
}
+
+   timings->pixel_clock = PICOS2KHZ(var->pixclock);
+   timings->hbp = var->left_margin;
+   timings->hfp = var->right_margin;
+   timings->vbp = var->upper_margin;
+   timings->vfp = var->lower_margin;
+   timings->hsw = var->hsync_len;
+   timings->vsw = var->vsync_len;
+   timings->x_res = var->xres;
+   timings->y_res = var->yres;
+
+   switch (var->bits_per_pixel) {
+   case 16:
+   *bpp = 16;
+   break;
+   case 24:
+   case 32:
+   default:
+   *bpp = 24;
+   break;
+   }
+
+   r = 0;
+
+err:
+   kfree(fbi);
+   kfree(var);
+   kfree(fbops);
+
+   return r;
 }
 
 static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
-- 
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

[PATCHv2 7/8] OMAP: DSS2: OMAPFB: remove dead code

[Tomi Valkeinen]

Remove old unused code lying inside #if 0.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/omapfb/omapfb-main.c |   29 -
 1 files changed, 0 insertions(+), 29 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index eba90b3..9a5b4bc 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -757,35 +757,6 @@ static int omapfb_open(struct fb_info *fbi, int user)
 
 static int omapfb_release(struct fb_info *fbi, int user)
 {
-#if 0
-   struct omapfb_info *ofbi = FB2OFB(fbi);
-   struct omapfb2_device *fbdev = ofbi->fbdev;
-   struct omap_dss_device *display = fb2display(fbi);
-
-   DBG("Closing fb with plane index %d\n", ofbi->id);
-
-   omapfb_lock(fbdev);
-
-   if (display && display->get_update_mode && display->update) {
-   /* XXX this update should be removed, I think. But it's
-* good for debugging */
-   if (display->get_update_mode(display) ==
-   OMAP_DSS_UPDATE_MANUAL) {
-   u16 w, h;
-
-   if (display->sync)
-   display->sync(display);
-
-   display->get_resolution(display, &w, &h);
-   display->update(display, 0, 0, w, h);
-   }
-   }
-
-   if (display && display->sync)
-   display->sync(display);
-
-   omapfb_unlock(fbdev);
-#endif
return 0;
 }
 
-- 
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

[PATCHv2 6/8] OMAP: DSS2: RFBI: cleanup

[Tomi Valkeinen]

The RFBI driver is quite messy. Remove dead and unneeded code and add
statics to functions.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dss.h  |7 --
 drivers/video/omap2/dss/rfbi.c |  124 +---
 2 files changed, 3 insertions(+), 128 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f659cfb..6cc56a1 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -497,13 +497,6 @@ void hdmi_panel_exit(void);
 int rfbi_init_platform_driver(void);
 void rfbi_uninit_platform_driver(void);
 void rfbi_dump_regs(struct seq_file *s);
-
-int rfbi_configure(int rfbi_module, int bpp, int lines);
-void rfbi_enable_rfbi(bool enable);
-void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
-   u16 height, void (callback)(void *data), void *data);
-void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t);
-unsigned long rfbi_get_max_tx_rate(void);
 int rfbi_init_display(struct omap_dss_device *display);
 #else
 static inline int rfbi_init_platform_driver(void)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 155caf0..c06fbe0 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -66,9 +66,6 @@ struct rfbi_reg { u16 idx; };
 #define REG_FLD_MOD(idx, val, start, end) \
rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
 
-/* To work around an RFBI transfer rate limitation */
-#define OMAP_RFBI_RATE_LIMIT1
-
 enum omap_rfbi_cycleformat {
OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
@@ -90,11 +87,6 @@ enum omap_rfbi_parallelmode {
OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
 };
 
-enum update_cmd {
-   RFBI_CMD_UPDATE = 0,
-   RFBI_CMD_SYNC   = 1,
-};
-
 static int rfbi_convert_timings(struct rfbi_timings *t);
 static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
 
@@ -115,22 +107,9 @@ static struct {
 
struct omap_dss_device *dssdev[2];
 
-   struct kfifo  cmd_fifo;
-   spinlock_tcmd_lock;
-   struct completion cmd_done;
-   atomic_t  cmd_fifo_full;
-   atomic_t  cmd_pending;
-
struct semaphore bus_lock;
 } rfbi;
 
-struct update_region {
-   u16 x;
-   u16 y;
-   u16 w;
-   u16 h;
-};
-
 static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
 {
__raw_writel(val, rfbi.base + idx.idx);
@@ -305,7 +284,7 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int 
scr_width,
 }
 EXPORT_SYMBOL(omap_rfbi_write_pixels);
 
-void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
+static void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
u16 height, void (*callback)(void *data), void *data)
 {
u32 l;
@@ -345,8 +324,6 @@ static void framedone_callback(void *data, u32 mask)
 
if (callback != NULL)
callback(rfbi.framedone_callback_data);
-
-   atomic_set(&rfbi.cmd_pending, 0);
 }
 
 #if 1 /* VERBOSE */
@@ -436,7 +413,7 @@ static int calc_extif_timings(struct rfbi_timings *t)
 }
 
 
-void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t)
+static void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t)
 {
int r;
 
@@ -471,59 +448,6 @@ static int ps_to_rfbi_ticks(int time, int div)
return ret;
 }
 
-#ifdef OMAP_RFBI_RATE_LIMIT
-unsigned long rfbi_get_max_tx_rate(void)
-{
-   unsigned long   l4_rate, dss1_rate;
-   int min_l4_ticks = 0;
-   int i;
-
-   /* According to TI this can't be calculated so make the
-* adjustments for a couple of known frequencies and warn for
-* others.
-*/
-   static const struct {
-   unsigned long l4_clk;   /* HZ */
-   unsigned long dss1_clk; /* HZ */
-   unsigned long min_l4_ticks;
-   } ftab[] = {
-   { 55,   132,7, },   /* 7.86 MPix/s */
-   { 110,  110,12, },  /* 9.16 MPix/s */
-   { 110,  132,10, },  /* 11   Mpix/s */
-   { 120,  120,10, },  /* 12   Mpix/s */
-   { 133,  133,10, },  /* 13.3 Mpix/s */
-   };
-
-   l4_rate = rfbi.l4_khz / 1000;
-   dss1_rate = dss_clk_get_rate(DSS_CLK_FCK) / 100;
-
-   for (i = 0; i < ARRAY_SIZE(ftab); i++) {
-   /* Use a window instead of an exact match, to account
-* for different DPLL multiplier / divider pairs.
-*/
-   if (abs(ftab[i].l4_clk - l4_rate) < 3 &&
-   abs(ftab[i].dss1_clk - dss1_rate) < 3) {
-   min_l4_ticks = ftab[i].min_l4_ticks;
-   break;
-   }
-   }
-   if (i == ARRAY_SIZE(ftab)) {
-   /* Can't be sure, return anyway the maximum not
-

[PATCHv2 3/8] OMAP: DSS2: RFBI: add rfbi_bus_lock

[Tomi Valkeinen]

Add similar bus lock to RFBI as is in DSI. The panel driver can use the
bus lock to mark that the RFBI bus is currently in use.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/rfbi.c |   16 
 include/video/omapdss.h|2 ++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 0985f2f..46817e7 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "dss.h"
@@ -119,6 +120,8 @@ static struct {
struct completion cmd_done;
atomic_t  cmd_fifo_full;
atomic_t  cmd_pending;
+
+   struct semaphore bus_lock;
 } rfbi;
 
 struct update_region {
@@ -146,6 +149,18 @@ static void rfbi_enable_clocks(bool enable)
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
 }
 
+void rfbi_bus_lock(void)
+{
+   down(&rfbi.bus_lock);
+}
+EXPORT_SYMBOL(rfbi_bus_lock);
+
+void rfbi_bus_unlock(void)
+{
+   up(&rfbi.bus_lock);
+}
+EXPORT_SYMBOL(rfbi_bus_unlock);
+
 void omap_rfbi_write_command(const void *buf, u32 len)
 {
rfbi_enable_clocks(1);
@@ -1022,6 +1037,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
rfbi.pdev = pdev;
 
spin_lock_init(&rfbi.cmd_lock);
+   sema_init(&rfbi.bus_lock, 1);
 
init_completion(&rfbi.cmd_done);
atomic_set(&rfbi.cmd_fifo_full, 0);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ab7d656..1ea151e 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -212,6 +212,8 @@ int omap_rfbi_enable_te(bool enable, unsigned line);
 int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
 unsigned hs_pulse_time, unsigned vs_pulse_time,
 int hs_pol_inv, int vs_pol_inv, int extif_div);
+void rfbi_bus_lock(void);
+void rfbi_bus_unlock(void);
 
 /* DSI */
 void dsi_bus_lock(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

[PATCHv2 5/8] OMAP: DSS2: RFBI: add omap_rfbi_configure

[Tomi Valkeinen]

Add omap_rfbi_configure() which the panel driver can use to reconfigure
the data element size and the number of data lines in the RFBI bus.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/rfbi.c |8 +++-
 include/video/omapdss.h|2 ++
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 1c19d17..155caf0 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -851,7 +851,13 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
 
return 0;
 }
-EXPORT_SYMBOL(rfbi_configure);
+
+int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
+   int data_lines)
+{
+   return rfbi_configure(dssdev->phy.rfbi.channel, pixel_size, data_lines);
+}
+EXPORT_SYMBOL(omap_rfbi_configure);
 
 int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
u16 *x, u16 *y, u16 *w, u16 *h)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 1ea151e..9b00748 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -612,5 +612,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
 int omap_rfbi_update(struct omap_dss_device *dssdev,
u16 x, u16 y, u16 w, u16 h,
void (*callback)(void *), void *data);
+int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
+   int data_lines);
 
 #endif
-- 
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

[PATCHv2 4/8] OMAP: DSS2: RFBI: clock enable/disable changes

[Tomi Valkeinen]

RFBI enables and disables clocks inside almost every function to get a
finegrained control to the clocks. However, the current understanding is
that this is not necessary power-management-wise.

Change the clocking scheme so that RFBI clocks are enabled when the
omapdss_rfbi_display_enable is called, and disabled when
omapdss_rfbi_display_disable is called.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/rfbi.c |   28 
 1 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 46817e7..1c19d17 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -163,7 +163,6 @@ EXPORT_SYMBOL(rfbi_bus_unlock);
 
 void omap_rfbi_write_command(const void *buf, u32 len)
 {
-   rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -187,13 +186,11 @@ void omap_rfbi_write_command(const void *buf, u32 len)
default:
BUG();
}
-   rfbi_enable_clocks(0);
 }
 EXPORT_SYMBOL(omap_rfbi_write_command);
 
 void omap_rfbi_read_data(void *buf, u32 len)
 {
-   rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -221,13 +218,11 @@ void omap_rfbi_read_data(void *buf, u32 len)
default:
BUG();
}
-   rfbi_enable_clocks(0);
 }
 EXPORT_SYMBOL(omap_rfbi_read_data);
 
 void omap_rfbi_write_data(const void *buf, u32 len)
 {
-   rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -252,7 +247,6 @@ void omap_rfbi_write_data(const void *buf, u32 len)
BUG();
 
}
-   rfbi_enable_clocks(0);
 }
 EXPORT_SYMBOL(omap_rfbi_write_data);
 
@@ -264,8 +258,6 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int 
scr_width,
int horiz_offset = scr_width - w;
int i;
 
-   rfbi_enable_clocks(1);
-
if (rfbi.datatype == OMAP_DSS_RFBI_DATATYPE_16 &&
   rfbi.parallelmode == OMAP_DSS_RFBI_PARALLELMODE_8) {
const u16 __iomem *pd = buf;
@@ -310,8 +302,6 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int 
scr_width,
} else {
BUG();
}
-
-   rfbi_enable_clocks(0);
 }
 EXPORT_SYMBOL(omap_rfbi_write_pixels);
 
@@ -332,8 +322,6 @@ void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 
width,
rfbi.framedone_callback = callback;
rfbi.framedone_callback_data = data;
 
-   rfbi_enable_clocks(1);
-
rfbi_write_reg(RFBI_PIXEL_CNT, width * height);
 
l = rfbi_read_reg(RFBI_CONTROL);
@@ -352,8 +340,6 @@ static void framedone_callback(void *data, u32 mask)
 
REG_FLD_MOD(RFBI_CONTROL, 0, 0, 0);
 
-   rfbi_enable_clocks(0);
-
callback = rfbi.framedone_callback;
rfbi.framedone_callback = NULL;
 
@@ -462,7 +448,6 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings 
*t)
 
BUG_ON(!t->converted);
 
-   rfbi_enable_clocks(1);
rfbi_write_reg(RFBI_ONOFF_TIME(rfbi_module), t->tim[0]);
rfbi_write_reg(RFBI_CYCLE_TIME(rfbi_module), t->tim[1]);
 
@@ -471,7 +456,6 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings 
*t)
(t->tim[2] ? 1 : 0), 4, 4);
 
rfbi_print_timings();
-   rfbi_enable_clocks(0);
 }
 
 static int ps_to_rfbi_ticks(int time, int div)
@@ -659,7 +643,6 @@ int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
DSSDBG("setup_te: mode %d hs %d vs %d hs_inv %d vs_inv %d\n",
mode, hs, vs, hs_pol_inv, vs_pol_inv);
 
-   rfbi_enable_clocks(1);
rfbi_write_reg(RFBI_HSYNC_WIDTH, hs);
rfbi_write_reg(RFBI_VSYNC_WIDTH, vs);
 
@@ -672,7 +655,6 @@ int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
l &= ~(1 << 20);
else
l |= 1 << 20;
-   rfbi_enable_clocks(0);
 
return 0;
 }
@@ -687,7 +669,6 @@ int omap_rfbi_enable_te(bool enable, unsigned line)
if (line > (1 << 11) - 1)
return -EINVAL;
 
-   rfbi_enable_clocks(1);
l = rfbi_read_reg(RFBI_CONFIG(0));
l &= ~(0x3 << 2);
if (enable) {
@@ -697,7 +678,6 @@ int omap_rfbi_enable_te(bool enable, unsigned line)
rfbi.te_enabled = 0;
rfbi_write_reg(RFBI_CONFIG(0), l);
rfbi_write_reg(RFBI_LINE_NUMBER, line);
-   rfbi_enable_clocks(0);
 
return 0;
 }
@@ -836,8 +816,6 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
break;
}
 
-   rfbi_enable_clocks(1);
-
REG_FLD_MOD(RFBI_CONTROL, 0, 3, 2); /* clear CS */
 
l = 0;
@@ -871,8 +849,6 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
DSSDBG("RFBI config: bpp %d, lines %d, cycles: 0x%x 0x%x 0x%x\n",
   bpp, lines, cycle1, cycle2, cycle3);
 
-   rfbi_enable_clocks(0);
-
 

[PATCHv2 2/8] OMAPFB: fix wrong clock aliases and device name

[Tomi Valkeinen]

The clock aliases and the dss platform device name have changed, and
omapfb fails to initialize. Update the names to correct ones.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap/dispc.c   |4 ++--
 drivers/video/omap/omapfb_main.c |2 +-
 drivers/video/omap/rfbi.c|2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 5294834..0ccd7ad 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -922,14 +922,14 @@ static int get_dss_clocks(void)
return PTR_ERR(dispc.dss_ick);
}
 
-   dispc.dss1_fck = clk_get(&dispc.fbdev->dssdev->dev, "dss1_fck");
+   dispc.dss1_fck = clk_get(&dispc.fbdev->dssdev->dev, "fck");
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev->dev, "can't get dss1_fck\n");
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
 
-   dispc.dss_54m_fck = clk_get(&dispc.fbdev->dssdev->dev, "tv_fck");
+   dispc.dss_54m_fck = clk_get(&dispc.fbdev->dssdev->dev, "tv_clk");
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev->dev, "can't get tv_fck\n");
clk_put(dispc.dss_ick);
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index e264efd..b3ddd74 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -90,7 +90,7 @@ static void omapdss_release(struct device *dev)
 
 /* dummy device for clocks */
 static struct platform_device omapdss_device = {
-   .name   = "omapdss",
+   .name   = "omapdss_dss",
.id = -1,
.dev= {
.release = omapdss_release,
diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
index eada9f1..0c6981f 100644
--- a/drivers/video/omap/rfbi.c
+++ b/drivers/video/omap/rfbi.c
@@ -90,7 +90,7 @@ static int rfbi_get_clocks(void)
return PTR_ERR(rfbi.dss_ick);
}
 
-   rfbi.dss1_fck = clk_get(&rfbi.fbdev->dssdev->dev, "dss1_fck");
+   rfbi.dss1_fck = clk_get(&rfbi.fbdev->dssdev->dev, "fck");
if (IS_ERR(rfbi.dss1_fck)) {
dev_err(rfbi.fbdev->dev, "can't get dss1_fck\n");
clk_put(rfbi.dss_ick);
-- 
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

[PATCHv2 0/8] OMAP: DSS: Miscellaneous patches

[Tomi Valkeinen]

Here are some smallish fixes and cleanups I made while porting N800's display
driver to DSS2.

Changes in v2:
* Fix typos in commit messages
* Properly check kzalloc return value and fail if allocation failed 
* Rebased on DSS master

 Tomi

Tomi Valkeinen (8):
  OMAP: DSS2: Add missing dummy functions
  OMAPFB: fix wrong clock aliases and device name
  OMAP: DSS2: RFBI: add rfbi_bus_lock
  OMAP: DSS2: RFBI: clock enable/disable changes
  OMAP: DSS2: RFBI: add omap_rfbi_configure
  OMAP: DSS2: RFBI: cleanup
  OMAP: DSS2: OMAPFB: remove dead code
  OMAP: DSS2: OMAPFB: Reduce stack usage

 drivers/video/omap/dispc.c   |4 +-
 drivers/video/omap/omapfb_main.c |2 +-
 drivers/video/omap/rfbi.c|2 +-
 drivers/video/omap2/dss/dss.h|   28 --
 drivers/video/omap2/dss/rfbi.c   |  174 +-
 drivers/video/omap2/omapfb/omapfb-main.c |  124 +++---
 include/video/omapdss.h  |4 +
 7 files changed, 119 insertions(+), 219 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

[PATCHv2 1/8] OMAP: DSS2: Add missing dummy functions

[Tomi Valkeinen]

dpi.c does not compile if DSI is not compiled in. Add the missing dummy
functions so that dpi.c compiles.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dss.h |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index eea5c7d..f659cfb 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -313,6 +313,27 @@ static inline unsigned long 
dsi_get_pll_hsdiv_dispc_rate(void)
WARN("%s: DSI not compiled in, returning rate as 0\n", __func__);
return 0;
 }
+static inline int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo)
+{
+   WARN("%s: DSI not compiled in\n", __func__);
+   return -ENODEV;
+}
+static inline int dsi_pll_calc_clock_div_pck(bool is_tft, unsigned long 
req_pck,
+   struct dsi_clock_info *cinfo,
+   struct dispc_clock_info *dispc_cinfo)
+{
+   WARN("%s: DSI not compiled in\n", __func__);
+   return -ENODEV;
+}
+static inline int dsi_pll_init(struct omap_dss_device *dssdev,
+   bool enable_hsclk, bool enable_hsdiv)
+{
+   WARN("%s: DSI not compiled in\n", __func__);
+   return -ENODEV;
+}
+static inline void dsi_pll_uninit(bool disconnect_lanes)
+{
+}
 static inline void dsi_wait_pll_hsdiv_dispc_active(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/2] omap: rx51: Don't power up speaker amplifier at bootup

[Jarkko Nikula]

Speaker amplifier is accidentally powered up in early TWL gpio setup. This
causes a few mA of needless battery current consumption. Without this patch
the amplifier can be shutdown only by having one active audio playback and
shutdown cycle to speaker output.

Thanks to Kalle Jokiniemi  for noticing the issue.

Signed-off-by: Jarkko Nikula 
Cc: Kalle Jokiniemi 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 8242e99..0374562 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -561,7 +561,7 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned 
gpio, unsigned n)
gpio_request(gpio + 6, "backlight_pwm");
gpio_direction_output(gpio + 6, 0);
gpio_request(gpio + 7, "speaker_en");
-   gpio_direction_output(gpio + 7, 1);
+   gpio_direction_output(gpio + 7, 0);
 
return 0;
 }
-- 
1.7.4.4

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

[PATCH 1/2] omap: rx51: Set regulator V28_A always on

[Jarkko Nikula]

The V28_A domain in Nokia N900 that supplies VDD voltages to TLV320AIC34 and
TPA6130A2 should not be shutdown. This is because otherwise there will be
leak from VIO to VDD in TLV320AIC34 and this leak consumes more battery
current that is saved from keeping V28_A off. With this patch the battery
current consumption is approximately 1.5 mA lower.

Thanks to Kalle Jokiniemi  for noticing the issue.

Signed-off-by: Jarkko Nikula 
Cc: Kalle Jokiniemi 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..8242e99 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -464,6 +464,7 @@ static struct regulator_init_data rx51_vmmc2 = {
.name   = "V28_A",
.min_uV = 280,
.max_uV = 300,
+   .always_on  = true, /* due VIO leak to AIC34 VDDs */
.apply_uV   = true,
.valid_modes_mask   = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
-- 
1.7.4.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 3/5] arm: omap: usb: device name change for the clk names of usbhs

[Igor Grinberg]

On 05/12/11 13:49, Premi, Sanjeev wrote:

>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org 
>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
>> Munegowda, Keshava
>> Sent: Wednesday, May 11, 2011 7:35 PM
>> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>> Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; 
>> part...@india.ti.com
>> Subject: [PATCH 3/5] arm: omap: usb: device name change for 
>> the clk names of usbhs
> [snip]...[snip]
>
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -27,7 +27,7 @@
>>  #include 
>>  #include 
>>  
>> -#define USBHS_DRIVER_NAME   "usbhs-omap"
>> +#define USBHS_DRIVER_NAME   "usbhs_omap"
>>  #define OMAP_EHCI_DEVICE"ehci-omap"
>>  #define OMAP_OHCI_DEVICE"ohci-omap3"
>
> [sp] Shouldn't we be consistent in using minus/dash and
>  underscore in the device names?

Also, can't we avoid once again changing the clock names
(at least for a while...)?
Is that really necessary? Can't hwmod use current clock names?
Because, Linus is sooo happy each time he sees that kind of changes


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

[Igor Grinberg]

On 05/12/11 11:47, Janorkar, Mayuresh wrote:

>> On 05/12/11 10:16, Igor Grinberg wrote:
>> there is a typo in the function name:
>> s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/
> Also,
>> +};
>> +
>> +r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
> This should be ARRAY_SIZE(twl_gpios));

yeah, sorry for that

that is what happening when making patches in a hurry and no checks done

> And one more thing:
> We need to use regulator for OMAP3430.
>
>
> Something like this:
> +/* VPLL2 for digital video outputs */
> +static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
> +REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
> +REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"),
> +};
> +
> +static struct regulator_init_data ldp_vpll2 = {
> +.constraints = {
> +.name   = "VDVI",
> +.min_uV = 180,
> +.max_uV = 180,
> +.apply_uV   = true,
> +.valid_modes_mask   = REGULATOR_MODE_NORMAL
> +| REGULATOR_MODE_STANDBY,
> +.valid_ops_mask = REGULATOR_CHANGE_MODE
> +| REGULATOR_CHANGE_STATUS,
> +},
> +.num_consumer_supplies  = ARRAY_SIZE(ldp_vpll2_supplies),
> +.consumer_supplies  = ldp_vpll2_supplies,
> +};
>
> @@ -340,6 +514,7 @@ static struct twl4030_platform_data ldp_twldata = {
> .vmmc1  = &ldp_vmmc1,
> .gpio   = &ldp_gpio_data,
> .keypad = &ldp_kp_twl4030_data,
> +   .vpll2  = &ldp_vpll2,
>

Right. Do both fixes make it work?

If it is, then Tomi,
will you add both fixes to the patch set with our SOBs?
or do you want this to be sent properly as a follow up?

-- 
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: beagleboardxm 2.6.39rc4 mcbsp problems.

[Peter Ujfalusi]

On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
> Of course for this you need to use omap as a master and codec as a
> slave. One example for this is sound/soc/omap/omap3pandora.c.
> 
>  static struct omap_board_mux board_mux[] __initdata = {
> + OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> + OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> + OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> + OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> +

I think the CLKX, FSX need to be input, since the config suggests,t that 
McBSP1 is the slave port:

> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f

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

Re: [PATCH v10 4/7] MFD: TWL4030: power scripts for OMAP3 boards

[Tony Lindgren]

* Lesly A M  [110506 06:14]:
> Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
> 
> TWL4030 power scripts which can be used by different OMAP3 boards
> with the power companion chip (TWL4030 series).
> 
> The twl4030 generic script can be used by any board file to update
> the power data in twl4030_platform_data.
> 
> Since the TWL4030 power script has dependency with APIs in twl4030-power.c
> removing the __init for these APIs.
> 
> For more information please see:
>   http://omapedia.org/wiki/TWL4030_power_scripts
> 
> Signed-off-by: Lesly A M 
> Cc: Nishanth Menon 
> Cc: David Derrick 
> Cc: Samuel Ortiz 
> ---
>  arch/arm/configs/omap2plus_defconfig |1 +
>  arch/arm/mach-omap2/devices.c|   15 ++
>  drivers/mfd/Kconfig  |   11 +
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/twl4030-power.c  |   31 ++--
>  drivers/mfd/twl4030-script-omap.c|  373 
> ++
>  include/linux/i2c/twl.h  |   41 -
>  7 files changed, 454 insertions(+), 19 deletions(-)
>  create mode 100644 drivers/mfd/twl4030-script-omap.c
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index 076db52..d9b9858 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -184,6 +184,7 @@ CONFIG_TWL4030_WATCHDOG=y
>  CONFIG_MENELAUS=y
>  CONFIG_TWL4030_CORE=y
>  CONFIG_TWL4030_POWER=y
> +CONFIG_TWL4030_SCRIPT=m
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_TWL4030=y
>  CONFIG_REGULATOR_TPS65023=y
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 7b85585..7653329 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -329,6 +329,20 @@ static void omap_init_audio(void)
>  static inline void omap_init_audio(void) {}
>  #endif
>  
> +#ifdef CONFIG_ARCH_OMAP3
> +static struct platform_device omap_twl4030_script = {
> + .name   = "twl4030_script",
> + .id = -1,
> +};
> +
> +static void omap_init_twl4030_script(void)
> +{
> + platform_device_register(&omap_twl4030_script);
> +}
> +#else
> +static inline void omap_init_twl4030_script(void) {}
> +#endif

This should be if defined(CONFIG_TWL4030_SCRIPT) ||
defined(CONFIG_TWL4030_SCRIPT_MODULE) instead. And you should
probably only enable it based on some board specific flag.

>  #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
>  
>  #include 
> @@ -691,6 +705,7 @@ static int __init omap2_init_devices(void)
>   omap_init_sham();
>   omap_init_aes();
>   omap_init_vout();
> + omap_init_twl4030_script();
>  
>   return 0;
>  }

The changes above probably also conflict with what I have
in devel-cleanup branch. So maybe split it so I can take this
part?

Also, please note that patches touching arch/arm/*omap*/
files should also be sent with linux-arm-kernel list Cc'd.

Regards,

Tony

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 3/5] arm: omap: usb: device name change for the clk names of usbhs

[Premi, Sanjeev]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> Munegowda, Keshava
> Sent: Wednesday, May 11, 2011 7:35 PM
> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
> Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; 
> part...@india.ti.com
> Subject: [PATCH 3/5] arm: omap: usb: device name change for 
> the clk names of usbhs

[snip]...[snip]

> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  
> -#define USBHS_DRIVER_NAME"usbhs-omap"
> +#define USBHS_DRIVER_NAME"usbhs_omap"
>  #define OMAP_EHCI_DEVICE "ehci-omap"
>  #define OMAP_OHCI_DEVICE "ohci-omap3"

[sp] Shouldn't we be consistent in using minus/dash and
 underscore in the device names?

~sanjeev

>  
> -- 
> 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
> --
To unsubscribe from this list: send the line "unsubscribe 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 v10 3/7] MFD: TWL4030: Modifying the macro name Main_Ref to all caps

[Tony Lindgren]

* Lesly A M  [110506 06:14]:
> Modifying the macro name Main_Ref to all caps(MAIN_REF).

This may get counted as "crazy churn" patch.. Please provide
some reason for doing this in the patch description.

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

Re: [PATCH V2 15/16] OMAP: hsmmc: add platform data for eMMC hardware reset gpio

[Tony Lindgren]

* Adrian Hunter  [110506 02:11]:
> eMMC may have a hardware reset line connected to a gpio,
> so pass it to the driver.
> 
> Signed-off-by: Adrian Hunter 

This looks safe to merge via MMC list:

Acked-by: Tony Lindgren 

> ---
>  arch/arm/mach-omap2/hsmmc.c   |5 +
>  arch/arm/mach-omap2/hsmmc.h   |1 +
>  arch/arm/plat-omap/include/plat/mmc.h |1 +
>  3 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index c37ba4f..a8078c1 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -472,6 +472,11 @@ static int __init omap_hsmmc_pdata_init(struct 
> omap2_hsmmc_info *c,
>   mmc->slots[0].switch_pin = c->gpio_cd;
>   mmc->slots[0].gpio_wp = c->gpio_wp;
>  
> + if (c->gpio_hw_reset)
> + mmc->slots[0].gpio_hw_reset = c->gpio_hw_reset;
> + else
> + mmc->slots[0].gpio_hw_reset = -EINVAL;
> +
>   mmc->slots[0].remux = c->remux;
>   mmc->slots[0].init_card = c->init_card;
>  
> diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
> index 0f2a87e..b78ed41 100644
> --- a/arch/arm/mach-omap2/hsmmc.h
> +++ b/arch/arm/mach-omap2/hsmmc.h
> @@ -22,6 +22,7 @@ struct omap2_hsmmc_info {
>   boolnomux;  /* No default muxing for this slot */
>   int gpio_cd;/* or -EINVAL */
>   int gpio_wp;/* or -EINVAL */
> + int gpio_hw_reset;  /* hardware reset */
>   char*name;  /* or NULL for default */
>   struct device *dev; /* returned: pointer to mmc adapter */
>   int ocr_mask;   /* temporary HACK */
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
> b/arch/arm/plat-omap/include/plat/mmc.h
> index e3c9b20..9b69b7e 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -119,6 +119,7 @@ struct omap_mmc_platform_data {
>  
>   int switch_pin; /* gpio (card detect) */
>   int gpio_wp;/* gpio (write protect) */
> + int gpio_hw_reset;  /* gpio (hardware reset) */
>  
>   int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
>   int (*set_power)(struct device *dev, int slot,
> -- 
> 1.7.0.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 13/16] OMAP: hsmmc: implement clock switcher

[Tony Lindgren]

* Adrian Hunter  [110506 02:13]:
> From: Andy Shevchenko 
> 
> There are 3 new platform data methods which should help us to do a clock
> switching when notification is happened or request is started.
> 
> The purpose of the patch is to avoid high frequency of MMC controller on low
> OPPs due to an HW bug in OMAP 3630.
...

> +static int hsmmc_clk_notifier(struct notifier_block *nb, unsigned long event,
> +   void *data)
> +{
> + struct cpufreq_freqs *freqs = data;
> + unsigned int threshold = 40; /* between opp1 and opp2 */
> +
> + switch (event) {
> + case CPUFREQ_PRECHANGE:
> + if (freqs->new < threshold && freqs->old >= threshold) {
> + /* opp2 -> opp1 */
> + hsmmc_max_freq = HSMMC_MAX_FREQ >> 1;
> +
> + /* Timeout is 1 sec */
> + if (!wait_event_timeout(hsmmc_max_freq_wq,
> + hsmmc_max_freq_ok(),
> + msecs_to_jiffies(1000)))
> + pr_err("MMC violates maximum frequency "
> +"constraint\n");
> + }
> + break;
> + case CPUFREQ_POSTCHANGE:
> + if (freqs->old < threshold && freqs->new >= threshold) {
> + /* opp1 -> opp2 */
> + hsmmc_max_freq = HSMMC_MAX_FREQ;
> + }
> + break;
> + default:
> + break;
> + }
> +
> + return NOTIFY_DONE;
> +}

I think the cpufreq notifier code should be in the driver, the platform
init code should just prepare things for the driver.

Regards,

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

Re: [PATCH v2] arm: omap2plus: GPIO cleanup

[Tony Lindgren]

* Igor Grinberg  [110511 00:35]:
> ping!
> 
> On 05/03/11 18:22, Igor Grinberg wrote:
> 
> > use gpio_request_() instead of multiple gpiolib calls,
> > remove unneeded variables, etc.

Thanks that shrinks down the board files nicely. Applying to
devel-cleanup.

Regards,

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

Re: [PATCH V3] OMAP3+: SR Layer Cleanup

[Kevin Hilman]

"Menon, Nishanth"  writes:

> On Wed, May 11, 2011 at 04:12, Shweta Gulati  wrote:
>> To set sr ntarget values  for all volt_domain,
>> volt_table is retrieved by doing a look_up of 'vdd_name'
>> field from omap_hwmod but voltage domain pointer does not
>> belong to omap_hwmod and is not used anywhere else.
>> As a part of voltage layer and SR Layer clean up volt
>> pointer is removed from omap_hwmod and added in dev
>> attributes of SR.
>>
>> Tested on OMAP3630 SDP and OMAP4430 SDP Board
>>
>> Signed-off-by: Shweta Gulati 
>> Cc: Nishanth Menon 
>> ---
>> V3:
>>   Changed the Subject and Rephrased Commit log as reviewed
>>   by Nishanth Menon.
>>  V2:
>>   Rebased on latest 'pm-wip/voltdm_a' branch.
> thanks.. actually it applies on voltdm_c branch as well :) 

Can this be taken as an Ack?  if so, Shweta please add an Acked-by from
Nishanth in your updated patch.  Thanks.

> might be
> good if kevin where to roll it up

Yes, I'll pick this one up (after Todd's comments are addressed.)

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: [v2 0/7] OMAP: GPIO: Use PM runtime framework

[Kevin Hilman]

Linus Walleij  writes:

[...]

> For TI I guess this currently means you simply cannot work
> on GPIO stuff until you know where to go with it unless you
> allow the OMAP GPIO authors to keep churning in arch/arm/*...
>
> That's unless Grant is OK with us moving stuff into
> drivers/gpio that does *not* use gpiolib and utilize singletons to
> get at the gpio_chip addresses (i.e. current form) and keep it
> churning like that until it can be refactored.

The churn will happen one way or another.  the only question is whether
it happens in drivers/gpio or arch/arm/*.

Grant, what's your feeling here.  How much ugliness are you willing to
tolerate in a bulk move to drivers/gpio.  At least for OMAP, I am
personally be working on the cleanup/move so I can work either way,
although I know Tony has an obvious preference for moving it to
drivers/gpio. :)

The OMAP driver is already using gpiolib.  The main ugliness in the OMAP
driver is the awful ifdeffery used to handle the differences across the
various SoCs in the OMAP family.  I've already got most of that cleaned
up[1].

Kevin

[1] http://marc.info/?l=linux-omap&m=130351321022770&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions

[kalle.jokiniemi]

Hi Tony,

 > -Original Message-
 > From: ext Jarkko Nikula [mailto:jhnik...@gmail.com]
 > Sent: 2. toukokuuta 2011 9:58
 > To: Jokiniemi Kalle (Nokia-SD/Tampere)
 > Cc: t...@atomide.com; broo...@opensource.wolfsonmicro.com; linux-
 > o...@vger.kernel.org
 > Subject: Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions

Did this one get pushed to linux-omap? Just checking on my old patches...

- Kalle


 > 
 > On Mon,  2 May 2011 09:28:53 +0300
 > Kalle Jokiniemi  wrote:
 > 
 > > The vaux2 (VCSI) regulator is left on by the bootloader
 > > in rx-51. Since there the product has shipped and there
 > > won't be any bootloader updates to fix this issue, we
 > > need to define all the regulators and declare full
 > > constraints for the regulator FW. This will allow the
 > > regulator FW to disable unused regulators.
 > >
 > > Also this helps in adding more fine grain regulator
 > > support for rx-51 in the future.
 > >
 > > Thanks for Mark Brown for pointing out the correct
 > > solution.
 > >
 > > Signed-off-by: Kalle Jokiniemi 
 > > Cc: Mark Brown 
 > > ---
 > 
 > Reviewed-by: Jarkko Nikula 



--
To unsubscribe from this list: send the line "unsubscribe 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

[Janorkar, Mayuresh]

> -Original Message-
> From: Igor Grinberg [mailto:grinb...@compulab.co.il]
> Sent: Thursday, May 12, 2011 2:08 PM
> To: Valkeinen, Tomi
> Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
> Stanley Miao
> Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> 
> On 05/12/11 10:16, Igor Grinberg wrote:
> 
> > On 05/12/11 09:40, Igor Grinberg wrote:
> >> On 05/11/11 09:32, Tomi Valkeinen wrote:
> >>> On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
> > +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;
> > +   }
>  If I test with this patch, this request is returning error.
> >>> Hmm. Well, the GPIOs are the same as in the old driver. However, the
> old
> >>> driver doesn't even seem to check if it manages to request the GPIOs,
> so
> >>> it may well be that it was failing also.
> >>>
> >>> Can you check from /sys/class/gpio/ if some of the GPIOs are already
> >>> allocated: 207, 199, 55, 56?
> >>>
> >>> The definition of two of those GPIOs look kinda funny to me: (15 +
> >>> OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
> >>> it sure doesn't sound ok to have a GPIO number that is 15 over the
> >>> maximum =).
> >>>
> >> This means that some kind of gpio expander is used.
> >> I bet those are twl gpios (or may be some other discrete chip).
> >> If those are twl gpios then you need to provide the .setup callback
> >> in struct twl4030_gpio_platform_data which will request and setup those
> gpios.
> >>
> > No need to wonder ;)
> >
> > Mayuresh,
> > try the attached patch (though some changes to Tomi's patch will be
> needed)
> > if it works, then we're good.
> 
> there is a typo in the function name:
> 
> s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/

Also,
> + };
> +
> + r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));

This should be ARRAY_SIZE(twl_gpios));

And one more thing:
We need to use regulator for OMAP3430.


Something like this:
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
+REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
+REGULATOR_SUPPLY("vdds_dsi", "omapdss_dsi1"),
+};
+
+static struct regulator_init_data ldp_vpll2 = {
+.constraints = {
+.name   = "VDVI",
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV   = true,
+.valid_modes_mask   = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies  = ARRAY_SIZE(ldp_vpll2_supplies),
+.consumer_supplies  = ldp_vpll2_supplies,
+};

@@ -340,6 +514,7 @@ static struct twl4030_platform_data ldp_twldata = {
.vmmc1  = &ldp_vmmc1,
.gpio   = &ldp_gpio_data,
.keypad = &ldp_kp_twl4030_data,
+   .vpll2  = &ldp_vpll2,
  
> 
> sorry...
> 
> 
> --
> 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

[Igor Grinberg]

On 05/12/11 10:16, Igor Grinberg wrote:

> On 05/12/11 09:40, Igor Grinberg wrote:
>> On 05/11/11 09:32, Tomi Valkeinen wrote:
>>> On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
> +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;
> + }
 If I test with this patch, this request is returning error.
>>> Hmm. Well, the GPIOs are the same as in the old driver. However, the old
>>> driver doesn't even seem to check if it manages to request the GPIOs, so
>>> it may well be that it was failing also.
>>>
>>> Can you check from /sys/class/gpio/ if some of the GPIOs are already
>>> allocated: 207, 199, 55, 56?
>>>
>>> The definition of two of those GPIOs look kinda funny to me: (15 +
>>> OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
>>> it sure doesn't sound ok to have a GPIO number that is 15 over the
>>> maximum =).
>>>
>> This means that some kind of gpio expander is used.
>> I bet those are twl gpios (or may be some other discrete chip).
>> If those are twl gpios then you need to provide the .setup callback
>> in struct twl4030_gpio_platform_data which will request and setup those 
>> gpios.
>>
> No need to wonder ;)
>
> Mayuresh,
> try the attached patch (though some changes to Tomi's patch will be needed)
> if it works, then we're good.

there is a typo in the function name:

s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/

sorry...


-- 
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 06/13] clocksource: add common mmio clocksource

[Thomas Gleixner]

On Tue, 10 May 2011, Russell King - ARM Linux wrote:

> Add a generic mmio clocksource, covering both 32-bit and 16-bit register
> access sizes, for up or down counters.  This can be used to easily
> create clocksources for simple counter-based implementations.
> 
> Cc: Alessandro Rubini 
> Cc: Colin Cross 
> Cc: Eric Miao 
> Cc: Erik Gilling 
> Cc: "Hans J. Koch" 
> Cc: Imre Kaloz 
> Cc: Krzysztof Halasa 
> Cc: Kukjin Kim 
> Cc: Lennert Buytenhek 
> Cc: Linus Walleij 
> Cc: linux-omap@vger.kernel.org
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Viresh Kumar 
> Cc: Wan ZongShun 
> Signed-off-by: Russell King 

Reviewed-by: Thomas Gleixner 

Please take this through the ARM tree. It's not conflicting with
anything in my tree.

--
To unsubscribe from this list: send the line "unsubscribe 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 13/13] clocksource: convert OMAP1 to 32-bit down counting clocksource

[Tony Lindgren]

* Russell King - ARM Linux  [110510 00:30]:
> Convert the OMAP1 32-bit down counting clocksource to the generic
> clocksource infrastructure.
> 
> Cc: Tony Lindgren 
> Cc: linux-omap@vger.kernel.org
> Signed-off-by: Russell King 

Tested-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe 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 04/13] ARM: omap1: convert to using readl/writel instead of volatile struct

[Tony Lindgren]

* Russell King - ARM Linux  [110510 00:25]:
> Cc: Tony Lindgren 
> Cc: linux-omap@vger.kernel.org
> Signed-off-by: Russell King 

Tested-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe 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 06/13] clocksource: add common mmio clocksource

[Tony Lindgren]

* Russell King - ARM Linux  [110510 01:44]:
> On Tue, May 10, 2011 at 10:38:41AM +0200, Sascha Hauer wrote:
> > You forgot to initialize cs->reg. With this:
> 
> Damnit.  Fixed.
> 
> > Tested-by: Sascha Hauer 

With cs->reg initialization and CONFIG_OMAP_MPU_TIMER=y things
boot tested on omap1 osk:

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

Re: [PATCH 03/13] ARM: omap1: delete useless interrupt handler

[Tony Lindgren]

* Kevin Hilman  [110510 05:46]:
> Russell King - ARM Linux  writes:
> 
> > The OMAP1 clocksource interrupt handler just increments a variable
> > which otherwise isn't used, so this seems to be unnecessary.  Tony
> > Lindgren confirms, so lets remove it.
> >
> > Cc: Tony Lindgren 
> > Cc: linux-omap@vger.kernel.org
> > Signed-off-by: Russell King 
> 
> Yes, this is left over legacy code from an earlier implementation.
> 
> Acked-by: Kevin Hilman 

Acked-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe 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

[Igor Grinberg]

On 05/12/11 09:40, Igor Grinberg wrote:

> On 05/11/11 09:32, Tomi Valkeinen wrote:
>> On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
 +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;
 +  }
>>> If I test with this patch, this request is returning error.
>> Hmm. Well, the GPIOs are the same as in the old driver. However, the old
>> driver doesn't even seem to check if it manages to request the GPIOs, so
>> it may well be that it was failing also.
>>
>> Can you check from /sys/class/gpio/ if some of the GPIOs are already
>> allocated: 207, 199, 55, 56?
>>
>> The definition of two of those GPIOs look kinda funny to me: (15 +
>> OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
>> it sure doesn't sound ok to have a GPIO number that is 15 over the
>> maximum =).
>>
> This means that some kind of gpio expander is used.
> I bet those are twl gpios (or may be some other discrete chip).
> If those are twl gpios then you need to provide the .setup callback
> in struct twl4030_gpio_platform_data which will request and setup those gpios.
>

No need to wonder ;)

Mayuresh,
try the attached patch (though some changes to Tomi's patch will be needed)
if it works, then we're good.

Tomi,
Your "ldp" patch does not apply, it would be nice if you rebase on top
of Tony's master.


-- 
Regards,
Igor.

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

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index f7d6038..ca92e43 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -203,10 +203,27 @@ static struct twl4030_usb_data ldp_usb_data = {
 	.usb_mode	= T2_USB_MODE_ULPI,
 };
 
+static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
+{
+	int r;
+
+	struct gpio twl_gpios[] = {
+		{gpio + 7 , GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
+		{gpio + 15, GPIOF_OUT_INIT_LOW, "LCD BACKLIGHT"},
+	};
+
+	r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
+	if (r)
+		pr_err("Cannot request LCD GPIOs, error %d\n", r);
+
+	return r;
+}
+
 static struct twl4030_gpio_platform_data ldp_gpio_data = {
 	.gpio_base	= OMAP_MAX_GPIO_LINES,
 	.irq_base	= TWL4030_GPIO_IRQ_BASE,
 	.irq_end	= TWL4030_GPIO_IRQ_END,
+	.setup		= ldp_twl_gpios_setup,
 };
 
 static struct twl4030_madc_platform_data ldp_madc_data = {