[Bug 100954] i915 i2c-dev failures with recent chips and docking stations

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Oct 23 09:51:44 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=100954

--- Comment #20 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Sanford Rockowitz from comment #18)
> Here's a vote for getting some variant of the I2C speed change for DDC
> devices into the i915 driver, preferably with a module option allowing users
> to specify the speed to be used.  
> 
> Relatedly, it looks like the following change allows for adjusting the
> DDC/CI speed for DisplayPort connected monitors, irrespective of video
> driver.  Am I correct on that?
> 
> https://www.systutorials.com/linux-kernels/600766/drm-dp-add-
> dp_aux_i2c_speed_khz-module-param-to-set-the-assume-i2c-bus-speed-linux-4-3/
> 
> You're so right about marginal DDC/CI implementations.  For my personal
> rogues' gallery see: http://www.ddcutil.com/monitor_notes/

dp_aux_i2c_speed_khz only allows you to set the assumed i2c bus speed (for
timeouts and such). It doesn't actually try to configure it via the
DP_I2C_SPEED_CONTROL_STATUS. And I haven't seen many devices that even support
DP_I2C_SPEED_CONTROL_STATUS.

In general we don't like to add modparams. Having them usually means users
randomly setting them instead of reporting the bugs. Ideally we'd come up with
some kind of scheme that just works. Perhaps some kind of "retry with slower
speed" type of thing. Unfortunately that would only work for i2c protocol level
errors. If it's just the payload that's corrupted we can't detect it. That
would have to be done by whoever initiated the transfer. So some kind of new
i2c adapter function that could be called to reduce the speed perhaps, and I
suppose we'd need a similar ioctl for /dev/i2c. An alternative would be a new
function/ioctl to explicitly set the bus speed. Something like that would allow
you to maintain a i2c bus speed quirk list for ddc/ci at least.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20181023/f5c53c61/attachment-0001.html>


More information about the intel-gfx-bugs mailing list