Re: [PATCH 0/5] Adjustments to common mode behavior

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/24/25 12:33 PM, Timur Kristóf wrote:
> 
> 
> On 9/24/25 19:21, Mario Limonciello wrote:
>>
>> On 9/24/25 12:13 PM, Timur Kristóf wrote:
>>>
>>>
>>> On 9/24/25 18:16, Mario Limonciello wrote:
>>>> As part of enablement for SI and CIK in DC Timur pointed out some
>>>> differences in behavior for common mode handling for DC vs non DC
>>>> code paths. This series lines up the behavior between the two
>>>> implementations.
>>>>
>>> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
>>>
>>> Thank you Mario, this series makes good sense to me.
>>> My only worry is this: is it possible that removing the common modes 
>>> from connectors like DP, HDMI, etc. will regress somebody's setup?
>>
>> Possibly.  We're not going to know until we try.  I generally prefer 
>> not to add common modes (hence why I tried to drop them before until 
>> we hit the Xorg bug report).
>>
>> If someone complains about this then I see two other directions we can 
>> go.
> 
> Sounds good.
> 
> Considering the non-DC code already didn't add those common modes, I 
> think it's reasonable to assume that we would have already heard about 
> it if somebody had issues with it.
> 
>>
>> 1) to make both DC and non-DC paths apply common modes to eDP,LVDS, 
>> DP, HDMI.  Make them not apply common modes to VGA and DVI
>>
>> 2) Enabling common modes /across the board/ but anything not in the 
>> EDID gets the GPU scalar turned on.
> 
> I guess we'll see if any of those are necessary. For now, I'd propose to 
> just consider adding the common modes if there are 0 modes probed. But 
> I'm also OK with leaving that for later if you feel it isn't necessary.
> 

Yeah if something comes up and we need to weight it out we have this 
thread to refer back to for our ideas on what to do.

> A slightly related question, would you be OK with changing the link 
> detection code to return dc_connection_none when DDC cannot read an EDID 
> header on digital signals, similar to how the non-DC code does it?
> 

I personally think lining up all these nuances that are different 
between the two is a good idea.e e

But for that specific question that's probably more of a Harry/Alex Hung 
question.

>>>
>>> Two possible cases come to mind:
>>> 1. When we are unable to read the EDID for some reason
>>> 2. When the EDID is buggy and/or doesn't contain any modes
>>> Are these issues real or am I overthinking it?
>>>
>>> Thanks & best regards,
>>> Timur
>>
>> Failing to read EDID has happened in the past, but I think with the 
>> deferred aux message handling that should be cleared up now.
> 
> I was actually curious about that. I saw that issue while I was working 
> on something else. How is it deferred now? Can you point me to the 
> series that fixed it?
> 

There's more patches than this one, but I believe this was the 💰 patch.

https://lore.kernel.org/amd-gfx/20250428135514.20775-27-ray.wu@amd.com/