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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH 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 8F4D5C282CE for ; Tue, 4 Jun 2019 13:35:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 649EB24A00 for ; Tue, 4 Jun 2019 13:35:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="w/TKMaHX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727169AbfFDNfa (ORCPT ); Tue, 4 Jun 2019 09:35:30 -0400 Received: from lelv0143.ext.ti.com ([198.47.23.248]:37506 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727348AbfFDNf3 (ORCPT ); Tue, 4 Jun 2019 09:35:29 -0400 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id x54DZQj0096702; Tue, 4 Jun 2019 08:35:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1559655326; bh=I1f1/nc3GTK/87eQxsgEh380nkUJssWDCrGg4XMrrM4=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=w/TKMaHXarZvMAncPLLwTs5X4M0xd7I22gHdNu8Rz3KbfF5Hz/L1OP+yvRcJUkx91 jVROi5rOhcYFb3LTXrJ5c7O9nt6kWLtStvyo4xefevpIfz89Y8WsCGNCOgZX1QRCJK DBFZK//OGFT/llpxX7v2zJOrjW/qju++doIB7Kio= Received: from DLEE108.ent.ti.com (dlee108.ent.ti.com [157.170.170.38]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x54DZQl8029514 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 4 Jun 2019 08:35:26 -0500 Received: from DLEE111.ent.ti.com (157.170.170.22) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 4 Jun 2019 08:35:25 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Tue, 4 Jun 2019 08:35:25 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id x54DZO6W024117; Tue, 4 Jun 2019 08:35:24 -0500 Subject: Re: [PATCH] dmaengine: dmatest: Add support for completion polling To: Vinod Koul CC: , , References: <20190529083724.18182-1-peter.ujfalusi@ti.com> <4f327f4a-9e3d-c9d2-fe48-14e492b07417@ti.com> <793f9f48-0609-4aa5-2688-bf30525e229c@ti.com> <20190604124527.GG15118@vkoul-mobl> From: Peter Ujfalusi Message-ID: <0e909b8a-8296-7c6a-058a-3fc780d66195@ti.com> Date: Tue, 4 Jun 2019 16:35:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190604124527.GG15118@vkoul-mobl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 04/06/2019 15.45, Vinod Koul wrote: > 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. What happens if client is issuing a DMA memcpy (short one) while interrupts are disabled? The user for this is: drivers/gpu/drm/omapdrm/omap_dmm_tiler.c commit: f5b9930b85dc6319fd6bcc259e447eff62fc691c The interrupt based completion is not going to work in some cases, the DMA driver should obey that the missing DMA_PREP_INTERRUPT really implies that interrupts can not be used. > 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? OK, so clients are expected to call dmaengine_terminate_* unconditionally after the transfer is completed, right? If we use interrupts then the handler would anyway free up the descriptor, so terminating should not do any harm, if we can not have interrupts then terminate will clear up the completed descriptor proactively. In any case I have updated the EDMA patch to do the same thing in case of polling w/o interrupts as it would do in the completion irq handler, and similar approach prepared for omap-dma as well. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki