From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A4AECA9EB9 for ; Wed, 23 Oct 2019 17:16:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE75B21872 for ; Wed, 23 Oct 2019 17:16:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728492AbfJWRQf (ORCPT ); Wed, 23 Oct 2019 13:16:35 -0400 Received: from muru.com ([72.249.23.125]:39462 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726205AbfJWRQe (ORCPT ); Wed, 23 Oct 2019 13:16:34 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id C4EFC80CF; Wed, 23 Oct 2019 17:17:06 +0000 (UTC) Date: Wed, 23 Oct 2019 10:16:28 -0700 From: Tony Lindgren To: Peter Ujfalusi Cc: Dan Williams , Vinod Koul , Alexandre Bailon , Andy Shevchenko , Bin Liu , Daniel Mack , Felipe Balbi , Grygorii Strashko , Johan Hovold , Sekhar Nori , Sebastian Andrzej Siewior , Sergei Shtylyov , dmaengine@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, giulio.benetti@benettiengineering.com, Sebastian Reichel , Skvortsov , Yegor Yefremov Subject: Re: [PATCH] dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle Message-ID: <20191023171628.GO5610@atomide.com> References: <20191023153138.23442-1-tony@atomide.com> <245e1e8f-7933-bae1-b779-239f33d4d449@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <245e1e8f-7933-bae1-b779-239f33d4d449@ti.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org * Peter Ujfalusi [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