[Bug 93956] Display Port BYT-M [N2807] - Data link training fails sporadically

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Zoran Stojsavljevic <zoran.stojsavljevic at intel.com> ---
(In reply to Zoran Stojsavljevic from comment #4)
> Hello Jim,
> 
> I would write this code differently:
> 
> 482         struct drm_i915_private *dev_priv = bus->dev_priv;
> 483 --      int i = 0, inc, try = 0;
> 483 ++      int i = 0, inc = 1, try = 0;
> 484         int ret = 0;
> 485 
> 486         intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> 487         mutex_lock(&dev_priv->gmbus_mutex);
> 488 
> 489         if (bus->force_bit) {
> 490                 ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
> 491                 goto out;
> 492         }
> 493 
> 494 retry:
> 495         I915_WRITE(GMBUS0, bus->reg0);
> 496 
> 497         for (; i < num; i += inc) {
> 498 --              inc = 1;
> 499                 if (gmbus_is_index_read(msgs, i, num)) {
> 500                         ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
> 501                         inc = 2; /* an index read is two msgs */
> 502                 } else if (msgs[i].flags & I2C_M_RD) {
> 503                         ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
> 504                 } else {
> 505                         ret = gmbus_xfer_write(dev_priv, &msgs[i]);
> 506                 }
> 507 
> 508                 if (ret == -ETIMEDOUT)
> 509                         goto timeout;
> 510                 if (ret == -ENXIO)
> 511                         goto clear_err;
> 512 
> 513                 ret = gmbus_wait_hw_status(dev_priv, GMBUS_HW_WAIT_PHASE,
> 514                                            GMBUS_HW_WAIT_EN);
> 515                 if (ret == -ENXIO)
> 516                         goto clear_err;
> 517                 if (ret)
> 518                         goto timeout;
> 519         }
> 
> Since you can be potentially stuck in:
> 497         for (; i < num; i += inc) {
> 
> forever.
> 
> Thank you,
> Zoran

Please, disregard/discard my message. I over combined. The code is OK.

I need to think more... About this case.

One question here to explore is the following: to have while booting to Linux 0
displays (no ANY monitor) attached -- headless booting via UEFI BIOS + GOP
used, and then, after system comes to Linux kernel 4.2+ and later, to see if
this bug shows again (attach monitor after kernel login screen)?

Thank you,
Zoran

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