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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BDC5C4167B for ; Tue, 14 Nov 2023 18:09:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233839AbjKNSJ4 (ORCPT ); Tue, 14 Nov 2023 13:09:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233807AbjKNSJx (ORCPT ); Tue, 14 Nov 2023 13:09:53 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A887121 for ; Tue, 14 Nov 2023 10:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699985389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7C7wW8Bb55AP5fqpBh20EWuPiJ+kxnmpZ3Q7RhkSlhM=; b=aRpOE9BokjZKAr0bGVvJJCr6m3dcod1iyEH8PVFa9opQrN17itDHKDm+tV+L6IuHnsYQH1 AfPS7dSO7omu/VtwVieL9rIInX13sNppIazWmfMP0o9cmolB29a7v2wDtzgYf1dQqU3GXV hKh/cUh0/2mjJf0h4Q1gGQYZHwk2dww= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-528-qYaEBM26PqKVdKi26FpbcQ-1; Tue, 14 Nov 2023 13:09:47 -0500 X-MC-Unique: qYaEBM26PqKVdKi26FpbcQ-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-32f7384d5a2so2747244f8f.3 for ; Tue, 14 Nov 2023 10:09:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699985386; x=1700590186; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7C7wW8Bb55AP5fqpBh20EWuPiJ+kxnmpZ3Q7RhkSlhM=; b=X4YPxs9n5Qh6HRmC4tQFyeUpQ/2cBj6fFF4MFgzyKWECjzGgUPlysvUhxojjZOXCQ2 We3rrSL6LUyiOS+WOeeQvAZurBRLfk9WoWCA/uNFDZajYnuZaDqCLeNxLNZWr60BLrpn aAfTJ4H+IRAM6Ht/UEVywCCAlTcNpdQ5+a8cfgNzNxg+1YbfwN5NZOjANDeX1EwcRrg7 dItSXdsaM1MsISyrjxzva/EV0eBE8ykC8ndMv9APLZnlpYcPKNGmCxbLzp0QlRinYGER +PXatVHxlB5kKTP59uWgvR9SyKFdHmjexZTCQpuXyOTOrimFfeSJbyESY7f5zpg3t6mW 4rZQ== X-Gm-Message-State: AOJu0Yy4bQ/vReWcP1ZE4HwiYiMvbgDfZjjphcrT28oJc548kmI6zEDO 6meZtbyi2ap+L8zexb3j49KSHi5ATgWb97qk0nhIzCv7ciFI0mnf1JWlezp2Clzn0WjsMaB6M5z T3dNFDb7FQGL/ipL3vHhVc4NZ X-Received: by 2002:a05:6000:1567:b0:319:867e:97d7 with SMTP id 7-20020a056000156700b00319867e97d7mr9247568wrz.52.1699985386723; Tue, 14 Nov 2023 10:09:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IGQK+7LGbBm9NWV35d1R+NImBNQNggBVsNQ2twsZUsBZR8uiQcCCjKalWkzse4WmlZcEOZ58Q== X-Received: by 2002:a05:6000:1567:b0:319:867e:97d7 with SMTP id 7-20020a056000156700b00319867e97d7mr9247549wrz.52.1699985386363; Tue, 14 Nov 2023 10:09:46 -0800 (PST) Received: from localhost (205.pool92-176-231.dynamic.orange.es. [92.176.231.205]) by smtp.gmail.com with ESMTPSA id n7-20020a5d4847000000b0032d88e370basm8419537wrs.34.2023.11.14.10.09.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Nov 2023 10:09:46 -0800 (PST) From: Javier Martinez Canillas To: Thomas Zimmermann , linux-kernel@vger.kernel.org Cc: nerdopolis , Pekka Paalanen , dri-devel@lists.freedesktop.org, Sima Vetter , Bilal Elmoussaoui , Maxime Ripard , Gerd Hoffmann , stable@vger.kernel.org, Erico Nunes Subject: Re: [PATCH 2/6] drm: Add drm_atomic_helper_buffer_damage_{iter_init,merged}() helpers In-Reply-To: References: <20231109172449.1599262-1-javierm@redhat.com> <20231109172449.1599262-3-javierm@redhat.com> <8734x872dy.fsf@minerva.mail-host-address-is-not-set> Date: Tue, 14 Nov 2023 19:09:45 +0100 Message-ID: <87r0ks5hqu.fsf@minerva.mail-host-address-is-not-set> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Zimmermann writes: > Hi > > Am 14.11.23 um 16:58 schrieb Javier Martinez Canillas: >> Thomas Zimmermann writes: >> >> Hello Thomas, >> >> Thanks a lot for your feedback. >> >>> Hi >>> >>> Am 09.11.23 um 18:24 schrieb Javier Martinez Canillas: >>>> To be used by drivers that do per-buffer (e.g: virtio-gpu) uploads (rather >>>> than per-plane uploads), since these type of drivers need to handle buffer >>>> damages instead of frame damages. >>>> >>>> The drm_atomic_helper_buffer_damage_iter_init() has the same logic than >>>> drm_atomic_helper_damage_iter_init() but it also takes into account if the >>>> framebuffer attached to plane's state has changed since the last update. >>>> >>>> And the drm_atomic_helper_buffer_damage_merged() is just a version of the >>>> drm_atomic_helper_damage_merged() helper, but it uses the iter_init helper >>>> that is mentioned above. >>>> >>>> Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane") >>>> Cc: # v6.4+ >>>> Reported-by: nerdopolis >>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218115 >>>> Suggested-by: Sima Vetter >>>> Signed-off-by: Javier Martinez Canillas >>>> --- >>>> >>>> drivers/gpu/drm/drm_damage_helper.c | 79 ++++++++++++++++++++++++++--- >>>> include/drm/drm_damage_helper.h | 7 +++ >>>> 2 files changed, 80 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/drm_damage_helper.c b/drivers/gpu/drm/drm_damage_helper.c >>>> index aa2325567918..b72062c9d31c 100644 >>>> --- a/drivers/gpu/drm/drm_damage_helper.c >>>> +++ b/drivers/gpu/drm/drm_damage_helper.c >>>> @@ -204,7 +204,8 @@ EXPORT_SYMBOL(drm_atomic_helper_dirtyfb); >>>> static void >>>> __drm_atomic_helper_damage_iter_init(struct drm_atomic_helper_damage_iter *iter, >>>> const struct drm_plane_state *old_state, >>>> - const struct drm_plane_state *state) >>>> + const struct drm_plane_state *state, >>>> + bool buffer_damage) >>> >>> I think it would be preferable to drop patches one and two and instead >>> add this parameter directly to drm_atomic_helper_damage_iter_init() and >>> drm_atomic_helper_damage_merged(). That's a bit of churn, but more >>> readable code. >>> >> >> Makes sense. I'll do that in v2. > > Instead of modifying these function interfaces, it might be even better > to introduce a state flag in struct drm_plane_state that you can modify > in the plane's atomic_check helper. Something simple like this: > > if (old_fb != new_fb) > plane_state->ignore_damage_clips = true; > > in the affected drivers/planes. In drm_atomic_helper_damage_iter_init() > you can use it to generate a full update. This avoids the churn and is > in line with the overall check/commit design of the DRM framework. > Thanks. That indeed seems more aligned with the rest of the DRM framework. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat