Hi Kristen,

On Sat, 19 Mar 2011 05:04:38 +0800
Kristen Carlson Accardi <[email protected]> wrote:

> On Thu, 17 Mar 2011 14:32:42 +0800
> Feng Tang <[email protected]> wrote:
> 
> > Hi Kristen,
> > 
> > For the logical part about where should we add runtime_put/get hook,
> > could you try the following patch?
> > 
> <snip>                                        transfer_list);
> > @@ -670,6 +672,11 @@ static int dw_spi_transfer(struct spi_device
> > *spi, struct spi_message *msg) return -ESHUTDOWN;
> >     }
> >  
> > +   spin_unlock_irqrestore(&dws->lock, flags);
> > +   /* make sure the HW is up */
> > +   pm_runtime_get_sync(dws->parent_dev);
> > +   spin_lock_irqsave(&dws->lock, flags);
> > +
> >     msg->actual_length = 0;
> >     msg->status = -EINPROGRESS;
> >     msg->state = START_STATE;
> > 
> > use pm_runtime_get_sync will make sure the driver/HW is up
> > and ready for the spi_message.
> 
> Hi Feng,
> I think that dw_spi_transfer can be called from interrupt context,
> and my understanding is the pm_runtime_get_sync may sleep (because
> it has to schedule a resume).  I am thinking we'll have to manually
> call pm_runtime_get_noresume and manually resume if we are shutdown.

Good point. But my understanding is, for a spi device (like max3110), if
the dw_spi_transfer is called in interrupt context, then the device
itself should be in runtime running mode. And the dw_spi controller as
its parent, shouldn't be in runtime suspended at this time, and
pm_runtime_get_sync() will simple return without going to sleep, and is
safe to be called. 

Thanks,
Feng

> 
> Kristen
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel

Reply via email to