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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 D0C9CC3F2D1 for ; Tue, 3 Mar 2020 19:23:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2AF42072D for ; Tue, 3 Mar 2020 19:23:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="r1snqAb5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729436AbgCCTXT (ORCPT ); Tue, 3 Mar 2020 14:23:19 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:53208 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728033AbgCCTXS (ORCPT ); Tue, 3 Mar 2020 14:23:18 -0500 Received: from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi [81.175.216.236]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id F3A6B2AF; Tue, 3 Mar 2020 20:23:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1583263397; bh=Q2CDy+4lbTd8LdaNdIvimeg+lgDMXUxRFBoGblnVf1Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r1snqAb5kbGtX1dAO6dzT6eOfMxOZkHdexslHciCMgLl78zTBc/4ZFUi1/DEfSkYi q9VOShZxjt+RxKfGRXHs7WXvNpB/fIWFcS995CWrXtVESVMCyvnE+Pg8lk9TGpVYdN iQ1nDCw0zuxGjJomh2U1kZg/Qcslv+KWuITfHYHY= Date: Tue, 3 Mar 2020 21:22:55 +0200 From: Laurent Pinchart To: Vinod Koul Cc: Peter Ujfalusi , dmaengine@vger.kernel.org, Michal Simek , Hyun Kwon , Tejas Upadhyay , Satish Kumar Nagireddy Subject: Re: [PATCH v3 2/6] dmaengine: Add interleaved cyclic transaction type Message-ID: <20200303192255.GN11333@pendragon.ideasonboard.com> References: <736038ef-e8b2-5542-5cda-d8923e3a4826@ti.com> <20200213165249.GH29760@pendragon.ideasonboard.com> <20200214042349.GS2618@vkoul-mobl> <20200214162236.GK4831@pendragon.ideasonboard.com> <20200219092514.GG2618@vkoul-mobl> <20200226163011.GE4770@pendragon.ideasonboard.com> <20200302034735.GD4148@vkoul-mobl> <20200302073728.GB9177@pendragon.ideasonboard.com> <20200303043254.GN4148@vkoul-mobl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200303043254.GN4148@vkoul-mobl> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org Hi Vinod, On Tue, Mar 03, 2020 at 10:02:54AM +0530, Vinod Koul wrote: > On 02-03-20, 09:37, Laurent Pinchart wrote: > > > > I would be more comfortable in calling an API to do so :) > > > The flow I am thinking is: > > > > > > - prep cyclic1 txn > > > - submit cyclic1 txn > > > - call issue_pending() (cyclic one starts) > > > > > > - prep cyclic2 txn > > > - submit cyclic2 txn > > > - signal_cyclic1_txn aka terminate_cookie() > > > - cyclic1 completes, switch to cyclic2 (dmaengine driver) > > > - get callback for cyclic1 (optional) > > > > > > To check if hw supports terminate_cookie() or not we can check if the > > > callback support is implemented > > > > Two questions though: > > > > - Where is .issue_pending() called for cyclic2 in your above sequence ? > > Surely it should be called somewhere, as the DMA engine API requires > > .issue_pending() to be called for a transfer to be executed, otherwise > > it stays in the submitted but not pending queue. > > Sorry missed that one, I would do that after submit cyclic2 txn step and > then signal signal_cyclic1_txn termination OK, that matches my understanding, good :-) > > - With the introduction of a new .terminate_cookie() operation, we need > > to specify that operation for all transfer types. What's its > > Correct > > > envisioned semantics for non-cyclic transfers ? And how do DMA engine > > drivers report that they support .terminate_cookie() for cyclic > > transfers but not for other transfer types (the counterpart of > > reporting, in my proposition, that .issue_pending() isn't supported > > replace the current cyclic transfer) ? > > Typically for dmaengine controller cyclic is *not* a special mode, only > change is that a list provided to controller is circular. I don't agree with this. For cyclic transfers to be replaceable in a clean way, the feature must be specifically implemented at the hardware level. A DMA engine that supports chaining transfers with an explicit way to override that chaining, and without the logic to report if the inherent race was lost or not, really can't support this API. Furthemore, for non-cyclic transfers, what would .terminate_cookie() do ? I need it to be defined as terminating the current transfer when it ends for the cyclic case, not terminating it immediately. All non-cyclic transfers terminate by themselves when they end, so what would this new operation do ? > So, the .terminate_cookie() should be a feature for all type of txn's. > If for some reason (dont discount what hw designers can do) a controller > supports this for some specific type(s), then they should return > -ENOTSUPP for cookies that do not support and let the caller know. But then the caller can't know ahead of time, it will only find out when it's too late, and can't decide not to use the DMA engine if it doesn't support the feature. I don't think that's a very good option. -- Regards, Laurent Pinchart