* Peter Ujfalusi <peter.ujfal...@ti.com> [191023 17:04]:
> On 10/23/19 6:31 PM, Tony Lindgren wrote:
> > diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
> > --- a/drivers/dma/ti/cppi41.c
> > +++ b/drivers/dma/ti/cppi41.c
> > @@ -586,9 +586,22 @@ static struct dma_async_tx_descriptor 
> > *cppi41_dma_prep_slave_sg(
> >     enum dma_transfer_direction dir, unsigned long tx_flags, void *context)
> >  {
> >     struct cppi41_channel *c = to_cpp41_chan(chan);
> > +   struct dma_async_tx_descriptor *txd = NULL;
> > +   struct cppi41_dd *cdd = c->cdd;
> >     struct cppi41_desc *d;
> >     struct scatterlist *sg;
> >     unsigned int i;
> > +   int error;
> > +
> > +   error = pm_runtime_get(cdd->ddev.dev);
> 
> If pm_runtime_get()
> pm_runtime_mark_last_busy()+pm_runtime_put_autosuspend() around a code
> which updates a descriptor in _memory_ helps then this best described as
> works by luck ;)

It also checks the cpp41 state for cdd->is_suspended
though. AFAIK we do not currently have any other place
to tell the driver a DMA request is about to start at
some point soon.

> I have a feeling that if you put enough delay between prepare_sg and
> issue_pending in the usb driver then it will keep failing, no?

Nope, it will just queue it and run the queue when awake.

> fwiw, in the cppi41_dma_issue_pending() the driver does:
> 
>       error = pm_runtime_get(cdd->ddev.dev);
> ...
>       if (!cdd->is_suspended)
>               cppi41_run_queue(cdd);
> ...
>       pm_runtime_mark_last_busy(cdd->ddev.dev);
>       pm_runtime_put_autosuspend(cdd->ddev.dev);
> 
> Without waiting for the transfer to complete?

The queue gets run when cpp41 is awake, runtime PM
reference is not released until completed.

> If issue_pending is not starting the transfer right away then the whole
> pm handling is broken in there. imho.

AFAIK there is no other way to do this without tagging
devices with pm_runtime_irq_safe(), which is nasty as
it takes a permanent use count on the parent device.

But yeah, some dmaengine API that can sleep to tell
a request is about to come would simplify things.

I don't think we have anything like that available
right now?

Regards,

Tony

Reply via email to