diff options
author | Julius Werner <jwerner@chromium.org> | 2021-05-05 17:41:10 -0700 |
---|---|---|
committer | Julius Werner <jwerner@chromium.org> | 2021-05-08 00:12:58 +0000 |
commit | e0dbeee40f9cfa0e43465db1a3f1c6c510b212ab (patch) | |
tree | 65385523acd52802575bfb8193b36fcf7b2e6d4e /src/mainboard/ocp | |
parent | 2f195fe167ba3083218d599a66e44d9bbc11c1ba (diff) |
drivers/sn65dsi86: Switch EDID reading to use "indirect mode"
The SN65DSI86 eDP bridge supports two ways to read the EDID: for now
we've been using "direct mode", which works by basically making the
bridge I2C device listen to another chip address besides its own and
proxy all requests received there directly to the eDP AUX channel. The
great part about that mode is that it is super easy and hassle-free to
use. The not so great part about it is that it doesn't work: for EDID
extensions, the last byte (which happens to contain the checksum) is
somehow always read as zero. We presume this is a hardware bug in the
bridge part.
The other, much more annoying way is "indirect mode", where each byte
transmitted over the AUX channel has to be manually set up in the I2C
registers of the bridge, just like we're already doing with DPCD
transactions. Thankfully, we can reuse most of the DPCD code for this so
it's not a lot of extra code. It's a bit slower but not as much as you'd
expect (26ms instead of 18ms on my board), and the difference is not
very relevant compared to common total times for display init.
Also, some of the (previously unused) enum definitions for the AUX_CMD
mode field of the bridge had just been plain wrong for some reason, and
needed to be fixed to make this work.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I65f80193380d3c3841f9f5c26897ed672f45e15a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52959
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/mainboard/ocp')
0 files changed, 0 insertions, 0 deletions