Re: [RFC PATCH] dma: pl330: add Power Management support

[Krzysztof Kozlowski]

On pon, 2014-09-08 at 10:11 +0200, Krzysztof Kozlowski wrote:
> On piÄ, 2014-09-05 at 17:23 +0200, Lars-Peter Clausen wrote:
> > On 09/05/2014 05:06 PM, Krzysztof Kozlowski wrote:
> > [...]
> > > @@ -2168,11 +2199,23 @@ static void pl330_issue_pending(struct dma_chan *chan)
> > >   {
> > >   	struct dma_pl330_chan *pch = to_pchan(chan);
> > >   	unsigned long flags;
> > > +	bool power_up;
> > >
> > >   	spin_lock_irqsave(&pch->lock, flags);
> > > +	power_up = list_empty(&pch->work_list);
> > >   	list_splice_tail_init(&pch->submitted_list, &pch->work_list);
> > >   	spin_unlock_irqrestore(&pch->lock, flags);
> > >
> > > +	if (power_up) {
> > > +		/*
> > > +		 * Warn on nothing pending. This may break our pm_runtime
> > > +		 * usage counter as it is updated on work_list emptiness
> > > +		 * status.
> > > +		 */
> > > +		WARN_ON(list_empty(&pch->work_list));
> > > +		pm_runtime_get_sync(pch->dmac->ddma.dev);
> > 
> > Unfortunately this does not work. pm_runtime_get_sync() may sleep, where as 
> > the issue_pending callback needs to be able to run from contexts in which 
> > sleeping is not possible.
> 
> Thank you for pointing this out. It seems I'll have to find another
> solution because I really need to runtime suspend this driver...

I found that idea was wrong in few more places. The most important is
that the pl330 is an AMBA device. This means that runtime suspend/resume
callbacks are already implemented (drivers/amba/bus.c) and they are
called instead of my callbacks.

That would be fine... except that these callbacks in amba/bus.c call
clk_preare()/clk_unprepare() which is not safe for atomic context. This
prohibits me from using pm_runtime_irq_safe() which could solve problem
pointed by you. 

Best regards,
Krzysztof


> 
> Best regards,
> Krzysztof
> 
> > 
> > > +	}
> > > +
> > >   	pl330_tasklet((unsigned long)pch);
> > >   }
> > >
> > [...]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/