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 28516D59D84 for ; Fri, 12 Dec 2025 18:45:45 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D18DB10E14D; Fri, 12 Dec 2025 18:45:44 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="WovFfU3q"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5172C10E090; Fri, 12 Dec 2025 18:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765565143; x=1797101143; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=UhXq1Up/zfsYcUHE1TSOJz5tAaESIqsgggpPg2jMlms=; b=WovFfU3qBM4lBbbKPQLYhn5uEVUDpyB/abbKmMirbroBH6sVNqdKCzx8 YEnxUmrEYLc8E5y39TdCnniM6X8Y+vmQF1p1ndvZUgjKo4G9hwS5z512y gjqCpnrbtZSq+xNT9l9qQJX3l/wAuVW1JbXOW8B5fvCiU7QfB+7TVdAKS LcVTzalBOs3tWAZONdwq8Gll3sT6qAXpMipK5NS+s1YBnOlTBGfmS43c2 qGedDhsRU9LSUkSfdtgz8DNOSH+29cNlV8Z26+PeMDrQ+sQdmlgishdfr tZ6+lQPr8c8d4Cq46VfTefLQ5gm80bbfl8kk7J3tl1oddnZ5UiA+oJjIU Q==; X-CSE-ConnectionGUID: Gg2iyyetTXG9ImgBuKFcuA== X-CSE-MsgGUID: J1dwF52STDCV4tmxjNbVxg== X-IronPort-AV: E=McAfee;i="6800,10657,11640"; a="67610622" X-IronPort-AV: E=Sophos;i="6.21,144,1763452800"; d="scan'208";a="67610622" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2025 10:45:43 -0800 X-CSE-ConnectionGUID: JJedukN3QmG0yyjz0Z4Fag== X-CSE-MsgGUID: LDDQFR6qRyS+8+P3MdsnUw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,144,1763452800"; d="scan'208";a="201573591" Received: from egrumbac-mobl6.ger.corp.intel.com (HELO localhost) ([10.245.245.152]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2025 10:45:39 -0800 Date: Fri, 12 Dec 2025 20:45:36 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Borah, Chaitanya Kumar" Cc: Uma Shankar , intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, pekka.paalanen@collabora.com, contact@emersion.fr, harry.wentland@amd.com, mwen@igalia.com, jadahl@redhat.com, sebastian.wick@redhat.com, swati2.sharma@intel.com, alex.hung@amd.com, jani.nikula@intel.com, suraj.kandpal@intel.com Subject: Re: [v8 14/15] drm/i915/color: Add 3D LUT to color pipeline Message-ID: References: <20251203085211.3663374-1-uma.shankar@intel.com> <20251203085211.3663374-15-uma.shankar@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo 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 Fri, Dec 12, 2025 at 11:16:56PM +0530, Borah, Chaitanya Kumar wrote: > > > On 12/12/2025 8:38 PM, Ville Syrjälä wrote: > > On Wed, Dec 03, 2025 at 02:22:10PM +0530, Uma Shankar wrote: > >> From: Chaitanya Kumar Borah > >> > >> Add helpers to program the 3D LUT registers and arm them. > >> > >> LUT_3D_READY in LUT_3D_CLT is cleared off by the HW once > >> the LUT buffer is loaded into it's internal working RAM. > >> So by the time we try to load/commit new values, we expect > >> it to be cleared off. If not, log an error and return > >> without writing new values. Do it only when writing with MMIO. > >> There is no way to read register within DSB execution. > >> > >> v2: > >> - Add information regarding LUT_3D_READY to commit message (Jani) > >> - Log error instead of a drm_warn and return without committing changes > >> if 3DLUT HW is not ready to accept new values. > >> - Refactor intel_color_crtc_has_3dlut() > >> Also remove Gen10 check (Suraj) > >> v3: > >> - Addressed review comments (Suraj) > >> > >> Reviewed-by: Suraj Kandpal > >> Signed-off-by: Chaitanya Kumar Borah > >> Signed-off-by: Uma Shankar > >> --- > >> drivers/gpu/drm/i915/display/intel_color.c | 78 +++++++++++++++++++ > >> drivers/gpu/drm/i915/display/intel_color.h | 4 + > >> .../drm/i915/display/intel_color_pipeline.c | 29 +++++-- > >> .../drm/i915/display/intel_color_pipeline.h | 3 +- > >> .../drm/i915/display/intel_display_limits.h | 1 + > >> .../drm/i915/display/intel_display_types.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_plane.c | 2 + > >> 7 files changed, 112 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c > >> index 08f3b5b47b8e..e7950655434b 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_color.c > >> +++ b/drivers/gpu/drm/i915/display/intel_color.c > >> @@ -4062,6 +4062,52 @@ xelpd_plane_load_luts(struct intel_dsb *dsb, const struct intel_plane_state *pla > >> xelpd_program_plane_post_csc_lut(dsb, plane_state); > >> } > >> > >> +static u32 glk_3dlut_10(const struct drm_color_lut32 *color) > >> +{ > >> + return REG_FIELD_PREP(LUT_3D_DATA_RED_MASK, drm_color_lut32_extract(color->red, 10)) | > >> + REG_FIELD_PREP(LUT_3D_DATA_GREEN_MASK, drm_color_lut32_extract(color->green, 10)) | > >> + REG_FIELD_PREP(LUT_3D_DATA_BLUE_MASK, drm_color_lut32_extract(color->blue, 10)); > >> +} > >> + > >> +static void glk_load_lut_3d(struct intel_dsb *dsb, > >> + struct intel_crtc *crtc, > >> + const struct drm_property_blob *blob) > >> +{ > >> + struct intel_display *display = to_intel_display(crtc->base.dev); > >> + const struct drm_color_lut32 *lut = blob->data; > >> + int i, lut_size = drm_color_lut32_size(blob); > >> + enum pipe pipe = crtc->pipe; > >> + > >> + if (!dsb && intel_de_read(display, LUT_3D_CTL(pipe)) & LUT_3D_READY) { > >> + drm_err(display->drm, "[CRTC:%d:%s] 3D LUT not ready, not loading LUTs\n", > >> + crtc->base.base.id, crtc->base.name); > >> + return; > > > > Just ran into this while perusing the code... > > > > This check could be implemented exactly like intel_vrr_check_push_sent() > > so that it works for both the DSB and non-DSB paths. > > We did discuss this briefly[1], but went on with this as a first step. > > My main concern was if it is a good idea to poll for a bit in the middle > of a commit. I understand that this is done for TRANS_PUSH_SEND but that > is the last thing we do for a commit. It's a single register read so not a big deal perhaps. But if that's a concern then the entire check could be moved to the start of the commit. Hmm, or perhaps we should move this check to the end of the commit as well... Not sure. > > >The 'return' should > > just get nuked IMO. > > > > So just move ahead and program irrespective? Having dead codepaths is not a great idea since they're never tested. Also we should try to keep the DSB and MMIO codepaths as similar as possible to avoid weird heisenbugs. > > >> +void intel_color_plane_commit_arm(struct intel_dsb *dsb, > >> + const struct intel_plane_state *plane_state) > >> +{ > >> + struct intel_display *display = to_intel_display(plane_state); > >> + struct intel_crtc *crtc = to_intel_crtc(plane_state->uapi.crtc); > >> + > >> + if (crtc && intel_color_crtc_has_3dlut(display, crtc->pipe)) > >> + glk_lut_3d_commit(dsb, crtc, !!plane_state->hw.lut_3d); > > ^^^^^^^^^^^^ > > > > And this looks like a pretty major fail. Why is the 3D LUT stored in > > the *plane* state when it's a pipe level thing? > > > > With DISPLAY_VER(display) >= 35, 3DLUT can be attached to a plane. > (Bits[23:22] in 3DLUT_CTL). This is the only way we are exposing the HW > to the userspace right now (through the new plane color pipeline uapi). > Therefore, it lies in the plane state. And something makes sure it's only used by one plane at a time? > However, there are (soonish)plans to adopt the color pipeline for crtcs > too. Once that happens, it needs to be handled a bit more carefully. A > potential approach is to allow userspace to program the block with a > first come first served semantics and fail the commit if it tries to set > 3DLUT both on plane and crtc in the same commit. > > [1] > https://lore.kernel.org/intel-gfx/b01cade8-ba63-472a-a95f-bba9af57afbb@intel.com/ > > == > Chaitanya -- Ville Syrjälä Intel