On Mon, Sep 04, 2023 at 01:04:40PM +0300, Jani Nikula wrote: > On Sat, 02 Sep 2023, Peter Senna Tschudin 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 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. This should be supported properly by the drm_bridge_connector helper, which supports delegating HPD and EDID retrieval to different bridges. > > 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? -- Regards, Laurent Pinchart