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=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS 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 CCD07C10F14 for ; Fri, 12 Apr 2019 13:50:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 98E7D2084D for ; Fri, 12 Apr 2019 13:50:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aZ2t6lvg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98E7D2084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kY8f5jpnHa2NYICscOyBg3FToDQZSZswXc/gxRkBOFA=; b=aZ2t6lvgxj2lD+ LoHEOWZRSt3dUolbcYrkFP76Q93whvHazI/AKAimp2St85K4N1LtxZLLC3A9enm0fR8zRtEUVY7YQ R/TnMyvAO7p2srum7laH6XllQJIeTJNk/vaIkl+cVLJRSwKCdLJ/gcYBFgDwOxSxUOYZ0A76zOvsF Y98VN50QZHXspyUnbx0rDWWfZnJLuvN3g5Ju6eQXzJRHZWvg7e4yNmgKlEnrMZXfv1sh8XeV0lCDE rHpwW2eTw+gZS20LF7zf9gg9otjeUYpcmtRtRxo2cheg+gPHc0uKqaEbCTcCGzp8YlJPkBcmLoIYf w2cjWiyZBmsUUfqbHSUg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEwZG-0005Ec-AY; Fri, 12 Apr 2019 13:50:10 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEwZB-0004RM-AR; Fri, 12 Apr 2019 13:50:08 +0000 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id EA2202813B7; Fri, 12 Apr 2019 14:50:00 +0100 (BST) Date: Fri, 12 Apr 2019 15:49:57 +0200 From: Boris Brezillon To: Helen Koike Subject: Re: [PATCH v3 2/4] drm/atomic: rename async_{update,check} to amend_{update,check} Message-ID: <20190412154957.558e49f8@collabora.com> In-Reply-To: <20190412125827.5877-3-helen.koike@collabora.com> References: <20190412125827.5877-1-helen.koike@collabora.com> <20190412125827.5877-3-helen.koike@collabora.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190412_065005_737632_36EFBFBD X-CRM114-Status: GOOD ( 20.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Sean Paul , alexandros.frantzis@collabora.com, David Airlie , daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Eric Anholt , Mamta Shukla , tina.zhang@intel.com, kernel@collabora.com, Anthony Koo , Ville =?UTF-8?B?U3lyasOkbMOk?= , "David \(ChunMing\) Zhou" , Maxime Ripard , Jonathan Corbet , Sean Paul , David Francis , linux-doc@vger.kernel.org, amd-gfx@lists.freedesktop.org, Gustavo Padovan , linux-rockchip@lists.infradead.org, Harry Wentland , daniels@collabora.com, Leo Li , linux-arm-msm@vger.kernel.org, Maarten Lankhorst , Russell King , Daniel Vetter , Mikita Lipski , Bhawanpreet Lakha , linux-arm-kernel@lists.infradead.org, dnicoara@chromium.org, =?UTF-8?B?U3TDqXBoYW5l?= Marchesin , Sandy Huang , tomasz Figa , Rob Clark , Thomas Zimmermann , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , freedreno@lists.freedesktop.org, nicholas.kazlauskas@amd.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Helen, On Fri, 12 Apr 2019 09:58:25 -0300 Helen Koike wrote: > Asynchronous update is the ability change the hw state at any time, not > only during vblank. > > Amend mode is the ability to perform 1000 commits to be applied as soon > as possible without waiting for 1000 vblanks. > > async updates can be seen as amend, but the opposite is not true. > > &drm_plane_helper_funcs.atomic_async_{update,check}() was being used by > drivers to implement amend and not async. So rename them to amend. > > Also improve docs explaining the difference. > > If asynchronous is required, normal page flip can be performed using > DRM_MODE_PAGE_FLIP_ASYNC flag. > > Signed-off-by: Helen Koike > > --- > Hello, > > I would like to officially clarify what async update means by adding it > in the docs. > Please correct me if I am wrong, but the current async_{update,check} > callbacks are being used to do amend (the legacy cursor behavior), i.e. > to allow 1000 updates without waiting for 1000 vblanks. Right now, the semantic of async update is driver dependent. Some drivers will amend the last commit touching that plane (amend semantic), others will update the plane buffer immediately which might cause tearing (async semantic). > > So I would like to clarify this in the docs and rename the current > callbacks to reflect this behaviour. I'm all for this clarification, but I don't think renaming the async hooks is a good idea, since some drivers will not do real 'amend'. So, you're changing the name, but it's still confusing :-). How about adding new hooks (and/or flags) for the AMEND case, and keeping the async path untouched. We can then let drivers that currently implement async as amend implement the amend hooks instead. Once you've done that, you can hook that up to the legacy cursor update path so that it first tries one then the other and finally falls back to a sync update if none of ASYNC/AMEND is possible. > > I also see that for real async updates, the flag > DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is > already being used by some drivers actually, in the atomic path, not only > in the legacy page flip, at least is what I understood from > amdgpu_dm_atomic_commit_tail() implementation). Yes, right now, async does not necessarily imply non-block, but Daniel seemed to think that most users want non-block when they do an async page flip, so maybe it should be clarified too. Regards, Boris _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel