1. 25 1月, 2017 1 次提交
  2. 20 12月, 2016 1 次提交
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · 2c7d0602
      Imre Deak 提交于
      commit 848496e5
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Jul 13 16:32:03 2016 +0300
      
          drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      
      increased the timeout to match the spec, but we still see a timeout on
      at least one SKL. A CDCLK change request following the failed one will
      succeed nevertheless.
      
      I could reproduce this problem easily by running kms_pipe_crc_basic in a
      loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
      the worst case - when the pre-emption happened right after calculating
      timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
      once which failed and so _wait_for() timed out. As opposed to this the
      spec says to keep retrying the request for at most a 3ms period.
      
      To fix this send the first request explicitly to guarantee that there is
      3ms between the first and last request. Though this matches the spec, I
      noticed that in rare cases this can still time out if we sent only a few
      requests (in the worst case 2) _and_ PCODE is busy for some reason even
      after a previous request and a 3ms delay. To work around this retry the
      polling with pre-emption disabled to maximize the number of requests.
      Also increase the timeout to 10ms to account for interrupts that could
      reduce the number of requests. With this change I couldn't trigger
      the problem.
      
      v2:
      - Use 1ms poll period instead of 10us. (Chris)
      v3:
      - Poll with pre-emption disabled to increase the number of request
        attempts. (Ville, Chris)
      - Factor out a helper to poll, it's also needed by the next patch.
      v4:
      - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
        reply is generic. (Ville)
      v5:
      - List the request specific timeout values as code comment. (Ville)
      v6:
      - Try the poll first with preemption enabled.
      - Add code comment about first request being queued by PCODE. (Art)
      - Add timeout_base_ms argument. (Ville)
      v7:
      - Clarify code comment about first queued request. (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms
      Cc: <stable@vger.kernel.org> # v4.2-
      Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
      Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit a0b8a1fe)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2c7d0602
  3. 21 11月, 2016 1 次提交
  4. 17 11月, 2016 8 次提交
  5. 16 11月, 2016 1 次提交
    • P
      drm/i915/bxt: Broxton decoupled MMIO · 85ee17eb
      Praveen Paneri 提交于
      Decoupled MMIO is an alternative way to access forcewake domain
      registers, which requires less cycles for a single read/write and
      avoids frequent software forcewake.
      This certainly gives advantage over the forcewake as this new
      mechanism “decouples” CPU cycles and allow them to complete even
      when GT is in a CPD (frequency change) or C6 state.
      
      This can co-exist with forcewake and we will continue to use forcewake
      as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords
      separately and land into funny situations.
      
      v2:
      - Moved platform check out of the function and got rid of duplicate
       functions to find out decoupled power domain (Chris)
      - Added a check for forcewake already held and skipped decoupled
       access (Chris)
      - Skipped writing 64 bit registers through decoupled MMIO (Chris)
      
      v3:
      - Improved commit message with more info on decoupled mmio (Tvrtko)
      - Changed decoupled operation to enum and used u32 instead of
       uint_32 data type for register offset (Tvrtko)
      - Moved HAS_DECOUPLED_MMIO to device info (Tvrtko)
      - Added lookup table for converting fw_engine to pd_engine (Tvrtko)
      - Improved __gen9_decoupled_read and __gen9_decoupled_write
       routines (Tvrtko)
      
      v4:
      - Fixed alignment and variable names (Chris)
      - Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang)
      
      v5:
      - Changed HAS_DECOUPLED_MMIO() argument name to dev_priv (Tvrtko)
      - Sanitize info->had_decoupled_mmio at init (Chris)
      Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
      Signed-off-by: NPraveen Paneri <praveen.paneri@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1479230360-22395-1-git-send-email-praveen.paneri@intel.com
      85ee17eb
  6. 15 11月, 2016 5 次提交
  7. 14 11月, 2016 1 次提交
    • J
      drm/i915: rename preliminary_hw_support to alpha_support · c007fb4a
      Jani Nikula 提交于
      The term "preliminary hardware support" has always caused confusion both
      among users and developers. It has always been about preliminary driver
      support for new hardware, and not so much about preliminary hardware. Of
      course, initially both the software and hardware are in early stages,
      but the distinction becomes more clear when the user picks up production
      hardware and an older kernel to go with it, with just the early support
      we had for the hardware at the time the kernel was released. The user
      has to specifically enable the alpha quality *driver* support for the
      hardware in that specific kernel version.
      
      Rename preliminary_hw_support to alpha_support to emphasize that the
      module parameter, config option, and flag are about software, not about
      hardware. Improve the language in help texts and debug logging as well.
      
      This appears to be a good time to do the change, as there are currently
      no platforms with preliminary^W alpha support.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477909108-18696-1-git-send-email-jani.nikula@intel.com
      c007fb4a
  8. 11 11月, 2016 4 次提交
  9. 08 11月, 2016 2 次提交
  10. 03 11月, 2016 1 次提交
  11. 02 11月, 2016 4 次提交
  12. 01 11月, 2016 11 次提交