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 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 7DEB9107637D for ; Wed, 1 Apr 2026 14:24:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2B47B10E010; Wed, 1 Apr 2026 14:24:33 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="W5laloGD"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1163F10E010; Wed, 1 Apr 2026 14:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1775053472; x=1806589472; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=TG6R0Okg2YkUbsh3YiyV1gqvpsR7pJR89KtMevMDW7M=; b=W5laloGDFMu/Yd3M1RPWUXXN+ornLpgC4VHcirElqGMUdKf8zVgmws+R fERAG/UJ66qr0rEDwOzSNWrEwjKuFpEAgYQfLPcVF3t+0h9tSxtso9HB4 fELW8EO1WnZ/IaGTDEDZt1dGBWvmIS1O2AsMdd9bhZJWKQZ7Medp1I2HG pj6CmN0WYubEzIQ573g2yIBrv9Dcv2wIBX62zXiHfHGBt7dpRS1sCVgBr b6E3DiBd0TAR5oPopCd12jDG7y3yJ9OaAvftyG2/DU2K05WFFSzUUY6Ou mDMNCsOzFIwdHtwhYVY++sJYjM36zTifJqSE0FrAjR+ABa9E1z7XezSZO g==; X-CSE-ConnectionGUID: /s+NiyxvROiwP57RWf88pg== X-CSE-MsgGUID: LnvJdnV+QpKx8+xr44UoSA== X-IronPort-AV: E=McAfee;i="6800,10657,11745"; a="75268434" X-IronPort-AV: E=Sophos;i="6.23,153,1770624000"; d="scan'208";a="75268434" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 07:24:31 -0700 X-CSE-ConnectionGUID: SNf9buULQP6IxoXbmF++jA== X-CSE-MsgGUID: 6EF7fvO5SfaSwp53TBggkg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,153,1770624000"; d="scan'208";a="226673118" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO localhost) ([10.245.244.199]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2026 07:24:29 -0700 Date: Wed, 1 Apr 2026 17:24:26 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Borah, Chaitanya Kumar" Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, uma.shankar@intel.com, pranay.samala@intel.com Subject: Re: [PATCH 1/3] drm/i915/display: Copy color pipeline from plane in the primary joiner pipe Message-ID: References: <20260401083841.4081587-1-chaitanya.kumar.borah@intel.com> <33f81157-5a18-4faf-8457-edae0275d86a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <33f81157-5a18-4faf-8457-edae0275d86a@intel.com> X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed, Apr 01, 2026 at 07:40:44PM +0530, Borah, Chaitanya Kumar wrote: > > > On 4/1/2026 5:10 PM, Ville Syrjälä wrote: > > On Wed, Apr 01, 2026 at 02:08:39PM +0530, Chaitanya Kumar Borah wrote: > >> When copying plane color state in a joiner configuration, use the plane in > >> the primary joiner pipe since it carries the pipeline number selected by > >> the user-space. > >> > >> This assumes that all pipes in the joiner are symmetric in their plane > >> color capabilities. > >> > >> Cc: stable@vger.kernel.org # v6.19+ > >> Fixes: a78f1b6baf4d ("drm/i915/color: Add framework to program CSC") > >> Signed-off-by: Chaitanya Kumar Borah > >> --- > >> drivers/gpu/drm/i915/display/intel_plane.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_plane.c b/drivers/gpu/drm/i915/display/intel_plane.c > >> index 5390ceb21ca4..82f445c83158 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_plane.c > >> +++ b/drivers/gpu/drm/i915/display/intel_plane.c > >> @@ -373,7 +373,7 @@ intel_plane_color_copy_uapi_to_hw_state(struct intel_plane_state *plane_state, > >> bool changed = false; > >> int i = 0; > >> > >> - iter_colorop = plane_state->uapi.color_pipeline; > >> + iter_colorop = from_plane_state->uapi.color_pipeline; > >> > >> while (iter_colorop) { > >> for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) { > > > > Hmm. This whole colorop thing seems a bit weird. So each plane/crtc/etc > > doesn't actually have its full state in its state, but rather it points > > to some other colorop state somewhere? > > > > Yes, colorops are unique in the DRM model. While they are DRM objects > with their own states, they contain information about a plane/crtc's > state. The plane/crtc property "COLOR PIPELINE" determines which chain > of colorops is currently active. > > > > The mess here with the 'intel_atomic_state' here needs to get cleaned up. > > At the very least we need to pass the full atomic state from the caller > > instead of digging it out via the plane_state->uapi.state footgun. > > To make the dependency on the intel_atomic_state explicit? > I will make the change. Seems we do need to pass NULL occasionally: - intel_legacy_cursor_update() should be fine since the colorop uapi state doesn't change there so nothing to update - intel_find_initial_plane_obj() really shouldn't use that function at all. It really should do the readout into the hw state and the do the opposite (hw->uapi) copy. But changing that would require real thought, so I guess passing NULL there is fine for now as well > > > That thing should never be used, and ideally we'd just nuke it entirely. > > > > You mean the back pointer to the atomic state in the plane state? Yeah. That pointer is only valid under specific circumstances. If you don't use it, then you don't have to wonder about its validity. -- Ville Syrjälä Intel