Bug 80684 - I2C-over-AUX drops single bytes
Summary: I2C-over-AUX drops single bytes
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-29 18:09 UTC by Stefan Brüns
Modified: 2019-11-20 08:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
possible fix (866 bytes, patch)
2014-07-01 16:00 UTC, Alex Deucher
no flags Details | Splinter Review
different approach (522 bytes, patch)
2014-07-02 23:19 UTC, Stefan Brüns
no flags Details | Splinter Review
return -EIO for flags not zero (1.07 KB, patch)
2014-07-03 15:23 UTC, Alex Deucher
no flags Details | Splinter Review

Description Stefan Brüns 2014-06-29 18:09:20 UTC
I get frequent errors for the EDID checksum, obviously single bytes are dropped from the EDID.

Good EDID:
Raw EDID:
      02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12
      15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80
      18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01
      1d 80 18 71 1c 16 20 58 2c 25 00 55 50 21 00 00 <-- 
      9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21
      00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55
      50 21 00 00 18 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d

Bad EDID example:
Raw EDID:
      02 03 1d f1 50 90 05 04 03 02 07 16 01 06 11 12
      15 13 14 1f 20 23 09 7f 07 83 01 00 00 02 3a 80
      18 71 38 2d 40 58 2c 25 00 55 50 21 00 00 1e 01
      1d 80 18 1c 16 20 58 2c 25 00 55 50 21 00 00 9e <-- 0x71 is missing
      01 1d 00 72 51 d0 1e 20 6e 28 55 00 55 50 21 00
      00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 55 50
      21 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 5d 00

The position of the dropped byte changes, sometimes the EDID is complete, sometimes several bytes are dropped.

The bad EDIDs are *often* accompanied with [drm:radeon_process_aux_ch] dp_aux_ch flags not zero messages.

Most probably the common i2c-over-aux code drops the byte, as it starts the transfer again in case of -EBUSY. If I change radeon_process_aux_ch to return -EIO in case of (ReplyStatus == 2), I no longer have any bad checksums.

Hardware is Radeon 7750 + Dell U2713HM, connected via DP.

Same monitor with Intel Haswell and different cable works without any errors.

Kernel is 3.15.1, i.e. without the i2c bus mutex, dont know if this fixes the problems as well.
Comment 1 Stefan Brüns 2014-06-29 18:35:25 UTC
I have added the i2c bus mutex, this does *not* fix this bug.
Comment 2 Alex Deucher 2014-07-01 16:00:29 UTC
Created attachment 102076 [details] [review]
possible fix

Does this patch help?
Comment 3 Stefan Brüns 2014-07-02 23:19:37 UTC
Created attachment 102173 [details] [review]
different approach

This patch fixes the problem for me. I get several warning messages with "flags not zero", but the EDID is complete and correct.
Comment 4 Stefan Brüns 2014-07-02 23:22:21 UTC
(In reply to comment #2)
> Created attachment 102076 [details] [review] [review]
> possible fix
> 
> Does this patch help?

Nope, unfortunately not.

The transfer has actually worked, even with nonzero flags. *if* we want to start the transfer again, we have to set the offset before doing so.
Comment 5 Alex Deucher 2014-07-03 15:23:44 UTC
Created attachment 102203 [details] [review]
return -EIO for flags not zero

Thinking about this more, I think returning -EIO is probably the right thing to do since we don't know for sure whether the transaction succeeded or not.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.