An error occurred fetching the project authors.
  1. 18 Mar, 2015 5 commits
  2. 26 Jan, 2015 5 commits
    • Rodrigo Vivi's avatar
      drm/i915: BDW Fix Halo PCI IDs marked as ULT. · 6b96d705
      Rodrigo Vivi authored
      BDW with PCI-IDs ended in "2" aren't ULT, but HALO.
      Let's fix it and at least allow VGA to work on this units.
      
      v2: forgot ammend and v1 doesn't compile
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87220
      Cc: Xion Zhang <xiong.y.zhang@intel.com>
      Cc: Guo Jinxian <jinxianx.guo@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      6b96d705
    • Rodrigo Vivi's avatar
      drm/i915: Fix and clean BDW PCH identification · a35cc9d0
      Rodrigo Vivi authored
      It seems in the past we have BDW with PCH not been propperly identified
      and we force it to be LPT and we were warning !IS_HASWELL on propper identification.
      
      Now that products are out there we are receiveing logs with this incorrect WARN.
      And also according to local tests on all production BDW here ULT or HALO we don't
      need this force anymore. So let's clean this block for real.
      
      v2: Fix LPT_LP WARNs to avoid wrong warns on BDW_ULT (By Jani).
      
      Reference: https://bugs.freedesktop.org/attachment.cgi?id=110972
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Xion Zhang <xiong.y.zhang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      a35cc9d0
    • Bob Paauwe's avatar
      drm/i915: Only fence tiled region of object. · af1a7301
      Bob Paauwe authored
      When creating a fence for a tiled object, only fence the area that
      makes up the actual tiles.  The object may be larger than the tiled
      area and if we allow those extra addresses to be fenced, they'll
      get converted to addresses beyond where the object is mapped. This
      opens up the possiblity of writes beyond the end of object.
      
      To prevent this, we adjust the size of the fence to only encompass
      the area that makes up the actual tiles.  The extra space is considered
      un-tiled and now behaves as if it was a linear object.
      
      Testcase: igt/gem_tiled_fence_overflow
      Reported-by: default avatarDan Hettena <danh@ghs.com>
      Signed-off-by: default avatarBob Paauwe <bob.j.paauwe@intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      af1a7301
    • Jeremiah Mahler's avatar
      drm/i915: fix inconsistent brightness after resume · 13f3fbe8
      Jeremiah Mahler authored
      commit 6dda730e
      Author: Jani Nikula <jani.nikula@intel.com>
      Date:   Tue Jun 24 18:27:40 2014 +0300
      
          drm/i915: respect the VBT minimum backlight brightness
      
      introduced a bug which resulted in inconsistent brightness levels on
      different machines. If a suspended was entered with the screen off some
      machines would resume with the screen at minimum brightness and others
      at maximum brightness.
      
      The following commands can be used to produce this behavior.
      
        xset dpms force off
        sleep 1
        sudo systemctl suspend
        (resume ...)
      
      The root cause of this problem is a comparison which checks to see if
      the backlight level is zero when the panel is enabled.  If it is zero,
      it is set to the maximum level.  Unfortunately, not all machines have a
      minimum level of zero. On those machines the level is left at the
      minimum instead of begin set to the maximum.
      
      Fix the bug by updating the comparison to check for the minimum
      backlight level instead of zero.  Also, expand the comparison for
      the possible case when the level is less than the minimum.
      
      Fixes: 6dda730e ("respect the VBT minimum backlight brightness")
      Signed-off-by: default avatarJeremiah Mahler <jmmahler@gmail.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      13f3fbe8
    • David Woodhouse's avatar
      drm/i915: Init PPGTT before context enable · f48a0165
      David Woodhouse authored
      Commit 82460d97 ("drm/i915: Rework ppgtt init to no require an aliasing
      ppgtt") introduced a regression on Broadwell, triggering the following
      IOMMU fault at startup:
      
        vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
        dmar: DRHD: handling fault status reg 2
        dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 880000
        DMAR:[fault reason 23] Unknown
        fbcon: inteldrmfb (fb0) is primary device
      
      Further commentary from Daniel:
      
      I sugggested this change to David after staring at the offending patch
      for a while. I have no idea and theory whatsoever why this would upset
      the gpu less than the other way round. But it seems to work. David
      promised to chase hw people a bit more to get a more meaningful answer.
      
      Wrt the comment that this deletes: I've done some digging and afaict
      loading context before ppgtt enable was once required before our recent
      restructuring of the context/ppgtt init code: Before that context sw
      setup (i.e. allocating the default context) and hw setup was smashed
      together.  Also the setup of the default context was the bit that
      actually allocated the aliasing ppgtt structures. Which is the reason
      for the context before ppgtt depency.
      
      Or was, since with all the untangling there's no no real depency any
      more (functional, who knows what the hw is doing), so the comment is
      just stale.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      f48a0165
  3. 12 Jan, 2015 5 commits
  4. 24 Dec, 2014 1 commit
  5. 18 Dec, 2014 4 commits
    • Imre Deak's avatar
      drm/i915: add missing rpm ref to i915_gem_pwrite_ioctl · 5d77d9c5
      Imre Deak authored
      Without this RPM ref we can hit the device suspended WARN via:
      i915_gem_object_pin()->ggtt_bind_vma->gen6_ggtt_insert_entries(). I
      noticed this on my BYT while keeping the i915 device in runtime
      suspended state for a while. I chose this place to take the ref to
      avoid the possible deadlock via the mutex_lock taken both later in this
      function and in the runtime suspend handler. This can happen if an RPM
      suspend event is queued and need to be flushed before taking the RPM
      ref.
      
      Testcase: igt/pm_rpm/gem-evict-pwrite
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87363Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5d77d9c5
    • Ville Syrjälä's avatar
      Revert "drm/i915: Preserve VGACNTR bits from the BIOS" · 01f5a626
      Ville Syrjälä authored
      The VGA_2X_MODE bit apparently affects the display even when the VGA
      plane is disabled. The bit will set by the BIOS when the panel width
      is at least 1280 pixels. So by preserving the bit from the BIOS we
      end up with corrupted display on machines with such high res panels.
      I only have 1024x768 panels on my gen2 machines so never ran into
      this problem.
      
      The original reason for preserving the VGACNTR register was to make
      my 830 survive S3 with acpi_sleep=s3_bios option. However after
      further 830 fixes that option is no longer needed to make S3 work
      and preserving VGACNTR doesn't seem to be necessary without it,
      so we can just revert the entire patch.
      
      This reverts
      commit 69769f9a
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Fri Aug 15 01:22:08 2014 +0300
      
          drm/i915: Preserve VGACNTR bits from the BIOS
      
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      01f5a626
    • Ville Syrjälä's avatar
      drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4 · 7d47559e
      Ville Syrjälä authored
      The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That
      means if we first call intel_prepare_page_flip() but don't call
      intel_finish_page_flip(), the next stall check will erroneosly think
      the page flip was somehow stuck.
      
      With enough debug spew emitted from the interrupt handler my 830 hangs
      when this happens. My theory is that the previous vblank interrupt gets
      sufficiently delayed that the handler will see the pending bit set in
      IIR, but ISR still has the bit set as well (ie. the flip was processed
      by CS but didn't complete yet). In this case the handler will proceed
      to call intel_check_page_flip() immediately after
      intel_prepare_page_flip(). It then tries to print a backtrace for the
      stuck flip WARN, which apparetly results in way too much debug spew
      delaying interrupt processing further. That then seems to cause an
      endless loop in the interrupt handler, and the machine is dead until
      the watchdog kicks in and reboots. At least limiting the number of
      iterations of the loop in the interrupt handler also prevented the
      hang.
      
      So it seems better to not call intel_prepare_page_flip() without
      immediately calling intel_finish_page_flip(). The IIR/ISR trickery
      avoids races here so this is a perfectly safe thing to do.
      
      v2: Fix typo in commit message (checkpatch)
      
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      7d47559e
    • Ville Syrjälä's avatar
      drm/i915: Kill check_power_well() calls · 7f1241ed
      Ville Syrjälä authored
      pps_{lock,unlock}() call intel_display_power_{get,put}() outside
      pps_mutes to avoid deadlocks with the power_domain mutex. In theory
      during aux transfers we should usually have the relevant power domain
      references already held by some higher level code, so this should not
      result in much overhead (exception being userspace i2c-dev access).
      However thanks to the check_power_well() calls in
      intel_display_power_{get/put}() we end up doing a few Punit reads for
      each aux transfer. Obviously doing this for each byte transferred via
      i2c-over-aux is not a good idea.
      
      I can't think of a good way to keep check_power_well() while eliminating
      the overhead, so let's just remove check_power_well() entirely.
      
      Fixes a driver init time regression introduced by:
       commit 773538e8
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Thu Sep 4 14:54:56 2014 +0300
      
          drm/i915: Reset power sequencer pipe tracking when disp2d is off
      
      Credit goes to Jani for figuring this out.
      
      v2: Add the regression note in the commit message.
      
      Cc: stable@vger.kernel.org (v3.18+)
      Cc: Egbert Eich <eich@suse.de>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201Tested-by: default avatarWendy Wang <wendy.wang@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      7f1241ed
  6. 16 Dec, 2014 3 commits
    • Chris Wilson's avatar
      drm/i915: Disable PSMI sleep messages on all rings around context switches · 2c550183
      Chris Wilson authored
      There exists a current workaround to prevent a hang on context switch
      should the ring go to sleep in the middle of the restore,
      WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
      spite of disabling arbitration (which prevents the ring from powering
      down during the critical section) we were still hitting hangs that had
      the hallmarks of the known erratum. That is we are still seeing hangs
      "on the last instruction in the context restore". By comparing -nightly
      (broken) with requests (working), we were able to deduce that it was the
      semaphore LRI cross-talk that reproduced the original failure. The key
      was that requests implemented deferred semaphore signalling, and
      disabling that, i.e. emitting the semaphore signal to every other ring
      after every batch restored the frequent hang.  Explicitly disabling PSMI
      sleep on the RCS ring was insufficient, all the rings had to be awake to
      prevent the hangs. Fortunately, we can reduce the wakelock to the
      MI_SET_CONTEXT operation itself, and so should be able to limit the extra
      power implications.
      
      Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
      products, we should apply this extra hammer for all of the same
      platforms despite so far that we have only been able to reproduce the
      hang on certain ivb and hsw models. The last question is whether we want
      to always use the extra hammer or only when we know semaphores are in
      operation. At the moment, we only use LRI on non-RCS rings for
      semaphores, but that may change in the future with the possibility of
      reintroducing this bug under subtle conditions.
      
      v2: Make it explicit that the PSMI LRI are an extension to the original
      workaround for the other rings.
      v3: Bikeshedding variable names and whitespacing
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
      Cc: Simon Farnsworth <simon@farnz.org.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarPeter Frühberger <fritsch@xbmc.org>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      2c550183
    • Chris Wilson's avatar
      drm/i915: Force the CS stall for invalidate flushes · add284a3
      Chris Wilson authored
      In order to act as a full command barrier by itself, we need to tell the
      pipecontrol to actually stall the command streamer while the flush runs.
      We require the full command barrier before operations like
      MI_SET_CONTEXT, which currently rely on a prior invalidate flush.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=83677
      Cc: Simon Farnsworth <simon@farnz.org.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      add284a3
    • Chris Wilson's avatar
      drm/i915: Invalidate media caches on gen7 · 148b83d0
      Chris Wilson authored
      In the gen7 pipe control there is an extra bit to flush the media
      caches, so let's set it during cache invalidation flushes.
      
      v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec.
      
      Cc: Simon Farnsworth <simon@farnz.org.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      148b83d0
  7. 15 Dec, 2014 2 commits
    • Imre Deak's avatar
      drm/i915: sanitize RPS resetting during GPU reset · dbea3cea
      Imre Deak authored
      Atm, we don't disable RPS interrupts and related work items before
      resetting the GPU. This may interfere with the following GPU
      initialization and cause RPS interrupts to show up in PM_IIR too early
      before calling gen6_enable_rps_interrupts() (triggering a WARN there).
      
      Solve this by disabling RPS interrupts and flushing any related work
      items before resetting the GPU.
      
      v2:
      - split out the common parts of the gt suspend and the new gt reset
        functions (Paulo)
      v3:
      - remove the check for UMS, it's a NOP nowadays (Daniel)
      Reported-by: default avatarHe, Shuang <shuang.he@intel.com>
      Testcase: igt/gem_reset_stats/ban-render
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      dbea3cea
    • Imre Deak's avatar
      drm/i915: move RPS PM_IER enabling to gen6_enable_rps_interrupts · 78e68d36
      Imre Deak authored
      Paulo noticed that we don't enable RPS interrupts via PM_IER in
      gen6_enable_rps_interrupts(). This wasn't a problem so far, since the
      only place we disabled RPS interrupts was during system/runtime suspend
      and after that we reenable all interrupts in the IRQ pre/postinstall
      hooks.
      
      In the next patch we'll disable/reenable RPS interrupts during GPU reset
      too, but not call IRQ uninstall, pre/postinstall hooks, so there the
      above wouldn't work. The logical place for programming PM_IER is
      gen6_enable_rps_interrupts() and this also makes the function more
      symmetric with gen6_disable_rps_interrupts(), so move the programming
      there from the postinstall hooks.
      
      Note that these changes don't affect the ILK RPS interrupt code, which
      could be sanitized in a similar way. But that can be done as a
      follow-up.
      
      Credits-to: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      78e68d36
  8. 11 Dec, 2014 2 commits
    • Imre Deak's avatar
      drm/i915: vlv: fix IRQ masking when uninstalling interrupts · c352d1ba
      Imre Deak authored
      irq_mask should include all IRQ bits that we want to mask, but atm we
      set it incorrectly to the inverse of this. If the mask is used
      subsequently to enable/disable some IRQ bits, we may unintentionally
      unmask unrelated IRQs. I can't see any way that this can lead to a real
      problem in the current -nightly code, since the first place the mask
      will be used next (after a suspend/resume cycle) is in
      valleyview_irq_postinstall(), but the mask is reset there to its proper
      value.
      
      This causes a problem in the upstream kernel though, where - due to another
      issue - the mask is used in the above way to disable only the display IRQs.
      This other issue is fixed by:
      
      commit 950eabaf
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Mon Sep 8 15:21:09 2014 +0300
      
          drm/i915: vlv: fix display IRQ enable/disable
      
      Interestingly, even with the above two bugs, we shouldn't in theory have
      any real problems (arguably a famous last sentence:). That's because
      even if we unmask something unintentionally via the VLV_IMR/VLV_IER
      register the master IRQ masking bit in VLV_MASTER_IER is still set and
      should prevent all i915 interrupts. According to my testing on an ASUS
      T100 with DSI output this isn't the case at least with the
      MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
      VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
      shown in the bugzilla ticket below. This fix should get rid of the
      problem reported there in upstream and older kernels.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920
      Cc: stable@vger.kernel.org (v3.15+)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      c352d1ba
    • Jesse Barnes's avatar
      drm/i915: save/restore GMBUS freq across suspend/resume on gen4 · 9f49c376
      Jesse Barnes authored
      Should probably just init this in the GMbus code all the time, based on
      the cdclk and HPLL like we do on newer platforms.  Ville has code for
      that in a rework branch, but until then we can fix this bug fairly
      easily.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarNikolay <mar.kolya@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      9f49c376
  9. 10 Dec, 2014 4 commits
  10. 08 Dec, 2014 4 commits
  11. 05 Dec, 2014 3 commits
  12. 03 Dec, 2014 2 commits
    • Ville Syrjälä's avatar
      drm/i915: Reject modeset when the same digital port is used more than once · 00f0b378
      Ville Syrjälä authored
      On pre-HSW we have two encoders per digital port: one HDMI, one DP.
      However they are the same physical port in hardware and we can't enable
      both at the same time. Reject the modeset if the user attempts this.
      
      So far we've been saved by the fact that we never see both HDMI and DP
      connectors as connected. But if the user decides to force a mode anyway,
      all kinds of funny stuff might happen.
      
      Unfortunately we don't seem to have any way to inform userspace that
      such configurations are invalid except by returning an error from
      setcrtc. possible_clones only covers real cloning situations, and
      looking at the connector names doesn't work either since we don't
      always register both connectors for the same port. I suppose the
      only way to fix that would be to expose only a single encoder per
      digital port like we do on HSW+ but that would be a fairly large
      undertaking for little gain.
      
      kms_setmode hits this since it forces modes on non-connected VGA and
      HDMI connectors. Previosuly it just resulted in weirdness such as
      failed link training. With this patch it will now get an error back
      from the kernel and will die with an assert since it thinks that the
      configuration should be fine.
      
      v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo)
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      00f0b378
    • Imre Deak's avatar
      drm/i915: mask RPS IRQs properly when disabling RPS · 9939fba2
      Imre Deak authored
      Atm, igt/gem_reset_stats can trigger the recently added WARN on
      left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two
      reasons for this:
      1. we call intel_enable_gt_powersave() without a preceeding
         intel_disable_gt_powersave()
      2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR
      
      1. means RPS interrupts will remain enabled and can be serviced during
      the HW initialization after a GPU reset. 2. means even if we called
      gen6_disable_rps_interrupts() any new RPS interrupt during RPS
      initialization would still propagate to PM_IIR too early (though
      wouldn't be serviced).
      
      This patch solves the 2. issue by also masking interrupts in PM_IMR, the
      following patch fixes 1. getting rid of the WARN. This also makes
      intel_enable_gt_powersave() and intel_disable_gt_powersave() more
      symmetric.
      
      Since gen6_disable_rps_interrupts() is called during driver loading with
      i915 interrupts disabled add a new version of gen6_disable_pm_irq() that
      doesn't WARN for this.
      
      Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR
      programming sequence and make sure that any queued PM_IIR bit is also
      cleared.
      
      The WARN was caught by PRTS after I sent my previous RPS sanitizing
      patchset and I could easily reproduce it on HSW. To actually fix it we
      also need the next patch.
      Reported-by: default avatarHe, Shuang <shuang.he@intel.com>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9939fba2