Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
Hi On Wed, 21 Oct 2009 05:11:06 +0200 Janusz Krzysztofik wrote: > Hi, > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > omap_pcm_prepare() unconditionally calls: > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > AFAICS, current implementation of those two functions found in > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 at > all, so they both end with BUG() on that machine. That seems to result in > ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta. > Thanks for reporting the issue. Nobody didn't realize when those calls were added that indeed they will end up to BUG() in arch/arm/plat-omap/dma.c on OMAP1. > Is calling BUG() for OMAP1 from those functions intentional? > > If not intentional, can those be corrected by simply putting break; before > defalut:? > I'd let it on as it is as it will point out immediately invalid argument for OMAP1 and those functions do not have return value. > If intentional, can those function calls be conditionally omited, at least > for > OMAP1510, in sound/soc/omap/omap-pcm.c? > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c since we should not try to set unsupported burst size for OMAP1. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
On Tue, Oct 20, 2009 at 05:40:17PM -0700, Tony Lindgren wrote: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > 0028 > > > > pgd = c0004000 > > > > [0028] *pgd= > > > > Internal error: Oops: 8005 [#1] > > > > last sysfs file: > > > > Modules linked in: > > > > CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12) > > > > PC is at 0x28 > > > > LR is at serial8250_config_port+0x184/0xc34 > > > > (...etc...) > > > > > > > > Please consider following fix (and while there fix OMAP2 too as patch > > > > broke > > > > it as well (untested)) > > > > > > Thanks, I already refreshed the original patch with the same fix few > > > days ago :) It should be there in for-next branch and master branch. > > > > Correction, sorry looks like I did not really read your patch. It seems > > to be the right solution for mach-omap1, but not needed for mach-omap2 > > because the array is not plat_serial8250_port on mach-omap2. Ach, sorry. Now it was me who didn't read code carefully. > I've refreshed the original serial.c patch in for-next branch by leaving > out the mach-omap2 changes. Also updated in the master branch, can you > please check? Just pulled master branch and succesfully booted on OMAP5910 board. Thank you, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] twl4030 codec as MFD device
Hello Samuel, On Monday 19 October 2009 15:42:16 Ujfalusi Peter (Nokia-D/Tampere) wrote: > Hello, > > The following series adds new MFD device on top of the twl4030 MFD device > for the codec part of the chip, and also converts the soc audio driver to > use the correct probing (device model). > > Reason for the twl4030_codec MFD: the vibra control is actually in the > codec part of the twl4030. If both the vibra and the audio functionality > is needed from the twl4030 at the same time, than they need to control the > codec power and APLL at the same time without breaking the other driver. > Also these two has to be able to work without the need for the other > driver. Have you had time to look at the series? I have made all the modification suggested by Mark Brown, and I'm holding back the second series (to have the comments from you for the initial series), so I can address those in the same round. Thank you, Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 20 October, 2009 20:48
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>setup times dynamically in idle loop
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> It is suggested by TI (SWPA152 February 2009) to write clksetup,
>> voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
>idle loop.
>
>Can you summarize the reasons why?
Basically this optimizes the clksetup / voltsetup times according to the sleep
mode. Currently the settings are too high in both retention and off-mode,
because the hardware appears to use for example VOLTSETUP2 even if we are not
in off-mode, adding extra delay to wakeup. Also, CLKSETUP is too high for
retention mode because oscillator is not actually shut-off here.
However, now that I think about it, it might be better to change this in a way
that it is user configurable whether we want to change the settings or not,
maybe add new items in to the prm_setup struct for alternate settings for ret /
off and only use these if available. Some boards might actually switch
oscillator off in retention mode which would require higher setup time.
>
>> Signed-off-by: Jouni Hogander
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 36
>+---
>> 1 files changed, 25 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index f492142..ae83121 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -575,6 +575,30 @@ void omap_sram_idle(void)
>> if (regset_save_on_suspend)
>> pm_dbg_regset_save(1);
>>
>> +/* Write voltage setup times which are changed dynamically */
>
>AFAICT, we only set these values at init time and they are never
>changed. Are there some forthcoming patches that change these
>dynamically?
Following bit of the code actually changes them dynamically, you can see that
e.g. CLKSETUP time is either prm_setup.clksetup or 0x1 depending on the sleep
mode. But as previously said, I think these should probably be added as new
items to the prm_setup struct.
>
>Kevin
>
>> +if (core_next_state == PWRDM_POWER_OFF) {
>> +prm_write_mod_reg(0, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP1_OFFSET);
>> +prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP2_OFFSET);
>> +prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>> +OMAP3_PRM_CLKSETUP_OFFSET);
>> +} else {
>> +prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>> +OMAP3430_SETUP_TIME2_SHIFT) |
>> +(prm_setup.voltsetup_time1 <<
>> +OMAP3430_SETUP_TIME1_SHIFT),
>> +OMAP3430_GR_MOD,
>OMAP3_PRM_VOLTSETUP1_OFFSET);
>> +prm_write_mod_reg(0, OMAP3430_GR_MOD,
>> +OMAP3_PRM_VOLTSETUP2_OFFSET);
>> +/*
>> + * Use static 1 as only HF_CLKOUT is turned off.
>> + * Value taken from application note SWPA152
>> + */
>> +prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
>> +OMAP3_PRM_CLKSETUP_OFFSET);
>> +}
>> +
>> /*
>> * omap3_arm_context is the location where ARM registers
>> * get saved. The restore path then reads from this
>> @@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
>>OMAP3430_GR_MOD,
>>OMAP3_PRM_VC_I2C_CFG_OFFSET);
>>
>> -/* Write setup times */
>> -prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>> -OMAP3_PRM_CLKSETUP_OFFSET);
>> -prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>> -OMAP3430_SETUP_TIME2_SHIFT) |
>> -(prm_setup.voltsetup_time1 <<
>> -OMAP3430_SETUP_TIME1_SHIFT),
>> -OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
>> -
>> +/* Write static setup times */
>> prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
>> OMAP3_PRM_VOLTOFFSET_OFFSET);
>> -prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>> -OMAP3_PRM_VOLTSETUP2_OFFSET);
>>
>> pm_dbg_regset_init(1);
>> pm_dbg_regset_init(2);
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
>-Original Message-
>From: linux-omap-ow...@vger.kernel.org
>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>Sent: 20 October, 2009 20:31
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>before entering suspend
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> Suspending drivers may still generate interrupts just before
>their suspend is
>> completed. Any pending interrupts here will prevent sleep.
>>
>> Signed-off-by: Tero Kristo
>
>This could also be done in omap3_intc_prepare_idle() hook.
I thought it is better to do this in suspend path only, because in normal sleep
case we most likely don't want to miss any interrupts. In suspend case, we
usually want to enter the suspend no matter what, and this is used here only to
clean up the mess left by some of the drivers. The GPT case is one of the main
things we try to fix here.
-Tero
>
>> ---
>> arch/arm/mach-omap2/irq.c |2 +-
>> arch/arm/mach-omap2/pm34xx.c |2 ++
>> arch/arm/plat-omap/include/mach/irqs.h |1 +
>> 3 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
>> index aceedd8..4ed05e9 100644
>> --- a/arch/arm/mach-omap2/irq.c
>> +++ b/arch/arm/mach-omap2/irq.c
>> @@ -101,7 +101,7 @@ static int omap_check_spurious(unsigned int irq)
>> }
>>
>> /* XXX: FIQ and additional INTC support (only MPU at the moment) */
>> -static void omap_ack_irq(unsigned int irq)
>> +void omap_ack_irq(unsigned int irq)
>> {
>> intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
>> }
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index 5854fa7..6a41811 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
>>
>> omap_uart_prepare_suspend();
>>
>> +/* Ack pending IRQs, as a pending IRQ will cause the
>suspend to fail */
>> +omap_ack_irq(0);
>> regset_save_on_suspend = 1;
>> omap_sram_idle();
>> regset_save_on_suspend = 0;
>> diff --git a/arch/arm/plat-omap/include/mach/irqs.h
>b/arch/arm/plat-omap/include/mach/irqs.h
>> index 2473910..d56be1c 100644
>> --- a/arch/arm/plat-omap/include/mach/irqs.h
>> +++ b/arch/arm/plat-omap/include/mach/irqs.h
>> @@ -483,6 +483,7 @@
>> #ifndef __ASSEMBLY__
>> extern void omap_init_irq(void);
>> extern int omap_irq_pending(void);
>> +extern void omap_ack_irq(unsigned int irq);
>> void omap3_intc_save_context(void);
>> void omap3_intc_restore_context(void);
>> #endif
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/17] OMAP2/3: GPTIMER: Clear pending interrupts when entering suspend
>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman >Sent: 20 October, 2009 20:37 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 08/17] OMAP2/3: GPTIMER: Clear pending >interrupts when entering suspend > >Tero Kristo writes: > >> From: Tero Kristo >> >> OMAP GP timers keep running for a few cycles after they are stopped, >> which can cause the timer to expire and generate an >interrupt. The pending >> interrupt will prevent OMAP from entering suspend, thus we >ack it manually. >> >> Signed-off-by: Tero Kristo >> >> --- >> arch/arm/mach-omap2/timer-gp.c | 14 +- >> 1 files changed, 13 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/timer-gp.c >b/arch/arm/mach-omap2/timer-gp.c >> index 9c056ff..c9d47bb 100644 >> --- a/arch/arm/mach-omap2/timer-gp.c >> +++ b/arch/arm/mach-omap2/timer-gp.c >> @@ -92,9 +92,21 @@ static void omap2_gp_timer_set_mode(enum >clock_event_mode mode, >> case CLOCK_EVT_MODE_ONESHOT: >> break; >> case CLOCK_EVT_MODE_UNUSED: >> -case CLOCK_EVT_MODE_SHUTDOWN: >> case CLOCK_EVT_MODE_RESUME: >> break; >> +case CLOCK_EVT_MODE_SHUTDOWN: >> +/* >> + * Wait for min period x 2 to make sure that timer is >> + * stopped >> + */ >> +udelay(evt->min_delta_ns / 500); >> +/* >> + * Clear possibly pending interrupt, this will >occasionally >> + * generate spurious timer IRQs during suspend but this >> + * is okay, as another option is not to enter >suspend at all >> + */ >> +omap_dm_timer_write_status(gptimer, >OMAP_TIMER_INT_OVERFLOW); >> +break; > >Seems to me that this fix should just be done in omap_dm_timer_stop() >since it could also result in extra interrupts in when using oneshot >mode under dyntick. Hmm yea, I can attempt to move this in there. > >Kevin > >-- >To unsubscribe from this list: send the line "unsubscribe >linux-omap" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 17/17] OMAP3: PM: Force disable OTG autoidle
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 20 October, 2009 21:44
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 17/17] OMAP3: PM: Force disable OTG autoidle
>
>Tero Kristo writes:
>
>> From: Tero Kristo
>>
>> OMAP3 sleep can be prevented in some cases where OTG
>autoidle is enabled.
>> This patch force disables autoidle during boot and after
>wakeup from off-mode.
>> See omap erratas 1.164 and 1.165.
>
>The init-at-boot step isn't needed as this is already done in
>PM branch (see usb-muxb.c:usb_musb_pm_init()).
True, that reset part actually does this, which is also part of the errata.
>
>> Signed-off-by: Tero Kristo
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 14 ++
>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>b/arch/arm/mach-omap2/pm34xx.c
>> index ae83121..5f351f2 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -94,6 +94,8 @@ u32 voltage_off_while_idle;
>> OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
>> OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
>>
>> +#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
>> +
>> struct power_state {
>> struct powerdomain *pwrdm;
>> u32 next_state;
>> @@ -423,6 +425,16 @@ static void restore_table_entry(void)
>> restore_control_register(control_reg_value);
>> }
>>
>> +static inline void disable_otg_autoidle(void)
>> +{
>> +/*
>> + * OTG autoidle can prevent core domain sleep in some
>cases, thus
>> + * disable it. See omap erratas 1.164 and 1.165.
>> + */
>> +cm_set_mod_reg_bits(OMAP3430_EN_HSOTGUSB, CORE_MOD, CM_ICLKEN1);
>
>Is the ICLK enable required as part of the fix too? I don't see
>mention of enabling the iclk as part of the workaround for either of
>these errata.
>
>If the iclk needs to be enabled, it should be done at init using
>the clk API.
ICLK enable part is here because we will crash unless ICLK is active. It does
not really need to be on, but it was rather simpler to do it this way. I can
try to look if adding this into USB code would make sense.
>
>> +omap_writel(0x0, OTG_SYSCONFIG);
>
>omap_writel() deprecated.
Again...
>
>> +}
>> +
>
>For readability, this should be a function in the USB core code
>(either usb-musb.c or a static inline in )
>
>Kevin
>
>> void omap_sram_idle(void)
>> {
>> /* Variable to tell what needs to be saved and restored
>> @@ -628,6 +640,7 @@ void omap_sram_idle(void)
>> omap3_prcm_restore_context();
>> omap3_sram_restore_context();
>> omap2_sms_restore_context();
>> +disable_otg_autoidle();
>> }
>> omap_uart_resume_idle(0);
>> omap_uart_resume_idle(1);
>> @@ -1417,6 +1430,7 @@ static int __init omap3_pm_early_init(void)
>> OMAP3_PRM_POLCTRL_OFFSET);
>>
>> configure_vc();
>> +disable_otg_autoidle();
>>
>> return 0;
>> }
>> --
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a): > Hi > > On Wed, 21 Oct 2009 05:11:06 +0200 > > Janusz Krzysztofik wrote: > > Hi, > > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > > omap_pcm_prepare() unconditionally calls: > > > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > > > AFAICS, current implementation of those two functions found in > > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 > > at all, so they both end with BUG() on that machine. That seems to result > > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad > > Delta. > > Thanks for reporting the issue. Nobody didn't realize when those calls > were added that indeed they will end up to BUG() in > arch/arm/plat-omap/dma.c on OMAP1. > > > Is calling BUG() for OMAP1 from those functions intentional? > > > > If not intentional, can those be corrected by simply putting break; > > before defalut:? > > I'd let it on as it is as it will point out immediately invalid > argument for OMAP1 and those functions do not have return value. > > > If intentional, can those function calls be conditionally omited, at > > least for OMAP1510, in sound/soc/omap/omap-pcm.c? > > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c > since we should not try to set unsupported burst size for OMAP1. Here you are. Signed-off-by: Janusz Krzysztofik --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.0 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmci-omap: free irq resource
Free IRQ on remove. Signed-off-by: Ladislav Michl diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 5d773b8..5f970e2 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1529,6 +1529,7 @@ static int mmc_omap_remove(struct platform_device *pdev) host->pdata->cleanup(&pdev->dev); mmc_omap_fclk_enable(host, 0); + free_irq(host->irq, host); clk_put(host->fclk); clk_disable(host->iclk); clk_put(host->iclk); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmci-omap: remove bogus check for host->iclk
Remove check for host->iclk being NULL from error path since we already know
it is non-null and use return value from clk_get.
Signed-off-by: Ladislav Michl
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..c6d7e8e 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1459,8 +1459,10 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
goto err_ioremap;
host->iclk = clk_get(&pdev->dev, "ick");
- if (IS_ERR(host->iclk))
+ if (IS_ERR(host->iclk)) {
+ ret = PTR_ERR(host->iclk);
goto err_free_mmc_host;
+ }
clk_enable(host->iclk);
host->fclk = clk_get(&pdev->dev, "fck");
@@ -1500,10 +1502,8 @@ err_free_irq:
err_free_fclk:
clk_put(host->fclk);
err_free_iclk:
- if (host->iclk != NULL) {
- clk_disable(host->iclk);
- clk_put(host->iclk);
- }
+ clk_disable(host->iclk);
+ clk_put(host->iclk);
err_free_mmc_host:
iounmap(host->virt_base);
err_ioremap:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix broken NAND on Amstrad Delta
Wednesday 21 October 2009 02:51:35 Tony Lindgren wrote: > > Let's just remove the omap_cfg_reg() calls from mach-omap1/serial.c, and > add them to the board-*.c files like you suggest above. We should be able > to find which ports to mux by looking at the enabled_uarts mask in the > commit mentioned above. Tony, I can prepare a patch if you haven't started working on it yet, but please do me a favour and give your comments on another, old but still not answered subject: http://www.spinics.net/lists/linux-omap/msg17692.html I have just checked that temporary solution still applies cleanly on top of 2.6.32-rc5 and corrects the problem of otherwise unusable ASoC over McBSP1 on my Amstrad Delta. Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] PM: Skip PER previous state register read
According to measurements, reading the previous state of PER
domain after wfi takes ~11us on OPP2.
Removed this unneccessary latency from cases where we know
PER power domain did not try to enter off mode.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/pm34xx.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 237c819..b70ea19 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -489,12 +489,19 @@ void omap_sram_idle(void)
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
- per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
- if (per_prev_state == PWRDM_POWER_OFF) {
- omap3_per_restore_context();
- omap3_gpio_restore_pad_context(0);
- } else if (per_next_state == PWRDM_POWER_OFF)
- omap3_gpio_restore_pad_context(1);
+ if (per_next_state == PWRDM_POWER_OFF) {
+ /*
+* Reading the prev-state takes long time (1...@opp2),
+* only do it, if we really tried to put PER in OFF
+*/
+ per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
+ if (per_prev_state == PWRDM_POWER_OFF) {
+ omap3_per_restore_context();
+ omap3_gpio_restore_pad_context(0);
+ } else if (per_next_state == PWRDM_POWER_OFF) {
+ omap3_gpio_restore_pad_context(1);
+ }
+ }
omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
if (per_state_modified)
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] PM: Misc latency fixes
Hello, Here are some fruits from digging out the latency sources of our idle loop. The main latency source was powerdomain state counter updating at beginning and end of the idle loop. Also PER previous state reading strangely seemed to cause some latency with significance. Could not find any TRM or errata comment to why this is, though. The I2C mpu wakeup latency constraint patch has been updated to calculate latencies at boot from clkrate and fifo size. This was included in this set, since it benefits from the reduced latency of the other patches. Patches tested on linux-omap/pm and rx-51. Kalle Jokiniemi (3): OMAP3: Only update pm-counters when needed PM: Skip PER previous state register read OMAP: I2C: Add mpu wake up latency constraint in i2c arch/arm/mach-omap2/pm-debug.c | 51 - arch/arm/mach-omap2/pm.h |2 + arch/arm/mach-omap2/pm34xx.c | 31 ++ arch/arm/plat-omap/i2c.c | 54 +++- drivers/i2c/busses/i2c-omap.c | 25 +++--- include/linux/i2c-omap.h |9 ++ 6 files changed, 143 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.
Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.
Cc: Moiz Sonasath
Cc: Jarkko Nikula
Cc: Paul Walmsley
Cc: Nishanth Menon
Signed-off-by: Kalle Jokiniemi
---
arch/arm/plat-omap/i2c.c | 54 +++-
drivers/i2c/busses/i2c-omap.c | 25 ---
include/linux/i2c-omap.h |9 +++
3 files changed, 72 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 8b84839..3c122cd 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,8 +26,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -69,14 +71,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP34XX)
- I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
#endif
};
@@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
#define OMAP_I2C_CMDLINE_SETUP (BIT(31))
+#ifdef CONFIG_ARCH_OMAP34XX
+/*
+ * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev: i2c bus device pointer
+ * @val: latency constraint to set, -1 to disable constraint
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup from
+ * idle, when transfer completes.
+ */
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int val)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, val);
+}
+#endif
+
+static void __init omap_set_i2c_constraint_func(
+ struct omap_i2c_bus_platform_data *pd)
+{
+ if (cpu_is_omap34xx())
+ pd->set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
+ else
+ pd->set_mpu_wkup_lat = NULL;
+}
+
static void __init omap_i2c_mux_pins(int bus)
{
int scl, sda;
@@ -180,8 +207,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -195,9 +222,10 @@ static int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
- for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
- if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
- i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
+ for (i = 0; i < ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate & OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
+ omap_set_i2c_constraint_func(&i2c_pdata[i]);
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -231,9 +259,11 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- if (!i2c_rate[bus_id - 1])
- i2c_rate[bus_id - 1] = clkrate;
- i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
+ if (!i2c_pdata[bus_id - 1].clkrate)
+ i2c_pdata[bus_id - 1].clkrate = clkrate;
+
+ omap_set_i2c_constraint_func(&i2c_pdata[bus_id - 1]);
+ i2c_pdata[bus_id - 1].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
return omap_i2c_add_bus(bus_id);
}
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 75bf3ad..bbea8a0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.
[PATCH 1/3] OMAP3: Only update pm-counters when needed
From: Kalle Jokiniemi
The biggest source of latency in idle loop (omap_sram_idle
function) comes from updating the state counters for each
power domain. The two purposes of these counters are to
provide debug data in debugfs, and to keep track of context
losses occurring during idle transitions (off mode counters).
I created new debugfs interface "enable_count" for
enabling the "count" interface, which exposes the debug
part of these counters. The counters are not updated
anymore for CORE ON idle transitions, when the count
interface is disabled. For deeper CORE states, counters
are still updated to preserve context loss tracking.
This change decreases C1/C2 state latency over 100us at
OPP2.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/pm-debug.c | 51 ++-
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm34xx.c | 12 +
3 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 5aac64f..76c2696 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -37,6 +37,9 @@
#include "prm-regbits-34xx.h"
int omap2_pm_debug;
+static int pm_dbg_count_active;
+static struct dentry *de_pm_debug_count;
+static struct dentry *de_pm_debug;
#define DUMP_PRM_MOD_REG(mod, reg)\
regs[reg_count].name = #mod "." #reg; \
@@ -327,6 +330,11 @@ int pm_dbg_regset_save(int reg_set)
return 0;
}
+int pm_dbg_count_is_active(void)
+{
+ return pm_dbg_count_active;
+}
+
static const char pwrdm_state_names[][4] = {
"OFF",
"RET",
@@ -460,6 +468,40 @@ static const struct file_operations debug_reg_fops = {
.release= single_release,
};
+static int pm_dbg_count_enable_get(void *data, u64 *val)
+{
+ *val = pm_dbg_count_active;
+ return 0;
+}
+
+static int pm_dbg_count_enable_set(void *data, u64 val)
+{
+ if (val > 1) {
+ printk(KERN_ERR "Invalid value! 1 to enable, 0 to disable\n");
+ return -EINVAL;
+ }
+
+ if (val == 1 && !pm_dbg_count_active) {
+ de_pm_debug_count = debugfs_create_file("count", S_IRUGO,
+ de_pm_debug, (void *)DEBUG_FILE_COUNTERS, &debug_fops);
+
+ if (de_pm_debug_count == NULL) {
+ printk(KERN_ERR "Error: could not create debugfs "
+ "entry\n");
+ return -ENOMEM;
+ }
+ pm_dbg_count_active = 1;
+ } else if (val == 0 && pm_dbg_count_active) {
+ debugfs_remove(de_pm_debug_count);
+ de_pm_debug_count = NULL;
+ pm_dbg_count_active = 0;
+ }
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(enable_count_fops, pm_dbg_count_enable_get,
+ pm_dbg_count_enable_set, "%llu\n");
+
int pm_dbg_regset_init(int reg_set)
{
char name[2];
@@ -576,12 +618,17 @@ static int __init pm_dbg_init(void)
return -ENODEV;
}
+ pm_dbg_count_active = 0;
+
d = debugfs_create_dir("pm_debug", NULL);
if (IS_ERR(d))
return PTR_ERR(d);
+ de_pm_debug = d;
+
+ (void) debugfs_create_file("enable_count", S_IRUGO |
+ S_IWUGO, d, &pm_dbg_count_active,
+ &enable_count_fops);
- (void) debugfs_create_file("count", S_IRUGO,
- d, (void *)DEBUG_FILE_COUNTERS, &debug_fops);
(void) debugfs_create_file("time", S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, &debug_fops);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f8d11a2..3f0202b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -63,12 +63,14 @@ extern int omap2_pm_debug;
extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
extern int pm_dbg_regset_save(int reg_set);
extern int pm_dbg_regset_init(int reg_set);
+extern int pm_dbg_count_is_active(void);
#else
#define omap2_pm_dump(mode, resume, us)do {} while (0);
#define omap2_pm_debug 0
#define pm_dbg_update_time(pwrdm, prev) do {} while (0);
#define pm_dbg_regset_save(reg_set) do {} while (0);
#define pm_dbg_regset_init(reg_set) do {} while (0);
+#define pm_dbg_count_is_active() 0
#endif /* CONFIG_PM_DEBUG */
extern void omap24xx_idle_loop_suspend(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 01260ec..237c819 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -378,15 +378,17 @@ void omap_sram_idle(void)
return;
}
- pwrdm_pre_transition();
+ per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
+ core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+
+ if (pm_dbg_count_is_active() || (core_next_state != PWRDM_POWER
Re: Fwd: mmap /dev/mem in python
Doh! Thank you! This looks to be the problem, I've made some changes
to the code (calling mmap.read(4) rather than mmap.read_bye()) and
everything seems to be working.
On Tue, Oct 20, 2009 at 8:27 PM, Paul Walmsley wrote:
> On Tue, 20 Oct 2009, Brett Graham wrote:
>
>> --minimal python example--
>> open("/dev/mem", O_RDWR|O_SYNC|O_LARGEFILE) = 3
>> fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
>> dup(3) = 4
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x4002
>> --- SIGBUS (Bus error) @ 0 (0) ---
>> +++ killed by SIGBUS +++
>> Process 1633 detached
>
> Your script:
>
>>> m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE |
>>> mmap.PROT_READ, offset=addr & ~MAP_MASK)
>>> m.seek(addr & MAP_MASK)
>
> So the mmap() is working fine, based on the output above...
>
>>> c = m.read_byte()
>
> ... but the above line is going to fail. GPTIMER registers need 16-
> or 32-bit accesses[1].
>
>
> - Paul
>
> 1. OMAP34xx TRM 16.3.2:
>
> "CAUTION
> The GP timer registers are limited to 32-bit and 16-bit data accesses;
> 8-bit access is not allowed and can corrupt the register content."
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stable kernel version
Hi Ameya, this patch fixes the kernel panic. For my taste there should be a more verbose message, that the USB won't work, but otherwise it is fine ;-) Regards Janosch Ameya Palande wrote: Hi, Does this commit fixes the issue? [v2] usb: musb: Warn and check for OTG transceiver misconfiguration Warn if OTG is selected in Kconfig but not initialized by platform code. Add checks to prevent NULL pointer exception in case the OTG transceiver has not been initialized. i.e. musb->xceiv == NULL Signed-off-by: Roger Quadros --- drivers/usb/musb/musb_core.c |7 ++- drivers/usb/musb/omap2430.c |3 ++- 2 files changed, 8 insertions(+), 2 deletions(-) Link: http://patchwork.kernel.org/patch/32914/ Cheers, Ameya. On Mon, Oct 19, 2009 at 8:19 PM, Maldonado Zambrano, Ivan wrote: Hi Machowinski, Enabling TWL4030 USB Transceiver Driver on your menuconfig the issue that you mentioned on a log file attached on previous mails is corrected. I had the same problem. Like an introduction, my name is Ivan Maldonado Zambrano and I'm working on USB tests for zoom3 and sdp. Attached my log file, if you compare with yours is the same problem. Regards Maldonado Zambrano, Ivan x0109...@ti.com Project L23x3630. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Janosch Machowinski Sent: Monday, October 19, 2009 11:32 AM To: linux-omap@vger.kernel.org Subject: Re: stable kernel version Pandita, Vikram schrieb: Here's the problem: <3>HS USB OTG: no transceiver configured <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19 Depending on your board, you will have to define the transceiver for MUSB. It could be TWL4030 or NO-transceiver... I got an Gumstix Overo Earth so which one would it be then ? I tried one kernel, with only NOOP, and one with all three options enabled, same result any time (crash). Drivers -> USB -> (last options) *** OTG and related infrastructure *** Or do u want to disable USB to start with !! Actually USB is the feature why I started compiling a new kernel in the fist place ;-) Regards Janosch -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DSS2 clocking
I'm using DSS2, currently just with a frame buffer to a [VGA/RGB] monitor. I'm trying to understand how to set the timing parameters for my device. The simple 'omapfb.mode=1024x768...@75' doesn't quite cut it for some of the devices I need to use. Questions: * How can I get different pixel clocks? I seem to always end up with 61714285: # cat /tmp/dbg/omapdss/clk - dss - internal clk count 2 dss_ick 83001 dss1_alwon_fck 123428570 1 dss2_alwon_fck 13000 dss_tv_fck 54000 dss_96m_fck 96000 - dispc - dispc fclk source = dss1_alwon_fclk pixel clk = 123428570 / 1 / 2 = 61714285 * How can I control the waveform? In particular, the size and shape of the "porches"? My display seems to need these settings: 61714,1024/26/162/136,768/3/29/6 I'd like to get this behaviour, either from the boot line or ideally by default. * The display also seems to want the sync pulses to be asserted low (inverted?). Currently, I have this "hard-wired" into my display device, but I'd also like this to be adjustable. Thanks for any pointers, etc. Note: I'm using Tomi's tree from roughly late July http://www.bat.org/~tomba/git/linux-omap-dss.git 7ae220f46384b34e72b8c3b0c2075a674a3f74fe Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FW: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
"Gulati, Shweta" writes:
> Any comments would be taken in.
Sorry, I did not see this v2 on the list nor do I find it in the archives.
> -Original Message-
> From: Gulati, Shweta
> Sent: Tuesday, October 13, 2009 3:56 PM
> To: linux-omap@vger.kernel.org
> Cc: Gulati, Shweta; Gopinath, Thara
> Subject: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on
> OMAP3430
>
> From: Shweta Gulati
>
> (Resending the patch with the subject line and some minor fixes)
>
> According to Silicon Bug on context restore it is found that the pad
> configuration register for GPIO_28/GPIO_29(ETKD14/15) is corrupted after
> returning from Core OFF mode. This happens if the MPU reads the
> PADCONF_SAVEDONE bit very close to the end of context save sequence
> for the pad conf registers, resulting in last context not being saved to the
> scratchpad memory. This is a h/w bug. The workaround is to delay the
> MPU access of SAVEDONE bit until the last context has been saved.
>
> This patch adds a configuration option to allow 300 us delay in
> save path as recommended by TI. The other option is to let the
> bug occur but store the value of pad configuration register explicitly
> and write it back in resume path. But this option should be chosen
> only if the ETKD14/15 pads are not in use as this workaround can
> lead to glitch in the pin.
>
> Signed-off-by: Shweta Gulati
> Signed-off-by: Thara Gopinath
Is this patch still needed with this fix recently postd by Nokia:
http://marc.info/?l=linux-omap&m=125569123004013&w=2
Also, this description is still missing the Errata reference. After
reading the errata, I don't think a Kconfig option is the right
answer. Rather, the delay should be inserted iff the pin is enabled,
set as output, and set to high.
Also, the errata makes no mention of the 300usec delay. Please describe
how that number was decided on.
Re: Subject, would be better as
OMAP3: PM: PADCONF restore fix for Errata x.xxx
> --- arch/arm/mach-omap2/pm34xx.c | 25 +
> arch/arm/plat-omap/Kconfig | 17 + 2 files changed,
> 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index cea3bca..4f9671a 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -54,10 +55,19 @@
>
> static int regset_save_on_suspend;
>
> +/* A extra variable to store value of pad_config register if
> + * delay is not to be inserted and value is explicitly restored
> + * in resume path.
> + */
> +#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
> +static u32 store_pad_config;
> +#endif
> +
> /* Scratchpad offsets */
> #define OMAP343X_TABLE_ADDRESS_OFFSET 0x31
> #define OMAP343X_TABLE_VALUE_OFFSET 0x30
> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32
> +#define CONTROL_PADCONF_ETK_D14 0x480025F8
>
> u32 enable_off_mode;
> u32 sleep_while_idle;
> @@ -202,6 +212,17 @@ static void omap3_core_save_context(void)
> omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
> control_padconf_off |= START_PADCONF_SAVE;
> omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
> +#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
> + store_pad_config = omap_readl(CONTROL_PADCONF_ETK_D14);
omap_read* deprecated. Use omap_ctrl_readl() as is done in
the rest of the code.
> +#else
> + /* Due to Silicon Bug on context restore it is found
> + * that the CONTROL_PAD_CONF_ETK14 register is not saved into
> + * scratch pad memory sometimes. To rectify it delay acess by Mpu
> + * for 300us for scm to finish saving task
> + */
> + udelay(300);
> +#endif
> +
> /* wait for the save to complete */
> while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
> & PADCONF_SAVE_DONE)
> @@ -217,6 +238,10 @@ static void omap3_core_save_context(void)
>
> static void omap3_core_restore_context(void)
> {
> + /* Restore the last padconf value if needed */
> +#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
> + omap_writel(store_pad_config, CONTROL_PADCONF_ETK_D14);
> +#endif
> /* Restore the control module context, padconf restored by h/w */
> omap3_control_restore_context();
> /* Restore the GPMC context */
> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> index 2143db5..737d0aa 100644
> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -242,6 +242,23 @@ config OMAP_PM_SRF
>
> endchoice
>
> +config DELAY_IN_PADCONF_SAVE
> + bool "Insert 300 us delay after the start of padconf saving"
> + depends on ARCH_OMAP3 && PM
> + help
> + If this option is selected a 300 us delay is inserted in the
> + suspend path after writing into START_PADCONF_SAVE bit to ensure
> + that pad configuration register is stored properly.If mpu
Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
writes:
>
>
>>-Original Message-
>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>Sent: 20 October, 2009 20:48
>>To: Kristo Tero (Nokia-D/Tampere)
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>>setup times dynamically in idle loop
>>
>>Tero Kristo writes:
>>
>>> From: Tero Kristo
>>>
>>> It is suggested by TI (SWPA152 February 2009) to write clksetup,
>>> voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
>>idle loop.
>>
>>Can you summarize the reasons why?
>
> Basically this optimizes the clksetup / voltsetup times according to the
> sleep mode. Currently the settings are too high in both retention and
> off-mode, because the hardware appears to use for example VOLTSETUP2 even if
> we are not in off-mode, adding extra delay to wakeup. Also, CLKSETUP is too
> high for retention mode because oscillator is not actually shut-off here.
>
> However, now that I think about it, it might be better to change this in a
> way that it is user configurable whether we want to change the settings or
> not, maybe add new items in to the prm_setup struct for alternate settings
> for ret / off and only use these if available. Some boards might actually
> switch oscillator off in retention mode which would require higher setup time.
>
>>
>>> Signed-off-by: Jouni Hogander
>>> ---
>>> arch/arm/mach-omap2/pm34xx.c | 36
>>+---
>>> 1 files changed, 25 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>>b/arch/arm/mach-omap2/pm34xx.c
>>> index f492142..ae83121 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -575,6 +575,30 @@ void omap_sram_idle(void)
>>> if (regset_save_on_suspend)
>>> pm_dbg_regset_save(1);
>>>
>>> + /* Write voltage setup times which are changed dynamically */
>>
>>AFAICT, we only set these values at init time and they are never
>>changed. Are there some forthcoming patches that change these
>>dynamically?
>
> Following bit of the code actually changes them dynamically, you can
> see that e.g. CLKSETUP time is either prm_setup.clksetup or 0x1
> depending on the sleep mode.
Doh, I see now.
> But as previously said, I think these should probably be added as
> new items to the prm_setup struct.
Yes, I would rather see the prm_setup struct extended so these can be
passed in by board code.
Kevin
>>
>>Kevin
>>
>>> + if (core_next_state == PWRDM_POWER_OFF) {
>>> + prm_write_mod_reg(0, OMAP3430_GR_MOD,
>>> + OMAP3_PRM_VOLTSETUP1_OFFSET);
>>> + prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>>> + OMAP3_PRM_VOLTSETUP2_OFFSET);
>>> + prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>>> + OMAP3_PRM_CLKSETUP_OFFSET);
>>> + } else {
>>> + prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>>> + OMAP3430_SETUP_TIME2_SHIFT) |
>>> + (prm_setup.voltsetup_time1 <<
>>> + OMAP3430_SETUP_TIME1_SHIFT),
>>> + OMAP3430_GR_MOD,
>>OMAP3_PRM_VOLTSETUP1_OFFSET);
>>> + prm_write_mod_reg(0, OMAP3430_GR_MOD,
>>> + OMAP3_PRM_VOLTSETUP2_OFFSET);
>>> + /*
>>> +* Use static 1 as only HF_CLKOUT is turned off.
>>> +* Value taken from application note SWPA152
>>> +*/
>>> + prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
>>> + OMAP3_PRM_CLKSETUP_OFFSET);
>>> + }
>>> +
>>> /*
>>> * omap3_arm_context is the location where ARM registers
>>> * get saved. The restore path then reads from this
>>> @@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
>>> OMAP3430_GR_MOD,
>>> OMAP3_PRM_VC_I2C_CFG_OFFSET);
>>>
>>> - /* Write setup times */
>>> - prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
>>> - OMAP3_PRM_CLKSETUP_OFFSET);
>>> - prm_write_mod_reg((prm_setup.voltsetup_time2 <<
>>> - OMAP3430_SETUP_TIME2_SHIFT) |
>>> - (prm_setup.voltsetup_time1 <<
>>> - OMAP3430_SETUP_TIME1_SHIFT),
>>> - OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
>>> -
>>> + /* Write static setup times */
>>> prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
>>> OMAP3_PRM_VOLTOFFSET_OFFSET);
>>> - prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
>>> - OMAP3_PRM_VOLTSETUP2_OFFSET);
>>>
>>> pm_dbg_regset_init(1);
>>> pm_dbg_regset_init(2);
>>> --
>>> 1.5.4.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>linux-omap" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.ht
Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
writes:
>>-Original Message-
>>From: linux-omap-ow...@vger.kernel.org
>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Kevin Hilman
>>Sent: 20 October, 2009 20:31
>>To: Kristo Tero (Nokia-D/Tampere)
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>>before entering suspend
>>
>>Tero Kristo writes:
>>
>>> From: Tero Kristo
>>>
>>> Suspending drivers may still generate interrupts just before
>>their suspend is
>>> completed. Any pending interrupts here will prevent sleep.
>>>
>>> Signed-off-by: Tero Kristo
>>
>>This could also be done in omap3_intc_prepare_idle() hook.
>
> I thought it is better to do this in suspend path only, because in
> normal sleep case we most likely don't want to miss any
> interrupts.
Agreed, then I'd suggest doing this in omap3_intc_[suspend|resume]()
hooks.
> In suspend case, we usually want to enter the suspend no
> matter what, and this is used here only to clean up the mess left by
> some of the drivers. The GPT case is one of the main things we try
> to fix here.
So is this still needed with the GPTIMER fix in PATCH 8/17?
If there are other drivers having delayed interrupt triggering, it
sounds like the drivers need to be fixed instead of this brute force
approach.
Kevin
>
>>
>>> ---
>>> arch/arm/mach-omap2/irq.c |2 +-
>>> arch/arm/mach-omap2/pm34xx.c |2 ++
>>> arch/arm/plat-omap/include/mach/irqs.h |1 +
>>> 3 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
>>> index aceedd8..4ed05e9 100644
>>> --- a/arch/arm/mach-omap2/irq.c
>>> +++ b/arch/arm/mach-omap2/irq.c
>>> @@ -101,7 +101,7 @@ static int omap_check_spurious(unsigned int irq)
>>> }
>>>
>>> /* XXX: FIQ and additional INTC support (only MPU at the moment) */
>>> -static void omap_ack_irq(unsigned int irq)
>>> +void omap_ack_irq(unsigned int irq)
>>> {
>>> intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
>>> }
>>> diff --git a/arch/arm/mach-omap2/pm34xx.c
>>b/arch/arm/mach-omap2/pm34xx.c
>>> index 5854fa7..6a41811 100644
>>> --- a/arch/arm/mach-omap2/pm34xx.c
>>> +++ b/arch/arm/mach-omap2/pm34xx.c
>>> @@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
>>>
>>> omap_uart_prepare_suspend();
>>>
>>> + /* Ack pending IRQs, as a pending IRQ will cause the
>>suspend to fail */
>>> + omap_ack_irq(0);
>>> regset_save_on_suspend = 1;
>>> omap_sram_idle();
>>> regset_save_on_suspend = 0;
>>> diff --git a/arch/arm/plat-omap/include/mach/irqs.h
>>b/arch/arm/plat-omap/include/mach/irqs.h
>>> index 2473910..d56be1c 100644
>>> --- a/arch/arm/plat-omap/include/mach/irqs.h
>>> +++ b/arch/arm/plat-omap/include/mach/irqs.h
>>> @@ -483,6 +483,7 @@
>>> #ifndef __ASSEMBLY__
>>> extern void omap_init_irq(void);
>>> extern int omap_irq_pending(void);
>>> +extern void omap_ack_irq(unsigned int irq);
>>> void omap3_intc_save_context(void);
>>> void omap3_intc_restore_context(void);
>>> #endif
>>> --
>>> 1.5.4.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>linux-omap" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>--
>>To unsubscribe from this list: send the line "unsubscribe
>>linux-omap" in
>>the body of a message to majord...@vger.kernel.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Fix broken omap-keypad
Hi,
Commit 4f5433324d1e29cf234d5b1b14782c0fc2948298 had made machines that use new
matrix_keypad based drivers happy while breaking those that still use old
omap-keypad driver. The patch fixes omap-keypad device for my Amstrad Delta
(tested) and probably 11 more OMAP1 based machines. It leaves a potential
similiar problem on OMAP2 H4 machine not addressed.
I would say that those new, matrix_keypad based drivers should be corrected to
simply not include arch/arm/plat-omap/include/mach/keypad.h, which should keep
serving omap-keypad based machines until they are all upgraded to use
matrix_keypad.
Created against linux-2.6.32-rc5
Signed-off-by: Janusz Krzysztofik
---
--- linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h.orig
2009-10-16 02:41:50.0 +0200
+++ linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h 2009-10-21
15:32:37.0 +0200
@@ -10,7 +10,9 @@
#ifndef ASMARM_ARCH_KEYPAD_H
#define ASMARM_ARCH_KEYPAD_H
+#ifndef CONFIG_ARCH_OMAP1
#include
+#endif
struct omap_kp_platform_data {
int rows;
@@ -38,5 +40,11 @@ struct omap_kp_platform_data {
#define KEY_PERSISTENT 0x0080
#define KEYNUM_MASK0x00EF
+#ifdef CONFIG_ARCH_OMAP1
+#define KEY(col, row, val) (((col) << 28) | ((row) << 24) | (val))
+#define PERSISTENT_KEY(col, row) (((col) << 28) | ((row) << 24) | \
+ KEY_PERSISTENT)
+#endif
+
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
I'm resending, this time CCing Mark as I should. Janusz --- Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a): > Hi > > On Wed, 21 Oct 2009 05:11:06 +0200 > > Janusz Krzysztofik wrote: > > Hi, > > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > > omap_pcm_prepare() unconditionally calls: > > > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > > > AFAICS, current implementation of those two functions found in > > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 > > at all, so they both end with BUG() on that machine. That seems to result > > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad > > Delta. > > Thanks for reporting the issue. Nobody didn't realize when those calls > were added that indeed they will end up to BUG() in > arch/arm/plat-omap/dma.c on OMAP1. > > > Is calling BUG() for OMAP1 from those functions intentional? > > > > If not intentional, can those be corrected by simply putting break; > > before defalut:? > > I'd let it on as it is as it will point out immediately invalid > argument for OMAP1 and those functions do not have return value. > > > If intentional, can those function calls be conditionally omited, at > > least for OMAP1510, in sound/soc/omap/omap-pcm.c? > > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c > since we should not try to set unsupported burst size for OMAP1. Here you are. Signed-off-by: Janusz Krzysztofik --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.0 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
Kevin Hilman wrote: Hello, I've rebased/updated the PM branch based on current linux-omap master branch (2.6.32-rc1 based.) I've also updated the OMAP Power Management wiki, and the 'Current version' section highlights the changes, supported platforms as well as the features that have made it into mainline. http://elinux.org/OMAP_Power_Management#Current_version Have fun, Kevin Hi Kevin, I am not sure if anyone else if seeing this, but I have noticed that if my root file-system is on an SD card, then if I enable sleep_while_idle and off mode then the system will hang after sometime and eventually the kernel will panic. If my root file-system is mounted over the network, then I see no problems. I have reproduced this problem on both the beagle board and 3430sdp. To reproduce this problem simply enable sleep_while_idle and enable_off_mode, wait sometime and then execute any command such as "ls" to view the file-system. Eventually you should see the below backtrace. Not sure what the problem is but appears to be related to MMC and off mode. Cheers Jon INFO: task mmcqd:400 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. mmcqd D c02c977c 0 400 2 0x Backtrace: [] (schedule+0x0/0x370) from [] (schedule_timeout+0x24/0x21c ) [] (schedule_timeout+0x0/0x21c) from [] (wait_for_common+0xe 4/0x19c) r7:7fff r6:c78d3df4 r5:c78faa40 r4:c78d3db0 [] (wait_for_common+0x0/0x19c) from [] (wait_for_completion+ 0x18/0x1c) [] (wait_for_completion+0x0/0x1c) from [] (mmc_wait_for_req+ 0x124/0x134) [] (mmc_wait_for_req+0x0/0x134) from [] (mmc_blk_issue_rq+0x 1d0/0x734) r5:c78d2000 r4:c78d3e94 [] (mmc_blk_issue_rq+0x0/0x734) from [] (mmc_queue_thread+0x f8/0xfc) [] (mmc_queue_thread+0x0/0xfc) from [] (kthread+0x88/0x90) [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x644) r7: r6: r5: r4: INFO: task kjournald:405 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kjournald D c02c977c 0 405 2 0x Backtrace: [] (schedule+0x0/0x370) from [] (io_schedule+0x44/0x70) [] (io_schedule+0x0/0x70) from [] (sync_buffer+0x4c/0x54) r5:c7907e9c r4: [] (sync_buffer+0x0/0x54) from [] (__wait_on_bit+0x64/0xb0) [] (__wait_on_bit+0x0/0xb0) from [] (out_of_line_wait_on_bit +0x80/0x8c) [] (out_of_line_wait_on_bit+0x0/0x8c) from [] (__wait_on_buf fer+0x28/0x30) [] (__wait_on_buffer+0x0/0x30) from [] (journal_commit_trans action+0xc5c/0x141c) [] (journal_commit_transaction+0x0/0x141c) from [] (kjournal d+0xc4/0x264) [] (kjournald+0x0/0x264) from [] (kthread+0x88/0x90) [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x644) r7: r6: r5: r4: INFO: task ash:427 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. ash D c02c977c 0 427 1 0x Backtrace: [] (schedule+0x0/0x370) from [] (do_get_write_access+0x27c/0 x4b8) [] (do_get_write_access+0x0/0x4b8) from [] (journal_get_writ e_access+0x2c/0x40) [] (journal_get_write_access+0x0/0x40) from [] (__ext3_journ al_get_write_access+0x28/0x58) r5:c7471090 r4: [] (__ext3_journal_get_write_access+0x0/0x58) from [] (ext3_ reserve_inode_write+0x44/0x80) r7:c753fdb0 r6:c7477000 r5:c79b3d24 r4: [] (ext3_reserve_inode_write+0x0/0x80) from [] (ext3_mark_in ode_dirty+0x24/0x44) r7:0115 r6:c79b3d24 r5:c753fdb0 r4:c7477000 [] (ext3_mark_inode_dirty+0x0/0x44) from [] (ext3_dirty_inod e+0x70/0x88) r6:c753fdb0 r5: r4:c7477000 [] (ext3_dirty_inode+0x0/0x88) from [] (__mark_inode_dirty+0 x34/0x15c) r7:0115 r6: r5:c753fdb0 r4:0001 [] (__mark_inode_dirty+0x0/0x15c) from [] (file_update_time+ 0x108/0x124) r7:0115 r6: r5:0003 r4:c753fdb0 [] (file_update_time+0x0/0x124) from [] (__generic_file_aio_ write+0x37c/0x4e4) r8:0608 r7:c753fdb0 r6:001b r5: r4:0623 [] (__generic_file_aio_write+0x0/0x4e4) from [] (generic_fil e_aio_write+0x74/0xd8) [] (generic_file_aio_write+0x0/0xd8) from [] (do_sync_write+ 0xb4/0x104) [] (do_sync_write+0x0/0x104) from [] (vfs_write+0xb8/0x164) r8:001b r7:001b r6:c79b3f70 r5:001d6fa0 r4:c798af00 [] (vfs_write+0x0/0x164) from [] (sys_write+0x44/0x70) r8:001d6fa0 r7:001b r6:c798af00 r5: r4:0608 [] (sys_write+0x0/0x70) from [] (ret_fast_syscall+0x0/0x2c) r8:c0028104 r7:0004 r6:0003 r5:001d6fa0 r4:001b -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] updated PM branch, based on 2.6.32-rc1
Jon Hunter writes: > Kevin Hilman wrote: >> Hello, >> >> I've rebased/updated the PM branch based on current linux-omap master >> branch (2.6.32-rc1 based.) >> >> I've also updated the OMAP Power Management wiki, and the 'Current >> version' section highlights the changes, supported platforms as well >> as the features that have made it into mainline. >> >> http://elinux.org/OMAP_Power_Management#Current_version >> >> Have fun, >> >> Kevin > > Hi Kevin, > > I am not sure if anyone else if seeing this, but I have noticed that > if my root file-system is on an SD card, then if I enable > sleep_while_idle and off mode then the system will hang after sometime > and eventually the kernel will panic. If my root file-system is > mounted over the network, then I see no problems. I have reproduced > this problem on both the beagle board and 3430sdp. > > To reproduce this problem simply enable sleep_while_idle and > enable_off_mode, wait sometime and then execute any command such as > "ls" to view the file-system. Eventually you should see the below > backtrace. > > Not sure what the problem is but appears to be related to MMC and off mode. Right, MMC driver does not yet have OFF mode support enabled. I believe latest series from Adrian Hunter heading upstream should get this working but I have yet to test with PM branch. I think Madhu has done testing of that series with PM branch. Maybe he can report. Kevin > > INFO: task mmcqd:400 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > mmcqd D c02c977c 0 400 2 0x > Backtrace: > [] (schedule+0x0/0x370) from [] > (schedule_timeout+0x24/0x21c > ) > [] (schedule_timeout+0x0/0x21c) from [] > (wait_for_common+0xe > 4/0x19c) > r7:7fff r6:c78d3df4 r5:c78faa40 r4:c78d3db0 > [] (wait_for_common+0x0/0x19c) from [] > (wait_for_completion+ > 0x18/0x1c) > [] (wait_for_completion+0x0/0x1c) from [] > (mmc_wait_for_req+ > 0x124/0x134) > [] (mmc_wait_for_req+0x0/0x134) from [] > (mmc_blk_issue_rq+0x > 1d0/0x734) > r5:c78d2000 r4:c78d3e94 > [] (mmc_blk_issue_rq+0x0/0x734) from [] > (mmc_queue_thread+0x > f8/0xfc) > [] (mmc_queue_thread+0x0/0xfc) from [] > (kthread+0x88/0x90) > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x644) > r7: r6: r5: r4: > INFO: task kjournald:405 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kjournald D c02c977c 0 405 2 0x > Backtrace: > [] (schedule+0x0/0x370) from [] (io_schedule+0x44/0x70) > [] (io_schedule+0x0/0x70) from [] > (sync_buffer+0x4c/0x54) > r5:c7907e9c r4: > [] (sync_buffer+0x0/0x54) from [] > (__wait_on_bit+0x64/0xb0) > [] (__wait_on_bit+0x0/0xb0) from [] > (out_of_line_wait_on_bit > +0x80/0x8c) > [] (out_of_line_wait_on_bit+0x0/0x8c) from [] > (__wait_on_buf > fer+0x28/0x30) > [] (__wait_on_buffer+0x0/0x30) from [] > (journal_commit_trans > action+0xc5c/0x141c) > [] (journal_commit_transaction+0x0/0x141c) from [] > (kjournal > d+0xc4/0x264) > [] (kjournald+0x0/0x264) from [] (kthread+0x88/0x90) > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x644) > r7: r6: r5: r4: > INFO: task ash:427 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > ash D c02c977c 0 427 1 0x > Backtrace: > [] (schedule+0x0/0x370) from [] > (do_get_write_access+0x27c/0 > x4b8) > [] (do_get_write_access+0x0/0x4b8) from [] > (journal_get_writ > e_access+0x2c/0x40) > [] (journal_get_write_access+0x0/0x40) from [] > (__ext3_journ > al_get_write_access+0x28/0x58) > r5:c7471090 r4: > [] (__ext3_journal_get_write_access+0x0/0x58) from > [] (ext3_ > reserve_inode_write+0x44/0x80) > r7:c753fdb0 r6:c7477000 r5:c79b3d24 r4: > [] (ext3_reserve_inode_write+0x0/0x80) from [] > (ext3_mark_in > ode_dirty+0x24/0x44) > r7:0115 r6:c79b3d24 r5:c753fdb0 r4:c7477000 > [] (ext3_mark_inode_dirty+0x0/0x44) from [] > (ext3_dirty_inod > e+0x70/0x88) > r6:c753fdb0 r5: r4:c7477000 > [] (ext3_dirty_inode+0x0/0x88) from [] > (__mark_inode_dirty+0 > x34/0x15c) > r7:0115 r6: r5:c753fdb0 r4:0001 > [] (__mark_inode_dirty+0x0/0x15c) from [] > (file_update_time+ > 0x108/0x124) > r7:0115 r6: r5:0003 r4:c753fdb0 > [] (file_update_time+0x0/0x124) from [] > (__generic_file_aio_ > write+0x37c/0x4e4) > r8:0608 r7:c753fdb0 r6:001b r5: r4:0623 > [] (__generic_file_aio_write+0x0/0x4e4) from [] > (generic_fil > e_aio_write+0x74/0xd8) > [] (generic_file_aio_write+0x0/0xd8) from [] > (do_sync_write+ > 0xb4/0x104) > [] (do_sync_write+0x0/0x104) from [] > (vfs_write+0xb8/0x164) > r8:001b r7:001b r6:c79b3f70 r5:001d6fa0 r4:c798af00 > [] (vfs_write+0x0/0x164) from [] (sys_write+0x44/0x70) > r8:001d6fa0 r7:001b r6:c798af00 r5: r4:0608 > [] (sys_write+0x0/0x70) fro
RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
> -Original Message-
> From: Gopinath, Thara [mailto:th...@ti.com]
> Sent: Tuesday, October 20, 2009 11:37 PM
> To: Kevin Hilman; tero.kri...@nokia.com
> Cc: Ghongdemath, Girish; Woodruff, Richard; linux-omap@vger.kernel.org;
> jouni.hogan...@nokia.com
> Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt
> controller
> >>OMAP3_PRM_VOLTCTRL_OFFSET);
> >>}
> >>+ /* Re-enable interrupt controller autoidle */
> >>+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
>
> Autoidle is being enabled inside the if (core_next_state < PWRDM_POWER_ON).
> This is a bug because it
> is disabled irrespective of core pwr domain state. So if Core domain is on ,
> this code will end up
> not enabling INTC autoidle during resume.
It's outside "if (core_next_state < *)" check in restore path. I see this patch
is dependent on some previous set of patches.
-Girish
>
> >>-Original Message-
> >>From: linux-omap-ow...@vger.kernel.org
> >>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
> >>Hilman
> >>Sent: Tuesday, October 20, 2009 10:02 PM
> >>To: tero.kri...@nokia.com
> >>Cc: Ghongdemath, Girish; Woodruff, Richard; linux-omap@vger.kernel.org;
> >>jouni.hogan...@nokia.com
> >>Subject: Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt
> >>controller
> >>
> >> writes:
> >>
> >>[...]
> >>
> >
> > Anyway, I guess the optimization would look something like this:
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c
> b/arch/arm/mach-omap2/pm34xx.c
> > index 210a806..7a98321 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
> > OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
> > OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
> >
> > +#define INTC_SYSCONFIG 0x10
> > +
> > struct power_state {
> > struct powerdomain *pwrdm;
> > u32 next_state;
> > @@ -505,6 +507,12 @@ void omap_sram_idle(void)
> > prm_set_mod_reg_bits(OMAP3430_EN_IO,
> WKUP_MOD, PM_WKEN);
> > omap3_enable_io_chain();
> > }
> > + /*
> > +* Disable INTC autoidle as it can cause interrupt controller
> > +* to enter unknown state with right combination of
> sleep / wakeup
> > +* transitions
> > +*/
> > + omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
>
> Except omap_write* functions are deprecated.
> >>>
> >>> I see, will use __raw_writel here then.
> >>>
>
> I'd rather see a call into the interrupt code. Something like
> omap_intc_prepare_idle()
> >>>
> >>> Can do these changes to add the interface yes. Though name would be
> >>> omap3_intc_prepare_idle() /
> >>...resume_idle() as this is only needed for OMAP3.
> >>
> >>OK.
> >>
>
> Also, isn't this only needed if CORE != ON?
> >>>
> >>> I understood from the problem description that this is needed always when
> >>> we are entering WFI,
> >>because we might have L3/L4 sleep/run transitions there even if CORE is on.
> >>>
> >>
> >>OK.
> >>
> >>Kevin
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >>the body of a message to majord...@vger.kernel.org
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: Wrong test on unsigned?
regno is unsigned so the test didn't work. If regno
can't be used return an error.
Signed-off-by: Roel Kluin
---
>> Is this correct? please review.
>>
>> diff --git a/drivers/video/omap/omapfb_main.c
>> b/drivers/video/omap/omapfb_main.c
>> index 0d0c8c8..cc7dd93 100644
>> --- a/drivers/video/omap/omapfb_main.c
>> +++ b/drivers/video/omap/omapfb_main.c
>> @@ -286,7 +286,7 @@ static int _setcolreg(struct fb_info
>> *info, u_int regno, u_int red, u_int green,
>> if (r != 0)
>> break;
>>
>> -if (regno < 0) {
>> +if ((int)regno < 0) {
>
> Hmm...
>
> Isn't regno unsigned integer from the start?
yes
> 2 things here:
>
> - regno will never be negative.
> - Casting won't make a difference in the meaning., it'll make a negative only
> when:
>
> regno > ((2^32) / 2)
>
> Which doesn't make any sense IMHO.
I think it is strange that _setcolreg() accepts a regno that is invalid,
ignores it and just returns as if all was OK. If you agree then you may
like the patch below.
> Regards,
> Sergio
Thanks,
Roel
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 0d0c8c8..4da94d0 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -285,12 +285,6 @@ static int _setcolreg(struct fb_info *info, u_int regno,
u_int red, u_int green,
case OMAPFB_COLOR_RGB444:
if (r != 0)
break;
-
- if (regno < 0) {
- r = -EINVAL;
- break;
- }
-
if (regno < 16) {
u16 pal;
pal = ((red >> (16 - var->red.length)) <<
@@ -299,6 +293,8 @@ static int _setcolreg(struct fb_info *info, u_int regno,
u_int red, u_int green,
var->green.offset) |
(blue >> (16 - var->blue.length));
((u32 *)(info->pseudo_palette))[regno] = pal;
+ } else {
+ r = -EINVAL;
}
break;
default:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 21 October, 2009 17:15
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>setup times dynamically in idle loop
>
> writes:
>
>>
>>
>>>-Original Message-
>>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>>Sent: 20 October, 2009 20:48
>>>To: Kristo Tero (Nokia-D/Tampere)
>>>Cc: linux-omap@vger.kernel.org
>>>Subject: Re: [PATCH 16/17] OMAP3: PM: Write voltage and clock
>>>setup times dynamically in idle loop
>>>
>>>Tero Kristo writes:
>>>
From: Tero Kristo
It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in
>>>idle loop.
>>>
>>>Can you summarize the reasons why?
>>
>> Basically this optimizes the clksetup / voltsetup times
>according to the sleep mode. Currently the settings are too
>high in both retention and off-mode, because the hardware
>appears to use for example VOLTSETUP2 even if we are not in
>off-mode, adding extra delay to wakeup. Also, CLKSETUP is too
>high for retention mode because oscillator is not actually
>shut-off here.
>>
>> However, now that I think about it, it might be better to
>change this in a way that it is user configurable whether we
>want to change the settings or not, maybe add new items in to
>the prm_setup struct for alternate settings for ret / off and
>only use these if available. Some boards might actually switch
>oscillator off in retention mode which would require higher setup time.
>>
>>>
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/pm34xx.c | 36
>>>+---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
>>>b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+ /* Write voltage setup times which are changed dynamically */
>>>
>>>AFAICT, we only set these values at init time and they are never
>>>changed. Are there some forthcoming patches that change these
>>>dynamically?
>>
>> Following bit of the code actually changes them dynamically, you can
>> see that e.g. CLKSETUP time is either prm_setup.clksetup or 0x1
>> depending on the sleep mode.
>
>Doh, I see now.
>
>> But as previously said, I think these should probably be added as
>> new items to the prm_setup struct.
>
>Yes, I would rather see the prm_setup struct extended so these can be
>passed in by board code.
I'll change the patch accordingly.
>>>
>>>Kevin
>>>
+ if (core_next_state == PWRDM_POWER_OFF) {
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ } else {
+ prm_write_mod_reg((prm_setup.voltsetup_time2 <<
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (prm_setup.voltsetup_time1 <<
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD,
>>>OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ /*
+ * Use static 1 as only HF_CLKOUT is turned off.
+ * Value taken from application note SWPA152
+ */
+ prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ }
+
/*
* omap3_arm_context is the location where ARM registers
* get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
- /* Write setup times */
- prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
- OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((prm_setup.voltsetup_time2 <<
- OMAP3430_SETUP_TIME2_SHIFT) |
- (prm_setup.voltsetup_time1 <<
- OMAP3430_SETUP_TIME1_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+ /* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(prm_setup
RE: [PATCH] omapfb: Wrong test on unsigned?
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Roel Kluin
> Sent: Wednesday, October 21, 2009 10:44 AM
> To: Aguirre Rodriguez, Sergio Alberto
> Cc: Imre Deak; linux-fbdev-de...@lists.sourceforge.net;
> linux-omap@vger.kernel.org; Andrew Morton
> Subject: Re: [PATCH] omapfb: Wrong test on unsigned?
>
> regno is unsigned so the test didn't work. If regno
> can't be used return an error.
>
> Signed-off-by: Roel Kluin
> ---
> >> Is this correct? please review.
> >>
> >> diff --git a/drivers/video/omap/omapfb_main.c
> >> b/drivers/video/omap/omapfb_main.c
> >> index 0d0c8c8..cc7dd93 100644
> >> --- a/drivers/video/omap/omapfb_main.c
> >> +++ b/drivers/video/omap/omapfb_main.c
> >> @@ -286,7 +286,7 @@ static int _setcolreg(struct fb_info
> >> *info, u_int regno, u_int red, u_int green,
> >>if (r != 0)
> >>break;
> >>
> >> - if (regno < 0) {
> >> + if ((int)regno < 0) {
> >
> > Hmm...
> >
> > Isn't regno unsigned integer from the start?
>
> yes
>
> > 2 things here:
> >
> > - regno will never be negative.
> > - Casting won't make a difference in the meaning., it'll
> make a negative only when:
> >
> > regno > ((2^32) / 2)
> >
> > Which doesn't make any sense IMHO.
>
> I think it is strange that _setcolreg() accepts a regno that
> is invalid,
> ignores it and just returns as if all was OK. If you agree
> then you may
> like the patch below.
Yep. Looks nicer to me ;)
Acked-by: Sergio Aguirre
Regards,
Sergio
>
> > Regards,
> > Sergio
>
> Thanks,
>
> Roel
>
> diff --git a/drivers/video/omap/omapfb_main.c
> b/drivers/video/omap/omapfb_main.c
> index 0d0c8c8..4da94d0 100644
> --- a/drivers/video/omap/omapfb_main.c
> +++ b/drivers/video/omap/omapfb_main.c
> @@ -285,12 +285,6 @@ static int _setcolreg(struct fb_info
> *info, u_int regno, u_int red, u_int green,
> case OMAPFB_COLOR_RGB444:
> if (r != 0)
> break;
> -
> - if (regno < 0) {
> - r = -EINVAL;
> - break;
> - }
> -
> if (regno < 16) {
> u16 pal;
> pal = ((red >> (16 - var->red.length)) <<
> @@ -299,6 +293,8 @@ static int _setcolreg(struct fb_info
> *info, u_int regno, u_int red, u_int green,
> var->green.offset) |
> (blue >> (16 - var->blue.length));
> ((u32 *)(info->pseudo_palette))[regno] = pal;
> + } else {
> + r = -EINVAL;
> }
> break;
> default:
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: Wrong test on unsigned?
Op 21 okt 2009, om 17:43 heeft Roel Kluin het volgende geschreven: Hi, Ajays latest patches make MUSB behave a lot better on beagleboard, but my DVB stick still errors when beginning to stream data (scanning frequencies works): pgd = ced6c000 [] *pgd=8e2b7031, *pte=, *ppte= Internal error: Oops: 817 [#1] Modules linked in: mt2060 dvb_usb_dib0700 dib7000p ipv6 dib7000m dvb_usb dvb_core dib3000mc dibx000_common dib0070 CPU: 0Not tainted (2.6.27-rc7-omap1 #1) PC is at dma_cache_maint+0x40/0xa4 LR is at usb_hcd_submit_urb+0x164/0x870 pc : []lr : []psr: 2013 sp : cee5dca0 ip : cee5dcb0 fp : cee5dcac r10: ce02fca8 r9 : 0020 r8 : r7 : r6 : cf953800 r5 : ce02fca0 r4 : ffc47000 r3 : r2 : 0002 r1 : ffc50a38 r0 : ffc47000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387f Table: 8ed6c018 DAC: 0015 Process w_scan (pid: 1824, stack limit = 0xcee5c2e8) Stack: (0xcee5dca0 to 0xcee5e000) dca0: cee5dd64 cee5dcb0 c01eae34 c0038698 d820 d09ae000 005e dcc0: 60001782 cee5dcd0 c0033830 c003300c 0a23 f03fe03a 0006 0004 dce0: 0007 001d d09ae000 005e c0007420 0003 0002 60001782 dd00: cee5dd78 cee5dd1c c003b1d4 c003b1a0 2013 0001 dd20: cf815eb8 c0634560 d09ae000 c0007420 cee5dd74 c00931cc cf86a400 dd40: 0002 0020 0010 d098606c cf9d77a4 cee5dd84 cee5dd68 dd60: c01eb8bc c01eacdc cf9d7a54 cf9d7a54 0001 cee5dda4 cee5dd88 dd80: bf01faa4 c01eb694 cf9d772c d0872000 0001 0001 cee5ddc4 cee5dda8 dda0: bf01f120 bf01fa8c d0872000 cf9d77f8 cf9d79d0 cee5ddd4 cee5ddc8 ddc0: bf01f1c8 bf01f05c cee5ddf4 cee5ddd8 bf00d448 bf01f1c0 d0986000 dde0: d0986000 cee5de3c cee5ddf8 bf00b694 bf00d34c de00: cee7f5e0 403c6f2b d0986000 d0986008 d0986000 cee5de78 de20: d0986010 0010 d098606c cf9d77e0 cee5de6c cee5de40 bf00ba04 bf00b44c de40: cee5de78 bebf6ae4 cee5de78 403c 403c6f2b 0001 cee6f0e0 de60: cee5df24 cee5de70 bf00a204 bf00b838 cee7f5e0 cee7f5e0 de80: dea0: 0005 c009d184 0003 cee5dec8 dec0: 000192ec 0002 0026 a000 0017 cf80cca0 cf566db8 dee0: 0017 cee5dfb0 bd3c 0101 0001 cee5dfac 403c6f2b df00: bebf6ae4 0004 cee7f5e0 c0033e04 cee5c000 339e1c80 cee5df3c cee5df28 df20: bf00ae60 bf00a128 bf00b82c cee5df54 cee5df40 c00aa988 bf00ae50 df40: cee7f5e0 bebf6ae4 cee5df7c cee5df58 c00aac08 c00aa92c cee5df94 cee5df68 df60: 0004 bebf6ae4 403c6f2b cee7f5e0 cee5dfa4 cee5df80 c00aac58 c00aa9a4 df80: 0005 bebf743c 000192fc 0036 cee5dfa8 dfa0: c0033c80 c00aac24 bebf743c 0004 403c6f2b bebf6ae4 0005 dfc0: bebf743c 000192fc 0036 0001 bebf7b1c 339e1c80 0003 dfe0: 00019188 bebf6ad8 a2a4 400e199c a010 0004 Backtrace: [] (dma_cache_maint+0x0/0xa4) from [] (usb_hcd_submit_urb+0x164/0x870) [] (usb_hcd_submit_urb+0x0/0x870) from [] (usb_submit_urb+0x234/0x250) [] (usb_submit_urb+0x0/0x250) from [] (usb_urb_submit+0x24/0x78 [dvb_usb]) r7: r6:0001 r5:cf9d7a54 r4:cf9d7a54 [] (usb_urb_submit+0x0/0x78 [dvb_usb]) from [] (dvb_usb_ctrl_feed+0xd0/0x14c [dvb_usb]) r7:0001 r6:0001 r5:d0872000 r4:cf9d772c [] (dvb_usb_ctrl_feed+0x0/0x14c [dvb_usb]) from [] (dvb_usb_start_feed+0x14/0x18 [dvb_usb]) r7:cf9d79d0 r6: r5:cf9d77f8 r4:d0872000 [] (dvb_usb_start_feed+0x0/0x18 [dvb_usb]) from [] (dmx_section_feed_start_filtering+0x108/0x150 [dvb_core]) [] (dmx_section_feed_start_filtering+0x0/0x150 [dvb_core]) from [] (dvb_dmxdev_filter_start+0x254/0x3ec [dvb_core]) r7:d0986000 r6: r5:d0986000 r4: [] (dvb_dmxdev_filter_start+0x0/0x3ec [dvb_core]) from [] (dvb_demux_do_ioctl+0x1d8/0x38c [dvb_core]) [] (dvb_demux_do_ioctl+0x0/0x38c [dvb_core]) from [] (dvb_usercopy+0xe8/0x170 [dvb_core]) [] (dvb_usercopy+0x0/0x170 [dvb_core]) from [] (dvb_demux_ioctl+0x1c/0x28 [dvb_core]) [] (dvb_demux_ioctl+0x0/0x28 [dvb_core]) from [] (vfs_ioctl+0x68/0x78) [] (vfs_ioctl+0x0/0x78) from [] (do_vfs_ioctl +0x270/0x280) r5:bebf6ae4 r4:cee7f5e0 [] (do_vfs_ioctl+0x0/0x280) from [] (sys_ioctl +0x40/0x64) r7:cee7f5e0 r6:403c6f2b r5:bebf6ae4 r4:0004 [] (sys_ioctl+0x0/0x64) from [] (ret_fast_syscall +0x0/0x2c) r7:0036 r6:000192fc r5: r4:bebf743c Code: 9a01 e15c0003 3a01 e3a03000 (e5833000) ---[ end trace 64b6e462f7b06513 ]--- Is this a problem with MUSB, omap dma or the dvb stack? I have a dvb stick using similar drivers and I'm seeing similar problems on omap3-musb, omap3-ehci and marvell-kirkwood-ehci, so I suspect the dvb dudes br
Re: [PATCH] Fix broken NAND on Amstrad Delta
* Janusz Krzysztofik [091021 03:54]: > Wednesday 21 October 2009 02:51:35 Tony Lindgren wrote: > > > > Let's just remove the omap_cfg_reg() calls from mach-omap1/serial.c, and > > add them to the board-*.c files like you suggest above. We should be able > > to find which ports to mux by looking at the enabled_uarts mask in the > > commit mentioned above. > > Tony, > I can prepare a patch if you haven't started working on it yet, but please do > me a favour and give your comments on another, old but still not answered > subject: Yes, please do that patch if you can! > http://www.spinics.net/lists/linux-omap/msg17692.html > I have just checked that temporary solution still applies cleanly on top of > 2.6.32-rc5 and corrects the problem of otherwise unusable ASoC over McBSP1 on > my Amstrad Delta. Well let's try to work that in for this coming merge window. How about we rename it to dsp-c55x-common.c? And only do the minimal bits to idle the DSP if called from the board-*.c file? The rest we can move to the old dspgateway branch and rebase that to the current kernel. I think the right way would be to update the dspgateway to use the iommu code, so let's not add similar code except to idle the c55x. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix broken omap-keypad
* Janusz Krzysztofik [091021 07:21]:
> Hi,
> Commit 4f5433324d1e29cf234d5b1b14782c0fc2948298 had made machines that use
> new
> matrix_keypad based drivers happy while breaking those that still use old
> omap-keypad driver. The patch fixes omap-keypad device for my Amstrad Delta
> (tested) and probably 11 more OMAP1 based machines. It leaves a potential
> similiar problem on OMAP2 H4 machine not addressed.
>
> I would say that those new, matrix_keypad based drivers should be corrected to
> simply not include arch/arm/plat-omap/include/mach/keypad.h, which should keep
> serving omap-keypad based machines until they are all upgraded to use
> matrix_keypad.
Hmm, yeah let's try to do that instead.
> Created against linux-2.6.32-rc5
>
> Signed-off-by: Janusz Krzysztofik
>
> ---
> --- linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h.orig
> 2009-10-16 02:41:50.0 +0200
> +++ linux-2.6.32-rc5/arch/arm/plat-omap/include/mach/keypad.h 2009-10-21
> 15:32:37.0 +0200
> @@ -10,7 +10,9 @@
> #ifndef ASMARM_ARCH_KEYPAD_H
> #define ASMARM_ARCH_KEYPAD_H
>
> +#ifndef CONFIG_ARCH_OMAP1
> #include
> +#endif
>
> struct omap_kp_platform_data {
> int rows;
I guess we only need to patch a few board-*.c files currently,
maybe only board-rx51.c?
> @@ -38,5 +40,11 @@ struct omap_kp_platform_data {
> #define KEY_PERSISTENT 0x0080
> #define KEYNUM_MASK 0x00EF
>
> +#ifdef CONFIG_ARCH_OMAP1
> +#define KEY(col, row, val) (((col) << 28) | ((row) << 24) | (val))
> +#define PERSISTENT_KEY(col, row) (((col) << 28) | ((row) << 24) | \
> + KEY_PERSISTENT)
> +#endif
> +
> #endif
>
Maybe we should add:
#warning: Please update the board to use matrix_keypad.h instead
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/17] OMAP3: PM: Ack pending interrupts before entering suspend
>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: 21 October, 2009 17:20
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>before entering suspend
>
> writes:
>
>>>-Original Message-
>>>From: linux-omap-ow...@vger.kernel.org
>>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
>Kevin Hilman
>>>Sent: 20 October, 2009 20:31
>>>To: Kristo Tero (Nokia-D/Tampere)
>>>Cc: linux-omap@vger.kernel.org
>>>Subject: Re: [PATCH 09/17] OMAP3: PM: Ack pending interrupts
>>>before entering suspend
>>>
>>>Tero Kristo writes:
>>>
From: Tero Kristo
Suspending drivers may still generate interrupts just before
>>>their suspend is
completed. Any pending interrupts here will prevent sleep.
Signed-off-by: Tero Kristo
>>>
>>>This could also be done in omap3_intc_prepare_idle() hook.
>>
>> I thought it is better to do this in suspend path only, because in
>> normal sleep case we most likely don't want to miss any
>> interrupts.
>
>Agreed, then I'd suggest doing this in omap3_intc_[suspend|resume]()
>hooks.
>
>> In suspend case, we usually want to enter the suspend no
>> matter what, and this is used here only to clean up the mess left by
>> some of the drivers. The GPT case is one of the main things we try
>> to fix here.
>
>So is this still needed with the GPTIMER fix in PATCH 8/17?
Yeah, it is not enough to ack the interrupt at module level, we still have the
pending IRQ in the interrupt controller itself.
>
>If there are other drivers having delayed interrupt triggering, it
>sounds like the drivers need to be fixed instead of this brute force
>approach.
I think any system device can have similar issue if they receive an interrupt
while we are entering suspend. The main problem is the sequence executed during
suspend: interrupts are disabled before we suspend the system devices (e.g.
clock source) and it is very possible for the devices to receive interrupts
during this window. GPT is a special case because it also has internal
buffering for the register writes, so it continues to tick a while after it is
stopped. GPT is also special in a sense that it can trigger an interrupt at
arbitrary points of time.
I don't know if similar issue exists on other platforms so changing the suspend
sequence itself is probably not an option. And.. acking all interrupts at every
suspending device is probably neither.
-Tero
>
>>
>>>
---
arch/arm/mach-omap2/irq.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/plat-omap/include/mach/irqs.h |1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index aceedd8..4ed05e9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -101,7 +101,7 @@ static int
>omap_check_spurious(unsigned int irq)
}
/* XXX: FIQ and additional INTC support (only MPU at the
>moment) */
-static void omap_ack_irq(unsigned int irq)
+void omap_ack_irq(unsigned int irq)
{
intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
>>>b/arch/arm/mach-omap2/pm34xx.c
index 5854fa7..6a41811 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -778,6 +778,8 @@ static int omap3_pm_suspend(void)
omap_uart_prepare_suspend();
+ /* Ack pending IRQs, as a pending IRQ will cause the
>>>suspend to fail */
+ omap_ack_irq(0);
regset_save_on_suspend = 1;
omap_sram_idle();
regset_save_on_suspend = 0;
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
>>>b/arch/arm/plat-omap/include/mach/irqs.h
index 2473910..d56be1c 100644
--- a/arch/arm/plat-omap/include/mach/irqs.h
+++ b/arch/arm/plat-omap/include/mach/irqs.h
@@ -483,6 +483,7 @@
#ifndef __ASSEMBLY__
extern void omap_init_irq(void);
extern int omap_irq_pending(void);
+extern void omap_ack_irq(unsigned int irq);
void omap3_intc_save_context(void);
void omap3_intc_restore_context(void);
#endif
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe
>>>linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>--
>>>To unsubscribe from this list: send the line "unsubscribe
>>>linux-omap" in
>>>the body of a message to majord...@vger.kernel.org
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP1: fix redundant UARTs pin muxing that can break other hardware support
Wednesday 21 October 2009 02:51:35 Tony Lindgren napisał(a):
>
> Let's just remove the omap_cfg_reg() calls from mach-omap1/serial.c, and
> add them to the board-*.c files like you suggest above. We should be able
> to find which ports to mux by looking at the enabled_uarts mask in the
> commit mentioned above.
Here you are (board-*.c changes limited to those OMAP1510 based).
Created against linux-2.6.32-rc5.
Tested on Amsdtrad Delta only.
Signed-off-by: Janusz Krzysztofik
---
diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-ams-delta.c 2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-ams-delta.c
2009-10-21 17:41:29.0 +0200
@@ -219,6 +219,10 @@ static struct platform_device *ams_delta
static void __init ams_delta_init(void)
{
+ /* setup mux pins for uarts, removed from serial.c */
+ omap_cfg_reg(UART1_TX);
+ omap_cfg_reg(UART1_RTS);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-generic.c
linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-generic.c
--- linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-generic.c 2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-generic.c 2009-10-21
18:15:37.0 +0200
@@ -64,6 +64,14 @@ static void __init omap_generic_init(voi
{
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap15xx()) {
+ /* setup mux pins for uarts, removed from serial.c */
+ omap_cfg_reg(UART1_TX);
+ omap_cfg_reg(UART1_RTS);
+ omap_cfg_reg(UART2_TX);
+ omap_cfg_reg(UART2_RTS);
+ omap_cfg_reg(UART3_TX);
+ omap_cfg_reg(UART3_RX);
+
omap_usb_init(&generic1510_usb_config);
}
#endif
diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-innovator.c
linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-innovator.c
--- linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-innovator.c 2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-innovator.c
2009-10-21 18:16:59.0 +0200
@@ -376,6 +376,24 @@ static void __init innovator_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap1510()) {
+ /* setup mux pins for uarts, removed from serial.c */
+ omap_cfg_reg(UART1_TX);
+ omap_cfg_reg(UART1_RTS);
+ omap_cfg_reg(UART2_TX);
+ omap_cfg_reg(UART2_RTS);
+ omap_cfg_reg(UART3_TX);
+ omap_cfg_reg(UART3_RX);
+
+ reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg |= OMAP1510_FPGA_PCR_COM1_EN;
+ fpga_write(reg, OMAP1510_FPGA_POWER);
+ udelay(10);
+
+ reg = fpga_read(OMAP1510_FPGA_POWER);
+ reg |= OMAP1510_FPGA_PCR_COM2_EN;
+ fpga_write(reg, OMAP1510_FPGA_POWER);
+ udelay(10);
+
platform_add_devices(innovator1510_devices,
ARRAY_SIZE(innovator1510_devices));
spi_register_board_info(innovator1510_boardinfo,
ARRAY_SIZE(innovator1510_boardinfo));
diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-palmte.c
linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-palmte.c
--- linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-palmte.c2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-palmte.c 2009-10-21
17:38:59.0 +0200
@@ -342,6 +342,14 @@ static void __init palmte_misc_gpio_setu
static void __init omap_palmte_init(void)
{
+ /* setup mux pins for uarts, removed from serial.c */
+ omap_cfg_reg(UART1_TX);
+ omap_cfg_reg(UART1_RTS);
+ omap_cfg_reg(UART2_TX);
+ omap_cfg_reg(UART2_RTS);
+ omap_cfg_reg(UART3_TX);
+ omap_cfg_reg(UART3_RX);
+
omap_board_config = palmte_config;
omap_board_config_size = ARRAY_SIZE(palmte_config);
diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-palmtt.c
linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-palmtt.c
--- linux-2.6.32-rc5.orig/arch/arm/mach-omap1/board-palmtt.c2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap1/board-palmtt.c 2009-10-21
17:39:19.0 +0200
@@ -289,6 +289,14 @@ static void __init omap_mpu_wdt_mode(int
static void __init omap_palmtt_init(void)
{
+ /* setup mux pins for uarts, removed from serial.c */
+ omap_cfg_reg(UART1_TX);
+ omap_cfg_reg(UART1_RTS);
+ omap_cfg_reg(UART2_TX);
+ omap_cfg_reg(UART2_RTS);
+ omap_cfg_reg(UART3_TX);
+ omap_cfg_reg(UART3_RX);
+
omap_mpu_wdt_mode(0);
omap_board_config = palmtt_config;
diff -upr
Re: MMC_CAP_SDIO_IRQ for omap 3430
Madhusudhan wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I don't think it is already ready for review. We are still in the "find out how to get sdio irq working" phase. Once we have found out what's needed for this, sure, I will send a patch for review inlined. Best regards Dirk I wonder in the version that John tested was the CTPL bit set in "set_ios" or "enable_sdio_irq"? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby wrote: Richard, MMCHS_CON.CPTL = 1 < Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt> Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 < allow ocp wrapper to generate an interrupt to prcm> MMCHS_HCTL.IWE = 1 < route wake up to module ocp wrapper> MMCHS_CON.CPTL = 1 < Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt> MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE MMCHS_STAT R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC_CAP_SDIO_IRQ for omap 3430
John Rigby wrote: In enable_sdio_irq if enable set ctpl else clear ctpl It would really help avoiding mails like this if you just would send your changes. We know that they are for an old kernel and just a dirty hack. Dirk On Tue, Oct 20, 2009 at 4:47 PM, Madhusudhan wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in "set_ios" or "enable_sdio_irq"? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby wrote: Richard, MMCHS_CON.CPTL = 1 < Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt> Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 < allow ocp wrapper to generate an interrupt to prcm> MMCHS_HCTL.IWE = 1 < route wake up to module ocp wrapper> MMCHS_CON.CPTL = 1 < Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt> MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE MMCHS_STAT R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] omap: add bits for future 3430/3630 ES revisions
>-Original Message-
>From: Paul Walmsley [mailto:p...@pwsan.com]
>Sent: Tuesday, October 20, 2009 6:15 PM
>To: Pandita, Vikram; Woodruff, Richard; Menon, Nishanth
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH v2 1/2] omap: add bits for future 3430/3630 ES revisions
>
>Hi Vikram, Nishanth, Richard,
>
>a few comments on this:
>
>On Tue, 20 Oct 2009, Vikram Pandita wrote:
>
>> Add bits for future expansion of omap_chip_id type field.
>> This is needed to accomodate 3630ES1 chip id which is bit10
>
>...
>
>> diff --git a/arch/arm/plat-omap/include/plat/cpu.h
>> b/arch/arm/plat-omap/include/plat/cpu.h
>> index 7cb0556..922bf1c 100644
>> --- a/arch/arm/plat-omap/include/plat/cpu.h
>> +++ b/arch/arm/plat-omap/include/plat/cpu.h
>> @@ -45,7 +45,7 @@ int omap_type(void);
>>
>> struct omap_chip_id {
>> u8 oc;
>> -u8 type;
>> +u32 type;
>> };
>
>Just wanted to understand the motivation for using the u32.
>
>Earlier in the life of these patches, two comments were mentioned: the
>desire to 'futureproof' and the desire to reserve space for other
>34xx-family parts.
>
>Regarding 'futureproofing:' that's part of the reason that a separate
>struct was defined for this: to prevent code that uses it from depending
>on the size of the type. (Originally it was a typedef, but Linus hates
>typedefs...) So it shouldn't matter how big or small the type is here, as
>long as it can handle all of the bits allocated for it.
>
>Also mentioned was the idea of reserving space for other 34xx-family
>chips. I'd suggest simply renumbering the bits when and if those versions
>appear. Code that uses the omap_chip_id system should always use the
>macros (e.g. CHIP_IS_OMAP3430) and not encode separate bit shift values,
>so renumbering should be completely safe and transparent for core code.
>Module code shouldn't be using the omap_chip code, it's for core usage
>only.
>
>So, since only one bit is being added, why not continue the use of the u8?
>Then when the next bits need to be added, the type can be expanded at that
>point, and the bits renumbered if necessary. This should be a completely
>transparent operation for code that uses it. Vikram's original patch:
>
>http://patchwork.kernel.org/patch/54847/
My preference is to go with version one patch.
As and when required, should we add the bits.
>
>should be fine.
>
>Or am I missing something?
>
>
>- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: [alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
On Wed, Oct 21, 2009 at 04:36:49PM +0200, Janusz Krzysztofik wrote: > I'm resending, this time CCing Mark as I should. This is fine by me but I'd like a proper changelog and if possible an ack from Jarkko please. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: Fix omap-keypad by restoring old keypad.h without breaking omap2 boards that use matrix_keypad
Wednesday 21 October 2009 17:59:40 Tony Lindgren napisał(a): > * Janusz Krzysztofik [091021 07:21]: > > Hi, > > Commit 4f5433324d1e29cf234d5b1b14782c0fc2948298 had made machines that > > use new matrix_keypad based drivers happy while breaking those that still > > use old omap-keypad driver. The patch fixes omap-keypad device for my > > Amstrad Delta (tested) and probably 11 more OMAP1 based machines. It > > leaves a potential similiar problem on OMAP2 H4 machine not addressed. > > > > I would say that those new, matrix_keypad based drivers should be > > corrected to simply not include arch/arm/plat-omap/include/mach/keypad.h, > > which should keep serving omap-keypad based machines until they are all > > upgraded to use matrix_keypad. > > Hmm, yeah let's try to do that instead. > ... > > Maybe we should add: > > #warning: Please update the board to use matrix_keypad.h instead Here you are. Created against linux-2.6.32-rc5. Compile tested with omap_3430sdp_defconfig and rx51_defconfig. Signed-off-by: Janusz Krzysztofik --- diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-3430sdp.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-3430sdp.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-3430sdp.c 2009-10-21 19:28:48.0 +0200 @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include @@ -38,7 +39,6 @@ #include #include -#include #include #include "sdram-qimonda-hyb18m512160af-6.h" diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-ldp.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-ldp.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-ldp.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-ldp.c 2009-10-21 19:30:03.0 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -41,7 +42,6 @@ #include #include #include -#include #include "mmc-twl4030.h" diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-omap3evm.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-omap3evm.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-omap3evm.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-omap3evm.c 2009-10-21 19:30:16.0 +0200 @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -37,7 +38,6 @@ #include #include #include -#include #include "sdram-micron-mt46h32m32lf-6.h" #include "mmc-twl4030.h" diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-omap3pandora.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-omap3pandora.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-omap3pandora.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-omap3pandora.c 2009-10-21 19:28:03.0 +0200 @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -39,7 +40,6 @@ #include #include #include -#include #include #include "sdram-micron-mt46h32m32lf-6.h" diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-rx51-peripherals.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-rx51-peripherals.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-rx51-peripherals.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-rx51-peripherals.c 2009-10-21 19:29:31.0 +0200 @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -27,7 +28,6 @@ #include #include #include -#include #include #include diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-rx51.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-rx51.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-rx51.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-rx51.c 2009-10-21 19:25:33.0 +0200 @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include diff -upr linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-zoom2.c linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-zoom2.c --- linux-2.6.32-rc5.orig/arch/arm/mach-omap2/board-zoom2.c 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/mach-omap2/board-zoom2.c2009-10-21 19:29:52.0 +0200 @@ -13,6 +13,7 @@ #include #include #include +#include #include #include #include @@ -22,7 +23,6 @@ #include #include -#include #include "mmc-twl4030.h" #include "sdram-micron-mt46h32m32lf-6.h" diff -upr linux-2.6.32-rc5.orig/arch/arm/plat-omap/include/mach/keypad.h linux-2.6.32-rc5.fixed/arch/arm/plat-omap/include/mach/keypad.h --- linux-2.6.32-rc5.orig/arch/arm/plat-omap/include/mach/keypad.h 2009-10-16 02:41:50.0 +0200 +++ linux-2.6.32-rc5.fixed/arch/arm/plat-omap
Sitara ARM processor family announcement (v3)
I believe many of you have likely seen the new Sitara ARM product family announcement[1] as part of broadening our ARM product portfolio[2]. This family draws processing cores from the DaVinci family of DSP/multimedia devices and OMAP family of low-power devices and focuses on markets like industrial automation, point-of-sale, medical instrumentation, digital signage, portable data terminals, test & measurement, and single board computers. The important thing is where will the community collaborate on the Linux kernel for these new devices! To help decode the broad number of part numbers and brands, I'm creating a wiki table that shows where TI will be submitting our patches to handle the new devices and as a place holder for frequently asked questions[3]. Regards, Jason Kridner [1] http://www.ti.com/sitara [2] http://www.ti.com/arm [3] http://tiexpressdsp.com/index.php?title=Applications_Processors_Crossreference -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 24xx/n8x0 booting again, linux-omap updated to -rc5
* green [091020 15:09]:
> Tony Lindgren wrote at 2009-10-20 13:56 -0500:
> > * green [091020 09:31]:
> > > But I must be missing something somewhere... I have not yet been able to
> > > get
> > > the N810 to boot. I see only the Nokia splash. Note that I just want to
> > > see
> > > the framebuffer console at this point: I expect a panic due to no root fs.
> > >
> > > Attached is the config I'm using, which is based on n8x0_defconfig.
> >
> > Looks like your config ends up waiting for root on the mmc. But we're
> > missing
> > what was board-n800-mmc.c, so that needs to be updated for mainline.
> > You can find the old code in the omap-2.6.30 branch under
> > arch/arm/mach-omap2
> > if you have the cycles to update it.
>
> I did not expect it to boot, even if mmc was available (no rootfs exists on
> either mmc). But the framebuffer does not seem to be working. I would like
> to
> see a console. Any idea about that?
Well I got took a quick look at it last night to get the LCD working again..
I just pushed one fix into omap-fixes, fixed the drivers/cbus compile, updated
the board-n8x0.c for LCD. And then still needed one more hack to skip the LCD
detection.. The current linux-omap master should work with the two attached
patches and the Kconfig I used. Only tested on n810, no idea if the LCD
detection
hack also works on n800.
Anyways, hopefully that will get you going, I don't know when I'll have
a chance to play with that sfuff again :)
> > Also, the drivers/cbus needs to be updated to get the GPIO pins from
> > board-*.c files, otherwise the retu watchdog will power down the system
> > in 30 seconds.
>
> Yeah, I see the Nokia splash for roughly 30 seconds before the device powers
> off.
I also pushed the earlier changes for retu wdt to the cbus branch so the
boards keep running by default.
Regards,
Tony
>From 9581b39d89b94f2a5834a9b26d7348450c00c98a Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Wed, 21 Oct 2009 11:21:37 -0700
Subject: [PATCH] Enable framebuffer on n8x0
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 764ab1e..bc05ea8 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -29,6 +29,22 @@
#include
#include
#include
+#include
+#include
+#include
+
+#include <../drivers/cbus/tahvo.h>
+
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
+/* REVISIT: Why both this and the omap_lcd_config below? */
+static struct mipid_platform_data n8x0_mipid_platform_data = {
+ .nreset_gpio = 30,
+ .data_lines = 24,
+};
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
@@ -37,6 +53,14 @@ static struct omap2_mcspi_device_config p54spi_mcspi_config = {
static struct spi_board_info n800_spi_board_info[] __initdata = {
{
+ .modalias = "lcd_mipid",
+ .bus_num = 1,
+ .chip_select = 1,
+ .max_speed_hz = 400,
+ .controller_data= &mipid_mcspi_config,
+ .platform_data = &n8x0_mipid_platform_data,
+ },
+ {
.modalias = "p54spi",
.bus_num = 2,
.chip_select = 0,
@@ -45,6 +69,127 @@ static struct spi_board_info n800_spi_board_info[] __initdata = {
},
};
+#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
+
+#define N8X0_BLIZZARD_POWERDOWN_GPIO 15
+
+/* REVISIT: Get rid of the these *_config entries, use platform_data */
+static struct omap_lcd_config n8x0_lcd_config __initdata = {
+ .nreset_gpio = 30,
+ .data_lines = 24,
+ .ctrl_name = "blizzard",
+};
+
+static struct omap_fbmem_config n8x0_fbmem0_config __initdata = {
+ .size = 752 * 1024,
+};
+
+static struct omap_fbmem_config n8x0_fbmem1_config __initdata = {
+ .size = 752 * 1024,
+};
+
+static struct omap_fbmem_config n8x0_fbmem2_config __initdata = {
+ .size = 752 * 1024,
+};
+
+static void mipid_shutdown(struct mipid_platform_data *pdata)
+{
+ if (pdata->nreset_gpio != -1) {
+ pr_info("shutdown LCD\n");
+ gpio_set_value(pdata->nreset_gpio, 0);
+ msleep(120);
+ }
+}
+
+static void __init mipid_dev_init(void)
+{
+ n8x0_mipid_platform_data.shutdown = mipid_shutdown;
+}
+
+static struct {
+ struct clk *sys_ck;
+} blizzard;
+
+static int blizzard_get_clocks(void)
+{
+ blizzard.sys_ck = clk_get(0, "osc_ck");
+ if (IS_ERR(blizzard.sys_ck)) {
+ printk(KERN_ERR "can't get Blizzard clock\n");
+ return PTR_ERR(blizzard.sys_ck);
+ }
+ return 0;
+}
+
+static unsigned long blizzard_get_clock_rate(struct device *dev)
+{
+ return clk_get_rate(blizzard.sys_ck);
+}
+
+static void blizzard_enable_clocks(int enable)
+{
+ if (enable)
+ clk_enable(blizzard.sys_ck);
+ else
+ clk_disable(blizzard.sys_ck);
+}
+
+static void blizzard_power_up(struct device *dev)
+{
+ /* Vcore to 1.475V */
+ tahvo_set_clear_reg_bits(0x07, 0, 0xf);
+ msleep(10);
+
+ blizzard_enable_clocks(1);
+ gpio_set_value(N8X0_BLIZZARD_POWERDOWN_GPIO, 1);
+}
+
+static void blizzard_power_down(struct device *dev)
+{
+ gpio_set_value(N8X0_BLIZZARD_POWERDOWN_GPIO, 0);
+ bl
Re: mmci-omap regressions
Hmm, it seems noone is going to fix it for me, so let's move on...
On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Hi,
>
> * Ladislav Michl [090112 11:19]:
> > Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well
> > on
> > my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently
> > used
> > for production) doesn't work at all. Inspecting diff between 2.6.15-omap2
> > and
> > 2.6.22-omap1 showed that
> > --- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
> > +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +0100
> > @@ -974,7 +974,7 @@
> > * Writing to the CON register twice seems to do the trick. */
> > for (i = 0; i < 2; i++)
> > OMAP_MMC_WRITE(host, CON, dsor);
> > - if (ios->power_mode == MMC_POWER_ON) {
> > + if (ios->power_mode == MMC_POWER_UP) {
> > /* Send clock cycles, poll completion */
> > OMAP_MMC_WRITE(host, IE, 0);
> > OMAP_MMC_WRITE(host, STAT, 0x);
> > did the trick.
> >
> > With above patch applied to 2.6.22-omap1 I got
> > # modprobe omap
> > mmci-omap mmci-omap.1: command timeout, CMD 8
> > mmcblk0: mmc0:0001127104KiB
> > mmcblk0: p1
> > while there is no command timeout with 2.6.15-omap2, but at least it works.
>
> OK, well at least that's a good start on figuring out what has broken
> it. It does not seem like the right fix though as the MMC_POWER_UP
> should just power up the slot, and clocks should not get turned on
> until in MMC_POWER_ON.
>
> > Doing the same modification in current git doesn't help. Moreover removing
> > omap.ko and inserting again behaves differently than inserting for first
> > time:
> > # modprobe omap
> > mmci-omap mmci-omap.0: command timeout (CMD8)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmc0: error -22 whilst initialising MMC card
> > # rmmod omap
> > # modprobe omap
> > mmci-omap: probe of mmci-omap.0 failed with error -16
>
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.
>
> > I'll happily send any requested debug informations and test any patches
>
> Can you maybe try to debug by applying your patch and commenting out
> the goto exit?
Here is somehow working version. It seems sending init stream multiple times
is not good idea. Please note I have no clue how is MMC supposed to work
(except very basic knowledge).
So with the patch (complete patch, see mmc driver fixes I posted earlier today)
below, output looks like:
# modprobe omap
MMC_POWER_OFF
MMC dsor: 0
MMC_POWER_UP
MMC_POWER_ON
MMC dsor: 878
time elapsed: 254us
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 803
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 D0601 122 MiB
mmcblk0:
p1
Note, that "command timeout" is still there, but at least it detect card and
also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
actually more than 200us.
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..0bcd6b0 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -123,15 +123,16 @@ struct mmc_omap_host {
struct mmc_data * data;
struct mmc_host * mmc;
struct device * dev;
- unsigned char id; /* 16xx chips have 2 MMC blocks */
struct clk *iclk;
struct clk *fclk;
struct resource *mem_res;
void __iomem*virt_base;
unsigned intphys_base;
int irq;
+ unsigned char id; /* 16xx chips have 2 MMC blocks */
unsigned char bus_mode;
unsigned char hw_bus_mode;
+ unsigned char power_mode;
struct work_struct cmd_abort_work;
unsignedabort:1;
@@ -1233,7 +1234,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct mmc_omap_slot *slot = mmc_priv(mmc);
struct mmc_omap_host *host = slot->hos
Re: [Resend PATCH 2/2] twl4030: Enable low-power mode to 32kHz oscillator
Hi Ilkka,
On Tue, Oct 20, 2009 at 04:22:53PM +0300, Ilkka Koskinen wrote:
> +struct twl4030_clock_init_data {
> + int ck32k_lowpwr_enable;
I guess you could use a bool here ?
Cheers,
Samuel.
> +};
> +
> struct twl4030_bci_platform_data {
> int *battery_tmp_tbl;
> unsigned int tblsize;
> @@ -403,6 +407,7 @@ extern void twl4030_power_init(struct twl4030_power_data
> *triton2_scripts);
>
> struct twl4030_platform_data {
> unsignedirq_base, irq_end;
> + struct twl4030_clock_init_data *clock;
> struct twl4030_bci_platform_data*bci;
> struct twl4030_gpio_platform_data *gpio;
> struct twl4030_madc_platform_data *madc;
> --
> 1.6.0.4
>
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend PATCH 1/2] twl4030: Do not dereference null pointer in error path
Hi Ilkka,
On Tue, Oct 20, 2009 at 04:22:52PM +0300, Ilkka Koskinen wrote:
> Signed-off-by: Ilkka Koskinen
Patch applied to my for-linus and for-next branches.
I'll try to get that one merged for 2.6.32.
Cheers,
Samuel.
> ---
> drivers/mfd/twl4030-core.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
> index e424cf6..8cf0a02 100644
> --- a/drivers/mfd/twl4030-core.c
> +++ b/drivers/mfd/twl4030-core.c
> @@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> twl->client = i2c_new_dummy(client->adapter,
> twl->address);
> if (!twl->client) {
> - dev_err(&twl->client->dev,
> + dev_err(&client->dev,
> "can't attach client %d\n", i);
> status = -ENOMEM;
> goto fail;
> --
> 1.6.0.4
>
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core
Hi Peter,
On Mon, Oct 19, 2009 at 03:42:17PM +0300, Peter Ujfalusi wrote:
> New MFD child to twl4030 MFD device.
> This MFD device will be used by the drivers, which needs resources
> from the twl4030 codec like audio and vibra.
>
> The platform specific configuration data is passed along to the
> child drivers (audio, vibra).
Some comments on your code:
> +config TWL4030_CODEC
> + bool "Support codec part of the TWL4030 family chips"
> + depends on TWL4030_CORE
> + help
> + Say yes here if you want to use the codec resources on the
> + TWL4030 family chips. The codec in TWL4030 provides the audio
> + functionality and also has the vibrator controls.
> +
> + This driver provides MFD device to be used for drivers, which needs
> + access to the codec part, the board-specific data is passed from this
> + driver to the childs as platform data with the board specific
> + configuration.
> +
As Mark noticed already, you dont really want users to explicitely select this
obscure mfd driver to get their audio and vibre driver selectable. It should
be the other way around, and I think you already agreed with that.
> +static struct device *
> +twl4030_codec_new_child(const char *name, void *pdata, unsigned pdata_len)
> +{
> + struct platform_device *pdev;
> + int status = 0;
> +
> + pdev = platform_device_alloc(name, -1);
> + if (!pdev) {
> + dev_dbg(&twl4030_codec_dev->dev, "can't alloc dev (%s)\n",
> + name);
> + return ERR_PTR(-ENOMEM);
> + }
> + pdev->dev.parent = &twl4030_codec_dev->dev;
> +
> + if (pdata) {
> + status = platform_device_add_data(pdev, pdata, pdata_len);
> + if (status < 0) {
> + dev_dbg(&pdev->dev, "can't add platform_data\n");
> + goto err;
> + }
> + }
> + status = platform_device_add(pdev);
> + if (status < 0) {
> + dev_dbg(&pdev->dev, "Adding platform device failed\n");
> + goto err;
> + }
> +
> + return &pdev->dev;
> +err:
> + platform_device_put(pdev);
> + dev_err(&twl4030_codec_dev->dev, "can't add %s dev\n", name);
> + return ERR_PTR(status);
> +}
This could really use the mfd-core API, and avoid duplicating code.
You just would have to define a couple cells, and call mfd_add_devices on
them.
> +static int __devexit twl4030_codec_remove(struct platform_device *pdev)
> +{
> + struct twl4030_codec *codec = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> + kfree(codec);
> + twl4030_codec_dev = NULL;
> +
> + return 0;
> +}
I think you're missing a platform_device_unregister() here (or an
mfd_remove_devices() if you're going to switch to the mfd-core API)
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: timekeeping: time should not stop during suspend
Kevin Hilman writes:
> During suspend, the kernel timekeeping subsystem is shut down. Before
> suspend and upon resume, it uses a weak function
> read_persistent_clock() to determine the amount of time that elapsed
> during suspend.
>
> This function was not implemented on OMAP, so from the timekeeping
> subsystem perspective (and thus userspace as well) it appeared that no
> time elapsed during suspend.
>
> This patch uses the 32k sync timer as a the persistent clock the 32k
> sync timer value converted to seconds.
>
> NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
> wrapping of the 32k sync timer during suspend may cause
> problems. Also, there are not interrupts when the 32k sync
> timer wraps, so something else has to be done.
>
> Reported-by: Jon Hunter
> Signed-off-by: Kevin Hilman
> ---
> Tested on OMAP3 using PM branch.
> If no issues, I will queue for 2.6.32-rc fixes
oops, forgot about this one. Will queue in PM branch fixes.
Kevin
> arch/arm/plat-omap/common.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
> index b3f70e6..3e4325b 100644
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
> return ret;
> }
>
> +/**
> + * read_persistent_clock - Return time in seconds from the persistent clock.
> + */
> +unsigned long read_persistent_clock(void)
> +{
> + unsigned long long ret;
> + cycle_t cycles;
> +
> + cycles = clocksource_32k.read(&clocksource_32k);
> + ret = (cycles * clocksource_32k.mult_orig) >> clocksource_32k.shift;
> + do_div(ret, NSEC_PER_SEC);
> +
> + return (unsigned long)ret;
> +}
> +
> static int __init omap_init_clocksource_32k(void)
> {
> static char err[] __initdata = KERN_ERR
> --
> 1.6.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP1: AMS_DELTA: Fix DSP public peripherals support
DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?)
machines as long as old dspgateway code were present in the l-o tree. For
several months it is no longer included, breaking support for McBSP1 based
audio on Amstrad Delta, for example.
This patch, derived from the old dspgateway code, corrects the problem for the
board by simply taking the DSP out of reset state, I guess. That way, things
should not break when a new dsp code is added to the tree, and the change can
be reverted then.
If there are any reports on McBSP1 or other DSP public peripherals not working
for other OMAP1 machines (I've not heard of any for now), I can prepare a more
general patch providing an extra include file with a helper function defined.
Created and tested against linux-2.6.32-rc5
Signed-off-by: Janusz Krzysztofik
---
--- linux-2.6.32-rc5/arch/arm/mach-omap1/board-ams-delta.c.orig 2009-10-22
00:55:49.0 +0200
+++ linux-2.6.32-rc5/arch/arm/mach-omap1/board-ams-delta.c 2009-10-22
01:46:39.0 +0200
@@ -235,6 +235,8 @@ static void __init ams_delta_init(void)
omap_usb_init(&ams_delta_usb_config);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
+
+ omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] updated mach-types file
this patch updates the auto-generated mach-types file to enable addition of 3630 boards: 1) zoom3 2) sdp3630 Signed-off-by: Vikram Pandita --- Tony: Could you Temporarily host this patch on linux-omap tree till rmk pulls in mach-types. This would allow us to add 3630 board files arch/arm/tools/mach-types | 54 - 1 files changed, 53 insertions(+), 1 deletions(-) diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types index 94be7bb..0160378 100644 --- a/arch/arm/tools/mach-types +++ b/arch/arm/tools/mach-types @@ -12,7 +12,7 @@ # # http://www.arm.linux.org.uk/developer/machines/?action=new # -# Last update: Fri Sep 18 21:42:00 2009 +# Last update: Wed Oct 21 15:33:08 2009 # # machine_is_xxx CONFIG_ MACH_TYPE_xxx number # @@ -2421,3 +2421,55 @@ liberty MACH_LIBERTYLIBERTY 2434 mh355 MACH_MH355 MH355 2435 pc7802 MACH_PC7802 PC7802 2436 gnet_sgc MACH_GNET_SGC GNET_SGC2437 +einstein15 MACH_EINSTEIN15 EINSTEIN15 2438 +cmpd MACH_CMPD CMPD2439 +davinci_hase1 MACH_DAVINCI_HASE1 DAVINCI_HASE1 2440 +lgeincitephone MACH_LGEINCITEPHONE LGEINCITEPHONE 2441 +ea313x MACH_EA313X EA313X 2442 +fwbd_39064 MACH_FWBD_39064 FWBD_39064 2443 +fwbd_390128MACH_FWBD_390128FWBD_390128 2444 +pelco_moe MACH_PELCO_MOE PELCO_MOE 2445 +minimix27 MACH_MINIMIX27 MINIMIX27 2446 +omap3_thunder MACH_OMAP3_THUNDER OMAP3_THUNDER 2447 +passionc MACH_PASSIONC PASSIONC2448 +mx27amata MACH_MX27AMATA MX27AMATA 2449 +bgat1 MACH_BGAT1 BGAT1 2450 +buzz MACH_BUZZ BUZZ2451 +mb9g20 MACH_MB9G20 MB9G20 2452 +yushan MACH_YUSHAN YUSHAN 2453 +lizard MACH_LIZARD LIZARD 2454 +omap3polycom MACH_OMAP3POLYCOM OMAP3POLYCOM2455 +smdkv210 MACH_SMDKV210 SMDKV2102456 +bravo MACH_BRAVO BRAVO 2457 +siogentoo1 MACH_SIOGENTOO1 SIOGENTOO1 2458 +siogentoo2 MACH_SIOGENTOO2 SIOGENTOO2 2459 +sm3k MACH_SM3K SM3K2460 +acer_tempo_f900MACH_ACER_TEMPO_F900ACER_TEMPO_F900 2461 +sst61vc010_dev MACH_SST61VC010_DEV SST61VC010_DEV 2462 +glittertindMACH_GLITTERTINDGLITTERTIND 2463 +omap_zoom3 MACH_OMAP_ZOOM3 OMAP_ZOOM3 2464 +omap_3630sdp MACH_OMAP_3630SDP OMAP_3630SDP2465 +cybook2440 MACH_CYBOOK2440 CYBOOK2440 2466 +torino_s MACH_TORINO_S TORINO_S2467 +havana MACH_HAVANA HAVANA 2468 +beaumont_11MACH_BEAUMONT_11BEAUMONT_11 2469 +vanguard MACH_VANGUARD VANGUARD2470 +s5pc110_draco MACH_S5PC110_DRACO S5PC110_DRACO 2471 +cartesio_two MACH_CARTESIO_TWO CARTESIO_TWO2472 +aster MACH_ASTER ASTER 2473 +voguesv210 MACH_VOGUESV210 VOGUESV210 2474 +acm500xMACH_ACM500XACM500X 2475 +km9260 MACH_KM9260 KM9260 2476 +nideflexg1 MACH_NIDEFLEXG1 NIDEFLEXG1 2477 +ctera_plug_io MACH_CTERA_PLUG_IO CTERA_PLUG_IO 2478 +smartq7MACH_SMARTQ7SMARTQ7 2479 +at91sam9g10ek2 MACH_AT91SAM9G10EK2 AT91SAM9G10EK2 2480 +asusp527 MACH_ASUSP527 ASUSP5272481 +at91sam9g20mpm2MACH_AT91SAM9G20MPM2AT91SAM9G20MPM2 2482 +topasa900 MACH_TOPASA900 TOPASA900 2483 +electrum_100 MACH_ELECTRUM_100 ELECTRUM_1002484 +mx51grbMACH_MX51GRBMX51GRB 2485 +xea300 MACH_XEA300 XEA300 2486 +htcstartrek
Re: [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core
On Thursday 22 October 2009 02:13:11 ext Samuel Ortiz wrote:
> As Mark noticed already, you dont really want users to explicitely select
> this obscure mfd driver to get their audio and vibre driver selectable. It
> should be the other way around, and I think you already agreed with that.
Yes, I have already made the modification.
>
> > +static struct device *
> > +twl4030_codec_new_child(const char *name, void *pdata, unsigned
> > pdata_len) +{
...
> This could really use the mfd-core API, and avoid duplicating code.
> You just would have to define a couple cells, and call mfd_add_devices on
> them.
Good point. When I wrote this driver I have been looking at the twl4030-core
driver, which is not using the mfd-core API. I'll make the change.
>
> > +static int __devexit twl4030_codec_remove(struct platform_device *pdev)
> > +{
> > + struct twl4030_codec *codec = platform_get_drvdata(pdev);
> > +
> > + platform_set_drvdata(pdev, NULL);
> > + kfree(codec);
> > + twl4030_codec_dev = NULL;
> > +
> > + return 0;
> > +}
>
> I think you're missing a platform_device_unregister() here (or an
> mfd_remove_devices() if you're going to switch to the mfd-core API)
You are right, although I have used the bool in the Kconfig for the twl4030-
codec in a same way as the twl4030-core (and the core did not unregister the
devices either), but yes, this is not correct so I'll fix it.
I have now question about the practicalities on how this series would be taken,
and via which tree.
The final patch for the soc codec driver depends on the change in MFD and in
the
OMAP board files.
The change in the OMAP board files depends on the MFD changes, obviously.
So in order to have the soc codec changes the MFD and OMAP part has to be
applied before, otherwise the audio will be broken.
the mfd-2.6:for-next branch has some patches against the twl4030-core in
addition to the ones in l-o and in sound-2.6:topic/asoc.
I'll check, if the MFD patch applies to mfd-2.6:for-next also, but to have the
soc codec changes the MFD patch should go to the sound-2.6 tree as well to make
sure it is not braking things.
All-in-all, how these things can be handled?
Thanks,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
>>-Original Message- >>From: linux-omap-ow...@vger.kernel.org >>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin >>Hilman >>Sent: Wednesday, October 21, 2009 7:21 PM >>To: Gulati, Shweta >>Cc: linux-omap@vger.kernel.org >>Subject: Re: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on >>OMAP3430 >> >>"Gulati, Shweta" writes: >> >>> Any comments would be taken in. >> >>Sorry, I did not see this v2 on the list nor do I find it in the archives. >> >>> -Original Message- >>> From: Gulati, Shweta >>> Sent: Tuesday, October 13, 2009 3:56 PM >>> To: linux-omap@vger.kernel.org >>> Cc: Gulati, Shweta; Gopinath, Thara >>> Subject: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on >>> OMAP3430 >>> >>> From: Shweta Gulati >>> >>> (Resending the patch with the subject line and some minor fixes) >>> >>> According to Silicon Bug on context restore it is found that the pad >>> configuration register for GPIO_28/GPIO_29(ETKD14/15) is corrupted after >>> returning from Core OFF mode. This happens if the MPU reads the >>> PADCONF_SAVEDONE bit very close to the end of context save sequence >>> for the pad conf registers, resulting in last context not being saved to the >>> scratchpad memory. This is a h/w bug. The workaround is to delay the >>> MPU access of SAVEDONE bit until the last context has been saved. >>> >>> This patch adds a configuration option to allow 300 us delay in >>> save path as recommended by TI. The other option is to let the >>> bug occur but store the value of pad configuration register explicitly >>> and write it back in resume path. But this option should be chosen >>> only if the ETKD14/15 pads are not in use as this workaround can >>> lead to glitch in the pin. >>> >>> Signed-off-by: Shweta Gulati >>> Signed-off-by: Thara Gopinath >> >>Is this patch still needed with this fix recently postd by Nokia: >> >> http://marc.info/?l=linux-omap&m=125569123004013&w=2 This patch is still needed. The problem is with accessing SAVEDONE bit while the save is happening. >> >>Also, this description is still missing the Errata reference. After >>reading the errata, I don't think a Kconfig option is the right >>answer. Rather, the delay should be inserted iff the pin is enabled, >>set as output, and set to high. Why should this affect only if the pin is output and set to high? The problem is the padconf values for this pin will not be saved and any junk can be restored back irrespective of what state the pin was configured to be in. There is no errata released for this yet. 300 us was found by the Silicon team to be a safe value and was recommended to be used. This will probably be formally relased as an errata in a while. Also 300 us might get optimized. But this is the available fix today as per h/w recommendations. We can probably put a comment as per errata xyz where xyz can be populated later. >> >>Also, the errata makes no mention of the 300usec delay. Please describe >>how that number was decided on. >> >>Re: Subject, would be better as >> >>OMAP3: PM: PADCONF restore fix for Errata x.xxx >> >>> --- arch/arm/mach-omap2/pm34xx.c | 25 + >>> arch/arm/plat-omap/Kconfig | 17 + 2 files changed, >>> 42 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c >>> index cea3bca..4f9671a 100644 >>> --- a/arch/arm/mach-omap2/pm34xx.c >>> +++ b/arch/arm/mach-omap2/pm34xx.c >>> @@ -26,6 +26,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include >>> @@ -54,10 +55,19 @@ >>> >>> static int regset_save_on_suspend; >>> >>> +/* A extra variable to store value of pad_config register if >>> + * delay is not to be inserted and value is explicitly restored >>> + * in resume path. >>> + */ >>> +#ifndef CONFIG_DELAY_IN_PADCONF_SAVE >>> +static u32 store_pad_config; >>> +#endif >>> + >>> /* Scratchpad offsets */ >>> #define OMAP343X_TABLE_ADDRESS_OFFSET 0x31 >>> #define OMAP343X_TABLE_VALUE_OFFSET 0x30 >>> #define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32 >>> +#define CONTROL_PADCONF_ETK_D140x480025F8 >>> >>> u32 enable_off_mode; >>> u32 sleep_while_idle; >>> @@ -202,6 +212,17 @@ static void omap3_core_save_context(void) >>> omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF); >>> control_padconf_off |= START_PADCONF_SAVE; >>> omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF); >>> +#ifndef CONFIG_DELAY_IN_PADCONF_SAVE >>> + store_pad_config = omap_readl(CONTROL_PADCONF_ETK_D14); >> >>omap_read* deprecated. Use omap_ctrl_readl() as is done in >>the rest of the code. >> >>> +#else >>> + /* Due to Silicon Bug on context restore it is found >>> +* that the CONTROL_PAD_CONF_ETK14 register is not saved into >>> +* scratch pad memory sometimes. To rectify it delay acess by Mpu >>> +* for 300us for scm to finish saving task >>> +*/ >>> + udelay
