Summary: | I2C-over-AUX drops single bytes | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Stefan Brüns <stefan.bruens> | ||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||
Status: | RESOLVED MOVED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | medium | ||||||||||
Version: | DRI git | ||||||||||
Hardware: | Other | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Stefan Brüns
2014-06-29 18:09:20 UTC
I have added the i2c bus mutex, this does *not* fix this bug. Created attachment 102076 [details] [review] possible fix Does this patch help? 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. (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. 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.