Re: [RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7" display for DEVKIT8000

2010-02-11 Thread Jaya Kumar
On Fri, Feb 12, 2010 at 3:41 AM, Thomas Weber  wrote:
> This patch adds the 7 inch display for the DEVKIT8000.
>
> Signed-off-by: Thomas Weber 
> ---
>  drivers/video/omap2/displays/Kconfig               |    8 ++-
>  drivers/video/omap2/displays/Makefile              |    1 +
>  .../video/omap2/displays/panel-innolux-at070tn83.c |  107 
> 
>  3 files changed, 115 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/video/omap2/displays/panel-innolux-at070tn83.c
>
> diff --git a/drivers/video/omap2/displays/Kconfig 
> b/drivers/video/omap2/displays/Kconfig
> index b12a59c..ca6b372 100644
> --- a/drivers/video/omap2/displays/Kconfig
> +++ b/drivers/video/omap2/displays/Kconfig
> @@ -5,7 +5,7 @@ config PANEL_GENERIC
>         tristate "Generic Panel"
>         help
>          Generic panel driver.
> -         Used for DVI output for Beagle and OMAP3 SDP.
> +         Used for DVI output for Beagle, Devkit8000 and OMAP3 SDP.
>
>  config PANEL_SHARP_LS037V7DW01
>         tristate "Sharp LS037V7DW01 LCD Panel"
> @@ -13,6 +13,12 @@ config PANEL_SHARP_LS037V7DW01
>         help
>           LCD Panel used in TI's SDP3430 and EVM boards
>
> +config PANEL_INNOLUX_AT070TN83
> +       tristate "Innolux AT070TN83 LCD Panel"
> +       depends on OMAP2_DSS
> +       help
> +        LCD Panel used in TimLL's Devkit8000
> +
>  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 9556464..087b192 100644
> --- a/drivers/video/omap2/displays/Makefile
> +++ b/drivers/video/omap2/displays/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
>  obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
>
>  obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
> +obj-$(CONFIG_PANEL_INNOLUX_AT070TN83) += panel-innolux-at070tn83.o
> diff --git a/drivers/video/omap2/displays/panel-innolux-at070tn83.c 
> b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
> new file mode 100644
> index 000..f1d7f69
> --- /dev/null
> +++ b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
> @@ -0,0 +1,107 @@
> +/*
> + * LCD panel driver for Innolux AT70TN83
> + *
> + * Copyright (C) 2010 Thomas Weber 
> + *
> + * 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 
> +
> +static struct omap_video_timings innolux_at_timings = {
> +       .x_res          = 800,
> +       .y_res          = 480,
> +
> +       .pixel_clock    = 4,
> +
> +       .hsw            = 48,
> +       .hfp            = 1,
> +       .hbp            = 1,
> +
> +       .vsw            = 3,
> +       .vfp            = 12,
> +       .vbp            = 25,
> +};
> +
> +static int innolux_at_panel_probe(struct omap_dss_device *dssdev)
> +{
> +       dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> +               OMAP_DSS_LCD_IHS;
> +       dssdev->panel.acb = 0x28;
> +       dssdev->panel.timings = innolux_at_timings;
> +
> +       return 0;
> +}
> +

Hi Thomas, Tomi,

Just curious, does this patch imply that code like this needs to be
written for every single LCD type and resolution that can be connected
to omap2? Maybe there is a better way, like a common table of timings
and values that can be selected with a module option or even
autodetected.

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


RE: [RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7" display for DEVKIT8000

2010-02-11 Thread Hiremath, Vaibhav

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Thomas Weber
> Sent: Friday, February 12, 2010 1:11 AM
> Cc: Thomas Weber; Tomi Valkeinen; Thomas Weber; linux-
> o...@vger.kernel.org; linux-fb...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7" display
> for DEVKIT8000
> 
> This patch adds the 7 inch display for the DEVKIT8000.
[Hiremath, Vaibhav] Specify panel part/name here, patch description seems less 
descriptive.

> 
> Signed-off-by: Thomas Weber 
> ---
>  drivers/video/omap2/displays/Kconfig   |8 ++-
>  drivers/video/omap2/displays/Makefile  |1 +
>  .../video/omap2/displays/panel-innolux-at070tn83.c |  107
> 
>  3 files changed, 115 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/video/omap2/displays/panel-innolux-
> at070tn83.c
> 
> diff --git a/drivers/video/omap2/displays/Kconfig
> b/drivers/video/omap2/displays/Kconfig
> index b12a59c..ca6b372 100644
> --- a/drivers/video/omap2/displays/Kconfig
> +++ b/drivers/video/omap2/displays/Kconfig
> @@ -5,7 +5,7 @@ config PANEL_GENERIC
>  tristate "Generic Panel"
>  help
> Generic panel driver.
> -   Used for DVI output for Beagle and OMAP3 SDP.
> +   Used for DVI output for Beagle, Devkit8000 and OMAP3 SDP.
> 
[Hiremath, Vaibhav] I think we should remove board name from here, since all 
the OMAP board supporting DVI output would use this. 

>  config PANEL_SHARP_LS037V7DW01
>  tristate "Sharp LS037V7DW01 LCD Panel"
> @@ -13,6 +13,12 @@ config PANEL_SHARP_LS037V7DW01
>  help
>LCD Panel used in TI's SDP3430 and EVM boards
> 
> +config PANEL_INNOLUX_AT070TN83
> + tristate "Innolux AT070TN83 LCD Panel"
> + depends on OMAP2_DSS
> + help
> +  LCD Panel used in TimLL's Devkit8000
> +
>  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 9556464..087b192 100644
> --- a/drivers/video/omap2/displays/Makefile
> +++ b/drivers/video/omap2/displays/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
>  obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> 
>  obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
> +obj-$(CONFIG_PANEL_INNOLUX_AT070TN83) += panel-innolux-at070tn83.o
> diff --git a/drivers/video/omap2/displays/panel-innolux-at070tn83.c
> b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
> new file mode 100644
> index 000..f1d7f69
> --- /dev/null
> +++ b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
> @@ -0,0 +1,107 @@
> +/*
> + * LCD panel driver for Innolux AT70TN83
> + *
> + * Copyright (C) 2010 Thomas Weber 
> + *
> + * 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 
[Hiremath, Vaibhav] Do you need consumer.h file here?

> +#include 
> +
> +#include 
> +
> +static struct omap_video_timings innolux_at_timings = {
> + .x_res  = 800,
> + .y_res  = 480,
> +
> + .pixel_clock= 4,
> +
> + .hsw= 48,
> + .hfp= 1,
> + .hbp= 1,
> +
> + .vsw= 3,
> + .vfp= 12,
> + .vbp= 25,
> +};
> +
> +static int innolux_at_panel_probe(struct omap_dss_device *dssdev)
> +{
> + dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS;
> + dssdev->panel.acb = 0x28;
> + dssdev->panel.timings = innolux_at_timings;
> +
> + return 0;
> +}
> +
> +static void innolux_at_panel_remove(struct omap_dss_device *dssdev)
> +{
> +}
> +
> +static int innolux_at_panel_enable(struct omap_dss_device *dssdev)
> +{
> + return 0;
> +}
> +
> +static void innolux_at_panel_disable(struct omap_dss_device
> *dssdev)
> +{
> +
> + if (dssdev->platform_disable)
> + dssdev->platform_disable(dssdev);
> +
> +}
> +
> +static int innolux_at_panel_suspend(struct omap_dss_device *dssdev)
> +{
> + innolux_at_panel_disable(dssdev);
> + return 0;
> +}
> +
> +static int innolux_at_panel_resume(struct omap_dss_device *dssdev)
> +{
> + return innolux_at_panel_enable(dssdev);
> +}
> +
> +static struct omap_dss_driver innolux_at_d

[PATCH 19/19] OMAP4: MCPDM: Register McPDM platform device

2010-02-11 Thread Tony Lindgren
From: Jorge Eduardo Candelaria 

Add platform device for McPDM interface in OMAP4 and register
its memory and irq resources.

Signed-off-by: Jorge Eduardo Candelaria 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/devices.c |   37 +
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 59f92c8..3a3e357 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdefined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
 
@@ -192,6 +193,41 @@ void omap_mcbsp_register_board_cfg(struct 
omap_mcbsp_platform_data *config,
 
 /*-*/
 
+#if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
+   defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
+
+static struct resource mcpdm_resources[] = {
+   {
+   .name   = "mcpdm_mem",
+   .start  = OMAP44XX_MCPDM_BASE,
+   .end= OMAP44XX_MCPDM_BASE + SZ_4K,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .name   = "mcpdm_irq",
+   .start  = INT_44XX_MCPDM_IRQ,
+   .end= INT_44XX_MCPDM_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device omap_mcpdm_device = {
+   .name   = "omap-mcpdm",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(mcpdm_resources),
+   .resource   = mcpdm_resources,
+};
+
+static void omap_init_mcpdm(void)
+{
+   (void) platform_device_register(&omap_mcpdm_device);
+}
+#else
+static inline void omap_init_mcpdm(void) {}
+#endif
+
+/*-*/
+
 #if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 
@@ -385,6 +421,7 @@ static int __init omap_init_devices(void)
omap_init_dsp();
omap_init_kp();
omap_init_rng();
+   omap_init_mcpdm();
omap_init_uwire();
omap_init_wdt();
return 0;

--
To unsubscribe from this list: send the line "unsubscribe 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 18/19] ARM: OMAP4: Add McPDM base address

2010-02-11 Thread Tony Lindgren
From: Jorge Eduardo Candelaria 

Define McPDM physical and L3 base address for OMAP4

Signed-off-by: Jorge Eduardo Candelaria 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/omap44xx.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h 
b/arch/arm/plat-omap/include/plat/omap44xx.h
index ef870de..2068b39 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -41,6 +41,8 @@
 #define OMAP44XX_SCU_BASE  0x4824
 #define OMAP44XX_LOCAL_TWD_BASE0x48240600
 #define OMAP44XX_WKUPGEN_BASE  0x48281000
+#define OMAP44XX_MCPDM_BASE0x40132000
+#define OMAP44XX_MCPDM_L3_BASE 0x49032000
 
 #define OMAP44XX_MAILBOX_BASE  (L4_44XX_BASE + 0xF4000)
 

--
To unsubscribe from this list: send the line "unsubscribe 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 17/19] OMAP4: IRQ: Add McPDM IRQ definition

2010-02-11 Thread Tony Lindgren
From: Jorge Eduardo Candelaria 

Support for McPDM IRQs in OMAP4

Signed-off-by: Jorge Eduardo Candelaria 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/irqs.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/irqs.h 
b/arch/arm/plat-omap/include/plat/irqs.h
index 90d8370..e8205c1 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -442,7 +442,7 @@
 #define INT_44XX_PARTHASH_IRQ  (79 + IRQ_GIC_START)
 #define INT_44XX_MMC3_IRQ  (94 + IRQ_GIC_START)
 #define INT_44XX_MMC4_IRQ  (96 + IRQ_GIC_START)
-
+#define INT_44XX_MCPDM_IRQ (112 + IRQ_GIC_START)
 
 /* Max. 128 level 2 IRQs (OMAP1610), 192 GPIOs (OMAP730/850) and
  * 16 MPUIO lines */

--
To unsubscribe from this list: send the line "unsubscribe 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 16/19] arm: omap: kill compile warning on board-4430-sdp.c

2010-02-11 Thread Tony Lindgren
From: Felipe Balbi 

sdp4430_uart_config isn't used anywhere, so remove it.

Signed-off-by: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-4430sdp.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index cc4c00d..793ce8f 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,10 +38,6 @@ static struct platform_device *sdp4430_devices[] __initdata 
= {
&sdp4430_lcd_device,
 };
 
-static struct omap_uart_config sdp4430_uart_config __initdata = {
-   .enabled_uarts  = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
-};
-
 static struct omap_lcd_config sdp4430_lcd_config __initdata = {
.ctrl_name  = "internal",
 };

--
To unsubscribe from this list: send the line "unsubscribe 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 15/19] AM35xx: Update irq.h for AM35xx IPSS module interrupts

2010-02-11 Thread Tony Lindgren
From: Vaibhav Hiremath 

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/irqs.h |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/irqs.h 
b/arch/arm/plat-omap/include/plat/irqs.h
index c0ab7c8..90d8370 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -344,6 +344,16 @@
 
 #defineINT_34XX_BENCH_MPU_EMUL 3
 
+#define INT_35XX_HECC0_IRQ 24
+#define INT_35XX_HECC1_IRQ 28
+#define INT_35XX_EMAC_C0_RXTHRESH_IRQ  67
+#define INT_35XX_EMAC_C0_RX_PULSE_IRQ  68
+#define INT_35XX_EMAC_C0_TX_PULSE_IRQ  69
+#define INT_35XX_EMAC_C0_MISC_PULSE_IRQ70
+#define INT_35XX_USBOTG_IRQ71
+#define INT_35XX_CCDC_VD0_IRQ  88
+#define INT_35XX_CCDC_VD1_IRQ  92
+#define INT_35XX_CCDC_VD2_IRQ  93
 
 #define IRQ_GIC_START  32
 #define INT_44XX_LOCALTIMER_IRQ29

--
To unsubscribe from this list: send the line "unsubscribe 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 14/19] AM35xx: Add AM35xx intr_clr & sw_rst cntrl reg bit definition

2010-02-11 Thread Tony Lindgren
From: Vaibhav Hiremath 

AM3517/05 has few additional control module registers to control
the new IP's, like VPFE, USBOTG, CPGMAC.

This patch adds the bit defination for INTR_CLR and SW_RST control
register.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/control.h |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/control.h 
b/arch/arm/plat-omap/include/plat/control.h
index fcdc71b..2074473 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -274,6 +274,23 @@
 #define AM35XX_CPGMAC_FCLK_SHIFT9
 #define AM35XX_VPFE_FCLK_SHIFT  10
 
+/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+#define AM35XX_CPGMAC_C0_MISC_PULSE_CLRBIT(0)
+#define AM35XX_CPGMAC_C0_RX_PULSE_CLR  BIT(1)
+#define AM35XX_CPGMAC_C0_RX_THRESH_CLR BIT(2)
+#define AM35XX_CPGMAC_C0_TX_PULSE_CLR  BIT(3)
+#define AM35XX_USBOTGSS_INT_CLRBIT(4)
+#define AM35XX_VPFE_CCDC_VD0_INT_CLR   BIT(5)
+#define AM35XX_VPFE_CCDC_VD1_INT_CLR   BIT(6)
+#define AM35XX_VPFE_CCDC_VD2_INT_CLR   BIT(7)
+
+/*AM35XX CONTROL_IP_SW_RESET bits*/
+#define AM35XX_USBOTGSS_SW_RST BIT(0)
+#define AM35XX_CPGMACSS_SW_RST BIT(1)
+#define AM35XX_VPFE_VBUSP_SW_RST   BIT(2)
+#define AM35XX_HECC_SW_RST BIT(3)
+#define AM35XX_VPFE_PCLK_SW_RSTBIT(4)
+
 /*
  * CONTROL OMAP STATUS register to identify OMAP3 features
  */

--
To unsubscribe from this list: send the line "unsubscribe 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 13/19] AM35xx: Introduce am35xx.h file

2010-02-11 Thread Tony Lindgren
From: Vaibhav Hiremath 

Add base address definations for new AM35xx IPSS modules, like
VPFE, USBOTG, CPGMAC.

Please note that the OMAP34xx IVA2 memory space is being used for
AM35xx IPSS modules.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Sriramakrishnan 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-am3517evm.c |1 +
 arch/arm/mach-omap2/include/mach/am35xx.h |   26 ++
 2 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/include/mach/am35xx.h

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 3966846..aaa5c01 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -22,6 +22,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h 
b/arch/arm/mach-omap2/include/mach/am35xx.h
new file mode 100644
index 000..a705f94
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/am35xx.h
@@ -0,0 +1,26 @@
+/*:
+ * Address mappings and base address for AM35XX specific interconnects
+ * and peripherals.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Author: Sriramakrishnan 
+ *Vaibhav Hiremath 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_ARCH_AM35XX_H
+#define __ASM_ARCH_AM35XX_H
+
+/*
+ * Base addresses
+ * Note: OMAP3430 IVA2 memory space is being used for AM35xx IPSS modules
+ */
+#define AM35XX_IPSS_EMAC_BASE  0x5C00
+#define AM35XX_IPSS_USBOTGSS_BASE  0x5C04
+#define AM35XX_IPSS_HECC_BASE  0x5C05
+#define AM35XX_IPSS_VPFE_BASE  0x5C06
+
+#endif /*  __ASM_ARCH_AM35XX_H */

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


[PATCH 12/19] omap3: pm: Add T2 Keypad as a wakeup source

2010-02-11 Thread Tony Lindgren
From: Lesly A M 

Changes for setting the padconf value for sys_nirq line which is
connected to T2 INTR1. This will fix the T2 keypad wakeup.

Signed-off-by: Lesly A M 
Signed-off-by: Teerth Reddy 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-zoom-peripherals.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4278d5e..9a0821f 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include "mux.h"
 #include "hsmmc.h"
 
 /* Zoom2 has Qwerty keyboard*/
@@ -263,9 +264,17 @@ static int __init omap_i2c_init(void)
return 0;
 }
 
+static void enable_board_wakeup_source(void)
+{
+   /* T2 interrupt line (keypad) */
+   omap_mux_init_signal("sys_nirq",
+   OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
+}
+
 void __init zoom_peripherals_init(void)
 {
omap_i2c_init();
omap_serial_init();
usb_musb_init();
+   enable_board_wakeup_source();
 }

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


[PATCH 11/19] omap3: Clean-up for omap_mux_init

2010-02-11 Thread Tony Lindgren
Get rid of the ifdeffery in omap_mux_init by creating
omap_mux_init_package and omap_mux_init_signals functions.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/mux.c |   46 +
 1 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 5ee2372..986077f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -985,6 +985,38 @@ static void __init omap_mux_init_list(struct omap_mux 
*superset)
}
 }
 
+#ifdef CONFIG_OMAP_MUX
+
+static void omap_mux_init_package(struct omap_mux *superset,
+ struct omap_mux *package_subset,
+ struct omap_ball *package_balls)
+{
+   if (package_subset)
+   omap_mux_package_fixup(package_subset, superset);
+   if (package_balls)
+   omap_mux_package_init_balls(package_balls, superset);
+}
+
+static void omap_mux_init_signals(struct omap_board_mux *board_mux)
+{
+   omap_mux_set_cmdline_signals();
+   omap_mux_write_array(board_mux);
+}
+
+#else
+
+static void omap_mux_init_package(struct omap_mux *superset,
+ struct omap_mux *package_subset,
+ struct omap_ball *package_balls)
+{
+}
+
+static void omap_mux_init_signals(struct omap_board_mux *board_mux)
+{
+}
+
+#endif
+
 int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
struct omap_mux *superset,
struct omap_mux *package_subset,
@@ -1001,19 +1033,9 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
return -ENODEV;
}
 
-#ifdef CONFIG_OMAP_MUX
-   if (package_subset)
-   omap_mux_package_fixup(package_subset, superset);
-   if (package_balls)
-   omap_mux_package_init_balls(package_balls, superset);
-#endif
-
+   omap_mux_init_package(superset, package_subset, package_balls);
omap_mux_init_list(superset);
-
-#ifdef CONFIG_OMAP_MUX
-   omap_mux_set_cmdline_signals();
-   omap_mux_write_array(board_mux);
-#endif
+   omap_mux_init_signals(board_mux);
 
return 0;
 }

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


[PATCH 10/19] omap_hsmmc: allow compile without regulator framework

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

It is still possible to use the omap_hsmmc module
without the regulator framework.  Accordingly, ifdef
out regulator-specific functions.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 drivers/mmc/host/omap_hsmmc.c |  133 -
 1 files changed, 79 insertions(+), 54 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index af37477..83f0aff 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -236,6 +236,8 @@ static int omap_hsmmc_resume_cdirq(struct device *dev, int 
slot)
 
 #endif
 
+#ifdef CONFIG_REGULATOR
+
 static int omap_hsmmc_1_set_power(struct device *dev, int slot, int power_on,
  int vdd)
 {
@@ -357,59 +359,6 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int 
slot, int sleep,
return regulator_enable(host->vcc_aux);
 }
 
-static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
-{
-   int ret;
-
-   if (gpio_is_valid(pdata->slots[0].switch_pin)) {
-   pdata->suspend = omap_hsmmc_suspend_cdirq;
-   pdata->resume = omap_hsmmc_resume_cdirq;
-   if (pdata->slots[0].cover)
-   pdata->slots[0].get_cover_state =
-   omap_hsmmc_get_cover_state;
-   else
-   pdata->slots[0].card_detect = omap_hsmmc_card_detect;
-   pdata->slots[0].card_detect_irq =
-   gpio_to_irq(pdata->slots[0].switch_pin);
-   ret = gpio_request(pdata->slots[0].switch_pin, "mmc_cd");
-   if (ret)
-   return ret;
-   ret = gpio_direction_input(pdata->slots[0].switch_pin);
-   if (ret)
-   goto err_free_sp;
-   } else
-   pdata->slots[0].switch_pin = -EINVAL;
-
-   if (gpio_is_valid(pdata->slots[0].gpio_wp)) {
-   pdata->slots[0].get_ro = omap_hsmmc_get_wp;
-   ret = gpio_request(pdata->slots[0].gpio_wp, "mmc_wp");
-   if (ret)
-   goto err_free_cd;
-   ret = gpio_direction_input(pdata->slots[0].gpio_wp);
-   if (ret)
-   goto err_free_wp;
-   } else
-   pdata->slots[0].gpio_wp = -EINVAL;
-
-   return 0;
-
-err_free_wp:
-   gpio_free(pdata->slots[0].gpio_wp);
-err_free_cd:
-   if (gpio_is_valid(pdata->slots[0].switch_pin))
-err_free_sp:
-   gpio_free(pdata->slots[0].switch_pin);
-   return ret;
-}
-
-static void omap_hsmmc_gpio_free(struct omap_mmc_platform_data *pdata)
-{
-   if (gpio_is_valid(pdata->slots[0].gpio_wp))
-   gpio_free(pdata->slots[0].gpio_wp);
-   if (gpio_is_valid(pdata->slots[0].switch_pin))
-   gpio_free(pdata->slots[0].switch_pin);
-}
-
 static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
 {
struct regulator *reg;
@@ -488,6 +437,82 @@ static void omap_hsmmc_reg_put(struct omap_hsmmc_host 
*host)
mmc_slot(host).set_sleep = NULL;
 }
 
+static inline int omap_hsmmc_have_reg(void)
+{
+   return 1;
+}
+
+#else
+
+static inline int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
+{
+   return -EINVAL;
+}
+
+static inline void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
+{
+}
+
+static inline int omap_hsmmc_have_reg(void)
+{
+   return 0;
+}
+
+#endif
+
+static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
+{
+   int ret;
+
+   if (gpio_is_valid(pdata->slots[0].switch_pin)) {
+   pdata->suspend = omap_hsmmc_suspend_cdirq;
+   pdata->resume = omap_hsmmc_resume_cdirq;
+   if (pdata->slots[0].cover)
+   pdata->slots[0].get_cover_state =
+   omap_hsmmc_get_cover_state;
+   else
+   pdata->slots[0].card_detect = omap_hsmmc_card_detect;
+   pdata->slots[0].card_detect_irq =
+   gpio_to_irq(pdata->slots[0].switch_pin);
+   ret = gpio_request(pdata->slots[0].switch_pin, "mmc_cd");
+   if (ret)
+   return ret;
+   ret = gpio_direction_input(pdata->slots[0].switch_pin);
+   if (ret)
+   goto err_free_sp;
+   } else
+   pdata->slots[0].switch_pin = -EINVAL;
+
+   if (gpio_is_valid(pdata->slots[0].gpio_wp)) {
+   pdata->slots[0].get_ro = omap_hsmmc_get_wp;
+   ret = gpio_request(pdata->slots[0].gpio_wp, "mmc_wp");
+   if (ret)
+   goto err_free_cd;
+   ret = gpio_direction_input(pdata->slots[0].gpio_wp);
+   if (ret)
+   goto err_free_wp;
+   } else
+   pdata->slots[0].gpio_wp = -EINVAL;
+
+   return 0;
+
+err_free_wp:
+   g

[PATCH 09/19] omap_hsmmc: Allow for a shared VccQ

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

EMMC can have two voltage supplies, Vcc and VccQ
which are implemented in the code as consumer
supplies vmmc and vmmc_aux.

If the regulator that supplies vmmc_aux is shared
with other consumers, then sending it to sleep
will disrupt those consumers.  However, the
TWL4030-family regulators may have OFF remapped
to SLEEP, in which case 'regulator_disable()'
will put the regulator to sleep only when all
consumers are disabled - which is the desired
behaviour.

This patch adds a platform data field to allow
that option.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/hsmmc.c   |3 +++
 arch/arm/mach-omap2/hsmmc.h   |1 +
 arch/arm/plat-omap/include/plat/mmc.h |3 +++
 drivers/mmc/host/omap_hsmmc.c |   16 +++-
 4 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index e4ab123..9ad2295 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -205,6 +205,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
if (c->no_off)
mmc->slots[0].no_off = 1;
 
+   if (c->vcc_aux_disable_is_sleep)
+   mmc->slots[0].vcc_aux_disable_is_sleep = 1;
+
/* NOTE:  MMC slots should have a Vcc regulator set up.
 * This may be from a TWL4030-family chip, another
 * controllable regulator, or a fixed supply.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 2453a7a..36f0ba8 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -15,6 +15,7 @@ struct omap2_hsmmc_info {
boolnonremovable;   /* Nonremovable e.g. eMMC */
boolpower_saving;   /* Try to sleep or power off when possible */
boolno_off; /* power_saving and power is not to go off */
+   boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
char*name;  /* or NULL for default */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index b463949..a1bac07 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -99,6 +99,9 @@ struct omap_mmc_platform_data {
/* If using power_saving and the MMC power is not to go off */
unsigned no_off:1;
 
+   /* Regulator off remapped to sleep */
+   unsigned vcc_aux_disable_is_sleep:1;
+
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
 
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d2fad58..af37477 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -347,7 +347,14 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int 
slot, int sleep,
err = regulator_set_mode(host->vcc, mode);
if (err)
return err;
-   return regulator_set_mode(host->vcc_aux, mode);
+
+   if (!mmc_slot(host).vcc_aux_disable_is_sleep)
+   return regulator_set_mode(host->vcc_aux, mode);
+
+   if (sleep)
+   return regulator_disable(host->vcc_aux);
+   else
+   return regulator_enable(host->vcc_aux);
 }
 
 static int omap_hsmmc_gpio_init(struct omap_mmc_platform_data *pdata)
@@ -1982,6 +1989,13 @@ static int __init omap_hsmmc_probe(struct 
platform_device *pdev)
else
mmc->ops= &omap_hsmmc_ops;
 
+   /*
+* If regulator_disable can only put vcc_aux to sleep then there is
+* no off state.
+*/
+   if (mmc_slot(host).vcc_aux_disable_is_sleep)
+   mmc_slot(host).no_off = 1;
+
mmc->f_min  = 40;
mmc->f_max  = 5200;
 

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


[PATCH 08/19] omap_hsmmc: Ensure regulator enable / disable are paired

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

Stop using 'regulator_is_enabled()' and just pair enables
with disables so that the regulator reference counts can
work correctly.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 drivers/mmc/host/omap_hsmmc.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index cb94044..d2fad58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -296,11 +296,8 @@ static int omap_hsmmc_23_set_power(struct device *dev, int 
slot, int power_on,
ret = mmc_regulator_set_ocr(host->vcc, 0);
}
} else {
-   if (host->vcc_aux) {
-   ret = regulator_is_enabled(host->vcc_aux);
-   if (ret > 0)
-   ret = regulator_disable(host->vcc_aux);
-   }
+   if (host->vcc_aux)
+   ret = regulator_disable(host->vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(host->vcc, 0);
}
@@ -1975,7 +1972,7 @@ static int __init omap_hsmmc_probe(struct platform_device 
*pdev)
host->slot_id   = 0;
host->mapbase   = res->start;
host->base  = ioremap(host->mapbase, SZ_4K);
-   host->power_mode = -1;
+   host->power_mode = MMC_POWER_OFF;
 
platform_set_drvdata(pdev, host);
INIT_WORK(&host->mmc_carddetect_work, omap_hsmmc_detect);

--
To unsubscribe from this list: send the line "unsubscribe 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 07/19] omap_hsmmc: Fix disable timeouts

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

Disable timeouts are in msecs not jiffies.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 drivers/mmc/host/omap_hsmmc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e15d0f4..cb94044 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1620,7 +1620,7 @@ static int omap_hsmmc_enabled_to_disabled(struct 
omap_hsmmc_host *host)
if (host->power_mode == MMC_POWER_OFF)
return 0;
 
-   return msecs_to_jiffies(OMAP_MMC_SLEEP_TIMEOUT);
+   return OMAP_MMC_SLEEP_TIMEOUT;
 }
 
 /* Handler for [DISABLED -> REGSLEEP / CARDSLEEP] transition */
@@ -1663,7 +1663,7 @@ static int omap_hsmmc_disabled_to_sleep(struct 
omap_hsmmc_host *host)
mmc_slot(host).card_detect ||
(mmc_slot(host).get_cover_state &&
 mmc_slot(host).get_cover_state(host->dev, host->slot_id)))
-   return msecs_to_jiffies(OMAP_MMC_OFF_TIMEOUT);
+   return OMAP_MMC_OFF_TIMEOUT;
 
return 0;
 }

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


[PATCH 06/19] omap_hsmmc: Allow for power saving without going off

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

An eMMC may be always powered on, so that the lowest
power saving state possible is sleeping. Add a field
to the platform data to indicate that.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/hsmmc.c   |3 +++
 arch/arm/mach-omap2/hsmmc.h   |1 +
 arch/arm/plat-omap/include/plat/mmc.h |3 +++
 drivers/mmc/host/omap_hsmmc.c |6 ++
 4 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 4a05c37..e4ab123 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -202,6 +202,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
if (c->power_saving)
mmc->slots[0].power_saving = 1;
 
+   if (c->no_off)
+   mmc->slots[0].no_off = 1;
+
/* NOTE:  MMC slots should have a Vcc regulator set up.
 * This may be from a TWL4030-family chip, another
 * controllable regulator, or a fixed supply.
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f641f59..2453a7a 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -14,6 +14,7 @@ struct omap2_hsmmc_info {
boolcover_only; /* No card detect - just cover switch */
boolnonremovable;   /* Nonremovable e.g. eMMC */
boolpower_saving;   /* Try to sleep or power off when possible */
+   boolno_off; /* power_saving and power is not to go off */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
char*name;  /* or NULL for default */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b23d32..b463949 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -96,6 +96,9 @@ struct omap_mmc_platform_data {
/* Try to sleep or power off when possible */
unsigned power_saving:1;
 
+   /* If using power_saving and the MMC power is not to go off */
+   unsigned no_off:1;
+
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
 
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2c5e15d..e15d0f4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1656,6 +1656,9 @@ static int omap_hsmmc_disabled_to_sleep(struct 
omap_hsmmc_host *host)
dev_dbg(mmc_dev(host->mmc), "DISABLED -> %s\n",
host->dpm_state == CARDSLEEP ? "CARDSLEEP" : "REGSLEEP");
 
+   if (mmc_slot(host).no_off)
+   return 0;
+
if ((host->mmc->caps & MMC_CAP_NONREMOVABLE) ||
mmc_slot(host).card_detect ||
(mmc_slot(host).get_cover_state &&
@@ -1671,6 +1674,9 @@ static int omap_hsmmc_sleep_to_off(struct omap_hsmmc_host 
*host)
if (!mmc_try_claim_host(host->mmc))
return 0;
 
+   if (mmc_slot(host).no_off)
+   return 0;
+
if (!((host->mmc->caps & MMC_CAP_NONREMOVABLE) ||
  mmc_slot(host).card_detect ||
  (mmc_slot(host).get_cover_state &&

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


[PATCH 05/19] omap: RX51: Remux to pull eMMC lines down when powering off

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

It has been discovered that, when eMMC is powered off, current
will flow from OMAP eMMC data pull-ups to the eMMC voltage supply.
Configuring pads for OMAP off-mode does not help because eMMC is
powered off independently of OMAP off-mode.  Hence the pads are
now re-configured when eMMC is powered on or off.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   43 +-
 arch/arm/mach-omap2/hsmmc.c  |8 +
 arch/arm/mach-omap2/hsmmc.h  |2 +
 arch/arm/plat-omap/include/plat/mmc.h|1 +
 4 files changed, 53 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ab07ca2..4377a4c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -209,6 +209,46 @@ static struct twl4030_madc_platform_data rx51_madc_data = {
.irq_line   = 1,
 };
 
+/* Enable input logic and pull all lines up when eMMC is on. */
+static struct omap_board_mux rx51_mmc2_on_mux[] = {
+   OMAP3_MUX(SDMMC2_CMD, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT0, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT1, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT2, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT3, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT4, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT5, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT6, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT7, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0),
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+/* Disable input logic and pull all lines down when eMMC is off. */
+static struct omap_board_mux rx51_mmc2_off_mux[] = {
+   OMAP3_MUX(SDMMC2_CMD, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT0, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT1, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT2, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT3, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT4, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT5, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT6, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   OMAP3_MUX(SDMMC2_DAT7, OMAP_PULL_ENA | OMAP_MUX_MODE0),
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+
+/*
+ * Current flows to eMMC when eMMC is off and the data lines are pulled up,
+ * so pull them down. N.B. we pull 8 lines because we are using 8 lines.
+ */
+static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
+{
+   if (power_on)
+   omap_mux_write_array(rx51_mmc2_on_mux);
+   else
+   omap_mux_write_array(rx51_mmc2_off_mux);
+}
+
 static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name   = "external",
@@ -222,11 +262,12 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name   = "internal",
.mmc= 2,
-   .wires  = 8,
+   .wires  = 8, /* See also rx51_mmc2_remux */
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable   = true,
.power_saving   = true,
+   .remux  = rx51_mmc2_remux,
},
{}  /* Terminator */
 };
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index cc7e77f..4a05c37 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -48,6 +48,9 @@ static void hsmmc1_before_set_reg(struct device *dev, int 
slot,
u32 reg, prog_io;
struct omap_mmc_platform_data *mmc = dev->platform_data;
 
+   if (mmc->slots[0].remux)
+   mmc->slots[0].remux(dev, slot, power_on);
+
/*
 * Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
 * card with Vcc regulator (from twl4030 or whatever).  OMAP has both
@@ -121,6 +124,9 @@ static void hsmmc23_before_set_reg(struct device *dev, int 
slot,
 {
struct omap_mmc_platform_data *mmc = dev->platform_data;
 
+   if (mmc->slots[0].remux)
+   mmc->slots[0].remux(dev, slot, power_on);
+
if (power_on) {
/* Only MMC2 supports a CLKIN */
if (mmc->slots[0].internal_clock) {
@@ -185,6 +191,8 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
mmc->slots[0].switch_pin = c->gpio_cd;
mmc->slots[0].gpio_wp = c->gpio_wp;
 
+   mmc->slots[0].remux = c->remux;
+
if (c->cover_only)
mmc->slots[0].cover = 1;
 
diff --git a/arch/arm/mach-

[PATCH 04/19] omap: Reconnect hsmmc context loss count

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

Call the PM context-loss count function, now that there
is a prototype for it.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/hsmmc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 2ba0d55..cc7e77f 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hsmmc.h"
 
@@ -34,8 +35,7 @@ static struct hsmmc_controller {
 
 static int hsmmc_get_context_loss(struct device *dev)
 {
-   /* FIXME: PM DPS not implemented yet */
-   return 0;
+   return omap_pm_get_dev_context_loss_count(dev);
 }
 
 #else

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


[PATCH 03/19] omap: Rename hsmmc symbols to reflect independence from twl4030

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

hsmmc.[ch] no longer has any dependency on twl4030
and variable names should be renamed to reflect that.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-2430sdp.c  |4 ++--
 arch/arm/mach-omap2/board-3430sdp.c  |4 ++--
 arch/arm/mach-omap2/board-cm-t35.c   |4 ++--
 arch/arm/mach-omap2/board-igep0020.c |4 ++--
 arch/arm/mach-omap2/board-ldp.c  |4 ++--
 arch/arm/mach-omap2/board-omap3beagle.c  |4 ++--
 arch/arm/mach-omap2/board-omap3evm.c |4 ++--
 arch/arm/mach-omap2/board-omap3pandora.c |4 ++--
 arch/arm/mach-omap2/board-omap3touchbook.c   |4 ++--
 arch/arm/mach-omap2/board-overo.c|4 ++--
 arch/arm/mach-omap2/board-rx51-peripherals.c |   18 --
 arch/arm/mach-omap2/board-zoom-peripherals.c |4 ++--
 arch/arm/mach-omap2/hsmmc.c  |   24 
 arch/arm/mach-omap2/hsmmc.h  |6 +++---
 14 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index a43c094..d6f55ef 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -182,7 +182,7 @@ static int __init omap2430_i2c_init(void)
return 0;
 }
 
-static struct twl4030_hsmmc_info mmc[] __initdata = {
+static struct omap2_hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
.wires  = 4,
@@ -201,7 +201,7 @@ static void __init omap_2430sdp_init(void)
 
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
-   twl4030_mmc_init(mmc);
+   omap2_hsmmc_init(mmc);
usb_musb_init();
board_smc91x_init();
 
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 6c7261b..5adef51 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -328,7 +328,7 @@ static struct twl4030_bci_platform_data sdp3430_bci_data = {
.tblsize= ARRAY_SIZE(sdp3430_batt_table),
 };
 
-static struct twl4030_hsmmc_info mmc[] = {
+static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
/* 8 bits (default) requires S6.3 == ON,
@@ -365,7 +365,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
 */
mmc[0].gpio_cd = gpio + 0;
mmc[1].gpio_cd = gpio + 1;
-   twl4030_mmc_init(mmc);
+   omap2_hsmmc_init(mmc);
 
/* link regulators to MMC adapters ... we "know" the
 * regulators will be set up only *after* we return.
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 58f6683..86903a4 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -364,7 +364,7 @@ static struct twl4030_keypad_data cm_t35_kp_data = {
.rep= 1,
 };
 
-static struct twl4030_hsmmc_info mmc[] = {
+static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires  = 4,
@@ -413,7 +413,7 @@ static int cm_t35_twl_gpio_setup(struct device *dev, 
unsigned gpio,
 
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
-   twl4030_mmc_init(mmc);
+   omap2_hsmmc_init(mmc);
 
/* link regulators to MMC adapters */
cm_t35_vmmc1_supply.dev = mmc[0].dev;
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index ea7bfba..adc1b46 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -121,7 +121,7 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies  = &igep2_vmmc1_supply,
 };
 
-static struct twl4030_hsmmc_info mmc[] = {
+static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires  = 4,
@@ -142,7 +142,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
 {
/* gpio + 0 is "mmc0_cd" (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
-   twl4030_mmc_init(mmc);
+   omap2_hsmmc_init(mmc);
 
/* link regulators to MMC adapters ... we "know" the
 * regulators will be set up only *after* we return.
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index f2b47cb..095adcb 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -359,7 +359,7 @@ static int __init omap_i2c_init(void)
return 0;
 }
 
-static struct twl4030_hsmmc_info mmc[] __initdata = {
+static struct omap2_hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
.wires  = 4,
@@ -396,7 +396,7 @@ static void __init omap_ldp_init(void)
omap_serial_init();
usb_musb_init();
 
-   twl4030_mmc_ini

[PATCH 02/19] omap: Rename mmc-twl4030 files to hsmmc

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

mmc-twl4030.[ch] no longer has any dependency on twl4030
and should be renamed to reflect that.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/Makefile |   28 +-
 arch/arm/mach-omap2/board-2430sdp.c  |2 +-
 arch/arm/mach-omap2/board-3430sdp.c  |2 +-
 arch/arm/mach-omap2/board-cm-t35.c   |2 +-
 arch/arm/mach-omap2/board-igep0020.c |2 +-
 arch/arm/mach-omap2/board-ldp.c  |2 +-
 arch/arm/mach-omap2/board-omap3beagle.c  |2 +-
 arch/arm/mach-omap2/board-omap3evm.c |2 +-
 arch/arm/mach-omap2/board-omap3pandora.c |2 +-
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 +-
 arch/arm/mach-omap2/board-overo.c|2 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
 arch/arm/mach-omap2/hsmmc.c  |4 ++--
 arch/arm/mach-omap2/hsmmc.h  |0 
 15 files changed, 28 insertions(+), 28 deletions(-)
 rename arch/arm/mach-omap2/{mmc-twl4030.c => hsmmc.c} (98%)
 rename arch/arm/mach-omap2/{mmc-twl4030.h => hsmmc.h} (100%)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index af5853f..dfc49a0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -87,43 +87,43 @@ obj-y   += 
$(i2c-omap-m) $(i2c-omap-y)
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
 obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OVERO)   += board-overo.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
-  mmc-twl4030.o \
+  hsmmc.o \
   board-sdp-flash.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o \
   board-rx51-sdram.o \
   board-rx51-peripherals.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom2.o \
   board-zoom-peripherals.o \
-  mmc-twl4030.o \
+  hsmmc.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_ZOOM3)  += board-zoom3.o \
   board-zoom-peripherals.o \
-  mmc-twl4030.o \
+  hsmmc.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
   board-zoom-peripherals.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_CM_T35)  += board-cm-t35.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
-  mmc-twl4030.o
+  hsmmc.o
 obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
 
 obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 18497b7..a43c094 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-oma

[PATCH 01/19] omap_hsmmc: Move gpio and regulator control from board file

2010-02-11 Thread Tony Lindgren
From: Adrian Hunter 

This patch moves the setup code for GPIO's and Voltage
Regulators from the board file mmc-twl4030.c to the
driver omap_hsmmc.c.  PBIAS and other system control
configuration remains in the board file.

Moving GPIO code to the driver makes the board initialisation
code independent of when GPIO's are defined.  That makes the
board initialisation now entirely independent of its original
twl4030 roots.

Moving Voltage Regulator code to the driver allows for further
development of regulator support in the core MMC code.  It also
permits the MMC core to be compiled as a module, because the
board code no longer calls MMC core functions.

Signed-off-by: Adrian Hunter 
Signed-off-by: Tony Lindgren 
---
 arch/arm/configs/rx51_defconfig   |4 
 arch/arm/mach-omap2/mmc-twl4030.c |  352 +++--
 arch/arm/mach-omap2/mmc-twl4030.h |4 
 arch/arm/plat-omap/include/plat/mmc.h |   28 ++-
 drivers/mmc/host/omap_hsmmc.c |  352 -
 5 files changed, 391 insertions(+), 349 deletions(-)

diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index b6eeebb..426ae94 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -1354,7 +1354,7 @@ CONFIG_USB_OTG_UTILS=y
 # CONFIG_USB_GPIO_VBUS is not set
 # CONFIG_ISP1301_OMAP is not set
 CONFIG_TWL4030_USB=y
-CONFIG_MMC=y
+CONFIG_MMC=m
 # CONFIG_MMC_DEBUG is not set
 # CONFIG_MMC_UNSAFE_RESUME is not set
 
@@ -1362,7 +1362,7 @@ CONFIG_MMC=y
 # MMC/SD/SDIO Card Drivers
 #
 CONFIG_MMC_BLOCK=m
-CONFIG_MMC_BLOCK_BOUNCE=y
+# CONFIG_MMC_BLOCK_BOUNCE is not set
 # CONFIG_SDIO_UART is not set
 # CONFIG_MMC_TEST is not set
 
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c 
b/arch/arm/mach-omap2/mmc-twl4030.c
index 8afe9dd..6f8f29e 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -9,26 +9,17 @@
  * 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 "mmc-twl4030.h"
 
-
-#if defined(CONFIG_REGULATOR) && \
-   (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
+#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 
 static u16 control_pbias_offset;
 static u16 control_devconf1_offset;
@@ -36,168 +27,9 @@ static u16 control_devconf1_offset;
 #define HSMMC_NAME_LEN 9
 
 static struct twl_mmc_controller {
-   struct omap_mmc_platform_data   *mmc;
-   /* Vcc == configured supply
-* Vcc_alt == optional
-*   -  MMC1, supply for DAT4..DAT7
-*   -  MMC2/MMC2, external level shifter voltage supply, for
-*  chip (SDIO, eMMC, etc) or transceiver (MMC2 only)
-*/
-   struct regulator*vcc;
-   struct regulator*vcc_aux;
charname[HSMMC_NAME_LEN + 1];
 } hsmmc[OMAP34XX_NR_MMC];
 
-static int twl_mmc_card_detect(int irq)
-{
-   unsigned i;
-
-   for (i = 0; i < ARRAY_SIZE(hsmmc); i++) {
-   struct omap_mmc_platform_data *mmc;
-
-   mmc = hsmmc[i].mmc;
-   if (!mmc)
-   continue;
-   if (irq != mmc->slots[0].card_detect_irq)
-   continue;
-
-   /* NOTE: assumes card detect signal is active-low */
-   return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
-   }
-   return -ENOSYS;
-}
-
-static int twl_mmc_get_ro(struct device *dev, int slot)
-{
-   struct omap_mmc_platform_data *mmc = dev->platform_data;
-
-   /* NOTE: assumes write protect signal is active-high */
-   return gpio_get_value_cansleep(mmc->slots[0].gpio_wp);
-}
-
-static int twl_mmc_get_cover_state(struct device *dev, int slot)
-{
-   struct omap_mmc_platform_data *mmc = dev->platform_data;
-
-   /* NOTE: assumes card detect signal is active-low */
-   return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
-}
-
-/*
- * MMC Slot Initialization.
- */
-static int twl_mmc_late_init(struct device *dev)
-{
-   struct omap_mmc_platform_data *mmc = dev->platform_data;
-   int ret = 0;
-   int i;
-
-   /* MMC/SD/SDIO doesn't require a card detect switch */
-   if (gpio_is_valid(mmc->slots[0].switch_pin)) {
-   ret = gpio_request(mmc->slots[0].switch_pin, "mmc_cd");
-   if (ret)
-   goto done;
-   ret = gpio_direction_input(mmc->slots[0].switch_pin);
-   if (ret)
-   goto err;
-   }
-
-   /* require at least main regulator */
-   for (i = 0; i < ARRAY_SIZE(hsmmc); i++) {
-   if (hsmmc[i].name == mmc->slots[0].name) {
-   struct regulator *reg;
-
-   

[PATCH 00/19] omap updates for 2.6.34 merge window, part 2

2010-02-11 Thread Tony Lindgren
Hi all,

Here is part 2 of the omap updates for 2.6.34. The MMC low-level
init patches have been already posted to linux-omap and linux-mmc.

Regards,

Tony

---

Adrian Hunter (10):
  omap_hsmmc: Move gpio and regulator control from board file
  omap: Rename mmc-twl4030 files to hsmmc
  omap: Rename hsmmc symbols to reflect independence from twl4030
  omap: Reconnect hsmmc context loss count
  omap: RX51: Remux to pull eMMC lines down when powering off
  omap_hsmmc: Allow for power saving without going off
  omap_hsmmc: Fix disable timeouts
  omap_hsmmc: Ensure regulator enable / disable are paired
  omap_hsmmc: Allow for a shared VccQ
  omap_hsmmc: allow compile without regulator framework

Felipe Balbi (1):
  arm: omap: kill compile warning on board-4430-sdp.c

Jorge Eduardo Candelaria (3):
  OMAP4: IRQ: Add McPDM IRQ definition
  ARM: OMAP4: Add McPDM base address
  OMAP4: MCPDM: Register McPDM platform device

Lesly A M (1):
  omap3: pm: Add T2 Keypad as a wakeup source

Tony Lindgren (1):
  omap3: Clean-up for omap_mux_init

Vaibhav Hiremath (3):
  AM35xx: Introduce am35xx.h file
  AM35xx: Add AM35xx intr_clr & sw_rst cntrl reg bit definition
  AM35xx: Update irq.h for AM35xx IPSS module interrupts


 arch/arm/configs/rx51_defconfig  |4 
 arch/arm/mach-omap2/Makefile |   28 +
 arch/arm/mach-omap2/board-2430sdp.c  |6 
 arch/arm/mach-omap2/board-3430sdp.c  |6 
 arch/arm/mach-omap2/board-4430sdp.c  |4 
 arch/arm/mach-omap2/board-am3517evm.c|1 
 arch/arm/mach-omap2/board-cm-t35.c   |6 
 arch/arm/mach-omap2/board-igep0020.c |6 
 arch/arm/mach-omap2/board-ldp.c  |6 
 arch/arm/mach-omap2/board-omap3beagle.c  |6 
 arch/arm/mach-omap2/board-omap3evm.c |6 
 arch/arm/mach-omap2/board-omap3pandora.c |6 
 arch/arm/mach-omap2/board-omap3touchbook.c   |6 
 arch/arm/mach-omap2/board-overo.c|6 
 arch/arm/mach-omap2/board-rx51-peripherals.c |   63 ++-
 arch/arm/mach-omap2/board-zoom-peripherals.c |   15 +
 arch/arm/mach-omap2/hsmmc.c  |  266 +
 arch/arm/mach-omap2/hsmmc.h  |   14 -
 arch/arm/mach-omap2/include/mach/am35xx.h|   26 +
 arch/arm/mach-omap2/mmc-twl4030.c|  542 --
 arch/arm/mach-omap2/mux.c|   46 ++
 arch/arm/plat-omap/devices.c |   37 ++
 arch/arm/plat-omap/include/plat/control.h|   17 +
 arch/arm/plat-omap/include/plat/irqs.h   |   12 +
 arch/arm/plat-omap/include/plat/mmc.h|   35 +-
 arch/arm/plat-omap/include/plat/omap44xx.h   |2 
 drivers/mmc/host/omap_hsmmc.c|  400 ++-
 27 files changed, 920 insertions(+), 652 deletions(-)
 create mode 100644 arch/arm/mach-omap2/hsmmc.c
 rename arch/arm/mach-omap2/{mmc-twl4030.h => hsmmc.h} (63%)
 create mode 100644 arch/arm/mach-omap2/include/mach/am35xx.h
 delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c

-- 
Signature
--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Validate node handle from user

2010-02-11 Thread Ameya Palande
Hi Ernesto,

On Thu, 2010-02-11 at 19:44 +0100, ext Ramos Falcon, Ernesto wrote:
> 
> >-Original Message-
> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> >Sent: Thursday, February 11, 2010 7:51 AM
> >To: Ramos Falcon, Ernesto
> >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
> >Hiroshi (Nokia-D/Helsinki)
> >Subject: RE: [PATCH] DSPBRIDGE: Validate node handle from user
> >
> >On Tue, 2010-02-09 at 18:52 +0100, ext Ramos Falcon, Ernesto wrote:
> >>
> >> >-Original Message-
> >> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> >> >Sent: Tuesday, February 09, 2010 11:32 AM
> >> >To: Ramos Falcon, Ernesto
> >> >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki);
> >Doyu
> >> >Hiroshi (Nokia-D/Helsinki)
> >> >Subject: Re: [PATCH] DSPBRIDGE: Validate node handle from user
> >> >
> >> >Hi Ernesto,
> >> >
> >> >On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
> >> >> From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
> >> >> From: Ernesto Ramos 
> >> >> Date: Fri, 29 Jan 2010 16:21:59 -0600
> >> >> Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
> >> >>
> >> >> Add checks to validate the node handles received from user.
> >> >>
> >> >> Signed-off-by: Ernesto Ramos 



> >> >If you have several nodes allocated by user space, then what you are
> >> >validating here is for any node! Is that ok?
> >> >
> >> >This validation and design itself doesn't look good to me. If we don't
> >> >want to trust user space, then instead of checking the node handle in
> >> >every function it is better to store all user space specific date inside
> >> >pr_context and use it from there.
> >> >
> >>
> >> The user can launch several nodes, how are we going to know which node
> >handle to use?
> >> I think we may need to receive at least one index or id to the node
> >handle.
> >
> >Yes, I guess thats the correct way! We need to maintain how many nodes
> >are allocated for a user process, and just make sure that this id /
> >index is <= number of allocated nodes.
> >
> 
> This comparison (<=) won't work because the user can eliminate nodes in the 
> middle of the list in which case we may need to maintain a list of valid 
> indexes. So I don't see any improvement with this way to validate the 
> handles. 

I agree :(

> I was thinking in an array an based on the index verify that the handle is 
> valid, independently of the number of nodes this would be very quick, but the 
> disadvantage would be that the number per process will be limited to the size 
> of the array.

Yes, array has disadvantage of size, but Linux also uses initial array
of 32 size for storing file pointers. 

On a second thought our problem looks similar to following use case:

User space application opens several files using open() system call and
receives handles for each. Now it passes handle to kernel using read(),
write() system calls to identify the file to operate on. How does kernel
validates the handle received from user space?

I guess we can base our solution on a bitmap to find next available
slot:

DECLARE_BITMAP();
find_first_zero_bit();
set_bit();
clear_bit();

And use array[free_slot] to store the pointer.

With solution I guess we can get rid of these checks ;)

Cheers,
Ameya.

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


Re: [PATCHv3] OMAP3: Serial: Improved sleep logic

2010-02-11 Thread Tony Lindgren
* Tero Kristo  [100211 03:48]:
> From: Tero Kristo 
> 
> This patch contains following improvements:
> - Only RX interrupt will now kick the sleep prevent timer
> - TX fifo status is checked before disabling clocks, this will prevent
>   on-going transmission to be cut
> - Smartidle is disabled while entering idle if we have data in the transmit
>   buffer because having this enabled would prevent wakeups from the TX
>   interrupt and this would cause pauses while sending large blocks of data
> - Sleep prevent timer is changed to use ktime_get() instead of a jiffy timer
>   as jiffy timers are not valid within idle loop (tick scheduler is stopped)
> - Added RX ignore timer for ignoring the first character received during
>   first millisecond of wakeup, this prevents garbage character to be received
>   in low sleep states

Cool, sounds like the way to go. Note that current mainline kernel has
the DEFAULT_TIMEOUT set to 0 because of the lost/corrupt characters.
 
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -36,13 +39,14 @@
>  #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV  0x52
>  #define UART_OMAP_WER0x17/* Wake-up enable register */
>  
> -#define DEFAULT_TIMEOUT (5 * HZ)
> +#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)

Won't apply to mainline..
  
> @@ -420,9 +443,9 @@ static void omap_uart_idle_init(struct omap_uart_state 
> *uart)
>  
>   uart->can_sleep = 0;
>   uart->timeout = DEFAULT_TIMEOUT;
> - setup_timer(&uart->timer, omap_uart_idle_timer,
> - (unsigned long) uart);
> - mod_timer(&uart->timer, jiffies + uart->timeout);
> +
> + uart->expire_time = ktime_add_ns(ktime_get(), uart->timeout);
> +
>   omap_uart_smart_idle_enable(uart, 0);
>  
>   if (cpu_is_omap34xx()) {

And the above should probably be:

if (uart->timeout)
uart->expire_time = ktime_add_ns(ktime_get(), uart->timeout); 

In order to support zero default timeout. Some other changes
may be necessary too if DEFAULT_TIMEOUT is 0.

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


[GIT PULL] omap fix for 2.6.33-rc7

2010-02-11 Thread Tony Lindgren
Hi Linus,

Please pull one omap fix from:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-fixes-for-linus

Regards,

Tony


The following changes since commit 80e1e823989ec44d8e35bdfddadbddcffec90424:
  Linus Torvalds (1):
Fix race in tty_fasync() properly

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-fixes-for-linus

Aaro Koskinen (1):
  OMAP: hsmmc: fix memory leak

 arch/arm/mach-omap2/mmc-twl4030.c |7 ++-
 1 files changed, 6 insertions(+), 1 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 v4] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread Ameya Palande
On Thu, 2010-02-11 at 22:54 +0100, ext Deepak Chitriki wrote:
> Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
> as NTFY_Notify() is already invoked in InputMsg().
> 
> Cc: Ameya Palande 
> Cc: Omar Ramirez Luna 
> Cc: Nishanth Menon 
> 
> Signed-off-by: Deepak Chitriki 

Acked-by: Ameya Palande 

> ---
> Ref:
> v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
> v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
> v2:http://marc.info/?l=linux-omap&m=126591341909124&w=2
> v3:http://marc.info/?l=linux-omap&m=126591743315572&w=2
> v4:Comment fixes from v3
> 
>  drivers/dsp/bridge/wmd/msg_sm.c |   10 ++
>  1 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
> index 3a275f1..8475e20 100644
> --- a/drivers/dsp/bridge/wmd/msg_sm.c
> +++ b/drivers/dsp/bridge/wmd/msg_sm.c
> @@ -295,11 +295,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
>  (struct list_head *)pMsgFrame);
>   if (LST_IsEmpty(hMsgQueue->msgUsedList))
>   SYNC_ResetEvent(hMsgQueue->hSyncEvent);
> - else {
> - NTFY_Notify(hMsgQueue->hNtfy,
> - DSP_NODEMESSAGEREADY);
> + else
>   SYNC_SetEvent(hMsgQueue->hSyncEvent);
> - }
>  
>   fGotMsg = true;
>   }
> @@ -347,11 +344,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
>   }
>   hMsgQueue->refCount--;
>   /* Reset the event if there are still queued messages */
> - if (!LST_IsEmpty(hMsgQueue->msgUsedList)) {
> - NTFY_Notify(hMsgQueue->hNtfy,
> - DSP_NODEMESSAGEREADY);
> + if (!LST_IsEmpty(hMsgQueue->msgUsedList))
>   SYNC_SetEvent(hMsgQueue->hSyncEvent);
> - }
>   /* Exit critical section */
>   (void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
>   }

--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread Deepak Chitriki
Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().

Cc: Ameya Palande 
Cc: Omar Ramirez Luna 
Cc: Nishanth Menon 

Signed-off-by: Deepak Chitriki 

---
Ref:
v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
v2:http://marc.info/?l=linux-omap&m=126591341909124&w=2
v3:http://marc.info/?l=linux-omap&m=126591743315572&w=2
v4:Comment fixes from v3

 drivers/dsp/bridge/wmd/msg_sm.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 3a275f1..8475e20 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -295,11 +295,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
   (struct list_head *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_ResetEvent(hMsgQueue->hSyncEvent);
-   else {
-   NTFY_Notify(hMsgQueue->hNtfy,
-   DSP_NODEMESSAGEREADY);
+   else
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }
 
fGotMsg = true;
}
@@ -347,11 +344,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue->refCount--;
/* Reset the event if there are still queued messages */
-   if (!LST_IsEmpty(hMsgQueue->msgUsedList)) {
-   NTFY_Notify(hMsgQueue->hNtfy,
-   DSP_NODEMESSAGEREADY);
+   if (!LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }
/* Exit critical section */
(void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
}
-- 
1.6.3.3

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


Re: [PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'

2010-02-11 Thread Tony Lindgren
* Tony Lindgren  [100211 12:43]:
> * Vimal Singh  [100210 21:16]:
> > From: Vimal Singh 
> > 
> > This patch adds 'board-zoom-flash.c', which could be utilized
> > by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
> > 
> > This does initialization for NAND device based on the 'cs' number
> > and partition information passed from board file (ex: board-zoom2.c).
> > 
> > Signed-off-by: Vimal Singh 
> > ---
> >  arch/arm/mach-omap2/board-zoom-flash.c|   85 
> > +
> >  arch/arm/mach-omap2/include/mach/board-zoom.h |   11 +++
> >  2 files changed, 96 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
> > 
> > diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
> > b/arch/arm/mach-omap2/board-zoom-flash.c
> > new file mode 100644
> > index 000..f2328a4
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/board-zoom-flash.c
> > @@ -0,0 +1,85 @@
> > +/*
> > + * board-zoom-flash.c
> > + *
> > + * Copyright (C) 2009 Texas Instruments Inc.
> > + * Vimal Singh 
> > + *
> > + * 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 
> > +
> > +#if defined(CONFIG_MTD_NAND_OMAP2) || \
> > +   defined(CONFIG_MTD_NAND_OMAP2_MODULE)
> > +
> > +/* Note that all values in this struct are in nanoseconds */
> > +static struct gpmc_timings nand_timings = {
> > +
> > +   .sync_clk = 0,
> > +
> > +   .cs_on = 0,
> > +   .cs_rd_off = 36,
> > +   .cs_wr_off = 36,
> > +
> > +   .adv_on = 6,
> > +   .adv_rd_off = 24,
> > +   .adv_wr_off = 36,
> > +
> > +   .we_off = 30,
> > +   .oe_off = 48,
> > +
> > +   .access = 54,
> > +   .rd_cycle = 72,
> > +   .wr_cycle = 72,
> > +
> > +   .wr_access = 30,
> > +   .wr_data_mux_bus = 0,
> > +};
> > +
> > +/* NAND chip access: 16 bit */
> > +static struct omap_nand_platform_data zoom_nand_data = {
> > +   .nand_setup = NULL,
> > +   .gpmc_t = &nand_timings,
> > +   .dma_channel= -1,   /* disable DMA in OMAP NAND driver */
> > +   .dev_ready  = NULL,
> > +   .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
> > +};
> > +
> > +/**
> > + * zoom_flash_init - Identify devices connected to GPMC and register.
> > + *
> > + * @return - void.
> > + */
> > +void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int 
> > cs)
> > +{
> > +   u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
> > +
> > +   zoom_nand_data.cs   = cs;
> > +   zoom_nand_data.parts= zoom_nand_parts[0].parts;
> > +   zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
> > +   zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
> > +   zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
> > +   GPMC_CS0_BASE +
> > +   cs * GPMC_CS_SIZE);
> 
> The gpmc_baseaddr and gpmc_cs_baseaddr should no longer be
> needed with gpmc-nand.c, right?

Yeah.. For now, I suggest you set the gpmc_baseaddr and
gpmc_cs_baseaddr in gpmc_nand_init() based on the results from
gpmc_cs_request.

That will allow us to remove the insane hardcoded gpmc virtual
addresses from all board-*.c files.

And then we can finally fix gpmc-nand.c driver not to go tinker
with the GPMC registers directly. All of that should be in
gpmc-nand.c using gpmc.c. The driver should be just a generic
NAND 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 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'

2010-02-11 Thread Tony Lindgren
* Vimal Singh  [100210 21:16]:
> From: Vimal Singh 
> 
> This patch adds 'board-zoom-flash.c', which could be utilized
> by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
> 
> This does initialization for NAND device based on the 'cs' number
> and partition information passed from board file (ex: board-zoom2.c).
> 
> Signed-off-by: Vimal Singh 
> ---
>  arch/arm/mach-omap2/board-zoom-flash.c|   85 
> +
>  arch/arm/mach-omap2/include/mach/board-zoom.h |   11 +++
>  2 files changed, 96 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
> 
> diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
> b/arch/arm/mach-omap2/board-zoom-flash.c
> new file mode 100644
> index 000..f2328a4
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-zoom-flash.c
> @@ -0,0 +1,85 @@
> +/*
> + * board-zoom-flash.c
> + *
> + * Copyright (C) 2009 Texas Instruments Inc.
> + * Vimal Singh 
> + *
> + * 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 
> +
> +#if defined(CONFIG_MTD_NAND_OMAP2) || \
> + defined(CONFIG_MTD_NAND_OMAP2_MODULE)
> +
> +/* Note that all values in this struct are in nanoseconds */
> +static struct gpmc_timings nand_timings = {
> +
> + .sync_clk = 0,
> +
> + .cs_on = 0,
> + .cs_rd_off = 36,
> + .cs_wr_off = 36,
> +
> + .adv_on = 6,
> + .adv_rd_off = 24,
> + .adv_wr_off = 36,
> +
> + .we_off = 30,
> + .oe_off = 48,
> +
> + .access = 54,
> + .rd_cycle = 72,
> + .wr_cycle = 72,
> +
> + .wr_access = 30,
> + .wr_data_mux_bus = 0,
> +};
> +
> +/* NAND chip access: 16 bit */
> +static struct omap_nand_platform_data zoom_nand_data = {
> + .nand_setup = NULL,
> + .gpmc_t = &nand_timings,
> + .dma_channel= -1,   /* disable DMA in OMAP NAND driver */
> + .dev_ready  = NULL,
> + .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
> +};
> +
> +/**
> + * zoom_flash_init - Identify devices connected to GPMC and register.
> + *
> + * @return - void.
> + */
> +void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int 
> cs)
> +{
> + u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
> +
> + zoom_nand_data.cs   = cs;
> + zoom_nand_data.parts= zoom_nand_parts[0].parts;
> + zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
> + zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
> + zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
> + GPMC_CS0_BASE +
> + cs * GPMC_CS_SIZE);

The gpmc_baseaddr and gpmc_cs_baseaddr should no longer be
needed with gpmc-nand.c, right?

Tony

> + gpmc_nand_init(&zoom_nand_data);
> +}
> +#else
> +void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int 
> cs)
> +{
> +}
> +#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
> +
> diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
> b/arch/arm/mach-omap2/include/mach/board-zoom.h
> index c93b29e..f4469d3 100644
> --- a/arch/arm/mach-omap2/include/mach/board-zoom.h
> +++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
> @@ -1,5 +1,16 @@
>  /*
>   * Defines for zoom boards
>   */
> +#include 
> +#include 
> +
> +struct flash_partitions {
> + struct mtd_partition *parts;
> + int nr_parts;
> +};
> +
> +#define ZOOM_NAND_CS 0
> +
> +extern void __init zoom_flash_init(struct flash_partitions [], int); >  
> extern int __init zoom_debugboard_init(void);
>  extern void __init zoom_peripherals_init(void);
> -- 
> 1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2-V2] AM3517: Enable RTC driver support for AM3517EVM

2010-02-11 Thread Tony Lindgren
* hvaib...@ti.com  [100211 00:09]:
> From: Vaibhav Hiremath 
> 
> Add platform hook-up interface to support RTC driver (S35390A).
> 
> Signed-off-by: Vaibhav Hiremath 
> ---
>  arch/arm/mach-omap2/board-am3517evm.c |   25 +
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
> b/arch/arm/mach-omap2/board-am3517evm.c
> index 247c700..d9f487f 100644
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@ -174,6 +174,18 @@ struct platform_device am3517_evm_dss_device = {
>   .platform_data  = &am3517_evm_dss_data,
>   },
>  };
> +/*
> + * RTC - S35390A
> + */
> +#define  GPIO_RTCS35390A_IRQ 55

Please change this into standard

#define GPIO_RTCS35390A_IRQ 55

instead of having a tab between #define and GPIO...

> +static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
> + {
> + I2C_BOARD_INFO("s35390a", 0x30),
> + .type   = "s35390a",
> + },
> +};
> +
> 
>  static int __init am3517_evm_i2c_init(void)
>  {
> @@ -235,6 +247,19 @@ static void __init am3517_evm_init(void)
>   usb_ehci_init(&ehci_pdata);
>   /* DSS */
>   am3517_evm_display_init();
> +
> + /* RTC - S35390A */
> + omap_mux_init_gpio(55, OMAP_PIN_INPUT_PULLUP);
> + if (gpio_request(GPIO_RTCS35390A_IRQ, "rtcs35390a-irq") < 0)
> + printk(KERN_WARNING "failed to request GPIO#%d\n",
> + GPIO_RTCS35390A_IRQ);

Here you need to check the return value before trying to change
the GPIO value. In general it's preferred to use:

int err;

err = gpio_request()
if (err < 0)
return err;
...


> + if (gpio_direction_input(GPIO_RTCS35390A_IRQ))
> + printk(KERN_WARNING "GPIO#%d cannot be configured as "
> + "input\n", GPIO_RTCS35390A_IRQ);

And only after that call gpio_direction_input.

Regards,

Tony

> + am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
> +
> + i2c_register_board_info(1, am3517evm_i2c_boardinfo,
> + ARRAY_SIZE(am3517evm_i2c_boardinfo));
>  }
> 
>  static void __init am3517_evm_map_io(void)
> --
> 1.6.2.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: installing miro

2010-02-11 Thread Felipe Contreras
On Thu, Feb 11, 2010 at 4:09 PM, Niamathullah sharief  wrote:
>   I am using omap processor board. In that i want to install "miro"
> software. is it possible?if yes how to do that? please help me

linux-omap is a kernel mailing list. I'm not sure what would be the
appropriate user-space alternative.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread ameya.palande
Hi Deepak,

I can't see NTFY_Notify() getting removed in this patch :(
It is just removing braces around if and else!

Cheers,
Ameya.

From: ext Deepak Chitriki [deepak.chitr...@ti.com]
Sent: Thursday, February 11, 2010 9:22 PM
To: linux-omap
Cc: Deepak Chitriki; Palande Ameya (Nokia-D/Helsinki); Omar Ramirez Luna; 
Nishanth Menon
Subject: [PATCH v3] DSPBRIDGE: Fix to avoid possible recursive locking

Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().

Cc: Ameya Palande 
Cc: Omar Ramirez Luna 
Cc: Nishanth Menon 

Signed-off-by: Deepak Chitriki 

---
Ref:
v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
v2:http://marc.info/?l=linux-omap&m=126591341909124&w=2
v3:Comment fixes from v2

 drivers/dsp/bridge/wmd/msg_sm.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 7de3705..7414113 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -295,9 +295,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
   (struct list_head *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_ResetEvent(hMsgQueue->hSyncEvent);
-   else {
+   else
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }

fGotMsg = true;
}
@@ -345,9 +344,9 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue->refCount--;
/* Reset the event if there are still queued messages */
-   if (!LST_IsEmpty(hMsgQueue->msgUsedList)) {
+   if (!LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }
+
/* Exit critical section */
(void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
}
--
1.6.3.3--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RESEND][PATCHv2 4/4] OMAP: DSS2: Add Innolux 7" display for DEVKIT8000

2010-02-11 Thread Thomas Weber
This patch adds the 7 inch display for the DEVKIT8000.

Signed-off-by: Thomas Weber 
---
 drivers/video/omap2/displays/Kconfig   |8 ++-
 drivers/video/omap2/displays/Makefile  |1 +
 .../video/omap2/displays/panel-innolux-at070tn83.c |  107 
 3 files changed, 115 insertions(+), 1 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-innolux-at070tn83.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index b12a59c..ca6b372 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -5,7 +5,7 @@ config PANEL_GENERIC
 tristate "Generic Panel"
 help
  Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
+ Used for DVI output for Beagle, Devkit8000 and OMAP3 SDP.
 
 config PANEL_SHARP_LS037V7DW01
 tristate "Sharp LS037V7DW01 LCD Panel"
@@ -13,6 +13,12 @@ config PANEL_SHARP_LS037V7DW01
 help
   LCD Panel used in TI's SDP3430 and EVM boards
 
+config PANEL_INNOLUX_AT070TN83
+   tristate "Innolux AT070TN83 LCD Panel"
+   depends on OMAP2_DSS
+   help
+LCD Panel used in TimLL's Devkit8000
+
 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 9556464..087b192 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
 
 obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_INNOLUX_AT070TN83) += panel-innolux-at070tn83.o
diff --git a/drivers/video/omap2/displays/panel-innolux-at070tn83.c 
b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
new file mode 100644
index 000..f1d7f69
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-innolux-at070tn83.c
@@ -0,0 +1,107 @@
+/*
+ * LCD panel driver for Innolux AT70TN83
+ *
+ * Copyright (C) 2010 Thomas Weber 
+ *
+ * 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 
+
+static struct omap_video_timings innolux_at_timings = {
+   .x_res  = 800,
+   .y_res  = 480,
+
+   .pixel_clock= 4,
+
+   .hsw= 48,
+   .hfp= 1,
+   .hbp= 1,
+
+   .vsw= 3,
+   .vfp= 12,
+   .vbp= 25,
+};
+
+static int innolux_at_panel_probe(struct omap_dss_device *dssdev)
+{
+   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+   OMAP_DSS_LCD_IHS;
+   dssdev->panel.acb = 0x28;
+   dssdev->panel.timings = innolux_at_timings;
+
+   return 0;
+}
+
+static void innolux_at_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int innolux_at_panel_enable(struct omap_dss_device *dssdev)
+{
+   return 0;
+}
+
+static void innolux_at_panel_disable(struct omap_dss_device *dssdev)
+{
+
+   if (dssdev->platform_disable)
+   dssdev->platform_disable(dssdev);
+
+}
+
+static int innolux_at_panel_suspend(struct omap_dss_device *dssdev)
+{
+   innolux_at_panel_disable(dssdev);
+   return 0;
+}
+
+static int innolux_at_panel_resume(struct omap_dss_device *dssdev)
+{
+   return innolux_at_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver innolux_at_driver = {
+   .probe  = innolux_at_panel_probe,
+   .remove = innolux_at_panel_remove,
+
+   .enable = innolux_at_panel_enable,
+   .disable= innolux_at_panel_disable,
+   .suspend= innolux_at_panel_suspend,
+   .resume = innolux_at_panel_resume,
+
+   .driver = {
+   .name   = "innolux_at_panel",
+   .owner  = THIS_MODULE,
+   },
+};
+
+static int __init innolux_at_panel_drv_init(void)
+{
+   return omap_dss_register_driver(&innolux_at_driver);
+}
+
+static void __exit innolux_at_panel_drv_exit(void)
+{
+   omap_dss_unregister_driver(&innolux_at_driver);
+}
+
+module_init(innolux_at_panel_drv_init);
+module_exit(innolux_at_panel_drv_exit);
+MODULE_LICENSE("GPL");
-- 
1.6.4.4

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

[PATCH v3] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread Deepak Chitriki
Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().

Cc: Ameya Palande 
Cc: Omar Ramirez Luna 
Cc: Nishanth Menon 

Signed-off-by: Deepak Chitriki 

---
Ref:
v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
v2:http://marc.info/?l=linux-omap&m=126591341909124&w=2
v3:Comment fixes from v2

 drivers/dsp/bridge/wmd/msg_sm.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 7de3705..7414113 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -295,9 +295,8 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
   (struct list_head *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_ResetEvent(hMsgQueue->hSyncEvent);
-   else {
+   else
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }
 
fGotMsg = true;
}
@@ -345,9 +344,9 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue->refCount--;
/* Reset the event if there are still queued messages */
-   if (!LST_IsEmpty(hMsgQueue->msgUsedList)) {
+   if (!LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_SetEvent(hMsgQueue->hSyncEvent);
-   }
+
/* Exit critical section */
(void)SYNC_LeaveCS(hMsgMgr->hSyncCS);
}
-- 
1.6.3.3

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


Re: USB lockup on OMAP3530

2010-02-11 Thread Michael Trimarchi

Hi

Gadiyar, Anand wrote:




So far I have tried many versions of the linux-omap and linux-omap-pm
kernel, from about 2.6.30 to the latest git version. They all exhibit
the USB OTG death bug.
I've used kernels with openembedded patches and without, currently
without. Yesterday I discovered the musb_hdrc.fifo_mode parameter and
played around with it. I also modified the given configurations. Result:
- FIFO configurations including .mode = BUF_DOUBLE don't work at all - no
 devices work.
- the USB death bug is not fixed by:
 - using only one endpoint
 - using no TXRX entries but only separate RX and TX
   (every endpoint gets a TX and an RX entry though)
 - using a large number of endpoints with same maxpacket value
... still no solution.

Enabling debug output of the musb_hdrc driver (yes I've also compiled in
debug messages) is not very practical due to the high volume of
messages; also, when the bug occurs nothing special is printed. The
first error usually comes from the memory manager / filesystem
complaining that it can't do "IO to offline device", i.e. the
disappeared external harddisk (which contains the swapfile).

I would *really* appreciate somebody looking into this because this
currently makes the hardware as useful as a brick for me. I can supply
debug output and test patches.


Would you care to try these two patches please?

http://marc.info/?l=linux-usb&m=125957336716915&w=2

And

The dependency patch:
http://marc.info/?l=linux-usb&m=125879861004131&w=2


Let me know if these fix the bug for you.



Use an hub with external power and connect the hub to the OTG and the device to 
the HUB.
Is it the same?



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



--
To unsubscribe from this list: send the line "unsubscribe 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: Moving board patches from DSS2 to linux-omap

2010-02-11 Thread Tony Lindgren
* Tomi Valkeinen  [100211 03:59]:
> On Thu, 2010-02-11 at 12:50 +0100, ext Mike Rapoport wrote:
> > Tomi Valkeinen wrote:
> > > Hi,
> > > 
> > > As discussed previously, board file changes in DSS2 tree cause conflicts
> > > with linux-omap easily. There are currently three board file patches in
> > > DSS2's for-next branch:
> > > 
> > > 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display 
> > > support
> > > 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for 
> > > AM3517EVM board
> > > 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM 
> > > board
> > > 
> > > The problem here is of course that DSS2 tree may contain unmerged panel
> > > drivers, and those board file changes try to use these new panel
> > > drivers.

OK, Tomi, can you please set up a banch against mainline -rc7 with
whatever board-*.c dss2 patches you want me to pull? I'll pull them
into omap-for-linus, and rebase omap for-next on those.

In general, omap-for-linus should be static for Linus to pull, while
omap for-next still changes based on the comments.
 
> > Well, the panel drivers are referenced by name in the board files, so 
> > merging board
> > file changes through linux-omap tree should not create merge conflicts and 
> > compile
> > problems. There just won't be display until DSS2 tree is merged. Or am I 
> > missing
> > something?
> 
> Yes, that is correct. This makes adding new boards and panels a bit more
> complicated, but should remove most conflicts that happen between
> linux-omap and dss2 trees.

Sure I'll can pull whatever Tomi thinks is OK. Just please
make sure that before I pull, all the dss2 board-*.c patches have
been reviewed on both linux-omap and linux-arm-kernel lists.

We should probably also start merging Tomi's drivers/video/omap branch
into omap master branch on regular basis for testing.

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] DSPBRIDGE: Validate node handle from user

2010-02-11 Thread Ramos Falcon, Ernesto


>-Original Message-
>From: Ameya Palande [mailto:ameya.pala...@nokia.com]
>Sent: Thursday, February 11, 2010 7:51 AM
>To: Ramos Falcon, Ernesto
>Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
>Hiroshi (Nokia-D/Helsinki)
>Subject: RE: [PATCH] DSPBRIDGE: Validate node handle from user
>
>On Tue, 2010-02-09 at 18:52 +0100, ext Ramos Falcon, Ernesto wrote:
>>
>> >-Original Message-
>> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
>> >Sent: Tuesday, February 09, 2010 11:32 AM
>> >To: Ramos Falcon, Ernesto
>> >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki);
>Doyu
>> >Hiroshi (Nokia-D/Helsinki)
>> >Subject: Re: [PATCH] DSPBRIDGE: Validate node handle from user
>> >
>> >Hi Ernesto,
>> >
>> >On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
>> >> From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
>> >> From: Ernesto Ramos 
>> >> Date: Fri, 29 Jan 2010 16:21:59 -0600
>> >> Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
>> >>
>> >> Add checks to validate the node handles received from user.
>> >>
>> >> Signed-off-by: Ernesto Ramos 
>> >> ---
>> >>  drivers/dsp/bridge/pmgr/wcd.c  |   91 -
>> >>  drivers/dsp/bridge/rmgr/node.c |  174 +--
>---
>> >-
>> >>  2 files changed, 146 insertions(+), 119 deletions(-)
>> >>
>> >> diff --git a/drivers/dsp/bridge/pmgr/wcd.c
>> >b/drivers/dsp/bridge/pmgr/wcd.c
>> >> index 74654dc..2e6eeb0 100644
>> >> --- a/drivers/dsp/bridge/pmgr/wcd.c
>> >> +++ b/drivers/dsp/bridge/pmgr/wcd.c
>> >> @@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args,
>void
>> >*pr_ctxt)
>> >> return retVal;
>> >>  }
>> >>
>> >> +bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
>> >> +{
>> >> +   bool retVal = false;
>> >> +   struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
>> >> +   struct NODE_RES_OBJECT *pNode = pCtxt->pNodeList;
>> >> +
>> >> +   if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
>> >> +   retVal = true;
>> >> +
>> >> +   while (pNode && !retVal) {
>> >> +   if (hNode == pNode->hNode)
>> >
>> >If you have several nodes allocated by user space, then what you are
>> >validating here is for any node! Is that ok?
>> >
>> >This validation and design itself doesn't look good to me. If we don't
>> >want to trust user space, then instead of checking the node handle in
>> >every function it is better to store all user space specific date inside
>> >pr_context and use it from there.
>> >
>>
>> The user can launch several nodes, how are we going to know which node
>handle to use?
>> I think we may need to receive at least one index or id to the node
>handle.
>
>Yes, I guess thats the correct way! We need to maintain how many nodes
>are allocated for a user process, and just make sure that this id /
>index is <= number of allocated nodes.
>

This comparison (<=) won't work because the user can eliminate nodes in the 
middle of the list in which case we may need to maintain a list of valid 
indexes. So I don't see any improvement with this way to validate the handles. 

I was thinking in an array an based on the index verify that the handle is 
valid, independently of the number of nodes this would be very quick, but the 
disadvantage would be that the number per process will be limited to the size 
of the array.

>Cheers,
>Ameya.

--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes

2010-02-11 Thread Ameya Palande
Hi all,

On Thu, 2010-02-11 at 16:53 +0100, Contreras Felipe (Nokia-D/Helsinki)
wrote:
> On Wed, Feb 10, 2010 at 06:31:35PM +0100, ext Guzman Lugo, Fernando wrote:
> > >-Original Message-
> > >From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> > >> Resource cleanup does not support that even without my proposed changes.
> > >
> > >Aha! I suspected it :P
> > >
> > Resource cleanup does not support that because it tries to unreserved
> > every chunk mapped. However it does not means the dspbridge does not
> > support reserving a big chunk of memory and mapping small parts of
> > that memory, but I have not tested it to confirm if it works.
> 
> I think I did once and it didn't work, but I thought the problem was in
> my app. Anyway I think we should either forget about this use-case or
> fix the resource cleaning.
> 
> > >> I just proposed a solution which fixes two issues in one patch.
> > >> Moreover if this change is merged when the second issue be fixed this
> > >> patch will not needed anymore, so why don't merge the patch which
> > >> fixes both errors at this moment?
> > >
> > >simple patches > complicated patches
> > The patch is more simple than it looks.
> 
> Only one way to know :)
> 
> > >Personally I think your patches should be a continuation to the patches
> > >I just proposed.
> > Yes, I think it would be better.
> 
> Cool.
> 

Thanks for reviewing the patch!

After going through your comments I feel the current patch is inadequate
to do proper resource cleanup :(

I am working on something which should take care of map and reserve
both. Basically I am working on separating current DMM resource
accounting for map and reserve, which should fix all the problems. Will
post the patchset soon!

Cheers,
Ameya.

--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread Ameya Palande
Hi Deepak,

On Thu, 2010-02-11 at 18:33 +0100, ext Deepak Chitriki wrote:
> Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
> as NTFY_Notify() is already invoked in InputMsg().
> 
> Cc: Ameya Palande 
> Cc: Omar Ramirez Luna 
> Cc: Nishanth Menon 
> 
> Signed-off-by: Deepak Chitriki 
> 
> ---
> Ref:
> v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
> v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
> v2:Comment fixes from v1
> 
>  drivers/dsp/bridge/wmd/msg_sm.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
> index d778cbc..7414113 100644
> --- a/drivers/dsp/bridge/wmd/msg_sm.c
> +++ b/drivers/dsp/bridge/wmd/msg_sm.c
> @@ -295,7 +295,7 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
>  (struct list_head *)pMsgFrame);
>   if (LST_IsEmpty(hMsgQueue->msgUsedList))
>   SYNC_ResetEvent(hMsgQueue->hSyncEvent);
> - else 
> + else
>   SYNC_SetEvent(hMsgQueue->hSyncEvent);
>  
>   fGotMsg = true;
> @@ -344,7 +344,7 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
>   }
>   hMsgQueue->refCount--;
>   /* Reset the event if there are still queued messages */
> - if (!LST_IsEmpty(hMsgQueue->msgUsedList)) 
> + if (!LST_IsEmpty(hMsgQueue->msgUsedList))
>   SYNC_SetEvent(hMsgQueue->hSyncEvent);
>  
>   /* Exit critical section */

Is this the correct change?

Cheers,
Ameya.

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


Re: [RESEND][PATCHv2 3/4] Add ASoC support for Devkit8000

2010-02-11 Thread Mark Brown
On Thu, Feb 11, 2010 at 04:13:59PM +0100, Thomas Weber wrote:
> This patch expands the omap3beagle sound soc for the
> beagle board clone DevKit8000.
> 
> Signed-off-by: Thomas Weber 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe 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 13/13] OMAP4 clock: drop the ALWAYS_ENABLED clock flag

2010-02-11 Thread Paul Walmsley
Get rid of the ALWAYS_ENABLED clock flag - it doesn't actually do anything.
(The OMAP4 clock autogeneration scripts have been updated accordingly.)

Signed-off-by: Paul Walmsley 
Cc: Rajendra Nayak 
Cc: Benoît Cousson 
---
 arch/arm/mach-omap2/clock44xx_data.c|   11 ---
 arch/arm/plat-omap/include/plat/clock.h |1 -
 2 files changed, 0 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 022f1a7..6deca1e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -39,42 +39,36 @@ static struct clk extalt_clkin_ck = {
.name   = "extalt_clkin_ck",
.rate   = 5900,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk pad_clks_ck = {
.name   = "pad_clks_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk pad_slimbus_core_clks_ck = {
.name   = "pad_slimbus_core_clks_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk secure_32k_clk_src_ck = {
.name   = "secure_32k_clk_src_ck",
.rate   = 32768,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk slimbus_clk = {
.name   = "slimbus_clk",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk sys_32k_ck = {
.name   = "sys_32k_ck",
.rate   = 32768,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk virt_1200_ck = {
@@ -179,35 +173,30 @@ static struct clk sys_clkin_ck = {
.clksel_mask= OMAP4430_SYS_CLKSEL_MASK,
.ops= &clkops_null,
.recalc = &omap2_clksel_recalc,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk utmi_phy_clkout_ck = {
.name   = "utmi_phy_clkout_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60mhsp1_ck = {
.name   = "xclk60mhsp1_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60mhsp2_ck = {
.name   = "xclk60mhsp2_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60motg_ck = {
.name   = "xclk60motg_ck",
.rate   = 6000,
.ops= &clkops_null,
-   .flags  = ALWAYS_ENABLED,
 };
 
 /* Module clocks and DPLL outputs */
diff --git a/arch/arm/plat-omap/include/plat/clock.h 
b/arch/arm/plat-omap/include/plat/clock.h
index dcfdcd6..5e1c035 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -193,7 +193,6 @@ extern const struct clkops clkops_null;
 #define CLOCK_NO_IDLE_PARENT   (1 << 2)
 #define ENABLE_ON_INIT (1 << 3)/* Enable upon framework init */
 #define INVERT_ENABLE  (1 << 4)/* 0 enables, 1 disables */
-#define ALWAYS_ENABLED (1 << 5)
 
 /* Clksel_rate flags */
 #define DEFAULT_RATE   (1 << 0)


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


[PATCH 02/13] OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag

2010-02-11 Thread Paul Walmsley
The CLOCK_IN_OMAP4430 clock flag is not currently needed in the OMAP4
ES1 clock tree, and platform discrimination via clock flags is
deprecated in favor of the clkdev mechanism, so, drop it.  (The OMAP4
clock tree autogeneration script has been updated accordingly.)

Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/clock44xx_data.c|  124 +++
 arch/arm/plat-omap/include/plat/clock.h |4 +
 2 files changed, 13 insertions(+), 115 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 1cb789d..70b314c 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -39,42 +39,42 @@ static struct clk extalt_clkin_ck = {
.name   = "extalt_clkin_ck",
.rate   = 5900,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk pad_clks_ck = {
.name   = "pad_clks_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk pad_slimbus_core_clks_ck = {
.name   = "pad_slimbus_core_clks_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk secure_32k_clk_src_ck = {
.name   = "secure_32k_clk_src_ck",
.rate   = 32768,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk slimbus_clk = {
.name   = "slimbus_clk",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk sys_32k_ck = {
.name   = "sys_32k_ck",
.rate   = 32768,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk virt_1200_ck = {
@@ -179,35 +179,35 @@ static struct clk sys_clkin_ck = {
.clksel_mask= OMAP4430_SYS_CLKSEL_MASK,
.ops= &clkops_null,
.recalc = &omap2_clksel_recalc,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk utmi_phy_clkout_ck = {
.name   = "utmi_phy_clkout_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60mhsp1_ck = {
.name   = "xclk60mhsp1_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60mhsp2_ck = {
.name   = "xclk60mhsp2_ck",
.rate   = 1200,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 static struct clk xclk60motg_ck = {
.name   = "xclk60motg_ck",
.rate   = 6000,
.ops= &clkops_null,
-   .flags  = CLOCK_IN_OMAP4430 | ALWAYS_ENABLED,
+   .flags  = ALWAYS_ENABLED,
 };
 
 /* Module clocks and DPLL outputs */
@@ -233,7 +233,6 @@ static struct clk dpll_sys_ref_clk = {
.recalc = &omap2_clksel_recalc,
.round_rate = &omap2_clksel_round_rate,
.set_rate   = &omap2_clksel_set_rate,
-   .flags  = CLOCK_IN_OMAP4430,
 };
 
 static const struct clksel abe_dpll_refclk_mux_sel[] = {
@@ -251,7 +250,6 @@ static struct clk abe_dpll_refclk_mux_ck = {
.clksel_mask= OMAP4430_CLKSEL_0_0_MASK,
.ops= &clkops_null,
.recalc = &omap2_clksel_recalc,
-   .flags  = CLOCK_IN_OMAP4430,
 };
 
 /* DPLL_ABE */
@@ -283,7 +281,6 @@ static struct clk dpll_abe_ck = {
.recalc = &omap3_dpll_recalc,
.round_rate = &omap2_dpll_round_rate,
.set_rate   = &omap3_noncore_dpll_set_rate,
-   .flags  = CLOCK_IN_OMAP4430,
 };
 
 static struct clk dpll_abe_m2x2_ck = {
@@ -291,7 +288,6 @@ static struct clk dpll_abe_m2x2_ck = {
.parent = &dpll_abe_ck,
.ops= &clkops_null,
.recalc = &followparent_recalc,
-   .flags  = CLOCK_IN_OMAP4430,
 };
 
 static struct clk abe_24m_fclk = {
@@ -29

[PATCH 11/13] OMAP2 clock: drop DELAYED_APP clock flag

2010-02-11 Thread Paul Walmsley
All of the clocks that are marked with DELAYED_APP are changed as part
of the virt_prcm_set OPP virtual clock.  On 24xx, these clocks all
need to be changed as part of a group to keep the clock tree
functional - hence the need for the VALID_CONFIG bit, which is not
present on later OMAPs.  These clocks should not be rate-changed
independently.  So prevent these clocks from being changed
independently by dropping their .round_rate and .set_rate function
pointers.  It then turns out that the DELAYED_APP clock flag is no
longer useful, so drop it and the associated code and renumber the
clock flags.

Signed-off-by: Paul Walmsley 
Cc: Richard Woodruff 
---
 arch/arm/mach-omap2/clkt_clksel.c   |4 
 arch/arm/mach-omap2/clock.c |   27 +--
 arch/arm/mach-omap2/clock2420_data.c|   20 
 arch/arm/mach-omap2/clock2430_data.c|   17 -
 arch/arm/plat-omap/include/plat/clock.h |7 +++
 5 files changed, 4 insertions(+), 71 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_clksel.c 
b/arch/arm/mach-omap2/clkt_clksel.c
index 25a2363..ade19f6 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -377,8 +377,6 @@ int omap2_clksel_set_rate(struct clk *clk, unsigned long 
rate)
 
clk->rate = clk->parent->rate / new_div;
 
-   omap2xxx_clk_commit(clk);
-
return 0;
 }
 
@@ -400,8 +398,6 @@ int omap2_clksel_set_parent(struct clk *clk, struct clk 
*new_parent)
__raw_writel(v, clk->clksel_reg);
v = __raw_readl(clk->clksel_reg);/* OCP barrier */
 
-   omap2xxx_clk_commit(clk);
-
clk_reparent(clk, new_parent);
 
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 82b17ef..426d76f 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -2,7 +2,7 @@
  *  linux/arch/arm/mach-omap2/clock.c
  *
  *  Copyright (C) 2005-2008 Texas Instruments, Inc.
- *  Copyright (C) 2004-2008 Nokia Corporation
+ *  Copyright (C) 2004-2010 Nokia Corporation
  *
  *  Contacts:
  *  Richard Woodruff 
@@ -14,12 +14,9 @@
  */
 #undef DEBUG
 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -89,28 +86,6 @@ static void _omap2_clk_disable(struct clk *clk)
 /* Public functions */
 
 /**
- * omap2xxx_clk_commit - commit clock parent/rate changes in hardware
- * @clk: struct clk *
- *
- * If @clk has the DELAYED_APP flag set, meaning that parent/rate changes
- * don't take effect until the VALID_CONFIG bit is written, write the
- * VALID_CONFIG bit and wait for the write to complete.  No return value.
- */
-void omap2xxx_clk_commit(struct clk *clk)
-{
-   if (!cpu_is_omap24xx())
-   return;
-
-   if (!(clk->flags & DELAYED_APP))
-   return;
-
-   prm_write_mod_reg(OMAP24XX_VALID_CONFIG, OMAP24XX_GR_MOD,
-   OMAP2_PRCM_CLKCFG_CTRL_OFFSET);
-   /* OCP barrier */
-   prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP2_PRCM_CLKCFG_CTRL_OFFSET);
-}
-
-/**
  * omap2_init_clk_clkdm - look up a clockdomain name, store pointer in clk
  * @clk: OMAP clock struct ptr to use
  *
diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index 7124213..bef647a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -404,7 +404,6 @@ static struct clk mpu_ck = {/* Control cpu */
.name   = "mpu_ck",
.ops= &clkops_null,
.parent = &core_ck,
-   .flags  = DELAYED_APP,
.clkdm_name = "mpu_clkdm",
.init   = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
@@ -443,7 +442,6 @@ static struct clk dsp_fck = {
.name   = "dsp_fck",
.ops= &clkops_omap2_dflt_wait,
.parent = &core_ck,
-   .flags  = DELAYED_APP,
.clkdm_name = "dsp_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT,
@@ -470,7 +468,6 @@ static struct clk dsp_irate_ick = {
.name   = "dsp_irate_ick",
.ops= &clkops_null,
.parent = &dsp_fck,
-   .flags  = DELAYED_APP,
.clksel_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask= OMAP24XX_CLKSEL_DSP_IF_MASK,
.clksel = dsp_irate_ick_clksel,
@@ -495,7 +492,6 @@ static struct clk iva1_ifck = {
.name   = "iva1_ifck",
.ops= &clkops_omap2_dflt_wait,
.parent = &core_ck,
-   .flags  = DELAYED_APP,
.clkdm_name = "iva1_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP2420_EN_IVA

[PATCH 10/13] OMAP2430 clock: make func_96m_ck parent-selectable

2010-02-11 Thread Paul Walmsley
func_96m_ck was incorrectly marked as being rate-selectable, when in
fact it is only parent-selectable.  Remove the .set_rate and .round_rate
function pointers for this clk.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap2/clock2430_data.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index 9b9470e..daf6439 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -210,7 +210,6 @@ static const struct clksel func_96m_clksel[] = {
{ .parent = NULL }
 };
 
-/* The parent of this clock is not selectable on 2420. */
 static struct clk func_96m_ck = {
.name   = "func_96m_ck",
.ops= &clkops_null,
@@ -221,8 +220,6 @@ static struct clk func_96m_ck = {
.clksel_mask= OMAP2430_96M_SOURCE,
.clksel = func_96m_clksel,
.recalc = &omap2_clksel_recalc,
-   .round_rate = &omap2_clksel_round_rate,
-   .set_rate   = &omap2_clksel_set_rate
 };
 
 /* func_48m_ck */


--
To unsubscribe from this list: send the line "unsubscribe 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 04/13] OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks

2010-02-11 Thread Paul Walmsley
The DELAYED_APP flag is effective only with clksel clocks, so drop it from
clocks that are not rate-changeable or that use non-clksel rate changing code
(e.g., virt_prcm_set).

Signed-off-by: Paul Walmsley 
Cc: Richard Woodruff 
---
 arch/arm/mach-omap2/clock2xxx_data.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2xxx_data.c 
b/arch/arm/mach-omap2/clock2xxx_data.c
index d08d545..aa37761 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -512,7 +512,7 @@ static struct clk dsp_ick = {
.name   = "dsp_ick", /* apparently ipi and isp */
.ops= &clkops_omap2_dflt_wait,
.parent = &dsp_irate_ick,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = CONFIG_PARTICIPANT,
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_ICLKEN),
.enable_bit = OMAP2420_EN_DSP_IPI_SHIFT,  /* for ipi */
 };
@@ -522,7 +522,7 @@ static struct clk iva2_1_ick = {
.name   = "iva2_1_ick",
.ops= &clkops_omap2_dflt_wait,
.parent = &dsp_irate_ick,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = CONFIG_PARTICIPANT,
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT,
 };
@@ -779,7 +779,7 @@ static struct clk gfx_ick = {
.name   = "gfx_ick",/* From l3 */
.ops= &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = CONFIG_PARTICIPANT,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_ICLKEN),
.enable_bit = OMAP_EN_GFX_SHIFT,
@@ -2068,7 +2068,6 @@ static struct clk mmchsdb2_fck = {
 static struct clk virt_prcm_set = {
.name   = "virt_prcm_set",
.ops= &clkops_null,
-   .flags  = DELAYED_APP,
.parent = &mpu_ck,  /* Indexed by mpu speed, no parent */
.recalc = &omap2_table_mpu_recalc,  /* sets are keyed on 
mpu rate */
.set_rate   = &omap2_select_table_rate,


--
To unsubscribe from this list: send the line "unsubscribe 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 12/13] OMAP clock: drop RATE_FIXED clock flag

2010-02-11 Thread Paul Walmsley
The RATE_FIXED clock flag is pointless.  In the OMAP1 clock code, it
simply causes the omap1_clk_round_rate() function to return the
current rate of the clock.  omap1_clk_round_rate(), however, should
never be called for a fixed-rate clock, since none of these clocks
have a .round_rate function pointer set in their struct clk records.
Similarly, in the OMAP2+ clock code, the RATE_FIXED flag just causes
the clock code to emit a warning if the OMAP clock maintainer was
foolish enough to add a .round_rate function pointer to a fixed-rate
clock.  "Doctor, it hurts when I pretend that a fixed-rate clock is
rate-changeable."  "Then don't pretend that a fixed-rate clock is
rate-changeable."  It has no functional value.  This patch drops the
RATE_FIXED clock flag, removing it from all clocks that are so marked.

Signed-off-by: Paul Walmsley 
Cc: Richard Woodruff 
---
 arch/arm/mach-omap1/clock.c |5 +
 arch/arm/mach-omap1/clock_data.c|   25 +
 arch/arm/mach-omap2/clkt_clksel.c   |4 
 arch/arm/mach-omap2/clock2420_data.c|7 ++-
 arch/arm/mach-omap2/clock2430_data.c|7 ++-
 arch/arm/plat-omap/include/plat/clock.h |   13 ++---
 6 files changed, 20 insertions(+), 41 deletions(-)

diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 3e052f6..0ba044d 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -1,7 +1,7 @@
 /*
  *  linux/arch/arm/mach-omap1/clock.c
  *
- *  Copyright (C) 2004 - 2005, 2009 Nokia corporation
+ *  Copyright (C) 2004 - 2005, 2009-2010 Nokia Corporation
  *  Written by Tuukka Tikkanen 
  *
  *  Modified to use omap shared clock framework by
@@ -571,9 +571,6 @@ const struct clkops clkops_uart = {
 
 long omap1_clk_round_rate(struct clk *clk, unsigned long rate)
 {
-   if (clk->flags & RATE_FIXED)
-   return clk->rate;
-
if (clk->round_rate != NULL)
return clk->round_rate(clk, rate);
 
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index cea91cd..8b1d14d 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -1,7 +1,7 @@
 /*
  *  linux/arch/arm/mach-omap1/clock_data.c
  *
- *  Copyright (C) 2004 - 2005, 2009 Nokia corporation
+ *  Copyright (C) 2004 - 2005, 2009-2010 Nokia Corporation
  *  Written by Tuukka Tikkanen 
  *  Based on clocks.h by Tony Lindgren, Gordon McNutt and RidgeRun, Inc
  *
@@ -31,7 +31,6 @@
 static struct clk dummy_ck = {
.name   = "dummy",
.ops= &clkops_dummy,
-   .flags  = RATE_FIXED,
 };
 
 static struct clk ck_ref = {
@@ -389,8 +388,7 @@ static struct uart_clk uart1_16xx = {
/* Direct from ULPD, no real parent */
.parent = &armper_ck.clk,
.rate   = 4800,
-   .flags  = RATE_FIXED | ENABLE_REG_32BIT |
- CLOCK_NO_IDLE_PARENT,
+   .flags  = ENABLE_REG_32BIT | CLOCK_NO_IDLE_PARENT,
.enable_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_0),
.enable_bit = 29,
},
@@ -430,8 +428,7 @@ static struct uart_clk uart3_16xx = {
/* Direct from ULPD, no real parent */
.parent = &armper_ck.clk,
.rate   = 4800,
-   .flags  = RATE_FIXED | ENABLE_REG_32BIT |
- CLOCK_NO_IDLE_PARENT,
+   .flags  = ENABLE_REG_32BIT | CLOCK_NO_IDLE_PARENT,
.enable_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_0),
.enable_bit = 31,
},
@@ -443,7 +440,7 @@ static struct clk usb_clko = {  /* 6 MHz output on 
W4_USB_CLKO */
.ops= &clkops_generic,
/* Direct from ULPD, no parent */
.rate   = 600,
-   .flags  = RATE_FIXED | ENABLE_REG_32BIT,
+   .flags  = ENABLE_REG_32BIT,
.enable_reg = OMAP1_IO_ADDRESS(ULPD_CLOCK_CTRL),
.enable_bit = USB_MCLK_EN_BIT,
 };
@@ -453,7 +450,7 @@ static struct clk usb_hhc_ck1510 = {
.ops= &clkops_generic,
/* Direct from ULPD, no parent */
.rate   = 4800, /* Actually 2 clocks, 12MHz and 48MHz */
-   .flags  = RATE_FIXED | ENABLE_REG_32BIT,
+   .flags  = ENABLE_REG_32BIT,
.enable_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_0),
.enable_bit = USB_HOST_HHC_UHOST_EN,
 };
@@ -464,7 +461,7 @@ static struct clk usb_hhc_ck16xx = {
/* Direct from ULPD, no parent */
.rate   = 4800,
/* OTG_SYSCON_2.OTG_PADEN == 0 (not 1510-compatible) */
-   .flags  = RATE_FIXED | ENABLE_REG_32BIT,
+   .flags  = ENABLE_REG_32BIT,
.enable_reg = OMAP1_IO_ADDRESS(OTG_BASE + 0x08), /* OTG_SYSCON_2 */
.enable_bit = 8 /* UHOST_EN */,
 };
@@ -474,7 +

[PATCH 03/13] OMAP2xxx clock: GFX functional clock rates are not independently changeable

2010-02-11 Thread Paul Walmsley
According to the OMAP242x TRM Rev X Figure 5-15 "Clock Output Control
- Functional Clocks 2", the GFX functional clocks should be marked
both DELAYED_APP and CONFIG_PARTICIPANT, meaning that their rates must
be reprogrammed as part of a larger OPP set change.

Signed-off-by: Paul Walmsley 
Cc: Richard Woodruff 
---
 arch/arm/mach-omap2/clock2xxx_data.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2xxx_data.c 
b/arch/arm/mach-omap2/clock2xxx_data.c
index f20a4b2..d08d545 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -737,7 +737,6 @@ static struct clk ssi_l4_ick = {
  * divided value of fclk.
  *
  */
-/* XXX REVISIT: GFX clock is part of CONFIG_PARTICIPANT, no? doublecheck. */
 
 /* This clksel struct is shared between gfx_3d_fck and gfx_2d_fck */
 static const struct clksel gfx_fck_clksel[] = {
@@ -764,6 +763,7 @@ static struct clk gfx_2d_fck = {
.name   = "gfx_2d_fck",
.ops= &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
+   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_EN_2D_SHIFT,
@@ -779,6 +779,7 @@ static struct clk gfx_ick = {
.name   = "gfx_ick",/* From l3 */
.ops= &clkops_omap2_dflt_wait,
.parent = &core_l3_ck,
+   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
.clkdm_name = "gfx_clkdm",
.enable_reg = OMAP_CM_REGADDR(GFX_MOD, CM_ICLKEN),
.enable_bit = OMAP_EN_GFX_SHIFT,


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


[PATCH 05/13] OMAP2 clock: drop CONFIG_PARTICIPANT clock flag

2010-02-11 Thread Paul Walmsley
It turns out that the only purpose of the CONFIG_PARTICIPANT clock
flag is to prevent omap2_clk_set_rate() and omap2_clk_set_parent()
from being executed on clocks with that flag set.  The rate-changing
component can be more directly accomplished by dropping the .set_rate
and .round_rate function pointers from those CONFIG_PARTICIPANT struct
clks.  As far as the parent-changing component is concerned, it turns
out that none of the CONFIG_PARTICIPANT clocks have multiple parent
choices, so all that is necessary is for omap2_clk_set_parent() to
bail out early if the new parent is equal to the old parent.
Implement this change and get rid of the flag, which has always had a
confusing name (it appears to be a Kconfig option, falsely).

Signed-off-by: Paul Walmsley 
Cc: Richard Woodruff 
---
 arch/arm/mach-omap2/clock.c |   11 +++---
 arch/arm/mach-omap2/clock2xxx_data.c|   35 +++
 arch/arm/plat-omap/include/plat/clock.h |2 +-
 3 files changed, 12 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 3bb3292..9df5937 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -318,11 +318,6 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
 
pr_debug("clock: set_rate for clock %s to rate %ld\n", clk->name, rate);
 
-   /* CONFIG_PARTICIPANT clocks are changed only in sets via the
-  rate table mechanism, driven by mpu_speed  */
-   if (clk->flags & CONFIG_PARTICIPANT)
-   return -EINVAL;
-
/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
if (clk->set_rate)
ret = clk->set_rate(clk, rate);
@@ -332,12 +327,12 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long 
rate)
 
 int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
 {
-   if (clk->flags & CONFIG_PARTICIPANT)
-   return -EINVAL;
-
if (!clk->clksel)
return -EINVAL;
 
+   if (clk->parent == new_parent)
+   return 0;
+
return omap2_clksel_set_parent(clk, new_parent);
 }
 
diff --git a/arch/arm/mach-omap2/clock2xxx_data.c 
b/arch/arm/mach-omap2/clock2xxx_data.c
index aa37761..9bcef44 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -426,15 +426,13 @@ static struct clk mpu_ck = {  /* Control cpu */
.name   = "mpu_ck",
.ops= &clkops_null,
.parent = &core_ck,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = DELAYED_APP,
.clkdm_name = "mpu_clkdm",
.init   = &omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
.clksel_mask= OMAP24XX_CLKSEL_MPU_MASK,
.clksel = mpu_clksel,
.recalc = &omap2_clksel_recalc,
-   .round_rate = &omap2_clksel_round_rate,
-   .set_rate   = &omap2_clksel_set_rate
 };
 
 /*
@@ -468,7 +466,7 @@ static struct clk dsp_fck = {
.name   = "dsp_fck",
.ops= &clkops_omap2_dflt_wait,
.parent = &core_ck,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = DELAYED_APP,
.clkdm_name = "dsp_clkdm",
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_FCLKEN),
.enable_bit = OMAP24XX_CM_FCLKEN_DSP_EN_DSP_SHIFT,
@@ -476,8 +474,6 @@ static struct clk dsp_fck = {
.clksel_mask= OMAP24XX_CLKSEL_DSP_MASK,
.clksel = dsp_fck_clksel,
.recalc = &omap2_clksel_recalc,
-   .round_rate = &omap2_clksel_round_rate,
-   .set_rate   = &omap2_clksel_set_rate
 };
 
 /* DSP interface clock */
@@ -498,13 +494,11 @@ static struct clk dsp_irate_ick = {
.name   = "dsp_irate_ick",
.ops= &clkops_null,
.parent = &dsp_fck,
-   .flags  = DELAYED_APP | CONFIG_PARTICIPANT,
+   .flags  = DELAYED_APP,
.clksel_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_CLKSEL),
.clksel_mask= OMAP24XX_CLKSEL_DSP_IF_MASK,
.clksel = dsp_irate_ick_clksel,
.recalc = &omap2_clksel_recalc,
-   .round_rate = &omap2_clksel_round_rate,
-   .set_rate = &omap2_clksel_set_rate
 };
 
 /* 2420 only */
@@ -512,7 +506,6 @@ static struct clk dsp_ick = {
.name   = "dsp_ick", /* apparently ipi and isp */
.ops= &clkops_omap2_dflt_wait,
.parent = &dsp_irate_ick,
-   .flags  = CONFIG_PARTICIPANT,
.enable_reg = OMAP_CM_REGADDR(OMAP24XX_DSP_MOD, CM_ICLKEN),
.enable_bit = OMAP2420_EN_DSP_IPI_SHIFT,  /* for ipi */
 };
@@ -522,7 +515,6 @@ static struct clk iva2_1_ick = {
.name   = "iva2_1_ick",
.ops= &clkops_omap2_dflt_wai

[PATCH 06/13] OMAP clock: compress clock flags down to a u8

2010-02-11 Thread Paul Walmsley
There are now only eight OMAP clock flags, so renumber the flags to
fit in a u8 and shrink the size of struct clk.flags from a u32 to a
u8.  The intention is to save memory.

Signed-off-by: Paul Walmsley 
---
 arch/arm/plat-omap/include/plat/clock.h |   24 +---
 1 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/clock.h 
b/arch/arm/plat-omap/include/plat/clock.h
index 5dac307..7dc1ae7 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -126,7 +126,6 @@ struct clk {
struct list_headchildren;
struct list_headsibling;/* node for children */
unsigned long   rate;
-   __u32   flags;
void __iomem*enable_reg;
unsigned long   (*recalc)(struct clk *);
int (*set_rate)(struct clk *, unsigned long);
@@ -135,6 +134,7 @@ struct clk {
__u8enable_bit;
__s8usecount;
u8  fixed_div;
+   u8  flags;
 #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
defined(CONFIG_ARCH_OMAP4)
void __iomem*clksel_reg;
@@ -189,20 +189,14 @@ extern void clk_exit_cpufreq_table(struct 
cpufreq_frequency_table **table);
 extern const struct clkops clkops_null;
 
 /* Clock flags */
-/* bit 0 is free */
-#define RATE_FIXED (1 << 1)/* Fixed clock rate */
-/* bits 2-4 are free */
-#define ENABLE_REG_32BIT   (1 << 5)/* Use 32-bit access */
-/* bit 6 is free */
-#define CLOCK_IDLE_CONTROL (1 << 7)
-#define CLOCK_NO_IDLE_PARENT   (1 << 8)
-#define DELAYED_APP(1 << 9)/* Delay application of clock */
-/* bit 10 is currently free */
-#define ENABLE_ON_INIT (1 << 11)   /* Enable upon framework init */
-#define INVERT_ENABLE  (1 << 12)   /* 0 enables, 1 disables */
-/* bit 13 is currently free */
-#define ALWAYS_ENABLED (1 << 14)
-/* bits 15-31 are currently free */
+#define RATE_FIXED (1 << 0)/* Fixed clock rate */
+#define ENABLE_REG_32BIT   (1 << 1)/* Use 32-bit access */
+#define CLOCK_IDLE_CONTROL (1 << 2)
+#define CLOCK_NO_IDLE_PARENT   (1 << 3)
+#define DELAYED_APP(1 << 4)/* Delay application of clock */
+#define ENABLE_ON_INIT (1 << 5)/* Enable upon framework init */
+#define INVERT_ENABLE  (1 << 6)/* 0 enables, 1 disables */
+#define ALWAYS_ENABLED (1 << 7)
 
 /* Clksel_rate flags */
 #define DEFAULT_RATE   (1 << 0)


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


[PATCH 08/13] OMAP3/4 clock: split into per-chip family files

2010-02-11 Thread Paul Walmsley
clock34xx_data.c now contains data for the OMAP34xx family, the
OMAP36xx family, and the OMAP3517 family, so rename it to
clock3xxx_data.c.  Rename clock34xx.c to clock3xxx.c, and move the
chip family-specific clock functions to clock34xx.c, clock36xx.c, or
clock3517.c, as appropriate.  So now "clock3xxx.*" refers to the OMAP3
superset.

The main goal here is to prepare to compile chip family-specific clock
functions only for kernel builds that target that chip family.  To get to
that point, we also need to add CONFIG_ARCH_* options for those other
chip families; that will be done in a future patch, planned for 2.6.35.

OMAP4 is also affected by this.  It duplicated the OMAP3 non-CORE DPLL
clkops structure.  The OMAP4 variant of this clkops structure has been
removed, and since there was nothing else currently in clock44xx.c, it
too has been removed -- it can always be added back later when there
is some content for it.  (The OMAP4 clock autogeneration scripts have been
updated accordingly.)

Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
Cc: Rajendra Nayak 
Cc: Ranjith Lohithakshan 
---
 arch/arm/mach-omap2/Makefile   |   36 ++--
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |1 
 arch/arm/mach-omap2/clock.c|   12 +
 arch/arm/mach-omap2/clock.h|2 
 arch/arm/mach-omap2/clock34xx.c|  260 
 arch/arm/mach-omap2/clock34xx.h|   27 +--
 arch/arm/mach-omap2/clock3517.c|  124 +++
 arch/arm/mach-omap2/clock3517.h|   14 ++
 arch/arm/mach-omap2/clock36xx.c|   72 +
 arch/arm/mach-omap2/clock36xx.h|   13 ++
 arch/arm/mach-omap2/clock3xxx.c|  145 ++
 arch/arm/mach-omap2/clock3xxx.h|   21 +++
 arch/arm/mach-omap2/clock3xxx_data.c   |   16 +-
 arch/arm/mach-omap2/clock44xx.c|   19 --
 arch/arm/mach-omap2/clock44xx.h|6 -
 arch/arm/mach-omap2/clock44xx_data.c   |   12 +
 arch/arm/mach-omap2/io.c   |2 
 17 files changed, 450 insertions(+), 332 deletions(-)
 create mode 100644 arch/arm/mach-omap2/clock3517.c
 create mode 100644 arch/arm/mach-omap2/clock3517.h
 create mode 100644 arch/arm/mach-omap2/clock36xx.c
 create mode 100644 arch/arm/mach-omap2/clock36xx.h
 create mode 100644 arch/arm/mach-omap2/clock3xxx.c
 create mode 100644 arch/arm/mach-omap2/clock3xxx.h
 rename arch/arm/mach-omap2/{clock34xx_data.c => clock3xxx_data.c} (99%)
 delete mode 100644 arch/arm/mach-omap2/clock44xx.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 10e6c6e..03058ad 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -7,22 +7,14 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o 
timer-gp.o
 
 omap-2-3-common= irq.o sdrc.o omap_hwmod.o \
  omap_hwmod_common_data.o
-omap-3-4-common= dpll3xxx.o
 prcm-common= prcm.o powerdomain.o
 clock-common   = clock.o clock_common_data.o \
  clockdomain.o clkt_dpll.o \
  clkt_clksel.o
-clock-omap2xxx = clkt2xxx_dpllcore.o \
- clkt2xxx_virt_prcm_set.o \
- clkt2xxx_apll.o clkt2xxx_osc.o \
- clkt2xxx_sys.o
-clock-omap3xxx = clkt34xx_dpll3m2.o
-
-obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
-   $(clock-omap2xxx)
-obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
-   $(omap-3-4-common) $(clock-omap3xxx)
-obj-$(CONFIG_ARCH_OMAP4) += $(omap-3-4-common) $(prcm-common) $(clock-common)
+
+obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common)
+obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(omap-3-4-common) $(prcm-common)
 
 obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 
@@ -56,14 +48,24 @@ obj-$(CONFIG_ARCH_OMAP3)+= cm.o
 obj-$(CONFIG_ARCH_OMAP4)   += cm4xxx.o
 
 # Clock framework
-obj-$(CONFIG_ARCH_OMAP2)   += clock2xxx.o clock2xxx_data.o
+obj-$(CONFIG_ARCH_OMAP2)   += $(clock-common) clock2xxx.o \
+  clock2xxx_data.o clkt2xxx_sys.o \
+  clkt2xxx_dpllcore.o \
+  clkt2xxx_virt_prcm_set.o \
+  clkt2xxx_apll.o clkt2xxx_osc.o
+obj-$(CONFIG_ARCH_OMAP3)   += $(clock-common) clock3xxx.o \
+  clock34xx.o clkt34xx_dpll3m2.o \
+  clock3517.o clock36xx.o \
+  dpll3xxx.o cl

[PATCH 07/13] OMAP clock: drop .id field; ensure each clock has a unique name

2010-02-11 Thread Paul Walmsley
After the clkdev conversion, the struct clk.id became superfluous, so,
drop it.  Bring the clock names closer to the TRMs and ensure they are
unique for debugfs.

Signed-off-by: Paul Walmsley 
---
 arch/arm/mach-omap1/clock_data.c|   10 +---
 arch/arm/mach-omap2/clock2xxx_data.c|   81 ++---
 arch/arm/mach-omap2/clock34xx_data.c|   88 +++
 arch/arm/plat-omap/clock.c  |2 -
 arch/arm/plat-omap/include/plat/clock.h |1 
 5 files changed, 61 insertions(+), 121 deletions(-)

diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index edefb34..cea91cd 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -530,7 +530,7 @@ static struct clk bclk_16xx = {
 };
 
 static struct clk mmc1_ck = {
-   .name   = "mmc_ck",
+   .name   = "mmc1_ck",
.ops= &clkops_generic,
/* Functional clock is direct from ULPD, interface clock is ARMPER */
.parent = &armper_ck.clk,
@@ -541,8 +541,7 @@ static struct clk mmc1_ck = {
 };
 
 static struct clk mmc2_ck = {
-   .name   = "mmc_ck",
-   .id = 1,
+   .name   = "mmc2_ck",
.ops= &clkops_generic,
/* Functional clock is direct from ULPD, interface clock is ARMPER */
.parent = &armper_ck.clk,
@@ -553,8 +552,7 @@ static struct clk mmc2_ck = {
 };
 
 static struct clk mmc3_ck = {
-   .name   = "mmc_ck",
-   .id = 2,
+   .name   = "mmc3_ck",
.ops= &clkops_generic,
/* Functional clock is direct from ULPD, interface clock is ARMPER */
.parent = &armper_ck.clk,
@@ -577,7 +575,6 @@ static struct clk virtual_ck_mpu = {
 remains active during MPU idle whenever this is enabled */
 static struct clk i2c_fck = {
.name   = "i2c_fck",
-   .id = 1,
.ops= &clkops_null,
.flags  = CLOCK_NO_IDLE_PARENT,
.parent = &armxor_ck.clk,
@@ -586,7 +583,6 @@ static struct clk i2c_fck = {
 
 static struct clk i2c_ick = {
.name   = "i2c_ick",
-   .id = 1,
.ops= &clkops_null,
.flags  = CLOCK_NO_IDLE_PARENT,
.parent = &armper_ck.clk,
diff --git a/arch/arm/mach-omap2/clock2xxx_data.c 
b/arch/arm/mach-omap2/clock2xxx_data.c
index 9bcef44..82ad8b4 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -1224,9 +1224,8 @@ static struct clk gpt12_fck = {
 };
 
 static struct clk mcbsp1_ick = {
-   .name   = "mcbsp_ick",
+   .name   = "mcbsp1_ick",
.ops= &clkops_omap2_dflt_wait,
-   .id = 1,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
@@ -1235,9 +1234,8 @@ static struct clk mcbsp1_ick = {
 };
 
 static struct clk mcbsp1_fck = {
-   .name   = "mcbsp_fck",
+   .name   = "mcbsp1_fck",
.ops= &clkops_omap2_dflt_wait,
-   .id = 1,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
@@ -1246,9 +1244,8 @@ static struct clk mcbsp1_fck = {
 };
 
 static struct clk mcbsp2_ick = {
-   .name   = "mcbsp_ick",
+   .name   = "mcbsp2_ick",
.ops= &clkops_omap2_dflt_wait,
-   .id = 2,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
@@ -1257,9 +1254,8 @@ static struct clk mcbsp2_ick = {
 };
 
 static struct clk mcbsp2_fck = {
-   .name   = "mcbsp_fck",
+   .name   = "mcbsp2_fck",
.ops= &clkops_omap2_dflt_wait,
-   .id = 2,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
@@ -1268,9 +1264,8 @@ static struct clk mcbsp2_fck = {
 };
 
 static struct clk mcbsp3_ick = {
-   .name   = "mcbsp_ick",
+   .name   = "mcbsp3_ick",
.ops= &clkops_omap2_dflt_wait,
-   .id = 3,
.parent = &l4_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN2),
@@ -1279,9 +1274,8 @@ static struct clk mcbsp3_ick = {
 };
 
 static struct clk mcbsp3_fck = {
-   .name   = "mcbsp_fck",
+   .name   = "mcbsp3_fck",
.ops= &clkops_omap2_dflt_wait,
-   .id = 3,
.parent = &func_96m_ck,
.clkdm_name = "core_l4_clkdm",
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP24XX_CM

[PATCH 01/13] OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation

2010-02-11 Thread Paul Walmsley
The maximum DPLL multiplier (M) values for OMAP2xxx and OMAP3xxx are
one increment higher than they should be.  See for example the
OMAP242x TRM Rev X Section 5.10.6 "Clock Generator Registers" and the
OMAP36xx TRM Rev C Table 3-202 "CM_CLKSEL1_PLL".  Programming a 0 into
the DPLL's M register bitfield is valid for OMAP2/3 and indicates that
the DPLL should enter MN-bypass mode.  Also, increase the minimum
multiplier (M) value for the DPLL rate rounding code from 1 to 2, to
ensure that it does not inadvertently put the DPLL into bypass.

Note that the register documentation in the OMAP2xxx and OMAP3xxx TRMs
does not make clear that the actual DPLL divider value (the "N") is
the content of the appropriate register bitfield for the N value,
_plus one_.  (In other words, an N register bitfield of 0 indicates a
DPLL divider value of 1.)  This is only clearly documented in the
OMAP4430 TRM, in, for example, OMAP4430 TRM Rev A Table 3-1167
"CM_CLKSEL_DPLL_USB".

While here, update copyrights, add kerneldoc for struct dpll_data,
drop the unused struct dpll_data.max_tolerance field, remove some
unnecessary #includes in DPLL-related code, and replace the #include
of  with , which is what was really
needed.  The OMAP4 clock autogenerator script has been updated
accordingly.

Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
Cc: Rajendra Nayak 
---
 arch/arm/mach-omap2/clkt_dpll.c |2 -
 arch/arm/mach-omap2/clock2xxx_data.c|6 +--
 arch/arm/mach-omap2/clock34xx_data.c|8 ++--
 arch/arm/mach-omap2/clock44xx.h |7 +++
 arch/arm/mach-omap2/clock44xx_data.c|2 -
 arch/arm/mach-omap2/dpll3xxx.c  |4 --
 arch/arm/plat-omap/include/plat/clock.h |   64 +--
 7 files changed, 67 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 9eee0e6..6ce512e 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -29,7 +29,7 @@
 #include "cm-regbits-34xx.h"
 
 /* DPLL rate rounding: minimum DPLL multiplier, divider values */
-#define DPLL_MIN_MULTIPLIER1
+#define DPLL_MIN_MULTIPLIER2
 #define DPLL_MIN_DIVIDER   1
 
 /* Possible error results from _dpll_test_mult */
diff --git a/arch/arm/mach-omap2/clock2xxx_data.c 
b/arch/arm/mach-omap2/clock2xxx_data.c
index 52c7a6c..f20a4b2 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -2,7 +2,7 @@
  *  linux/arch/arm/mach-omap2/clock2xxx_data.c
  *
  *  Copyright (C) 2005-2009 Texas Instruments, Inc.
- *  Copyright (C) 2004-2009 Nokia Corporation
+ *  Copyright (C) 2004-2010 Nokia Corporation
  *
  *  Contacts:
  *  Richard Woodruff 
@@ -13,9 +13,9 @@
  * published by the Free Software Foundation.
  */
 
-#include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -107,7 +107,7 @@ static struct dpll_data dpll_dd = {
.clk_ref= &sys_ck,
.control_reg= OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
.enable_mask= OMAP24XX_EN_DPLL_MASK,
-   .max_multiplier = 1024,
+   .max_multiplier = 1023,
.min_divider= 1,
.max_divider= 16,
.rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE
diff --git a/arch/arm/mach-omap2/clock34xx_data.c 
b/arch/arm/mach-omap2/clock34xx_data.c
index 972a90a..92529da 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -1,8 +1,8 @@
 /*
  * OMAP3 clock data
  *
- * Copyright (C) 2007-2009 Texas Instruments, Inc.
- * Copyright (C) 2007-2009 Nokia Corporation
+ * Copyright (C) 2007-2010 Texas Instruments, Inc.
+ * Copyright (C) 2007-2010 Nokia Corporation
  *
  * Written by Paul Walmsley
  * With many device clock fixes by Kevin Hilman and Jouni Högander
@@ -16,9 +16,9 @@
  * to be requested from drivers directly.
  */
 
-#include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -37,7 +37,7 @@
 #define OMAP_CM_REGADDROMAP34XX_CM_REGADDR
 
 /* Maximum DPLL multiplier, divider values for OMAP3 */
-#define OMAP3_MAX_DPLL_MULT2048
+#define OMAP3_MAX_DPLL_MULT2047
 #define OMAP3630_MAX_JTYPE_DPLL_MULT   4095
 #define OMAP3_MAX_DPLL_DIV 128
 
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 1f55b6b..ed3b741 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -2,12 +2,17 @@
  * OMAP4 clock function prototypes and macros
  *
  * Copyright (C) 2009 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
  */
 
 #ifndef __ARCH_ARM_MACH_OMAP2_CLOCK_44XX_H
 #define __ARCH_ARM_MACH_OMAP2_CLOCK_44XX_H
 
-#define OMAP4430_MAX_DPLL_MULT 2048
+/*
+ * XXX Missing values for the OMAP4 DPLL_USB
+ * XXX Missing min_multiplier values for all OMAP4 DPLLs
+ */
+#define OMAP4430_MAX_DPLL_MULT 2047
 #define OMAP4430_MAX_DPLL_DIV  128
 
 int omap4xxx_

[PATCH 00/13] OMAP: clock: cleanup series for 2.6.34

2010-02-11 Thread Paul Walmsley
Hello,

this series, targeted for 2.6.34,

- fixes several OMAP clock bugs,

- removes several unnecessary clock structure fields and clock flags,

- splits the OMAP2420 and OMAP2430 clock trees in preparation for
  multi-OMAP 2 kernels,

- and modularizes the OMAP3 chip family-specific clock code so
  some code and data that is not applicable to a targeted build
  can be elided during compilation.

The series has been boot-tested on the OMAP2430 SDP.  Further testing
is now being undertaken on OMAP5912 OSK, N800 and OMAP3530 Beagle.


- Paul

---

size:
   textdata bss dec hex filename
3420642  179744  146880 3747266  392dc2 vmlinux.2430sdp.orig
3420170  176928  146880 3743978  3920ea vmlinux.2430sdp.patched


Paul Walmsley (13):
  OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, 
includes, documentation
  OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag
  OMAP2xxx clock: GFX functional clock rates are not independently 
changeable
  OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks
  OMAP2 clock: drop CONFIG_PARTICIPANT clock flag
  OMAP clock: compress clock flags down to a u8
  OMAP clock: drop .id field; ensure each clock has a unique name
  OMAP3/4 clock: split into per-chip family files
  OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
  OMAP2430 clock: make func_96m_ck parent-selectable
  OMAP2 clock: drop DELAYED_APP clock flag
  OMAP clock: drop RATE_FIXED clock flag
  OMAP4 clock: drop the ALWAYS_ENABLED clock flag


 arch/arm/mach-omap1/clock.c |5 
 arch/arm/mach-omap1/clock_data.c|   35 +-
 arch/arm/mach-omap2/Makefile|   38 +-
 arch/arm/mach-omap2/clkt2xxx_apll.c |4 
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c  |1 
 arch/arm/mach-omap2/clkt_clksel.c   |8 
 arch/arm/mach-omap2/clkt_dpll.c |2 
 arch/arm/mach-omap2/clock.c |   50 +-
 arch/arm/mach-omap2/clock.h |2 
 arch/arm/mach-omap2/clock2420_data.c|  697 +++
 arch/arm/mach-omap2/clock2430.c |   59 +++
 arch/arm/mach-omap2/clock2430_data.c|  637 +++-
 arch/arm/mach-omap2/clock2xxx.c |   38 --
 arch/arm/mach-omap2/clock2xxx.h |   26 +
 arch/arm/mach-omap2/clock34xx.c |  260 
 arch/arm/mach-omap2/clock34xx.h |   27 -
 arch/arm/mach-omap2/clock3517.c |  124 ++
 arch/arm/mach-omap2/clock3517.h |   14 +
 arch/arm/mach-omap2/clock36xx.c |   72 +++
 arch/arm/mach-omap2/clock36xx.h |   13 +
 arch/arm/mach-omap2/clock3xxx.c |  145 ++
 arch/arm/mach-omap2/clock3xxx.h |   21 +
 arch/arm/mach-omap2/clock3xxx_data.c|  112 ++---
 arch/arm/mach-omap2/clock44xx.c |   19 -
 arch/arm/mach-omap2/clock44xx.h |   13 -
 arch/arm/mach-omap2/clock44xx_data.c|  127 --
 arch/arm/mach-omap2/dpll3xxx.c  |4 
 arch/arm/mach-omap2/io.c|8 
 arch/arm/plat-omap/clock.c  |2 
 arch/arm/plat-omap/include/plat/clock.h |   82 ++--
 30 files changed, 964 insertions(+), 1681 deletions(-)
 copy arch/arm/mach-omap2/{clock2xxx_data.c => clock2420_data.c} (72%)
 create mode 100644 arch/arm/mach-omap2/clock2430.c
 rename arch/arm/mach-omap2/{clock2xxx_data.c => clock2430_data.c} (75%)
 create mode 100644 arch/arm/mach-omap2/clock3517.c
 create mode 100644 arch/arm/mach-omap2/clock3517.h
 create mode 100644 arch/arm/mach-omap2/clock36xx.c
 create mode 100644 arch/arm/mach-omap2/clock36xx.h
 create mode 100644 arch/arm/mach-omap2/clock3xxx.c
 create mode 100644 arch/arm/mach-omap2/clock3xxx.h
 rename arch/arm/mach-omap2/{clock34xx_data.c => clock3xxx_data.c} (98%)
 delete mode 100644 arch/arm/mach-omap2/clock44xx.c

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


RE: [PATCH] OMAP: Fix for bus width which improves SD card's peformance.

2010-02-11 Thread Madhusudhan


> -Original Message-
> From: kishore kadiyala [mailto:kishore.kadiy...@ti.com]
> Sent: Thursday, February 11, 2010 8:20 AM
> To: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: jarkko.lavi...@nokia.com; madhu...@ti.com
> Subject: [PATCH] OMAP: Fix for bus width which improves SD card's
> peformance.
> 
> This patch improves low speeds for SD cards.
> OMAP-MMC controller's can support maximum bus width of '8'.
> when bus width is mentioned as "8" in controller data,the SD
> stack will check whether bus width is "4" and if not it will
> set bus width to "1" and there by degrading peformance.
> This patch fixes the issue and improves the performance of
> SD cards.
> 
> Signed-off-by: Kishore Kadiyala 

ACK

Acked-by: Madhusudhan Chikkature 

> ---
>  Here are my experiment numbers, on a Class 6 SDHC card:
>  Read peformance is increased by 220%
>  Write Performance is increased by 52%
> 
>  drivers/mmc/host/omap_hsmmc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 83f0aff..8c97c22 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct
> platform_device
> *pdev)
>MMC_CAP_WAIT_WHILE_BUSY;
> 
>   if (mmc_slot(host).wires >= 8)
> - mmc->caps |= MMC_CAP_8_BIT_DATA;
> + mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA);
>   else if (mmc_slot(host).wires >= 4)
>   mmc->caps |= MMC_CAP_4_BIT_DATA;
> 
> --
> 1.6.3.3

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


[PATCH v2] DSPBRIDGE: Fix to avoid possible recursive locking

2010-02-11 Thread Deepak Chitriki
Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().

Cc: Ameya Palande 
Cc: Omar Ramirez Luna 
Cc: Nishanth Menon 

Signed-off-by: Deepak Chitriki 

---
Ref:
v0:http://marc.info/?l=linux-omap&m=126584779011493&w=2
v1:http://marc.info/?l=linux-omap&m=126586224627725&w=2
v2:Comment fixes from v1

 drivers/dsp/bridge/wmd/msg_sm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index d778cbc..7414113 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -295,7 +295,7 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
   (struct list_head *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_ResetEvent(hMsgQueue->hSyncEvent);
-   else 
+   else
SYNC_SetEvent(hMsgQueue->hSyncEvent);
 
fGotMsg = true;
@@ -344,7 +344,7 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue->refCount--;
/* Reset the event if there are still queued messages */
-   if (!LST_IsEmpty(hMsgQueue->msgUsedList)) 
+   if (!LST_IsEmpty(hMsgQueue->msgUsedList))
SYNC_SetEvent(hMsgQueue->hSyncEvent);
 
/* Exit critical section */
-- 
1.6.3.3

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


Re: [RESEND][PATCHv2 3/4] Add ASoC support for Devkit8000

2010-02-11 Thread Jarkko Nikula
On Thu, 11 Feb 2010 15:20:28 +
Liam Girdwood  wrote:

> On Thu, 2010-02-11 at 16:13 +0100, Thomas Weber wrote:
> > This patch expands the omap3beagle sound soc for the
> > beagle board clone DevKit8000.
> > 
> > Signed-off-by: Thomas Weber 
> 
> Acked-by: Liam Girdwood 
> 
Acked-by: Jarkko Nikula 

Note, this is safe to push even if this goes to mainline before the
basic board file and arch/arm/mach-omap2/Kconfig change from linux-omap.
The machine type and so machine_is_devkit8000() are already there.


-- 
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Mark Brown
On Thu, Feb 11, 2010 at 05:02:54PM +0200, Peter Ujfalusi wrote:
> On Thursday 11 February 2010 13:14:18 ext Jarkko Nikula wrote:

> > Yeah, after thinking twice, we don't have zillions of options for e.g.
> > Intel HDA either. If we ever figure out some common OMAP+TWL4030

> Well, I really doubt that we can find a way to have a common driver for this 
> combination. You can attach quite a big variety of amps to the outputs (some 
> controlled with GPIO, some like the tpa6130 has i2c interface, etc).
> To have some kind of "infrastructure" to support all of the possible 
> scenarios 
> is just does not worth the effort IMHO.

On the other hand there's probably going to be a bunch of boards which
can use the same driver by virtue of having copied the audio subsystem
en masse from one of the reference designs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Circular mm_lock semaphore in omapfb code

2010-02-11 Thread Peter Barada
I've got a version of OMAP 2.6.33-rc3 up on my board, based on Kevin's
tree, commit 838cb5e10ba0131bd46b5404d313980144a481a5

And I've added in my LCD code which works (I see a penguin on bootup).
 I have CONFIG_FB_OMAP enabled and CONFIG_OMAp2_DSS not disabled in my
kernel config.

When I try to execute a small test program that maps in the
framebuffer with the following code(stripped down):

ret = ioctl(fb, FBIOGET_FSCREENINFO, &fb_fix);
ret = ioctl(fb, FBIOGET_VSCREENINFO, &fb_var);
fb_size = fb_var.xres * fb_var.yres * fb_var.bits_per_pixel/8;
fb_ptr = mmap(NULL, fb_size, PROT_READ|PROT_WRITE, MAP_SHARED, fb, 0);

to map in the frame buffer for scribbling, and I get:

===
[ INFO: possible circular locking dependency detected ]
2.6.33-rc3 #5
---
draw-test/1018 is trying to acquire lock:
 (&fbdev->rqueue_mutex){+.+...}, at: [] omapfb_mmap+0x1c/0x44

but task is already holding lock:
 (&fb_info->mm_lock){+.+...}, at: [] fb_mmap+0x50/0x164

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&fb_info->mm_lock){+.+...}:
   [] __lock_acquire+0x1394/0x173c
   [] lock_acquire+0xd8/0xf0
   [] mutex_lock_nested+0x60/0x2e4
   [] set_fb_fix+0x38/0xd8
   [] omapfb_set_par+0x24/0x40
   [] fbcon_init+0x2e0/0x408
   [] visual_init+0xf4/0x148
   [] bind_con_driver+0x2f4/0x444
   [] take_over_console+0x34/0x3c
   [] fbcon_takeover+0x78/0xe4
   [] fbcon_event_notify+0x2a8/0x6f0
   [] notifier_call_chain+0x2c/0x70
   [] __blocking_notifier_call_chain+0x48/0x5c
   [] blocking_notifier_call_chain+0x14/0x18
   [] register_framebuffer+0x29c/0x2d8
   [] omapfb_do_probe+0x5f8/0x86c
   [] omap3logic_panel_probe+0xc/0x18
   [] platform_drv_probe+0x18/0x1c
   [] driver_probe_device+0xa0/0x14c
   [] __driver_attach+0x60/0x84
   [] bus_for_each_dev+0x44/0x74
   [] bus_add_driver+0x100/0x28c
   [] driver_register+0xa8/0x130
   [] do_one_initcall+0x5c/0x1bc
   [] kernel_init+0x90/0x10c
   [] kernel_thread_exit+0x0/0x8

-> #0 (&fbdev->rqueue_mutex){+.+...}:
   [] __lock_acquire+0x1044/0x173c
   [] lock_acquire+0xd8/0xf0
   [] mutex_lock_nested+0x60/0x2e4
   [] omapfb_mmap+0x1c/0x44
   [] fb_mmap+0x68/0x164
   [] mmap_region+0x1d8/0x3b0
   [] sys_mmap_pgoff+0x94/0xc0
   [] ret_fast_syscall+0x0/0x38

other info that might help us debug this:

2 locks held by draw-test/1018:
 #0:  (&mm->mmap_sem){++}, at: [] sys_mmap_pgoff+0x70/0xc0
 #1:  (&fb_info->mm_lock){+.+...}, at: [] fb_mmap+0x50/0x164

stack backtrace:
[] (unwind_backtrace+0x0/0xdc) from [] (print_circular_bug+0
xc8/0xe0)
[] (print_circular_bug+0xc8/0xe0) from [] (__lock_acquire+0x
1044/0x173c)
[] (__lock_acquire+0x1044/0x173c) from [] (lock_acquire+0xd8
/0xf0)
[] (lock_acquire+0xd8/0xf0) from [] (mutex_lock_nested+0x60/
0x2e4)
[] (mutex_lock_nested+0x60/0x2e4) from [] (omapfb_mmap+0x1c/
0x44)
[] (omapfb_mmap+0x1c/0x44) from [] (fb_mmap+0x68/0x164)
[] (fb_mmap+0x68/0x164) from [] (mmap_region+0x1d8/0x3b0)
[] (mmap_region+0x1d8/0x3b0) from [] (sys_mmap_pgoff+0x94/0x
c0)
[] (sys_mmap_pgoff+0x94/0xc0) from [] (ret_fast_syscall+0x0/
0x38)

Has anyone seen this before?
--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes

2010-02-11 Thread Felipe Contreras
On Wed, Feb 10, 2010 at 06:31:35PM +0100, ext Guzman Lugo, Fernando wrote:
> >-Original Message-
> >From: Felipe Contreras [mailto:felipe.contre...@nokia.com]
> >> Resource cleanup does not support that even without my proposed changes.
> >
> >Aha! I suspected it :P
> >
> Resource cleanup does not support that because it tries to unreserved
> every chunk mapped. However it does not means the dspbridge does not
> support reserving a big chunk of memory and mapping small parts of
> that memory, but I have not tested it to confirm if it works.

I think I did once and it didn't work, but I thought the problem was in
my app. Anyway I think we should either forget about this use-case or
fix the resource cleaning.

> >> I just proposed a solution which fixes two issues in one patch.
> >> Moreover if this change is merged when the second issue be fixed this
> >> patch will not needed anymore, so why don't merge the patch which
> >> fixes both errors at this moment?
> >
> >simple patches > complicated patches
> The patch is more simple than it looks.

Only one way to know :)

> >Personally I think your patches should be a continuation to the patches
> >I just proposed.
> Yes, I think it would be better.

Cool.

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


Re: [RESEND][PATCHv2 3/4] Add ASoC support for Devkit8000

2010-02-11 Thread Liam Girdwood
On Thu, 2010-02-11 at 16:13 +0100, Thomas Weber wrote:
> This patch expands the omap3beagle sound soc for the
> beagle board clone DevKit8000.
> 
> Signed-off-by: Thomas Weber 

Acked-by: Liam Girdwood 

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

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


[RESEND][PATCHv2 3/4] Add ASoC support for Devkit8000

2010-02-11 Thread Thomas Weber
This patch expands the omap3beagle sound soc for the
beagle board clone DevKit8000.

Signed-off-by: Thomas Weber 
---
 sound/soc/omap/Kconfig   |8 +---
 sound/soc/omap/omap3beagle.c |6 +++---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 61952aa..18ebdc7 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -94,12 +94,14 @@ config SND_OMAP_SOC_OMAP3_PANDORA
  Say Y if you want to add support for SoC audio on the OMAP3 Pandora.
 
 config SND_OMAP_SOC_OMAP3_BEAGLE
-   tristate "SoC Audio support for OMAP3 Beagle"
-   depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_BEAGLE
+   tristate "SoC Audio support for OMAP3 Beagle and Devkit8000"
+   depends on TWL4030_CORE && SND_OMAP_SOC
+   depends on (MACH_OMAP3_BEAGLE || MACH_DEVKIT8000)
select SND_OMAP_SOC_MCBSP
select SND_SOC_TWL4030
help
- Say Y if you want to add support for SoC audio on the Beagleboard.
+ Say Y if you want to add support for SoC audio on the Beagleboard or
+ the clone Devkit8000.
 
 config SND_OMAP_SOC_ZOOM2
tristate "SoC Audio support for Zoom2"
diff --git a/sound/soc/omap/omap3beagle.c b/sound/soc/omap/omap3beagle.c
index d88ad5c..240e097 100644
--- a/sound/soc/omap/omap3beagle.c
+++ b/sound/soc/omap/omap3beagle.c
@@ -117,11 +117,11 @@ static int __init omap3beagle_soc_init(void)
 {
int ret;
 
-   if (!machine_is_omap3_beagle()) {
-   pr_debug("Not OMAP3 Beagle!\n");
+   if (!(machine_is_omap3_beagle() || machine_is_devkit8000())) {
+   pr_debug("Not OMAP3 Beagle or Devkit8000!\n");
return -ENODEV;
}
-   pr_info("OMAP3 Beagle SoC init\n");
+   pr_info("OMAP3 Beagle/Devkit8000 SoC init\n");
 
omap3beagle_snd_device = platform_device_alloc("soc-audio", -1);
if (!omap3beagle_snd_device) {
-- 
1.6.6.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: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Peter Ujfalusi
On Thursday 11 February 2010 13:14:18 ext Jarkko Nikula wrote:
> On Thu, 11 Feb 2010 10:49:48 +
> 
> Liam Girdwood  wrote:
> > I do agree this makes good sense for boards that are very similar and
> > have different audio options/config, but in this case the ASoC mach
> > drivers are identical (atm). Imo it just makes more sense to keep the
> > one Kconfig.
> 
> Yeah, after thinking twice, we don't have zillions of options for e.g.
> Intel HDA either. If we ever figure out some common OMAP+TWL4030
> driver, the defconfigs are anyway have to modify so it's better stay
> with the original patch:

Well, I really doubt that we can find a way to have a common driver for this 
combination. You can attach quite a big variety of amps to the outputs (some 
controlled with GPIO, some like the tpa6130 has i2c interface, etc).
To have some kind of "infrastructure" to support all of the possible scenarios 
is just does not worth the effort IMHO.

> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025129.h
> tml
> 
> Sorry about line noise, Thomas :-)
> 

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


[PATCH] OMAP: Fix for bus width which improves SD card's peformance.

2010-02-11 Thread kishore kadiyala
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as "8" in controller data,the SD
stack will check whether bus width is "4" and if not it will
set bus width to "1" and there by degrading peformance.
This patch fixes the issue and improves the performance of
SD cards.

Signed-off-by: Kishore Kadiyala 
---
 Here are my experiment numbers, on a Class 6 SDHC card:
 Read peformance is increased by 220%
 Write Performance is increased by 52%

 drivers/mmc/host/omap_hsmmc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 83f0aff..8c97c22 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
 MMC_CAP_WAIT_WHILE_BUSY;

if (mmc_slot(host).wires >= 8)
-   mmc->caps |= MMC_CAP_8_BIT_DATA;
+   mmc->caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA);
else if (mmc_slot(host).wires >= 4)
mmc->caps |= MMC_CAP_4_BIT_DATA;

-- 
1.6.3.3


binjE3zK1O3r0.bin
Description: Binary data


installing miro

2010-02-11 Thread Niamathullah sharief
hello,
   I am using omap processor board. In that i want to install "miro"
software. is it possible?if yes how to do that? please help me
--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Validate node handle from user

2010-02-11 Thread Ameya Palande
On Tue, 2010-02-09 at 18:52 +0100, ext Ramos Falcon, Ernesto wrote:
> 
> >-Original Message-
> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> >Sent: Tuesday, February 09, 2010 11:32 AM
> >To: Ramos Falcon, Ernesto
> >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
> >Hiroshi (Nokia-D/Helsinki)
> >Subject: Re: [PATCH] DSPBRIDGE: Validate node handle from user
> >
> >Hi Ernesto,
> >
> >On Tue, 2010-02-09 at 18:08 +0100, ext Ramos Falcon, Ernesto wrote:
> >> From 8310b586b025b0703c3951560849c4ea0250b6e1 Mon Sep 17 00:00:00 2001
> >> From: Ernesto Ramos 
> >> Date: Fri, 29 Jan 2010 16:21:59 -0600
> >> Subject: [PATCH] DSPBRIDGE: Validate node handle from user.
> >>
> >> Add checks to validate the node handles received from user.
> >>
> >> Signed-off-by: Ernesto Ramos 
> >> ---
> >>  drivers/dsp/bridge/pmgr/wcd.c  |   91 -
> >>  drivers/dsp/bridge/rmgr/node.c |  174 +-
> >-
> >>  2 files changed, 146 insertions(+), 119 deletions(-)
> >>
> >> diff --git a/drivers/dsp/bridge/pmgr/wcd.c
> >b/drivers/dsp/bridge/pmgr/wcd.c
> >> index 74654dc..2e6eeb0 100644
> >> --- a/drivers/dsp/bridge/pmgr/wcd.c
> >> +++ b/drivers/dsp/bridge/pmgr/wcd.c
> >> @@ -1066,6 +1066,24 @@ u32 PROCWRAP_Stop(union Trapped_Args *args, void
> >*pr_ctxt)
> >> return retVal;
> >>  }
> >>
> >> +bool validate_node_handle(struct NODE_OBJECT *hNode, void *pr_ctxt)
> >> +{
> >> +   bool retVal = false;
> >> +   struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
> >> +   struct NODE_RES_OBJECT *pNode = pCtxt->pNodeList;
> >> +
> >> +   if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
> >> +   retVal = true;
> >> +
> >> +   while (pNode && !retVal) {
> >> +   if (hNode == pNode->hNode)
> >
> >If you have several nodes allocated by user space, then what you are
> >validating here is for any node! Is that ok?
> >
> >This validation and design itself doesn't look good to me. If we don't
> >want to trust user space, then instead of checking the node handle in
> >every function it is better to store all user space specific date inside
> >pr_context and use it from there.
> >
> 
> The user can launch several nodes, how are we going to know which node handle 
> to use?
> I think we may need to receive at least one index or id to the node handle.

Yes, I guess thats the correct way! We need to maintain how many nodes
are allocated for a user process, and just make sure that this id /
index is <= number of allocated nodes.

Cheers,
Ameya.

--
To unsubscribe from this list: send the line "unsubscribe 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] DSPBRIDGE: Validate Processor Handle from user

2010-02-11 Thread Ameya Palande
On Tue, 2010-02-09 at 18:51 +0100, ext Ramos Falcon, Ernesto wrote:
> 
> >-Original Message-
> >From: Ameya Palande [mailto:ameya.pala...@nokia.com]
> >Sent: Tuesday, February 09, 2010 11:27 AM
> >To: Ramos Falcon, Ernesto
> >Cc: linux-omap@vger.kernel.org; Contreras Felipe (Nokia-D/Helsinki); Doyu
> >Hiroshi (Nokia-D/Helsinki)
> >Subject: Re: [PATCH] DSPBRIDGE: Validate Processor Handle from user
> >
> >Hi Ernesto,
> >
> >On Tue, 2010-02-09 at 18:07 +0100, ext Ramos Falcon, Ernesto wrote:
> >> From 07b9f6d30c9d363ba0c4cefded8068662e1048c4 Mon Sep 17 00:00:00 2001
> >> From: Ernesto Ramos 
> >> Date: Wed, 3 Feb 2010 19:43:31 -0600
> >> Subject: [PATCH] DSPBRIDGE: Validate Processor Handle from user.
> >>
> >> Add check to validate the Processor handle received
> >> from user.
> >>
> >> Signed-off-by: Ernesto Ramos 
> >> ---
> >>  drivers/dsp/bridge/pmgr/wcd.c  |   86 -
> >>  drivers/dsp/bridge/rmgr/proc.c |  280 ++
> >--
> >>  2 files changed, 179 insertions(+), 187 deletions(-)
> >
> >My understanding: In bridge_open() we allocate a new process_context and
> >store it in filp->private_data which can't be modified / tampered by
> >user space.
> >
> >If this understanding is correct, then why we need to perform any
> >validation on data hold be process_context pointer stored in
> >flip->private_data?
> >
> >If you don't trust hProcessor handle received from user space arguments
> >then instead of using that we can just use pCtxt->hProcessor!
> >
> 
> Agree. We plan to remove the Proc Attach and remove the parameter hProcessor 
> handle passed to the user but we have not done it yet because it may impact 
> the API.
> 
> >I don't understand why we need validation so NACK from my side.
> >
> 
> We have had some cases where we receive an invalid proc handle from user 
> which resulted in kernel panic. 

Why are we using a processor handle passed from user space?

Instead of checking validity of this parameter can't we just use
pCtxt->hProcessor? This way we can get rid of all the checks!

Cheers,
Ameya.





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


modules installation doubt

2010-02-11 Thread Niamathullah sharief
Hello,
  i am using omap processor. In that i am using "2.6.32.7-x7.0" kernel
but when i use modprobe i am getting "FATAL: Could not load
/lib/modules/2.6.32/modules.dep: No such file or directory ". The
thing is it is different filesystem. So where to change for that? How
to fix this problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards

2010-02-11 Thread Mike Rapoport
David Vrabel wrote:
> Mike Rapoport wrote:
>> I've started to apply the patches one by one and after the first patch
>> is applied, the SD card works Ok, but libertas fails to initialize with
>> the following messages:
>>
>>> modprobe libertas_sdio
>> [   82.233489] lib80211: common routines for IEEE802.11 drivers
>> [   82.833251] cfg80211: Calling CRDA to update world regulatory domain
>> [   83.327911] libertas_sdio: Libertas SDIO driver
>> [   83.332489] libertas_sdio: Copyright Pierre Ossman
>> [   83.348510] libertas_sdio mmc1:0001:1: firmware: requesting
>> sd8686_helper.bin
>> [   83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
>> [   83.679229] DMA synchronization event drop occurred with device 47
> 
> What block size are you using?  It looks like you're using something
> less than 512. I've checked the spec again and the DMA packet size
> should be the block size in words (and not the FIFO depth).

It's quite possible. I haven't dig too much and I really don't know how exactly
libertas driver sends/receives the data... I'll continue testing and will try 
to get
some more meaningful info

> Also, keep in mind that the buffers for transfers must begin and end on
> a word boundary.  The OMAP's DMA controller can only transfer whole
> words to the MMC FIFO.
> 
> David


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


Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards

2010-02-11 Thread David Vrabel
Mike Rapoport wrote:
> 
> I've started to apply the patches one by one and after the first patch
> is applied, the SD card works Ok, but libertas fails to initialize with
> the following messages:
> 
>> modprobe libertas_sdio
> [   82.233489] lib80211: common routines for IEEE802.11 drivers
> [   82.833251] cfg80211: Calling CRDA to update world regulatory domain
> [   83.327911] libertas_sdio: Libertas SDIO driver
> [   83.332489] libertas_sdio: Copyright Pierre Ossman
> [   83.348510] libertas_sdio mmc1:0001:1: firmware: requesting
> sd8686_helper.bin
> [   83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
> [   83.679229] DMA synchronization event drop occurred with device 47

What block size are you using?  It looks like you're using something
less than 512. I've checked the spec again and the DMA packet size
should be the block size in words (and not the FIFO depth).

Also, keep in mind that the buffers for transfers must begin and end on
a word boundary.  The OMAP's DMA controller can only transfer whole
words to the MMC FIFO.

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


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


Re: Moving board patches from DSS2 to linux-omap

2010-02-11 Thread Tomi Valkeinen
On Thu, 2010-02-11 at 12:50 +0100, ext Mike Rapoport wrote:
> Tomi Valkeinen wrote:
> > Hi,
> > 
> > As discussed previously, board file changes in DSS2 tree cause conflicts
> > with linux-omap easily. There are currently three board file patches in
> > DSS2's for-next branch:
> > 
> > 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display 
> > support
> > 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for 
> > AM3517EVM board
> > 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM 
> > board
> > 
> > The problem here is of course that DSS2 tree may contain unmerged panel
> > drivers, and those board file changes try to use these new panel
> > drivers.
> 
> Well, the panel drivers are referenced by name in the board files, so merging 
> board
> file changes through linux-omap tree should not create merge conflicts and 
> compile
> problems. There just won't be display until DSS2 tree is merged. Or am I 
> missing
> something?

Yes, that is correct. This makes adding new boards and panels a bit more
complicated, but should remove most conflicts that happen between
linux-omap and dss2 trees.

 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: Moving board patches from DSS2 to linux-omap

2010-02-11 Thread Mike Rapoport
Tomi Valkeinen wrote:
> Hi,
> 
> As discussed previously, board file changes in DSS2 tree cause conflicts
> with linux-omap easily. There are currently three board file patches in
> DSS2's for-next branch:
> 
> 722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display 
> support
> 7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for 
> AM3517EVM board
> 40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM board
> 
> The problem here is of course that DSS2 tree may contain unmerged panel
> drivers, and those board file changes try to use these new panel
> drivers.

Well, the panel drivers are referenced by name in the board files, so merging 
board
file changes through linux-omap tree should not create merge conflicts and 
compile
problems. There just won't be display until DSS2 tree is merged. Or am I missing
something?

> Now, I don't think there's a perfect solution for this, but I think a
> working solution would be to put all board file changes to linux-omap
> tree (with the exception of some rare changes that don't compile without
> new DSS2 patches), but leave the kernel config unchanged.
> 
> This way the board file contains references to new panel drivers, but as
> DSS2 nor the panel drivers are enabled in the Kconfig, the board file
> code is not used and everything should work as before.
> 
> Then either I can have Kconfig patches in my tree, which are less likely
> to conflict, or the Kconfig changes can be done after both linux-omap
> and dss2 patches have been merged.
> 
> How does this sound?
> 
>  Tomi
> 
> Ps. I haven't actually tried those board file patches on top of
> linux-omap, but I don't see anything there that would cause compilation
> to fail.
> 
> 


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


[PATCHv3] OMAP3: Serial: Improved sleep logic

2010-02-11 Thread Tero Kristo
From: Tero Kristo 

This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
  on-going transmission to be cut
- Smartidle is disabled while entering idle if we have data in the transmit
  buffer because having this enabled would prevent wakeups from the TX
  interrupt and this would cause pauses while sending large blocks of data
- Sleep prevent timer is changed to use ktime_get() instead of a jiffy timer
  as jiffy timers are not valid within idle loop (tick scheduler is stopped)
- Added RX ignore timer for ignoring the first character received during
  first millisecond of wakeup, this prevents garbage character to be received
  in low sleep states

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/serial.c |   81 -
 1 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 837b347..75ce549 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,12 +23,15 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
+#include 
+
 #include "prm.h"
 #include "pm.h"
 #include "prm-regbits-34xx.h"
@@ -36,13 +39,14 @@
 #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
 #define UART_OMAP_WER  0x17/* Wake-up enable register */
 
-#define DEFAULT_TIMEOUT (5 * HZ)
+#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)
 
 struct omap_uart_state {
int num;
int can_sleep;
-   struct timer_list timer;
-   u32 timeout;
+   ktime_t expire_time;
+   ktime_t garbage_time;
+   u64 timeout;
 
void __iomem *wk_st;
void __iomem *wk_en;
@@ -231,6 +235,9 @@ static inline void omap_uart_enable_clocks(struct 
omap_uart_state *uart)
clk_enable(uart->fck);
uart->clocked = 1;
omap_uart_restore_context(uart);
+
+   /* Set up garbage timer to ignore RX during first 1ms */
+   uart->garbage_time = ktime_add_ns(ktime_get(), NSEC_PER_MSEC);
 }
 
 #ifdef CONFIG_PM
@@ -302,9 +309,7 @@ static void omap_uart_block_sleep(struct omap_uart_state 
*uart)
omap_uart_smart_idle_enable(uart, 0);
uart->can_sleep = 0;
if (uart->timeout)
-   mod_timer(&uart->timer, jiffies + uart->timeout);
-   else
-   del_timer(&uart->timer);
+   uart->expire_time = ktime_add_ns(ktime_get(), uart->timeout);
 }
 
 static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -317,25 +322,28 @@ static void omap_uart_allow_sleep(struct omap_uart_state 
*uart)
if (!uart->clocked)
return;
 
-   omap_uart_smart_idle_enable(uart, 1);
+   if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
+   omap_uart_smart_idle_enable(uart, 1);
uart->can_sleep = 1;
-   del_timer(&uart->timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
-   struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
-   omap_uart_allow_sleep(uart);
 }
 
 void omap_uart_prepare_idle(int num)
 {
struct omap_uart_state *uart;
+   ktime_t t;
 
list_for_each_entry(uart, &uart_list, node) {
+   if (num == uart->num && !uart->can_sleep) {
+   t = ktime_get();
+   if (t.tv64 > uart->expire_time.tv64)
+   uart->can_sleep = 1;
+   }
if (num == uart->num && uart->can_sleep) {
-   omap_uart_disable_clocks(uart);
+   if (serial_read_reg(uart->p, UART_LSR) &
+   UART_LSR_TEMT)
+   omap_uart_disable_clocks(uart);
+   else
+   omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -360,6 +368,7 @@ void omap_uart_resume_idle(int num)
/* Check for normal UART wakeup */
if (__raw_readl(uart->wk_st) & uart->wk_mask)
omap_uart_block_sleep(uart);
+
return;
}
}
@@ -407,10 +416,24 @@ int omap_uart_can_sleep(void)
 static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
 {
struct omap_uart_state *uart = dev_id;
+   u8 lsr;
+   int ret = IRQ_NONE;
 
-   omap_uart_block_sleep(uart);
+   lsr = serial_read_reg(uart->p, UART_LSR);
+   /* Check for receive interrupt */
+   if (lsr & UART_LSR_DR) {
+   omap_uart_block_sleep(uart);
+   if (uart->garbage_time.tv64 &&
+   ktime_get().tv64 < uart->garbage_time.tv64) {
+   serial_read_reg(uart->p, UART_RX);
+   uart->garbage_time.tv64 = 0;
+   ret = IRQ_HANDLED;
+  

[PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency during DVFS

2010-02-11 Thread Reddy, Teerth
From: Teerth Reddy 

Dynamic Calculation of SDRC stall latency during DVFS

The patch has the changes to calculate the dpll3 clock stabilization delay 
dynamically. The SRAM delay is calibrated during bootup using the gptimers and 
used while calculating the stabilization delay. By using the dynamic method the 
dependency on the type of cache being used is removed. Hence there is no need 
of loop based calculation.

The wait time for L3 clock stabilization is calculated using the formula : 
4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the registers.Since 
this value gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3. 

Signed-off-by: Teerth Reddy 
Signed-off-by: Romit Dasgupta 
---
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c|   52 -
 arch/arm/mach-omap2/clock34xx.h   |2 +
 arch/arm/mach-omap2/clock34xx_data.c  |   11 ++
 arch/arm/mach-omap2/sram34xx.S|   17 +
 arch/arm/plat-omap/dmtimer.c  |6 +++
 arch/arm/plat-omap/include/plat/dmtimer.h |1 +
 arch/arm/plat-omap/include/plat/sram.h|5 +++
 arch/arm/plat-omap/sram.c |   51 
 8 files changed, 136 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 8716a01..2e6d774 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,13 +24,22 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clock.h"
 #include "clock34xx.h"
 #include "sdrc.h"
+#include "cm.h"
 
 #define CYCLES_PER_MHZ 100
 
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2   27
+
 /*
  * CORE DPLL (DPLL3) M2 divider rate programming functions
  *
@@ -55,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
int ret;
+   u32 clk_sel_regval;
+   u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
+   u32 sys_clk_rate, sdrc_clk_stab;
+   u32 nr1, nr2, nr, dr;
+   unsigned int delay_sram;
 
if (!clk || !rate)
return -EINVAL;
@@ -78,16 +92,36 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
unlock_dll = 1;
}
 
-   /*
-* XXX This only needs to be done when the CPU frequency changes
-*/
+   clk_sel_regval = cm_read_mod_reg(PLL_MOD, CM_CLKSEL);
+
+   /* Get the M, N and M2 values required for getting sdrc clk stab */
+   core_dpll_mul_m = (clk_sel_regval >> SHIFT_DPLL_M) & DPLL_M_MASK;
+   core_dpll_div_n = (clk_sel_regval >> SHIFT_DPLL_N) & DPLL_N_MASK;
+   core_dpll_clkoutdiv_m2 = (clk_sel_regval >> SHIFT_DPLL_M2) &
+   DPLL_M2_MASK;
+   sys_clk_rate = clk_get_rate(clk_get(NULL, "osc_sys_ck"));
+
+   sys_clk_rate = sys_clk_rate / 100;
+
+   /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+   nr1 = (4 * (core_dpll_div_n + 1) * 2 * core_dpll_clkoutdiv_m2 *
+core_dpll_mul_m);
+   nr2 = 8 * (core_dpll_div_n + 1);
+   nr = nr1 + nr2;
+
+   dr = 2 * sys_clk_rate * core_dpll_mul_m * core_dpll_clkoutdiv_m2;
+
+   sdrc_clk_stab = nr / dr;
+
+   /* Adding 2us to sdrc clk stab */
+   sdrc_clk_stab = sdrc_clk_stab + 2;
+
+   delay_sram = delay_sram_val();
+
+   /* Calculate the number of MPU cycles to wait for SDRC to stabilize */
_mpurate = arm_fck_p->rate / CYCLES_PER_MHZ;
-   c = (_mpurate << SDRC_MPURATE_SCALE) >> SDRC_MPURATE_BASE_SHIFT;
-   c += 1;  /* for safety */
-   c *= SDRC_MPURATE_LOOPS;
-   c >>= SDRC_MPURATE_SCALE;
-   if (c == 0)
-   c = 1;
+
+   c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
 
pr_debug("clock: changing CORE DPLL rate from %lu to %lu\n", clk->rate,
 validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h 
index 313efc0..97afe34 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -22,4 +22,6 @@ extern const struct clkops clkops_omap3430es2_hsotgusb_wait;  
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
 extern const struct clkops omap3_clkops_noncore_dpll_ops;
 
+unsigned int delay_sram_val(void);
+
 #endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c 
b/arch/arm/mach-omap2/clock34xx_data.c
index 8728f1f..cf7384b 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 #include "clock.h"
 #include "c

RE: [PATCH] OMAP3: Serial: Improved sleep logic

2010-02-11 Thread Tero.Kristo
This patch can be ignored. The RX fifo clear logic did not really work for low 
C states (C1 / C2) and you would still get garbage. I'll send an updated patch 
where I have replaced the logic by an ignore timer for the first millisecond 
after clocks are enabled. Also, I forgot v2 out from this.

>-Original Message-
>From: linux-omap-ow...@vger.kernel.org 
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kristo 
>Tero (Nokia-D/Tampere)
>Sent: 10 February, 2010 18:29
>To: linux-omap@vger.kernel.org
>Subject: [PATCH] OMAP3: Serial: Improved sleep logic
>
>From: Tero Kristo 
>
>This patch contains following improvements:
>- Only RX interrupt will now kick the sleep prevent timer
>- TX fifo status is checked before disabling clocks, this will prevent
>  on-going transmission to be cut
>- Smartidle is disabled while entering idle if we have data in 
>the transmit
>  buffer because having this enabled would prevent wakeups from the TX
>  interrupt and this would cause pauses while sending large 
>blocks of data
>- Sleep prevent timer is changed to use ktime_get() instead of 
>a jiffy timer
>  as jiffy timers are not valid within idle loop (tick 
>scheduler is stopped)
>- RX and TX fifos are cleared when clocks are enabled, this 
>will purge the
>  first character from RX fifo, which is most likely garbage
>
>Signed-off-by: Tero Kristo 
>---
> arch/arm/mach-omap2/serial.c |   70 
>+++---
> 1 files changed, 45 insertions(+), 25 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/serial.c 
>b/arch/arm/mach-omap2/serial.c
>index 837b347..d7d96ba 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -23,12 +23,15 @@
> #include 
> #include 
> #include 
>+#include 
> 
> #include 
> #include 
> #include 
> #include 
> 
>+#include 
>+
> #include "prm.h"
> #include "pm.h"
> #include "prm-regbits-34xx.h"
>@@ -36,13 +39,13 @@
> #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV   0x52
> #define UART_OMAP_WER 0x17/* Wake-up enable register */
> 
>-#define DEFAULT_TIMEOUT (5 * HZ)
>+#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)
> 
> struct omap_uart_state {
>   int num;
>   int can_sleep;
>-  struct timer_list timer;
>-  u32 timeout;
>+  ktime_t expire_time;
>+  u64 timeout;
> 
>   void __iomem *wk_st;
>   void __iomem *wk_en;
>@@ -231,6 +234,9 @@ static inline void 
>omap_uart_enable_clocks(struct omap_uart_state *uart)
>   clk_enable(uart->fck);
>   uart->clocked = 1;
>   omap_uart_restore_context(uart);
>+
>+  /* Clear RX and TX fifos, as they contain garbage at 
>this point */
>+  serial_write_reg(uart->p, UART_FCR, 0xa7);
> }
> 
> #ifdef CONFIG_PM
>@@ -302,9 +308,7 @@ static void omap_uart_block_sleep(struct 
>omap_uart_state *uart)
>   omap_uart_smart_idle_enable(uart, 0);
>   uart->can_sleep = 0;
>   if (uart->timeout)
>-  mod_timer(&uart->timer, jiffies + uart->timeout);
>-  else
>-  del_timer(&uart->timer);
>+  uart->expire_time = ktime_add_ns(ktime_get(), 
>uart->timeout);
> }
> 
> static void omap_uart_allow_sleep(struct omap_uart_state *uart)
>@@ -317,25 +321,28 @@ static void omap_uart_allow_sleep(struct 
>omap_uart_state *uart)
>   if (!uart->clocked)
>   return;
> 
>-  omap_uart_smart_idle_enable(uart, 1);
>+  if (serial_read_reg(uart->p, UART_LSR) & UART_LSR_TEMT)
>+  omap_uart_smart_idle_enable(uart, 1);
>   uart->can_sleep = 1;
>-  del_timer(&uart->timer);
>-}
>-
>-static void omap_uart_idle_timer(unsigned long data)
>-{
>-  struct omap_uart_state *uart = (struct omap_uart_state *)data;
>-
>-  omap_uart_allow_sleep(uart);
> }
> 
> void omap_uart_prepare_idle(int num)
> {
>   struct omap_uart_state *uart;
>+  ktime_t t;
> 
>   list_for_each_entry(uart, &uart_list, node) {
>+  if (num == uart->num && !uart->can_sleep) {
>+  t = ktime_get();
>+  if (t.tv64 > uart->expire_time.tv64)
>+  uart->can_sleep = 1;
>+  }
>   if (num == uart->num && uart->can_sleep) {
>-  omap_uart_disable_clocks(uart);
>+  if (serial_read_reg(uart->p, UART_LSR) &
>+  UART_LSR_TEMT)
>+  omap_uart_disable_clocks(uart);
>+  else
>+  omap_uart_smart_idle_enable(uart, 0);
>   return;
>   }
>   }
>@@ -360,6 +367,7 @@ void omap_uart_resume_idle(int num)
>   /* Check for normal UART wakeup */
>   if (__raw_readl(uart->wk_st) & uart->wk_mask)
>   omap_uart_block_sleep(uart);
>+
>   return;
>   }
>   }
>@@ -407,8 +415,14 @@ int omap_uart_can_sleep(void)
> static irqreturn_t omap_uart_interrupt(int irq, void *dev_i

Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards

2010-02-11 Thread Mike Rapoport
David Vrabel wrote:
> Mike Rapoport wrote:
>> Hi David,
>>
>> David Vrabel wrote:
>>> These patches add support for SDIO cards to the omap_hsmmc driver.  Less
>>> restrictions on the sizes of transfers, power management changes to 
>>> prevent SDIO cards from being turned off and losing all state, and card
>>> interrupts.
>>>
>>> I've been unable to test these exact patches as I only have an N900 for 
>>> testing and the N900 support in mainline is incomplete.
>> I've tried your patches on CM-T35 that has 8686 SDIO and the result was
>> absence of MMC/SDIO devices at all :( Morover, kmmcd hangs:
>>
>> [  399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds.
>> [...]
>> [  399.485290] [] (mmc_wait_for_cmd+0x64/0x74) from
>> [] (mmc_go_idle+0x60/0xac)
> 
> I suspect interrupts aren't enabled correctly as this command does not
> complete.  Try reverting this hunk.

I did. No changes...

I've started to apply the patches one by one and after the first patch
is applied, the SD card works Ok, but libertas fails to initialize with
the following messages:

> modprobe libertas_sdio
[   82.233489] lib80211: common routines for IEEE802.11 drivers
[   82.833251] cfg80211: Calling CRDA to update world regulatory domain
[   83.327911] libertas_sdio: Libertas SDIO driver
[   83.332489] libertas_sdio: Copyright Pierre Ossman
[   83.348510] libertas_sdio mmc1:0001:1: firmware: requesting
sd8686_helper.bin
[   83.497619] libertas_sdio mmc1:0001:1: firmware: requesting sd8686.bin
[   83.679229] DMA synchronization event drop occurred with device 47

And then modprobe hangs:

[  258.700561] INFO: task modprobe:1191 blocked for more than 120
seconds.
[  258.707336] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  258.715270] modprobe  D c027f794 0  1191   1182 0x0003
[  258.721588] [] (schedule+0x274/0x2ac) from []
(schedule_timeout+0x18/0x17c)
[  258.730377] [] (schedule_timeout+0x18/0x17c) from
[] (wait_for_common+0xc0/0x14c)
[  258.739746] [] (wait_for_common+0xc0/0x14c) from
[] (mmc_wait_for_req+0x1f4/0x214)
[  258.749145] [] (mmc_wait_for_req+0x1f4/0x214) from
[] (mmc_io_rw_extended+0x188/0x1f0)
[  258.758911] [] (mmc_io_rw_extended+0x188/0x1f0) from
[] (sdio_io_rw_ext_helper+0xc4/0x184)
[  258.769012] [] (sdio_io_rw_ext_helper+0xc4/0x184) from
[] (sdio_writesb+0x18/0x1c)
[  258.778442] [] (sdio_writesb+0x18/0x1c) from []
(if_sdio_probe+0x63c/0x938 [libertas_sdio])
[  258.788665] [] (if_sdio_probe+0x63c/0x938 [libertas_sdio])
from [] (sdio_bus_probe+0x5c/0x68)
[  258.799041] [] (sdio_bus_probe+0x5c/0x68) from []
(driver_probe_device+0xa0/0x14c)
[  258.808441] [] (driver_probe_device+0xa0/0x14c) from
[] (__driver_attach+0x60/0x84)
[  258.817932] [] (__driver_attach+0x60/0x84) from
[] (bus_for_each_dev+0x44/0x78)
[  258.827087] [] (bus_for_each_dev+0x44/0x78) from
[] (bus_add_driver+0x9c/0x224)
[  258.836212] [] (bus_add_driver+0x9c/0x224) from
[] (driver_register+0xa8/0x130)
[  258.845367] [] (driver_register+0xa8/0x130) from
[] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[  258.856292] [] (if_sdio_init_module+0x1c/0x3c
[libertas_sdio]) from [] (do_one_initcall+0x54/0x190)
[  258.867187] [] (do_one_initcall+0x54/0x190) from
[] (sys_init_module+0xb8/0x1e4)
[  258.876403] [] (sys_init_module+0xb8/0x1e4) from
[] (ret_fast_syscall+0x0/0x2c)


> @@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
> *host, struct mmc_command *cmd,
> mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
> host->cmd = cmd;
> 
> -   /*
> -* Clear status bits and enable interrupts
> -*/
> -   OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> -   OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
> -
> if (host->use_dma)
> OMAP_HSMMC_WRITE(host->base, IE,
>  INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));
> 
> David


-- 
Sincerely yours,
Mike.

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


RE: [PATCH 1/2 V2] OMAP: DSS: Add display board file for zoom boards

2010-02-11 Thread G, Manjunath Kondaiah



> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Thursday, February 11, 2010 3:33 PM
> To: Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org; Hiremath, Vaibhav; Grazvydas Ignotas
> Subject: [PATCH 1/2 V2] OMAP: DSS: Add display board file for 
> zoom boards
> 
> From: Kishore Y 
> 
> board-zoom-display.c added as a common file for display fucntionality
> on boards zoom2, zoom3 and 3630sdp
> 
> Signed-off-by: Mukund Mittal 
> Signed-off-by: Kishore Y 
> ---
>  arch/arm/mach-omap2/Makefile  |3 +
>  arch/arm/mach-omap2/board-zoom-display.c  |  188 
> +
>  arch/arm/mach-omap2/board-zoom-peripherals.c  |   36 +
>  arch/arm/mach-omap2/include/mach/board-zoom.h |3 +
>  4 files changed, 230 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
> 
> diff --git a/arch/arm/mach-omap2/Makefile 
> b/arch/arm/mach-omap2/Makefile
> index b32678b..3dbe694 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -91,14 +91,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) 
> += board-rx51.o \
>  board-rx51-peripherals.o \
>  mmc-twl4030.o
>  obj-$(CONFIG_MACH_OMAP_ZOOM2)+= board-zoom2.o \
> +board-zoom-display.o \
>  board-zoom-peripherals.o \
>  mmc-twl4030.o \
>  board-zoom-debugboard.o
>  obj-$(CONFIG_MACH_OMAP_ZOOM3)+= board-zoom3.o \
> +board-zoom-display.o \
>  board-zoom-peripherals.o \
>  mmc-twl4030.o \
>  board-zoom-debugboard.o
>  obj-$(CONFIG_MACH_OMAP_3630SDP)  += board-3630sdp.o \
> +board-zoom-display.o \
>  board-zoom-peripherals.o \
>  mmc-twl4030.o
>  obj-$(CONFIG_MACH_CM_T35)+= board-cm-t35.o \
> diff --git a/arch/arm/mach-omap2/board-zoom-display.c 
> b/arch/arm/mach-omap2/board-zoom-display.c
> new file mode 100644
> index 000..fcadfd4
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-zoom-display.c
> @@ -0,0 +1,188 @@
> +/*
> + * Copyright (C) 2009 Texas Instruments Inc.

2009?

> + *
> + * Modified from mach-omap2/board-zoom-peripherals.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 
> +
> +#define LCD_PANEL_ENABLE_GPIO(7 + 
> OMAP_MAX_GPIO_LINES)
> +#define LCD_PANEL_RESET_GPIO_PROD96
> +#define LCD_PANEL_RESET_GPIO_PILOT   55
> +#define LCD_PANEL_QVGA_GPIO  56
> +#define TV_PANEL_ENABLE_GPIO 95
> +
> +struct zoom_dss_board_info {
> + int gpio_flag;
> +};
> +
> +static void zoom_lcd_tv_panel_init(void)
> +{
> + int ret;
> + unsigned char lcd_panel_reset_gpio;
> +
> + if (omap_rev() > OMAP3430_REV_ES3_0) {
> + /* Production Zoom2 board:
> +  * GPIO-96 is the LCD_RESET_GPIO
> +  */
> + lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PROD;
> + } else {
> + /* Pilot Zoom2 board:
> +  * GPIO-55 is the LCD_RESET_GPIO
> +  */
> + lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PILOT;
> + }

How about: 

lcd_panel_reset_gpio = (omap_rev() > OMAP3430_REV_ES3_0) ? 
LCD_PANEL_RESET_GPIO_PROD :
LCD_PANEL_RESET_GPIO_PILOT;

> +
> + ret = gpio_request(lcd_panel_reset_gpio, "lcd reset");
> + if (ret) {
> + pr_err("Failed to get LCD reset GPIO.\n");

Something like:

   pr_err("Failed to request GPIO%d for LCD reset GPIO\n",
lcd_panel_reset_gpio);

Will be useful info for the user incase of failure.

> + return;
> + }
> + gpio_direction_output(lcd_panel_reset_gpio, 1);
> +
> + ret = gpio_request(LCD_PANEL_QVGA_GPIO, "lcd qvga");
> + if (ret) {
> + pr_err("Failed to get LCD_PANEL_QVGA_GPIO.\n");

-Ditto-

> + goto err0;
> + }
> + gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
> +
> + ret = gpio_request(TV_PANEL_ENABLE_GPIO, "tv panel");
> + if (ret) {
> + pr_err("Failed to get TV_PANEL_ENABLE_GPIO.\n");

-Ditto- 

> + goto err1;
> + }
> + gpio_direction_output(TV_PANEL_ENABLE_GPIO, 0);
> +
>

Re: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Mark Brown
On Thu, Feb 11, 2010 at 01:14:18PM +0200, Jarkko Nikula wrote:

> Yeah, after thinking twice, we don't have zillions of options for e.g.
> Intel HDA either. If we ever figure out some common OMAP+TWL4030
> driver, the defconfigs are anyway have to modify so it's better stay
> with the original patch:

> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025129.html

> Sorry about line noise, Thomas :-)

Thomas, please resend the patch CCing the relevant maintainers (ie,
myself and Liam) - you should always CC maintainers on patch
submissions.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards

2010-02-11 Thread David Vrabel
Mike Rapoport wrote:
> Hi David,
> 
> David Vrabel wrote:
>> These patches add support for SDIO cards to the omap_hsmmc driver.  Less
>> restrictions on the sizes of transfers, power management changes to 
>> prevent SDIO cards from being turned off and losing all state, and card
>> interrupts.
>>
>> I've been unable to test these exact patches as I only have an N900 for 
>> testing and the N900 support in mainline is incomplete.
> 
> I've tried your patches on CM-T35 that has 8686 SDIO and the result was
> absence of MMC/SDIO devices at all :( Morover, kmmcd hangs:
> 
> [  399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds.
> [...]
> [  399.485290] [] (mmc_wait_for_cmd+0x64/0x74) from
> [] (mmc_go_idle+0x60/0xac)

I suspect interrupts aren't enabled correctly as this command does not
complete.  Try reverting this hunk.

@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
host->cmd = cmd;

-   /*
-* Clear status bits and enable interrupts
-*/
-   OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
-   OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
-
if (host->use_dma)
OMAP_HSMMC_WRITE(host->base, IE,
 INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));

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


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


Re: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Jarkko Nikula
On Thu, 11 Feb 2010 10:49:48 +
Liam Girdwood  wrote:

> I do agree this makes good sense for boards that are very similar and
> have different audio options/config, but in this case the ASoC mach
> drivers are identical (atm). Imo it just makes more sense to keep the
> one Kconfig.
> 
Yeah, after thinking twice, we don't have zillions of options for e.g.
Intel HDA either. If we ever figure out some common OMAP+TWL4030
driver, the defconfigs are anyway have to modify so it's better stay
with the original patch:

http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025129.html

Sorry about line noise, Thomas :-)

-- 
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Liam Girdwood
On Thu, 2010-02-11 at 12:40 +0200, Jarkko Nikula wrote:
> On Thu, 11 Feb 2010 09:55:12 +
> Liam Girdwood  wrote:
> 
> > Since this shares the same mach driver as beagle you should share the
> > Kconfig option too (like the Overo).
> > 
> Heh, I had just an opposite view :-)
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025124.html
> 
> 

Heh, didn't see that. ;)

I do agree this makes good sense for boards that are very similar and
have different audio options/config, but in this case the ASoC mach
drivers are identical (atm). Imo it just makes more sense to keep the
one Kconfig.

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP3 migrating: partition / clock

2010-02-11 Thread Arno Steffen
2010/2/8 Paul Walmsley :
> On Mon, 8 Feb 2010, Arno Steffen wrote:
>
>> Thanks Paul for your help.
>>
>> Switch on the  "#define DEBUG" in this both files skip almost all
>> kernel boot messages before this warning and gives just this: !?!
>
> You probably need to enable CONFIG_DEBUG_LL to see all of the messages.
>
>>  Uncompressing Linux done, booting the kernel.
>> lock: associated clk usbtll_ick to clkdm core_l4_clkdm
>> Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz
>> [ cut here ]
>> WARNING: at arch/arm/mach-omap2/clock34xx.c:773
>> omap3_noncore_dpll_set_rate+0x1d4/0x308()
>> Modules linked in:
>> [] (unwind_backtrace+0x0/0xdc) from []
>> (warn_slowpath_common+0x48/0x60)
>> 
>>
>> I expected to get more messages, not less:
>> You are right, my board is running at 12 instead of 13MHz, but this
>> setting is (or should be) done in uboot.
>> I don't know what this new line withb the "lock" means.
>
> The leading "c" was apparently dropped.  You can recursively grep through
> the source tree to locate messages, if you are curious as to where they
> come from.
>
>> On my board there is no USB at all.
>
> If you're not using any of the DPLL5-connected devices (USB, USIM, etc.),
> what happens if you comment out the omap3_clk_lock_dpll5() call in
> clock34xx.c?  This is not a proper fix, of course, but it may help narrow
> down the problem.
> - Paul

Thanks Paul!

Sorry for bothering you again:
Although I set "#define DEBUG" in clock.c and clock34xx.c and checked
that kernel has been new compiled with "CONFIG_DEBUG_LL=y" the debub
messages are quite strange.

Uncompressing Linux. done, booting the kernel.
kout2_src_ck to clkdm core_clkdm
Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz
Reprogramming SDRC clock to 33200 Hz
GPMC revision 5.0
...

This strange behaviour is just happend if I do a "#define DEBUG" in clock.c.
Changing the debug setting in clock34xx.c has no effect at all ?!?

Anyhow there are good news too:
I removed the call of omap3_clk_lock_dpll5() and you are right - the
message disappers. How did you know that?
This call
clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST);
causes the first message, and thus I assume that dpll5_clk might be
wrong, which is get by this command:
dpll5_clk = clk_get(NULL, "dpll5_ck");

I could live with this workaround (remove the call), but have to be
sure, that clock is not powered (save energy).

Best regards
Arno
--
To unsubscribe from this list: send the line "unsubscribe 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: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Jarkko Nikula
On Thu, 11 Feb 2010 09:55:12 +
Liam Girdwood  wrote:

> Since this shares the same mach driver as beagle you should share the
> Kconfig option too (like the Overo).
> 
Heh, I had just an opposite view :-)

http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025124.html


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


Moving board patches from DSS2 to linux-omap

2010-02-11 Thread Tomi Valkeinen
Hi,

As discussed previously, board file changes in DSS2 tree cause conflicts
with linux-omap easily. There are currently three board file patches in
DSS2's for-next branch:

722a97e4594b2041bbf18d95a913ba6dfaca87f2 omap3: cm-t35: add DSS2 display support
7a56267e775e469c64521179ccc958c8bb661dbf OMAP: AM3517: Enable DSS2 for 
AM3517EVM board
40e4e67c6dabcb9897b6823cce2297d6c3e78bbd OMAP: Enable DSS2 for OMAP3EVM board

The problem here is of course that DSS2 tree may contain unmerged panel
drivers, and those board file changes try to use these new panel
drivers.

Now, I don't think there's a perfect solution for this, but I think a
working solution would be to put all board file changes to linux-omap
tree (with the exception of some rare changes that don't compile without
new DSS2 patches), but leave the kernel config unchanged.

This way the board file contains references to new panel drivers, but as
DSS2 nor the panel drivers are enabled in the Kconfig, the board file
code is not used and everything should work as before.

Then either I can have Kconfig patches in my tree, which are less likely
to conflict, or the Kconfig changes can be done after both linux-omap
and dss2 patches have been merged.

How does this sound?

 Tomi

Ps. I haven't actually tried those board file patches on top of
linux-omap, but I don't see anything there that would cause compilation
to fail.


--
To unsubscribe from this list: send the line "unsubscribe 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 V2] OMAP: DSS: Enable display on ZOOM2/3 & 3630SDP

2010-02-11 Thread Y, Kishore
From: Kishore Y 

Enable dss and framebuffer on zoom2, zoom3 and 3630sdp boards.

Signed-off-by: Mukund Mittal 
Signed-off-by: Kishore Y 
---
 arch/arm/configs/omap_3630sdp_defconfig |   60 ++-
 arch/arm/configs/omap_zoom2_defconfig   |   60 ++-
 arch/arm/configs/omap_zoom3_defconfig   |   60 ++-
 arch/arm/mach-omap2/board-3630sdp.c |1 +
 arch/arm/mach-omap2/board-zoom2.c   |1 +
 arch/arm/mach-omap2/board-zoom3.c   |1 +
 6 files changed, 180 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/omap_3630sdp_defconfig 
b/arch/arm/configs/omap_3630sdp_defconfig
index d25c3d4..df37108 100644
--- a/arch/arm/configs/omap_3630sdp_defconfig
+++ b/arch/arm/configs/omap_3630sdp_defconfig
@@ -886,7 +886,57 @@ CONFIG_REGULATOR_TWL4030=y
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_UVESA is not set
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=4
+# CONFIG_OMAP2_DSS_DEBUG_SUPPORT is not set
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4
+CONFIG_FB_OMAP2=y
+# CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=1
+
+#
+# OMAP2/3 Display Device Drivers
+#
+# CONFIG_PANEL_GENERIC is not set
+# CONFIG_PANEL_SHARP_LS037V7DW01 is not set
+CONFIG_PANEL_NEC_NL8048HL11_01B=y
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
@@ -899,6 +949,14 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FONTS is not set
+CONFIG_LOGO=y
+CONFIG_LOGO_LINUX_MONO=y
+CONFIG_LOGO_LINUX_VGA16=y
+CONFIG_LOGO_LINUX_CLUT224=y
 CONFIG_SOUND=y
 # CONFIG_SOUND_OSS_CORE is not set
 CONFIG_SND=y
diff --git a/arch/arm/configs/omap_zoom2_defconfig 
b/arch/arm/configs/omap_zoom2_defconfig
index a82e813..66bde4d 100644
--- a/arch/arm/configs/omap_zoom2_defconfig
+++ b/arch/arm/configs/omap_zoom2_defconfig
@@ -859,7 +859,57 @@ CONFIG_DAB=y
 #
 # CONFIG_VGASTATE is not set
 CONFIG_VIDEO_OUTPUT_CONTROL=m
-# CONFIG_FB is not set
+CONFIG_FB=y
+# CONFIG_FIRMWARE_EDID is not set
+# CONFIG_FB_DDC is not set
+# CONFIG_FB_BOOT_VESA_SUPPORT is not set
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
+# CONFIG_FB_SYS_FILLRECT is not set
+# CONFIG_FB_SYS_COPYAREA is not set
+# CONFIG_FB_SYS_IMAGEBLIT is not set
+# CONFIG_FB_FOREIGN_ENDIAN is not set
+# CONFIG_FB_SYS_FOPS is not set
+# CONFIG_FB_SVGALIB is not set
+# CONFIG_FB_MACMODES is not set
+# CONFIG_FB_BACKLIGHT is not set
+# CONFIG_FB_MODE_HELPERS is not set
+# CONFIG_FB_TILEBLITTING is not set
+
+#
+# Frame buffer hardware drivers
+#
+# CONFIG_FB_UVESA is not set
+# CONFIG_FB_S1D13XXX is not set
+# CONFIG_FB_VIRTUAL is not set
+# CONFIG_FB_METRONOME is not set
+# CONFIG_FB_MB862XX is not set
+# CONFIG_FB_BROADSHEET is not set
+# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set
+CONFIG_OMAP2_VRAM=y
+CONFIG_OMAP2_VRFB=y
+CONFIG_OMAP2_DSS=y
+CONFIG_OMAP2_VRAM_SIZE=4
+# CONFIG_OMAP2_DSS_DEBUG_SUPPORT is not set
+# CONFIG_OMAP2_DSS_RFBI is not set
+CONFIG_OMAP2_DSS_VENC=y
+# CONFIG_OMAP2_DSS_SDI is not set
+# CONFIG_OMAP2_DSS_DSI is not set
+# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set
+CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4
+CONFIG_FB_OMAP2=y
+# CONFIG_FB_OMAP2_DEBUG_SUPPORT is not set
+# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set
+CONFIG_FB_OMAP2_NUM_FBS=1
+
+#
+# OMAP2/3 Display Device Drivers
+#
+# CONFIG_PANEL_GENERIC is not set
+# CONFIG_PANEL_SHARP_LS037V7DW01 is not set
+CONFIG_PANEL_NEC_NL8048HL11_01B=y
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
 
 #
@@ -872,6 +922,14 @@ CONFIG_VIDEO_OUTPUT_CONTROL=m
 #
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_DUMMY_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+# CONFIG_FRAM

[PATCH 1/2 V2] OMAP: DSS: Add display board file for zoom boards

2010-02-11 Thread Y, Kishore
From: Kishore Y 

board-zoom-display.c added as a common file for display fucntionality
on boards zoom2, zoom3 and 3630sdp

Signed-off-by: Mukund Mittal 
Signed-off-by: Kishore Y 
---
 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/board-zoom-display.c  |  188 +
 arch/arm/mach-omap2/board-zoom-peripherals.c  |   36 +
 arch/arm/mach-omap2/include/mach/board-zoom.h |3 +
 4 files changed, 230 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-display.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..3dbe694 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -91,14 +91,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51)   += board-rx51.o 
\
   board-rx51-peripherals.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom2.o \
+  board-zoom-display.o \
   board-zoom-peripherals.o \
   mmc-twl4030.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_ZOOM3)  += board-zoom3.o \
+  board-zoom-display.o \
   board-zoom-peripherals.o \
   mmc-twl4030.o \
   board-zoom-debugboard.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
+  board-zoom-display.o \
   board-zoom-peripherals.o \
   mmc-twl4030.o
 obj-$(CONFIG_MACH_CM_T35)  += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-display.c 
b/arch/arm/mach-omap2/board-zoom-display.c
new file mode 100644
index 000..fcadfd4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-zoom-peripherals.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 
+
+#define LCD_PANEL_ENABLE_GPIO  (7 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_RESET_GPIO_PROD  96
+#define LCD_PANEL_RESET_GPIO_PILOT 55
+#define LCD_PANEL_QVGA_GPIO56
+#define TV_PANEL_ENABLE_GPIO   95
+
+struct zoom_dss_board_info {
+   int gpio_flag;
+};
+
+static void zoom_lcd_tv_panel_init(void)
+{
+   int ret;
+   unsigned char lcd_panel_reset_gpio;
+
+   if (omap_rev() > OMAP3430_REV_ES3_0) {
+   /* Production Zoom2 board:
+* GPIO-96 is the LCD_RESET_GPIO
+*/
+   lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PROD;
+   } else {
+   /* Pilot Zoom2 board:
+* GPIO-55 is the LCD_RESET_GPIO
+*/
+   lcd_panel_reset_gpio = LCD_PANEL_RESET_GPIO_PILOT;
+   }
+
+   ret = gpio_request(lcd_panel_reset_gpio, "lcd reset");
+   if (ret) {
+   pr_err("Failed to get LCD reset GPIO.\n");
+   return;
+   }
+   gpio_direction_output(lcd_panel_reset_gpio, 1);
+
+   ret = gpio_request(LCD_PANEL_QVGA_GPIO, "lcd qvga");
+   if (ret) {
+   pr_err("Failed to get LCD_PANEL_QVGA_GPIO.\n");
+   goto err0;
+   }
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
+
+   ret = gpio_request(TV_PANEL_ENABLE_GPIO, "tv panel");
+   if (ret) {
+   pr_err("Failed to get TV_PANEL_ENABLE_GPIO.\n");
+   goto err1;
+   }
+   gpio_direction_output(TV_PANEL_ENABLE_GPIO, 0);
+
+   return;
+
+err1:
+   gpio_free(LCD_PANEL_QVGA_GPIO);
+err0:
+   gpio_free(lcd_panel_reset_gpio);
+}
+
+static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   int ret;
+   struct zoom_dss_board_info *pdata;
+
+   pdata = dssdev->dev.platform_data;
+   if (pdata->gpio_flag == 0) {
+   ret = gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd enable");
+   if (ret) {
+   pr_err("Failed to get LCD_PANEL_ENABLE_GPIO.\n");
+   return ret;
+   }
+   gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+   pdata->gpio_flag = 1;
+   } else {
+   gpio_set_value(LCD_PANEL_ENABLE_GPIO, 1);
+   }
+
+   return 0;
+}
+
+static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_set_value(LCD_PANEL_ENABLE_GPIO, 0);
+}
+
+static int zoom_

[PATCH 0/2] Enable DSS on zoom2/3 and 3630 sdp boards

2010-02-11 Thread Y, Kishore
From: Kishore Y 

This patch series enables DSS and FB in zoom2, zoom3 and 3630sdp.

Changes from version 1:
  - removed regulator framework calls
  - removed compiler warnings

OMAP: DSS: Enable display on ZOOM2/3 & 3630SDP
- Included display in boards and enabled in defconfig
OMAP: DSS: Add display board file for zoom boards
- Display board file added common for all boards

 arch/arm/configs/omap_3630sdp_defconfig   |   60 -
 arch/arm/configs/omap_zoom2_defconfig |   60 -
 arch/arm/configs/omap_zoom3_defconfig |   60 -
 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/board-3630sdp.c   |1 +
 arch/arm/mach-omap2/board-zoom-display.c  |  188 +
 arch/arm/mach-omap2/board-zoom-peripherals.c  |   36 +
 arch/arm/mach-omap2/board-zoom2.c |1 +
 arch/arm/mach-omap2/board-zoom3.c |1 +
 arch/arm/mach-omap2/include/mach/board-zoom.h |3 +
 drivers/video/omap2/dss/dpi.c |2 +-
 11 files changed, 411 insertions(+), 4 deletions(-)

Tested on top of LO kernel on dss2 brnach
commit id: 33b601093c6d5f5b18abcbd2de736d300d837f91
OMAP: DSS2: DSI: remove dsi_vc_print_status()

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


Re: [alsa-devel] [PATCHv3 3/4] Add ASoC support for DevKit8000

2010-02-11 Thread Liam Girdwood
On Wed, 2010-02-10 at 20:23 +0100, Thomas Weber wrote:
> This patch expands the omap3beagle sound soc for the
> beagle board clone Devkit8000.
> 
> Change log
> V2
>   Expand omap3beagle sound soc for DevKit8000 support.
> V3 
>   Separate Kconfig for Devkit8000.
> 
> Signed-off-by: Thomas Weber 
> ---
>  sound/soc/omap/Kconfig   |8 
>  sound/soc/omap/Makefile  |1 +
>  sound/soc/omap/omap3beagle.c |6 +++---
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
> index 61952aa..8520b75 100644
> --- a/sound/soc/omap/Kconfig
> +++ b/sound/soc/omap/Kconfig
> @@ -101,6 +101,14 @@ config SND_OMAP_SOC_OMAP3_BEAGLE
>   help
> Say Y if you want to add support for SoC audio on the Beagleboard.
>  
> +config SND_OMAP_SOC_DEVKIT8000
> + tristate "SoC Audio support for DevKit8000"
> + depends on TWL4030_CORE && SND_OMAP_SOC && MACH_DEVKIT8000
> + select SND_OMAP_SOC_MCBSP
> + select SND_SOC_TWL4030
> + help
> +   Say Y if you want to add support for SoC audio on the DevKit8000
> +

Since this shares the same mach driver as beagle you should share the
Kconfig option too (like the Overo).

Thanks

Liam

-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

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


RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel

2010-02-11 Thread Hiremath, Vaibhav

> -Original Message-
> From: Y, Kishore
> Sent: Thursday, February 11, 2010 2:23 PM
> To: Hiremath, Vaibhav; Tomi Valkeinen
> Cc: Aguirre, Sergio; Christensen, Mikkel; linux-omap@vger.kernel.org
> Subject: RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display
> panel
> 
> > -Original Message-
> > From: Hiremath, Vaibhav
> > Sent: Thursday, February 11, 2010 2:14 PM
> > To: Y, Kishore; Tomi Valkeinen
> > Cc: Aguirre, Sergio; Christensen, Mikkel; linux-
> o...@vger.kernel.org
> > Subject: RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display
> panel
> >
> > > -Original Message-
> > > From: Y, Kishore
> > > Sent: Thursday, February 11, 2010 1:51 PM
> > > To: Tomi Valkeinen
> > > Cc: Hiremath, Vaibhav; Aguirre, Sergio; Christensen, Mikkel;
> linux-
> > > o...@vger.kernel.org
> > > Subject: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display
> panel
> > >
> > > From: Erik Gilling 
> > >
> > > NEC WVGA LCD NL8048HL11-01B support has been added.
> > >
> > > Signed-off-by: Mukund Mittal 
> > > Signed-off-by: Kishore Y 
> > > ---
> > > Changes from version 1:
> > >   incorporated cosmetic comments.
> > >
> > >  drivers/video/omap2/displays/Kconfig   |6 +
> > >  drivers/video/omap2/displays/Makefile  |1 +
> > >  .../omap2/displays/panel-nec-NL8048HL11-01B.c  |  284
> > > 
> > >  3 files changed, 291 insertions(+), 0 deletions(-)
> > >  create mode 100644 drivers/video/omap2/displays/panel-nec-
> > > NL8048HL11-01B.c
> > >
> > > diff --git a/drivers/video/omap2/displays/Kconfig
> > > b/drivers/video/omap2/displays/Kconfig
> > > index dfb57ee..010ed48 100644
> > > --- a/drivers/video/omap2/displays/Kconfig
> > > +++ b/drivers/video/omap2/displays/Kconfig
> > > @@ -37,4 +37,10 @@ config PANEL_TPO_TD043MTEA1
> > >  help
> > >LCD Panel used in OMAP3 Pandora
> > >
> > > +config PANEL_NEC_NL8048HL11_01B
> > > +tristate "NEC NL8048HL11-01B Panel"
> > > +depends on OMAP2_DSS
> > > +help
> > > +  LCD Panel from NEC.
> > > +
> > >  endmenu
> > > diff --git a/drivers/video/omap2/displays/Makefile
> > > b/drivers/video/omap2/displays/Makefile
> > > index e2bb321..9aace29 100644
> > > --- a/drivers/video/omap2/displays/Makefile
> > > +++ b/drivers/video/omap2/displays/Makefile
> > > @@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-
> > > sharp-lq043t1dg01.o
> > >  obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
> > >  obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
> > >  obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> > > +obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-NL8048HL11-
> > > 01B.o
> > [Hiremath, Vaibhav] I think you have submitted patch from your
> working
> > directory and not linux-master. If I understand correctly we do
> not have
> > these panels supported in linux-omap. Please rebase it with linux-
> omap and
> > re-send.
> 
> I actually tested thin on dss2 branch of LO and not master branch. I
> would rebase it to master and send the next version taking in other
> comments.
> 
[Hiremath, Vaibhav] In that case you are following right method. No need to 
rebase it to master, since Tomi gives pull request.


> >
> > One small change mentioned below -
> >
> > > diff --git a/drivers/video/omap2/displays/panel-nec-NL8048HL11-
> 01B.c
> > > b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> > > new file mode 100644
> > > index 000..4d7e8ab
> > > --- /dev/null
> > > +++ b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> > > @@ -0,0 +1,284 @@
> > > +/*
> > > + * NEC panel support
> > > + *
> > [Hiremath, Vaibhav] copy-right is missing.
> I will add it.
> >
> > > + * 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 
> > [Hiremath, Vaibhav] you may want to add extra blank line here
> > > +#include 
> >
> > [Hiremath, Vaibhav] ditto.
> >
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define LCD_XRES 800
> > > +#define LCD_YRES 480
> > > +/* NEC PIX Clock Ratings
> > > + * MINi:21.8MHz TYP:23.8MHz MAX:25.7MHz
> > > + */
> > > +#define LCD_PIXEL_CLOCK  23800
> > > +
> > > +/* NEC NL8048HL11-01B  Manual
> > > + * defines HFB, HSW, HBP, VFP, VSW, VBP as 

RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel

2010-02-11 Thread Y, Kishore
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Thursday, February 11, 2010 2:14 PM
> To: Y, Kishore; Tomi Valkeinen
> Cc: Aguirre, Sergio; Christensen, Mikkel; linux-omap@vger.kernel.org
> Subject: RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel
> 
> > -Original Message-
> > From: Y, Kishore
> > Sent: Thursday, February 11, 2010 1:51 PM
> > To: Tomi Valkeinen
> > Cc: Hiremath, Vaibhav; Aguirre, Sergio; Christensen, Mikkel; linux-
> > o...@vger.kernel.org
> > Subject: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel
> >
> > From: Erik Gilling 
> >
> > NEC WVGA LCD NL8048HL11-01B support has been added.
> >
> > Signed-off-by: Mukund Mittal 
> > Signed-off-by: Kishore Y 
> > ---
> > Changes from version 1:
> > incorporated cosmetic comments.
> >
> >  drivers/video/omap2/displays/Kconfig   |6 +
> >  drivers/video/omap2/displays/Makefile  |1 +
> >  .../omap2/displays/panel-nec-NL8048HL11-01B.c  |  284
> > 
> >  3 files changed, 291 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/video/omap2/displays/panel-nec-
> > NL8048HL11-01B.c
> >
> > diff --git a/drivers/video/omap2/displays/Kconfig
> > b/drivers/video/omap2/displays/Kconfig
> > index dfb57ee..010ed48 100644
> > --- a/drivers/video/omap2/displays/Kconfig
> > +++ b/drivers/video/omap2/displays/Kconfig
> > @@ -37,4 +37,10 @@ config PANEL_TPO_TD043MTEA1
> >  help
> >LCD Panel used in OMAP3 Pandora
> >
> > +config PANEL_NEC_NL8048HL11_01B
> > +tristate "NEC NL8048HL11-01B Panel"
> > +depends on OMAP2_DSS
> > +help
> > +  LCD Panel from NEC.
> > +
> >  endmenu
> > diff --git a/drivers/video/omap2/displays/Makefile
> > b/drivers/video/omap2/displays/Makefile
> > index e2bb321..9aace29 100644
> > --- a/drivers/video/omap2/displays/Makefile
> > +++ b/drivers/video/omap2/displays/Makefile
> > @@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-
> > sharp-lq043t1dg01.o
> >  obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
> >  obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
> >  obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> > +obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-NL8048HL11-
> > 01B.o
> [Hiremath, Vaibhav] I think you have submitted patch from your working
> directory and not linux-master. If I understand correctly we do not have
> these panels supported in linux-omap. Please rebase it with linux-omap and
> re-send.

I actually tested thin on dss2 branch of LO and not master branch. I would 
rebase it to master and send the next version taking in other comments.

> 
> One small change mentioned below -
> 
> > diff --git a/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> > b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> > new file mode 100644
> > index 000..4d7e8ab
> > --- /dev/null
> > +++ b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> > @@ -0,0 +1,284 @@
> > +/*
> > + * NEC panel support
> > + *
> [Hiremath, Vaibhav] copy-right is missing.
I will add it.
> 
> > + * 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 
> [Hiremath, Vaibhav] you may want to add extra blank line here
> > +#include 
> 
> [Hiremath, Vaibhav] ditto.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define LCD_XRES   800
> > +#define LCD_YRES   480
> > +/* NEC PIX Clock Ratings
> > + * MINi:21.8MHz TYP:23.8MHz MAX:25.7MHz
> > + */
> > +#define LCD_PIXEL_CLOCK23800
> > +
> > +/* NEC NL8048HL11-01B  Manual
> > + * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
> > + */
> > +
> > +static struct omap_video_timings nec_8048_panel_timings = {
> > +   /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
> > +   .x_res  = LCD_XRES,
> > +   .y_res  = LCD_YRES,
> > +   .pixel_clock= LCD_PIXEL_CLOCK,
> > +   .hfp= 6,
> > +   .hsw= 1,
> > +   .hbp= 4,
> > +   .vfp= 3,
> > +   .vsw= 1,
> > +   .vbp= 4,
> > +};
> > +
> > +static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
> > +{
> > +   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> > +   OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
> > +

RE: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel

2010-02-11 Thread Hiremath, Vaibhav
> -Original Message-
> From: Y, Kishore
> Sent: Thursday, February 11, 2010 1:51 PM
> To: Tomi Valkeinen
> Cc: Hiremath, Vaibhav; Aguirre, Sergio; Christensen, Mikkel; linux-
> o...@vger.kernel.org
> Subject: [PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel
> 
> From: Erik Gilling 
> 
> NEC WVGA LCD NL8048HL11-01B support has been added.
> 
> Signed-off-by: Mukund Mittal 
> Signed-off-by: Kishore Y 
> ---
> Changes from version 1:
>   incorporated cosmetic comments.
> 
>  drivers/video/omap2/displays/Kconfig   |6 +
>  drivers/video/omap2/displays/Makefile  |1 +
>  .../omap2/displays/panel-nec-NL8048HL11-01B.c  |  284
> 
>  3 files changed, 291 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/video/omap2/displays/panel-nec-
> NL8048HL11-01B.c
> 
> diff --git a/drivers/video/omap2/displays/Kconfig
> b/drivers/video/omap2/displays/Kconfig
> index dfb57ee..010ed48 100644
> --- a/drivers/video/omap2/displays/Kconfig
> +++ b/drivers/video/omap2/displays/Kconfig
> @@ -37,4 +37,10 @@ config PANEL_TPO_TD043MTEA1
>  help
>LCD Panel used in OMAP3 Pandora
> 
> +config PANEL_NEC_NL8048HL11_01B
> +tristate "NEC NL8048HL11-01B Panel"
> +depends on OMAP2_DSS
> +help
> +  LCD Panel from NEC.
> +
>  endmenu
> diff --git a/drivers/video/omap2/displays/Makefile
> b/drivers/video/omap2/displays/Makefile
> index e2bb321..9aace29 100644
> --- a/drivers/video/omap2/displays/Makefile
> +++ b/drivers/video/omap2/displays/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-
> sharp-lq043t1dg01.o
>  obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
>  obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
>  obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> +obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-NL8048HL11-
> 01B.o
[Hiremath, Vaibhav] I think you have submitted patch from your working 
directory and not linux-master. If I understand correctly we do not have these 
panels supported in linux-omap. Please rebase it with linux-omap and re-send.

One small change mentioned below -

> diff --git a/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> new file mode 100644
> index 000..4d7e8ab
> --- /dev/null
> +++ b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
> @@ -0,0 +1,284 @@
> +/*
> + * NEC panel support
> + *
[Hiremath, Vaibhav] copy-right is missing.

> + * 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 
[Hiremath, Vaibhav] you may want to add extra blank line here
> +#include 

[Hiremath, Vaibhav] ditto.

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define LCD_XRES 800
> +#define LCD_YRES 480
> +/* NEC PIX Clock Ratings
> + * MINi:21.8MHz TYP:23.8MHz MAX:25.7MHz
> + */
> +#define LCD_PIXEL_CLOCK  23800
> +
> +/* NEC NL8048HL11-01B  Manual
> + * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
> + */
> +
> +static struct omap_video_timings nec_8048_panel_timings = {
> + /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
> + .x_res  = LCD_XRES,
> + .y_res  = LCD_YRES,
> + .pixel_clock= LCD_PIXEL_CLOCK,
> + .hfp= 6,
> + .hsw= 1,
> + .hbp= 4,
> + .vfp= 3,
> + .vsw= 1,
> + .vbp= 4,
> +};
> +
> +static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
> +{
> + dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> + OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
> + OMAP_DSS_LCD_ONOFF;
> + dssdev->panel.timings = nec_8048_panel_timings;
> + dssdev->panel.recommended_bpp = 16;
> +
> + return 0;
> +}
> +
> +static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
> +{
> +}
> +
> +static int nec_8048_panel_enable(struct omap_dss_device *dssdev)
> +{
> + int r = 0;
> +
> + /* Delay recommended by panel DATASHEET */
> + mdelay(4);
> + if (dssdev->platform_enable)
> + r = dssdev->platform_enable(dssdev);
> +
> + return r;
> +}
> +
> +static void nec_8048_panel_disable(struct omap_dss_device *dssdev)
> +{
> + if (dssdev->platform_disable)
> + 

Re: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards

2010-02-11 Thread Mike Rapoport
Hi David,

David Vrabel wrote:
> These patches add support for SDIO cards to the omap_hsmmc driver.  Less
> restrictions on the sizes of transfers, power management changes to 
> prevent SDIO cards from being turned off and losing all state, and card
> interrupts.
> 
> I've been unable to test these exact patches as I only have an N900 for 
> testing and the N900 support in mainline is incomplete.

I've tried your patches on CM-T35 that has 8686 SDIO and the result was
absence of MMC/SDIO devices at all :( Morover, kmmcd hangs:

[  399.427764] INFO: task kmmcd:149 blocked for more than 120 seconds.

[  399.434082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.

[  399.442016] kmmcd D c027f804 0   149  2 0x

[  399.448333] [] (schedule+0x274/0x2ac) from []
(schedule_timeout+0x18/0x17c)

[  399.457122] [] (schedule_timeout+0x18/0x17c) from
[] (wait_for_common+0xc0/0x14c)

[  399.466461] [] (wait_for_common+0xc0/0x14c) from
[] (mmc_wait_for_req+0x1f4/0x214)

[  399.475860] [] (mmc_wait_for_req+0x1f4/0x214) from
[] (mmc_wait_for_cmd+0x64/0x74)

[  399.485290] [] (mmc_wait_for_cmd+0x64/0x74) from
[] (mmc_go_idle+0x60/0xac)

[  399.494079] [] (mmc_go_idle+0x60/0xac) from []
(mmc_rescan+0x150/0x208)

[  399.502532] [] (mmc_rescan+0x150/0x208) from []
(worker_thread+0xf0/0x168)

[  399.511260] [] (worker_thread+0xf0/0x168) from []
(kthread+0x7c/0x84)

[  399.519531] [] (kthread+0x7c/0x84) from []
(kernel_thread_exit+0x0/0x8)


I'll try to debug it more today and see what is going on wrong...

> David Vrabel (3):
>   mmc: omap_hsmmc: use packet sync'd DMA
>   mmc: omap_hsmmc: don't turn SDIO cards off when idle
>   mmc: omap_hsmmc: enable SDIO card interrupts
> 
>  drivers/mmc/host/omap_hsmmc.c |  123 
> ++---
>  1 files changed, 78 insertions(+), 45 deletions(-)
> 


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


[PATCH V2] OMAP: DSS: Add NEC NL8048HL11-01B display panel

2010-02-11 Thread Y, Kishore
From: Erik Gilling 

NEC WVGA LCD NL8048HL11-01B support has been added.

Signed-off-by: Mukund Mittal 
Signed-off-by: Kishore Y 
---
Changes from version 1:
incorporated cosmetic comments.

 drivers/video/omap2/displays/Kconfig   |6 +
 drivers/video/omap2/displays/Makefile  |1 +
 .../omap2/displays/panel-nec-NL8048HL11-01B.c  |  284 
 3 files changed, 291 insertions(+), 0 deletions(-)
 create mode 100644 drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index dfb57ee..010ed48 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -37,4 +37,10 @@ config PANEL_TPO_TD043MTEA1
 help
   LCD Panel used in OMAP3 Pandora
 
+config PANEL_NEC_NL8048HL11_01B
+tristate "NEC NL8048HL11-01B Panel"
+depends on OMAP2_DSS
+help
+  LCD Panel from NEC.
+
 endmenu
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index e2bb321..9aace29 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += 
panel-sharp-lq043t1dg01.o
 obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
 obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
 obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-NL8048HL11-01B.o
diff --git a/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c 
b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
new file mode 100644
index 000..4d7e8ab
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-NL8048HL11-01B.c
@@ -0,0 +1,284 @@
+/*
+ * NEC panel support
+ *
+ * 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 
+
+#define LCD_XRES   800
+#define LCD_YRES   480
+/* NEC PIX Clock Ratings
+ * MINi:21.8MHz TYP:23.8MHz MAX:25.7MHz
+ */
+#define LCD_PIXEL_CLOCK23800
+
+/* NEC NL8048HL11-01B  Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_8048_panel_timings = {
+   /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
+   .x_res  = LCD_XRES,
+   .y_res  = LCD_YRES,
+   .pixel_clock= LCD_PIXEL_CLOCK,
+   .hfp= 6,
+   .hsw= 1,
+   .hbp= 4,
+   .vfp= 3,
+   .vsw= 1,
+   .vbp= 4,
+};
+
+static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
+{
+   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+   OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
+   OMAP_DSS_LCD_ONOFF;
+   dssdev->panel.timings = nec_8048_panel_timings;
+   dssdev->panel.recommended_bpp = 16;
+
+   return 0;
+}
+
+static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_8048_panel_enable(struct omap_dss_device *dssdev)
+{
+   int r = 0;
+
+   /* Delay recommended by panel DATASHEET */
+   mdelay(4);
+   if (dssdev->platform_enable)
+   r = dssdev->platform_enable(dssdev);
+
+   return r;
+}
+
+static void nec_8048_panel_disable(struct omap_dss_device *dssdev)
+{
+   if (dssdev->platform_disable)
+   dssdev->platform_disable(dssdev);
+   /* Delay recommended by panel DATASHEET */
+   mdelay(4);
+}
+
+static int nec_8048_panel_suspend(struct omap_dss_device *dssdev)
+{
+   nec_8048_panel_disable(dssdev);
+   return 0;
+}
+
+static int nec_8048_panel_resume(struct omap_dss_device *dssdev)
+{
+   return nec_8048_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver nec_8048_driver = {
+   .probe  = nec_8048_panel_probe,
+   .remove = nec_8048_panel_remove,
+   .enable = nec_8048_panel_enable,
+   .disable= nec_8048_panel_disable,
+   .suspend= nec_8048_panel_suspend,
+   .resume = nec_8048_panel_resume,
+
+   .driver = {
+   .name   = "NEC_8048_panel",
+   .owner  = THIS_MODULE,
+   },
+};
+
+static int
+spi_send(struct spi_device *spi, unsigned char r

[PATCH 0/2-V2] Add support for I2C based devices to AM3517EVM

2010-02-11 Thread hvaibhav
From: Vaibhav Hiremath 

This series of patchset adds platform hook-up interface for I2C based
devices to AM3517 -
- Real Time Clock (S35390A)
- I2C GPIO Expander (TCA6416)

Changes from last submission (V1) -
- Dropped "Basic I2C support patch" patch, since it has
  already been merged.
- Removed TSC2004 support patch, since it will be merged to
  TSC2007 driver.


Vaibhav Hiremath (2):
  AM3517: Enable RTC driver support for AM3517EVM
  AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

 arch/arm/mach-omap2/board-am3517evm.c |   62 +++-
 1 files changed, 60 insertions(+), 2 deletions(-)

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


[PATCH 2/2-V2] AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

2010-02-11 Thread hvaibhav
From: Vaibhav Hiremath 

Add platform hook-up interface to support I2C based GPIo expander
(TCA6416).

There are 3 instances of I2C Expander on AM3517EVM,
- One is over I2C-2 mounted on Base board
- Two are over I2C3 mounted on UI Card

Signed-off-by: Vaibhav Hiremath 
---
 arch/arm/mach-omap2/board-am3517evm.c |   37 +++-
 1 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index d9f487f..255328b 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -186,12 +187,44 @@ static struct i2c_board_info __initdata 
am3517evm_i2c_boardinfo[] = {
},
 };

+/*
+ * I2C GPIO Expander - TCA6416
+ */
+/* Mounted on Base-Board */
+static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES,
+};
+static struct i2c_board_info __initdata am3517evm_tca6516_info_0[] = {
+   {
+   I2C_BOARD_INFO("tca6416", 0x21),
+   .platform_data = &am3517evm_gpio_expander_info_0,
+   },
+};
+/* Mounted on UI Card */
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_1 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES + 16,
+};
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
+   .gpio_base  = OMAP_MAX_GPIO_LINES + 32,
+};
+static struct i2c_board_info __initdata am3517evm_ui_tca6516_info[] = {
+   {
+   I2C_BOARD_INFO("tca6416", 0x20),
+   .platform_data = &am3517evm_ui_gpio_expander_info_1,
+   },
+   {
+   I2C_BOARD_INFO("tca6416", 0x21),
+   .platform_data = &am3517evm_ui_gpio_expander_info_2,
+   },
+};

 static int __init am3517_evm_i2c_init(void)
 {
omap_register_i2c_bus(1, 400, NULL, 0);
-   omap_register_i2c_bus(2, 400, NULL, 0);
-   omap_register_i2c_bus(3, 400, NULL, 0);
+   omap_register_i2c_bus(2, 400, am3517evm_tca6516_info_0,
+   ARRAY_SIZE(am3517evm_tca6516_info_0));
+   omap_register_i2c_bus(3, 400, am3517evm_ui_tca6516_info,
+   ARRAY_SIZE(am3517evm_ui_tca6516_info));

return 0;
 }
--
1.6.2.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-V2] AM3517: Enable RTC driver support for AM3517EVM

2010-02-11 Thread hvaibhav
From: Vaibhav Hiremath 

Add platform hook-up interface to support RTC driver (S35390A).

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

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 247c700..d9f487f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -174,6 +174,18 @@ struct platform_device am3517_evm_dss_device = {
.platform_data  = &am3517_evm_dss_data,
},
 };
+/*
+ * RTC - S35390A
+ */
+#defineGPIO_RTCS35390A_IRQ 55
+
+static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[] = {
+   {
+   I2C_BOARD_INFO("s35390a", 0x30),
+   .type   = "s35390a",
+   },
+};
+

 static int __init am3517_evm_i2c_init(void)
 {
@@ -235,6 +247,19 @@ static void __init am3517_evm_init(void)
usb_ehci_init(&ehci_pdata);
/* DSS */
am3517_evm_display_init();
+
+   /* RTC - S35390A */
+   omap_mux_init_gpio(55, OMAP_PIN_INPUT_PULLUP);
+   if (gpio_request(GPIO_RTCS35390A_IRQ, "rtcs35390a-irq") < 0)
+   printk(KERN_WARNING "failed to request GPIO#%d\n",
+   GPIO_RTCS35390A_IRQ);
+   if (gpio_direction_input(GPIO_RTCS35390A_IRQ))
+   printk(KERN_WARNING "GPIO#%d cannot be configured as "
+   "input\n", GPIO_RTCS35390A_IRQ);
+   am3517evm_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_RTCS35390A_IRQ);
+
+   i2c_register_board_info(1, am3517evm_i2c_boardinfo,
+   ARRAY_SIZE(am3517evm_i2c_boardinfo));
 }

 static void __init am3517_evm_map_io(void)
--
1.6.2.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