Re: [PATCH v2 1/2] drm/i915/opregion: add support for mailbox #5 EDID

[Daniel Dadap <ddadap@nvidia.com>]

On 6/1/21 5:43 PM, Anisse Astier wrote:
>
> Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :
>> On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:
>>> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
>>> used for the embedded display. Add support for using it via by adding
>>> the EDID to the list of available modes on the connector, and use it for
>>> eDP when available.
>>>
>>> If a panel's EDID is broken, there may be an override EDID set in the
>>> ACPI OpRegion mailbox #5. Use it if available.
>> Looks like Windows uses the ACPI _DDC method instead. We should probably
>> do the same, just in case some crazy machine stores the EDID somewhere
>> else.
> Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a
> patch series to do just that, in a generic way:
> https://lore.kernel.org/amd-gfx/20200727205357.27839-1-ddadap@nvidia.com/
>
> I've tried patch 1 & 2, and after a fix[1] was able to call the _DDC method
> on most devices, but without any EDID being returned.
>
> I looked at the disassembled ACPI tables[2], and could not find any
> device with the _DDC method. Are you sure it's the only method the
> Windows driver uses to get the EDID ?


_DDC only works on devices that actually implement it, and the vast 
majority of devices don't, because the display just provides an EDID 
normally. AIUI, usually a device will implement _DDC either because an 
embedded panel has no ROM of its own to deliver an EDID, or to allow the 
EDID to be read by either GPU on a system with a muxed display, 
regardless of which GPU happens to have the DDC lines (in TMDS) or DP 
AUX routed to it at the moment. (To my knowledge, nobody actually muxes 
DP AUX independently from the main link, but there were some older 
pre-DP designs where DDC could be muxed independently.)

I'm not sure whether the comment about Windows using _DDC was meant for 
this device in particular, or just more generally, since DDC is part of 
the ACPI spec and some Windows GPU drivers *do* use it, where available. 
If it was meant for a particular device, then it's possible that the 
ACPI tables advertise different methods depending on e.g. _OSI. If you 
haven't already tried doing so, it might be worth overriding _OSI to 
spoof Windows, to see if _DDC gets advertised.

I'm not sure how you were able to call _DDC without an EDID being 
returned as described above, if there was no _DDC method in the ACPI 
tables; I would expect that attempting to call _DDC would fail to locate 
a suitable method and do_acpi_ddc would return NULL.


> Regards,
>
> Anisse
>
> [1] _DOD ids should only use 16 lower bits, see table here:
> https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/display-specific-methods.html#dod-enumerate-all-devices-attached-to-the-display-adapter


Thanks; I don't see a version of your modified patch here, was the fix 
just to mask the _DOD IDs against 0xffff?


> [2] acpidump: https://gitlab.freedesktop.org/drm/intel/-/issues/3454#note_913970
>