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

[Anisse Astier]

Le Wed, Jul 07, 2021 at 02:57:47PM -0500, Daniel Dadap a écrit :
> 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 think it's already the default Linux behaviour according to
https://www.kernel.org/doc/html/latest/firmware-guide/acpi/osi.html

I added a few specific Windows versions (2007 - 2020), but did not see
any difference.


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

I wasn't, I just tried calling the method on all devices (removing the
_DOD id check), but obviously it failed because it did not exist.

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

Yes, nothing fancy:

-                       if (adr == dod_entries[i]) {
+                       if (adr == (dod_entries[i] & 0xFFFF) ) {


Regards,

Anisse