summaryrefslogtreecommitdiff
path: root/src/ec/51nb
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2021-05-05 17:41:10 -0700
committerJulius Werner <jwerner@chromium.org>2021-05-08 00:12:58 +0000
commite0dbeee40f9cfa0e43465db1a3f1c6c510b212ab (patch)
tree65385523acd52802575bfb8193b36fcf7b2e6d4e /src/ec/51nb
parent2f195fe167ba3083218d599a66e44d9bbc11c1ba (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/ec/51nb')
0 files changed, 0 insertions, 0 deletions