1. 18 6月, 2016 6 次提交
    • Z
      drm/i915: Introduce GVT context creation API · c8c35799
      Zhi Wang 提交于
      GVT workload scheduler needs special host LRC contexts, the so called
      "shadow LRC context" to submit guest workload to host i915. During the
      guest workload submission, workload scheduler fills the shadow LRC
      context with the content of guest LRC context: engine context is copied
      without changes, ring context is mostly owned by host i915.
      
      v8:
      
      - Remove the graph temporarily. (Chris)
      - Use interruptible mutex_lock. (Chris)
      - Rename the function name of creating a GVT context. (Chris)
      - Add the missing declaration in i915_drv.h (Chris)
      
      v7:
      
      - Move chart to a better place. (Joonas)
      
      v6:
      
      - Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
      
      v5:
      - Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko)
      - Rebase the code into new repo.
      - Add a comment about the ring buffer size. (Joonas)
      
      v2:
      
      Mostly based on Daniel's idea. Call the refactored core logic of GEM
      context creation service and LRC context creation service to create the GVT
      context.
      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>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-10-git-send-email-zhi.a.wang@intel.com
      c8c35799
    • Z
      drm/i915: Support LRC context single submission · 80a9a8db
      Zhi Wang 提交于
      This patch introduces the support of LRC context single submission.
      As GVT context may come from different guests, which require different
      configuration of render registers. It can't be combined into a dual ELSP
      submission combo.
      
      Only GVT-g will create this kinds of GEM context currently.
      
      v8:
      
      - Rename the data member in struct i915_gem_context. (Chris)
      
      v7:
      
      - Fix typos in commit message. (Joonas)
      
      v6:
      - Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
      
      v5:
      
      - Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko)
      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>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-9-git-send-email-zhi.a.wang@intel.com
      80a9a8db
    • Z
      drm/i915: Introduce execlist context status change notification · 3c7ba635
      Zhi Wang 提交于
      This patch introduces an approach to track the execlist context status
      change.
      
      GVT-g uses GVT context as the "shadow context". The content inside GVT
      context will be copied back to guest after the context is idle. And GVT-g
      has to know the status of the execlist context.
      
      This function is configurable when creating a new GEM context. Currently,
      Only GVT-g will create the "status-change-notification" enabled GEM
      context.
      
      v10:
      
      - Fix the identation. (Joonas)
      
      v8:
      
      - Remove the boolean flag in struct i915_gem_context. (Joonas)
      
      v7:
      
      - Remove per-engine ctx status notifiers. Use one status notifier for all
      engines. (Joonas)
      - Add prefix "INTEL_" for related definitions. (Joonas)
      - Refine the comments in execlists_context_status_change(). (Joonas)
      
      v6:
      
      - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
      could automatically eliminate them for us. (Chris)
      - Always initialize the notifier header, so it could be switched on/off
      at runtime. (Chris)
      
      v5:
      
      - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)
      
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v8)
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-8-git-send-email-zhi.a.wang@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      3c7ba635
    • Z
      drm/i915: Make addressing mode bits in context descriptor configurable · c01fc532
      Zhi Wang 提交于
      Currently the addressing mode bit in context descriptor is statically
      generated from the configuration of system-wide PPGTT usage model.
      
      GVT-g will load the PPGTT shadow page table by itself and probably one
      guest is using a different addressing mode with i915 host. The addressing
      mode bits of a LRC context should be configurable under this case.
      
      v10:
      
      - Fix the identation. (Joonas)
      
      v9:
      - Rename the data member in struct i915_gem_context. (Chris)
      
      v8:
      - Rename the data member in struct i915_gem_context. (Chris)
      
      v7:
      - Move context addressing mode bit into i915_reg.h. (Joonas/Chris)
      - Add prefix "INTEL_" for related definitions. (Joonas)
      
      v6:
      - Directly save the addressing mode bits inside i915_gem_context. (Chris)
      - Move the LRC context addressing mode bits into intel_lrc.h. (Chris)
      
      v5:
      - Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko)
      
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9)
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-7-git-send-email-zhi.a.wang@intel.com
      c01fc532
    • Z
      drm/i915: Make ring buffer size of a LRC context configurable · bcd794c2
      Zhi Wang 提交于
      This patch introduces an option for configuring the ring buffer size
      of a LRC context after the context creation.
      
      v9:
      - Fix an identation issue. (Chris)
      
      v8:
      - Rename the data member in i915_gem_context. (Chris)
      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>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-6-git-send-email-zhi.a.wang@intel.com
      bcd794c2
    • 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
  2. 14 6月, 2016 1 次提交
    • 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 1 次提交
  4. 08 6月, 2016 2 次提交
  5. 07 6月, 2016 1 次提交
  6. 06 6月, 2016 1 次提交
  7. 01 6月, 2016 2 次提交
    • 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
    • S
      drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled · 1800ad25
      Sagar Arun Kamble 提交于
      On Loading, GuC sets PM interrupts routing (bit 31) and clears ARAT
      expired interrupt (bit 9). Host turbo also updates this register
      in RPS flows. This patch ensures bit 31 and bit 9 setup by GuC persists.
      ARAT timer interrupt is needed in GuC for various features. It also
      facilitates halting GuC and hence achieving RC6. PM interrupt routing
      will not impact RPS interrupt reception by host as GuC will redirect
      them.
      This patch fixes igt test pm_rc6_residency that was failing with guc
      load/submission enabled. Tested with SKL GuC v6.1 and BXT GuC v5.1 and v8.7.
      
      v2: i915_irq/i915_pm decoupling from intel_guc. (ChrisW)
      
      v3: restructuring the mask update and rebase w.r.t Ville's patch. (ChrisW)
      
      v4: Updating the pm_intr_keep during direct_interrupts_to_guc. (Sagar)
      
      Cc: Chris Harris <chris.harris@intel.com>
      Cc: Zhe Wang <zhe1.wang@intel.com>
      Cc: Deepak S <deepak.s@intel.com>
      Cc: Satyanantha, Rama Gopal M <rama.gopal.m.satyanantha@intel.com>
      Cc: Akash Goel <akash.goel@intel.com>
      Testcase: igt/pm_rc6_residency
      Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
      Tested-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1464683307-19475-1-git-send-email-sagar.a.kamble@intel.com
      1800ad25
  8. 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
  9. 24 5月, 2016 11 次提交
  10. 23 5月, 2016 5 次提交
  11. 20 5月, 2016 3 次提交
  12. 19 5月, 2016 2 次提交
  13. 14 5月, 2016 1 次提交
  14. 13 5月, 2016 3 次提交