From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AAB12D81B3; Mon, 5 May 2025 22:56:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746485784; cv=none; b=BZqIJ4v2WNolMGStB1IvHG5pw6AX1bRrotywZsUmthCnBi48iP0svGPiyQW1mEBbJ+KizvzOpQS5G0QQbwH6KjCLmQeNDDx0FdhsAwRVEb49GmDEkLAyIqVruemttQRt/g85ZX5ZsMbNJOyM9VJYtAiyAivh1nqLYqWtTxNMx1s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746485784; c=relaxed/simple; bh=736lJHlmV7wwiZPIZbmHltRNq13JFqo+n1yYiOkxlKo=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=E1A+L0ubHh3vf8/ehpjQ6W6BiOa6CS6omIcjxObE7RoZpY9Iu5LgjYnEIGAAWIDf+fOCL/ZaXZSSRA5PmMX19Fq2zui3ayvkF+X65U3FMc2HwZihbFIzxX9UQXmo1o8xmzX59joCt3EGJ4C3UCV1wbhoaIdW1KwGwbU5rGszg9w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OgYaNuGE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OgYaNuGE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31095C4CEF2; Mon, 5 May 2025 22:56:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746485783; bh=736lJHlmV7wwiZPIZbmHltRNq13JFqo+n1yYiOkxlKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OgYaNuGE4oV8yrsJAyEj+6m5m/Si8Hcm6eEcoJ/vInTQbL3QEZG6PpxyZzJccX4+D Ud2Ag7kKgh/wNX1reg4EGJcoT5rLE9VglCALvlpF2m32v9xkMTysUu39RSH1BzeQGY 480/FFNPiHqUm0yDdSWzP7vivcgs6AA33UqrL6J35eWAGmwF5FBqLWNeV4kPk9GLTD RBrNcurVuMSrBoxz/OXpkYW7SDc8qIdLkxqPSe7qWFhuZzGQcF0ZaQzrGKRlNxvLU8 DoJrckVSIq7V7dlEdJf1nMWvxv1vfutCmaWTkO7eVqr1d94bUZM6Ye3U/2G7wPTFd3 OUo3e7mnm3cJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Simona Vetter , Pekka Paalanen , Dmitry Baryshkov , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Rob Clark , Simon Ser , Manasi Navare , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Abhinav Kumar , Simona Vetter , Sasha Levin , simona@ffwll.ch, dri-devel@lists.freedesktop.org Subject: [PATCH AUTOSEL 6.12 482/486] drm/atomic: clarify the rules around drm_atomic_state->allow_modeset Date: Mon, 5 May 2025 18:39:18 -0400 Message-Id: <20250505223922.2682012-482-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250505223922.2682012-1-sashal@kernel.org> References: <20250505223922.2682012-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.26 Content-Transfer-Encoding: 8bit From: Simona Vetter [ Upstream commit c5e3306a424b52e38ad2c28c7f3399fcd03e383d ] 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. v3: Wording polish from Pekka and Thomas Acked-by: Pekka Paalanen Acked-by: Dmitry Baryshkov 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: Simona Vetter Signed-off-by: Simona Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20250108172417.160831-1-simona.vetter@ffwll.ch Signed-off-by: Sasha Levin --- 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 31ca88deb10d2..1ded9a8d4e84d 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -376,8 +376,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(). + * generally not consult this flag, but instead look at the output of + * drm_atomic_crtc_needs_modeset(). The detailed rules are: + * + * - Drivers must not consult @allow_modeset in the atomic commit path. + * Use drm_atomic_crtc_needs_modeset() instead. + * + * - 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 under the exclusive + * control of userspace. + * + * - 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. */ bool allow_modeset : 1; /** -- 2.39.5