1. 27 Jun, 2012 1 commit
  2. 22 Jun, 2012 2 commits
    • Takashi Iwai's avatar
      drm/i915: Fix eDP blank screen after S3 resume on HP desktops · 6db65cbb
      Takashi Iwai authored
      This patch fixes the problem on some HP desktop machines with eDP
      which give blank screens after S3 resume.
      
      It turned out that BLC_PWM_CPU_CTL must be written after
      BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
      SNB machines.
      
      Tested with 3.5-rc3 kernel.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6db65cbb
    • Daniel Vetter's avatar
      drm/i915: rip out the PM_IIR WARN · 58bf8062
      Daniel Vetter authored
      After banging my head against this for the past few months, I still
      don't see how this could possible race under the premise that once an
      irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again
      until we unmask it in PM_IMR.
      
      Still, we have reports of this being seen in the wild. Now Bspec has
      this little bit of lovely language in the PMIIR register:
      
      Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR":
      
      "For each bit, the IIR can store a second pending interrupt if two or
      more of the same interrupt conditions occur before the first condition
      is cleared. Upon clearing the interrupt, the IIR bit will momentarily
      go low, then return high to indicate there is another interrupt
      pending."
      
      Now if we presume that PMIMR only prevent new interrupts from being
      queued, we could easily end up masking an interrupt and clearing it,
      but the 2nd pending interrupt setting the bit in PMIIR right away
      again. Which leads, the next time the irq handler runs, to hitting the
      WARN.
      
      Also, no bad side effects of this have ever been reported. And we've
      tracked down our issues with the gpu turbo getting stuck to bogus
      interrupt generation limits in th RPLIMIT register.
      
      So let's just rip out this WARN as bogus and call it a day. The only
      shallow thing here is that this 2-deep irq queue in the hw makes you
      wonder how racy the windows irq handler is ...
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907
      Cc: stable@vger.kernel.org
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      58bf8062
  3. 21 Jun, 2012 10 commits
  4. 20 Jun, 2012 27 commits