From patchwork Wed Oct 11 09:20:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 13416944 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7382FCD6E53 for ; Wed, 11 Oct 2023 09:20:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4849510E5F7; Wed, 11 Oct 2023 09:20:58 +0000 (UTC) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9453E10E5F5 for ; Wed, 11 Oct 2023 09:20:56 +0000 (UTC) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-32d89600755so22094f8f.0 for ; Wed, 11 Oct 2023 02:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1697016055; x=1697620855; darn=lists.freedesktop.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=oAt8f6mcHhtjLLzOwyLl/yEuXy/pt+eQUDW9bFoHsT8=; b=dsdoooWOFOqY0E6VrfqBrUKp6CQua+Cuzuy0zWANqq1lrA7BhijQmBt9URHTGnr7by 9pvvKBNCAUYNiQBeoxIz8sNRa3pJgVwBtleH7T4Zj4fWswLPsmGs/uTYiiJwMrPEBjvI hwfACHgp4YYhWS6FJ6ZKi970ERLhHB1hN2miw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697016055; x=1697620855; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oAt8f6mcHhtjLLzOwyLl/yEuXy/pt+eQUDW9bFoHsT8=; b=DrhurkGHAmd4imk86Go29zOXxdGTwueMxHoNJigbd//Pe4TY7XHfTVwwFNizEbWQgI WGsMzbGUE7JcrmIDMdQxH74dMbxxcKPV/HeNvkg4h4wqjUUx7bWC8TFefF5SQby9ypo6 I8nfInFjreH52uzxOxC+fr70XMJjv368wFxZXnc0Rj7ZCx0gkwDhG+Q/xRnRbyr2h29d XeGmEvxRx//LgLdNNrjP0lCZjV3Mp5T3i7TzfHmki9jjdp7ZWvMJeoWCHfeL9Xz3s8XP hTeA6lxCHUV4ctd/3JiEcFiTCDggjp70bsNXXsPd9SFX0vqSCN/Ub8smCHsWNc+4Xinl H1sA== X-Gm-Message-State: AOJu0Yz58CbEuRbN0/zd71UHYu2lx0iogrQiGgqFZ8y/7ynhHp2vyhJV 4tDPBqzpn5j1TOvsRq98pXVhW3Pkv2T21XaRLTU= X-Google-Smtp-Source: AGHT+IFvVK1rcrqBIGUZdCxHbt0idBWXg7XDXZpbwEVXh9fl2YDMkypGC7xWHOfl1yndKD0lOR6EJQ== X-Received: by 2002:adf:f14e:0:b0:320:b1e:7e6c with SMTP id y14-20020adff14e000000b003200b1e7e6cmr17714071wro.3.1697016054876; Wed, 11 Oct 2023 02:20:54 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id c4-20020a5d4cc4000000b003247d3e5d99sm14858212wrt.55.2023.10.11.02.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 02:20:54 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH] drm/atomic: clarify the rules around drm_atomic_state->allow_modeset Date: Wed, 11 Oct 2023 11:20:51 +0200 Message-Id: <20231011092051.640422-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20231010170746.617366-1-daniel.vetter@ffwll.ch> References: <20231010170746.617366-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pekka Paalanen , Daniel Vetter , Abhinav Kumar , Maxime Ripard , Thomas Zimmermann , Dmitry Baryshkov , Daniel Vetter , Manasi Navare Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" msm is automagically upgrading normal commits to full modesets, and that's a big no-no: - for one this results in full on->off->on transitions on all these crtc, at least if you're using the usual helpers. Which seems to be the case, and is breaking uapi - further even if the ctm change itself would not result in flicker, this can hide modesets for other reasons. Which again breaks the uapi v2: I forgot the case of adding unrelated crtc state. Add that case and link to the existing kerneldoc explainers. This has come up in an irc discussion with Manasi and Ville about intel's bigjoiner mode. Also cc everyone involved in the msm irc discussion, more people joined after I sent out v1. Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Pekka Paalanen Cc: Rob Clark Cc: Simon Ser Cc: Manasi Navare Cc: Ville Syrjälä Cc: Abhinav Kumar Cc: Dmitry Baryshkov Signed-off-by: Daniel Vetter Acked-by: Pekka Paalanen --- include/drm/drm_atomic.h | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index cf8e1220a4ac..545c48545402 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -372,8 +372,27 @@ struct drm_atomic_state { * * Allow full modeset. This is used by the ATOMIC IOCTL handler to * implement the DRM_MODE_ATOMIC_ALLOW_MODESET flag. Drivers should - * never consult this flag, instead looking at the output of - * drm_atomic_crtc_needs_modeset(). + * not consult this flag, instead looking at the output of + * drm_atomic_crtc_needs_modeset(). The detailed rules are: + * + * - Drivers must not consult @allow_modeset in the atomic commit path, + * and instead use drm_atomic_crtc_needs_modeset(). + * + * - Drivers may consult @allow_modeset in the atomic check path, if + * they have the choice between an optimal hardware configuration + * which requires a modeset, and a less optimal configuration which + * can be committed without a modeset. An example would be suboptimal + * scanout FIFO allocation resulting in increased idle power + * consumption. This allows userspace to avoid flickering and delays + * for the normal composition loop at reasonable cost. + * + * - Drivers must consult @allow_modeset before adding unrelated struct + * drm_crtc_state to this commit by calling + * drm_atomic_get_crtc_state(). See also the warning in the + * documentation for that function. + * + * - Drivers must never change this flag, it is only under the control + * of userspace. */ bool allow_modeset : 1; /**