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 <[email protected]>
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/[email protected]/
