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=DKIMWL_WL_HIGH,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 72CB2C2BA83 for ; Thu, 13 Feb 2020 14:15:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 45CF920873 for ; Thu, 13 Feb 2020 14:15:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="asOMwzae" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730041AbgBMOPl (ORCPT ); Thu, 13 Feb 2020 09:15:41 -0500 Received: from fllv0016.ext.ti.com ([198.47.19.142]:54168 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730017AbgBMOPk (ORCPT ); Thu, 13 Feb 2020 09:15:40 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 01DEFZbe066532; Thu, 13 Feb 2020 08:15:35 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1581603335; bh=p3zqSraRoXu80dLQj0ChLg5p0Kgh0PWEYQWEdnB8vCI=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=asOMwzaeRSLZK+VWtNgP7+1EJyqnHBkVnLfD31HePmV+TnRleuoWMsPMLBTGUcKg8 /oM/GLw7a5n8nWq0nZitHNVMPEYVLSit8+pixXv2l/DVx6Rb/0wiq4KXm7s2RYypjG ERcXDJrqhNeinvmPig7pKKXzylyB/kQZYaTOODqA= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 01DEFZ86017289 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Feb 2020 08:15:35 -0600 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Thu, 13 Feb 2020 08:15:35 -0600 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Thu, 13 Feb 2020 08:15:35 -0600 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 01DEFXUK084499; Thu, 13 Feb 2020 08:15:33 -0600 Subject: Re: [PATCH v3 2/6] dmaengine: Add interleaved cyclic transaction type To: Vinod Koul , Laurent Pinchart CC: , Michal Simek , Hyun Kwon , Tejas Upadhyay , Satish Kumar Nagireddy References: <20200123022939.9739-3-laurent.pinchart@ideasonboard.com> <2f3a9e9e-9b74-7c2e-de3a-4897ab0e8205@ti.com> <20200123084352.GU2841@vkoul-mobl> <88aa9920-cdaf-97f0-c36f-66a998860ed2@ti.com> <20200123122304.GB13922@pendragon.ideasonboard.com> <20200124061047.GE2841@vkoul-mobl> <20200124085051.GA4842@pendragon.ideasonboard.com> <20200210140618.GA4727@pendragon.ideasonboard.com> <20200213132938.GF2618@vkoul-mobl> <20200213134843.GG4833@pendragon.ideasonboard.com> <20200213140709.GH2618@vkoul-mobl> From: Peter Ujfalusi Message-ID: <736038ef-e8b2-5542-5cda-d8923e3a4826@ti.com> Date: Thu, 13 Feb 2020 16:15:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200213140709.GH2618@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 Hi Vinod, Laurent, On 13/02/2020 16.07, Vinod Koul wrote: > On 13-02-20, 15:48, Laurent Pinchart wrote: >> Hi Vinod, >> >> On Thu, Feb 13, 2020 at 06:59:38PM +0530, Vinod Koul wrote: >>> On 10-02-20, 16:06, Laurent Pinchart wrote: >>> >>>>>>> The use case here is not to switch to a new configuration, but to switch >>>>>>> to a new buffer. If the transfer had to be terminated manually first, >>>>>>> the DMA engine would potentially miss a frame, which is not acceptable. >>>>>>> We need an atomic way to switch to the next transfer. >>>>>> >>>>>> So in this case you have, let's say a cyclic descriptor with N buffers >>>>>> and they are cyclically capturing data and providing to client/user.. >>>>> >>>>> For the display case it's cyclic over a single buffer that is repeatedly >>>>> displayed over and over again until a new one replaces it, when >>>>> userspace wants to change the content on the screen. Userspace only has >>>>> to provide a new buffer when content changes, otherwise the display has >>>>> to keep displaying the same one. >>>> >>>> Is the use case clear enough, or do you need more information ? Are you >>>> fine with the API for this kind of use case ? >>> >>> So we *know* when a new buffer is being used? >> >> The user of the DMA engine (the DRM DPSUB driver in this case) knows >> when a new buffer needs to be used, as it receives it from userspace. In >> response, it prepares a new interleaved cyclic transaction and queues >> it. At the next IRQ, the DMA engine driver switches to the new >> transaction (the implementation is slightly more complex to handle race >> conditions, but that's the idea). >> >>> IOW would it be possible for display (rather a dmaengine facing >>> display wrapper) to detect that we are reusing an old buffer and keep >>> the cyclic and once detected prepare a new descriptor, submit a new >>> one and then terminate old one which should trigger next transaction >>> to be submitted >> >> I'm not sure to follow you. Do you mean that the display driver should >> submit a non-cyclic transaction for every frame, reusing the same buffer >> for every transaction, until a new buffer is available ? The issue with >> this is that if the CPU load gets high, we may miss a frame, and the >> display will break. The DPDMA hardware implements cyclic support for >> this reason, and we want to use that feature to comply with the real >> time requirements. > > Sorry to cause confusion :) I mean cyclic > > So, DRM DPSUB get first buffer > A.1 Prepare cyclic interleave txn > A.2 Submit the txn (it doesn't start here) > A.3 Invoke issue_pending (that starts the txn) > > DRM DPSUB gets next buffer: > B.1 Prepare cyclic interleave txn > B.2 Submit the txn > B.3 Call terminate for current cyclic txn (we need an updated terminate > which terminates the current txn, right now we have terminate_all which > is a sledge hammer approach) > B.4 Next txn would start once current one is started > > Does this help and make sense in your case That would be a clean way to handle it. We were missing this API for a long time to be able to cancel the ongoing transfer (whether it is cyclic or slave_sg, or memcpy) and move to the next one if there is one pending. +1 from me if it counts ;) > > Thanks > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki