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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, USER_AGENT_MUTT autolearn=ham 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 58337C282CE for ; Tue, 4 Jun 2019 12:48:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2445124987 for ; Tue, 4 Jun 2019 12:48:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559652516; bh=8KWzU9bIvXCC37RanxpEhq9LZPTGbh7hPuzTjcqHB8E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=kuvtrrHri6ldFhQjg+rfMpNsIh8l0MdymzFalrBW0fj82NYB18pKkmVAsZduSj0wr B+p2tg6lVc4WVC/phFPcG5A8C/bIfeqzsGadzn82i/CafwuKOc/fAJ644XFFJ+7304 Ydz7lSryuCM+EiWnThRy4adH7qXs7NDHWFpXQSFo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727398AbfFDMsf (ORCPT ); Tue, 4 Jun 2019 08:48:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:55240 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726994AbfFDMsf (ORCPT ); Tue, 4 Jun 2019 08:48:35 -0400 Received: from localhost (unknown [117.99.94.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6303A2499E; Tue, 4 Jun 2019 12:48:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559652515; bh=8KWzU9bIvXCC37RanxpEhq9LZPTGbh7hPuzTjcqHB8E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B+2Q0Hcayic6UOdY9Jmsi3LIbjIM5UmxNQ2iYsqTOG9NZ6Sxff+kfQzrx8/Rg2Ku6 s0N0VhEdmydgEHrbyULBtatyqbg4EqwSH1vmv8jZCrU3sLeo/1N1IFEDC9XAzpS5kQ pRGeCDyoU7UsSdDmPIcvgRMv0h6Ey04AqWLp+eVI= Date: Tue, 4 Jun 2019 18:15:27 +0530 From: Vinod Koul To: Peter Ujfalusi Cc: dan.j.williams@intel.com, dmaengine@vger.kernel.org, andriy.shevchenko@linux.intel.com Subject: Re: [PATCH] dmaengine: dmatest: Add support for completion polling Message-ID: <20190604124527.GG15118@vkoul-mobl> References: <20190529083724.18182-1-peter.ujfalusi@ti.com> <4f327f4a-9e3d-c9d2-fe48-14e492b07417@ti.com> <793f9f48-0609-4aa5-2688-bf30525e229c@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <793f9f48-0609-4aa5-2688-bf30525e229c@ti.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 03-06-19, 10:05, Peter Ujfalusi wrote: > > I think the main question is how polling for completion should be > > handled when client does not request for completion interrupt, thus we > > will have no callback in the DMA driver when the transfer is completed. > > > > If DMA_PREP_INTERRUPT is set for the tx_descriptor then the polling will > > wait until the DMA driver internally receives the interrupt that the > > transfer is done and sets the cookie to completed state. > > > > However if DMA_PREP_INTERRUPT is not set, the DMA driver will not get > > notification from the HW that is the transfer is done, the only way to > > know is to check the tx_status and based on the residue (if it is 0 then > > it is done) decide what to tell the client. > > > > Should the client call dmaengine_terminate_* after the polling returned > > unconditionally to free up the descriptor? > > This is how omap-dma is handling the polled memcpy support. Yes that is a good question. Even if the client does not set DMA_PREP_INTERRUPT would there be no interrupt generated by controller on txn completion? If not how will next txn be submitted to the hardware. I think we should view DMA_PREP_INTERRUPT from client pov, but controller cannot get away with disabling interrupts IMO. Assuming I had enough caffeine before I thought process, then client would poll descriptor status using cookie and should free up once the cookie is freed, makes sense? -- ~Vinod