Re: [FYI] Rebase: tidspbridge-20081118

[Hiroshi DOYU]

From: "ext Tony Lindgren" <[EMAIL PROTECTED]>
Subject: Re: [FYI] Rebase: tidspbridge-20081118
Date: Wed, 19 Nov 2008 13:37:29 -0800

> * Hiroshi DOYU <[EMAIL PROTECTED]> [081117 05:37]:
> > Hi,
> > 
> > The following changes since commit f23f23fb6bfd8ce4669070df35ec9b320983ac0c:
> >   Grazvydas Ignotas (1):
> > HSMMC: Add MMC configuration for pandora
> > 
> > are available in the git repository at:
> > 
> >   http://git.gitorious.org/lk/mainline.git tidspbridge-20081118
> 
> Great, I'm now also mirroring tidspbridge-20081118 branch at:
> 
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary

Since I think that logical patchset doesn't make sense for this early
stage, I am considering to stop rebasing on the top of "omap/master"
and to start updating "tidspbridge", just merging "omap/master" into
it frequently.

Hiroshi DOYU



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

Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly

[Evgeniy Polyakov]

Hi.

On Wed, Nov 19, 2008 at 12:01:06PM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
wrote:
> > I've just pushed w1 patch (did I understand it right that there is only
> > one in the given set, all others touch very different areas).
> 
> Yes, that's correct. The other patches are for LDP specific board support,
> and will be merged with the arm patches.

Patch is in the mainline tree.

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

[PATCH PM-20081119] OMAP: PM: Check both, IOPAD and UART wakeup always

[Jouni Hogander]

Uart RX might not always generate IOPAD wake-up. E.g. IOPAD is not
enabled or core was not in sleep state.

Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/serial.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 745ae5c..8d2f0b1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -281,7 +281,7 @@ void omap_uart_resume_idle(int num)
}
 
/* Check for normal UART wakeup */
-   else if (__raw_readl(uart->wk_st) & uart->wk_mask)
+   if (__raw_readl(uart->wk_st) & uart->wk_mask)
omap_uart_block_sleep(uart);
 
return;
-- 
1.6.0.1

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

Re: [ANNOUNCE] new PM branch: pm-20081119

[Peter Reid]

Hello kevin,
   Here is what i did to put it to suspend, which fails.

 [EMAIL PROTECTED] echo  mem > /sys/power/state
 PM: Syncing filesystems ... done.
 Freezing user space processes ... (elapsed 0.00 seconds) done.
 Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
 Suspending console(s)
 Class driver suspend failed for cpu0
 PM: Some devices failed to power down

Regards,
Reid.

On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> A new PM branch is available named pm-20081119.
>
> This is mostly a new set of patches on top of the previous PM branch,
> rather than a rebase.  We finally found the root cause of some DPLL
> relocking bugs.  Special thanks to Paul Walmsley and Tero Kristo for
> debugging and fixing this problem.  Now the DPLL fix that was reverted
> in the previous PM branch is re-applied as well as some fixes on top
> of it.  It also has some additional UART fixes, so I think the UART
> idle work is ready to go to Tony.  Special thanks to Jouni Hogander
> for the extra testing and fixes here.
>
> The shortlog is below[1] and the root of the tree is still
> v2.6.27-omap1 + T2 power patches from Peter.
>
> This has primarily been tested on custom HW since I'm _still_ waiting
> for my SDP to arrive.  I have boot tested on Beagle, but I think there
> are still some problems with ES2 silicon.  On my ES2 Beagle, neither
> DSS or IVA will leave the ON state, even when all clocks in their
> powerdomains are off.  I have not debugged this further yet.
>
> Functionally, this tree is in pretty good shape, so I will do some
> bugfixes here when necessary, but will now spent some time focusing on
> getting the patches in this branch merged into linux-omap.
>
> Kevin
>
>
> [1] git shortlog:
>
> Amit Kucheria (2):
>  OMAP: PM: Typo fix for clock_allow_idle
>  HSMMC: Make driver support dynamic idle
>
> Jouni Hogander (11):
>  OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle 
> loop
>  OMAP3: Do not set mpu, core, neon states if cpuidle is used
>  OMAP3: PM: Do not set next states sw to control those is available
>  OMAP3: PM: Always return value in pwrdms_setup
>  OMAP3: PM: Fix wrong sequence in suspend.
>  OMAP3: UART: Make sure that uart clocks are enabled when needed
>  OMAP3: PM: Check in set_pwrdm_state that target state is supported by 
> pwrdm v2
>  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
>  OMAP: PM: Build fails if PM is not enabled
>  OMAP2: PM: Fix omap2 build
>  OMAP: MCSPI: Enable mcspi wake-up
>
> Kalle Jokiniemi (4):
>  OMAP: PM: sysfs interface for enabling voltage off in idle
>  OMAP3: PM: Fix cpu idle init sequencing
>  OMAP: SRF: Fixes to shared resource framework (Ver.3)
>  OMAP3: I2C: Enable I2C wakeups
>
> Kevin Hilman (16):
>  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
>  OMAP3: PM: Allow UARTs to be unclocked when inactive
>  8250: Allow platform to register PM hook
>  8250: when waking, PM hook should be called before accessing port
>  OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
>  OMAP3: PM: UART save/restore support for OFF-mode
>  OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot
>  OMAP3: PM: CPUidle: obey enable_off_mode flag
>  OMAP3: PM: CPUidle: restrict C-states on UART activity
>  OMAP3: PM: decouple PER and CORE context save and restore
>  Revert "OMAP3 clock: fix non-CORE DPLL rate assignment bugs"
>  Revert "OMAP3: PM: Do not set next states sw to control those is 
> available"
>  Revert "OMAP3: Do not set mpu, core, neon states if cpuidle is used"
>  OMAP: PM: UART: fix can_sleep hook to return correct value
>  OMAP: PM: UART: Only disable clocks in prepare-idle hook
>  OMAP3: PM: Check for UART wakeups in 'resume_idle' hook
>
> Paul Walmsley (14):
>  OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op 
> layer.
>  OMAP2/3 omapdev: add basic omapdev structure
>  OMAP242x omapdev: add OMAP242x omapdev records
>  OMAP243x omapdev: add OMAP243x omapdev records
>  OMAP3xxx omapdev: add OMAP3xxx omapdev records
>  OMAP2/3 omapdev: add code to walk the omapdev records
>  OMAP3 clock: fix non-CORE DPLL rate assignment bugs
>  OMAP3 powerdomains: remove RET from SGX power states list
>  OMAP3 powerdomains: remove RET from SGX power states list
>  OMAP3 clock: remove unnecessary dpll_data dereferences
>  OMAP3 clock: optimize DPLL rate rounding algorithm
>  OMAP3 clock: avoid invalid FREQSEL values during DPLL rate rounding
>  OMAP2/3 I2C: reprogram OCP_SYSCONFIG register after reset
>  OMAP: I2C: convert 'rev1' flag to generic 'rev' u8
>
> Peter 'p2' De Schrijver (9):
>  OMAP: PM counter infrastructure.
>  OMAP: PM: Hook into PM counters
>  OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each.
>  OMAP: PM: Add pm-debu

[omapzoom][PATCH 1/4] DSPBRIDGE: Free resources when user fails to do so

[Ramirez Luna, Omar]

From: Fernando Guzman Lugo <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 15:49:56 -0600
Subject: [PATCH] DSPBRIDGE: Free resources when user fails to do so

Added error protection in bridge driver to handle
the cases where user applications detach the
processor without releasing DMM resources.

Signed-off-by: Fernando Guzman Lugo <[EMAIL PROTECTED]>
---
 arch/arm/plat-omap/include/dspbridge/drv.h |   13 +++
 drivers/dsp/bridge/rmgr/drv.c  |3 +-
 drivers/dsp/bridge/rmgr/proc.c |   31 +++
 3 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h 
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 0a8fb7e..4345b56 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -427,4 +427,17 @@ struct PROCESS_CONTEXT{
extern DSP_STATUS DRV_ReleaseResources(IN u32 dwContext,
   struct DRV_OBJECT *hDrvObject);
 
+/*
+ *   DRV_ProcFreeDMMRes 
+ *  Purpose:
+ *   Actual DMM De-Allocation.
+ *  Parameters:
+ *  hPCtxt:  Path to the driver Registry Key.
+ *  Returns:
+ *  DSP_SOK if success;
+ */
+
+
+   extern DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt);
+
 #endif /* DRV_ */
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 2614103..22faf49 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -162,7 +162,6 @@ static DSP_STATUS RequestBridgeResourcesDSP(u32 dwContext, 
s32 fRequest);
 
 static DSP_STATUS PrintProcessInformation(void);
 static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt);
-static DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt);
 static DSP_STATUS  DRV_ProcFreeSTRMRes(HANDLE hPCtxt);
 extern enum NODE_STATE NODE_GetState(HANDLE hNode);
 
@@ -559,7 +558,7 @@ DSP_STATUS DRV_UpdateDMMResElement(HANDLE hDMMRes, u32 
pMpuAddr, u32 ulSize,
 }
 
 /* Actual DMM De-Allocation */
-static DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
+DSP_STATUS  DRV_ProcFreeDMMRes(HANDLE hPCtxt)
 {
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index eb7781d..d7798e7 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -140,6 +140,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*  --- This */
 #include 
@@ -646,25 +647,27 @@ DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor)
pProcObject->g_pszLastCoff = NULL;
}
 
+#ifndef RES_CLEANUP_DISABLE
+   /* Return PID instead of process handle */
+   hProcess = current->pid;
+
+   res_status = CFG_GetObject((u32 *)&hDRVObject, REG_DRV_OBJECT);
+   if (DSP_SUCCEEDED(res_status)) {
+   DRV_GetProcContext(hProcess,
+   (struct DRV_OBJECT *)hDRVObject, &pPctxt,
+NULL, 0);
+   if (pPctxt != NULL) {
+   DRV_ProcFreeDMMRes(pPctxt);
+   pPctxt->hProcessor = NULL;
+   }
+   }
+#endif
+
/* Remove the Proc from the DEV List */
(void)DEV_RemoveProcObject(pProcObject->hDevObject,
(u32)pProcObject);
/* Free the Processor Object */
MEM_FreeObject(pProcObject);
-#ifndef RES_CLEANUP_DISABLE
-   /* Return PID instead of process handle */
-   hProcess = current->pid;
-
-   res_status = CFG_GetObject((u32 *)&hDRVObject, REG_DRV_OBJECT);
-   /* res_status = CFG_GetObject(REG_DRV_OBJECT, (u32*)&hDRVObject); */
-   if (DSP_SUCCEEDED(res_status)) {
-   DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDRVObject, &pPctxt,
-NULL, 0);
-   if (pPctxt != NULL)
-   pPctxt->hProcessor = NULL;
-   }
-#endif
} else {
status = DSP_EHANDLE;
GT_0trace(PROC_DebugMask, GT_7CLASS,
-- 
1.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[omapzoom][PATCH 2/4] DSPBRIDGE: LM Timer release for hibernation

[Ramirez Luna, Omar]

From: Ramesh Gupta <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 16:11:19 -0600
Subject: [PATCH] DSPBRIDGE: LM Timer release for hibernation

Release load monitor timer when the DSP is
inactive and goes to hibernation

Signed-off-by: Ramesh Gupta <[EMAIL PROTECTED]>
Signed-off-by: SuiLun Lam <[EMAIL PROTECTED]>
---
 drivers/dsp/bridge/wmd/tiomap_sm.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c 
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index 63655d9..edc3bcf 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -190,7 +190,6 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT 
*hDevContext)
 
if  (pDevContext->dwBrdState == BRD_DSP_HIBERNATION ||
pDevContext->dwBrdState == BRD_HIBERNATION) {
-   pDevContext->dwBrdState = BRD_RUNNING;
 #ifndef CONFIG_DISABLE_BRIDGE_PM
 #ifndef CONFIG_DISABLE_BRIDGE_DVFS
 #ifndef CONFIG_OMAP3_PM
@@ -235,9 +234,12 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT 
*hDevContext)
  mboxsetting.irqEnable0);
DBG_Trace(DBG_LEVEL6, "MailBoxSettings: IRQENABLE1 = 0x%x\n",
 mboxsetting.irqEnable1);
-   /* Restart the peripheral clocks that were disabled */
-   DSP_PeripheralClocks_Enable(hDevContext, NULL);
+   /* Restart the peripheral clocks that were disabled only
+* in DSP initiated Hibernation case.*/
+   if (pDevContext->dwBrdState == BRD_DSP_HIBERNATION)
+   DSP_PeripheralClocks_Enable(hDevContext, NULL);
 
+   pDevContext->dwBrdState = BRD_RUNNING;
}
while (--cnt) {
hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
-- 
1.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[omapzoom][PATCH 3/4] DSPBRIDGE: Mapping sidetone registers

[Ramirez Luna, Omar]

From: Hari Kanigeri <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 16:20:06 -0600
Subject: [PATCH] DSPBRIDGE: Mapping sidetone registers

New 3430 HW feature integrated into McBSP2
and McBSP3, enabling a sidetone process, for DASF.
Bridge has to handle this new configuration.

Signed-off-by: Hari Kanigeri <[EMAIL PROTECTED]>
---
 drivers/dsp/bridge/wmd/_tiomap.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h
index ed1bff9..5267eb2 100644
--- a/drivers/dsp/bridge/wmd/_tiomap.h
+++ b/drivers/dsp/bridge/wmd/_tiomap.h
@@ -161,6 +161,11 @@ struct MAP_L4PERIPHERAL {
 #define PM_GRPSEL_BASE 0x48307000
 #define DSPVA_GRPSEL_BASE  0x11821000
 
+#define L4_PERIPHERAL_SIDETONE_MCBSP20x49028000
+#define DSPVA_PERIPHERAL_SIDETONE_MCBSP2 0x11824000
+#define L4_PERIPHERAL_SIDETONE_MCBSP30x4902a000
+#define DSPVA_PERIPHERAL_SIDETONE_MCBSP3 0x11825000
+
 /* define a static array with L4 mappings */
 static const struct MAP_L4PERIPHERAL L4PeripheralTable[] = {
{L4_PERIPHERAL_MBOX, DSPVA_PERIPHERAL_MBOX},
@@ -196,6 +201,8 @@ static const struct MAP_L4PERIPHERAL L4PeripheralTable[] = {
{L4_PERIPHERAL_CM, DSPVA_PERIPHERAL_CM},
{L4_PERIPHERAL_PER, DSPVA_PERIPHERAL_PER},
{PM_GRPSEL_BASE, DSPVA_GRPSEL_BASE},
+   {L4_PERIPHERAL_SIDETONE_MCBSP2, DSPVA_PERIPHERAL_SIDETONE_MCBSP2},
+   {L4_PERIPHERAL_SIDETONE_MCBSP3, DSPVA_PERIPHERAL_SIDETONE_MCBSP3},
{L4_PERIPHERAL_NULL, DSPVA_PERIPHERAL_NULL}
 };
 
-- 
1.6.0

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

[omapzoom][PATCH 4/4] DSPBRIDGE Deleting unneeded mem alloc

[Ramirez Luna, Omar]

From: Hiroshi DOYU <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2008 17:13:58 -0600
Subject: [PATCH] DSPBRIDGE Deleting unneeded mem alloc

Since "SYNC_InitializeCS()" allocates "struct SYNC_CSOBJECT"
for "hProcLock", "MEM_AllocObject()" shouldn't be called
for "hProcLock". This was double allocation for the
same pointer.

Signed-off-by: Hiroshi DOYU <[EMAIL PROTECTED]>
---
 drivers/dsp/bridge/rmgr/proc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index d7798e7..9afaaad 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -1009,7 +1009,6 @@ bool PROC_Init(void)
DBC_Assert(!PROC_DebugMask.flags);
GT_create(&PROC_DebugMask, "PR");  /* "PR" for Processor */
 
-   MEM_AllocObject(hProcLock, struct SYNC_CSOBJECT, SIGNATURECS);
(void)SYNC_InitializeCS(&hProcLock);
}
 
-- 
1.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.28-rc5 4/5] twl4030 power button irq

[Felipe Balbi]

On Wed, Nov 19, 2008 at 05:28:58PM -0800, David Brownell wrote:
> From: David Brownell <[EMAIL PROTECTED]>
> 
> Disable the TWL4030_PWRIRQ_PWRBTN symbol from the system headers;
> initialization of the power button handler still needs work, so
> an equivalent symbol is defined in its driver.
> 
> Power IRQs now properly handle trigger specs from request_irq();
> stop goofing with registers reserved to the IRQ infrastructure.
> 
> Minor cleanup:  switch several messages to pr_debug().

How about moving this to a platform_device as well and also move to
drivers/input/misc ?

This question, of course, won't prevent this patch from being applied.

> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
>  drivers/i2c/chips/twl4030-pwrbutton.c |   50 
>  include/linux/i2c/twl4030.h   |2 -
>  2 files changed, 15 insertions(+), 37 deletions(-)
> 
> --- a/drivers/i2c/chips/twl4030-pwrbutton.c
> +++ b/drivers/i2c/chips/twl4030-pwrbutton.c
> @@ -29,18 +29,16 @@
>  #include 
>  #include 
>  
> -#define PWR_ISR1 0
> -#define PWR_IMR1 1
> +
>  #define PWR_PWRON_IRQ (1<<0)
>  
> -#define PWR_EDR1 5
> -#define PWR_PWRON_RISING (1<<1)
> -#define PWR_PWRON_FALLING  (1<<0)
> -#define PWR_PWRON_BOTH (PWR_PWRON_RISING | PWR_PWRON_FALLING)
> +#define STS_HW_CONDITIONS 0xf
>  
> -#define PWR_SIH_CTRL 7
>  
> -#define STS_HW_CONDITIONS 0xf
> +/* FIXME have this constant delivered to us as part of the
> + * twl4030-core setup ...
> + */
> +#define TWL4030_PWRIRQ_PWRBTN(TWL4030_PWR_IRQ_BASE + 0)
>  
>  static struct input_dev *powerbutton_dev;
>  
> @@ -73,20 +71,19 @@ static irqreturn_t powerbutton_irq(int i
>  static int __init twl4030_pwrbutton_init(void)
>  {
>   int err = 0;
> - u8 value;
>  
>   /* PWRBTN == PWRON */
> - if (request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq, 0,
> - "PwrButton", NULL) < 0) {
> - printk(KERN_ERR "Unable to allocate IRQ for power button\n");
> - err = -EBUSY;
> + err = request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq,
> + IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> + "PwrButton", NULL);
> + if (err < 0) {
> + pr_debug("Can't get IRQ for power button: %d\n", err);
>   goto out;
>   }
>  
>   powerbutton_dev = input_allocate_device();
>   if (!powerbutton_dev) {
> - printk(KERN_ERR
> - "Unable to allocate input device for power button\n");
> + pr_debug("Can't allocate power button\n");
>   err = -ENOMEM;
>   goto free_irq_and_out;
>   }
> @@ -97,26 +94,7 @@ static int __init twl4030_pwrbutton_init
>  
>   err = input_register_device(powerbutton_dev);
>   if (err) {
> - input_free_device(powerbutton_dev);
> - goto free_irq_and_out;
> - }
> -
> - /* FIXME just pass IRQF_EDGE_FALLING | IRQF_EDGE_RISING
> -  * to request_irq(), once MODULE_INT supports them...
> -  */
> - err = twl4030_i2c_read_u8(TWL4030_MODULE_INT, &value, PWR_EDR1);
> - if (err) {
> - printk(KERN_WARNING "I2C error %d while reading TWL4030"
> - " INT PWR_EDR1 register\n", err);
> - goto free_input_dev;
> - }
> -
> - err = twl4030_i2c_write_u8(TWL4030_MODULE_INT,
> -value | PWR_PWRON_BOTH, PWR_EDR1);
> -
> - if (err) {
> - printk(KERN_WARNING "I2C error %d while writing TWL4030"
> - " INT PWR_EDR1 register\n", err);
> + pr_debug("Can't register power button: %d\n", err);
>   goto free_input_dev;
>   }
>  
> @@ -126,7 +104,7 @@ static int __init twl4030_pwrbutton_init
>  
>  
>  free_input_dev:
> - input_unregister_device(powerbutton_dev);
> + input_free_device(powerbutton_dev);
>  free_irq_and_out:
>   free_irq(TWL4030_PWRIRQ_PWRBTN, NULL);
>  out:
> --- a/include/linux/i2c/twl4030.h
> +++ b/include/linux/i2c/twl4030.h
> @@ -379,7 +379,7 @@ int twl4030_sih_setup(int module);
>  /* #define TWL4030_MODIRQ_USB(TWL4030_IRQ_BASE + 4) */
>  /* #define TWL4030_MODIRQ_PWR(TWL4030_IRQ_BASE + 5) */
>  
> -#define TWL4030_PWRIRQ_PWRBTN(TWL4030_PWR_IRQ_BASE + 0)
> +/* #define TWL4030_PWRIRQ_PWRBTN (TWL4030_PWR_IRQ_BASE + 0) */
>  /* #define TWL4030_PWRIRQ_CHG_PRES   (TWL4030_PWR_IRQ_BASE + 1) */
>  /* #define TWL4030_PWRIRQ_USB_PRES   (TWL4030_PWR_IRQ_BASE + 2) */
>  /* #define TWL4030_PWRIRQ_RTC(TWL4030_PWR_IRQ_BASE + 3) */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTE

Re: [patch 2.6.28-rc5 4/5] twl4030 power button irq

[David Brownell]

On Thursday 20 November 2008, Felipe Balbi wrote:
> 
> > Disable the TWL4030_PWRIRQ_PWRBTN symbol from the system headers;
> > initialization of the power button handler still needs work, so
> > an equivalent symbol is defined in its driver.
> > 
> > ...
> 
> How about moving this to a platform_device as well and also move to
> drivers/input/misc ?

That'd seem to be the right solution.


> This question, of course, won't prevent this patch from being applied.

Right.  This series is just to fix things up so the last patch
(or an equivalent) can safely be pulled down from mainline.

- dave



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

OMAP Framebuffer memory allocation and mapping

[Tomi Valkeinen]

Hi,

I have a couple of questions regarding the memory management for the new
display subsystem.

The new DSS allocates memory with dma_alloc_writecombine() and mmaps it
to user space with dma_mmap_writecombine(). Allocation is done when
omapfb starts up. Normally memory gets very quickly too fragmented for
dma_alloc_writecombine() to work, but setting
CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this.

However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14, I
am, for some reason, not able to allocate 1280x1024x4 (~5.2M)
framebuffer. Could the consistent DMA area be already too fragmented, or
is there some size limit there?

There's also support to allocate fb memory in very early phase with
reserve_bootmem(), which needs a predefined physical address and size
that can come from the bootloader. I've been looking at the old DSS to
see how this memory should be mapped, but I haven't been able to get it
to work. It looks like the DSS DMA and the user space have a bit
different view of the memory, so my assumption is that there's some
caching or similar being done.

So how to setup the memory gotten from reserve_bootmem() (or
alloc_bootmem()) so that it would work the same way as
dma_alloc_writecombine()'s memory?

And generally: any other ideas how to improve the memory management of
the DSS?

 Tomi


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

Re: TWL4030 asoc kcontrols and widgets

[Felipe Balbi]

This list has been moved to linux-omap@vger.kernel.org

Please, keep that in Cc, also for ASoC development, send it also to the
proper alsa mailing list [EMAIL PROTECTED]

Tony, I think you should apply this patch in mainline tree:

diff --git a/MAINTAINERS b/MAINTAINERS
index 8dae455..54c8e90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4010,6 +4010,13 @@ P:   Alex Dubov
 M: [EMAIL PROTECTED]
 S: Maintained

+TI OMAP
+P: Tony Lindgren
+M: [EMAIL PROTECTED]
+L: linux-omap@vger.kernel.org
+T: git kernel.org:/pub/scm/linux/tmlind/linux-omap-2.6.git
+S: Maintained
+
 TI OMAP MMC INTERFACE DRIVER
 P: Carlos Aguiar, Anderson Briglia and Syed Khasim
 M: linux-omap@vger.kernel.org


On Thu, Nov 20, 2008 at 12:02 PM, naveen krishna ch
<[EMAIL PROTECTED]> wrote:
> Hi All
>
> I have been working on TWL4030 codec driver for ALSA SOC.
> I have taken sound/soc/codec/twl4030.c as reference from main line
>
> This Patch adds some kcontrols, widgets and interconnection map for some of
> the TWL4030 ASOC codec
> I was building it for a custom board as it was for OVERO
>
>
> Suggestions on the DAPM part of the driver would be helpful
>
> Thanks in advance.
>
> The patch is as follows.
>
>
> --- twl4030.c2008-11-19 12:04:32.0 +0530
> +++ /home/chnaveen/Desktop/twl4030.c2008-11-21 15:08:06.0 +0530
> @@ -16,7 +16,9 @@
>  * along with this program; if not, write to the Free Software
>  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>  * 02110-1301 USA
> - *
> + * Modified by  : Naveen Krishna Ch
> + * Added Kcontrols for OMAP3 WaterlooBoard
> + * Dated: 28th october 2008
>  */
>
>  #include 
> @@ -29,24 +31,27 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include "twl4030.h"
>
> +static int twl4030_jack_func;
> +
>  /*
>  * twl4030 register cache & default register settings
>  */
>  static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = {
> 0x00, /* this register not used*/
> -0x93, /* REG_CODEC_MODE(0x1)*/
> +0x03, /* REG_CODEC_MODE(0x1)*/
> 0xc3, /* REG_OPTION(0x2)*/
> 0x00, /* REG_UNKNOWN(0x3)*/
> 0x00, /* REG_MICBIAS_CTL(0x4)*/
> -0x24, /* REG_ANAMICL(0x5)*/
> -0x04, /* REG_ANAMICR(0x6)*/
> +0xb0, /* REG_ANAMICL(0x5)*/
> +0x10, /* REG_ANAMICR(0x6)*/
> 0x0a, /* REG_AVADC_CTL(0x7)*/
> 0x00, /* REG_ADCMICSEL(0x8)*/
> 0x00, /* REG_DIGMIXING(0x9)*/
> @@ -67,22 +72,22 @@
> 0x00, /* REG_ARX2VTXPGA(0x18)*/
> 0x00, /* REG_ARXL1_APGA_CTL(0x19)*/
> 0x00, /* REG_ARXR1_APGA_CTL(0x1A)*/
> -0x4b, /* REG_ARXL2_APGA_CTL(0x1B)*/
> -0x4b, /* REG_ARXR2_APGA_CTL(0x1C)*/
> +0x2b, /* REG_ARXL2_APGA_CTL(0x1B)*/
> +0x2b, /* REG_ARXR2_APGA_CTL(0x1C)*/
> 0x00, /* REG_ATX2ARXPGA(0x1D)*/
> 0x00, /* REG_BT_IF(0x1E)*/
> 0x00, /* REG_BTPGA(0x1F)*/
> 0x00, /* REG_BTSTPGA(0x20)*/
> -0x00, /* REG_EAR_CTL(0x21)*/
> -0x24, /* REG_HS_SEL(0x22)*/
> -0x0a, /* REG_HS_GAIN_SET(0x23)*/
> -0x00, /* REG_HS_POPN_SET(0x24)*/
> -0x00, /* REG_PREDL_CTL(0x25)*/
> -0x00, /* REG_PREDR_CTL(0x26)*/
> -0x00, /* REG_PRECKL_CTL(0x27)*/
> -0x00, /* REG_PRECKR_CTL(0x28)*/
> -0x00, /* REG_HFL_CTL(0x29)*/
> -0x00, /* REG_HFR_CTL(0x2A)*/
> +0x20, /* REG_EAR_CTL(0x21)*/
> +0x00, /* REG_HS_SEL(0x22)*/
> +0x05, /* REG_HS_GAIN_SET(0x23)*/
> +0x42, /* REG_HS_POPN_SET(0x24)*/
> +0x20, /* REG_PREDL_CTL(0x25)*/
> +0x20, /* REG_PREDR_CTL(0x26)*/
> +0x20, /* REG_PRECKL_CTL(0x27)*/
> +0x20, /* REG_PRECKR_CTL(0x28)*/
> +0x1f, /* REG_HFL_CTL(0x29)*/
> +0x1f, /* REG_HFR_CTL(0x2A)*/
> 0x00, /* REG_ALC_CTL(0x2B)*/
> 0x00, /* REG_ALC_SET1(0x2C)*/
> 0x00, /* REG_ALC_SET2(0x2D)*/
> @@ -112,9 +117,40 @@
> 0x00, /* REG_VIBRA_CTL(0x45)*/
> 0x00, /* REG_VIBRA_SET(0x46)*/
> 0x00, /* REG_VIBRA_PWM_SET(0x47)*/
> -0x00, /* REG_ANAMIC_GAIN(0x48)*/
> +0x24, /* REG_ANAMIC_GAIN(0x48)*/
> 0x00, /* REG_MISC_SET_2(0x49)*/
>  };
> +static void twl4030_ext_control(struct snd_soc_codec *codec)
> +{
> +if (twl4030_jack_func)
> +snd_soc_dapm_enable_pin(codec, "Headphone Jack");
> +else
> +snd_soc_dapm_disable_pin(codec, "Headphone Jack");
> +
> +snd_soc_dapm_sync(codec);
> +}
> +
> +static int twl4030_get_jack(struct snd_kcontrol *kc

RE: OMAP Framebuffer memory allocation and mapping

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-omap-
> [EMAIL PROTECTED] On Behalf Of Tomi Valkeinen
> Sent: Thursday, November 20, 2008 4:22 PM
> To: linux-omap@vger.kernel.org
> Subject: OMAP Framebuffer memory allocation and mapping
> 
> Hi,
> 
> I have a couple of questions regarding the memory management for the
> new
> display subsystem.
> 
> The new DSS allocates memory with dma_alloc_writecombine() and mmaps
> it
> to user space with dma_mmap_writecombine(). Allocation is done when
> omapfb starts up. Normally memory gets very quickly too fragmented
> for
> dma_alloc_writecombine() to work, but setting
> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this.
> 
> However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14,
> I
> am, for some reason, not able to allocate 1280x1024x4 (~5.2M)
> framebuffer. Could the consistent DMA area be already too
> fragmented, or
> is there some size limit there?
> 
[Hiremath, Vaibhav] Similar issue I had also faced while implementing VRFB 
rotation on new DSS of yours. I increased the value of MAX_ORDER to 12 
(currently set to 11), defined in include/linux/mmzone.h file. And it worked 
for me; I am allocating 2048*720*4 bytes of buffer.

I am not sure community acceptance on this, probably somebody could suggest 
better way to this.

> There's also support to allocate fb memory in very early phase with
> reserve_bootmem(), which needs a predefined physical address and
> size
> that can come from the bootloader. I've been looking at the old DSS
> to
> see how this memory should be mapped, but I haven't been able to get
> it
> to work. It looks like the DSS DMA and the user space have a bit
> different view of the memory, so my assumption is that there's some
> caching or similar being done.
> 
> So how to setup the memory gotten from reserve_bootmem() (or
> alloc_bootmem()) so that it would work the same way as
> dma_alloc_writecombine()'s memory?
> 
> And generally: any other ideas how to improve the memory management
> of
> the DSS?
> 
>  Tomi
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] Fix section mismatch warning.

[Premi, Sanjeev]

> -Original Message-
> From: David Brownell [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 20, 2008 5:56 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] Fix section mismatch warning.
> 
> I know that Beagle and Overo get the same warnings, so this 
> isn't really a sufficient fix...

Was trying to fix for EVM. Can extend to these boards once we have a fix.

> 
> On Wednesday 19 November 2008, Sanjeev Premi wrote:
> > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > @@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data 
> > omap3evm_madc_data = {
> > .irq_line   = 1,
> >  };
> >  
> > -static struct twl4030_platform_data omap3evm_twldata = {
> > +static struct twl4030_platform_data __initdata omap3evm_twldata = {
> 
> ... and that's incorrect in any case, since that data is used 
> by probe() code that's doesn't sit in an init section.

Function probe() would be in __devinit. Changing __initdata to __devinit
would be fine for compilation. Do you see any issues with it?

BTW, I could not locate the definition of platform_driver for twl4030
to verify if probe() is indeed in __devinit.

> I have the following in my patchset, currently disabled since 
> it conflicts with other patches.  And in any case, Beagle 
> can't reboot with these "generic" scripts for some TBD reason.
> 
> - Dave
> 
> = CUT HERE
> ---
>  arch/arm/mach-omap2/board-omap3beagle.c   |2 +-
>  arch/arm/mach-omap2/board-omap3evm.c  |2 +-
>  arch/arm/mach-omap2/board-overo.c |2 +-
>  arch/arm/mach-omap2/twl4030-generic-scripts.c |3 +++
>  arch/arm/mach-omap2/twl4030-generic-scripts.h |5 +
>  5 files changed, 11 insertions(+), 3 deletions(-)
> 
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -188,7 +188,7 @@ static struct twl4030_platform_data beag
>   /* platform_data for children goes here */
>   .usb= &beagle_usb_data,
>   .gpio   = &beagle_gpio_data,
> - .power  = &generic3430_t2scripts_data,
> + .power  = GENERIC3430_T2SCRIPTS_DATA,
>  };
>  
>  static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -140,7 +140,7 @@ static struct twl4030_platform_data omap
>   .keypad = &omap3evm_kp_data,
>   .madc   = &omap3evm_madc_data,
>   .usb= &omap3evm_usb_data,
> - .power  = &generic3430_t2scripts_data,
> + .power  = GENERIC3430_T2SCRIPTS_DATA,
>   .gpio   = &omap3evm_gpio_data,
>  };
>  
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -162,7 +162,7 @@ static struct twl4030_platform_data over
>   .irq_end= TWL4030_IRQ_END,
>   .gpio   = &overo_gpio_data,
>   .usb= &overo_usb_data,
> - .power  = &generic3430_t2scripts_data,
> + .power  = GENERIC3430_T2SCRIPTS_DATA,
>  };
>  
>  static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
> --- a/arch/arm/mach-omap2/twl4030-generic-scripts.c
> +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.c
> @@ -23,6 +23,8 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  
> 02111-1307  USA
>   */
>  
> +#ifdef CONFIG_TWL4030_POWER
> +
>  #include 
>  #include 
>  #include 
> @@ -76,3 +78,4 @@ struct twl4030_power_data generic3430_t2  };
>  
>  
> +#endif /* CONFIG_TWL4030_POWER */
> --- a/arch/arm/mach-omap2/twl4030-generic-scripts.h
> +++ b/arch/arm/mach-omap2/twl4030-generic-scripts.h
> @@ -3,6 +3,11 @@
>  
>  #include 
>  
> +#ifdef CONFIG_TWL4030_POWER
>  extern struct twl4030_power_data generic3430_t2scripts_data;
> +#define GENERIC3430_T2SCRIPTS_DATA &generic3430_t2scripts_data #else 
> +#define GENERIC3430_T2SCRIPTS_DATA NULL #endif /* 
> CONFIG_TWL4030_POWER 
> +*/
>  
>  #endif
> 
> 
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix section mismatch warning.

[Felipe Balbi]

On Thu, Nov 20, 2008 at 06:14:55PM +0530, ext Premi, Sanjeev wrote:
> 
> > -Original Message-
> > From: David Brownell [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, November 20, 2008 5:56 AM
> > To: Premi, Sanjeev
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [PATCH] Fix section mismatch warning.
> > 
> > I know that Beagle and Overo get the same warnings, so this 
> > isn't really a sufficient fix...
> 
> Was trying to fix for EVM. Can extend to these boards once we have a fix.
> 
> > 
> > On Wednesday 19 November 2008, Sanjeev Premi wrote:
> > > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > > @@ -130,7 +130,7 @@ static struct twl4030_madc_platform_data 
> > > omap3evm_madc_data = {
> > > .irq_line   = 1,
> > >  };
> > >  
> > > -static struct twl4030_platform_data omap3evm_twldata = {
> > > +static struct twl4030_platform_data __initdata omap3evm_twldata = {
> > 
> > ... and that's incorrect in any case, since that data is used 
> > by probe() code that's doesn't sit in an init section.

__initdata_or_module would do the trick for static and dynamically
linked modules. When building it statically, we'd get a bit of
shrinkage, right ?

> Function probe() would be in __devinit. Changing __initdata to __devinit
> would be fine for compilation. Do you see any issues with it?

doesn't make sense.

> BTW, I could not locate the definition of platform_driver for twl4030
> to verify if probe() is indeed in __devinit.

It's in drivers/base/platform.c

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

Re: [PATCH] Fix section mismatch warning.

[David Brownell]

On Thursday 20 November 2008, Premi, Sanjeev wrote:
> BTW, I could not locate the definition of platform_driver for twl4030
> to verify if probe() is indeed in __devinit.

In this case, drivers/mfd/twl4030-power.c is what will use that
data, and it's called from drivers/mfd/twl4030-core.c ... which
is an I2C client.

I don't know of any cases when it's safe to have I2C drivers
have their probe() use an __init or __devinit annotation.


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

[PATCH] OMAP: Switch to gpio_direction_output in OMAP_LDP.

[Stanley.Miao]

stop using omap_set_gpio_direction() and switch to gpio_direction_output(),
make omap_ldp can build sucessfully.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-ldp.c |2 +-
 drivers/video/omap/lcd_ldp.c|8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index bc66b28..a59e4eb 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -341,7 +341,7 @@ static inline void __init ldp_init_smc911x(void)
eth_gpio);
return;
}
-   omap_set_gpio_direction(eth_gpio, 1);
+   gpio_direction_input(eth_gpio);
 }
 
 
diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c
index e944166..5892765 100644
--- a/drivers/video/omap/lcd_ldp.c
+++ b/drivers/video/omap/lcd_ldp.c
@@ -69,17 +69,15 @@ static int ldp_panel_init(struct lcd_panel *panel,
gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
 
-   omap_set_gpio_direction(LCD_PANEL_QVGA_GPIO, 0);
-   omap_set_gpio_direction(LCD_PANEL_RESET_GPIO, 0);
gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
 
 #ifdef CONFIG_FB_OMAP_LCD_VGA
-   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
 #else
-   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
 #endif
-   omap_set_gpio_dataout(LCD_PANEL_RESET_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_RESET_GPIO, 1);
 
return 0;
 }
-- 
1.5.6.3

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

[PATCH] OMAP: set appropriate platform data for touchscreen.

[Stanley.Miao]

Set appropriate platform data for touchscreen and make it work correctly.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-3430sdp.c |8 
 arch/arm/mach-omap2/board-ldp.c |8 
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index b7d2e92..42f92be 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -213,9 +213,17 @@ static int ads7846_vaux_control(int vaux_cntrl)
 }
 
 static struct ads7846_platform_data tsc2046_config __initdata = {
+   .x_max  = 0x0fff,
+   .y_max  = 0x0fff,
+   .x_plate_ohms   = 180,
+   .pressure_max   = 255,
+   .debounce_max   = 10,
+   .debounce_tol   = 10,
+   .debounce_rep   = 1,
.get_pendown_state  = ads7846_get_pendown_state,
.keep_vref_on   = 1,
.vaux_control   = ads7846_vaux_control,
+   .settle_delay_usecs = 150,
 };
 
 
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index a59e4eb..f17d507 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -277,9 +277,17 @@ static int ads7846_vaux_control(int vaux_cntrl)
 }
 
 static struct ads7846_platform_data tsc2046_config __initdata = {
+   .x_max  = 0x0fff,
+   .y_max  = 0x0fff,
+   .x_plate_ohms   = 180,
+   .pressure_max   = 255,
+   .debounce_max   = 10,
+   .debounce_tol   = 10,
+   .debounce_rep   = 1,
.get_pendown_state  = ads7846_get_pendown_state,
.keep_vref_on   = 1,
.vaux_control   = ads7846_vaux_control,
+   .settle_delay_usecs = 150,
 };
 
 
-- 
1.5.6.3

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

[PATCH] OMAP3 NAND: Add NAND support on OMAP_LDP

[Stanley.Miao]

Add NAND support on OMAP_LDP.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/Makefile|3 +-
 arch/arm/mach-omap2/board-ldp-flash.c   |  103 +++
 arch/arm/mach-omap2/board-ldp.c |1 +
 arch/arm/plat-omap/include/mach/board-ldp.h |2 +
 4 files changed, 108 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-ldp-flash.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3897347..bfc9bcf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -66,7 +66,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE)   += 
board-omap3beagle.o \
   twl4030-generic-scripts.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
   mmc-twl4030.o \
-  usb-musb.o
+  usb-musb.o \
+  board-ldp-flash.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
   board-apollon-mmc.o  \
   board-apollon-keys.o
diff --git a/arch/arm/mach-omap2/board-ldp-flash.c 
b/arch/arm/mach-omap2/board-ldp-flash.c
new file mode 100644
index 000..4c20f5f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ldp-flash.c
@@ -0,0 +1,103 @@
+/*
+ * linux/arch/arm/mach-omap2/board-ldp-flash.c
+ *
+ * Copyright (C) 2008 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-2430sdp-flash.c
+ * Author: Rohit Choraria <[EMAIL PROTECTED]>
+ *
+ * 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 
+
+#define GPMC_CS0_BASE  0x60
+#define GPMC_CS_SIZE   0x30
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition ldp_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader-NAND",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "Boot Env-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x10 */
+   .size   = 2 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x14 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System - NAND",
+   .size   = MTDPART_SIZ_FULL,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x54 */
+   },
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data ldp_nand_data = {
+   .parts  = ldp_nand_partitions,
+   .nr_parts   = ARRAY_SIZE(ldp_nand_partitions),
+   .nand_setup = NULL,
+   .dma_channel= -1,   /* disable DMA in OMAP NAND driver */
+   .dev_ready  = NULL,
+};
+
+static struct resource ldp_nand_resource = {
+   .flags  = IORESOURCE_MEM,
+};
+
+static struct platform_device ldp_nand_device = {
+   .name   = "omap2-nand",
+   .id = 0,
+   .dev= {
+   .platform_data  = &ldp_nand_data,
+   },
+   .num_resources  = 1,
+   .resource   = &ldp_nand_resource,
+};
+
+/**
+ * ldp430_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init ldp_flash_init(void)
+{
+   int nandcs = LDP_NAND_CS;
+   u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+   ldp_nand_data.cs = nandcs;
+   ldp_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+   GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+   ldp_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
+
+   if (platform_device_register(&ldp_nand_device) < 0)
+   printk(KERN_ERR "Unable to register NAND device\n");
+}
+
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index f17d507..d6f25ae 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -538,6 +538,7 @@ static void __init omap_ldp_init(void)
  

RE: [ANNOUNCE] new PM branch: pm-20081119

[Premi, Sanjeev]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Reid
> Sent: Thursday, November 20, 2008 2:16 PM
> To: Kevin Hilman
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
> 
> Hello kevin,
>Here is what i did to put it to suspend, which fails.
> 
>  [EMAIL PROTECTED] echo  mem > /sys/power/state
>  PM: Syncing filesystems ... done.
>  Freezing user space processes ... (elapsed 0.00 seconds) done.
>  Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
>  Suspending console(s)
>  Class driver suspend failed for cpu0
>  PM: Some devices failed to power down
> 
> Regards,
> Reid.
These are my observations on OMAP3EVM:

1) Very frequently I see these messages:

<4>__ratelimit: 6736 callbacks suppressed
__ratelimit: 6736 callbacks suppressed
<3>omapfb omapfb: irq error status 00c2
omapfb omapfb: irq error status 00c2
<3>omapfb omapfb: irq error status 0060
omapfb omapfb: irq error status 0060
<3>omapfb omapfb: irq error status 00c2
omapfb omapfb: irq error status 00c2
<3>omapfb omapfb: irq error status 0060
omapfb omapfb: irq error status 0060
<3>omapfb omapfb: irq error status 00e2
omapfb omapfb: irq error status 00e2
<3>omapfb omapfb: irq error status 00c2
omapfb omapfb: irq error status 00c2
<3>omapfb omapfb: irq error status 0060
omapfb omapfb: irq error status 0060
<3>omapfb omapfb: irq error status 00e2
omapfb omapfb: irq error status 00e2
<3>omapfb omapfb: irq error status 00c2
omapfb omapfb: irq error status 00c2
<3>omapfb omapfb: irq error status 0060
omapfb omapfb: irq error status 0060

2) Also:
# echo mem > /sys/power/state
<6>PM: Syncing filesystems ...
PM: Syncing filesystems ...
done.
done.
Freezing user space processes ... Freezing user space processes ... (elapsed 
0.00 seconds) (elapsed 0.00 seconds) done.
done.
Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... 
(elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
done.

Suspending console(s) (use no_console_suspend to debug)
Suspending console(s) (use no_console_suspend to debug)
<3>omapfb omapfb: timeout waiting for FRAME DONE

However, I the "resume" doesn't happen.
Trying to debug further.

Best regards,
Sanjeev

> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman 
> <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > A new PM branch is available named pm-20081119.
> >
> > This is mostly a new set of patches on top of the previous 
> PM branch, 
> > rather than a rebase.  We finally found the root cause of some DPLL 
> > relocking bugs.  Special thanks to Paul Walmsley and Tero 
> Kristo for 
> > debugging and fixing this problem.  Now the DPLL fix that 
> was reverted 
> > in the previous PM branch is re-applied as well as some 
> fixes on top 
> > of it.  It also has some additional UART fixes, so I think the UART 
> > idle work is ready to go to Tony.  Special thanks to Jouni Hogander 
> > for the extra testing and fixes here.
> >
> > The shortlog is below[1] and the root of the tree is still
> > v2.6.27-omap1 + T2 power patches from Peter.
> >
> > This has primarily been tested on custom HW since I'm 
> _still_ waiting 
> > for my SDP to arrive.  I have boot tested on Beagle, but I 
> think there 
> > are still some problems with ES2 silicon.  On my ES2 
> Beagle, neither 
> > DSS or IVA will leave the ON state, even when all clocks in their 
> > powerdomains are off.  I have not debugged this further yet.
> >
> > Functionally, this tree is in pretty good shape, so I will do some 
> > bugfixes here when necessary, but will now spent some time 
> focusing on 
> > getting the patches in this branch merged into linux-omap.
> >
> > Kevin
> >
> >
> > [1] git shortlog:
> >
> > Amit Kucheria (2):
> >  OMAP: PM: Typo fix for clock_allow_idle
> >  HSMMC: Make driver support dynamic idle
> >
> > Jouni Hogander (11):
> >  OMAP3: PM: Use pwrdm_set_next_pwrst instead of 
> set_pwrdm_state in idle loop
> >  OMAP3: Do not set mpu, core, neon states if cpuidle is used
> >  OMAP3: PM: Do not set next states sw to control those 
> is available
> >  OMAP3: PM: Always return value in pwrdms_setup
> >  OMAP3: PM: Fix wrong sequence in suspend.
> >  OMAP3: UART: Make sure that uart clocks are enabled when needed
> >  OMAP3: PM: Check in set_pwrdm_state that target state 
> is supported by pwrdm v2
> >  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
> >  OMAP: PM: Build fails if PM is not enabled
> >  OMAP2: PM: Fix omap2 build
> >  OMAP: MCSPI: Enable mcspi wake-up
> >
> > Kalle Jokiniemi (4):
> >  OMAP: PM: sysfs interface for enabling voltage off in idle
> >  OMAP3: PM: Fix cpu idle init sequencing
> >  OMAP: SRF: Fixes to shared resource framework (Ver.3)
> >  OMAP3: I2C: Enable I2C wakeups
> >
> > Kevin Hilman (16):
> >  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
> >  OMAP3: PM: Allow UARTs to be unclocked when inactive
> 

Re: [ANNOUNCE] new PM branch: pm-20081119

[Koen Kooi]

Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven:



These are my observations on OMAP3EVM:

1) Very frequently I see these messages:

<4>__ratelimit: 6736 callbacks suppressed
__ratelimit: 6736 callbacks suppressed
<3>omapfb omapfb: irq error status 00c2
omapfb omapfb: irq error status 00c2


There should be a workaround for those in 2.6.28rc3.  Rick Bronson  
posted a message about it on 7 november titled "Fix for dispc's error  
"omapfb omapfb: irq error status 4020"


regards,

Koen

regards,

Koen


PGP.sig
Description: This is a digitally signed message part

omap display controller strange problem

[Sudipta GHOSH]

Hi,

I am facing a strange problem with omap display controller. (kernel 2.6.25)

in omap_dispc_irq_handler, if I use printk then only display is
working (initialization and refreshing)

else after few refresh ..its stop working.

static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
{


if ((stat & dispc.enabled_irqs) && dispc.irq_callback) {
printk("omap_irqH\n"); 
< ?
dispc.irq_callback(dispc.irq_callback_data);
}


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

RE: omap display controller strange problem

[Hiremath, Vaibhav]

Thanks,
Vaibhav Hiremath

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-omap-
> [EMAIL PROTECTED] On Behalf Of Sudipta GHOSH
> Sent: Thursday, November 20, 2008 8:48 PM
> To: linux-omap@vger.kernel.org
> Subject: omap display controller strange problem
> 
> Hi,
> 
> I am facing a strange problem with omap display controller. (kernel
> 2.6.25)
> 
> in omap_dispc_irq_handler, if I use printk then only display is
> working (initialization and refreshing)
> 
[Hiremath, Vaibhav] What do you mean by "only display"?

Can you please provide detailed information about the issue? Your mail doesn't 
convey much.

> else after few refresh ..its stop working.
> 
> static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
> {
>   
> 
>   if ((stat & dispc.enabled_irqs) && dispc.irq_callback) {
>   printk("omap_irqH\n"); <
>  ?
>   dispc.irq_callback(dispc.irq_callback_data);
>   }
> 
> 
> Regards,
> -SG
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ANNOUNCE] new PM branch: pm-20081119

[Premi, Sanjeev]

 

> -Original Message-
> From: Koen Kooi [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 20, 2008 8:19 PM
> To: Premi, Sanjeev
> Cc: Peter Reid; Kevin Hilman; linux-omap@vger.kernel.org
> Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
> 
> 
> Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven:
> >>
> > These are my observations on OMAP3EVM:
> >
> > 1) Very frequently I see these messages:
> >
> > <4>__ratelimit: 6736 callbacks suppressed
> > __ratelimit: 6736 callbacks suppressed <3>omapfb omapfb: irq error 
> > status 00c2 omapfb omapfb: irq error status 00c2
> 
> There should be a workaround for those in 2.6.28rc3.  Rick 
> Bronson posted a message about it on 7 november titled "Fix 
> for dispc's error "omapfb omapfb: irq error status 4020"
> 

Did not help on this branch; not sure if there are any dependencies...

> regards,
> 
> Koen
> 
> regards,
> 
> Koen
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap display controller strange problem

[Sudipta GHOSH]

thanks for the reply.

in my board, there is a sharp lcd display.
We are using RFBI. and manual update.

So after configuraing dispc, rfbi, sharp from omapfb_do_probe

calling fbdev->ext_if->transfer_area(240,320,omapfb_cb,fbdev); return 0;

I see linux logo and debug prints but after some boot time prints, it
stop refresing the display.
I mean I cant see any more prints. (I have few prints in key press).

But if I use printk("omap_irqH\n"); in omap_dispc_irq_handler. I saw
all prints coming including key press.
I mean if I use that printk then display is working.

let me know if you need any more info.

Regards,
-SG



2008/11/20 Hiremath, Vaibhav <[EMAIL PROTECTED]>:
>
>
> Thanks,
> Vaibhav Hiremath
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:linux-omap-
>> [EMAIL PROTECTED] On Behalf Of Sudipta GHOSH
>> Sent: Thursday, November 20, 2008 8:48 PM
>> To: linux-omap@vger.kernel.org
>> Subject: omap display controller strange problem
>>
>> Hi,
>>
>> I am facing a strange problem with omap display controller. (kernel
>> 2.6.25)
>>
>> in omap_dispc_irq_handler, if I use printk then only display is
>> working (initialization and refreshing)
>>
> [Hiremath, Vaibhav] What do you mean by "only display"?
>
> Can you please provide detailed information about the issue? Your mail 
> doesn't convey much.
>
>> else after few refresh ..its stop working.
>>
>> static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
>> {
>>   
>>
>>   if ((stat & dispc.enabled_irqs) && dispc.irq_callback) {
>>   printk("omap_irqH\n"); <
>>  ?
>>   dispc.irq_callback(dispc.irq_callback_data);
>>   }
>>
>>
>> Regards,
>> -SG
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-
>> omap" in
>> the body of a message to [EMAIL PROTECTED]
>> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ANNOUNCE] new PM branch: pm-20081119

[Premi, Sanjeev]

--
> 
> 2) Also:
> # echo mem > /sys/power/state
> <6>PM: Syncing filesystems ...
> PM: Syncing filesystems ...
> done.
> done.
> Freezing user space processes ... Freezing user space 
> processes ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
> done.
> Freezing remaining freezable tasks ... Freezing remaining 
> freezable tasks ... (elapsed 0.00 seconds) (elapsed 0.00 
> seconds) done.
> done.
> 
> Suspending console(s) (use no_console_suspend to debug) 
> Suspending console(s) (use no_console_suspend to debug) 
> <3>omapfb omapfb: timeout waiting for FRAME DONE

I see a bus error generated.
Haven't been able to nail the reason so far :(

Last symbol I could trace was pm_power_off

> 
> However, I the "resume" doesn't happen.
> Trying to debug further.
> 


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

Re: [FYI] Rebase: tidspbridge-20081118

[Tony Lindgren]

* Hiroshi DOYU <[EMAIL PROTECTED]> [081120 00:21]:
> From: "ext Tony Lindgren" <[EMAIL PROTECTED]>
> Subject: Re: [FYI] Rebase: tidspbridge-20081118
> Date: Wed, 19 Nov 2008 13:37:29 -0800
> 
> > * Hiroshi DOYU <[EMAIL PROTECTED]> [081117 05:37]:
> > > Hi,
> > > 
> > > The following changes since commit 
> > > f23f23fb6bfd8ce4669070df35ec9b320983ac0c:
> > >   Grazvydas Ignotas (1):
> > > HSMMC: Add MMC configuration for pandora
> > > 
> > > are available in the git repository at:
> > > 
> > >   http://git.gitorious.org/lk/mainline.git tidspbridge-20081118
> > 
> > Great, I'm now also mirroring tidspbridge-20081118 branch at:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary
> 
> Since I think that logical patchset doesn't make sense for this early
> stage, I am considering to stop rebasing on the top of "omap/master"
> and to start updating "tidspbridge", just merging "omap/master" into
> it frequently.

Sure, looks like it's going to be a quite a while before the bridge
code is a logical patchset :)

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

Re: [PATCH v2 0/6] OMAP: Make OMAP LDP boot succussfuly

[Tony Lindgren]

* Evgeniy Polyakov <[EMAIL PROTECTED]> [081120 00:35]:
> Hi.
> 
> On Wed, Nov 19, 2008 at 12:01:06PM -0800, Tony Lindgren ([EMAIL PROTECTED]) 
> wrote:
> > > I've just pushed w1 patch (did I understand it right that there is only
> > > one in the given set, all others touch very different areas).
> > 
> > Yes, that's correct. The other patches are for LDP specific board support,
> > and will be merged with the arm patches.
> 
> Patch is in the mainline tree.

Thanks!

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

Re: TWL4030 asoc kcontrols and widgets

[Tony Lindgren]

* Felipe Balbi <[EMAIL PROTECTED]> [081120 02:55]:
> This list has been moved to linux-omap@vger.kernel.org
> 
> Please, keep that in Cc, also for ASoC development, send it also to the
> proper alsa mailing list [EMAIL PROTECTED]
> 
> Tony, I think you should apply this patch in mainline tree:
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8dae455..54c8e90 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4010,6 +4010,13 @@ P:   Alex Dubov
>  M: [EMAIL PROTECTED]
>  S: Maintained
> 
> +TI OMAP
> +P: Tony Lindgren
> +M: [EMAIL PROTECTED]
> +L: linux-omap@vger.kernel.org
> +T: git kernel.org:/pub/scm/linux/tmlind/linux-omap-2.6.git
> +S: Maintained
> +
>  TI OMAP MMC INTERFACE DRIVER
>  P: Carlos Aguiar, Anderson Briglia and Syed Khasim
>  M: linux-omap@vger.kernel.org


Yeah sure. Let's also add maintainers for omap subsystems that have
maintainers while we're at it.

Tony


> 
> 
> On Thu, Nov 20, 2008 at 12:02 PM, naveen krishna ch
> <[EMAIL PROTECTED]> wrote:
> > Hi All
> >
> > I have been working on TWL4030 codec driver for ALSA SOC.
> > I have taken sound/soc/codec/twl4030.c as reference from main line
> >
> > This Patch adds some kcontrols, widgets and interconnection map for some of
> > the TWL4030 ASOC codec
> > I was building it for a custom board as it was for OVERO
> >
> >
> > Suggestions on the DAPM part of the driver would be helpful
> >
> > Thanks in advance.
> >
> > The patch is as follows.
> >
> >
> > --- twl4030.c2008-11-19 12:04:32.0 +0530
> > +++ /home/chnaveen/Desktop/twl4030.c2008-11-21 15:08:06.0 +0530
> > @@ -16,7 +16,9 @@
> >  * along with this program; if not, write to the Free Software
> >  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> >  * 02110-1301 USA
> > - *
> > + * Modified by  : Naveen Krishna Ch
> > + * Added Kcontrols for OMAP3 WaterlooBoard
> > + * Dated: 28th october 2008
> >  */
> >
> >  #include 
> > @@ -29,24 +31,27 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > -
> > +#include 
> >  #include "twl4030.h"
> >
> > +static int twl4030_jack_func;
> > +
> >  /*
> >  * twl4030 register cache & default register settings
> >  */
> >  static const u8 twl4030_reg[TWL4030_CACHEREGNUM] = {
> > 0x00, /* this register not used*/
> > -0x93, /* REG_CODEC_MODE(0x1)*/
> > +0x03, /* REG_CODEC_MODE(0x1)*/
> > 0xc3, /* REG_OPTION(0x2)*/
> > 0x00, /* REG_UNKNOWN(0x3)*/
> > 0x00, /* REG_MICBIAS_CTL(0x4)*/
> > -0x24, /* REG_ANAMICL(0x5)*/
> > -0x04, /* REG_ANAMICR(0x6)*/
> > +0xb0, /* REG_ANAMICL(0x5)*/
> > +0x10, /* REG_ANAMICR(0x6)*/
> > 0x0a, /* REG_AVADC_CTL(0x7)*/
> > 0x00, /* REG_ADCMICSEL(0x8)*/
> > 0x00, /* REG_DIGMIXING(0x9)*/
> > @@ -67,22 +72,22 @@
> > 0x00, /* REG_ARX2VTXPGA(0x18)*/
> > 0x00, /* REG_ARXL1_APGA_CTL(0x19)*/
> > 0x00, /* REG_ARXR1_APGA_CTL(0x1A)*/
> > -0x4b, /* REG_ARXL2_APGA_CTL(0x1B)*/
> > -0x4b, /* REG_ARXR2_APGA_CTL(0x1C)*/
> > +0x2b, /* REG_ARXL2_APGA_CTL(0x1B)*/
> > +0x2b, /* REG_ARXR2_APGA_CTL(0x1C)*/
> > 0x00, /* REG_ATX2ARXPGA(0x1D)*/
> > 0x00, /* REG_BT_IF(0x1E)*/
> > 0x00, /* REG_BTPGA(0x1F)*/
> > 0x00, /* REG_BTSTPGA(0x20)*/
> > -0x00, /* REG_EAR_CTL(0x21)*/
> > -0x24, /* REG_HS_SEL(0x22)*/
> > -0x0a, /* REG_HS_GAIN_SET(0x23)*/
> > -0x00, /* REG_HS_POPN_SET(0x24)*/
> > -0x00, /* REG_PREDL_CTL(0x25)*/
> > -0x00, /* REG_PREDR_CTL(0x26)*/
> > -0x00, /* REG_PRECKL_CTL(0x27)*/
> > -0x00, /* REG_PRECKR_CTL(0x28)*/
> > -0x00, /* REG_HFL_CTL(0x29)*/
> > -0x00, /* REG_HFR_CTL(0x2A)*/
> > +0x20, /* REG_EAR_CTL(0x21)*/
> > +0x00, /* REG_HS_SEL(0x22)*/
> > +0x05, /* REG_HS_GAIN_SET(0x23)*/
> > +0x42, /* REG_HS_POPN_SET(0x24)*/
> > +0x20, /* REG_PREDL_CTL(0x25)*/
> > +0x20, /* REG_PREDR_CTL(0x26)*/
> > +0x20, /* REG_PRECKL_CTL(0x27)*/
> > +0x20, /* REG_PRECKR_CTL(0x28)*/
> > +0x1f, /* REG_HFL_CTL(0x29)*/
> > +0x1f, /* REG_HFR_CTL(0x2A)*/
> > 0x00, /* REG_ALC_CTL(0x2B)*/
> > 0x00, /* REG_ALC_SET1(0x2C)*/
> > 0x00, /* REG_ALC_SET2(0x2D)*/
> > @@ -112,9 +117,40 @@
> > 0x00, /* REG_VIBRA_CTL(0x45)*/
> > 0x00, /* REG_VIBRA_SET(0x46)*/
> > 0x00, /* REG_VIBRA_PWM_SET(0x47)*/
> > -0x00, /* REG_ANAMIC_GAIN(0x48)*/
> > +0x24, /* REG_ANAMIC_GAIN(0x48)*

Re: [ANNOUNCE] new PM branch: pm-20081119

[Kevin Hilman]

"Peter Reid" <[EMAIL PROTECTED]> writes:

> Hello kevin,
>Here is what i did to put it to suspend, which fails.
>
>  [EMAIL PROTECTED] echo  mem > /sys/power/state
>  PM: Syncing filesystems ... done.
>  Freezing user space processes ... (elapsed 0.00 seconds) done.
>  Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
>  Suspending console(s)
>  Class driver suspend failed for cpu0
>  PM: Some devices failed to power down

Hi Peter,

Thanks for testing on Beagle.  Do you mind sharing your .config?  And,
would you mind testing with the attached config?  This PM branch will
currently only work with a minimal set of drivers.  Many of the
current drivers will still prevent retention and OFF mode.

Do you have CPUfreq enabled?  I saw this 'class driver suspend'
problem when I had CPUfreq enabled.  This branch doesn't currently
have CPUfreq support, so you can leave that disabled.

I've also noticed problems on ES2 Beagle as well that I haven't
figured out yet.  Namely, I think the bootloader is leaving certain
modules (namely DSS and IVA) in a state that is preventing hitting
retention.

Immediately after boot, the DSS powerdomain is still ON and it should
be in retention, same for IVA but I haven't debugged this further on
Beagle.  The same kernel works on 3430SDP so that's why my hunch
points to the u-boot.

The kernel needs a way to ensure that after booting all the unused
modules are in a state where they are not preventing idle.  Even with
disabled clocks, certain modules can prevent idle.  Paul Walmsley has
written the 'omapdev' layer which will now make it easier to do this
boot-time init, but it is currently not there.  We currently have to
rely on bootloaders doing the right thing.

The beagle bootloader does all sorts of stuff with DSS, MMC, audio
etc.  so it is a likely candidate.

Kevin

>
> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman
> <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> A new PM branch is available named pm-20081119.
>>
>> This is mostly a new set of patches on top of the previous PM branch,
>> rather than a rebase.  We finally found the root cause of some DPLL
>> relocking bugs.  Special thanks to Paul Walmsley and Tero Kristo for
>> debugging and fixing this problem.  Now the DPLL fix that was reverted
>> in the previous PM branch is re-applied as well as some fixes on top
>> of it.  It also has some additional UART fixes, so I think the UART
>> idle work is ready to go to Tony.  Special thanks to Jouni Hogander
>> for the extra testing and fixes here.
>>
>> The shortlog is below[1] and the root of the tree is still
>> v2.6.27-omap1 + T2 power patches from Peter.
>>
>> This has primarily been tested on custom HW since I'm _still_ waiting
>> for my SDP to arrive.  I have boot tested on Beagle, but I think there
>> are still some problems with ES2 silicon.  On my ES2 Beagle, neither
>> DSS or IVA will leave the ON state, even when all clocks in their
>> powerdomains are off.  I have not debugged this further yet.
>>
>> Functionally, this tree is in pretty good shape, so I will do some
>> bugfixes here when necessary, but will now spent some time focusing on
>> getting the patches in this branch merged into linux-omap.
>>
>> Kevin
>>
>>
>> [1] git shortlog:
>>
>> Amit Kucheria (2):
>>  OMAP: PM: Typo fix for clock_allow_idle
>>  HSMMC: Make driver support dynamic idle
>>
>> Jouni Hogander (11):
>>  OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle 
>> loop
>>  OMAP3: Do not set mpu, core, neon states if cpuidle is used
>>  OMAP3: PM: Do not set next states sw to control those is available
>>  OMAP3: PM: Always return value in pwrdms_setup
>>  OMAP3: PM: Fix wrong sequence in suspend.
>>  OMAP3: UART: Make sure that uart clocks are enabled when needed
>>  OMAP3: PM: Check in set_pwrdm_state that target state is supported by 
>> pwrdm v2
>>  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
>>  OMAP: PM: Build fails if PM is not enabled
>>  OMAP2: PM: Fix omap2 build
>>  OMAP: MCSPI: Enable mcspi wake-up
>>
>> Kalle Jokiniemi (4):
>>  OMAP: PM: sysfs interface for enabling voltage off in idle
>>  OMAP3: PM: Fix cpu idle init sequencing
>>  OMAP: SRF: Fixes to shared resource framework (Ver.3)
>>  OMAP3: I2C: Enable I2C wakeups
>>
>> Kevin Hilman (16):
>>  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
>>  OMAP3: PM: Allow UARTs to be unclocked when inactive
>>  8250: Allow platform to register PM hook
>>  8250: when waking, PM hook should be called before accessing port
>>  OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
>>  OMAP3: PM: UART save/restore support for OFF-mode
>>  OMAP2/3: HSMMC: Ensure HSMMC is fully reset on boot
>>  OMAP3: PM: CPUidle: obey enable_off_mode flag
>>  OMAP3: PM: CPUidle: restrict C-states on UART activity
>>  OMAP3: PM: decouple PER and CORE context save and restore
>>  Re

Re: [ANNOUNCE] new PM branch: pm-20081119

[Kevin Hilman]

"Premi, Sanjeev" <[EMAIL PROTECTED]> writes:

> These are my observations on OMAP3EVM:
>
> 1) Very frequently I see these messages:
>
> <4>__ratelimit: 6736 callbacks suppressed
> __ratelimit: 6736 callbacks suppressed
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00e2
> omapfb omapfb: irq error status 00e2
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00e2
> omapfb omapfb: irq error status 00e2
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060

Sanjeev,

For starters can you try with a minimal kernel (no drivers, no
framebuffer, etc.) 

The first goal is to hit retention and off with no drivers than start
moving out to address driver issues from there.

Kevin

> 2) Also:
> # echo mem > /sys/power/state
> <6>PM: Syncing filesystems ...
> PM: Syncing filesystems ...
> done.
> done.
> Freezing user space processes ... Freezing user space processes ... (elapsed 
> 0.00 seconds) (elapsed 0.00 seconds) done.
> done.
> Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... 
> (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
> done.
>
> Suspending console(s) (use no_console_suspend to debug)
> Suspending console(s) (use no_console_suspend to debug)
> <3>omapfb omapfb: timeout waiting for FRAME DONE
>
> However, I the "resume" doesn't happen.
> Trying to debug further.
>
> Best regards,
> Sanjeev
>
>> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman 
>> <[EMAIL PROTECTED]> wrote:
>> > Hello,
>> >
>> > A new PM branch is available named pm-20081119.
>> >
>> > This is mostly a new set of patches on top of the previous 
>> PM branch, 
>> > rather than a rebase.  We finally found the root cause of some DPLL 
>> > relocking bugs.  Special thanks to Paul Walmsley and Tero 
>> Kristo for 
>> > debugging and fixing this problem.  Now the DPLL fix that 
>> was reverted 
>> > in the previous PM branch is re-applied as well as some 
>> fixes on top 
>> > of it.  It also has some additional UART fixes, so I think the UART 
>> > idle work is ready to go to Tony.  Special thanks to Jouni Hogander 
>> > for the extra testing and fixes here.
>> >
>> > The shortlog is below[1] and the root of the tree is still
>> > v2.6.27-omap1 + T2 power patches from Peter.
>> >
>> > This has primarily been tested on custom HW since I'm 
>> _still_ waiting 
>> > for my SDP to arrive.  I have boot tested on Beagle, but I 
>> think there 
>> > are still some problems with ES2 silicon.  On my ES2 
>> Beagle, neither 
>> > DSS or IVA will leave the ON state, even when all clocks in their 
>> > powerdomains are off.  I have not debugged this further yet.
>> >
>> > Functionally, this tree is in pretty good shape, so I will do some 
>> > bugfixes here when necessary, but will now spent some time 
>> focusing on 
>> > getting the patches in this branch merged into linux-omap.
>> >
>> > Kevin
>> >
>> >
>> > [1] git shortlog:
>> >
>> > Amit Kucheria (2):
>> >  OMAP: PM: Typo fix for clock_allow_idle
>> >  HSMMC: Make driver support dynamic idle
>> >
>> > Jouni Hogander (11):
>> >  OMAP3: PM: Use pwrdm_set_next_pwrst instead of 
>> set_pwrdm_state in idle loop
>> >  OMAP3: Do not set mpu, core, neon states if cpuidle is used
>> >  OMAP3: PM: Do not set next states sw to control those 
>> is available
>> >  OMAP3: PM: Always return value in pwrdms_setup
>> >  OMAP3: PM: Fix wrong sequence in suspend.
>> >  OMAP3: UART: Make sure that uart clocks are enabled when needed
>> >  OMAP3: PM: Check in set_pwrdm_state that target state 
>> is supported by pwrdm v2
>> >  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
>> >  OMAP: PM: Build fails if PM is not enabled
>> >  OMAP2: PM: Fix omap2 build
>> >  OMAP: MCSPI: Enable mcspi wake-up
>> >
>> > Kalle Jokiniemi (4):
>> >  OMAP: PM: sysfs interface for enabling voltage off in idle
>> >  OMAP3: PM: Fix cpu idle init sequencing
>> >  OMAP: SRF: Fixes to shared resource framework (Ver.3)
>> >  OMAP3: I2C: Enable I2C wakeups
>> >
>> > Kevin Hilman (16):
>> >  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
>> >  OMAP3: PM: Allow UARTs to be unclocked when inactive
>> >  8250: Allow platform to register PM hook
>> >  8250: when waking, PM hook should be called before 
>> accessing port
>> >  OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
>> >  OMAP3: PM: UART save/restore support for OFF-mode
>> >   

Re: [PATCH PM-20081119] OMAP: PM: Check both, IOPAD and UART wakeup always

[Kevin Hilman]

Jouni Hogander <[EMAIL PROTECTED]> writes:

> Uart RX might not always generate IOPAD wake-up. E.g. IOPAD is not
> enabled or core was not in sleep state.
>
> Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>

Thanks, applying to pm-20081119.

Kevin

>  arch/arm/mach-omap2/serial.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 745ae5c..8d2f0b1 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -281,7 +281,7 @@ void omap_uart_resume_idle(int num)
>   }
>  
>   /* Check for normal UART wakeup */
> - else if (__raw_readl(uart->wk_st) & uart->wk_mask)
> + if (__raw_readl(uart->wk_st) & uart->wk_mask)
>   omap_uart_block_sleep(uart);
>  
>   return;
> -- 
> 1.6.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TWL4030 asoc kcontrols and widgets

[Felipe Balbi]

On Thu, Nov 20, 2008 at 09:32:07AM -0800, Tony Lindgren wrote:
> * Felipe Balbi <[EMAIL PROTECTED]> [081120 02:55]:
> > This list has been moved to linux-omap@vger.kernel.org
> > 
> > Please, keep that in Cc, also for ASoC development, send it also to the
> > proper alsa mailing list [EMAIL PROTECTED]
> > 
> > Tony, I think you should apply this patch in mainline tree:
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8dae455..54c8e90 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4010,6 +4010,13 @@ P:   Alex Dubov
> >  M: [EMAIL PROTECTED]
> >  S: Maintained
> > 
> > +TI OMAP
> > +P: Tony Lindgren
> > +M: [EMAIL PROTECTED]
> > +L: linux-omap@vger.kernel.org
> > +T: git kernel.org:/pub/scm/linux/tmlind/linux-omap-2.6.git
> > +S: Maintained
> > +
> >  TI OMAP MMC INTERFACE DRIVER
> >  P: Carlos Aguiar, Anderson Briglia and Syed Khasim
> >  M: linux-omap@vger.kernel.org
> 
> 
> Yeah sure. Let's also add maintainers for omap subsystems that have
> maintainers while we're at it.

sounds good. At least mmc is already there.

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

Re: [ANNOUNCE] new PM branch: pm-20081119

[Kevin Hilman]

Kevin Hilman <[EMAIL PROTECTED]> writes:

> "Peter Reid" <[EMAIL PROTECTED]> writes:
>
>> Hello kevin,
>>Here is what i did to put it to suspend, which fails.
>>
>>  [EMAIL PROTECTED] echo  mem > /sys/power/state
>>  PM: Syncing filesystems ... done.
>>  Freezing user space processes ... (elapsed 0.00 seconds) done.
>>  Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
>>  Suspending console(s)
>>  Class driver suspend failed for cpu0
>>  PM: Some devices failed to power down
>
> Hi Peter,
>
> Thanks for testing on Beagle.  Do you mind sharing your .config?  And,
> would you mind testing with the attached config?  This PM branch will
> currently only work with a minimal set of drivers.  Many of the
> current drivers will still prevent retention and OFF mode.

This time, with the .config attached.


> Do you have CPUfreq enabled?  I saw this 'class driver suspend'
> problem when I had CPUfreq enabled.  This branch doesn't currently
> have CPUfreq support, so you can leave that disabled.
>
> I've also noticed problems on ES2 Beagle as well that I haven't
> figured out yet.  Namely, I think the bootloader is leaving certain
> modules (namely DSS and IVA) in a state that is preventing hitting
> retention.
>
> Immediately after boot, the DSS powerdomain is still ON and it should
> be in retention, same for IVA but I haven't debugged this further on
> Beagle.  The same kernel works on 3430SDP so that's why my hunch
> points to the u-boot.
>
> The kernel needs a way to ensure that after booting all the unused
> modules are in a state where they are not preventing idle.  Even with
> disabled clocks, certain modules can prevent idle.  Paul Walmsley has
> written the 'omapdev' layer which will now make it easier to do this
> boot-time init, but it is currently not there.  We currently have to
> rely on bootloaders doing the right thing.
>
> The beagle bootloader does all sorts of stuff with DSS, MMC, audio
> etc.  so it is a likely candidate.
>
> Kevin
>
>>
>> On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman
>> <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>>
>>> A new PM branch is available named pm-20081119.
>>>
>>> This is mostly a new set of patches on top of the previous PM branch,
>>> rather than a rebase.  We finally found the root cause of some DPLL
>>> relocking bugs.  Special thanks to Paul Walmsley and Tero Kristo for
>>> debugging and fixing this problem.  Now the DPLL fix that was reverted
>>> in the previous PM branch is re-applied as well as some fixes on top
>>> of it.  It also has some additional UART fixes, so I think the UART
>>> idle work is ready to go to Tony.  Special thanks to Jouni Hogander
>>> for the extra testing and fixes here.
>>>
>>> The shortlog is below[1] and the root of the tree is still
>>> v2.6.27-omap1 + T2 power patches from Peter.
>>>
>>> This has primarily been tested on custom HW since I'm _still_ waiting
>>> for my SDP to arrive.  I have boot tested on Beagle, but I think there
>>> are still some problems with ES2 silicon.  On my ES2 Beagle, neither
>>> DSS or IVA will leave the ON state, even when all clocks in their
>>> powerdomains are off.  I have not debugged this further yet.
>>>
>>> Functionally, this tree is in pretty good shape, so I will do some
>>> bugfixes here when necessary, but will now spent some time focusing on
>>> getting the patches in this branch merged into linux-omap.
>>>
>>> Kevin
>>>
>>>
>>> [1] git shortlog:
>>>
>>> Amit Kucheria (2):
>>>  OMAP: PM: Typo fix for clock_allow_idle
>>>  HSMMC: Make driver support dynamic idle
>>>
>>> Jouni Hogander (11):
>>>  OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle 
>>> loop
>>>  OMAP3: Do not set mpu, core, neon states if cpuidle is used
>>>  OMAP3: PM: Do not set next states sw to control those is available
>>>  OMAP3: PM: Always return value in pwrdms_setup
>>>  OMAP3: PM: Fix wrong sequence in suspend.
>>>  OMAP3: UART: Make sure that uart clocks are enabled when needed
>>>  OMAP3: PM: Check in set_pwrdm_state that target state is supported by 
>>> pwrdm v2
>>>  OMAP3: PM: Do not build suspend code if SUSPEND is not enabled
>>>  OMAP: PM: Build fails if PM is not enabled
>>>  OMAP2: PM: Fix omap2 build
>>>  OMAP: MCSPI: Enable mcspi wake-up
>>>
>>> Kalle Jokiniemi (4):
>>>  OMAP: PM: sysfs interface for enabling voltage off in idle
>>>  OMAP3: PM: Fix cpu idle init sequencing
>>>  OMAP: SRF: Fixes to shared resource framework (Ver.3)
>>>  OMAP3: I2C: Enable I2C wakeups
>>>
>>> Kevin Hilman (16):
>>>  OMAP3: PM: Add wake-up bit defintiions for CONTROL_PADCONF_X
>>>  OMAP3: PM: Allow UARTs to be unclocked when inactive
>>>  8250: Allow platform to register PM hook
>>>  8250: when waking, PM hook should be called before accessing port
>>>  OMAP3: PM: UART: Add 8250 UART PM hook for suspend/resume
>>>  OMAP3: PM: UART save/restore support for OFF-mode
>>>  OMAP2/3: HSMMC: Ensure HS

Re: [ANNOUNCE] new PM branch: pm-20081119

[Koen Kooi]

Op 20 nov 2008, om 18:38 heeft Kevin Hilman het volgende geschreven:


"Peter Reid" <[EMAIL PROTECTED]> writes:


Hello kevin,
  Here is what i did to put it to suspend, which fails.

[EMAIL PROTECTED] echo  mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s)
Class driver suspend failed for cpu0
PM: Some devices failed to power down


Hi Peter,

Thanks for testing on Beagle.  Do you mind sharing your .config?  And,
would you mind testing with the attached config?  This PM branch will
currently only work with a minimal set of drivers.  Many of the
current drivers will still prevent retention and OFF mode.

Do you have CPUfreq enabled?  I saw this 'class driver suspend'
problem when I had CPUfreq enabled.  This branch doesn't currently
have CPUfreq support, so you can leave that disabled.

I've also noticed problems on ES2 Beagle as well that I haven't
figured out yet.  Namely, I think the bootloader is leaving certain
modules (namely DSS and IVA) in a state that is preventing hitting
retention.

Immediately after boot, the DSS powerdomain is still ON and it should
be in retention, same for IVA but I haven't debugged this further on
Beagle.  The same kernel works on 3430SDP so that's why my hunch
points to the u-boot.

The kernel needs a way to ensure that after booting all the unused
modules are in a state where they are not preventing idle.  Even with
disabled clocks, certain modules can prevent idle.  Paul Walmsley has
written the 'omapdev' layer which will now make it easier to do this
boot-time init, but it is currently not there.  We currently have to
rely on bootloaders doing the right thing.

The beagle bootloader does all sorts of stuff with DSS, MMC, audio
etc.  so it is a likely candidate.


Only the TI version does that, you'd be better of using the 'omap3'  
branch of the u-boot arm git, or Steve Sakomans git tree (which is  
where the upstream patches originate from).
I don't know if that version fixed DSS and IVA, but it is a lot  
cleaner and saves a considerable amount of boot time :) A binary is  
located at:


http://www.angstrom-distribution.org/demo/beagleboard/u-boot.bin

That binary also contains a fix for the 'l1neon' problem where the  
optimized version of ffmpeg or mplayer would crash under heavy load.


regards,

Koen




PGP.sig
Description: This is a digitally signed message part

(non-hs)mmc vs lockdep

[David Brownell]

On Thursday 20 November 2008, Felipe Balbi wrote:
> > >  TI OMAP MMC INTERFACE DRIVER
> > >  P:     Carlos Aguiar, Anderson Briglia and Syed Khasim
> > >  M:     linux-omap@vger.kernel.org
> > 
> > 
> > Yeah sure. Let's also add maintainers for omap subsystems that have
> > maintainers while we're at it.
> 
> sounds good. At least mmc is already there.

So, who's going to fix the bug with the non-highspeed MMC controller
driver whereby it breaks with LOCKDEP enabled?

The "BUG_ON(irqs_disabled());" in mmc_omap_start_request() triggers,
since something inside the latest ARM MM code assumes it's never called
with IRQs blocked ... a regression was introduced at some point.  The
same failure is seen in some other MMC controller drivers.

- Dave


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

Re: (non-hs)mmc vs lockdep

[Felipe Balbi]

On Thu, Nov 20, 2008 at 10:56:28AM -0800, David Brownell wrote:
> On Thursday 20 November 2008, Felipe Balbi wrote:
> > > >  TI OMAP MMC INTERFACE DRIVER
> > > >  P:     Carlos Aguiar, Anderson Briglia and Syed Khasim
> > > >  M:     linux-omap@vger.kernel.org
> > > 
> > > 
> > > Yeah sure. Let's also add maintainers for omap subsystems that have
> > > maintainers while we're at it.
> > 
> > sounds good. At least mmc is already there.
> 
> So, who's going to fix the bug with the non-highspeed MMC controller
> driver whereby it breaks with LOCKDEP enabled?
> 
> The "BUG_ON(irqs_disabled());" in mmc_omap_start_request() triggers,
> since something inside the latest ARM MM code assumes it's never called
> with IRQs blocked ... a regression was introduced at some point.  The
> same failure is seen in some other MMC controller drivers.

Well, I haven't seen patches from none of the three maintainers for
quite a while. Maybe someone at TI could take over the driver(s) ??

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

Re: [PATCH] OMAP: Switch to gpio_direction_output in OMAP_LDP.

[David Brownell]

On Thursday 20 November 2008, Stanley.Miao wrote:
> -   omap_set_gpio_direction(LCD_PANEL_QVGA_GPIO, 0);
> -   omap_set_gpio_direction(LCD_PANEL_RESET_GPIO, 0);
> gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
> gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);

Nothing does

gpio_request(LCD_PANEL_QVGA_GPIO, "qvga something");
gpio_request(LCD_PANEL_RESET_GPIO, "lcd reset");

And by removing the initial direction setting call (above),
behavior of at least the reset line changes:  it's no longer
pullsed low.

It'd be better to change the direction setting calls above
(setting an initial low value), and then make the calls
below use gpio_set_value().

  
>  #ifdef CONFIG_FB_OMAP_LCD_VGA
> -   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 0);
> +   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
>  #else
> -   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 1);
> +   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
>  #endif
> -   omap_set_gpio_dataout(LCD_PANEL_RESET_GPIO, 1);
> +   gpio_direction_output(LCD_PANEL_RESET_GPIO, 1);

Use gpio_set_value() to replace omap_set_gpio_dataout(), except
when initializing.  The reset pin *was* being toggled...

- Dave

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

Question regarding OMAP NAND driver read_buf16() function

[Peter Barada]

In drivers/mtd/nand/omap2.c, I see the call to __raw_readsl:

__raw_readsl(nand->IO_ADDR_R, buf, len / 2);

Since len is in bytes (from the comment), shouldn't this either be:

__raw_readsl(nand->IO_ADDR_R, buf, len / 4);

or:

__raw_readsw(nand->IO_ADDR_R, buf, len / 2);

-- 
Peter Barada // senior software engineer
 
LOGIC // embedded product solutions
411 Washington Ave. N. Suite 400
Minneapolis, MN 55401
M // 617.513.5874
 
[EMAIL PROTECTED]
www.logicpd.com

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

Re: Question regarding OMAP NAND driver read_buf16() function

[David Brownell]

On Thursday 20 November 2008, Peter Barada wrote:
> In drivers/mtd/nand/omap2.c, I see the call to __raw_readsl:
> 
> __raw_readsl(nand->IO_ADDR_R, buf, len / 2);
> 
> Since len is in bytes (from the comment), shouldn't this either be:
> 
> __raw_readsl(nand->IO_ADDR_R, buf, len / 4);
> 
> or:
> 
> __raw_readsw(nand->IO_ADDR_R, buf, len / 2);
> 

Current GIT has the latter.  Upgrde your kernel.  ;)


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

Re: OOPS in OMAP 1-wire driver

[Madhusudhan Chikkature]

Hi,

I have not seen this crash before. If no slave modules are selected I see a
message that tells with a family ID not registered. But not a crash.

Regards,
Madhu


> I'm not sure this is the right place for 1-wire stuff but I remember
> seeing patches for the OMAP 1w driver so maybe someone is interested.
>
> Running git head on OMAP2430 SDP. Only OMAP master is built into the
> kernel, no slave modules.
> This happens on boot.
>
> Driver for 1-wire Dallas network protocol.
> omap_hdq omap_hdq.0: OMAP HDQ Hardware Rev 0.3. Driver in Interrupt mode
> Unable to handle kernel NULL pointer dereference at virtual address 00f0
> pgd = c0004000
> [00f0] *pgd=
> Internal error: Oops: 0 [#1] PREEMPT
> Modules linked in:
> CPU: 0Not tainted  (2.6.28-rc5-omap1 #21)
> PC is at 0xf0
> LR is at omap_w1_search_bus+0x64/0x70
> pc : [<00f0>]lr : []psr: 6013
> sp : c7957f68  ip : c7957f68  fp : c7957f8c
> r10:   r9 :   r8 : 
> r7 : 00f0  r6 : c7829160  r5 :   r4 : 0001
> r3 : 3d00  r2 : 0001  r1 : 3d00  r0 : c7829160
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 00c5387f  Table: 80004000  DAC: 0017
> Process w1_bus_master1 (pid: 263, stack limit = 0xc7956260)
> Stack: (0xc7957f68 to 0xc7958000)
> 7f60:   0001  c01af304 00f0 c7956000 03e8
> 7f80: c7957fa4 c7957f90 c01aed58 c01af310 c7943a00 c7943a00 c7957fbc c7957fa8
> 7fa0: c01ad880 c01aed20 c7943a68 c7943a00 c7957fdc c7957fc0 c01ad958 c01ad830
> 7fc0: c7943a00 c01ad8fc   c7957ff4 c7957fe0 c0059fd0 c01ad908
> 7fe0:    c7957ff8 c0048104 c0059f88 ff00ff00 ff00ff00
> Backtrace:
> [] (omap_w1_search_bus+0x0/0x70) from []
> (w1_search_devices+0x44/0x50)
>  r7:03e8 r6:c7956000 r5:00f0 r4:c01af304
> [] (w1_search_devices+0x0/0x50) from []
> (w1_search_process+0x5c/0xd8)
>  r5:c7943a00 r4:c7943a00
> [] (w1_search_process+0x0/0xd8) from []
> (w1_process+0x5c/0xe0)
>  r5:c7943a00 r4:c7943a68
> [] (w1_process+0x0/0xe0) from [] (kthread+0x54/0x80)
>  r7: r6: r5:c01ad8fc r4:c7943a00
> [] (kthread+0x0/0x80) from [] (do_exit+0x0/0x784)
>  r5: r4:
> Code: bad PC value.
>
>
> --
> Madness takes it's toll. Please have exact change.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix section mismatch warning.

[David Brownell]

On Thursday 20 November 2008, Felipe Balbi wrote:
> > > > -static struct twl4030_platform_data omap3evm_twldata = {
> > > > +static struct twl4030_platform_data __initdata omap3evm_twldata = {
> > > 
> > > ... and that's incorrect in any case, since that data is used 
> > > by probe() code that's doesn't sit in an init section.
> 
> __initdata_or_module would do the trick for static and dynamically
> linked modules.

Not in this case.  Recall there are several drivers who
would all need to be using non-hotpluggable structures ...
but since the root of their tree must be hotpluggable,
they can't work that way.


> When building it statically, we'd get a bit of 
> shrinkage, right ?

Can't work that way.
 


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

[PATCH] ALSA: SoC: Add support for TI SDP3430

[mesak82]

From: Misael Lopez Cruz <[EMAIL PROTECTED]>

This patch add ASoC support for TI SDP3430. It's based on Gumstix
Overo SoC code by Steve Sakoman.

Signed-off-by: Misael Lopez Cruz <[EMAIL PROTECTED]>
---
 sound/soc/omap/Kconfig   |7 ++
 sound/soc/omap/Makefile  |2 +
 sound/soc/omap/sdp3430.c |  152 ++
 3 files changed, 161 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/omap/sdp3430.c

diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index d7b8939..890b1ed 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -22,3 +22,10 @@ config SND_OMAP_SOC_OVERO
help
  Say Y if you want to add support for SoC audio on the Gumstix Overo.
 
+config SND_OMAP_SOC_SDP3430
+   tristate "SoC Audio support for Texas Instruments SDP3430"
+   depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
+   select SND_OMAP_SOC_MCBSP
+   select SND_SOC_TWL4030
+   help
+ Say Y if you want to add support for SoC audio on Texas Instruments 
SDP3430.
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index b96b97b..c21426b 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -8,7 +8,9 @@ obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
 # OMAP Machine Support
 snd-soc-n810-objs := n810.o
 snd-soc-overo-objs := overo.o
+snd-soc-sdp3430-objs := sdp3430.o
 
 obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
 obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
+obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
 
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
new file mode 100644
index 000..84ad3f9
--- /dev/null
+++ b/sound/soc/omap/sdp3430.c
@@ -0,0 +1,152 @@
+/*
+ * sdp3430.c  --  SoC audio for TI OMAP3430 SDP
+ *
+ * Author: Misael Lopez Cruz <[EMAIL PROTECTED]>
+ *
+ * Based on:
+ * Author: Steve Sakoman <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "omap-mcbsp.h"
+#include "omap-pcm.h"
+#include "../codecs/twl4030.h"
+
+static int sdp3430_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *codec_dai = rtd->dai->codec_dai;
+   struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+   int ret;
+
+   /* Set codec DAI configuration */
+   ret = snd_soc_dai_set_fmt(codec_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set codec DAI configuration\n");
+   return ret;
+   }
+
+   /* Set cpu DAI configuration */
+   ret = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set cpu DAI configuration\n");
+   return ret;
+   }
+
+   /* Set the codec system clock for DAC and ADC */
+   ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
+   SND_SOC_CLOCK_IN);
+   if (ret < 0) {
+   printk(KERN_ERR "can't set codec system clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops sdp3430_ops = {
+   .hw_params = sdp3430_hw_params,
+};
+
+/* Digital audio interface glue - connects codec <--> CPU */
+static struct snd_soc_dai_link sdp3430_dai = {
+   .name = "TWL4030",
+   .stream_name = "TWL4030",
+   .cpu_dai = &omap_mcbsp_dai[0],
+   .codec_dai = &twl4030_dai,
+   .ops = &sdp3430_ops,
+};
+
+/* Audio machine driver */
+static struct snd_soc_machine snd_soc_machine_sdp3430 = {
+   .name = "SDP3430",
+   .dai_link = &sdp3430_dai,
+   .num_links = 1,
+};
+
+/* Audio subsystem */
+static struct snd_soc_device sdp3430_snd_devdata = {
+   .machine = &snd_soc_machine_sdp3430,
+   .platform = &omap_soc_platform,
+   .codec_dev = &soc_codec_dev_twl4030,
+};
+
+static struct platform_devi

[PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and RCCR for OMAP2430/34xx

[mesak82]

From: Misael Lopez Cruz <[EMAIL PROTECTED]>

This patch fixes handling of XCCR and RCCR registers of McBSP for OMAP2430
and 34xx platforms. It also fixes OMAP McBSP DAI driver which was setting
those registers to 0, as they were not initialized.

Signed-off-by: Misael Lopez Cruz <[EMAIL PROTECTED]>
---
 arch/arm/plat-omap/include/mach/mcbsp.h |7 +++
 arch/arm/plat-omap/mcbsp.c  |1 +
 sound/soc/omap/omap-mcbsp.c |4 
 3 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h 
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 3e38575..faa9164 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -245,11 +245,16 @@
 #define XPBBLK(value)  ((value)<<7)/* Bits 7:8 */
 
 /*** McBSP XCCR bit definitions */
+#define EXTCLKGATE 0x8000
+#define PPCONNECT  0x4000
+#define DXENDLY(value) ((value)<<12)   /* Bits 12:13 */
+#define XFULL_CYCLE0x0800
 #define DILB   0x0020
 #define XDMAEN 0x0008
 #define XDISABLE   0x0001
 
 /** McBSP RCCR bit definitions */
+#define RFULL_CYCLE0x0800
 #define RDMAEN 0x0008
 #define RDISABLE   0x0001
 
@@ -403,8 +408,10 @@ struct omap_mcbsp_reg_cfg {
u16 rcerh;
u16 xcerg;
u16 xcerh;
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
u16 xccr;
u16 rccr;
+#endif
 };
 
 typedef enum {
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 906e8e3..2b29033 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -174,6 +174,7 @@ void omap_mcbsp_config(unsigned int id, const struct 
omap_mcbsp_reg_cfg *config)
OMAP_MCBSP_WRITE(io_base, MCR2, config->mcr2);
OMAP_MCBSP_WRITE(io_base, MCR1, config->mcr1);
OMAP_MCBSP_WRITE(io_base, PCR0, config->pcr0);
+   /* Write to xccr and rccr only for omap2430/34xx */
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
if (mcbsp->pdata->ops->config)
mcbsp->pdata->ops->config(id, config);
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 3a4cc4b..51a9313 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -285,6 +285,10 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai 
*cpu_dai,
regs->spcr1 |= RINTM(3);
regs->rcr2  |= RFIG;
regs->xcr2  |= XFIG;
+   if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+   regs->xccr = DXENDLY(1) | XDMAEN;
+   regs->rccr = RFULL_CYCLE | RDMAEN;
+   }
 
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
-- 
1.5.6.3

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

Re: [PATCH] ALSA: SoC: Add support for TI SDP3430

[David Brownell]

On Thursday 20 November 2008, [EMAIL PROTECTED] wrote:
> +   tristate "SoC Audio support for Texas Instruments SDP3430"
> +   depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
> +   select SND_OMAP_SOC_MCBSP
> +   select SND_SOC_TWL4030

depends also on TWL4030_CORE, yes?

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

RE: [PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and RCCR for OMAP2430/34xx

[Gadiyar, Anand]

> -Original Message-
> From: [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> 
> From: Misael Lopez Cruz <[EMAIL PROTECTED]>
> 
> This patch fixes handling of XCCR and RCCR registers of McBSP for OMAP2430
> and 34xx platforms. It also fixes OMAP McBSP DAI driver which was setting
> those registers to 0, as they were not initialized.
> 
> Signed-off-by: Misael Lopez Cruz <[EMAIL PROTECTED]>
> ---
>  arch/arm/plat-omap/include/mach/mcbsp.h |7 +++
>  arch/arm/plat-omap/mcbsp.c  |1 +
>  sound/soc/omap/omap-mcbsp.c |4 
>  3 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h 
> b/arch/arm/plat-omap/include/mach/mcbsp.h
> index 3e38575..faa9164 100644
> --- a/arch/arm/plat-omap/include/mach/mcbsp.h
> +++ b/arch/arm/plat-omap/include/mach/mcbsp.h
> @@ -245,11 +245,16 @@
>  #define XPBBLK(value)((value)<<7)/* Bits 7:8 */
>  
>  /*** McBSP XCCR bit definitions 
> */
> +#define EXTCLKGATE   0x8000
> +#define PPCONNECT0x4000
> +#define DXENDLY(value)   ((value)<<12)   /* Bits 12:13 */
> +#define XFULL_CYCLE  0x0800
>  #define DILB 0x0020
>  #define XDMAEN   0x0008
>  #define XDISABLE 0x0001
>  
>  /** McBSP RCCR bit definitions */
> +#define RFULL_CYCLE  0x0800
>  #define RDMAEN   0x0008
>  #define RDISABLE 0x0001
>  
> @@ -403,8 +408,10 @@ struct omap_mcbsp_reg_cfg {
>   u16 rcerh;
>   u16 xcerg;
>   u16 xcerh;
> +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
>   u16 xccr;
>   u16 rccr;
> +#endif
>  };

Won't this cause a compilation break on non-2430/34xx platforms
because you refer to these variables below?

>  
>  typedef enum {
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
> index 906e8e3..2b29033 100644
> --- a/arch/arm/plat-omap/mcbsp.c
> +++ b/arch/arm/plat-omap/mcbsp.c
> @@ -174,6 +174,7 @@ void omap_mcbsp_config(unsigned int id, 
> const struct omap_mcbsp_reg_cfg *config)
>   OMAP_MCBSP_WRITE(io_base, MCR2, config->mcr2);
>   OMAP_MCBSP_WRITE(io_base, MCR1, config->mcr1);
>   OMAP_MCBSP_WRITE(io_base, PCR0, config->pcr0);
> + /* Write to xccr and rccr only for omap2430/34xx */
>   if (cpu_is_omap2430() || cpu_is_omap34xx()) {
>   if (mcbsp->pdata->ops->config)
>   mcbsp->pdata->ops->config(id, config);
> diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> index 3a4cc4b..51a9313 100644
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -285,6 +285,10 @@ static int 
> omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai,
>   regs->spcr1 |= RINTM(3);
>   regs->rcr2  |= RFIG;
>   regs->xcr2  |= XFIG;
> + if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> + regs->xccr = DXENDLY(1) | XDMAEN;
> + regs->rccr = RFULL_CYCLE | RDMAEN;
> + }
>  
>   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>   case SND_SOC_DAIFMT_I2S:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] ALSA: SoC: Add support for TI SDP3430

[Lopez Cruz, Misael]

> On Thursday 20 November 2008, [EMAIL PROTECTED] wrote:
> > +   tristate "SoC Audio support for Texas Instruments SDP3430"
> > +   depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
> > +   select SND_OMAP_SOC_MCBSP
> > +   select SND_SOC_TWL4030
> 
> depends also on TWL4030_CORE, yes?
The machine driver itself doesn't depend on TWL4030_CORE, but TWL4030 SoC codec 
driver does (sound/soc/codecs/Kconfig)

config SND_SOC_TWL4030
tristate
depends on TWL4030_CORE

Although that dependency is overridden by _select_ statement.

What should be the best way to handle this dependency? Directly in kconfig 
entry for each TWL4030-related machine driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and RCCR for OMAP2430/34xx

[Misael Lopez]

> > @@ -403,8 +408,10 @@ struct omap_mcbsp_reg_cfg {
> > u16 rcerh;
> > u16 xcerg;
> > u16 xcerh;
> > +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
> > u16 xccr;
> > u16 rccr;
> > +#endif
> >  };
>
> Won't this cause a compilation break on non-2430/34xx platforms
> because you refer to these variables below?
True... I didn't consider that. Then for non-2430/34xx platforms,
having those registers in the structure but avoiding to write to them
is enough, correct? or any other alternative?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and RCCR for OMAP2430/34xx

[shekhar, chandra]

- Original Message - 
From: "Misael Lopez" <[EMAIL PROTECTED]>

To: "Gadiyar, Anand" <[EMAIL PROTECTED]>
Cc: ; "Pandita, Vikram" <[EMAIL PROTECTED]>
Sent: Friday, November 21, 2008 11:55 AM
Subject: Re: [PATCH][OMAPZOOM] OMAP3: Fix handling of McBSP registers XCCR and 
RCCR for OMAP2430/34xx




> @@ -403,8 +408,10 @@ struct omap_mcbsp_reg_cfg {
>  u16 rcerh;
>  u16 xcerg;
>  u16 xcerh;
> +#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
>  u16 xccr;
>  u16 rccr;
> +#endif
>  };

Won't this cause a compilation break on non-2430/34xx platforms
because you refer to these variables below?

True... I didn't consider that. Then for non-2430/34xx platforms,
having those registers in the structure but avoiding to write to them
is enough, correct? or any other alternative?


Since you  write those registers conditionally for 2430/34xx, i guess removing 
ifdef should do..



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [ANNOUNCE] new PM branch: pm-20081119

[Kalle Jokiniemi]

On to, 2008-11-20 at 19:43 +0530, ext Premi, Sanjeev wrote:
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Reid
> > Sent: Thursday, November 20, 2008 2:16 PM
> > To: Kevin Hilman
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [ANNOUNCE] new PM branch: pm-20081119
> > 
> > Hello kevin,
> >Here is what i did to put it to suspend, which fails.
> > 
> >  [EMAIL PROTECTED] echo  mem > /sys/power/state
> >  PM: Syncing filesystems ... done.
> >  Freezing user space processes ... (elapsed 0.00 seconds) done.
> >  Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> >  Suspending console(s)
> >  Class driver suspend failed for cpu0
> >  PM: Some devices failed to power down
> > 
> > Regards,
> > Reid.
> These are my observations on OMAP3EVM:
> 
> 1) Very frequently I see these messages:
> 
> <4>__ratelimit: 6736 callbacks suppressed
> __ratelimit: 6736 callbacks suppressed
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00e2
> omapfb omapfb: irq error status 00e2
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060
> <3>omapfb omapfb: irq error status 00e2
> omapfb omapfb: irq error status 00e2
> <3>omapfb omapfb: irq error status 00c2
> omapfb omapfb: irq error status 00c2
> <3>omapfb omapfb: irq error status 0060
> omapfb omapfb: irq error status 0060

The interrupts we see here mean that GFX FIFO has underflown. This is
because cpu idle issues WFI very frequently making the DSS also stop
it's clocks when idle. Problem is that waking up the DSS seems to take
longer than the FIFO lasts.

You can fix this by setting the fifo thresholds to very high. TI uses
1020 for high thresholds and 956 for low thresholds in their kernel.
Maximum is 1023. 

Here's a patch by Imre, that worked for us.

- Kalle



>From d23ce521f95671f1b012b8542e88100d4a143771 Mon Sep 17 00:00:00 2001
From: Imre Deak <[EMAIL PROTECTED]>
Date: Tue, 11 Nov 2008 13:43:39 +0200
Subject: [PATCH] ARM: OMAP: OMAPFB: Adjust DMA FIFO thresholds for power
save mode

DMA FIFO underflow error occures if power save mode is enabled, try
to tackle this by setting a higher DMA FIFO threshold values. Also
the maximum value is FIFO size - 1 not FIFO size, so fix this.

Problem report and solution from Kalle Jokiniemi.

Signed-off-by: Imre Deak <[EMAIL PROTECTED]>
---
 drivers/video/omap/dispc.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index da827b1..b4a1542 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -296,15 +296,10 @@ static void setup_plane_fifo(int plane, int
ext_mode)
BUG_ON(plane > 2);
 
l = dispc_read_reg(fsz_reg[plane]);
-   l &= FLD_MASK(0, 11);
-   if (ext_mode) {
-   low = l * 3 / 4;
-   high = l;
-   } else {
-   low = l / 4;
-   high = l * 3 / 4;
-   }
-   MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 12) | FLD_MASK(0, 12),
+   l &= FLD_MASK(0, 9);
+   low = l * 3 / 4;
+   high = l - 1;
+   MOD_REG_FLD(ftrs_reg[plane], FLD_MASK(16, 9) | FLD_MASK(0, 9),
(high << 16) | low);
 }
 
-- 
1.5.4.3


> 
> 2) Also:
> # echo mem > /sys/power/state
> <6>PM: Syncing filesystems ...
> PM: Syncing filesystems ...
> done.
> done.
> Freezing user space processes ... Freezing user space processes ... (elapsed 
> 0.00 seconds) (elapsed 0.00 seconds) done.
> done.
> Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... 
> (elapsed 0.00 seconds) (elapsed 0.00 seconds) done.
> done.
> 
> Suspending console(s) (use no_console_suspend to debug)
> Suspending console(s) (use no_console_suspend to debug)
> <3>omapfb omapfb: timeout waiting for FRAME DONE
> 
> However, I the "resume" doesn't happen.
> Trying to debug further.
> 
> Best regards,
> Sanjeev
> 
> > On Thu, Nov 20, 2008 at 6:23 AM, Kevin Hilman 
> > <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > A new PM branch is available named pm-20081119.
> > >
> > > This is mostly a new set of patches on top of the previous 
> > PM branch, 
> > > rather than a rebase.  We finally found the root cause of some DPLL 
> > > relocking bugs.  Special thanks to Paul Walmsley and Tero 
> > Kristo for 
> > > debugging and fixing this problem.  Now the DPLL fix that 
> > was reverted 
> > > in the previous PM branch is re-applied as well as some 
> > fixes on top 
> > > of it.  It also has some additional UART fixes, so I think the UART 
> > > idle work is r

Re: [PATCH] ALSA: SoC: Add support for TI SDP3430

[David Brownell]

On Thursday 20 November 2008, Lopez Cruz, Misael wrote:
> > On Thursday 20 November 2008, [EMAIL PROTECTED] wrote:
> > > +   tristate "SoC Audio support for Texas Instruments SDP3430"
> > > +   depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
> > > +   select SND_OMAP_SOC_MCBSP
> > > +   select SND_SOC_TWL4030
> > 
> > depends also on TWL4030_CORE, yes?
> The machine driver itself doesn't depend on TWL4030_CORE, but
> TWL4030 SoC codec driver does (sound/soc/codecs/Kconfig) 
> 
> config SND_SOC_TWL4030
> tristate
> depends on TWL4030_CORE
> 
> Although that dependency is overridden by _select_ statement.

No it isn't.  Reverse dependencies don't work like you might
expect ... even when there's no ambiguity in walking up a
chain of them, *no* additional dependencies are flagged.

So as you've written it, SND_SOC_TWL4030 will be active,
but not TWL4030_CORE on which it depends.


If you fix that in Kconfig, you'd make a lot of folk
fairly happy ... but there'd be fun ambiguities to cope
with.  Example:

config X
select D
config D
depends on (A && B) || C

It's not clear whether to enable both A and B; just C;
or all of them...

Probably asking the user to resolve such issues would be
necessary.  Coming up with all the solutions would be a bit
more complex than a Prolog interpreter, since Kconfig uses
tristate logic not boolean.


> What should be the best way to handle this dependency? Directly
> in kconfig entry for each TWL4030-related machine driver? 

The least error-prone answer involves no "select" statements
at all, ever.  That is, least error-prone in terms of the
output of Kconfig being a valid configuration ... in terms
of minimizing user error, I suggest just adding the single
dependency I mentioned.

- Dave

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

Re: [ANNOUNCE] new PM branch: pm-20081119

[Kalle Jokiniemi]

On to, 2008-11-20 at 15:48 +0100, ext Koen Kooi wrote:
> Op 20 nov 2008, om 15:13 heeft Premi, Sanjeev het volgende geschreven:
> >>
> > These are my observations on OMAP3EVM:
> >
> > 1) Very frequently I see these messages:
> >
> > <4>__ratelimit: 6736 callbacks suppressed
> > __ratelimit: 6736 callbacks suppressed
> > <3>omapfb omapfb: irq error status 00c2
> > omapfb omapfb: irq error status 00c2
> 
> There should be a workaround for those in 2.6.28rc3.  Rick Bronson  
> posted a message about it on 7 november titled "Fix for dispc's error  
> "omapfb omapfb: irq error status 4020"

This interrupt is from SYNCLOST, which is different than what Premi had
(GFX fifo underflow). For that underflow one needs to set higher fifo
thresholds, like I described in my earlier mail.

- Kalle

> 
> regards,
> 
> Koen
> 
> regards,
> 
> Koen
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PM: Fix compile error

[Sanjeev Premi]

Function pm_dbg_update_time() is defined in within
an #ifdef CONFIG_DEBUG_FS; leading to this error:

arch/arm/mach-omap2/built-in.o: In function `_pwrdm_state_switch':
/db/psp_git/users/a0756819/omap-kern-latest/arch/arm/mach-omap2/powerdomain.c:139:
 undefined reference to `pm_dbg_update_time'

Signed-off-by: Sanjeev Premi <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/powerdomain.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 0334609..081b3b6 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -136,7 +136,9 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, 
int flag)
if (state != prev)
pwrdm->state_counter[state]++;
 
+#ifdef CONFIG_DEBUG_FS
pm_dbg_update_time(pwrdm, prev);
+#endif
 
pwrdm->state = state;
 
-- 
1.5.6

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

Re: [PATCH] OMAP: set appropriate platform data for touchscreen.

[stanley.miao]

Please ignore it, I will resend it with other patches together.

Stanley.


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

Re: [PATCH] OMAP3 NAND: Add NAND support on OMAP_LDP

[stanley.miao]

Please ignore it, I will resend it with other patches together.

Stanley.

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

Re: [PATCH] OMAP: Switch to gpio_direction_output in OMAP_LDP.

[stanley.miao]

On Thu, 2008-11-20 at 11:11 -0800, David Brownell wrote:
> On Thursday 20 November 2008, Stanley.Miao wrote:
> > -   omap_set_gpio_direction(LCD_PANEL_QVGA_GPIO, 0);
> > -   omap_set_gpio_direction(LCD_PANEL_RESET_GPIO, 0);
> > gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
> > gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
> 
> Nothing does
> 
>   gpio_request(LCD_PANEL_QVGA_GPIO, "qvga something");
>   gpio_request(LCD_PANEL_RESET_GPIO, "lcd reset");
> 

Accepted, change omap_request_gpio() to gpio_request().

> And by removing the initial direction setting call (above),
> behavior of at least the reset line changes:  it's no longer
> pullsed low.
> 
> It'd be better to change the direction setting calls above
> (setting an initial low value), and then make the calls
> below use gpio_set_value().
> 
>   
> >  #ifdef CONFIG_FB_OMAP_LCD_VGA
> > -   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 0);
> > +   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
> >  #else
> > -   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 1);
> > +   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
> >  #endif
> > -   omap_set_gpio_dataout(LCD_PANEL_RESET_GPIO, 1);
> > +   gpio_direction_output(LCD_PANEL_RESET_GPIO, 1);
> 
> Use gpio_set_value() to replace omap_set_gpio_dataout(), except
> when initializing.  The reset pin *was* being toggled...

These actions are in init function. so keep omap_set_gpio_dataout() in
place.

Thanks for your review, I will resend it.

Stanley.

> 
> - Dave
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 0/3] OMAP_LDP support in linux-git tree

[Stanley.Miao]

Changes from v1:

1, change omap_request_gpio() to gpio_request() in gpio.patch.

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

[PATCHv2 1/3] OMAP: Switch to standard gpio interface in OMAP_LDP

[Stanley.Miao]

Switch to standard gpio interface and make LDP can build success.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-ldp.c |4 ++--
 drivers/video/omap/lcd_ldp.c|   16 +++-
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 103ce6d..cfa2cde 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -344,12 +344,12 @@ static inline void __init ldp_init_smc911x(void)
 
ldp_smc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
 
-   if (omap_request_gpio(eth_gpio) < 0) {
+   if (gpio_request(eth_gpio, "LAN IRQ line") < 0) {
printk(KERN_ERR "Failed to request GPIO%d for smc911x IRQ\n",
eth_gpio);
return;
}
-   omap_set_gpio_direction(eth_gpio, 1);
+   gpio_direction_input(eth_gpio);
 }
 
 
diff --git a/drivers/video/omap/lcd_ldp.c b/drivers/video/omap/lcd_ldp.c
index e944166..66a6b91 100644
--- a/drivers/video/omap/lcd_ldp.c
+++ b/drivers/video/omap/lcd_ldp.c
@@ -64,30 +64,28 @@
 static int ldp_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
 {
-   omap_request_gpio(LCD_PANEL_RESET_GPIO);
-   omap_request_gpio(LCD_PANEL_QVGA_GPIO);
+   gpio_request(LCD_PANEL_RESET_GPIO, "lcd reset");
+   gpio_request(LCD_PANEL_QVGA_GPIO, "VGA/QVGA switch");
gpio_request(LCD_PANEL_ENABLE_GPIO, "lcd panel");
gpio_request(LCD_PANEL_BACKLIGHT_GPIO, "lcd backlight");
 
-   omap_set_gpio_direction(LCD_PANEL_QVGA_GPIO, 0);
-   omap_set_gpio_direction(LCD_PANEL_RESET_GPIO, 0);
gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
 
 #ifdef CONFIG_FB_OMAP_LCD_VGA
-   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 0);
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 0);
 #else
-   omap_set_gpio_dataout(LCD_PANEL_QVGA_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
 #endif
-   omap_set_gpio_dataout(LCD_PANEL_RESET_GPIO, 1);
+   gpio_direction_output(LCD_PANEL_RESET_GPIO, 1);
 
return 0;
 }
 
 static void ldp_panel_cleanup(struct lcd_panel *panel)
 {
-   omap_free_gpio(LCD_PANEL_RESET_GPIO);
-   omap_free_gpio(LCD_PANEL_QVGA_GPIO);
+   gpio_free(LCD_PANEL_RESET_GPIO);
+   gpio_free(LCD_PANEL_QVGA_GPIO);
gpio_free(LCD_PANEL_ENABLE_GPIO);
gpio_free(LCD_PANEL_BACKLIGHT_GPIO);
 }
-- 
1.5.6.3

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

[PATCHv2 2/3] OMAP: set appropriate platform data for touchscreen.

[Stanley.Miao]

Set appropriate platform data for touchscreen and make it work correctly.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/board-3430sdp.c |8 
 arch/arm/mach-omap2/board-ldp.c |8 
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index b7d2e92..42f92be 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -213,9 +213,17 @@ static int ads7846_vaux_control(int vaux_cntrl)
 }
 
 static struct ads7846_platform_data tsc2046_config __initdata = {
+   .x_max  = 0x0fff,
+   .y_max  = 0x0fff,
+   .x_plate_ohms   = 180,
+   .pressure_max   = 255,
+   .debounce_max   = 10,
+   .debounce_tol   = 10,
+   .debounce_rep   = 1,
.get_pendown_state  = ads7846_get_pendown_state,
.keep_vref_on   = 1,
.vaux_control   = ads7846_vaux_control,
+   .settle_delay_usecs = 150,
 };
 
 
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index a59e4eb..f17d507 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -277,9 +277,17 @@ static int ads7846_vaux_control(int vaux_cntrl)
 }
 
 static struct ads7846_platform_data tsc2046_config __initdata = {
+   .x_max  = 0x0fff,
+   .y_max  = 0x0fff,
+   .x_plate_ohms   = 180,
+   .pressure_max   = 255,
+   .debounce_max   = 10,
+   .debounce_tol   = 10,
+   .debounce_rep   = 1,
.get_pendown_state  = ads7846_get_pendown_state,
.keep_vref_on   = 1,
.vaux_control   = ads7846_vaux_control,
+   .settle_delay_usecs = 150,
 };
 
 
-- 
1.5.6.3

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

[PATCHv2 3/3] OMAP3 NAND: Add NAND support on OMAP_LDP

[Stanley.Miao]

Add NAND support on OMAP_LDP.

Signed-off-by: Stanley.Miao <[EMAIL PROTECTED]>
---
 arch/arm/mach-omap2/Makefile|3 +-
 arch/arm/mach-omap2/board-ldp-flash.c   |  103 +++
 arch/arm/mach-omap2/board-ldp.c |1 +
 arch/arm/plat-omap/include/mach/board-ldp.h |2 +
 4 files changed, 108 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-ldp-flash.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3897347..bfc9bcf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -66,7 +66,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE)   += 
board-omap3beagle.o \
   twl4030-generic-scripts.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
   mmc-twl4030.o \
-  usb-musb.o
+  usb-musb.o \
+  board-ldp-flash.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
   board-apollon-mmc.o  \
   board-apollon-keys.o
diff --git a/arch/arm/mach-omap2/board-ldp-flash.c 
b/arch/arm/mach-omap2/board-ldp-flash.c
new file mode 100644
index 000..06e0f2d
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ldp-flash.c
@@ -0,0 +1,103 @@
+/*
+ * linux/arch/arm/mach-omap2/board-ldp-flash.c
+ *
+ * Copyright (C) 2008 Wind River Systems, Inc.
+ *
+ * Author: Stanley Miao <[EMAIL PROTECTED]>
+ * Based on mach-omap2/board-3430sdp-flash.c by Rohit Choraria
+ *
+ * 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 
+
+#define GPMC_CS0_BASE  0x60
+#define GPMC_CS_SIZE   0x30
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition ldp_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "X-Loader-NAND",
+   .offset = 0,
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "U-Boot-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x8 */
+   .size   = 4 * NAND_BLOCK_SIZE,
+   .mask_flags = MTD_WRITEABLE,/* force read-only */
+   },
+   {
+   .name   = "Boot Env-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x10 */
+   .size   = 2 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "Kernel-NAND",
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x14 */
+   .size   = 32 * NAND_BLOCK_SIZE,
+   },
+   {
+   .name   = "File System - NAND",
+   .size   = MTDPART_SIZ_FULL,
+   .offset = MTDPART_OFS_APPEND,   /* Offset = 0x54 */
+   },
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data ldp_nand_data = {
+   .parts  = ldp_nand_partitions,
+   .nr_parts   = ARRAY_SIZE(ldp_nand_partitions),
+   .nand_setup = NULL,
+   .dma_channel= -1,   /* disable DMA in OMAP NAND driver */
+   .dev_ready  = NULL,
+};
+
+static struct resource ldp_nand_resource = {
+   .flags  = IORESOURCE_MEM,
+};
+
+static struct platform_device ldp_nand_device = {
+   .name   = "omap2-nand",
+   .id = 0,
+   .dev= {
+   .platform_data  = &ldp_nand_data,
+   },
+   .num_resources  = 1,
+   .resource   = &ldp_nand_resource,
+};
+
+/**
+ * ldp430_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init ldp_flash_init(void)
+{
+   int nandcs = LDP_NAND_CS;
+   u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+   ldp_nand_data.cs = nandcs;
+   ldp_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+   GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+   ldp_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add);
+
+   if (platform_device_register(&ldp_nand_device) < 0)
+   printk(KERN_ERR "Unable to register NAND device\n");
+}
+
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 79f49d3..103ce6d 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -538,6 +538,7 @@ static void __init omap_ldp_init(void)
 

Re: [PATCH] OMAP: Switch to gpio_direction_output in OMAP_LDP.

[David Brownell]

On Thursday 20 November 2008, stanley.miao wrote:
> 
> > Use gpio_set_value() to replace omap_set_gpio_dataout(), except
> > when initializing.  The reset pin *was* being toggled...
> 
> These actions are in init function. so keep omap_set_gpio_dataout() in
> place.

No, omap_set_gpio_dataout() is gone.  You can't call it any more.

  gpio_direction_output(gpio, initial_value)

is what you'd want after gpio_request().
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html