All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Timur Kristóf" <timur.kristof@gmail.com>
To: Mario Limonciello <mario.limonciello@amd.com>,
	amd-gfx@lists.freedesktop.org, "Wentland,
	Harry" <Harry.Wentland@amd.com>, Alex Hung <alex.hung@amd.com>
Subject: Re: [PATCH 0/5] Adjustments to common mode behavior
Date: Wed, 24 Sep 2025 20:11:17 +0200	[thread overview]
Message-ID: <9d0509ea-7341-4bc5-88a0-d36a4b4528cc@gmail.com> (raw)
In-Reply-To: <68bff33a-46ef-4518-8b1e-d9d1b3087f2a@amd.com>



On 9/24/25 19:48, Mario Limonciello wrote:

> 
>> 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.

@Harry and @Alex, what do you guys think about this?

>>>>
>>>> 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/
> 

I'm not sure if that deals with the same issue that I'm referring to.

Basically what I notice is that when plugging in a cable, it can happen 
that the HPD pins make contact before the DDC pins, and hence DC fails 
to read the EDID. This can happen often with DVI ports and rarely with 
HDMI (and never happened to me with DP).

The non-DC code has a solution for this to retry in a few seconds.
I wasn't able to find anything for this in DC.
I found some code to set up some HPD filters, but that code is not 
called from anywhere and I was told the HPD filter may not be the right 
solution.

So my question is, what would be the right solution? Can we use a HPD 
filter? Or better to do what the non-DC code does and just retry again 
later?

Thanks,
Timur

  reply	other threads:[~2025-09-24 18:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 16:16 [PATCH 0/5] Adjustments to common mode behavior Mario Limonciello
2025-09-24 16:16 ` [PATCH 1/5] drm/amd/display: Only enable common modes for eDP and LVDS Mario Limonciello
2025-09-24 17:58   ` Harry Wentland
2025-09-24 16:16 ` [PATCH 2/5] drm/amd: Drop unnecessary check in amdgpu_connector_add_common_modes() Mario Limonciello
2025-09-24 16:16 ` [PATCH 3/5] drm/amd: Use dynamic array size declaration for amdgpu_connector_add_common_modes() Mario Limonciello
2025-09-24 17:05   ` Alex Deucher
2025-09-24 16:16 ` [PATCH 4/5] drm/amd: Drop some common modes from amdgpu_connector_add_common_modes() Mario Limonciello
2025-09-24 16:16 ` [PATCH 5/5] drm/amd: Add name to " Mario Limonciello
2025-09-24 17:07   ` Alex Deucher
2025-09-24 17:13 ` [PATCH 0/5] Adjustments to common mode behavior Timur Kristóf
2025-09-24 17:21   ` Mario Limonciello
2025-09-24 17:33     ` Timur Kristóf
2025-09-24 17:48       ` Mario Limonciello
2025-09-24 18:11         ` Timur Kristóf [this message]
2025-09-24 18:31           ` Mario Limonciello
2025-09-24 21:04             ` Timur Kristóf
2025-09-24 18:24         ` Harry Wentland
2025-09-24 19:11           ` Alex Deucher
2025-09-24 20:00             ` Harry Wentland
2025-09-24 20:07               ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d0509ea-7341-4bc5-88a0-d36a4b4528cc@gmail.com \
    --to=timur.kristof@gmail.com \
    --cc=Harry.Wentland@amd.com \
    --cc=alex.hung@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=mario.limonciello@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.