> -----Original Message-----
> From: [email protected] [mailto:linux-omap-
> [email protected]] On Behalf Of Shilimkar, Santosh
> Sent: Monday, August 09, 2010 9:43 PM
> To: Kevin Hilman
> Cc: Basak, Partha; Paul Walmsley; [email protected]; Kalliguddi,
> Hema; Raja, Govindraj; Varadarajan, Charulatha
> Subject: RE: Issues with calling pm_runtime functions in
> platform_pm_suspend_noirq/IRQ disabled context.
>
[Snip]
> > >> pm_runtime_put_sync()
> > >> __pm_runtime_put()
> > >> pm_runtime_idle()
> > >> spin_lock_irq()
> > >> __pm_runtime_idle()
> > >> spin_unlock_irq() <--- interrupts unconditionally
> > >> enabled
> > >> dev->bus->pm->runtime_idle()
> > >> spin_lock_irq()
> > >> spin_unlock_irq()
> > >>
> > >> To fix, use the save/restore versions of the spinlock API.
> > >>
> > > Similar thing was thought when this problem was encountered but
> > > there was a concern that it may lead to interrupts are being disable
> > > for longer times
> >
> > why?
> >
> > if interrupts are enabled when this API is used, this patch doesn't
> > change the amount of time interrupts are disabled.
> >
> > if interrupts are already disabled, then you *want* interrupts to be
> > disabled for the entire time.
> >
> Correct me if I am off the track here.
>
> If these API's are _always_ called with interrupt disabled then probably
> we don't even need the new spinlock version locking.
>
> Considering the API is called with interrupt enabled.
>
> int pm_runtime_suspend(struct device *dev)
> {
> int retval;
>
> spin_lock_irqsave(&dev->power.lock, dev->power.lock_flags);
> retval = __pm_runtime_suspend(dev, false);
> spin_unlock_irqrestore(&dev->power.lock, dev->power.lock_flags);c
>
> The interrupt on local cpu remain disabled till "__pm_runtime_suspend"
> does its job and re-enables the interrupts. No?
>
>
Sorry Kevin for oversight. The existing used lock is already a irq version.
You are right. This change should be fine. Some how I was under impression
the existing code was using plain spin lock version.
Really sorry about the noise.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
