1. 15 6月, 2016 1 次提交
    • L
      drm/i915/ilk: Don't disable SSC source if it's in use · 1c1a24d2
      Lyude 提交于
      Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
      
      Unfortunately one of the sideaffects of having the refclk for a DPLL set
      to SSC is that as long as it's set to SSC, the GPU will prevent us from
      powering down any of the pipes or transcoders using it. A couple of
      BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
      configurations. This causes issues on the first modeset, since we don't
      expect SSC to be left on and as a result, can't successfully power down
      the pipes or the transcoders using it. Here's an example from this Dell
      OptiPlex 990:
      
      [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
      [drm:intel_modeset_init] 2 display pipes available.
      [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
      vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
      [drm:intel_crt_reset] crt adpa set to 0xf40000
      [drm:intel_dp_init_connector] Adding DP connector on port C
      [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
      [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
      [drm:ironlake_init_pch_refclk] Disabling SSC entirely
      … later we try committing the first modeset …
      [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
      [drm:intel_dump_pipe_config] cpu_transcoder: A
      …
      [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
      [drm:intel_dump_pipe_config] planes on this crtc
      [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
      [drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
      [drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
      [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
      [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
      [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
      [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
      [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
      [drm:intel_disable_pipe] disabling pipe A
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
      pipe_off wait timed out
      …
      ---[ end trace 94fc8aa03ae139e8 ]---
      [drm:intel_dp_link_down]
      [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
      
      Later modesets succeed since they reset the DPLL's configuration anyway,
      but this is enough to get stuck with a big fat warning in dmesg.
      
      A better solution would be to add refcounts for the SSC source, but for
      now leaving the source clock on should suffice.
      
      Changes since v4:
       - Fix calculation of final for systems with LVDS panels (fixes BUG() on
         CI test suite)
      Changes since v3:
       - Move temp variable into loop
       - Move checks for using_ssc_source to after we've figured out has_ck505
       - Add using_ssc_source to debug output
      Changes since v2:
       - Fix debug output for when we disable the CPU source
      Changes since v1:
       - Leave the SSC source clock on instead of just shutting it off on all
         of the DPLL configurations.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NLyude <cpaul@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
      1c1a24d2
  2. 14 6月, 2016 10 次提交
    • D
      drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission · 4d75787b
      Dave Gordon 提交于
      During a hibernate/resume cycle, the whole system is reset, including
      the GuC and the doorbell hardware. Then the system is booted up, drivers
      are loaded, etc -- the GuC firmware may be loaded and set running at
      this point. But then, the booted kernel is replaced by the hibernated
      image, and this resumed kernel will also try to reload the GuC firmware
      (which will fail). To recover, we reset the GuC and try again (which
      should work). But this GuC reset doesn't also reset the doorbell
      hardware, so it can be left in a state inconsistent with that assumed
      by the driver and/or the newly-loaded GuC firmware.
      
      It would be better if the GuC reset also cleared all doorbell state,
      but that's not how the hardware currently works; also, the driver cannot
      directly reprogram the doorbell hardware (only the GuC can do that).
      
      So this patch cycles through all doorbells, assigning and releasing each
      in turn, so that all the doorbell hardware is left in a consistent
      state, no matter how it was programmed by the previously-running kernel
      and/or GuC firmware.
      
      v2: don't use kmap_atomic() now that client page 0 is kept mapped.
      Signed-off-by: NDave Gordon <david.s.gordon@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/1465837054-16245-2-git-send-email-david.s.gordon@intel.com
      4d75787b
    • D
      drm/i915/guc: replace assign_doorbell() with select_doorbell_register() · f10d69a7
      Dave Gordon 提交于
      This version doesn't update the doorbell bitmap, as that will
      be done when the selected doorbell is associated with a client.
      
      The call is now slightly earlier, just on the general principle
      that potentially-failing operations should be done as early as
      possible, to eliminate late failures and simplify recovery.
      Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      f10d69a7
    • D
      drm/i915/guc: refactor doorbell management code · a667429b
      Dave Gordon 提交于
      This patch refactors the driver's handling and tracking of doorbells, in
      preparation for a later one which will resolve a suspend-resume issue.
      
      There are three resources to be managed:
      1. Cachelines: a single line within the client-object's page 0
         is snooped by doorbell hardware for writes from the host.
      2. Doorbell registers: each defines one cacheline to be snooped.
      3. Bitmap: tracks which doorbell registers are in use.
      
      The doorbell setup/teardown protocol starts with:
      1. Pick a cacheline: select_doorbell_cacheline()
      2. Find an available doorbell register: assign_doorbell()
      (These values are passed to the GuC via the shared context
      descriptor; this part of the sequence remains unchanged).
      
      3. Update the bitmap to reflect registers-in-use
      4. Prepare the cacheline for use by setting its status to ENABLED
      5. Ask the GuC to program the doorbell to snoop the cacheline
      
      and of course teardown is very similar:
      6. Set the cacheline to DISABLED
      7. Ask the GuC to reprogram the doorbell to stop snooping
      8. Record that the doorbell is not in use.
      
      Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and
      release_doorbell()) were called in sequence from guc_client_free(), but
      are now moved into the teardown phase of the common function.
      
      Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
      similarly done as sequential steps in guc_client_alloc(), but since it
      turns out that we don't need to be able to do them separately they're
      now collected into the setup phase of the common function.
      
      The only new code (and new capability) is the block tagged
          /* Update the GuC's idea of the doorbell ID */
      i.e. we can now *change* the doorbell register used by an existing
      client, whereas previously it was set once for the entire lifetime
      of the client. We will use this new feature in the next patch.
      
      v2: Trivial independent fixes pushed ahead as separate patches.
          MUCH longer commit message :) [Tvrtko Ursulin]
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      a667429b
    • D
      drm/i915/guc: move guc_ring_doorbell() nearer to callsite · 10d2c3e2
      Dave Gordon 提交于
      Just code movement, no actual change to the function. This is in
      preparation for the next patch, which will reorganise all the other
      doorbell code, but doesn't change this function. So let's shuffle it
      down near its caller rather than leaving it mixed in with the setup
      code. Unlike the doorbell management code, this function is somewhat
      time-critical, so putting it near its caller may even yield a tiny
      performance improvement.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      10d2c3e2
    • D
      drm/i915/guc: remove writes to GEN8_DRBREG registers · dd16107f
      Dave Gordon 提交于
      These registers are not actually writable by the CPU; only the GuC can
      actually program them. So let's not do writes that have no effect.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      dd16107f
    • D
      drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear() · 072a21cf
      Dave Gordon 提交于
      Bitmap operators are overkill when touching only one bit.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      072a21cf
    • D
      drm/i915/guc: add doorbell map to debugfs/i915_guc_info · 9636f6db
      Dave Gordon 提交于
      To properly verify the driver->doorbell->GuC functionality, validation
      needs to know how the driver has assigned the doorbell cache lines and
      registers, so make them visible through debugfs.
      
      v2: use kernel bitmap-printing format (%pb) rather than %x.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      9636f6db
    • A
      drm/i915/bxt: Add WaDisablePooledEuLoadBalancingFix · 780f0aeb
      arun.siluvery@linux.intel.com 提交于
      This is a WA affecting pooled eu which is a bxt specific feature.
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Cc: Winiarski, Michal <michal.winiarski@intel.com>
      Cc: Zou, Nanhai <nanhai.zou@intel.com>
      Cc: Yang, Rong R <rong.r.yang@intel.com>
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      780f0aeb
    • A
      drm/i915/bxt: Add WaEnablePooledEuFor2x6 · e015dd69
      arun.siluvery@linux.intel.com 提交于
      Pooled EU is enabled by default for BXT but for fused down 2x6 parts it is
      advised to turn it off. But there is another HW issue in these parts (fused
      down 2x6 parts) before C0 that requires Pooled EU to be enabled as a
      workaround. In this case the pool configuration changes depending upon
      which subslice is disabled. This doesn't affect if the device has all 3
      subslices enabled.
      
      Userspace need to know min no. of eus in a pool as it varies based on which
      subslice is disabled, this is not yet exported because userspace support is
      not available yet. Once the support is available this needs to be exported
      using getparam ioctls.
      
      v2: s/subslice_total/subslice_per_slice as it is a more logical field (Mika)
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Cc: Winiarski, Michal <michal.winiarski@intel.com>
      Cc: Zou, Nanhai <nanhai.zou@intel.com>
      Cc: Yang, Rong R <rong.r.yang@intel.com>
      Cc: Tim Gore <tim.gore@intel.com>
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      e015dd69
    • A
      drm/i915:bxt: Enable Pooled EU support · 33e141ed
      arun.siluvery@linux.intel.com 提交于
      This mode allows to assign EUs to pools which can process work collectively.
      The command to enable this mode should be issued as part of context initialization.
      
      The pooled mode is global, once enabled it has to stay the same across all
      contexts until HW reset hence this is sent in auxiliary golden context batch.
      Thanks to Mika for the preliminary review and comments.
      
      v2: explain why this is enabled in golden context, use feature flag while
      enabling the support (Chris)
      
      v3: Include only kernel support as userspace support is not available yet.
      
      User space clients need to know when the pooled EU feature is present
      and enabled on the hardware so that they can adapt work submissions.
      Create a new device info flag for this purpose.
      
      Set has_pooled_eu to true in the Broxton static device info - Broxton
      supports the feature in hardware and the driver will enable it by
      default.
      
      We need to add getparam ioctls to enable userspace to query availability of
      this feature and to retrieve min. no of eus in a pool but we will expose
      them once userspace support is available. Opensource users for this feature
      are mesa, libva and beignet.
      
      Beignet team is currently working on adding userspace support.
      
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Cc: Winiarski, Michal <michal.winiarski@intel.com>
      Cc: Zou, Nanhai <nanhai.zou@intel.com>
      Cc: Yang, Rong R <rong.r.yang@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Armin Reese <armin.c.reese@intel.com>
      Cc: Tim Gore <tim.gore@intel.com>
      Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      33e141ed
  3. 13 6月, 2016 17 次提交
  4. 10 6月, 2016 1 次提交
  5. 08 6月, 2016 11 次提交