lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1466528429-23136-1-git-send-email-cpaul@redhat.com>
Date:	Tue, 21 Jun 2016 13:00:24 -0400
From:	Lyude <cpaul@...hat.com>
To:	intel-gfx@...ts.freedesktop.org
Cc:	Lyude <cpaul@...hat.com>, stable@...r.kernel.org,
	Ville Syrjälä 
	<ville.syrjala@...ux.intel.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org (open list:INTEL DRM DRIVERS (excluding
	Poulsbo, Moorestow...), linux-kernel@...r.kernel.org (open list))
Subject: [PATCH v3 0/4] Fixes for HPD

This is a revised version of the patchset:

https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html

This patchset is intended to fix the issue of not having HPD when we're in
runtime suspend, or on Valleyview/Cherryview systems when we don't have any
power wells enabled. While this isn't the best for RPM, until we have the
infrastructure to provide hpd while in runtime suspend this will have to
suffice since not having HPD at all times means a user could potentially boot
their system with no displays connected, then never have any displays they
connect afterwards get detected.

Unlike the previous patchset, this patchset includes a fix for the VGA detect
loops we were seeing on Valleyview. On my setup, this fix seems to have fixed
the loop entirely. As it turns out, I think our original understanding of this
issue wasn't entirely accurate. Originally it had been assumed that the HPD
signals we were getting from the ADPA were a result of turning the power wells
on and off. As it turns out, the HPD signals actually don't get fired off until
we do the force detect on the ADPA, not when we reset it. This means this
problem can easily be solved just by temporarily disabling HPD on the ADPA
whenever we do a force detect.

As such, "drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()"
deprecates Ville's previous two fixes

Cc: stable@...r.kernel.org
Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>

Lyude (4):
  drm/i915/vlv: Make intel_crt_reset() per-encoder
  drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
  drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
  drm/i915: Enable polling when we don't have hpd

 drivers/gpu/drm/i915/i915_drv.c         |   7 +-
 drivers/gpu/drm/i915/i915_drv.h         |   6 ++
 drivers/gpu/drm/i915/intel_crt.c        |  28 ++++++--
 drivers/gpu/drm/i915/intel_drv.h        |   4 +-
 drivers/gpu/drm/i915/intel_hotplug.c    | 112 +++++++++++++++++++++++++++++---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  10 +++
 6 files changed, 150 insertions(+), 17 deletions(-)

-- 
2.5.5

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ