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 6BE8025C832; Sun, 1 Jun 2025 23:36:25 +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=1748820985; cv=none; b=aVj4LNbtBsfMLJkw/kbAhIkBX3iQUL4GxJiPZ1imAV77vV+1MVFRs4SONqi23K8G3Jmi+YKp0NkMvfvf5SKofGF9YzVj/lsl5xr+x5KnZ/pTRG6MFabKWBhHLcPsqmUe1G7S2cTTKfKx6rYY0WWRzw160NspFzlHwZkC2vOuF5U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748820985; c=relaxed/simple; bh=HCd9AZ29JT+h7jrUhdR/kY47Vj38Non7ZPlG6fT3144=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=ElM+tiMk79LUdKD69nzyh8SPtIYTdOa4aNFZEqCNb+biJJ8y+ebqU/8IgcTUYnmN+xzaPPnUfL6EdeWI+gLlSB/KjrtAhWTdhrhCmoPRyNYJooi7RiewZIp5wUxMIcTxv8MUo2al/JmurP6OSxtqy51OwLefxIc8ngBzY6ZVwDM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cD0BWBFU; 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="cD0BWBFU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C474AC4CEE7; Sun, 1 Jun 2025 23:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748820984; bh=HCd9AZ29JT+h7jrUhdR/kY47Vj38Non7ZPlG6fT3144=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cD0BWBFUDEx4jwlLR2pIt8JhDk3VdbyQ6/4z66Wqb69zGM5PWuuBwax/tT2PXuh1G ocr8BKgMSAUbOife2vM8eku87GqjsYUa1RSzeKHQ5L6BE/vxhPjo1H9g4cgN6EVx4u X+Qe7Yeo2E1idS+GmPGewz0QgZ9DvyYk3TWO8AA0YWdyS7EVMpFZt6R+4OvpDQQNa7 1StzZU5/emWHKb0bj0rxLq9fQS14zAQcKt/0hcfHauHBmt3/lfr97vFAJnSLeH/lFN S2dFY0N5SxcwEuLztf+3qoKxTtJLMyRygG/uCnSC1Gj8bjYuXrSh09nGcmv8C8PIRX LrM4OGxj4HSDQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Samson Tam , Alvin Lee , Ray Wu , Daniel Wheeler , Alex Deucher , Sasha Levin , harry.wentland@amd.com, sunpeng.li@amd.com, christian.koenig@amd.com, airlied@gmail.com, simona@ffwll.ch, jun.lei@amd.com, alex.hung@amd.com, navid.assadian@amd.com, wenjing.liu@amd.com, Relja.Vojvodic@amd.com, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.12 53/93] drm/amd/display: disable EASF narrow filter sharpening Date: Sun, 1 Jun 2025 19:33:20 -0400 Message-Id: <20250601233402.3512823-53-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250601233402.3512823-1-sashal@kernel.org> References: <20250601233402.3512823-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Samson Tam [ Upstream commit c8d7e0be8183f4375a5cf5c3efd0c678129ea4de ] [Why & How] Default should be 1 to disable EASF narrow filter sharpening. Reviewed-by: Alvin Lee Signed-off-by: Samson Tam Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- Now I have a complete picture. Based on my analysis, I can provide the final backporting recommendation: ## **BACKPORTING ANALYSIS: drm/amd/display: disable EASF narrow filter sharpening** ### **RECOMMENDATION: YES** ### **Analysis Summary:** **Commit Details:** - **Commit ID:** c8d7e0be8183f4375a5cf5c3efd0c678129ea4de - **Author:** Samson Tam - **Date:** Thu May 1 15:59:47 2025 -0400 - **Subject:** drm/amd/display: disable EASF narrow filter sharpening - **Files Changed:** `drivers/gpu/drm/amd/display/dc/sspl/dc_spl.c` (2 lines) **Technical Changes:** The commit makes a simple but important change: - **Line 1302:** `easf_v_sharp_factor = 0` → `easf_v_sharp_factor = 1` - **Line 1466:** `easf_h_sharp_factor = 0` → `easf_h_sharp_factor = 1` **Why This Is A Bug Fix:** 1. **Intent vs Implementation Mismatch:** The commit message clearly states "Default should be 1 to disable EASF narrow filter sharpening" 2. **Hardware Behavior:** These sharp_factor variables control AMD display hardware's 2-tap sharp filtering: - Value 0001-Fix-Clippy-warnings.patch 0002-Enhance-inference-prompt-to-utilize- CVEKERNELDIR-whe.patch 0003-Update-to-latest-version-of-clap.patch drm_amd_display_vertical_interrupt_dcn32_dcn401_backport_analysis.md = sharpening **enabled** - Value 0001-Fix-Clippy-warnings.patch drm_amd_display_vertical_interrupt_dcn32_dcn401_backport_analysis.md gfx_v12_userq_eop_interrupt_handling_backport_analysis.md verisilicon_av1_4k_analysis.md = sharpening **disabled** 3. **Consistency Fix:** Prior to this fix, the code was unintentionally enabling sharpening when it should have been disabled by default **Stability and Risk Assessment:** - **LOW RISK:** Disables a feature rather than enabling new functionality - **IMPROVES STABILITY:** Prevents potential display artifacts from unwanted sharpening - **MINIMAL SCOPE:** Only affects EASF (Edge Adaptive Scaler Filter) narrow filter functionality - **WELL-TESTED:** Has proper review chain (Reviewed-by: Alvin Lee, Tested-by: Daniel Wheeler) **Backporting Criteria Analysis:** ✅ **Fixes Important Bug:** Corrects unintended feature activation that could cause display issues ✅ **Minimal Risk:** Simple value change, disables rather than enables functionality ✅ **No New Features:** Pure bug fix, no new architectural changes ✅ **Well- Contained:** Limited to AMD display driver's scaling/filtering subsystem ✅ **Stable Tree Appropriate:** Improves hardware behavior consistency **Comparison to Historical Similar Commits:** Looking at the provided historical commits that were marked "NO" for backporting: - Those were typically **feature additions** or **complex policy changes** - This commit is fundamentally different: it's a **simple bug fix** that corrects default behavior - Unlike feature commits, this **improves stability** by disabling problematic functionality **Conclusion:** This commit should be backported to stable kernels. It fixes a bug where EASF narrow filter sharpening was unintentionally enabled by default when AMD's design intent was to have it disabled. The fix is low-risk, well- tested, and improves display subsystem stability by preventing potential artifacts from unwanted sharpening algorithms. **Final Answer: YES** - This commit meets all criteria for stable kernel backporting. drivers/gpu/drm/amd/display/dc/spl/dc_spl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/spl/dc_spl.c b/drivers/gpu/drm/amd/display/dc/spl/dc_spl.c index 54c7d6aecf51c..23cc3d5e4b34e 100644 --- a/drivers/gpu/drm/amd/display/dc/spl/dc_spl.c +++ b/drivers/gpu/drm/amd/display/dc/spl/dc_spl.c @@ -1220,7 +1220,7 @@ static void spl_set_easf_data(struct spl_scratch *spl_scratch, struct spl_out *s if (enable_easf_v) { dscl_prog_data->easf_v_en = true; dscl_prog_data->easf_v_ring = 0; - dscl_prog_data->easf_v_sharp_factor = 0; + dscl_prog_data->easf_v_sharp_factor = 1; dscl_prog_data->easf_v_bf1_en = 1; // 1-bit, BF1 calculation enable, 0=disable, 1=enable dscl_prog_data->easf_v_bf2_mode = 0xF; // 4-bit, BF2 calculation mode /* 2-bit, BF3 chroma mode correction calculation mode */ @@ -1384,7 +1384,7 @@ static void spl_set_easf_data(struct spl_scratch *spl_scratch, struct spl_out *s if (enable_easf_h) { dscl_prog_data->easf_h_en = true; dscl_prog_data->easf_h_ring = 0; - dscl_prog_data->easf_h_sharp_factor = 0; + dscl_prog_data->easf_h_sharp_factor = 1; dscl_prog_data->easf_h_bf1_en = 1; // 1-bit, BF1 calculation enable, 0=disable, 1=enable dscl_prog_data->easf_h_bf2_mode = -- 2.39.5