RE: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
> From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, June 18, 2009 4:07 PM Hi Paul, > On Wed, 17 Jun 2009, Woodruff, Richard wrote: > > > I've only seen the condition along side of very aggressive SDRC_POWER > > settings. > > Could you send over the SDRC_POWER settings that cause this problem? This is one pulled for a custom board: # ./readmem 0x6d70 0x000200AD 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 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
Hello, On Fri, 19 Jun 2009, Russell King - ARM Linux wrote: > On Thu, Jun 18, 2009 at 08:48:47AM +0300, Tony Lindgren wrote: > > Paul, can you please post a git pull request for Russell on these? > > I think these should still go in if possible. > > > > Russell, if you think it's too late, I'll pile them up into omap > > for-next branch. > > Let's merge them. The following changes since commit cd07ecc828486e5887113c7dc4d9f9022145811b: Tony Lindgren (1): Merge branch 'omap4' into for-next are available in the git repository at: git://git.pwsan.com/linux-2.6 omap-clock-for-next Paul Walmsley (7): OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize OMAP3 clock: initialize SDRC timings at kernel start OMAP3 clock: add a short delay when lowering CORE clk rate OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock change OMAP3 SRAM: add more comments on the SRAM code OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLL Roel Kluin (1): OMAP2 clock/powerdomain: off by 1 error in loop timeout comparisons Tero Kristo (1): OMAP3: Add support for DPLL3 divisor values higher than 2 arch/arm/mach-omap2/clock.c|2 +- arch/arm/mach-omap2/clock34xx.c| 42 --- arch/arm/mach-omap2/io.c | 36 + arch/arm/mach-omap2/powerdomain.c |2 +- arch/arm/mach-omap2/sram34xx.S | 129 +--- arch/arm/plat-omap/include/mach/sram.h |6 +- arch/arm/plat-omap/sram.c |8 +- 7 files changed, 163 insertions(+), 62 deletions(-) - 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
[PATCH][RFC] OMAP3: PM: Prevent hang in prcm_interrupt_handler
From: Jon Hunter
There are two scenarios where a race condition could result in a hang in the
prcm_interrupt handler. These are:
1). Waiting for PRM_IRQSTATUS_MPU register to clear.
Bit 0 of the PRM_IRQSTATUS_MPU register indicates that a wake-up event is
pending for the MPU. This bit can only be cleared if the all the wake-up events
latched in the various PM_WKST_x registers have been cleared. If a wake-up event
occurred during the processing of the prcm interrupt handler, after the
corresponding PM_WKST_x register was checked but before the PRM_IRQSTATUS_MPU
was cleared, then the CPU would be stuck forever waiting for bit 0 in
PRM_IRQSTATUS_MPU to be cleared.
2). Waiting for the PM_WKST_x register to clear.
Some power domains have more than one wake-up source. The PM_WKST_x registers
indicate the source of a wake-up event and need to be cleared after a wake-up
event occurs. When the PM_WKST_x registers are read and before they are cleared,
it is possible that another wake-up event could occur causing another bit to be
set in one of the PM_WKST_x registers. If this did occur after reading a
PM_WKST_x register then the CPU would miss this event and get stuck forever in
a loop waiting for that PM_WKST_x register to clear.
This patch address the above race conditions that would result in a hang.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pm34xx.c | 169 +++---
1 files changed, 94 insertions(+), 75 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7a4a525..0545262 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -200,91 +200,110 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
u32 wkst, irqstatus_mpu;
u32 fclk, iclk;
- /* WKUP */
- wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
- if (wkst) {
- iclk = cm_read_mod_reg(WKUP_MOD, CM_ICLKEN);
- fclk = cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
- cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_ICLKEN);
- cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_FCLKEN);
- prm_write_mod_reg(wkst, WKUP_MOD, PM_WKST);
- while (prm_read_mod_reg(WKUP_MOD, PM_WKST))
- cpu_relax();
- cm_write_mod_reg(iclk, WKUP_MOD, CM_ICLKEN);
- cm_write_mod_reg(fclk, WKUP_MOD, CM_FCLKEN);
- }
-
- /* CORE */
- wkst = prm_read_mod_reg(CORE_MOD, PM_WKST1);
- if (wkst) {
- iclk = cm_read_mod_reg(CORE_MOD, CM_ICLKEN1);
- fclk = cm_read_mod_reg(CORE_MOD, CM_FCLKEN1);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_ICLKEN1);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_FCLKEN1);
- prm_write_mod_reg(wkst, CORE_MOD, PM_WKST1);
- while (prm_read_mod_reg(CORE_MOD, PM_WKST1))
- cpu_relax();
- cm_write_mod_reg(iclk, CORE_MOD, CM_ICLKEN1);
- cm_write_mod_reg(fclk, CORE_MOD, CM_FCLKEN1);
- }
- wkst = prm_read_mod_reg(CORE_MOD, OMAP3430ES2_PM_WKST3);
- if (wkst) {
- iclk = cm_read_mod_reg(CORE_MOD, CM_ICLKEN3);
- fclk = cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- cm_set_mod_reg_bits(wkst, CORE_MOD, CM_ICLKEN3);
- cm_set_mod_reg_bits(wkst, CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- prm_write_mod_reg(wkst, CORE_MOD, OMAP3430ES2_PM_WKST3);
- while (prm_read_mod_reg(CORE_MOD, OMAP3430ES2_PM_WKST3))
- cpu_relax();
- cm_write_mod_reg(iclk, CORE_MOD, CM_ICLKEN3);
- cm_write_mod_reg(fclk, CORE_MOD, OMAP3430ES2_CM_FCLKEN3);
- }
+ do {
+ /* WKUP */
+ wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
+ if (wkst) {
+ iclk = cm_read_mod_reg(WKUP_MOD, CM_ICLKEN);
+ fclk = cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
+ while (wkst) {
+ cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_ICLKEN);
+ cm_set_mod_reg_bits(wkst, WKUP_MOD, CM_FCLKEN);
+ prm_write_mod_reg(wkst, WKUP_MOD, PM_WKST);
+ wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
+ }
+ cm_write_mod_reg(iclk, WKUP_MOD, CM_ICLKEN);
+ cm_write_mod_reg(fclk, WKUP_MOD, CM_FCLKEN);
+ }
- /* PER */
- wkst = prm_read_mod_reg(OMAP3430_PER_MOD, PM_WKST);
- if (wkst) {
- iclk = cm_read_mod_reg(OMAP3430_PER_MOD, CM_ICLKEN);
- fclk = cm_read_mod_reg(OMAP3430_PER_MOD, CM_FCLKEN);
- cm_set_mod_reg_bits(wkst, OMAP3430_PER_MOD, CM_ICLKEN);
- cm_set_mod_reg_bits(wkst, OMAP3430_PER_MOD, CM_FCLKEN);
- prm_write_mod_reg(wkst, OMAP3430
Re: Please help in adding ams-delta support to ASoC
On Fri, Jun 19, 2009 at 4:20 AM, Janusz Krzysztofik wrote: > Tony Lindgren wrote: >> >> * Janusz Krzysztofik [090618 14:52]: >>> >>> Tony Lindgren wrote: On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up. >>> >>> AFAICS there is no DSP code in mainline at all, so the answer is no, DSP >>> was likely not powered up at all. For several weeks I was trying to do >>> what was impossible :/. But fortunatelly, I have learned a lot ;). >> >> We at least used to have code to power and idle the DSP even without the >> dspgateway compiled in.. Sorry I don't remember the details. But most >> likely you need to have the dspgateway patch enabled. > > Tony, > Thanks for clarifying things. > > Arun K S wrote: >> >> On Thu, Jun 18, 2009 at 4:40 AM, Janusz >> Krzysztofik wrote: >>> >>> ... I retried the new driver on commit >>> 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly >>> seen >>> hangup. I found that it was omap_mcbsp_request() never returning back >>> from. >> >> I faced the same issue while writing ASoC driver for tlv320aic23b codec. >> >> You can have a look at this thread: >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg03852.html >> >> It may help. > > Arun, > Thanks, it's good to hear not only me having this problem ;). So what is the > current status of your osk driver? What tree do you use, what extra patches > do you apply to make it actually working? Currently osk driver works fine on 2.6.31. Initially i used to add the omap_mcbsp_request() at the boot time, other wise it hangs up. Audio in current mainline tree works fine for osk5912 with out any such hacks. I believe there are some patches from Russel for the DSP memory mapping during 2.6.29 kernel. > > --- > > After all, could someone please give me an advise, what tree, even with > buggy omap1510 mcbsp/dsp support, should I base my work on for best results? > Omap? Sound? Mainline? I mean not only easy getting the driver working, but > also giving it the best possible path into the mainline. You have to use current omap tree with the patches from current sound tree(ASoC omap platform drivers changes) for testing the driver. Somebody correct me if i am wrong. > > 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
Re: [PATCH] initialize gpio debounce register
ye janboe writes: > Hi, > some bootloader may initialize debounce register and this will make > dbclk not consist with the debounce register after linux kernel boot > up. > > From 8f97e5b50e50627e9e4b40f5d4fba09d750aceb1 Mon Sep 17 00:00:00 2001 > From: janboe > Date: Fri, 19 Jun 2009 10:56:02 -0500 > Subject: [PATCH] initialize gpio debounce register > > Signed-off-by: janboe Signed-off-by: Kevin Hilman Tony, this should go into -fixes. Kevin > --- > arch/arm/plat-omap/gpio.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c > index 7fd89ba..26b387c 100644 > --- a/arch/arm/plat-omap/gpio.c > +++ b/arch/arm/plat-omap/gpio.c > @@ -1585,6 +1585,7 @@ static int __init _omap_gpio_init(void) > __raw_writel(0x, bank->base + > OMAP24XX_GPIO_IRQENABLE1); > __raw_writel(0x, bank->base + > OMAP24XX_GPIO_IRQSTATUS1); > __raw_writew(0x0015, bank->base + > OMAP24XX_GPIO_SYSCONFIG); > + __raw_writel(0x, bank->base + > OMAP24XX_GPIO_DEBOUNCE_EN); > > /* Initialize interface clock ungated, module enabled */ > __raw_writel(0, bank->base + OMAP24XX_GPIO_CTRL); > -- > 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
Missing OMAP nand drivers from 2.6.30?
Looking at the current linux-omap tree from yesterday, I'm wondering where the NAND chip driver for the OMAP34x/35x is. It used to be in drivers/mtd/nand/omap2.c, but there's no trace of it now (that I can find). Any ideas where it went? -- Peter Barada Logic Product Development, Inc. -- 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] usb: disable OTG AUTOIDLE only with omap3430
Things considering tranceiver suspend/wakeup are welcom, cause it seems to be mysteric, how to operate with. Sometimes clock aren't shutoff in suspend. Sometimes, wakeup is not succesfull. On 6/19/09, David Brownell wrote: > On Monday 18 May 2009, Woodruff, Richard wrote: >> >> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> > ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen >> > Sent: Monday, May 18, 2009 9:54 AM >> >> > Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG >> > register prevents the device from going into retention. >> > This is a workaround (by Richard Woodruff/TI), as his comment : >> > > A new MUSB bug which is a match to data below was identified very >> > > recently (on hardware and in simulation). >> > > This bug is in 3430 and not 3630. >> > > As a priority test (and as new default) you should have engineers >> > > disable autoidle for MUSB block. >> > > This is the workaround which will show up in next errata. >> > >> > Signed-off-by: Niilo Minkkinen >> >> Signed-off-by: Richard Woodruff >> >> Yes this is needed for 34xx. Side note is this cost around 1mW of power >> during active mode of MUSB. When device is not active cost is not >> significant. System impact depends on duty cycle of MUSB in usecase. > > There's also some initialization goofiness in that code ... it's supposed > to set initialize the transceiver with several distinct writes, of which > setting AUTOIDLE (to auto-gate the L3 clock) is ISTR the last step. > > The goofiness shows up with OTG initialization, which is documented as > needing a slightly different sequence ... my notes have it as being > an extra write to set ENABLEFORCE. > > - Dave > -- > 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 > -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi Arvokkainta ihmiselle on vapaus tehdä omia päätöksiä, jotka ovat joskus vääriäkin - Gottfried Leibniz (1646–1716) - -- -- 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: omap_3430sdp_defconfig for multiple boards?
From: Pandita, Vikram > >-Original Message- > >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre > >Rodriguez, Sergio Alberto > >Sent: Friday, June 19, 2009 11:10 AM > >To: linux-omap@vger.kernel.org > >Subject: omap_3430sdp_defconfig for multiple boards? > > > >Hi, > > > >Is it intentional that the current omap_3430sdp_defconfig builds an image > compatible with all this > >boards? > > This is wrong. Should have only MACH SDP defined. (Looping Khasim) OK. I saw that the commit for including support for the 3430SDP has the defconfig with this options already enabled. Regards, Sergio > > > > >> # > >> # OMAP Board Type > >> # > >> CONFIG_MACH_OMAP3_BEAGLE=y > >> CONFIG_MACH_OMAP_LDP=y > >> CONFIG_MACH_OVERO=y > >> CONFIG_MACH_OMAP3_PANDORA=y > >> CONFIG_MACH_OMAP_3430SDP=y > > > >Regards, > >Sergio > >-- > >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: omap_3430sdp_defconfig for multiple boards?
>-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Aguirre >Rodriguez, Sergio Alberto >Sent: Friday, June 19, 2009 11:10 AM >To: linux-omap@vger.kernel.org >Subject: omap_3430sdp_defconfig for multiple boards? > >Hi, > >Is it intentional that the current omap_3430sdp_defconfig builds an image >compatible with all this >boards? This is wrong. Should have only MACH SDP defined. > >> # >> # OMAP Board Type >> # >> CONFIG_MACH_OMAP3_BEAGLE=y >> CONFIG_MACH_OMAP_LDP=y >> CONFIG_MACH_OVERO=y >> CONFIG_MACH_OMAP3_PANDORA=y >> CONFIG_MACH_OMAP_3430SDP=y > >Regards, >Sergio >-- >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: OMAP3 PM: off-mode during idle, problem with UART1 console
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Friday, June 19, 2009 11:21 AM > Thanks a lot for testing. It sounds like something specific to the > ES3.0 GP SDP. Are DIP switches the same? ROM code may touch UART in one case and not the other. 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 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
Hi Paul, Russell, Tony, On Friday 19 June 2009 18:23:42 Russell King - ARM Linux wrote: > On Thu, Jun 18, 2009 at 08:48:47AM +0300, Tony Lindgren wrote: > > Paul, can you please post a git pull request for Russell on these? > > I think these should still go in if possible. > > > > Russell, if you think it's too late, I'll pile them up into omap > > for-next branch. > > Let's merge them. Also, can you look at '[PATCH 0/2] Allows the SDRAM self refresh to work with 2 chip selects' which apply on top of Paul's SDRC patches? Regards, Jean > > --- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php -- 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 00/10] OMAP clock/powerdomain/SDRC patches for post-2.6.30
On Thu, Jun 18, 2009 at 08:48:47AM +0300, Tony Lindgren wrote: > Paul, can you please post a git pull request for Russell on these? > I think these should still go in if possible. > > Russell, if you think it's too late, I'll pile them up into omap > for-next branch. Let's merge them. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 PM: off-mode during idle, problem with UART1 console
"Nayak, Rajendra" writes: >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>Sent: Wednesday, June 17, 2009 8:37 PM >>To: Nayak, Rajendra >>Cc: Woodruff, Richard; linux-omap@vger.kernel.org >>Subject: Re: OMAP3 PM: off-mode during idle, problem with UART1 console >> >>"Nayak, Rajendra" writes: >> >>> What Silicon Rev does your SDP have? I currently am using an >>ES3.1 based SDP >>> and I havent seen any of these issues you have reported with >>off-while-idle. >> >>I have and ES3.0 SDP. >> >>> Infact I have kept the board running overnight a couple >>times in the last week >>> with off-while-idle and voltage scaling to 0v enabled, >>mainly to test the recent >>> patch set (disabling Auto idle for PER in scratchpad memory) >>for stability. >> >>Ah, great. That is really good to know. Are you using >>omap_3430sdp_pm_defconfig? >> >>I see the same problems with and without your patches. >> >>> I will see if I can get hold of an ES3 and ES2.1 based SDP's >>and see if I reproduce >>> the issue. Besides I use nfs and I am not sure if that's got >>something to do with it. >>> Will try a ramdisk also. >> >>I'm using a ramdisk. >> >>> Does it take you a while to reproduce this, or is it seen >>after the very first UART >>> inactivity? >> >>It happens on the first try. >> >>Could you try my uImage which has my initramfs rootfs built-in on your >>ES3.1 SDP? >> >> http://userweb.kernel.org/~khilman/tmp/rajendra/uImage.pm-vanilla >> >>Immediately after booting, I do >> >># echo 1 > /sys/power/enable_off_mode >> >># echo 1 > /sys/power/voltage_off_while_idle >> >># echo 1 > /sys/power/sleep_while_idle >> >> >>and after UART inactivity, I start to see sys_off_mode LED blinking. > > Kevin, > > This image works just fine on both my ES3.1 GP as well as ES3.0 EMU SDP. > After the sys_off LED blinks, a key press stops the blinking and also gets > be the debug console back. > Rajendra, Thanks a lot for testing. It sounds like something specific to the ES3.0 GP SDP. 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
omap_3430sdp_defconfig for multiple boards?
Hi, Is it intentional that the current omap_3430sdp_defconfig builds an image compatible with all this boards? > # > # OMAP Board Type > # > CONFIG_MACH_OMAP3_BEAGLE=y > CONFIG_MACH_OMAP_LDP=y > CONFIG_MACH_OVERO=y > CONFIG_MACH_OMAP3_PANDORA=y > CONFIG_MACH_OMAP_3430SDP=y Regards, Sergio -- 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] initialize gpio debounce register
Hi, some bootloader may initialize debounce register and this will make dbclk not consist with the debounce register after linux kernel boot up. >From 8f97e5b50e50627e9e4b40f5d4fba09d750aceb1 Mon Sep 17 00:00:00 2001 From: janboe Date: Fri, 19 Jun 2009 10:56:02 -0500 Subject: [PATCH] initialize gpio debounce register Signed-off-by: janboe --- arch/arm/plat-omap/gpio.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 7fd89ba..26b387c 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -1585,6 +1585,7 @@ static int __init _omap_gpio_init(void) __raw_writel(0x, bank->base + OMAP24XX_GPIO_IRQENABLE1); __raw_writel(0x, bank->base + OMAP24XX_GPIO_IRQSTATUS1); __raw_writew(0x0015, bank->base + OMAP24XX_GPIO_SYSCONFIG); + __raw_writel(0x, bank->base + OMAP24XX_GPIO_DEBOUNCE_EN); /* Initialize interface clock ungated, module enabled */ __raw_writel(0, bank->base + OMAP24XX_GPIO_CTRL); -- 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] ARM: MACH-OMAP2: Cleanup Kconfig entries
>From 9258708325e0a04de7d7503b65cabc25860a9e7d Mon Sep 17 00:00:00 2001 From: Sergio Aguirre Date: Fri, 19 Jun 2009 09:50:52 -0500 Subject: [PATCH] ARM: MACH-OMAP2: Cleanup Kconfig entries This patch removes some duplicate entries, and intents to cleanup the order. Signed-off-by: Sergio Aguirre --- arch/arm/mach-omap2/Kconfig | 38 ++ 1 files changed, 14 insertions(+), 24 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index bfb36e2..caf5144 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,22 +109,30 @@ config MACH_OMAP_2430SDP bool "OMAP 2430 SDP board" depends on ARCH_OMAP2 && ARCH_OMAP2430 -config MACH_OMAP_LDP - bool "OMAP3 LDP board" +config MACH_OMAP_3430SDP + bool "OMAP 3430 SDP board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP_4430SDP + bool "OMAP 4430 SDP board" + depends on ARCH_OMAP4 + config MACH_OMAP2EVM bool "OMAP 2530 EVM board" depends on ARCH_OMAP2 && ARCH_OMAP24XX -config MACH_OMAP_3430SDP - bool "OMAP 3430 SDP board" - depends on ARCH_OMAP3 && ARCH_OMAP34XX - config MACH_OMAP3EVM bool "OMAP 3530 EVM board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP_LDP + bool "OMAP3 LDP board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX + +config MACH_OMAP_ZOOM2 + bool "OMAP3 Zoom2 board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX + config MACH_OMAP3_BEAGLE bool "OMAP3 BEAGLE board" depends on ARCH_OMAP3 && ARCH_OMAP34XX @@ -133,26 +141,8 @@ config MACH_OVERO bool "Gumstix Overo board" depends on ARCH_OMAP3 && ARCH_OMAP34XX -config MACH_OMAP3EVM - bool "OMAP 3530 EVM board" - depends on ARCH_OMAP3 && ARCH_OMAP34XX - config MACH_OMAP3_PANDORA bool "OMAP3 Pandora" depends on ARCH_OMAP3 && ARCH_OMAP34XX -config MACH_OMAP_3430SDP - bool "OMAP 3430 SDP board" - depends on ARCH_OMAP3 && ARCH_OMAP34XX -config MACH_OMAP_ZOOM2 - bool "OMAP3 Zoom2 board" - depends on ARCH_OMAP3 && ARCH_OMAP34XX - -config MACH_OMAP_ZOOM2 - bool "OMAP3 Zoom2 board" - depends on ARCH_OMAP3 && ARCH_OMAP34XX - -config MACH_OMAP_4430SDP - bool "OMAP 4430 SDP board" - depends on ARCH_OMAP4 -- 1.6.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help in adding ams-delta support to ASoC
Tony Lindgren wrote: * Janusz Krzysztofik [090618 14:52]: Tony Lindgren wrote: On omap1, DSP needs to be powered and idled before some mcbsp clocks can be used. Or at least needs to be powered up. AFAICS there is no DSP code in mainline at all, so the answer is no, DSP was likely not powered up at all. For several weeks I was trying to do what was impossible :/. But fortunatelly, I have learned a lot ;). We at least used to have code to power and idle the DSP even without the dspgateway compiled in.. Sorry I don't remember the details. But most likely you need to have the dspgateway patch enabled. Tony, Thanks for clarifying things. Arun K S wrote: On Thu, Jun 18, 2009 at 4:40 AM, Janusz Krzysztofik wrote: ... I retried the new driver on commit 90e758af52ba803cba233fabee81176d99589f09 and confirmed the prevoiusly seen hangup. I found that it was omap_mcbsp_request() never returning back from. I faced the same issue while writing ASoC driver for tlv320aic23b codec. You can have a look at this thread: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg03852.html It may help. Arun, Thanks, it's good to hear not only me having this problem ;). So what is the current status of your osk driver? What tree do you use, what extra patches do you apply to make it actually working? --- After all, could someone please give me an advise, what tree, even with buggy omap1510 mcbsp/dsp support, should I base my work on for best results? Omap? Sound? Mainline? I mean not only easy getting the driver working, but also giving it the best possible path into the mainline. 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
Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter
On Thursday 04 June 2009, Remith Ravi wrote: > Hi, > > Anybody had a chance to attend this issue? Any hint to solve the problem? > > The ASIX AX88772A USB2.0 Fast Ethernet Network Adapter Linux driver > available in Asix website supports only upto Linux 2.6.26. > I integrated that driver into the git kernel and tested it on the > OMAP35xx dev board (EHCI port). The driver detects the presence of > USB-2-Ethernet > converter and it is possible to assign ip address to the new Ethernet > interface. But the ping test fails (ping statistics --- > 40 packets transmitted, 0 packets received, 100% packet loss) and > therefore I cant continue testing it on the latest git kernel. That worked OK for me the last time I hooked up one of those adapters to a 3430 (essentially the same as a 3530). > > Any help towards solving this issue will be highly appreciated. > > Regards, > Remith > > > On Fri, May 29, 2009 at 7:46 PM, umesh krishnan wrote: > > Hi, > > > > Any help on the below-said musb-issue? > > > > > > -- Forwarded message -- > > From: Felipe Balbi > > Date: Fri, May 29, 2009 at 3:10 PM > > Subject: Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter > > To: ext umesh krishnan > > Cc: "linux-omap@vger.kernel.org" , > > linux-...@vger.kernel.org > > > > > > Hi, > > > > musb should be discussed in linux-usb, but keep linux-omap as Cc. > > unfortunately I don't have time to help community now due to internal > > tasks I gotta finish, but I'm sure there's more people in linux-usb that > > could help you with it. > > > > On Fri, May 29, 2009 at 11:24:37AM +0200, ext umesh krishnan wrote: > >> Greetings, > >> > >> I am facing issues while using Asix's AX88772A USB-2-Ethernet > >> converter on my OMAP3530 based product. It uses TI's 2.6.22.18 PSP > >> release-1.0.2 as its OS. The driver for AX8877A was taken from Asix's > >> website. > > > > This is one problem, community can only support you with the current > > version of the open source kernel. Meaning you should try with > > linux-omap-2.6.git or linux-2.6.git. > > > >> I am facing kernel crashes when I use the converter on USB OTG port. I > >> am able to get the device detected and also able to assign the ip to > >> the device. But when i repeat the process after plugging-out and > >> plugging-in again and then assigning the ip address , after repeating > >> the process about 9 times, the kernel crashes(when i assign the ip). I > >> tried testing by configuring the musb driver into both OTG and Host > >> only mode. Kernel crashed in both cases. Crash log is attached. > > > > (keeping the crash below for reference) > > > >> - > >> eth1: unregister 'asix' usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 Ethernet > >> musb_stage0_irq 699: CONNECT (a_host) devctl 5d > >> usb 1-1: new high speed USB device using musb_hdrc and address 3 > >> usb 1-1: Product: AX88x72A > >> usb 1-1: Manufacturer: ASIX Elec. Corp. > >> usb 1-1: SerialNumber: 01 > >> usb 1-1: configuration #1 chosen from 1 choice > >> eth1: register 'asix' at usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 > >> Ethernet, 00:0e:c6:00:0f:97 > >> > >> [r...@omap3 /]# ping 192.168.13.1 > >> [r...@omap3 /]# ifconfig eth1 192.168.13.254 > >> Unable to handle kernel NULL pointer dereference at virtual address > >> 001c > >> pgd = c719 > >> [001c] *pgd=8706b031, *pte=, *ppte= > >> Internal error: Oops: 17 [#1] > >> Modules linked in: > >> CPU: 0 Not tainted (2.6.22.18-omap3 #1) > >> PC is at musb_start_urb+0x74/0x9b0 > >> LR is at __init_begin+0x3fff8000/0x30 > >> pc : [] lr : [<>] psr: 6093 > >> sp : c706fc18 ip : c059d1ec fp : c706fcb4 > >> r10: 0020 r9 : r8 : c059d000 > >> r7 : c713e120 r6 : c059d1ec r5 : c059d0d8 r4 : c7f9a9e0 > >> r3 : r2 : r1 : c7f9a9e0 r0 : c059d1ec > >> Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment user > >> Control: 00c5387f Table: 87190018 DAC: 0015 > >> Process ifconfig (pid: 407, stack limit = 0xc706e2d8) > >> Stack: (0xc706fc18 to 0xc707) > >> fc00: 0020 > >> 0020 > >> fc20: c706fc44 c706fc30 c02180b4 c02174ec c05c0a00 c706fc64 > >> c03e4464 > >> fc40: c7f9a9e0 c059d0d8 c713e128 c8808000 c059d1ec > >> c706fc68 > >> fc60: c0087f24 c00351dc 005c c03e4464 c706fc9c c706fc80 c002b04c > >> c00688a4 > >> fc80: d820 c059d000 c7f9a9e0 c059d0d8 c059d1ec c713e120 > >> c059d000 > >> fca0: 0020 c706fcf4 c706fcb8 c021a874 c0219a5c c059d000 > >> c713e120 > >> fcc0: a013 0020 0020 871cfa20 c05a1034 c059d000 c713e120 > >> c713e128 > >> fce0: 0020 0020 c706fdbc c706fcf8 c01f8e34 c021a520 c706fd1c > >> c706fd08 > >> fd00: c02180b4 c02174ec c05c0a00 c706fd3c c03e4464 005c
Re: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
On Monday 18 May 2009, Woodruff, Richard wrote: > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen > > Sent: Monday, May 18, 2009 9:54 AM > > > Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG > > register prevents the device from going into retention. > > This is a workaround (by Richard Woodruff/TI), as his comment : > > > A new MUSB bug which is a match to data below was identified very > > > recently (on hardware and in simulation). > > > This bug is in 3430 and not 3630. > > > As a priority test (and as new default) you should have engineers > > > disable autoidle for MUSB block. > > > This is the workaround which will show up in next errata. > > > > Signed-off-by: Niilo Minkkinen > > Signed-off-by: Richard Woodruff > > Yes this is needed for 34xx. Side note is this cost around 1mW of power > during active mode of MUSB. When device is not active cost is not > significant. System impact depends on duty cycle of MUSB in usecase. There's also some initialization goofiness in that code ... it's supposed to set initialize the transceiver with several distinct writes, of which setting AUTOIDLE (to auto-gate the L3 clock) is ISTR the last step. The goofiness shows up with OTG initialization, which is documented as needing a slightly different sequence ... my notes have it as being an extra write to set ENABLEFORCE. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 PM: off-mode during idle, problem with UART1 console
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Wednesday, June 17, 2009 8:37 PM >To: Nayak, Rajendra >Cc: Woodruff, Richard; linux-omap@vger.kernel.org >Subject: Re: OMAP3 PM: off-mode during idle, problem with UART1 console > >"Nayak, Rajendra" writes: > >> What Silicon Rev does your SDP have? I currently am using an >ES3.1 based SDP >> and I havent seen any of these issues you have reported with >off-while-idle. > >I have and ES3.0 SDP. > >> Infact I have kept the board running overnight a couple >times in the last week >> with off-while-idle and voltage scaling to 0v enabled, >mainly to test the recent >> patch set (disabling Auto idle for PER in scratchpad memory) >for stability. > >Ah, great. That is really good to know. Are you using >omap_3430sdp_pm_defconfig? > >I see the same problems with and without your patches. > >> I will see if I can get hold of an ES3 and ES2.1 based SDP's >and see if I reproduce >> the issue. Besides I use nfs and I am not sure if that's got >something to do with it. >> Will try a ramdisk also. > >I'm using a ramdisk. > >> Does it take you a while to reproduce this, or is it seen >after the very first UART >> inactivity? > >It happens on the first try. > >Could you try my uImage which has my initramfs rootfs built-in on your >ES3.1 SDP? > > http://userweb.kernel.org/~khilman/tmp/rajendra/uImage.pm-vanilla > >Immediately after booting, I do > ># echo 1 > /sys/power/enable_off_mode > ># echo 1 > /sys/power/voltage_off_while_idle > ># echo 1 > /sys/power/sleep_while_idle > > >and after UART inactivity, I start to see sys_off_mode LED blinking. Kevin, This image works just fine on both my ES3.1 GP as well as ES3.0 EMU SDP. After the sys_off LED blinks, a key press stops the blinking and also gets be the debug console back. regards, Rajendra > > >>>-Original Message- >>>From: linux-omap-ow...@vger.kernel.org >>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >>>Sent: Wednesday, June 17, 2009 2:35 AM >>>To: Nayak, Rajendra; Woodruff, Richard >>>Cc: linux-omap@vger.kernel.org >>>Subject: OMAP3 PM: off-mode during idle, problem with UART1 console >>> >>>Rajendra, Richard, >>> >>>Hoping you can shed some light, or give me some direction on where to >>>debug this further... >>> >>>With the latest PM branch, I've notice that off-while idle isn't >>>working on the SDP, but the same kernel works fine on the RX51. >>>RET-while-idle works fine on both. This is with CPUidle disabled, so >>>just using the default idle where MPU and CORE are changed together. >>> >>>More specifically, it seems to be the UART1 (CORE) console that never >>>comes back from off-while-idle, but the UART3 (PER) console on RX51 >>>works. >>> >>>On SDP, if I >>> >>># echo 1 > /sys/power/enable_off_mode >>># echo 1 > /sys/power/voltage_off_while_idle >>># echo 1 > /sys/power/sleep_while_idle >>> >>>After the UART inactivty timeout of 5 seconds, I start to see the >>>sys_off_mode LED toggling between red and green with system timer >>>wakeups. >>> >>>If I then push a key on the UART1 console, the LED goes green, stays >>>for the 5 second UART inactivity and then goes back to toggling >>>red/green again. However, I never get my console back and never see >>>the characters on my console. >>> >>>If I keep typing, I keep the system from going back off (based on >>>sys_off_mode LED) and as soon as I stop typing long enough for the >>>inactivity timer to expiere (5 seconds) it goes back into off. >>> >>>Any ideas what's going on here? >>> >>>On RX51, the same thing works using UART3. >>> >>>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
