> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Shilimkar, Santosh > Sent: Monday, August 09, 2010 9:43 PM > To: Kevin Hilman > Cc: Basak, Partha; Paul Walmsley; linux-omap@xxxxxxxxxxxxxxx; 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
