Re: [FYI] Rebase: tidspbridge-20081118
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
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
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
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
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
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
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
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
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
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
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
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
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.
> -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.
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.
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.
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.
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
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
> -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
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
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
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
> -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
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
-- > > 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
* 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
* 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
* 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
"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
"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
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
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 <[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
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
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
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.
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
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
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
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.
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
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
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
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
> -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
> 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
> > @@ -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
- 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
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
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
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
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.
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
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.
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
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
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.
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
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.
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