1. 31 5月, 2019 2 次提交
  2. 29 1月, 2019 1 次提交
  3. 31 12月, 2018 3 次提交
  4. 27 9月, 2018 1 次提交
  5. 19 7月, 2018 1 次提交
  6. 18 5月, 2018 1 次提交
  7. 02 5月, 2018 1 次提交
  8. 19 3月, 2018 1 次提交
  9. 20 1月, 2018 1 次提交
  10. 19 12月, 2017 1 次提交
  11. 06 12月, 2017 1 次提交
  12. 01 12月, 2017 1 次提交
  13. 21 11月, 2017 2 次提交
  14. 04 10月, 2017 1 次提交
  15. 26 9月, 2017 3 次提交
  16. 22 9月, 2017 1 次提交
  17. 17 8月, 2017 1 次提交
  18. 21 7月, 2017 2 次提交
  19. 23 6月, 2017 2 次提交
  20. 21 6月, 2017 1 次提交
  21. 15 3月, 2017 1 次提交
  22. 07 2月, 2017 2 次提交
  23. 24 11月, 2016 1 次提交
  24. 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
  25. 12 10月, 2016 1 次提交
  26. 06 8月, 2016 1 次提交
  27. 18 6月, 2016 1 次提交
    • Z
      drm/i915: gvt: Introduce the basic architecture of GVT-g · 0ad35fed
      Zhi Wang 提交于
      This patch introduces the very basic framework of GVT-g device model,
      includes basic prototypes, definitions, initialization.
      
      v12:
      - Call intel_gvt_init() in driver early initialization stage. (Chris)
      
      v8:
      - Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
      
      v7:
      - Refine the URL link in Kconfig. (Joonas)
      - Refine the introduction of GVT-g host support in Kconfig. (Joonas)
      - Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas)
      - Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas)
      	- Remove {alloc, free}_gvt_device()
      	- Rename intel_gvt_{create, destroy}_gvt_device()
      	- Expost intel_gvt_init_host()
      - Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas)
      
      v6:
      - Refine introduction in Kconfig. (Chris)
      - The exposed API functions will take struct intel_gvt * instead of
      void *. (Chris/Tvrtko)
      - Remove most memebers of strct intel_gvt_device_info. Will add them
      in the device model patches.(Chris)
      - Remove gvt_info() and gvt_err() in debug.h. (Chris)
      - Move GVT kernel parameter into i915_params. (Chris)
      - Remove include/drm/i915_gvt.h, as GVT-g will be built within i915.
      - Remove the redundant struct i915_gvt *, as the functions in i915
      will directly take struct intel_gvt *.
      - Add more comments for reviewer.
      
      v5:
      Take Tvrtko's comments:
      - Fix the misspelled words in Kconfig
      - Let functions take drm_i915_private * instead of struct drm_device *
      - Remove redundant prints/local varible initialization
      
      v3:
      Take Joonas' comments:
      - Change file name i915_gvt.* to intel_gvt.*
      - Move GVT kernel parameter into intel_gvt.c
      - Remove redundant debug macros
      - Change error handling style
      - Add introductions for some stub functions
      - Introduce drm/i915_gvt.h.
      
      Take Kevin's comments:
      - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c
      
      v2:
      - Introduce i915_gvt.c.
      It's necessary to introduce the stubs between i915 driver and GVT-g host,
      as GVT-g components is configurable in kernel config. When disabled, the
      stubs here do nothing.
      
      Take Joonas' comments:
      - Replace boolean return value with int.
      - Replace customized info/warn/debug macros with DRM macros.
      - Document all non-static functions like i915.
      - Remove empty and unused functions.
      - Replace magic number with marcos.
      - Set GVT-g in kernel config to "n" by default.
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Kevin Tian <kevin.tian@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-5-git-send-email-zhi.a.wang@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      0ad35fed
  28. 01 6月, 2016 1 次提交
    • D
      drm/i915: Revert async unpin and nonblocking atomic commit · e42aeef1
      Daniel Vetter 提交于
      This reverts the following patches:
      
      d55dbd06 drm/i915: Allow nonblocking update of pageflips.
      15c86bdb drm/i915: Check for unpin correctness.
      95c2ccdc Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
      a6747b73 drm/i915: Make unpin async.
      03f476e1 drm/i915: Prepare connectors for nonblocking checks.
      2099deff drm/i915: Pass atomic states to fbc update functions.
      ee7171af drm/i915: Remove reset_counter from intel_crtc.
      2ee004f7 drm/i915: Remove queue_flip pointer.
      b8d2afae drm/i915: Remove use_mmio_flip kernel parameter.
      8dd634d9 drm/i915: Remove cs based page flip support.
      143f73b3 drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.
      84fc494b drm/i915: Add the exclusive fence to plane_state.
      6885843a drm/i915: Convert flip_work to a list.
      aa420ddd drm/i915: Allow mmio updates on all platforms, v2.
      afee4d87 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
      
      "drm/i915: Allow nonblocking update of pageflips" should have been
      split up, misses a proper commit message and seems to cause issues in
      the legacy page_flip path as demonstrated by kms_flip.
      
      "drm/i915: Make unpin async" doesn't handle the unthrottled cursor
      updates correctly, leading to an apparent pin count leak. This is
      caught by the WARN_ON in i915_gem_object_do_pin which screams if we
      have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins.
      
      Unfortuantely we can't just revert these two because this patch series
      came with a built-in bisect breakage in the form of temporarily
      removing the unthrottled cursor update hack for legacy cursor ioctl.
      Therefore there's no other option than to revert the entire pile :(
      
      There's one tiny conflict in intel_drv.h due to other patches, nothing
      serious.
      
      Normally I'd wait a bit longer with doing a maintainer revert, but
      since the minimal set of patches we need to revert (due to the bisect
      breakage) is so big, time is running out fast. And very soon
      (especially after a few attempts at fixing issues) it'll be really
      hard to revert things cleanly.
      
      Lessons learned:
      - Not a good idea to rush the review (done by someone fairly new to
        the area) and not make sure domain experts had a chance to read it.
      
      - Patches should be properly split up. I only looked at the two
        patches that should be reverted in detail, but both look like the
        mix up different things in one patch.
      
      - Patches really should have proper commit messages. Especially when
        doing more than one thing, and especially when touching critical and
        tricky core code.
      
      - Building a patch series and r-b stamping it when it has a built-in
        bisect breakage is not a good idea.
      
      - I also think we need to stop building up technical debt by
        postponing atomic igt testcases even longer. I think it's clear that
        there's enough corner cases in this beast that we really need to
        have the testcases _before_ the next step lands.
      
      (cherry picked from commit 5a21b665
      from drm-intel-next-queeud)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
      Cc: John Harrison <John.C.Harrison@Intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e42aeef1
  29. 25 5月, 2016 1 次提交
    • D
      drm/i915: Revert async unpin and nonblocking atomic commit · 5a21b665
      Daniel Vetter 提交于
      This reverts the following patches:
      
      d55dbd06 drm/i915: Allow nonblocking update of pageflips.
      15c86bdb drm/i915: Check for unpin correctness.
      95c2ccdc Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
      a6747b73 drm/i915: Make unpin async.
      03f476e1 drm/i915: Prepare connectors for nonblocking checks.
      2099deff drm/i915: Pass atomic states to fbc update functions.
      ee7171af drm/i915: Remove reset_counter from intel_crtc.
      2ee004f7 drm/i915: Remove queue_flip pointer.
      b8d2afae drm/i915: Remove use_mmio_flip kernel parameter.
      8dd634d9 drm/i915: Remove cs based page flip support.
      143f73b3 drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.
      84fc494b drm/i915: Add the exclusive fence to plane_state.
      6885843a drm/i915: Convert flip_work to a list.
      aa420ddd drm/i915: Allow mmio updates on all platforms, v2.
      afee4d87 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
      
      "drm/i915: Allow nonblocking update of pageflips" should have been
      split up, misses a proper commit message and seems to cause issues in
      the legacy page_flip path as demonstrated by kms_flip.
      
      "drm/i915: Make unpin async" doesn't handle the unthrottled cursor
      updates correctly, leading to an apparent pin count leak. This is
      caught by the WARN_ON in i915_gem_object_do_pin which screams if we
      have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins.
      
      Unfortuantely we can't just revert these two because this patch series
      came with a built-in bisect breakage in the form of temporarily
      removing the unthrottled cursor update hack for legacy cursor ioctl.
      Therefore there's no other option than to revert the entire pile :(
      
      There's one tiny conflict in intel_drv.h due to other patches, nothing
      serious.
      
      Normally I'd wait a bit longer with doing a maintainer revert, but
      since the minimal set of patches we need to revert (due to the bisect
      breakage) is so big, time is running out fast. And very soon
      (especially after a few attempts at fixing issues) it'll be really
      hard to revert things cleanly.
      
      Lessons learned:
      - Not a good idea to rush the review (done by someone fairly new to
        the area) and not make sure domain experts had a chance to read it.
      
      - Patches should be properly split up. I only looked at the two
        patches that should be reverted in detail, but both look like the
        mix up different things in one patch.
      
      - Patches really should have proper commit messages. Especially when
        doing more than one thing, and especially when touching critical and
        tricky core code.
      
      - Building a patch series and r-b stamping it when it has a built-in
        bisect breakage is not a good idea.
      
      - I also think we need to stop building up technical debt by
        postponing atomic igt testcases even longer. I think it's clear that
        there's enough corner cases in this beast that we really need to
        have the testcases _before_ the next step lands.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
      Cc: John Harrison <John.C.Harrison@Intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      5a21b665
  30. 23 5月, 2016 1 次提交
    • D
      drm/i915/guc: add enable_guc_loading parameter · fce91f22
      Dave Gordon 提交于
      Split the function of "enable_guc_submission" into two separate
      options.  The new one ("enable_guc_loading") controls only the
      *fetching and loading* of the GuC firmware image. The existing
      one is redefined to control only the *use* of the GuC for batch
      submission once the firmware is loaded.
      
      In addition, the degree of control has been refined from a simple
      bool to an integer key, allowing several options:
      -1 (default)     whatever the platform default is
       0  DISABLE      don't load/use the GuC
       1  BEST EFFORT  try to load/use the GuC, fallback if not available
       2  REQUIRE      must load/use the GuC, else leave the GPU wedged
      
      The new platform default (as coded here) will be to attempt to
      load the GuC iff the device has a GuC that requires firmware,
      but not yet to use it for submission. A later patch will change
      to enable it if appropriate.
      
      v4:
          Changed some error-message levels, mostly ERROR->INFO, per
          review comments by Tvrtko Ursulin.
      
      v5:
          Dropped one more error message, disabled GuC submission on
          hypothetical firmware-free devices [Tvrtko Ursulin].
      
      v6:
          Logging tidy by Tvrtko Ursulin:
           * Do not log falling back to execlists when wedging the GPU.
           * Do not log fw load errors when load was disabled by user.
           * Pass down some error code from fw load for log message to
             make more sense.
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Tested-by: NFiedorowicz, Lukasz <lukasz.fiedorowicz@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> (v6)
      fce91f22
  31. 19 5月, 2016 1 次提交