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

[Jani Nikula]

On Wed, 02 Sep 2020, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Tue, Sep 01, 2020 at 04:18:19PM +0300, Jani Nikula wrote:
>> On Mon, 31 Aug 2020, Jani Nikula <jani.nikula at intel.com> wrote:
>> > On Mon, 31 Aug 2020, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> >> On Fri, Aug 28, 2020 at 09:19:40AM +0300, Jani Nikula 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 the EDID
>> >>> override mechanism.
>> >>
>> >> Abusing the override for this feels a bit odd.
>> >
>> > It's the least intrusive way to make this work across the drm and driver
>> > EDID code that I could think of.
>> >
>> > BR,
>> > Jani.
>> >
>> >
>> >>
>> >> Also I have a vague recollection that there was perhaps some
>> >> linkage between the mailbox and the ACPI _DDC stuff:
>> >> git://github.com/vsyrjala/linux.git acpi_edid
>> 
>> Only looked at this now. The patch at hand is for actually overriding
>> the EDID from the panel, because the panel EDID is readable but bogus.
>
> Do we have an actual use case for this? The commit msg doesn't say so.

It's a bit hazy still, but potentially yes, with a need to backport to
stable as well.

>> I
>> have no idea how the ACPI _DDC stuff would work in this case. Would it
>> return the EDID from the panel or from mailbox #5 or something
>> completely different? Who knows.
>> 
>> Using drm_do_get_edid() would of course be doable for reading mailbox #5
>> directly as well, but you'd have to make that the "primary" method and
>> fall back to the usual drm_get_edid(). Note that this completely
>> prevents you from ever reading the actual panel EDID. Using
>> edid_override lets you get at the panel EDID too.
>
> Might be nice to make .get_edid() a connector vfunc and let each driver
> implement it however they want. That way the driver would be in total
> control over the priority of different EDID sources. But haven't really
> looked at what that would take. Not even sure if a vfunc is totally
> required as I think most EDID reads should be in some connector specific
> driver code.

-- 
Jani Nikula, Intel Open Source Graphics Center