* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Felipe Balbi @ 2009-03-12 0:23 UTC (permalink / raw)
To: Paul Walmsley
Cc: Felipe Balbi, Ari Kauppi, Ben Dooks, ben-linux, linux-omap,
linux-i2c
In-Reply-To: <alpine.DEB.2.00.0903111804510.26959@utopia.booyaka.com>
On Wed, Mar 11, 2009 at 06:07:00PM -0600, Paul Walmsley wrote:
> Hi Felipe,
>
> On Thu, 12 Mar 2009, Felipe Balbi wrote:
>
> > On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote:
> > > Ben's right, there shouldn't be any need for this. This patch could cause
> > > some unnecessary interrupt service latency.
> >
> > That's not what Thomas Gleixner thinks. How about the possibility of
> > stack overflow ?
>
> That sounds like a separate issue from the spurious IRQ problem that the
> patch was intended to fix.
>
> I'm not familiar with the discussion on the stack overflow issue. Could
> you send a link?
This is the link where Ingo discusses why !IRQF_DISABLED could cause
stack overflow:
http://lkml.org/lkml/2009/3/3/71
You probably wanna take a look at the whole thread to figure out the
discussion, but basically Ingo and Peter (Zijlstra) believe
!IRQF_DISABLED is a bug and drivers needing that probably should be
using threaded irqs (which is not yet merged) or the hw is broken, and
for those an IRQF_ENABLED flag will be created and a TAINT will also be
placed.
Once that gets merged, all drivers will be forced (at some point) to
IRQF_DISABLED and those which don't want that will be moved gradually to
threaded irq.
This patch is also interesting:
http://lkml.org/lkml/2009/3/2/33
--
balbi
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Kevin Hilman @ 2009-03-12 0:20 UTC (permalink / raw)
To: Paul Walmsley
Cc: Felipe Balbi, Ari Kauppi, Ben Dooks,
ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.00.0903111804510.26959-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> writes:
> Hi Felipe,
>
> On Thu, 12 Mar 2009, Felipe Balbi wrote:
>
>> On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote:
>> > Ben's right, there shouldn't be any need for this. This patch could cause
>> > some unnecessary interrupt service latency.
>>
>> That's not what Thomas Gleixner thinks. How about the possibility of
>> stack overflow ?
>
> That sounds like a separate issue from the spurious IRQ problem that the
> patch was intended to fix.
I agree. The IRQF_DISABLED happens to fix this issue, but it may be
masking the real spurious issue as Paul suggested.
> I'm not familiar with the discussion on the stack overflow issue. Could
> you send a link?
>
Here's one:
http://marc.info/?l=linux-kernel&m=123607359500596&w=2
Kevin
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Felipe Contreras @ 2009-03-12 0:11 UTC (permalink / raw)
To: me-uiRdBs8odbtmTBlB0Cgj/Q
Cc: Paul Walmsley, Ari Kauppi, Ben Dooks,
ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090311235908.GC19038@gandalf>
On Thu, Mar 12, 2009 at 1:59 AM, Felipe Balbi <me-uiRdBs8odbtmTBlB0Cgj/Q@public.gmane.org> wrote:
> On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote:
>> Ben's right, there shouldn't be any need for this. This patch could cause
>> some unnecessary interrupt service latency.
>
> That's not what Thomas Gleixner thinks. How about the possibility of
> stack overflow ?
>
> According to Thomas (and Ingo, I'd say) all drivers should call
> request_irq() with IRQF_DISABLED and that's gonna be true as soon as the
> threaded irq handler support gets merged, if I'm not wrong.
That's my understanding too, but I think it has always been true:
http://marc.info/?l=linux-kernel&m=123607685804562&w=2
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Paul Walmsley @ 2009-03-12 0:07 UTC (permalink / raw)
To: Felipe Balbi
Cc: Ari Kauppi, Ben Dooks, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090311235908.GC19038@gandalf>
Hi Felipe,
On Thu, 12 Mar 2009, Felipe Balbi wrote:
> On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote:
> > Ben's right, there shouldn't be any need for this. This patch could cause
> > some unnecessary interrupt service latency.
>
> That's not what Thomas Gleixner thinks. How about the possibility of
> stack overflow ?
That sounds like a separate issue from the spurious IRQ problem that the
patch was intended to fix.
I'm not familiar with the discussion on the stack overflow issue. Could
you send a link?
> According to Thomas (and Ingo, I'd say) all drivers should call
> request_irq() with IRQF_DISABLED and that's gonna be true as soon as the
> threaded irq handler support gets merged, if I'm not wrong.
- Paul
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Paul Walmsley @ 2009-03-12 0:04 UTC (permalink / raw)
To: Ari Kauppi
Cc: Ben Dooks, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.00.0903111741270.26959-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
Hi Ari,
One thing that I missed -
On Wed, 11 Mar 2009, Paul Walmsley wrote:
> > On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote:
> > > I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
> > > (and thus LOCKDEP) are disabled.
>
> Ari, are you seeing "Spurious irq XX: XXXXXXXX, please flush posted write
> for irq" messages? If so, the correct fix for this is to read from the
> device interrupt status register immediately after writing to it. This
> forces the ARM to wait until the write to the device is complete. Ari,
> could you make this change to i2c-omap.c:omap_i2c_isr() instead, and test
> whether this fixes the problem?
>
> + u32 tmp;
>
> ...
>
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
> + tmp = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); /* OCP barrier */
You'll also want to make a similar change in omap_i2c_ack_stat(), to add a
read immediately after that write.
- Paul
^ permalink raw reply
* DSPBRIDGE: segmentation fault after reloading dspbridge several times due to a memory leak.
From: Guzman Lugo, Fernando @ 2009-03-12 0:03 UTC (permalink / raw)
To: linux-omap@vger.kernel.org
Hi All,
Reloading the dspbridge several times I am getting a Segmentation fault. Seeing the log it seems that the memory was exhausted
The error happens when ioremap is called
void MEM_ExtPhysPoolInit(u32 poolPhysBase, u32 poolSize)
{
u32 poolVirtBase;
/* get the virtual address for the physical memory pool passed */
poolVirtBase = (u32)ioremap(poolPhysBase, poolSize);
.
Putting some printk's and printing the address returned by ioremap, I realized that address returned by ioremap each time I reload the dspbridge is different, in fact the address is increasing. I also put a printk where iounmap is called to make sure it is called and yes it is actually called. However testing with a kernel + bridge for linux 23x I always get the same address for pool memory. Any idea what the problem is? I have included the console output where you can see the address increasing.
Regards,
Fernando.
The first 15 loads and unloads
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c8000000
Releasing External memory pool, address = c8000000
interation 2
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c9000000
Releasing External memory pool, address = c9000000
interation 3
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c9800000
Releasing External memory pool, address = c9800000
interation 4
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ca800000
Releasing External memory pool, address = ca800000
interation 5
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cb000000
Releasing External memory pool, address = cb000000
interation 6
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cc000000
Releasing External memory pool, address = cc000000
interation 7
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cc800000
Releasing External memory pool, address = cc800000
interation 8
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = c8800000
Releasing External memory pool, address = c8800000
interation 9
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ca000000
Releasing External memory pool, address = ca000000
interation 10
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cd000000
Releasing External memory pool, address = cd000000
interation 11
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cd800000
Releasing External memory pool, address = cd800000
interation 12
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = ce800000
Releasing External memory pool, address = ce800000
interation 13
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = cf000000
Releasing External memory pool, address = cf000000
interation 14
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d0000000
Releasing External memory pool, address = d0000000
interation 15
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d0800000
Releasing External memory pool, address = d0800000
...
and It crashes in the 33rd reload.
interation 32
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
[PHYS_POOL]Mapping External, address = d7800000
Releasing External memory pool, address = d7800000
interation 33
INFO: For help run script as ./install_bridge help
INFO:Installed Bridgedriver from current directory:/dspbridge_os
<4>vmap allocation failed: use vmalloc=<size> to increase size.
vmap allocation failed: use vmalloc=<size> to increase size.
[PHYS_POOL]Mapping External, address = 0
<4>coherent allocation too big (requested 0x400000 mask 0xffffffff)
coherent allocation too big (requested 0x400000 mask 0xffffffff)
drivers/dsp/bridge/rmgr/drv.c, line 1546: Assertion ((DSP_SUCCEEDED(status) && p
DevNodeString != NULL && !LST_IsEmpty(pDRVObject->devNodeString)) || (DSP_FAILED
(status) && *pDevNodeString == 0)) failed.
drivers/dsp/bridge/rmgr/drv.c, line 1546: Assertion ((DSP_SUCCEEDED(status) && p
DevNodeString != NULL && !LST_IsEmpty(pDRVObject->devNodeString)) || (DSP_FAILED
(status) && *pDevNodeString == 0)) failed.
drivers/dsp/bridge/rmgr/drv_interface.c, line 484: Assertion (status == 0) faile
d.
drivers/dsp/bridge/rmgr/drv_interface.c, line 484: Assertion (status == 0) faile
d.
drivers/dsp/bridge/rmgr/drv_interface.c, line 485: Assertion (DSP_SUCCEEDED(init
Status)) failed.
drivers/dsp/bridge/rmgr/drv_interface.c, line 485: Assertion (DSP_SUCCEEDED(init
Status)) failed.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2] PM : cpuidle - Update statistics for correct state
From: Kevin Hilman @ 2009-03-12 0:00 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: Högander Jouni, linux-omap@vger.kernel.org
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301CC1F6C1F@dbde02.ent.ti.com>
"Premi, Sanjeev" <premi@ti.com> writes:
>>
>> I would gladly take a patch which uses the 'valid' field for
>> this and then the enter hook whould drop to the next lower
>> valid state if the state requested is not valid.
>>
>> Kevin
>
> [sp] I have not yet tested it (working offline for sometime).
> But, wanted to share the changes for an early review.
Thanks, some comments below.
> Initially, I was trying see if the CPUIDLE framework could
> use ".valid" as an additional argument in cpuidle_state.
> But, may be that's for later...
Yeah, I looked at that too, but it currently doesn't have a concept
of valid states, so for now I recommend we implement that in the
OMAP-specific code as you have done.
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx
> index c25158c..9493553 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -88,16 +88,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> goto return_sleep_time;
>
> /*
> + * Check if the chosen idle state is valid.
> + * If no, drop down to a lower valid state. Expects the lowest
> + * state will always be active.
> */
> + if (!cx->valid) {
> + for (idx = (cx->type - 1); idx == 1; idx--) {
^^^^^^^^
I think you mean idx >= 1 here.
Also, while you're working on this, could you fix this up so the
omap3_power_states[] array is zero based insted of 1-based, it would
make this code and the other code walking this array easier to follow.
That means defining OMAP_STATE_C1 = 0 and so on.
> + if (omap3_power_states[idx].valid)
> + break;
> }
> + state = &(dev->states[idx]);
> + dev->last_state = state ;
> +
> + cx = cpuidle_get_statedata(state);
> }
>
> current_cx_state = *cx;
> @@ -150,6 +153,26 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
> return omap3_enter_idle(dev, new_state);
> }
>
> +/**
> + * omap3_toggle_off_states - Enable / Disable validity of idle states
> + * @flag: Enable/ Disable support for OFF mode
> + *
> + * Called as result of change to "enable_off_mode".
> + */
> +void omap3_toggle_off_states(unsigned short flag)
> +{
How about calling this omap3_cpuidle_update_states() and taking
no arguments. Rather than the 'flag' argument, internally it
just checks the global 'enable_off_mode.'
This allows for potential further expansion down the road of other
reasons to update CPUidle valid states. For example, we've talked
about updating the CPUidle state latencies on the fly depending on
various other chip settings.
> + if (flag) {
> + omap3_power_states[OMAP3_STATE_C3].valid = 1;
> + omap3_power_states[OMAP3_STATE_C5].valid = 1;
> + omap3_power_states[OMAP3_STATE_C6].valid = 1;
> + }
> + else {
> + omap3_power_states[OMAP3_STATE_C3].valid = 0;
> + omap3_power_states[OMAP3_STATE_C5].valid = 0;
> + omap3_power_states[OMAP3_STATE_C6].valid = 0;
> + }
> +}
> +
Rather than set set specific OMAP3_STATE_Cx values, it would be better
to just walk the array, and check for [mpu|core]_state = PWRDM_POWER_OFF.
If the state has either set, then update the valid flag.
> DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
>
> /* omap3_init_power_states - Initialises the OMAP3 specific C states.
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 61c6dfb..6785850 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -47,6 +47,8 @@ atomic_t sleep_block = ATOMIC_INIT(0);
> static int vdd1_locked;
> static int vdd2_locked;
>
> +extern void omap3_toggle_off_states(unsigned short);
> +
Move the definition into pm.h as omap3_cpuidle_update_states(void) as
described above.
> static ssize_t idle_show(struct kobject *, struct kobj_attribute *, char *);
> static ssize_t idle_store(struct kobject *k, struct kobj_attribute *,
> const char *buf, size_t n);
> @@ -112,6 +114,8 @@ static ssize_t idle_store(struct kobject *kobj, struct kobj_
> } else if (attr == &enable_off_mode_attr) {
> enable_off_mode = value;
> omap3_pm_off_mode_enable(enable_off_mode);
> + if (cpu_is_omap34xx())
> + omap3_toggle_off_states(value);
Then, don't modify pm.c, rather just call omap3_cpuidle_update_states() from
omap3_pm_off_mode_enable().
Kevin
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Felipe Balbi @ 2009-03-11 23:59 UTC (permalink / raw)
To: Paul Walmsley
Cc: Ari Kauppi, Ben Dooks, ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.00.0903111741270.26959-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 11, 2009 at 05:55:50PM -0600, Paul Walmsley wrote:
> Ben's right, there shouldn't be any need for this. This patch could cause
> some unnecessary interrupt service latency.
That's not what Thomas Gleixner thinks. How about the possibility of
stack overflow ?
According to Thomas (and Ingo, I'd say) all drivers should call
request_irq() with IRQF_DISABLED and that's gonna be true as soon as the
threaded irq handler support gets merged, if I'm not wrong.
--
balbi
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Paul Walmsley @ 2009-03-11 23:55 UTC (permalink / raw)
To: Ari Kauppi; +Cc: Ben Dooks, ben-linux, linux-omap, linux-i2c
In-Reply-To: <20090310005222.GE19758@fluff.org.uk>
Hello Ari et al.,
On Tue, 10 Mar 2009, Ben Dooks wrote:
> On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote:
> > I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
> > (and thus LOCKDEP) are disabled.
> >
> > Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
> > but IRQF_DISABLED is needed for proper behaviour.
> >
> > Signed-off-by: Ari Kauppi <Ext-Ari.Kauppi@nokia.com>
> > Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
> > ---
> > drivers/i2c/busses/i2c-omap.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index 0c3ed41..18af43f 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev)
> > omap_i2c_init(dev);
> >
> > isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
> > - r = request_irq(dev->irq, isr, 0, pdev->name, dev);
> > + r = request_irq(dev->irq, isr, IRQF_DISABLED, pdev->name, dev);
>
> Is disabling all IRQs on the system the right thing to do?
Ben's right, there shouldn't be any need for this. This patch could cause
some unnecessary interrupt service latency.
Ari, are you seeing "Spurious irq XX: XXXXXXXX, please flush posted write
for irq" messages? If so, the correct fix for this is to read from the
device interrupt status register immediately after writing to it. This
forces the ARM to wait until the write to the device is complete. Ari,
could you make this change to i2c-omap.c:omap_i2c_isr() instead, and test
whether this fixes the problem?
+ u32 tmp;
...
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
+ tmp = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); /* OCP barrier */
- Paul
^ permalink raw reply
* Re: [PATCH] Add new C state
From: Kevin Hilman @ 2009-03-11 22:51 UTC (permalink / raw)
To: Peter 'p2' De Schrijver; +Cc: linux-omap
In-Reply-To: <1236700866-30760-1-git-send-email-peter.de-schrijver@nokia.com>
"Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:
> This patch introduces a new C state which allows MPU to go to WFI but keeps
> the core domain active. This offers a much better wakeup latency (3us vs
> 10s of us for the current C1) at the cost of a higher power consumption.
>
> Signed-off-by: Peter 'p2' De Schrijver <peter.de-schrijver@nokia.com>
Thanks, the content looks fine, but can you fix the two checkpatch warnings
and update the subject to be a bit more descriptive. Something like
OMAP3: PM: Add new lower-latency C1 state
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 119 +++++++++++++++++++++++-------------
> 1 files changed, 76 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 62fbb2e..5565aa7 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -26,6 +26,7 @@
> #include <mach/pm.h>
> #include <mach/prcm.h>
> #include <mach/powerdomain.h>
> +#include <mach/clockdomain.h>
> #include <mach/control.h>
> #include <mach/serial.h>
>
> @@ -33,13 +34,14 @@
>
> #ifdef CONFIG_CPU_IDLE
>
> -#define OMAP3_MAX_STATES 7
> +#define OMAP3_MAX_STATES 8
> #define OMAP3_STATE_C1 1 /* C1 - MPU WFI + Core active */
> -#define OMAP3_STATE_C2 2 /* C2 - MPU CSWR + Core active */
> -#define OMAP3_STATE_C3 3 /* C3 - MPU OFF + Core active */
> -#define OMAP3_STATE_C4 4 /* C4 - MPU RET + Core RET */
> -#define OMAP3_STATE_C5 5 /* C5 - MPU OFF + Core RET */
> -#define OMAP3_STATE_C6 6 /* C6 - MPU OFF + Core OFF */
> +#define OMAP3_STATE_C2 2 /* C2 - MPU WFI + Core inactive */
> +#define OMAP3_STATE_C3 3 /* C2 - MPU CSWR + Core inactive */
> +#define OMAP3_STATE_C4 4 /* C3 - MPU OFF + Core iactive */
> +#define OMAP3_STATE_C5 5 /* C4 - MPU RET + Core RET */
> +#define OMAP3_STATE_C6 6 /* C5 - MPU OFF + Core RET */
> +#define OMAP3_STATE_C7 7 /* C6 - MPU OFF + Core OFF */
>
> struct omap3_processor_cx {
> u8 valid;
> @@ -63,6 +65,16 @@ static int omap3_idle_bm_check(void)
> return 0;
> }
>
> +static int _cpuidle_allow_idle(struct powerdomain *pwrdm, struct clockdomain *clkdm)
> +{
> + omap2_clkdm_allow_idle(clkdm);
> +}
> +
> +static int _cpuidle_deny_idle(struct powerdomain *pwrdm, struct clockdomain *clkdm)
> +{
> + omap2_clkdm_deny_idle(clkdm);
> +}
> +
> /**
> * omap3_enter_idle - Programs OMAP3 to enter the specified state
> * @dev: cpuidle device
> @@ -99,9 +111,19 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
> if (omap_irq_pending())
> goto return_sleep_time;
>
> + if (cx->type == OMAP3_STATE_C1) {
> + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_deny_idle);
> + pwrdm_for_each_clkdm(core_pd, _cpuidle_deny_idle);
> + }
> +
> /* Execute ARM wfi */
> omap_sram_idle();
>
> + if (cx->type == OMAP3_STATE_C1) {
> + pwrdm_for_each_clkdm(mpu_pd, _cpuidle_allow_idle);
> + pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
> + }
> +
> return_sleep_time:
> getnstimeofday(&ts_postidle);
> ts_idle = timespec_sub(ts_postidle, ts_preidle);
> @@ -140,79 +162,90 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
> /* omap3_init_power_states - Initialises the OMAP3 specific C states.
> *
> * Below is the desciption of each C state.
> - * C1 . MPU WFI + Core active
> - * C2 . MPU CSWR + Core active
> - * C3 . MPU OFF + Core active
> - * C4 . MPU CSWR + Core CSWR
> - * C5 . MPU OFF + Core CSWR
> - * C6 . MPU OFF + Core OFF
> + * C1 . MPU WFI + Core active
> + * C2 . MPU WFI + Core inactive
> + * C3 . MPU CSWR + Core inactive
> + * C4 . MPU OFF + Core inactive
> + * C5 . MPU CSWR + Core CSWR
> + * C6 . MPU OFF + Core CSWR
> + * C7 . MPU OFF + Core OFF
> */
> void omap_init_power_states(void)
> {
> /* C1 . MPU WFI + Core active */
> omap3_power_states[OMAP3_STATE_C1].valid = 1;
> omap3_power_states[OMAP3_STATE_C1].type = OMAP3_STATE_C1;
> - omap3_power_states[OMAP3_STATE_C1].sleep_latency = 10;
> - omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 10;
> - omap3_power_states[OMAP3_STATE_C1].threshold = 30;
> + omap3_power_states[OMAP3_STATE_C1].sleep_latency = 2;
> + omap3_power_states[OMAP3_STATE_C1].wakeup_latency = 2;
> + omap3_power_states[OMAP3_STATE_C1].threshold = 5;
> omap3_power_states[OMAP3_STATE_C1].mpu_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C1].core_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
>
> - /* C2 . MPU CSWR + Core active */
> + /* C2 . MPU WFI + Core inactive */
> omap3_power_states[OMAP3_STATE_C2].valid = 1;
> omap3_power_states[OMAP3_STATE_C2].type = OMAP3_STATE_C2;
> - omap3_power_states[OMAP3_STATE_C2].sleep_latency = 50;
> - omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 50;
> - omap3_power_states[OMAP3_STATE_C2].threshold = 300;
> - omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_RET;
> + omap3_power_states[OMAP3_STATE_C2].sleep_latency = 10;
> + omap3_power_states[OMAP3_STATE_C2].wakeup_latency = 10;
> + omap3_power_states[OMAP3_STATE_C2].threshold = 30;
> + omap3_power_states[OMAP3_STATE_C2].mpu_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C2].core_state = PWRDM_POWER_ON;
> - omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID |
> - CPUIDLE_FLAG_CHECK_BM;
> + omap3_power_states[OMAP3_STATE_C2].flags = CPUIDLE_FLAG_TIME_VALID;
>
> - /* C3 . MPU OFF + Core active */
> + /* C3 . MPU CSWR + Core inactive */
> omap3_power_states[OMAP3_STATE_C3].valid = 1;
> omap3_power_states[OMAP3_STATE_C3].type = OMAP3_STATE_C3;
> - omap3_power_states[OMAP3_STATE_C3].sleep_latency = 1500;
> - omap3_power_states[OMAP3_STATE_C3].wakeup_latency = 1800;
> - omap3_power_states[OMAP3_STATE_C3].threshold = 4000;
> - omap3_power_states[OMAP3_STATE_C3].mpu_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C3].sleep_latency = 50;
> + omap3_power_states[OMAP3_STATE_C3].wakeup_latency = 50;
> + omap3_power_states[OMAP3_STATE_C3].threshold = 300;
> + omap3_power_states[OMAP3_STATE_C3].mpu_state = PWRDM_POWER_RET;
> omap3_power_states[OMAP3_STATE_C3].core_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C3].flags = CPUIDLE_FLAG_TIME_VALID |
> CPUIDLE_FLAG_CHECK_BM;
>
> - /* C4 . MPU CSWR + Core CSWR*/
> + /* C4 . MPU OFF + Core inactive */
> omap3_power_states[OMAP3_STATE_C4].valid = 1;
> omap3_power_states[OMAP3_STATE_C4].type = OMAP3_STATE_C4;
> - omap3_power_states[OMAP3_STATE_C4].sleep_latency = 2500;
> - omap3_power_states[OMAP3_STATE_C4].wakeup_latency = 7500;
> - omap3_power_states[OMAP3_STATE_C4].threshold = 12000;
> - omap3_power_states[OMAP3_STATE_C4].mpu_state = PWRDM_POWER_RET;
> - omap3_power_states[OMAP3_STATE_C4].core_state = PWRDM_POWER_RET;
> + omap3_power_states[OMAP3_STATE_C4].sleep_latency = 1500;
> + omap3_power_states[OMAP3_STATE_C4].wakeup_latency = 1800;
> + omap3_power_states[OMAP3_STATE_C4].threshold = 4000;
> + omap3_power_states[OMAP3_STATE_C4].mpu_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C4].core_state = PWRDM_POWER_ON;
> omap3_power_states[OMAP3_STATE_C4].flags = CPUIDLE_FLAG_TIME_VALID |
> CPUIDLE_FLAG_CHECK_BM;
>
> - /* C5 . MPU OFF + Core CSWR */
> + /* C5 . MPU CSWR + Core CSWR*/
> omap3_power_states[OMAP3_STATE_C5].valid = 1;
> omap3_power_states[OMAP3_STATE_C5].type = OMAP3_STATE_C5;
> - omap3_power_states[OMAP3_STATE_C5].sleep_latency = 3000;
> - omap3_power_states[OMAP3_STATE_C5].wakeup_latency = 8500;
> - omap3_power_states[OMAP3_STATE_C5].threshold = 15000;
> - omap3_power_states[OMAP3_STATE_C5].mpu_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C5].sleep_latency = 2500;
> + omap3_power_states[OMAP3_STATE_C5].wakeup_latency = 7500;
> + omap3_power_states[OMAP3_STATE_C5].threshold = 12000;
> + omap3_power_states[OMAP3_STATE_C5].mpu_state = PWRDM_POWER_RET;
> omap3_power_states[OMAP3_STATE_C5].core_state = PWRDM_POWER_RET;
> omap3_power_states[OMAP3_STATE_C5].flags = CPUIDLE_FLAG_TIME_VALID |
> CPUIDLE_FLAG_CHECK_BM;
>
> - /* C6 . MPU OFF + Core OFF */
> + /* C6 . MPU OFF + Core CSWR */
> omap3_power_states[OMAP3_STATE_C6].valid = 1;
> omap3_power_states[OMAP3_STATE_C6].type = OMAP3_STATE_C6;
> - omap3_power_states[OMAP3_STATE_C6].sleep_latency = 10000;
> - omap3_power_states[OMAP3_STATE_C6].wakeup_latency = 30000;
> - omap3_power_states[OMAP3_STATE_C6].threshold = 300000;
> + omap3_power_states[OMAP3_STATE_C6].sleep_latency = 3000;
> + omap3_power_states[OMAP3_STATE_C6].wakeup_latency = 8500;
> + omap3_power_states[OMAP3_STATE_C6].threshold = 15000;
> omap3_power_states[OMAP3_STATE_C6].mpu_state = PWRDM_POWER_OFF;
> - omap3_power_states[OMAP3_STATE_C6].core_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C6].core_state = PWRDM_POWER_RET;
> omap3_power_states[OMAP3_STATE_C6].flags = CPUIDLE_FLAG_TIME_VALID |
> CPUIDLE_FLAG_CHECK_BM;
> +
> + /* C7 . MPU OFF + Core OFF */
> + omap3_power_states[OMAP3_STATE_C7].valid = 1;
> + omap3_power_states[OMAP3_STATE_C7].type = OMAP3_STATE_C7;
> + omap3_power_states[OMAP3_STATE_C7].sleep_latency = 10000;
> + omap3_power_states[OMAP3_STATE_C7].wakeup_latency = 30000;
> + omap3_power_states[OMAP3_STATE_C7].threshold = 300000;
> + omap3_power_states[OMAP3_STATE_C7].mpu_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C7].core_state = PWRDM_POWER_OFF;
> + omap3_power_states[OMAP3_STATE_C7].flags = CPUIDLE_FLAG_TIME_VALID |
> + CPUIDLE_FLAG_CHECK_BM;
> }
>
> struct cpuidle_driver omap3_idle_driver = {
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
From: Felipe Contreras @ 2009-03-11 22:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Trilok Soni, linux-fbdev-devel, linux-omap, felipe.contreras,
linux-kernel
In-Reply-To: <20090311152000.8a3db19c.akpm@linux-foundation.org>
On Thu, Mar 12, 2009 at 12:20 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 11 Mar 2009 22:47:41 +0530
> Trilok Soni <soni.trilok@gmail.com> wrote:
>
>> Hi Felipe,
>>
>> On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras
>
> I bet he thought we'd forgotten.
You bet correctly :)
>> <felipe.contreras@gmail.com> wrote:
>> > From: Felipe Contreras <felipe.contreras@nokia.com>
>> >
>> > The blank operation should receive FB_BLANK_POWERDOWN, not
>> > VESA_POWERDOWN.
>> >
>>
>> Thanks. Looks good.
>>
>> Signed-off-by: Trilok Soni <soni.trilok@gmail.com>
>>
>
> Unfortunately the changelog didn't give me any hint as to the
> seriousness of the problem which was fixed. So I queued it for 2.6.30,
> perhaps inappropriately.
I noticed because of another bug in omapfb which required blanking in
order to actually see something (PM stuff?). If user-space tries to
blank the usual way, it wouldn't work.
My guess is that it's not a big issue, in part because nobody has
noticed, but perhaps I'm wrong. I was hoping the fbdev guys would know
better.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
From: Andrew Morton @ 2009-03-11 22:20 UTC (permalink / raw)
To: Trilok Soni
Cc: felipe.contreras, linux-fbdev-devel, linux-omap, felipe.contreras,
linux-kernel
In-Reply-To: <5d5443650903111017n9c818b0y2119d06ea84c3abf@mail.gmail.com>
On Wed, 11 Mar 2009 22:47:41 +0530
Trilok Soni <soni.trilok@gmail.com> wrote:
> Hi Felipe,
>
> On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras
I bet he thought we'd forgotten.
> <felipe.contreras@gmail.com> wrote:
> > From: Felipe Contreras <felipe.contreras@nokia.com>
> >
> > The blank operation should receive FB_BLANK_POWERDOWN, not
> > VESA_POWERDOWN.
> >
>
> Thanks. Looks good.
>
> Signed-off-by: Trilok Soni <soni.trilok@gmail.com>
>
Unfortunately the changelog didn't give me any hint as to the
seriousness of the problem which was fixed. So I queued it for 2.6.30,
perhaps inappropriately.
^ permalink raw reply
* Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes
From: Kevin Hilman @ 2009-03-11 22:11 UTC (permalink / raw)
To: Tero.Kristo; +Cc: linux-omap
In-Reply-To: <1F18D6510CF0474A8C9500565A7E41A20378951294@NOK-EUMSG-02.mgdnok.nokia.com>
<Tero.Kristo@nokia.com> writes:
> The first patch in this set contains a small bug, missing kfree() for one of the dynamically reserved arrays during init in error path. Sending a fixed patch now.
>
Thanks Tero. I will undo the first version and re-push with this version.
Kevin
>
>>-----Original Message-----
>>From: ext Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>Sent: 09 March, 2009 20:48
>>To: Kristo Tero (Nokia-D/Tampere)
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCH 0/2] OMAP3: GPIO off-mode fixes
>>
>>Tero Kristo <tero.kristo@nokia.com> writes:
>>
>>> These two patches add fixes to GPIO off-mode handling. First
>>patch is
>>> more important as it fixes a HW bug, second one just optimizes
>>> off-mode code a bit by removing a couple of unnecessary
>>registers from the context save.
>>
>>Thanks, pushing both patches to PM branch.
>>
>>Kevin
>>
^ permalink raw reply
* Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: Felipe Balbi @ 2009-03-11 21:00 UTC (permalink / raw)
To: David Brownell; +Cc: OMAP, Steve Sakoman
In-Reply-To: <200903111158.29860.david-b@pacbell.net>
On Wed, Mar 11, 2009 at 10:58:29AM -0800, David Brownell wrote:
> From: David Brownell <dbrownell@users.sourceforge.net>
>
> This patch hooks up the twl4030 MMC1 regulator on Overo,
> as well as the MMC1 card detect signal. The WLAN chip
> connected to MMC2 on some board versions has a dedicated
> regulator.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
> ---
> Patches still needed for LDP/Zoom and Pandora...
>
> arch/arm/mach-omap2/board-overo.c | 55 ++++++++++++++++++++++++------------
> 1 file changed, 37 insertions(+), 18 deletions(-)
>
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -267,10 +267,45 @@ static struct omap_uart_config overo_uar
> .enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
> };
>
> +static struct twl4030_hsmmc_info mmc[] = {
> + {
> + .mmc = 1,
> + .wires = 4,
> + .gpio_cd = -EINVAL,
> + .gpio_wp = -EINVAL,
> + },
> + {
> + .mmc = 2,
> + .wires = 4,
> + .gpio_cd = -EINVAL,
> + .gpio_wp = -EINVAL,
> + .transceiver = true,
> + .ocr_mask = 0x00100000, /* 3.3V */
> + },
> + {} /* Terminator */
> +};
> +
> +static struct regulator_consumer_supply overo_vmmc1_supply = {
> + .supply = "vmmc",
> +};
> +
> +static int overo_twl_gpio_setup(struct device *dev,
> + unsigned gpio, unsigned ngpio)
> +{
> + /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> + mmc[0].gpio_cd = gpio + 0;
> + twl4030_mmc_init(mmc);
> +
> + overo_vmmc1_supply.dev = mmc[0].dev;
> +
> + return 0;
> +}
> +
> static struct twl4030_gpio_platform_data overo_gpio_data = {
> .gpio_base = OMAP_MAX_GPIO_LINES,
> .irq_base = TWL4030_GPIO_IRQ_BASE,
> .irq_end = TWL4030_GPIO_IRQ_END,
> + .setup = overo_twl_gpio_setup,
> };
>
> static struct twl4030_usb_data overo_usb_data = {
> @@ -287,6 +322,8 @@ static struct regulator_init_data overo_
> | REGULATOR_CHANGE_MODE
> | REGULATOR_CHANGE_STATUS,
> },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &overo_vmmc1_supply,
> };
>
> /* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
> @@ -343,23 +380,6 @@ static struct platform_device *overo_dev
> &overo_lcd_device,
> };
>
> -static struct twl4030_hsmmc_info mmc[] __initdata = {
> - {
> - .mmc = 1,
> - .wires = 4,
> - .gpio_cd = -EINVAL,
> - .gpio_wp = -EINVAL,
> - },
> - {
> - .mmc = 2,
> - .wires = 4,
> - .gpio_cd = -EINVAL,
> - .gpio_wp = -EINVAL,
> - .transceiver = true,
> - },
> - {} /* Terminator */
> -};
> -
> static void __init overo_init(void)
> {
> overo_i2c_init();
> @@ -367,7 +387,6 @@ static void __init overo_init(void)
> omap_board_config = overo_config;
> omap_board_config_size = ARRAY_SIZE(overo_config);
> omap_serial_init();
> - twl4030_mmc_init(mmc);
> usb_musb_init();
> usb_ehci_init();
> overo_flash_init();
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
^ permalink raw reply
* Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: Felipe Balbi @ 2009-03-11 20:59 UTC (permalink / raw)
To: David Brownell; +Cc: me, OMAP, Steve Sakoman, Mark Brown
In-Reply-To: <200903111334.59499.david-b@pacbell.net>
On Wed, Mar 11, 2009 at 12:34:59PM -0800, David Brownell wrote:
> On Wednesday 11 March 2009, Felipe Balbi wrote:
> > with this patch I get:
> >
> > regulator: Unable to get requested regulator: vmmc_aux
>
> That's completely safe; annoying and useless noise from
> the regulator core, that's all.
You're right. And the appended patch should probably get merged via
Mark as it really makes sense when bootloader keeps the regulator on.
--
balbi
^ permalink raw reply
* Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: David Brownell @ 2009-03-11 20:34 UTC (permalink / raw)
To: me; +Cc: OMAP, Steve Sakoman, Mark Brown
In-Reply-To: <20090311193347.GC19730@gandalf>
On Wednesday 11 March 2009, Felipe Balbi wrote:
> with this patch I get:
>
> regulator: Unable to get requested regulator: vmmc_aux
That's completely safe; annoying and useless noise from
the regulator core, that's all.
> ------------[ cut here ]------------
> WARNING: at drivers/regulator/core.c:1216 regulator_disable+0x64/0x90()
> unbalanced disables for supply mmci-omap-hs.0-vmmc
This is that bug in the regulator framework which
Mark is so reluctant to fix ... the one whereby
regulators aren't initialized into a known state.
In this case, the Overo probably booted from MMC,
and U-Boot left the MMC1 regulator on. The first
thing the MMC stack does is force the regulator
off, so Linux can properly enumerate the device.
(Of course, some boards will boot from flash and
not turn the regulator on...)
I posted a patch to address that regulator framework
bug earlier:
http://marc.info/?l=linux-omap&m=123654568330807&w=2
I've appended a slightly simplified version of
that patch below.
> Modules linked in:
> [<c0363198>] (dump_stack+0x0/0x14) from [<c004f0fc>] (warn_slowpath+0x6c/0x88)
> [<c004f090>] (warn_slowpath+0x0/0x88) from [<c01b2694>] (regulator_disable+0x64/0x90)
> r3:cf9deae0 r2:c0425c79
> r7:cfa16e00 r6:cfa06c38 r5:cfa16e00 r4:fffffffb
> [<c01b2630>] (regulator_disable+0x0/0x90) from [<c025ed6c>] (mmc_regulator_set_ocr+0xb0/0xcc)
> r7:cfa16e00 r6:00000001 r5:00000000 r4:00000000
> [<c025ecbc>] (mmc_regulator_set_ocr+0x0/0xcc) from [<c003af08>] (twl_mmc1_set_power+0xc0/0xec)
> r7:cfa93538 r6:00000000 r5:00000000 r4:c04a5b58
> [<c003ae48>] (twl_mmc1_set_power+0x0/0xec) from [<c0267b34>] (omap_mmc_set_ios+0x54/0x314)
> r7:cfa93538 r6:cfa935c0 r5:cfa93400 r4:cf9a93c0
> [<c0267ae0>] (omap_mmc_set_ios+0x0/0x314) from [<c025e54c>] (mmc_power_off+0x90/0x9c)
> r7:00000000 r6:00000000 r5:cfa93400 r4:00000000
> [<c025e4bc>] (mmc_power_off+0x0/0x9c) from [<c025ea98>] (mmc_start_host+0x14/0x24)
> r5:00000000 r4:cfa93400
> [<c025ea84>] (mmc_start_host+0x0/0x24) from [<c025fcbc>] (mmc_add_host+0x64/0x70)
> r5:00000000 r4:cfa93400
> [<c025fc58>] (mmc_add_host+0x0/0x70) from [<c0021cac>] (omap_mmc_probe+0x464/0x614)
> r5:cfa935c0 r4:cfa93470
> [<c0021848>] (omap_mmc_probe+0x0/0x614) from [<c01d7b60>] (platform_drv_probe+0x20/0x24)
> [<c01d7b40>] (platform_drv_probe+0x0/0x24) from [<c01d6d54>] (driver_probe_device+0xd4/0x180)
> [<c01d6c80>] (driver_probe_device+0x0/0x180) from [<c01d6e68>] (__driver_attach+0x68/0x8c)
> r7:cfa15120 r6:c0499e34 r5:cfa06290 r4:cfa06208
> [<c01d6e00>] (__driver_attach+0x0/0x8c) from [<c01d65f8>] (bus_for_each_dev+0x4c/0x80)
> r7:cfa15120 r6:c0499e34 r5:c01d6e00 r4:00000000
> [<c01d65ac>] (bus_for_each_dev+0x0/0x80) from [<c01d6b98>] (driver_attach+0x20/0x28)
> r6:c0499e34 r5:00000000 r4:00000000
> [<c01d6b78>] (driver_attach+0x0/0x28) from [<c01d5ed4>] (bus_add_driver+0xa4/0x20c)
> [<c01d5e30>] (bus_add_driver+0x0/0x20c) from [<c01d708c>] (driver_register+0x98/0x120)
> r8:00000000 r7:c002182c r6:c0499e34 r5:00000000 r4:c0028a58
> [<c01d6ff4>] (driver_register+0x0/0x120) from [<c01d8008>] (platform_driver_register+0x6c/0x88)
> r9:00000000 r8:00000000 r7:c002182c r6:00000000 r5:00000000
> r4:c0028a58
> [<c01d7f9c>] (platform_driver_register+0x0/0x88) from [<c0021840>] (omap_mmc_init+0x14/0x1c)
> [<c002182c>] (omap_mmc_init+0x0/0x1c) from [<c002d2bc>] (__exception_text_end+0x5c/0x19c)
> [<c002d260>] (__exception_text_end+0x0/0x19c) from [<c0008400>] (kernel_init+0x80/0xf4)
> r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:c0028a58
> [<c0008380>] (kernel_init+0x0/0xf4) from [<c0051f50>] (do_exit+0x0/0x6a4)
> r4:00000000
> ---[ end trace e00c52255ce89b8f ]---
> mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
> regulator: Unable to get requested regulator: vmmc
>
> does this depend on any patch dave ? Using current omap HEAD.
I was probably running with the patch appended below.
- Dave
========== CUT HERE
From: David Brownell <dbrownell@users.sourceforge.net>
Make the regulator setup code simpler and more consistent:
- The only difference between "boot_on" and "always_on" is
that an "always_on" regulator won't be disabled. Both will
be active (and usecount will be 1) on return from setup.
- Regulators not marked as "boot_on" or "always_on" won't
be active (and usecount will be 0) on return from setup.
The exception to that simple policy is when there's a non-Linux
interface to the regulator ... e.g. if either a DSP or the CPU
running Linux can enable the regulator, and the DSP needs it to
be on, then it will be on.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/regulator/core.c | 47 +++++++++++++++++++++++++++++----------------
1 file changed, 31 insertions(+), 16 deletions(-)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -711,6 +711,7 @@ static int set_machine_constraints(struc
int ret = 0;
const char *name;
struct regulator_ops *ops = rdev->desc->ops;
+ int enable = 0;
if (constraints->name)
name = constraints->name;
@@ -799,10 +800,6 @@ static int set_machine_constraints(struc
}
}
- /* are we enabled at boot time by firmware / bootloader */
- if (rdev->constraints->boot_on)
- rdev->use_count = 1;
-
/* do we need to setup our suspend state */
if (constraints->initial_state) {
ret = suspend_prepare(rdev, constraints->initial_state);
@@ -814,21 +811,39 @@ static int set_machine_constraints(struc
}
}
- /* if always_on is set then turn the regulator on if it's not
- * already on. */
- if (constraints->always_on && ops->enable &&
- ((ops->is_enabled && !ops->is_enabled(rdev)) ||
- (!ops->is_enabled && !constraints->boot_on))) {
- ret = ops->enable(rdev);
- if (ret < 0) {
- printk(KERN_ERR "%s: failed to enable %s\n",
- __func__, name);
- rdev->constraints = NULL;
- goto out;
+ /* Should this be enabled when we return from here? The difference
+ * between "boot_on" and "always_on" is that "always_on" regulators
+ * won't ever be disabled.
+ */
+ if (constraints->boot_on || constraints->always_on)
+ enable = 1;
+
+ /* Make sure the regulator isn't wrongly enabled or disabled.
+ * Bootloaders are often sloppy about leaving things on; and
+ * sometimes Linux wants to use a different model.
+ */
+ if (enable) {
+ if (ops->enable) {
+ ret = ops->enable(rdev);
+ if (ret < 0)
+ pr_warning("%s: %s disable --> %d\n",
+ __func__, name, ret);
+ }
+ if (ret >= 0)
+ rdev->use_count = 1;
+ } else {
+ if (ops->disable) {
+ ret = ops->disable(rdev);
+ if (ret < 0)
+ pr_warning("%s: %s disable --> %d\n",
+ __func__, name, ret);
}
}
- print_constraints(rdev);
+ if (ret < 0)
+ rdev->constraints = NULL;
+ else
+ print_constraints(rdev);
out:
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: Felipe Balbi @ 2009-03-11 19:33 UTC (permalink / raw)
To: David Brownell; +Cc: OMAP, Steve Sakoman
In-Reply-To: <200903111158.29860.david-b@pacbell.net>
On Wed, Mar 11, 2009 at 10:58:29AM -0800, David Brownell wrote:
> From: David Brownell <dbrownell@users.sourceforge.net>
>
> This patch hooks up the twl4030 MMC1 regulator on Overo,
> as well as the MMC1 card detect signal. The WLAN chip
> connected to MMC2 on some board versions has a dedicated
> regulator.
>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> Patches still needed for LDP/Zoom and Pandora...
with this patch I get:
regulator: Unable to get requested regulator: vmmc_aux
------------[ cut here ]------------
WARNING: at drivers/regulator/core.c:1216 regulator_disable+0x64/0x90()
unbalanced disables for supply mmci-omap-hs.0-vmmc
Modules linked in:
[<c0363198>] (dump_stack+0x0/0x14) from [<c004f0fc>] (warn_slowpath+0x6c/0x88)
[<c004f090>] (warn_slowpath+0x0/0x88) from [<c01b2694>] (regulator_disable+0x64/0x90)
r3:cf9deae0 r2:c0425c79
r7:cfa16e00 r6:cfa06c38 r5:cfa16e00 r4:fffffffb
[<c01b2630>] (regulator_disable+0x0/0x90) from [<c025ed6c>] (mmc_regulator_set_ocr+0xb0/0xcc)
r7:cfa16e00 r6:00000001 r5:00000000 r4:00000000
[<c025ecbc>] (mmc_regulator_set_ocr+0x0/0xcc) from [<c003af08>] (twl_mmc1_set_power+0xc0/0xec)
r7:cfa93538 r6:00000000 r5:00000000 r4:c04a5b58
[<c003ae48>] (twl_mmc1_set_power+0x0/0xec) from [<c0267b34>] (omap_mmc_set_ios+0x54/0x314)
r7:cfa93538 r6:cfa935c0 r5:cfa93400 r4:cf9a93c0
[<c0267ae0>] (omap_mmc_set_ios+0x0/0x314) from [<c025e54c>] (mmc_power_off+0x90/0x9c)
r7:00000000 r6:00000000 r5:cfa93400 r4:00000000
[<c025e4bc>] (mmc_power_off+0x0/0x9c) from [<c025ea98>] (mmc_start_host+0x14/0x24)
r5:00000000 r4:cfa93400
[<c025ea84>] (mmc_start_host+0x0/0x24) from [<c025fcbc>] (mmc_add_host+0x64/0x70)
r5:00000000 r4:cfa93400
[<c025fc58>] (mmc_add_host+0x0/0x70) from [<c0021cac>] (omap_mmc_probe+0x464/0x614)
r5:cfa935c0 r4:cfa93470
[<c0021848>] (omap_mmc_probe+0x0/0x614) from [<c01d7b60>] (platform_drv_probe+0x20/0x24)
[<c01d7b40>] (platform_drv_probe+0x0/0x24) from [<c01d6d54>] (driver_probe_device+0xd4/0x180)
[<c01d6c80>] (driver_probe_device+0x0/0x180) from [<c01d6e68>] (__driver_attach+0x68/0x8c)
r7:cfa15120 r6:c0499e34 r5:cfa06290 r4:cfa06208
[<c01d6e00>] (__driver_attach+0x0/0x8c) from [<c01d65f8>] (bus_for_each_dev+0x4c/0x80)
r7:cfa15120 r6:c0499e34 r5:c01d6e00 r4:00000000
[<c01d65ac>] (bus_for_each_dev+0x0/0x80) from [<c01d6b98>] (driver_attach+0x20/0x28)
r6:c0499e34 r5:00000000 r4:00000000
[<c01d6b78>] (driver_attach+0x0/0x28) from [<c01d5ed4>] (bus_add_driver+0xa4/0x20c)
[<c01d5e30>] (bus_add_driver+0x0/0x20c) from [<c01d708c>] (driver_register+0x98/0x120)
r8:00000000 r7:c002182c r6:c0499e34 r5:00000000 r4:c0028a58
[<c01d6ff4>] (driver_register+0x0/0x120) from [<c01d8008>] (platform_driver_register+0x6c/0x88)
r9:00000000 r8:00000000 r7:c002182c r6:00000000 r5:00000000
r4:c0028a58
[<c01d7f9c>] (platform_driver_register+0x0/0x88) from [<c0021840>] (omap_mmc_init+0x14/0x1c)
[<c002182c>] (omap_mmc_init+0x0/0x1c) from [<c002d2bc>] (__exception_text_end+0x5c/0x19c)
[<c002d260>] (__exception_text_end+0x0/0x19c) from [<c0008400>] (kernel_init+0x80/0xf4)
r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:c0028a58
[<c0008380>] (kernel_init+0x0/0xf4) from [<c0051f50>] (do_exit+0x0/0x6a4)
r4:00000000
---[ end trace e00c52255ce89b8f ]---
mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc
does this depend on any patch dave ? Using current omap HEAD.
--
balbi
^ permalink raw reply
* Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
From: Felipe Balbi @ 2009-03-11 19:16 UTC (permalink / raw)
To: Ben Dooks; +Cc: Ari Kauppi, ben-linux, linux-omap, linux-i2c
In-Reply-To: <20090310005222.GE19758@fluff.org.uk>
On Tue, Mar 10, 2009 at 12:52:22AM +0000, Ben Dooks wrote:
> On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote:
> > I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
> > (and thus LOCKDEP) are disabled.
> >
> > Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
> > but IRQF_DISABLED is needed for proper behaviour.
> >
> > Signed-off-by: Ari Kauppi <Ext-Ari.Kauppi@nokia.com>
> > Acked-by: Felipe Balbi <felipe.balbi@nokia.com>
> > ---
> > drivers/i2c/busses/i2c-omap.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index 0c3ed41..18af43f 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev)
> > omap_i2c_init(dev);
> >
> > isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
> > - r = request_irq(dev->irq, isr, 0, pdev->name, dev);
> > + r = request_irq(dev->irq, isr, IRQF_DISABLED, pdev->name, dev);
>
> Is disabling all IRQs on the system the right thing to do?
if not we could fall into stack overflow, right ?
--
balbi
^ permalink raw reply
* [patch 2.6.29-rc7-omap-git] Overo: MMC regulator configuration
From: David Brownell @ 2009-03-11 18:58 UTC (permalink / raw)
To: OMAP; +Cc: Steve Sakoman
From: David Brownell <dbrownell@users.sourceforge.net>
This patch hooks up the twl4030 MMC1 regulator on Overo,
as well as the MMC1 card detect signal. The WLAN chip
connected to MMC2 on some board versions has a dedicated
regulator.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
Patches still needed for LDP/Zoom and Pandora...
arch/arm/mach-omap2/board-overo.c | 55 ++++++++++++++++++++++++------------
1 file changed, 37 insertions(+), 18 deletions(-)
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -267,10 +267,45 @@ static struct omap_uart_config overo_uar
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .mmc = 1,
+ .wires = 4,
+ .gpio_cd = -EINVAL,
+ .gpio_wp = -EINVAL,
+ },
+ {
+ .mmc = 2,
+ .wires = 4,
+ .gpio_cd = -EINVAL,
+ .gpio_wp = -EINVAL,
+ .transceiver = true,
+ .ocr_mask = 0x00100000, /* 3.3V */
+ },
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply overo_vmmc1_supply = {
+ .supply = "vmmc",
+};
+
+static int overo_twl_gpio_setup(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ /* gpio + 0 is "mmc0_cd" (input/IRQ) */
+ mmc[0].gpio_cd = gpio + 0;
+ twl4030_mmc_init(mmc);
+
+ overo_vmmc1_supply.dev = mmc[0].dev;
+
+ return 0;
+}
+
static struct twl4030_gpio_platform_data overo_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end = TWL4030_GPIO_IRQ_END,
+ .setup = overo_twl_gpio_setup,
};
static struct twl4030_usb_data overo_usb_data = {
@@ -287,6 +322,8 @@ static struct regulator_init_data overo_
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &overo_vmmc1_supply,
};
/* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
@@ -343,23 +380,6 @@ static struct platform_device *overo_dev
&overo_lcd_device,
};
-static struct twl4030_hsmmc_info mmc[] __initdata = {
- {
- .mmc = 1,
- .wires = 4,
- .gpio_cd = -EINVAL,
- .gpio_wp = -EINVAL,
- },
- {
- .mmc = 2,
- .wires = 4,
- .gpio_cd = -EINVAL,
- .gpio_wp = -EINVAL,
- .transceiver = true,
- },
- {} /* Terminator */
-};
-
static void __init overo_init(void)
{
overo_i2c_init();
@@ -367,7 +387,6 @@ static void __init overo_init(void)
omap_board_config = overo_config;
omap_board_config_size = ARRAY_SIZE(overo_config);
omap_serial_init();
- twl4030_mmc_init(mmc);
usb_musb_init();
usb_ehci_init();
overo_flash_init();
^ permalink raw reply
* RE: [PATCH 2/2] OMAP: McBSP: Do not enable or disable clocks on failed path
From: ext-Eero.Nurkkala @ 2009-03-11 18:28 UTC (permalink / raw)
To: jarkko.nikula; +Cc: linux-omap
In-Reply-To: <20090311130316.fb9ef9c1.jarkko.nikula@nokia.com>
> Didn't check any deeply can clk_disable sleep in any case but anyway
> there is no need to cover it with spinlock so better to not hold the
> lock while disabling.
>
>
> Jarkko
Actually, is there any room for the race? I remember someone saying
the clk:s have counters, so:
1. If mcbsp is "taken", clks on;
- and at the same time, the previous mcbsp has been released, leaving clks off
, clk counter decrements, nothing bad happens..
- Eero
^ permalink raw reply
* RE: Suspend/Resume support with Omap2fb
From: Hiremath, Vaibhav @ 2009-03-11 18:08 UTC (permalink / raw)
To: tomi.valkeinen@nokia.com; +Cc: linux-omap@vger.kernel.org
In-Reply-To: <1236775798.12797.33.camel@tubuntu>
Thanks,
Vaibhav Hiremath
> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Wednesday, March 11, 2009 6:20 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: Suspend/Resume support with Omap2fb
>
> On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote:
>
> > > >
> > > > How have you tested this?
> > > > Have you also tested with "echo mem > /sys/power/state"?
> > > > Are you using Kevin's power management tree? What is default
> > > configuration of your kernel during this test?
> > >
> > > It's been some time since I tested it, but it did work on OMAP3
> SDP
> > > with
> > > the pm-branch. Only changed needed were the
> > > get_last_off_on_transaction_id and omapfb -> omapdss. I also
> tested
> > > echo
> > > mem > ....
> > >
> > > I'll try to find time to test it again with latest trees.
> > >
> > [Hiremath, Vaibhav] That would be great, I am also trying few
> things here at my end. Hopefully I will get something.
>
> Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then
> merged pm-branch, and made the changes mentioned above. I get some
> warnings from getnstimeofday when resuming the kernel, but they seem
> to
> be unrelated to DSS, and the image is fine after resume. I used my
> dss_omap_3430sdp_defconfig and made the following commands to enable
> PM:
>
> echo 1 > /sys/power/clocks_off_while_idle
> echo 1 > /sys/power/enable_off_mode
> echo 1 > /sys/power/voltage_off_while_idle
> echo 1 > /sys/power/sleep_while_idle
>
[Hiremath, Vaibhav] Tomi, I looked into your latest code base, and I can see that you have added suspend and resume functionality and as you mentioned it is working for you.
The only difference I could point out here is, I am handling suspend at driver level (fb and v4l2) and you are handling it at DSS2 level. I can give try to your implementation; tomorrow morning after reaching to office first thing I will try this and let you know.
Just to share with wider audience, I am seeing some abrupt behavior and I doubt some timing synchronization is causing problem. I could see suspend is working if I comment "ovl->enable" or if I call "echo "gfx e:0 > /sys/devices/platform/omapfb/overlays". Although I have same implementation in omapfb_suspend and it does disables clock and overlay, system doesn't go to off state. It always gives error for dss_prwm.
Tomi,
Can you try enabling CONFIG_CPU_IDLE flag and see whether it is going to state5 or not?
And I think it won't go due to obvious reasons, framebuffer will hold the clocks. You have to have something in your framebuffer driver to trigger display disable. I have implemented timer here to do that.
I will send you the patch once I get rid of this issue.
> Tomi
>
>
^ permalink raw reply
* [PATCH] OMAP:clock: missing list_del for clk_notifier_unregister
From: Nishanth Menon @ 2009-03-11 17:59 UTC (permalink / raw)
To: Woodruff, Richard, ameya.palande
Cc: Menon, Nishanth, linux-omap@vger.kernel.org, ext Paul Walmsley,
Nayak, Rajendra, Gupta, Ramesh
In-Reply-To: <13B9B4C6EF24D648824FF11BE8967162037B763B7D@dlee02.ent.ti.com>
>From b30537e692ac7e72858479327935b16813ea3f56 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm@ti.com>
Date: Wed, 11 Mar 2009 11:29:11 -0500
Subject: [PATCH] OMAP:clock: missing list_del for clk_notifier_unregister
Apologies on the spam.. looks like my git-send-email needs a bit more
tweaking :(.. sending from gmail..
clk_notifier_unregister should clean the list before
freeing clock notifier, else clk_notifier_list is
filled with dangling pointers
Issue seen while repetative loading/unloading of bridgedriver
Ref: http://marc.info/?t=123678326300002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/plat-omap/clock.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c8d9e96..523d1b0 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -725,8 +725,11 @@ int clk_notifier_unregister(struct clk *clk, struct
notifier_block *nb)
* XXX ugh, layering violation. there should be some
* support in the notifier code for this.
*/
- if (!cn->notifier_head.head)
+ if (!cn->notifier_head.head) {
+ /* Free up my clock node too */
+ list_del(&cn->node);
kfree(cn);
+ }
} else {
r = -ENOENT;
--
1.5.4.3
^ permalink raw reply related
* Re: [Linux-fbdev-devel] [PATCH] omapfb: Fix argument of blank operation.
From: Trilok Soni @ 2009-03-11 17:17 UTC (permalink / raw)
To: Felipe Contreras
Cc: linux-fbdev-devel, linux-omap, Felipe Contreras, linux-kernel,
Andrew Morton
In-Reply-To: <1228430755-4221-1-git-send-email-felipe.contreras@gmail.com>
Hi Felipe,
On Fri, Dec 5, 2008 at 4:15 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> From: Felipe Contreras <felipe.contreras@nokia.com>
>
> The blank operation should receive FB_BLANK_POWERDOWN, not
> VESA_POWERDOWN.
>
Thanks. Looks good.
Signed-off-by: Trilok Soni <soni.trilok@gmail.com>
--
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
^ permalink raw reply
* RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
From: Menon, Nishanth @ 2009-03-11 16:55 UTC (permalink / raw)
To: Woodruff, Richard, linux-omap@vger.kernel.org
Cc: ext Paul Walmsley, Nayak, Rajendra, Gupta, Ramesh
In-Reply-To: <13B9B4C6EF24D648824FF11BE8967162037B763B7D@dlee02.ent.ti.com>
> -----Original Message-----
> From: Woodruff, Richard
> Sent: Wednesday, March 11, 2009 6:40 PM
> To: Menon, Nishanth; linux-omap@vger.kernel.org
> Cc: ext Paul Walmsley; Nayak, Rajendra; Gupta, Ramesh
> Subject: RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
>
> > It does not make sense for clock notifier_registration to oops out.. it
> has'nt
> > come out of init even..
> >
> > This looks like list_del missing in clock_notifier unregistration
> function :(.
> > I have a patch in place.. sending in a few mins
>
> Yes. Side issue I pointed out will come up later. If notifier doesn't
> work there might be a few bugs its useable.
Would this appear as the following crash (after 14-18 iterations now with my clk_notifer_unregister patch):
Unable to handle kernel paging request at virtual address 80200800
pgd = c3eb8000
*pgd=00000000[80200800]
Internal error: Oops: 5 [#1]
Modules linked in:Modules linked in: [last unloaded: bridgedriver] [last unloaded: bridgedriver]
CPU: 0 Not tainted (2.6.28-omap1-00211-gcb75442-dirty #6)
PC is at vmap_page_range+0xe4/0x1c4
LR is at vmap_page_range+0x160/0x1c4
pc : [<c0096fe8>] lr : [<c0097064>] psr: 80000013
<snip>
Backtrace: Backtrace:
[<c0096f04>] [<c0096f04>] (vmap_page_range+0x0/0x1c4) (vmap_page_range+0x0/0x1c4) from [<c00970f0>] from [<c00970f0>] (map_vm_area+0x28/0x40)
(map_vm_area+0x28/0x40)
[<c00970c8>] [<c00970c8>] (map_vm_area+0x0/0x40) (map_vm_area+0x0/0x40) from [<c009720c>] from [<c009720c>] (__vmalloc_area_node+0x104/0x130)
(__vmalloc_area_node+0x104/0x130)
r5:c39e1460 r5:c39e1460 r4:000003a8 r4:000003a8
[<c0097108>] [<c0097108>] (__vmalloc_area_node+0x0/0x130) (__vmalloc_area_node+0x0/0x130) from [<c00972c8>] from [<c00972c8>] (__vmalloc_node+0x90/0xa8)
(__vmalloc_node+0x90/0xa8)
[<c0097238>] [<c0097238>] (__vmalloc_node+0x0/0xa8) (__vmalloc_node+0x0/0xa8) from [<c009733c>] from [<c009733c>] (vmalloc+0x28/0x34)
(vmalloc+0x28/0x34)
r7:00000000 r7:00000000 r6:4023a000 r6:4023a000 r5:003a75f0 r5:003a75f0 r4:4023a000 r4:4023a000
[<c0097314>] [<c0097314>] (vmalloc+0x0/0x34) (vmalloc+0x0/0x34) from [<c0077808>] from [<c0077808>] (load_module+0x34/0x1468)
(load_module+0x34/0x1468)
[<c00777d4>] [<c00777d4>] (load_module+0x0/0x1468) (load_module+0x0/0x1468) from [<c0078c90>] from [<c0078c90>] (sys_init_module+0x54/0x188)
(sys_init_module+0x54/0x188)
[<c0078c3c>] [<c0078c3c>] (sys_init_module+0x0/0x188) (sys_init_module+0x0/0x188) from [<c002dd80>] from [<c002dd80>] (ret_fast_syscall+0x0/0x2c)
(ret_fast_syscall+0x0/0x2c)
r7:00000080 r7:00000080 r6:00000000 r6:00000000 r5:0000000b r5:0000000b r4:00000000 r4:00000000
Code: Code: 0a000024 0a000024 e51b1030 e51b1030 e51b303c e51b303c e0836101 e0836101 (e5952000) (e5952000)
Regards,
Nishanth Menon
^ permalink raw reply
* RE: DSPBRIDGE+BRIDGE_DVFS: Crashes on multiple reload
From: Woodruff, Richard @ 2009-03-11 16:40 UTC (permalink / raw)
To: Menon, Nishanth, linux-omap@vger.kernel.org
Cc: ext Paul Walmsley, Nayak, Rajendra, Gupta, Ramesh
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0CFF490055@dlee02.ent.ti.com>
> From: Menon, Nishanth
> Sent: Wednesday, March 11, 2009 11:33 AM
> > Does it need DVFS enabled to fail? Is voltage high enough (to current DM)?
> > There were some issues there.
> Yes, Rajendra's VDD change is merged in [1] pm branch.
Ok.
> It does not make sense for clock notifier_registration to oops out.. it has'nt
> come out of init even..
>
> This looks like list_del missing in clock_notifier unregistration function :(.
> I have a patch in place.. sending in a few mins
Yes. Side issue I pointed out will come up later. If notifier doesn't work there might be a few bugs its useable.
Regards,
Richard W.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox