Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 1月, 2019 1 次提交
  3. 28 11月, 2018 1 次提交
  5. 01 11月, 2018 1 次提交
  7. 19 9月, 2018 3 次提交
  9. 02 8月, 2018 1 次提交
  11. 16 7月, 2018 1 次提交
    • L
      drm/dp_helper: Add DP aux channel tracing · a18b2192
      由 Lyude Paul 提交于 
      This is something we've needed for a very long time now, as it makes
debugging issues with faulty MST hubs along with debugging issues
regarding us interfacing with hubs correctly vastly easier to debug.
Currently this can actually be done if you trace the i2c devices for DP
using ftrace but that's significantly less useful for a couple of
reasons:

- Tracing the i2c devices through ftrace means all of the traces are
  going to contain a lot of "garbage" output that we're sending over the
  i2c line. Most of this garbage comes from retrying transactions, DRM's
  helper library adding extra transactions to work around bad hubs, etc.
- Having a user set up ftrace so that they can provide debugging
  information is a lot more difficult then being able to say "just boot
  with drm.debug=0x100"
- We can potentially expand upon this tracing in the future to print
  debugging information in regards to other DP transactions like MST
  sideband transactions

This is inspired by a patch Rob Clark sent to do this a long time back.
Neither of us could find the patch however, so we both assumed it would
probably just be easier to rewrite it anyway.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180716154432.13433-1-lyude@redhat.com
      a18b2192
  13. 13 7月, 2018 1 次提交
  15. 24 5月, 2018 1 次提交
  17. 09 5月, 2018 1 次提交
  19. 26 1月, 2018 1 次提交
  21. 20 11月, 2017 1 次提交
  23. 11 10月, 2017 1 次提交
  25. 21 7月, 2017 2 次提交
  27. 29 5月, 2017 2 次提交
  29. 08 3月, 2017 1 次提交
  31. 07 3月, 2017 1 次提交
  33. 25 1月, 2017 1 次提交
  35. 19 9月, 2016 1 次提交
  37. 16 9月, 2016 1 次提交
  39. 15 9月, 2016 4 次提交
  41. 31 8月, 2016 1 次提交
  43. 17 8月, 2016 1 次提交
  45. 10 8月, 2016 2 次提交
  47. 03 8月, 2016 1 次提交
  49. 29 7月, 2016 1 次提交
    • V
      drm: aux ->transfer() can return 0, deal with it · a1f5524a
      由 Ville Syrjälä 提交于 
      Restore the correct behaviour (as in check msg.reply) when aux
->transfer() returns 0. It got removed in
commit 82922da3 ("drm/dp_helper: Retry aux transactions on all errors")

Now I can actually dump the "entire" DPCD on a Dell UP2314Q with
ddrescue. It has some offsets in the DPCD that can't be read
for some resaon, all you get is defers. Previously ddrescue would
just give up at the first unredable offset on account of
read() returning 0 means EOF. Here's the ddrescue log
for the interested:
0x00000000  0x00001400  +
0x00001400  0x00000030  -
0x00001430  0x000001D0  +
0x00001600  0x00000030  -
0x00001630  0x0001F9D0  +
0x00021000  0x00000001  -
0x00021001  0x000DEFFF  +

Cc: Lyude <cpaul@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch
Cc: stable@vger.kernel.org
Fixes: 82922da3 ("drm/dp_helper: Retry aux transactions on all errors")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      a1f5524a
  51. 17 6月, 2016 2 次提交
  53. 23 4月, 2016 3 次提交
    • L
      drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read() · f808f633
      由 Lyude 提交于 
      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.

Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.

			    Changes since v5
- If the throwaway read in drm_dp_dpcd_read() fails, return the error
  from that instead of continuing. This follows the same logic we do in
  drm_dp_dpcd_access() (e.g. the error from the first transaction may
  differ from the errors that proceeding attempts might return).
Signed-off-by: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460730335-5012-1-git-send-email-cpaul@redhat.com
      f808f633
    • L
      drm/dp_helper: Retry aux transactions on all errors · 82922da3
      由 Lyude 提交于 
      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: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
      82922da3
    • L
      drm/dp_helper: Always wait before retrying native aux transactions · e1083ff3
      由 Lyude 提交于 
      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.

Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive until they're ready.
Signed-off-by: NLyude <cpaul@redhat.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-2-git-send-email-cpaul@redhat.com
      e1083ff3
  55. 01 4月, 2016 1 次提交
  57. 12 2月, 2016 1 次提交
    • R
      drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers. · e94cb37b
      由 Rafael Antognolli 提交于 
      This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.

It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.

Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.

v2:
 - lseek is used to select the register to read/write
 - read/write are used instead of ioctl
 - no blocking_notifier is used, just a direct callback

v3:
 - use drm_dp_aux_dev prefix for public functions
 - chardev is named drm_dp_auxN
 - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
   time
 - remove notifier list from the implementation
 - option on menuconfig is now a boolean
 - add inline stub functions to avoid breakage when this option is disabled

v4:
 - fix build system changes - actually disable this module when not selected.

v5:
 - Use kref to avoid device closing while still in use
 - Don't use list, use an idr for storing aux_dev
 - Remove "connector" attribute
 - set aux.dev to the connector drm_connector device, instead of
   drm_device

v6:
 - Use atomic_t for usage count
 - Use a mutex instead of spinlock for idr lock
 - Destroy chardev immediately on unregister
 - other minor suggestions from Ville

v7:
 - style fixes
 - error handling fixes

v8:
 - more error handling fixes

v9:
 - remove module_init and module_exit, and add drm_dp_aux_dev_init/exit
 to drm_kms_helper_init/exit.
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-3-git-send-email-rafael.antognolli@intel.com
      e94cb37b