Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 26 1月, 2017 1 次提交
    • M
      drm/i915: Add support for DP Video pattern compliance tests · 611032bf
      由 Manasi Navare 提交于 
      The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.
When the  test is requested with specific BPC value, we read the BPC
value from the DPCD register. If this BPC value in intel_dp structure
has a non-zero value and we're on a display port connector, then we use
the value to calculate the bpp for the pipe. Also in this case if its
a 18bpp video pattern request, then we force the dithering on pipe to be
disabled since it causes CRC mismatches.

The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.

v5:
* Remove test_result variable
* Populate the compliance test data at the end of the function (Jani Nikula)
v4:
*Return TEST_NAK on read failures and invalid values (Jani Nikula)
* Address CRC mismatch errors
v3:
* Use the updated properly shifted bit definitions (Jani Nikula)
* Force dithering to be disabled on 18bpp compliance
test request (Manasi Navare)
v2:
* Updated the DPCD Register reads based on proper defines in header (Jani Nikula)
* Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula)
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
      611032bf
  3. 05 12月, 2016 1 次提交
  5. 29 11月, 2016 1 次提交
  7. 15 11月, 2016 1 次提交
  9. 29 9月, 2016 1 次提交
  11. 22 9月, 2016 2 次提交
  13. 08 9月, 2016 2 次提交
  15. 23 8月, 2016 4 次提交
  17. 06 8月, 2016 1 次提交
  19. 04 8月, 2016 1 次提交
  21. 02 8月, 2016 1 次提交
  23. 07 7月, 2016 1 次提交
  25. 04 7月, 2016 1 次提交
  27. 30 6月, 2016 1 次提交
  29. 24 6月, 2016 2 次提交
  31. 19 6月, 2016 1 次提交
  33. 30 5月, 2016 1 次提交
  35. 05 5月, 2016 1 次提交
  37. 04 5月, 2016 2 次提交
  39. 05 4月, 2016 1 次提交
    • L
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 9e60290d
      由 Lyude 提交于 
      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: NLyude <cpaul@redhat.com>
Signed-off-by: NRob Clark <rclark@redhat.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/1458155884-13877-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 1f771755)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      9e60290d
  41. 17 3月, 2016 1 次提交
    • L
      drm/i915: Fix race condition in intel_dp_destroy_mst_connector() · 1f771755
      由 Lyude 提交于 
      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: NLyude <cpaul@redhat.com>
Signed-off-by: NRob Clark <rclark@redhat.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/1458155884-13877-1-git-send-email-cpaul@redhat.com
      1f771755
  43. 09 3月, 2016 1 次提交
  45. 11 2月, 2016 1 次提交
  47. 12 1月, 2016 2 次提交
  49. 04 1月, 2016 1 次提交
  51. 11 12月, 2015 1 次提交
  53. 10 12月, 2015 1 次提交
  55. 20 11月, 2015 1 次提交
    • L
      drm/i915: Fix oops caused by fbdev initialization failure · 54632abe
      由 Lukas Wunner 提交于 
      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: NLukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/d05f0edf121264a9d0adb8ca713fd8cc4ae068bf.1447938059.git.lukas@wunner.deSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      54632abe
  57. 11 11月, 2015 1 次提交
  59. 06 10月, 2015 1 次提交
  61. 02 10月, 2015 1 次提交
    • D
      drm/dp/mst: split connector registration into two parts (v2) · d9515c5e
      由 Dave Airlie 提交于 
      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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      d9515c5e
  63. 30 9月, 2015 1 次提交