Skip to content

GitLab

Switch branch/tag
  1. 21 Sep, 2016 1 commit
  3. 07 Sep, 2016 2 commits
  5. 23 Aug, 2016 4 commits
  7. 05 Aug, 2016 1 commit
  9. 04 Aug, 2016 1 commit
  11. 02 Aug, 2016 1 commit
  13. 07 Jul, 2016 1 commit
  15. 04 Jul, 2016 1 commit
  17. 30 Jun, 2016 1 commit
  19. 24 Jun, 2016 2 commits
  21. 19 Jun, 2016 1 commit
  23. 30 May, 2016 1 commit
  25. 05 May, 2016 1 commit
  27. 04 May, 2016 1 commit
  29. 03 May, 2016 1 commit
  31. 05 Apr, 2016 1 commit
    • Lyude's avatar
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 9e60290d
      Lyude authored 
      
After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

CC: stable@vger.kernel.org
Signed-off-by: default avatarLyude <cpaul@redhat.com>
Signed-off-by: default avatarRob Clark <rclark@redhat.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 1f771755

)
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      9e60290d
  33. 17 Mar, 2016 1 commit
    • Lyude's avatar
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 1f771755
      Lyude authored 
      
After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

	[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
	[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
	[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

CC: stable@vger.kernel.org
Signed-off-by: default avatarLyude <cpaul@redhat.com>
Signed-off-by: default avatarRob Clark <rclark@redhat.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
      1f771755
  35. 09 Mar, 2016 1 commit
  37. 11 Feb, 2016 1 commit
  39. 12 Jan, 2016 2 commits
  41. 04 Jan, 2016 1 commit
  43. 11 Dec, 2015 1 commit
  45. 10 Dec, 2015 1 commit
  47. 19 Nov, 2015 1 commit
    • Lukas Wunner's avatar
      drm/i915: Fix oops caused by fbdev initialization failure · 54632abe
      Lukas Wunner authored 
      
intelfb_create() is called once on driver initialization. If it fails,
ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be NULL.

Further up in the call stack, intel_fbdev_initial_config() calls
intel_fbdev_fini() to tear down the ifbdev on failure. This calls
intel_fbdev_destroy() which dereferences ifbdev->fb. Fix the ensuing
oops.

Also check in these functions if ifbdev is not NULL to avoid oops:

i915_gem_framebuffer_info() is called on access to debugfs file
"i915_gem_framebuffer" and dereferences ifbdev, ifbdev->helper.fb
and ifbdev->helper.fb->obj.

intel_connector_add_to_fbdev() / intel_connector_remove_from_fbdev()
are called when registering / unregistering an mst connector and
dereference ifbdev.

v3: Drop additional null pointer checks in intel_fbdev_set_suspend(),
    intel_fbdev_output_poll_changed() and intel_fbdev_restore_mode()
    since they already check if ifbdev is not NULL, which is sufficient
    now that intel_fbdev_fini() is called on initialization failure.
    (Requested by Daniel Vetter <daniel.vetter@ffwll.ch>)
Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/d05f0edf121264a9d0adb8ca713fd8cc4ae068bf.1447938059.git.lukas@wunner.de

Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      54632abe
  49. 10 Nov, 2015 1 commit
  51. 06 Oct, 2015 1 commit
  53. 02 Oct, 2015 1 commit
    • Dave Airlie's avatar
      drm/dp/mst: split connector registration into two parts (v2) · d9515c5e
      Dave Airlie authored 
      
In order to cache the EDID properly for tiled displays, we
need to retrieve it before we register the connector with
userspace, otherwise userspace can call get resources
and try and get the edid before we've even cached it.

This fixes some problems when hotplugging mst monitors,
with X/mutter running. As mutter seems to get 0 modes
for one of the monitors in the tile.

v2: fix warning in radeon
handle tile setting in cached path rather than
get edid path.
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d9515c5e
  55. 30 Sep, 2015 2 commits
  57. 08 Sep, 2015 1 commit
  59. 01 Sep, 2015 1 commit
  61. 26 Aug, 2015 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Put back lane_count into intel_dp and add link_rate too · 901c2daf
      Ville Syrjälä authored 
      With MST there won't be a crtc assigned to the main link encoder, so
trying to dig up the pipe_config from there is a recipe for an oops.

Instead store the parameters (lane_count and link_rate) in the encoder,
and use those values during link training etc. Since those parameters
are now assigned only when the link is actually enabled,
.compute_config() won't clobber them as it did before.

Hardware state readout is still bonkers though as we don't transfer the
link parameters from pipe_config intel_dp. We should do that during
encoder sanitation. But since we don't even do a proper job of reading
out the main link encoder state for MST there's littel point in
worrying about this now.

Fixes a regression with MST caused by:
 commit 90a6b7b0


 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Jul 6 16:39:15 2015 +0300

    drm/i915: Move intel_dp->lane_count into pipe_config

v2: Different apporoach that should keep intel_dp_check_mst_status()
    somewhat less oopsy

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      901c2daf
  63. 14 Aug, 2015 2 commits

Powered by Integricloud