1. 26 Sep, 2012 2 commits
    • Ben Widawsky's avatar
      drm/i915: s/cacheing/caching/ · 199adf40
      Ben Widawsky authored
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Paulo Zanoni's avatar
      drm/i915: make sure we write all the DIP data bytes · adf00b26
      Paulo Zanoni authored
      ... even if the actual infoframe is smaller than the maximum possible
      If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
      be correctly calculated in some cases (e.g., when changing the port),
      and this will lead to black screens on HDMI monitors. The ECC value is
      generated by the hardware.
      I don't see how this should break anything since we're writing 0 and
      that should be the correct value, so this patch should be safe.
      Notice that on IVB and older we actually have 64 bytes available for
      VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
      others are either read-only ECC values or marked as "reserved". On HSW
      we only have 32 bytes, and the ECC value is stored on its own separate
      read-only register. See BSpec.
      This patch fixes bug #46761, which is marked as a regression
      introduced by commit 4e89ee17:
          drm/i915: set the DIP port on ibx_write_infoframe
      Before commit 4e89 we were just failing to send AVI infoframes when we
      needed to change the port, which can lead to black screens in some
      cases. After commit 4e89 we started sending infoframes, but with a
      possibly wrong ECC value. After this patch I hope we start sending
      correct infoframes.
      Version 2:
        - Improve commit message
        - Try to make the code more clear
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
  2. 24 Sep, 2012 1 commit
  3. 20 Sep, 2012 33 commits
  4. 17 Sep, 2012 4 commits
    • Daniel Vetter's avatar
      drm/i915: fix OOPS in lid_notify · 3b7a89fc
      Daniel Vetter authored
      This goes back to
      commit c1c7af60
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Sep 10 15:28:03 2009 -0700
          drm/i915: force mode set at lid open time
      It was used to fix an issue on a i915GM based Thinkpad X41, which
      somehow clobbered the modeset state at lid close time. Since then
      massive amounts of things changed: Tons of fixes to the modeset
      sequence, OpRegion support, better integration with the acpi code.
      Especially OpRegion /should/ allow us to control the display hw
      cooperatively with the firmware, without the firmware clobbering the
      hw state behind our backs.
      So it's dubious whether we still need this.
      The second issue is that it's unclear who's responsibility it actually
      is to restore the mode - Chris Wilson suggests to just emit a hotplug
      event and let userspace figure things out.
      The real reason I've stumbled over this is that the new modeset code
      breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc
      pointer. The reason this wasn't caught in testing earlier is that in
      commit c9354c85
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Mon Nov 2 09:29:55 2009 -0800
          i915: fix intel graphics suspend breakage due to resume/lid event
      logic was added to _not_ restore the modeset state after a resume. And
      since most machines are configured to auto-suspend on lid-close, this
      neatly papered over the issue.
      Summarizing, this shouldn't be required on any platform supporting
      OpRegion. And none of the really old machines I have here seem to
      require it either. Hence I'm inclined to just rip it out.
      But in case that there are really firmwares out there that clobber the
      hw state, replace it with a call to intel_modset_check_state. This
      will ensure that we catch any issues as soon as they happen.
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Daniel Vetter's avatar
      drm/i915: correctly update crtc->x/y in set_base · 6c4c86f5
      Daniel Vetter authored
      While reworking the modeset sequence, this got lost in
      commit 25c5b266
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun Jul 8 22:08:04 2012 +0200
          drm/i915: implement new set_mode code flow
      I've noticed this because some Xorg versions seem to set up a new mode
      with every crtc at (0,0) and then pan to the right multi-monitor
      setup. And since some hacks of mine added more calls to mode_set using
      the stored crtc->x/y my multi-screen setup blew up.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Wang Xingchao's avatar
      drm/i915: HDMI - Clear Audio Enable bit for Hot Plug · b98b6016
      Wang Xingchao authored
      Clear Audio Enable bit to trigger unsolicated event to notify Audio
      Driver part the HDMI hot plug change. The patch fixed the bug when
      remove HDMI cable the bit was not cleared correctly.
      In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
      be set to trigger unsolicated event to notify Alsa driver the change.
      intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
      remove the hdmi cable, here's debug log:
      [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
      [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
      so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
      cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
      This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
      [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
      [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
      Signed-off-by: default avatarWang Xingchao <xingchao.wang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    • Chris Wilson's avatar
      drm/i915: Reduce a pin-leak BUG into a WARN · 7e81a42e
      Chris Wilson authored
      Pin-leaks persist and we get the perennial bug reports of machine
      lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that
      the object cannot be pinned at that time it should prevent the driver from
      locking up, and hopefully restore a semblance of working whilst still
      leaving us a OOPS to debug.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>