On Sat, 02 Sep 2023, Peter Senna Tschudin <peter.senna@xxxxxxxxx> wrote:
> Good morning Jani,
>
> It has been a long time since I wrote the driver, and many many years
> since I sent my last kernel patch, so my memory does not serve me very
> well, but I will try to shed some light.
>
> On Fri, Sep 1, 2023 at 12:24 PM Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
>>
>> The driver was originally added in commit fcfa0ddc18ed ("drm/bridge:
>> Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)"). I tried to
>> look up the discussion, but didn't find anyone questioning the EDID
>> reading part.
>>
>> Why does it not use drm_get_edid() or drm_do_get_edid()?
>>
>> I don't know where client->addr comes from, so I guess it could be
>> different from DDC_ADDR, rendering drm_get_edid() unusable.
>>
>> There's also the comment:
>>
>> /* Yes, read the entire buffer, and do not skip the first
>> * EDID_LENGTH bytes.
>> */
>>
>> But again, there's not a word on *why*.
>
> The video pipeline has two hardware bridges between the LVDS from the
> SoC and DP+ output. For reasons, we would get hot plug events from one
> of these bridges, and EDID from the other. If I am not mistaken, I
> documented this strangeness in the DTS readme file.
>
> Did this shed any light on the *why* or did I tell you something you
> already knew?
I guess that answers the question why it's necessary to specify the ddc
to use, but not why drm_do_get_edid() could not be used. Is it really
necessary to read the EDID in one go?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
