1. 12 1月, 2015 1 次提交
    • I
      drm/i915: add component support · 58fddc28
      Imre Deak 提交于
      Register a component to be used to interface with the snd_hda_intel
      driver. This is meant to replace the same interface that is currently
      based on module symbol lookup.
      
      v2:
      - change roles between the hda and i915 components (Daniel)
      - add the implementation to a new file (Jani)
      - use better namespacing (Jani)
      v3:
      - move the implementation to intel_audio.c (Daniel)
      - rename display_component to audio_component (Daniel)
      - add kerneldoc (Daniel)
      v4:
      - run forgotten git rm i915_component.c (Jani)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      58fddc28
  2. 03 12月, 2014 1 次提交
    • V
      drm/i915: Grab modeset locks for GPU rest on pre-ctg · 7514747d
      Ville Syrjälä 提交于
      On gen4 and earlier the GPU reset also resets the display, so we should
      protect against concurrent modeset operations. Grab all the modeset locks
      around the entire GPU reset dance, remebering first ti dislogde any
      pending page flip to make sure we don't deadlock. Any pageflip coming
      in between these two steps should fail anyway due to reset_in_progress,
      so this should be safe.
      
      This fixes a lot of failed asserts in the modeset code when there's a
      modeset racing with the reset. Naturally the asserts aren't happy when
      the expected state has disappeared.
      
      v2: Drop UMS checks, complete pending flips after the reset (Daniel)
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7514747d
  3. 19 11月, 2014 1 次提交
    • I
      drm/i915: sanitize rps irq enabling · 3cc134e3
      Imre Deak 提交于
      Atm we first enable the RPS interrupts then we clear any pending ones.
      By this we could lose an interrupt arriving after we unmasked it. This
      may not be a problem as the caller should handle such a race, but logic
      still calls for the opposite order. Also we can delay enabling the
      interrupts until after all the RPS initialization is ready with the
      following order:
      
      1. disable left-over RPS (earlier via intel_uncore_sanitize)
      2. clear any pending RPS interrupts
      3. initialize RPS
      4. enable RPS interrupts
      
      This also allows us to do the 2. and 4. step the same way for all
      platforms, so let's follow this order to simplifying things.
      
      Also make sure any queued interrupts are also cleared.
      
      v2:
      - rebase on the GEN9 patches where we don't support RPS yet, so we
        musn't enable RPS interrupts on it (Paulo)
      v3:
      - avoid enabling RPS interrupts on GEN>9 too (Paulo)
      - clarify the RPS init sequence in the log message (Chris)
      - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
      - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
        (Paulo)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3cc134e3
  4. 18 11月, 2014 1 次提交
  5. 14 11月, 2014 6 次提交
  6. 08 11月, 2014 8 次提交
  7. 05 11月, 2014 7 次提交
  8. 24 10月, 2014 4 次提交
  9. 06 10月, 2014 1 次提交
  10. 03 10月, 2014 2 次提交
  11. 01 10月, 2014 5 次提交
  12. 24 9月, 2014 1 次提交
  13. 20 9月, 2014 1 次提交
    • D
      drm/i915: DocBook integration for frontbuffer tracking · b680c37a
      Daniel Vetter 提交于
      I shouldn't ask everyone to do this and fail myself ...
      
      This extracts all the frontbuffer tracking functions into
      intel_frontbuffer.c, adds a DOC overview section and also adds the
      missing kerneldoc for i915_gem_track_fb and also pulls it into the
      same section for convenience.
      
      v2: Don't forget about the header files.
      
      v3: Oops, might check compilation next time around. To make my life
      easier drop the increase_pllclock from set_base_atomic since really,
      it doesn't matter if you see your Oops or kgdb with a tiny bit of lag.
      
      v4: Try to better explain how to actually use this, requested by Paulo
      on irc.
      
      v5: Explain invalidate/flush a bit clearer.
      
      v6: s/business/busyness/
      Acked-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Vandana Kannan <vandana.kannan@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b680c37a
  14. 19 9月, 2014 1 次提交