From: Mario Limonciello Mario.Limonciello@amd.com
[ Upstream commit 5e76bc677cb7c92b37d8bc66bb67a18922895be2 ]
[Why] fill_stream_properties_from_drm_display_mode() will not configure pixel encoding to YCBCR422 when the DRM color format supports YCBCR422 but not YCBCR420 or YCBCR4444. Instead it will fallback to RGB.
[How] Add support for YCBCR422 in pixel encoding mapping.
Suggested-by: Mauri Carvalho mcarvalho3@lenovo.com Reviewed-by: Wayne Lin wayne.lin@amd.com Signed-off-by: Mario Limonciello Mario.Limonciello@amd.com Signed-off-by: Ray Wu ray.wu@amd.com Tested-by: Daniel Wheeler daniel.wheeler@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## **Backport Recommendation: CONDITIONAL YES**
**This commit should be backported ONLY as part of a series with commit db291ed1732e0 "drm/amd/display: Add fallback path for YCBCR422". Backporting this commit alone is NOT recommended.**
---
## Detailed Analysis
### What the Commit Does
Commit `5e76bc677cb7c` adds YCBCR422 pixel encoding support to the `fill_stream_properties_from_drm_display_mode()` function in `/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c` (lines 6408-6410 in the diff):
```c else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422) && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422; ```
**The Bug Being Fixed**: Before this commit, when a display supported YCBCR422 color format but NOT YCBCR420 or YCBCR444, the driver would incorrectly fall back to RGB encoding instead of using the supported YCBCR422 encoding. This is a logic gap in the if-else chain that selects pixel encoding.
### Critical Discovery: Immediate Follow-up Commit
Through extensive git history analysis, I discovered that commit `db291ed1732e0` "drm/amd/display: Add fallback path for YCBCR422" was committed **the very next day** (Aug 27, 2025) and **directly modifies the code added by this commit**:
**Original implementation (5e76bc677cb7c)**: ```c else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422) && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) // Check for HDMI timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422; ```
**Modified by follow-up (db291ed1732e0)**: ```c else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422) && aconnector && aconnector->force_yuv422_output) // Changed to opt- in flag timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422; ```
### Why This Matters
The follow-up commit `db291ed1732e0`:
1. **Changes the behavior** from automatic YCBCR422 selection (when HDMI display supports it) to opt-in via `force_yuv422_output` flag 2. **Adds a progressive fallback mechanism** for DisplayPort bandwidth validation failures: - First tries YUV422 8bpc (bandwidth efficient) - Then YUV422 6bpc (reduced color depth) - Finally YUV420 (last resort) 3. **Fixes a serious issue**: "This resolves cases where displays would show no image due to insufficient DP link bandwidth for the requested RGB mode" 4. **Adds the `force_yuv422_output` field** to `struct amdgpu_dm_connector` in `amdgpu_dm.h`
### Evidence of Close Relationship
- **Same author**: Mario Limonciello (both commits) - **Same suggested-by**: Mauri Carvalho (both commits) - **Same reviewer**: Wayne Lin (both commits) - **Same tester**: Daniel Wheeler (both commits) - **Consecutive commits**: Aug 26 and Aug 27, 2025 - **No intervening commits**: These are back-to-back commits in the AMD display driver
### Technical Analysis Using Semcode
Using the `mcp__semcode__find_function` tool, I confirmed that: - YCBCR422 encoding (`PIXEL_ENCODING_YCBCR422`) is already well- established in the AMD display driver - It's used in 13+ different locations across the driver subsystem for clock calculations, stream encoding, and bandwidth management - The missing check in `fill_stream_properties_from_drm_display_mode()` was indeed a gap that needed to be filled
### Backporting Criteria Assessment
**For commit 5e76bc677cb7c ALONE:**
✅ **Fixes a bug**: Yes - incorrect pixel encoding selection ✅ **Small and contained**: Yes - only 3 lines added ❌ **Minimal risk**: Questionable - behavior was modified the next day ✅ **No architectural changes**: Yes ✅ **Confined to subsystem**: Yes - AMD display driver only ❌ **Stable tag present**: No `Cc: stable@vger.kernel.org` tag ⚠️ **Complete fix**: No - requires follow-up commit for full functionality
**For BOTH commits as a series:**
✅ All criteria above ✅ **Complete feature**: Yes - implements both HDMI YCBCR422 support and DP fallback ✅ **Tested together**: Yes - same test cycle, same tester ✅ **No known regressions**: No fixes or reverts found in subsequent history
### Risk Analysis
**Risk of backporting 5e76bc677cb7c alone**: MODERATE-HIGH - Would enable automatic YCBCR422 for HDMI displays, which the follow-up commit changed to opt-in - Would not include the DP bandwidth fallback mechanism that fixes "no image" issues - Could introduce unexpected behavior changes that were corrected in db291ed1732e0 - Missing the `force_yuv422_output` field addition would cause compilation issues if the field is referenced elsewhere
**Risk of backporting both commits together**: LOW - Represents the complete, tested implementation - Small, focused changes to AMD display driver - No subsequent fixes or reverts found - Addresses both HDMI pixel encoding and DP bandwidth issues
### Recommendation
**YES - Backport to stable trees, BUT ONLY as a two-commit series:**
1. **5e76bc677cb7c** "drm/amd/display: Set up pixel encoding for YCBCR422" 2. **db291ed1732e0** "drm/amd/display: Add fallback path for YCBCR422"
**These commits should be treated as a single logical changeset** because: - They implement a complete feature (YCBCR422 support + DP fallback) - The second commit fundamentally modifies the first commit's behavior - They were developed, reviewed, and tested together - They fix related display issues (pixel encoding correctness and bandwidth management)
**DO NOT backport commit 5e76bc677cb7c alone** as it represents an incomplete implementation that was refined the next day.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 8eb2fc4133487..3762b3c0ef983 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6399,6 +6399,9 @@ static void fill_stream_properties_from_drm_display_mode( && aconnector && aconnector->force_yuv420_output) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; + else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422) + && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) + timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422; else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR444) && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;