2009-04-08 07:16:42 +08:00
|
|
|
/*
|
|
|
|
* Copyright © 2009 Keith Packard
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
*
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/i2c.h>
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/drm_dp_helper.h>
|
|
|
|
#include <drm/drmP.h>
|
2009-04-08 07:16:42 +08:00
|
|
|
|
2016-08-13 04:48:52 +08:00
|
|
|
#include "drm_crtc_helper_internal.h"
|
|
|
|
|
2012-11-01 21:45:18 +08:00
|
|
|
/**
|
|
|
|
* DOC: dp helpers
|
|
|
|
*
|
|
|
|
* These functions contain some common logic and helpers at various abstraction
|
|
|
|
* levels to deal with Display Port sink devices and related things like DP aux
|
|
|
|
* channel transfers, EDID reading over DP aux channels, decoding certain DPCD
|
|
|
|
* blocks, ...
|
|
|
|
*/
|
|
|
|
|
2012-10-18 16:15:24 +08:00
|
|
|
/* Helpers for DP link training */
|
2013-09-28 00:01:01 +08:00
|
|
|
static u8 dp_link_status(const u8 link_status[DP_LINK_STATUS_SIZE], int r)
|
2012-10-18 16:15:24 +08:00
|
|
|
{
|
|
|
|
return link_status[r - DP_LANE0_1_STATUS];
|
|
|
|
}
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
|
2012-10-18 16:15:24 +08:00
|
|
|
int lane)
|
|
|
|
{
|
|
|
|
int i = DP_LANE0_1_STATUS + (lane >> 1);
|
|
|
|
int s = (lane & 1) * 4;
|
|
|
|
u8 l = dp_link_status(link_status, i);
|
|
|
|
return (l >> s) & 0xf;
|
|
|
|
}
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
|
2012-10-18 16:15:24 +08:00
|
|
|
int lane_count)
|
|
|
|
{
|
|
|
|
u8 lane_align;
|
|
|
|
u8 lane_status;
|
|
|
|
int lane;
|
|
|
|
|
|
|
|
lane_align = dp_link_status(link_status,
|
|
|
|
DP_LANE_ALIGN_STATUS_UPDATED);
|
|
|
|
if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
|
|
|
|
return false;
|
|
|
|
for (lane = 0; lane < lane_count; lane++) {
|
|
|
|
lane_status = dp_get_lane_status(link_status, lane);
|
|
|
|
if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_channel_eq_ok);
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
|
2012-10-18 16:15:24 +08:00
|
|
|
int lane_count)
|
|
|
|
{
|
|
|
|
int lane;
|
|
|
|
u8 lane_status;
|
|
|
|
|
|
|
|
for (lane = 0; lane < lane_count; lane++) {
|
|
|
|
lane_status = dp_get_lane_status(link_status, lane);
|
|
|
|
if ((lane_status & DP_LANE_CR_DONE) == 0)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_clock_recovery_ok);
|
2012-10-18 16:15:27 +08:00
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
u8 drm_dp_get_adjust_request_voltage(const u8 link_status[DP_LINK_STATUS_SIZE],
|
2012-10-18 16:15:27 +08:00
|
|
|
int lane)
|
|
|
|
{
|
|
|
|
int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
|
|
|
|
int s = ((lane & 1) ?
|
|
|
|
DP_ADJUST_VOLTAGE_SWING_LANE1_SHIFT :
|
|
|
|
DP_ADJUST_VOLTAGE_SWING_LANE0_SHIFT);
|
|
|
|
u8 l = dp_link_status(link_status, i);
|
|
|
|
|
|
|
|
return ((l >> s) & 0x3) << DP_TRAIN_VOLTAGE_SWING_SHIFT;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_get_adjust_request_voltage);
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SIZE],
|
2012-10-18 16:15:27 +08:00
|
|
|
int lane)
|
|
|
|
{
|
|
|
|
int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
|
|
|
|
int s = ((lane & 1) ?
|
|
|
|
DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT :
|
|
|
|
DP_ADJUST_PRE_EMPHASIS_LANE0_SHIFT);
|
|
|
|
u8 l = dp_link_status(link_status, i);
|
|
|
|
|
|
|
|
return ((l >> s) & 0x3) << DP_TRAIN_PRE_EMPHASIS_SHIFT;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
|
2012-10-18 21:32:40 +08:00
|
|
|
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
|
|
|
|
udelay(100);
|
|
|
|
else
|
|
|
|
mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
|
|
|
|
|
2013-09-28 00:01:01 +08:00
|
|
|
void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
|
2012-10-18 21:32:40 +08:00
|
|
|
if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
|
|
|
|
udelay(400);
|
|
|
|
else
|
|
|
|
mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
|
2012-10-18 16:15:31 +08:00
|
|
|
|
|
|
|
u8 drm_dp_link_rate_to_bw_code(int link_rate)
|
|
|
|
{
|
|
|
|
switch (link_rate) {
|
|
|
|
case 162000:
|
|
|
|
default:
|
|
|
|
return DP_LINK_BW_1_62;
|
|
|
|
case 270000:
|
|
|
|
return DP_LINK_BW_2_7;
|
|
|
|
case 540000:
|
|
|
|
return DP_LINK_BW_5_4;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
|
|
|
|
|
|
|
|
int drm_dp_bw_code_to_link_rate(u8 link_bw)
|
|
|
|
{
|
|
|
|
switch (link_bw) {
|
|
|
|
case DP_LINK_BW_1_62:
|
|
|
|
default:
|
|
|
|
return 162000;
|
|
|
|
case DP_LINK_BW_2_7:
|
|
|
|
return 270000;
|
|
|
|
case DP_LINK_BW_5_4:
|
|
|
|
return 540000;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
|
2013-11-28 18:31:00 +08:00
|
|
|
|
2015-08-27 03:55:05 +08:00
|
|
|
#define AUX_RETRY_INTERVAL 500 /* us */
|
|
|
|
|
2013-11-28 18:31:00 +08:00
|
|
|
/**
|
|
|
|
* DOC: dp helpers
|
|
|
|
*
|
|
|
|
* The DisplayPort AUX channel is an abstraction to allow generic, driver-
|
|
|
|
* independent access to AUX functionality. Drivers can take advantage of
|
|
|
|
* this by filling in the fields of the drm_dp_aux structure.
|
|
|
|
*
|
|
|
|
* Transactions are described using a hardware-independent drm_dp_aux_msg
|
|
|
|
* structure, which is passed into a driver's .transfer() implementation.
|
|
|
|
* Both native and I2C-over-AUX transactions are supported.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
|
|
|
|
unsigned int offset, void *buffer, size_t size)
|
|
|
|
{
|
|
|
|
struct drm_dp_aux_msg msg;
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
unsigned int retry, native_reply;
|
|
|
|
int err = 0, ret = 0;
|
2013-11-28 18:31:00 +08:00
|
|
|
|
|
|
|
memset(&msg, 0, sizeof(msg));
|
|
|
|
msg.address = offset;
|
|
|
|
msg.request = request;
|
|
|
|
msg.buffer = buffer;
|
|
|
|
msg.size = size;
|
|
|
|
|
2016-02-26 05:15:05 +08:00
|
|
|
mutex_lock(&aux->hw_mutex);
|
|
|
|
|
2013-11-28 18:31:00 +08:00
|
|
|
/*
|
|
|
|
* The specification doesn't give any recommendation on how often to
|
2014-11-26 11:13:09 +08:00
|
|
|
* retry native transactions. We used to retry 7 times like for
|
|
|
|
* aux i2c transactions but real world devices this wasn't
|
|
|
|
* sufficient, bump to 32 which makes Dell 4k monitors happier.
|
2013-11-28 18:31:00 +08:00
|
|
|
*/
|
2014-11-26 11:13:09 +08:00
|
|
|
for (retry = 0; retry < 32; retry++) {
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
if (ret != 0 && ret != -ETIMEDOUT) {
|
2016-04-13 22:58:30 +08:00
|
|
|
usleep_range(AUX_RETRY_INTERVAL,
|
|
|
|
AUX_RETRY_INTERVAL + 100);
|
|
|
|
}
|
2014-06-04 14:02:28 +08:00
|
|
|
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
ret = aux->transfer(aux, &msg);
|
2013-11-28 18:31:00 +08:00
|
|
|
|
2016-07-28 22:54:42 +08:00
|
|
|
if (ret >= 0) {
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
native_reply = msg.reply & DP_AUX_NATIVE_REPLY_MASK;
|
|
|
|
if (native_reply == DP_AUX_NATIVE_REPLY_ACK) {
|
|
|
|
if (ret == size)
|
|
|
|
goto unlock;
|
2013-11-28 18:31:00 +08:00
|
|
|
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
ret = -EPROTO;
|
|
|
|
} else
|
|
|
|
ret = -EIO;
|
2013-11-28 18:31:00 +08:00
|
|
|
}
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We want the error we return to be the error we received on
|
|
|
|
* the first transaction, since we may get a different error the
|
|
|
|
* next time we retry
|
|
|
|
*/
|
|
|
|
if (!err)
|
|
|
|
err = ret;
|
2013-11-28 18:31:00 +08:00
|
|
|
}
|
|
|
|
|
2016-08-06 08:30:33 +08:00
|
|
|
DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
ret = err;
|
2016-02-26 05:15:05 +08:00
|
|
|
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&aux->hw_mutex);
|
drm/dp_helper: Retry aux transactions on all errors
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
2016-04-13 22:58:31 +08:00
|
|
|
return ret;
|
2013-11-28 18:31:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_dpcd_read() - read a series of bytes from the DPCD
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @offset: address of the (first) register to read
|
|
|
|
* @buffer: buffer to store the register values
|
|
|
|
* @size: number of bytes in @buffer
|
|
|
|
*
|
|
|
|
* Returns the number of bytes transferred on success, or a negative error
|
|
|
|
* code on failure. -EIO is returned if the request was NAKed by the sink or
|
|
|
|
* if the retry count was exceeded. If not all bytes were transferred, this
|
|
|
|
* function returns -EPROTO. Errors from the underlying AUX channel transfer
|
|
|
|
* function, with the exception of -EBUSY (which causes the transaction to
|
|
|
|
* be retried), are propagated to the caller.
|
|
|
|
*/
|
|
|
|
ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
|
|
|
|
void *buffer, size_t size)
|
|
|
|
{
|
2016-04-15 22:25:35 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HP ZR24w corrupts the first DPCD access after entering power save
|
|
|
|
* mode. Eg. on a read, the entire buffer will be filled with the same
|
|
|
|
* byte. Do a throw away read to avoid corrupting anything we care
|
|
|
|
* about. Afterwards things will work correctly until the monitor
|
|
|
|
* gets woken up and subsequently re-enters power save mode.
|
|
|
|
*
|
|
|
|
* The user pressing any button on the monitor is enough to wake it
|
|
|
|
* up, so there is no particularly good place to do the workaround.
|
|
|
|
* We just have to do it before any DPCD access and hope that the
|
|
|
|
* monitor doesn't power down exactly after the throw away read.
|
|
|
|
*/
|
|
|
|
ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
|
|
|
|
1);
|
|
|
|
if (ret != 1)
|
|
|
|
return ret;
|
|
|
|
|
2013-11-28 18:31:00 +08:00
|
|
|
return drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
|
|
|
|
size);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_dpcd_read);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_dpcd_write() - write a series of bytes to the DPCD
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @offset: address of the (first) register to write
|
|
|
|
* @buffer: buffer containing the values to write
|
|
|
|
* @size: number of bytes in @buffer
|
|
|
|
*
|
|
|
|
* Returns the number of bytes transferred on success, or a negative error
|
|
|
|
* code on failure. -EIO is returned if the request was NAKed by the sink or
|
|
|
|
* if the retry count was exceeded. If not all bytes were transferred, this
|
|
|
|
* function returns -EPROTO. Errors from the underlying AUX channel transfer
|
|
|
|
* function, with the exception of -EBUSY (which causes the transaction to
|
|
|
|
* be retried), are propagated to the caller.
|
|
|
|
*/
|
|
|
|
ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int offset,
|
|
|
|
void *buffer, size_t size)
|
|
|
|
{
|
|
|
|
return drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
|
|
|
|
size);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_dpcd_write);
|
2013-11-22 23:37:57 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_dpcd_read_link_status() - read DPCD link status (bytes 0x202-0x207)
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @status: buffer to store the link status in (must be at least 6 bytes)
|
|
|
|
*
|
|
|
|
* Returns the number of bytes transferred on success or a negative error
|
|
|
|
* code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
|
|
|
|
u8 status[DP_LINK_STATUS_SIZE])
|
|
|
|
{
|
|
|
|
return drm_dp_dpcd_read(aux, DP_LANE0_1_STATUS, status,
|
|
|
|
DP_LINK_STATUS_SIZE);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
|
2013-12-09 18:47:55 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_link_probe() - probe a DisplayPort link for capabilities
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @link: pointer to structure in which to return link capabilities
|
|
|
|
*
|
|
|
|
* The structure filled in by this function can usually be passed directly
|
|
|
|
* into drm_dp_link_power_up() and drm_dp_link_configure() to power up and
|
|
|
|
* configure the link based on the link's capabilities.
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
|
|
|
|
{
|
|
|
|
u8 values[3];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
memset(link, 0, sizeof(*link));
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
link->revision = values[0];
|
|
|
|
link->rate = drm_dp_bw_code_to_link_rate(values[1]);
|
|
|
|
link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
|
|
|
|
|
|
|
|
if (values[2] & DP_ENHANCED_FRAME_CAP)
|
|
|
|
link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_probe);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_link_power_up() - power up a DisplayPort link
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @link: pointer to a structure containing the link configuration
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link)
|
|
|
|
{
|
|
|
|
u8 value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* DP_SET_POWER register is only available on DPCD v1.1 and later */
|
|
|
|
if (link->revision < 0x11)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
value &= ~DP_SET_POWER_MASK;
|
|
|
|
value |= DP_SET_POWER_D0;
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* According to the DP 1.1 specification, a "Sink Device must exit the
|
|
|
|
* power saving state within 1 ms" (Section 2.5.3.1, Table 5-52, "Sink
|
|
|
|
* Control Field" (register 0x600).
|
|
|
|
*/
|
|
|
|
usleep_range(1000, 2000);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_power_up);
|
|
|
|
|
2014-12-02 23:43:07 +08:00
|
|
|
/**
|
|
|
|
* drm_dp_link_power_down() - power down a DisplayPort link
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @link: pointer to a structure containing the link configuration
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link)
|
|
|
|
{
|
|
|
|
u8 value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* DP_SET_POWER register is only available on DPCD v1.1 and later */
|
|
|
|
if (link->revision < 0x11)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
value &= ~DP_SET_POWER_MASK;
|
|
|
|
value |= DP_SET_POWER_D3;
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_power_down);
|
|
|
|
|
2013-12-09 18:47:55 +08:00
|
|
|
/**
|
|
|
|
* drm_dp_link_configure() - configure a DisplayPort link
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
* @link: pointer to a structure containing the link configuration
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
|
|
|
|
{
|
|
|
|
u8 values[2];
|
|
|
|
int err;
|
|
|
|
|
|
|
|
values[0] = drm_dp_link_rate_to_bw_code(link->rate);
|
|
|
|
values[1] = link->num_lanes;
|
|
|
|
|
|
|
|
if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
|
|
|
|
values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
|
|
|
|
|
|
|
|
err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, values, sizeof(values));
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_link_configure);
|
2013-12-12 16:57:53 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* I2C-over-AUX implementation
|
|
|
|
*/
|
|
|
|
|
|
|
|
static u32 drm_dp_i2c_functionality(struct i2c_adapter *adapter)
|
|
|
|
{
|
|
|
|
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
|
|
|
|
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
|
|
|
|
I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
|
|
|
|
I2C_FUNC_10BIT_ADDR;
|
|
|
|
}
|
|
|
|
|
2015-08-27 22:23:30 +08:00
|
|
|
static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* In case of i2c defer or short i2c ack reply to a write,
|
|
|
|
* we need to switch to WRITE_STATUS_UPDATE to drain the
|
|
|
|
* rest of the message
|
|
|
|
*/
|
|
|
|
if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
|
|
|
|
msg->request &= DP_AUX_I2C_MOT;
|
|
|
|
msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-02 01:12:54 +08:00
|
|
|
#define AUX_PRECHARGE_LEN 10 /* 10 to 16 */
|
|
|
|
#define AUX_SYNC_LEN (16 + 4) /* preamble + AUX_SYNC_END */
|
|
|
|
#define AUX_STOP_LEN 4
|
|
|
|
#define AUX_CMD_LEN 4
|
|
|
|
#define AUX_ADDRESS_LEN 20
|
|
|
|
#define AUX_REPLY_PAD_LEN 4
|
|
|
|
#define AUX_LENGTH_LEN 8
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the duration of the AUX request/reply in usec. Gives the
|
|
|
|
* "best" case estimate, ie. successful while as short as possible.
|
|
|
|
*/
|
|
|
|
static int drm_dp_aux_req_duration(const struct drm_dp_aux_msg *msg)
|
|
|
|
{
|
|
|
|
int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
|
|
|
|
AUX_CMD_LEN + AUX_ADDRESS_LEN + AUX_LENGTH_LEN;
|
|
|
|
|
|
|
|
if ((msg->request & DP_AUX_I2C_READ) == 0)
|
|
|
|
len += msg->size * 8;
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int drm_dp_aux_reply_duration(const struct drm_dp_aux_msg *msg)
|
|
|
|
{
|
|
|
|
int len = AUX_PRECHARGE_LEN + AUX_SYNC_LEN + AUX_STOP_LEN +
|
|
|
|
AUX_CMD_LEN + AUX_REPLY_PAD_LEN;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For read we expect what was asked. For writes there will
|
|
|
|
* be 0 or 1 data bytes. Assume 0 for the "best" case.
|
|
|
|
*/
|
|
|
|
if (msg->request & DP_AUX_I2C_READ)
|
|
|
|
len += msg->size * 8;
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define I2C_START_LEN 1
|
|
|
|
#define I2C_STOP_LEN 1
|
|
|
|
#define I2C_ADDR_LEN 9 /* ADDRESS + R/W + ACK/NACK */
|
|
|
|
#define I2C_DATA_LEN 9 /* DATA + ACK/NACK */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the length of the i2c transfer in usec, assuming
|
|
|
|
* the i2c bus speed is as specified. Gives the the "worst"
|
|
|
|
* case estimate, ie. successful while as long as possible.
|
|
|
|
* Doesn't account the the "MOT" bit, and instead assumes each
|
|
|
|
* message includes a START, ADDRESS and STOP. Neither does it
|
|
|
|
* account for additional random variables such as clock stretching.
|
|
|
|
*/
|
|
|
|
static int drm_dp_i2c_msg_duration(const struct drm_dp_aux_msg *msg,
|
|
|
|
int i2c_speed_khz)
|
|
|
|
{
|
|
|
|
/* AUX bitrate is 1MHz, i2c bitrate as specified */
|
|
|
|
return DIV_ROUND_UP((I2C_START_LEN + I2C_ADDR_LEN +
|
|
|
|
msg->size * I2C_DATA_LEN +
|
|
|
|
I2C_STOP_LEN) * 1000, i2c_speed_khz);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Deterine how many retries should be attempted to successfully transfer
|
|
|
|
* the specified message, based on the estimated durations of the
|
|
|
|
* i2c and AUX transfers.
|
|
|
|
*/
|
|
|
|
static int drm_dp_i2c_retry_count(const struct drm_dp_aux_msg *msg,
|
|
|
|
int i2c_speed_khz)
|
|
|
|
{
|
|
|
|
int aux_time_us = drm_dp_aux_req_duration(msg) +
|
|
|
|
drm_dp_aux_reply_duration(msg);
|
|
|
|
int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz);
|
|
|
|
|
|
|
|
return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL);
|
|
|
|
}
|
|
|
|
|
2015-08-27 03:55:07 +08:00
|
|
|
/*
|
|
|
|
* FIXME currently assumes 10 kHz as some real world devices seem
|
|
|
|
* to require it. We should query/set the speed via DPCD if supported.
|
|
|
|
*/
|
|
|
|
static int dp_aux_i2c_speed_khz __read_mostly = 10;
|
|
|
|
module_param_unsafe(dp_aux_i2c_speed_khz, int, 0644);
|
|
|
|
MODULE_PARM_DESC(dp_aux_i2c_speed_khz,
|
|
|
|
"Assumed speed of the i2c bus in kHz, (1-400, default 10)");
|
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
/*
|
|
|
|
* Transfer a single I2C-over-AUX message and handle various error conditions,
|
2014-04-07 22:33:45 +08:00
|
|
|
* retrying the transaction as appropriate. It is assumed that the
|
|
|
|
* aux->transfer function does not modify anything in the msg other than the
|
|
|
|
* reply field.
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
*
|
|
|
|
* Returns bytes transferred on success, or a negative error code on failure.
|
2013-12-12 16:57:53 +08:00
|
|
|
*/
|
|
|
|
static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
|
|
|
|
{
|
2015-04-18 15:04:18 +08:00
|
|
|
unsigned int retry, defer_i2c;
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
int ret;
|
2013-12-12 16:57:53 +08:00
|
|
|
/*
|
|
|
|
* DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
|
|
|
|
* is required to retry at least seven times upon receiving AUX_DEFER
|
|
|
|
* before giving up the AUX transaction.
|
2015-09-02 01:12:54 +08:00
|
|
|
*
|
|
|
|
* We also try to account for the i2c bus speed.
|
2013-12-12 16:57:53 +08:00
|
|
|
*/
|
2015-08-27 03:55:07 +08:00
|
|
|
int max_retries = max(7, drm_dp_i2c_retry_count(msg, dp_aux_i2c_speed_khz));
|
2015-09-02 01:12:54 +08:00
|
|
|
|
|
|
|
for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c); retry++) {
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
ret = aux->transfer(aux, msg);
|
|
|
|
if (ret < 0) {
|
|
|
|
if (ret == -EBUSY)
|
2013-12-12 16:57:53 +08:00
|
|
|
continue;
|
|
|
|
|
2016-08-06 08:30:39 +08:00
|
|
|
/*
|
|
|
|
* While timeouts can be errors, they're usually normal
|
|
|
|
* behavior (for instance, when a driver tries to
|
|
|
|
* communicate with a non-existant DisplayPort device).
|
|
|
|
* Avoid spamming the kernel log with timeout errors.
|
|
|
|
*/
|
|
|
|
if (ret == -ETIMEDOUT)
|
|
|
|
DRM_DEBUG_KMS_RATELIMITED("transaction timed out\n");
|
|
|
|
else
|
|
|
|
DRM_DEBUG_KMS("transaction failed: %d\n", ret);
|
|
|
|
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
return ret;
|
2013-12-12 16:57:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
switch (msg->reply & DP_AUX_NATIVE_REPLY_MASK) {
|
|
|
|
case DP_AUX_NATIVE_REPLY_ACK:
|
|
|
|
/*
|
|
|
|
* For I2C-over-AUX transactions this isn't enough, we
|
|
|
|
* need to check for the I2C ACK reply.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DP_AUX_NATIVE_REPLY_NACK:
|
2015-03-19 19:38:57 +08:00
|
|
|
DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n", ret, msg->size);
|
2013-12-12 16:57:53 +08:00
|
|
|
return -EREMOTEIO;
|
|
|
|
|
|
|
|
case DP_AUX_NATIVE_REPLY_DEFER:
|
2015-04-15 23:38:47 +08:00
|
|
|
DRM_DEBUG_KMS("native defer\n");
|
2013-12-12 16:57:53 +08:00
|
|
|
/*
|
|
|
|
* We could check for I2C bit rate capabilities and if
|
|
|
|
* available adjust this interval. We could also be
|
|
|
|
* more careful with DP-to-legacy adapters where a
|
|
|
|
* long legacy cable may force very low I2C bit rates.
|
|
|
|
*
|
|
|
|
* For now just defer for long enough to hopefully be
|
|
|
|
* safe for all use-cases.
|
|
|
|
*/
|
2015-08-27 03:55:05 +08:00
|
|
|
usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100);
|
2013-12-12 16:57:53 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
default:
|
|
|
|
DRM_ERROR("invalid native reply %#04x\n", msg->reply);
|
|
|
|
return -EREMOTEIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (msg->reply & DP_AUX_I2C_REPLY_MASK) {
|
|
|
|
case DP_AUX_I2C_REPLY_ACK:
|
|
|
|
/*
|
|
|
|
* Both native ACK and I2C ACK replies received. We
|
|
|
|
* can assume the transfer was successful.
|
|
|
|
*/
|
2015-08-27 22:23:30 +08:00
|
|
|
if (ret != msg->size)
|
|
|
|
drm_dp_i2c_msg_write_status_update(msg);
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
return ret;
|
2013-12-12 16:57:53 +08:00
|
|
|
|
|
|
|
case DP_AUX_I2C_REPLY_NACK:
|
2015-03-19 19:38:57 +08:00
|
|
|
DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu\n", ret, msg->size);
|
2014-11-05 06:17:35 +08:00
|
|
|
aux->i2c_nack_count++;
|
2013-12-12 16:57:53 +08:00
|
|
|
return -EREMOTEIO;
|
|
|
|
|
|
|
|
case DP_AUX_I2C_REPLY_DEFER:
|
|
|
|
DRM_DEBUG_KMS("I2C defer\n");
|
2015-04-18 15:04:18 +08:00
|
|
|
/* DP Compliance Test 4.2.2.5 Requirement:
|
|
|
|
* Must have at least 7 retries for I2C defers on the
|
|
|
|
* transaction to pass this test
|
|
|
|
*/
|
2014-11-05 06:17:35 +08:00
|
|
|
aux->i2c_defer_count++;
|
2015-04-18 15:04:18 +08:00
|
|
|
if (defer_i2c < 7)
|
|
|
|
defer_i2c++;
|
2015-08-27 03:55:05 +08:00
|
|
|
usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100);
|
2015-08-27 22:23:30 +08:00
|
|
|
drm_dp_i2c_msg_write_status_update(msg);
|
2015-09-22 17:02:18 +08:00
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
default:
|
|
|
|
DRM_ERROR("invalid I2C reply %#04x\n", msg->reply);
|
|
|
|
return -EREMOTEIO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-21 22:34:06 +08:00
|
|
|
DRM_DEBUG_KMS("too many retries, giving up\n");
|
2013-12-12 16:57:53 +08:00
|
|
|
return -EREMOTEIO;
|
|
|
|
}
|
|
|
|
|
2015-08-27 22:23:30 +08:00
|
|
|
static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
|
|
|
|
const struct i2c_msg *i2c_msg)
|
|
|
|
{
|
|
|
|
msg->request = (i2c_msg->flags & I2C_M_RD) ?
|
|
|
|
DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
|
|
|
|
msg->request |= DP_AUX_I2C_MOT;
|
|
|
|
}
|
|
|
|
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
/*
|
|
|
|
* Keep retrying drm_dp_i2c_do_msg until all data has been transferred.
|
|
|
|
*
|
|
|
|
* Returns an error code on failure, or a recommended transfer size on success.
|
|
|
|
*/
|
|
|
|
static int drm_dp_i2c_drain_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *orig_msg)
|
|
|
|
{
|
|
|
|
int err, ret = orig_msg->size;
|
|
|
|
struct drm_dp_aux_msg msg = *orig_msg;
|
|
|
|
|
|
|
|
while (msg.size > 0) {
|
|
|
|
err = drm_dp_i2c_do_msg(aux, &msg);
|
|
|
|
if (err <= 0)
|
|
|
|
return err == 0 ? -EPROTO : err;
|
|
|
|
|
|
|
|
if (err < msg.size && err < ret) {
|
|
|
|
DRM_DEBUG_KMS("Partial I2C reply: requested %zu bytes got %d bytes\n",
|
|
|
|
msg.size, err);
|
|
|
|
ret = err;
|
|
|
|
}
|
|
|
|
|
|
|
|
msg.size -= err;
|
|
|
|
msg.buffer += err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bizlink designed DP->DVI-D Dual Link adapters require the I2C over AUX
|
|
|
|
* packets to be as large as possible. If not, the I2C transactions never
|
|
|
|
* succeed. Hence the default is maximum.
|
|
|
|
*/
|
|
|
|
static int dp_aux_i2c_transfer_size __read_mostly = DP_AUX_MAX_PAYLOAD_BYTES;
|
|
|
|
module_param_unsafe(dp_aux_i2c_transfer_size, int, 0644);
|
|
|
|
MODULE_PARM_DESC(dp_aux_i2c_transfer_size,
|
|
|
|
"Number of bytes to transfer in a single I2C over DP AUX CH message, (1-16, default 16)");
|
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs,
|
|
|
|
int num)
|
|
|
|
{
|
|
|
|
struct drm_dp_aux *aux = adapter->algo_data;
|
|
|
|
unsigned int i, j;
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
unsigned transfer_size;
|
2014-04-07 22:33:44 +08:00
|
|
|
struct drm_dp_aux_msg msg;
|
|
|
|
int err = 0;
|
2013-12-12 16:57:53 +08:00
|
|
|
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
dp_aux_i2c_transfer_size = clamp(dp_aux_i2c_transfer_size, 1, DP_AUX_MAX_PAYLOAD_BYTES);
|
|
|
|
|
2014-04-07 22:33:44 +08:00
|
|
|
memset(&msg, 0, sizeof(msg));
|
2013-12-12 16:57:53 +08:00
|
|
|
|
2014-04-07 22:33:44 +08:00
|
|
|
for (i = 0; i < num; i++) {
|
|
|
|
msg.address = msgs[i].addr;
|
2015-08-27 22:23:30 +08:00
|
|
|
drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
|
2014-04-07 22:33:44 +08:00
|
|
|
/* Send a bare address packet to start the transaction.
|
|
|
|
* Zero sized messages specify an address only (bare
|
|
|
|
* address) transaction.
|
|
|
|
*/
|
|
|
|
msg.buffer = NULL;
|
|
|
|
msg.size = 0;
|
|
|
|
err = drm_dp_i2c_do_msg(aux, &msg);
|
2015-08-27 22:23:30 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset msg.request in case in case it got
|
|
|
|
* changed into a WRITE_STATUS_UPDATE.
|
|
|
|
*/
|
|
|
|
drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
|
|
|
|
|
2014-04-07 22:33:44 +08:00
|
|
|
if (err < 0)
|
|
|
|
break;
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
/* We want each transaction to be as large as possible, but
|
|
|
|
* we'll go to smaller sizes if the hardware gives us a
|
|
|
|
* short reply.
|
2013-12-12 16:57:53 +08:00
|
|
|
*/
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
transfer_size = dp_aux_i2c_transfer_size;
|
|
|
|
for (j = 0; j < msgs[i].len; j += msg.size) {
|
2013-12-12 16:57:53 +08:00
|
|
|
msg.buffer = msgs[i].buf + j;
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
msg.size = min(transfer_size, msgs[i].len - j);
|
2013-12-12 16:57:53 +08:00
|
|
|
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
err = drm_dp_i2c_drain_msg(aux, &msg);
|
2015-08-27 22:23:30 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset msg.request in case in case it got
|
|
|
|
* changed into a WRITE_STATUS_UPDATE.
|
|
|
|
*/
|
|
|
|
drm_dp_i2c_msg_set_request(&msg, &msgs[i]);
|
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
if (err < 0)
|
2014-04-07 22:33:44 +08:00
|
|
|
break;
|
drm/dp: Use large transactions for I2C over AUX
Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
in their I2C over AUX implementation (fixed in newer revisions). They work
fine with Windows, but fail with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.
Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does.
Also provide an unsafe module parameter for testing smaller transfer sizes,
in case there are sinks out there that cannot work with Windows.
Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
the following changes in his testing:
Device under test: old -> with this patch
DP->DVI (OUI 001cf8): 40ms -> 35ms
DP->VGA (OUI 0022b9): 45ms -> 38ms
Zotac DP->2xHDMI: 25ms -> 4ms
Asus PB278 monitor: 22ms -> 3ms
A back of the envelope calculation shows that peak theoretical transfer rate
for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
around 500 kbit/s, which explains the increase in speed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-11 02:38:08 +08:00
|
|
|
transfer_size = err;
|
2013-12-12 16:57:53 +08:00
|
|
|
}
|
2014-04-07 22:33:44 +08:00
|
|
|
if (err < 0)
|
|
|
|
break;
|
2013-12-12 16:57:53 +08:00
|
|
|
}
|
2014-04-07 22:33:44 +08:00
|
|
|
if (err >= 0)
|
|
|
|
err = num;
|
|
|
|
/* Send a bare address packet to close out the transaction.
|
|
|
|
* Zero sized messages specify an address only (bare
|
|
|
|
* address) transaction.
|
|
|
|
*/
|
|
|
|
msg.request &= ~DP_AUX_I2C_MOT;
|
|
|
|
msg.buffer = NULL;
|
|
|
|
msg.size = 0;
|
|
|
|
(void)drm_dp_i2c_do_msg(aux, &msg);
|
2013-12-12 16:57:53 +08:00
|
|
|
|
2014-04-07 22:33:44 +08:00
|
|
|
return err;
|
2013-12-12 16:57:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct i2c_algorithm drm_dp_i2c_algo = {
|
|
|
|
.functionality = drm_dp_i2c_functionality,
|
|
|
|
.master_xfer = drm_dp_i2c_xfer,
|
|
|
|
};
|
|
|
|
|
2016-06-17 16:33:17 +08:00
|
|
|
static struct drm_dp_aux *i2c_to_aux(struct i2c_adapter *i2c)
|
|
|
|
{
|
|
|
|
return container_of(i2c, struct drm_dp_aux, ddc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void lock_bus(struct i2c_adapter *i2c, unsigned int flags)
|
|
|
|
{
|
|
|
|
mutex_lock(&i2c_to_aux(i2c)->hw_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int trylock_bus(struct i2c_adapter *i2c, unsigned int flags)
|
|
|
|
{
|
|
|
|
return mutex_trylock(&i2c_to_aux(i2c)->hw_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unlock_bus(struct i2c_adapter *i2c, unsigned int flags)
|
|
|
|
{
|
|
|
|
mutex_unlock(&i2c_to_aux(i2c)->hw_mutex);
|
|
|
|
}
|
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
/**
|
2016-06-17 16:33:18 +08:00
|
|
|
* drm_dp_aux_init() - minimally initialise an aux channel
|
2013-12-12 16:57:53 +08:00
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
*
|
2016-06-17 16:33:18 +08:00
|
|
|
* If you need to use the drm_dp_aux's i2c adapter prior to registering it
|
|
|
|
* with the outside world, call drm_dp_aux_init() first. You must still
|
|
|
|
* call drm_dp_aux_register() once the connector has been registered to
|
|
|
|
* allow userspace access to the auxiliary DP channel.
|
2013-12-12 16:57:53 +08:00
|
|
|
*/
|
2016-06-17 16:33:18 +08:00
|
|
|
void drm_dp_aux_init(struct drm_dp_aux *aux)
|
2013-12-12 16:57:53 +08:00
|
|
|
{
|
2014-06-04 14:02:28 +08:00
|
|
|
mutex_init(&aux->hw_mutex);
|
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
aux->ddc.algo = &drm_dp_i2c_algo;
|
|
|
|
aux->ddc.algo_data = aux;
|
|
|
|
aux->ddc.retries = 3;
|
|
|
|
|
2016-06-17 16:33:17 +08:00
|
|
|
aux->ddc.lock_bus = lock_bus;
|
|
|
|
aux->ddc.trylock_bus = trylock_bus;
|
|
|
|
aux->ddc.unlock_bus = unlock_bus;
|
2016-06-17 16:33:18 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_aux_init);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_aux_register() - initialise and register aux channel
|
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
*
|
|
|
|
* Automatically calls drm_dp_aux_init() if this hasn't been done yet.
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_aux_register(struct drm_dp_aux *aux)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!aux->ddc.algo)
|
|
|
|
drm_dp_aux_init(aux);
|
2016-06-17 16:33:17 +08:00
|
|
|
|
2013-12-12 16:57:53 +08:00
|
|
|
aux->ddc.class = I2C_CLASS_DDC;
|
|
|
|
aux->ddc.owner = THIS_MODULE;
|
|
|
|
aux->ddc.dev.parent = aux->dev;
|
|
|
|
aux->ddc.dev.of_node = aux->dev->of_node;
|
|
|
|
|
2014-03-14 22:51:12 +08:00
|
|
|
strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
|
|
|
|
sizeof(aux->ddc.name));
|
2013-12-12 16:57:53 +08:00
|
|
|
|
2016-01-22 07:10:19 +08:00
|
|
|
ret = drm_dp_aux_register_devnode(aux);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i2c_add_adapter(&aux->ddc);
|
|
|
|
if (ret) {
|
|
|
|
drm_dp_aux_unregister_devnode(aux);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2013-12-12 16:57:53 +08:00
|
|
|
}
|
2014-06-04 14:02:28 +08:00
|
|
|
EXPORT_SYMBOL(drm_dp_aux_register);
|
2013-12-12 16:57:53 +08:00
|
|
|
|
|
|
|
/**
|
2014-06-04 14:02:28 +08:00
|
|
|
* drm_dp_aux_unregister() - unregister an AUX adapter
|
2013-12-12 16:57:53 +08:00
|
|
|
* @aux: DisplayPort AUX channel
|
|
|
|
*/
|
2014-06-04 14:02:28 +08:00
|
|
|
void drm_dp_aux_unregister(struct drm_dp_aux *aux)
|
2013-12-12 16:57:53 +08:00
|
|
|
{
|
2016-01-22 07:10:19 +08:00
|
|
|
drm_dp_aux_unregister_devnode(aux);
|
2013-12-12 16:57:53 +08:00
|
|
|
i2c_del_adapter(&aux->ddc);
|
|
|
|
}
|
2014-06-04 14:02:28 +08:00
|
|
|
EXPORT_SYMBOL(drm_dp_aux_unregister);
|
2016-05-18 16:57:29 +08:00
|
|
|
|
|
|
|
#define PSR_SETUP_TIME(x) [DP_PSR_SETUP_TIME_ ## x >> DP_PSR_SETUP_TIME_SHIFT] = (x)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* drm_dp_psr_setup_time() - PSR setup in time usec
|
|
|
|
* @psr_cap: PSR capabilities from DPCD
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* PSR setup time for the panel in microseconds, negative
|
|
|
|
* error code on failure.
|
|
|
|
*/
|
|
|
|
int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
|
|
|
|
{
|
|
|
|
static const u16 psr_setup_time_us[] = {
|
|
|
|
PSR_SETUP_TIME(330),
|
|
|
|
PSR_SETUP_TIME(275),
|
|
|
|
PSR_SETUP_TIME(165),
|
|
|
|
PSR_SETUP_TIME(110),
|
|
|
|
PSR_SETUP_TIME(55),
|
|
|
|
PSR_SETUP_TIME(0),
|
|
|
|
};
|
|
|
|
int i;
|
|
|
|
|
|
|
|
i = (psr_cap[1] & DP_PSR_SETUP_TIME_MASK) >> DP_PSR_SETUP_TIME_SHIFT;
|
|
|
|
if (i >= ARRAY_SIZE(psr_setup_time_us))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return psr_setup_time_us[i];
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(drm_dp_psr_setup_time);
|
|
|
|
|
|
|
|
#undef PSR_SETUP_TIME
|