- 02 7月, 2016 5 次提交
-
-
由 Chris Wilson 提交于
When waiting for an interrupt (waiting for the engine to complete some work), we know we are the only waiter to be woken on this engine. We also know when the GPU has nearly completed our request (or at least started processing it), so after being woken and we detect that the GPU is active and working on our request, allow us the bottom-half (the first waiter who wakes up to handle checking the seqno after the interrupt) to spin for a very short while to reduce client latencies. The impact is minimal, there was an improvement to the realtime-vs-many clients case, but exporting the function proves useful later. However, it is tempting to adjust irq_seqno_barrier to include the spin. The problem is first ensuring that the "start-of-request" seqno is coherent as we use that as our basis for judging when it is ok to spin. If we could, spinning there could dramatically shorten some sleeps, and allow us to make the barriers more conservative to handle missed seqno writes on more platforms (all gen7+ are known to have the occasional issue, at least). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-7-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but every client is woken up after every batchbuffer - hence the thunder of hooves as then every client must do its heavyweight dance to read a coherent seqno to see if it is the lucky one. Ideally, we only want one client to wake up after the interrupt and check its request for completion. Since the requests must retire in order, we can select the first client on the oldest request to be woken. Once that client has completed his wait, we can then wake up the next client and so on. However, all clients then incur latency as every process in the chain may be delayed for scheduling - this may also then cause some priority inversion. To reduce the latency, when a client is added or removed from the list, we scan the tree for completed seqno and wake up all the completed waiters in parallel. Using igt/benchmarks/gem_latency, we can demonstrate this effect. The benchmark measures the number of GPU cycles between completion of a batch and the client waking up from a call to wait-ioctl. With many concurrent waiters, with each on a different request, we observe that the wakeup latency before the patch scales nearly linearly with the number of waiters (before external factors kick in making the scaling much worse). After applying the patch, we can see that only the single waiter for the request is being woken up, providing a constant wakeup latency for every operation. However, the situation is not quite as rosy for many waiters on the same request, though to the best of my knowledge this is much less likely in practice. Here, we can observe that the concurrent waiters incur extra latency from being woken up by the solitary bottom-half, rather than directly by the interrupt. This appears to be scheduler induced (having discounted adverse effects from having a rbtree walk/erase in the wakeup path), each additional wake_up_process() costs approximately 1us on big core. Another effect of performing the secondary wakeups from the first bottom-half is the incurred delay this imposes on high priority threads - rather than immediately returning to userspace and leaving the interrupt handler to wake the others. To offset the delay incurred with additional waiters on a request, we could use a hybrid scheme that did a quick read in the interrupt handler and dequeued all the completed waiters (incurring the overhead in the interrupt handler, not the best plan either as we then incur GPU submission latency) but we would still have to wake up the bottom-half every time to do the heavyweight slow read. Or we could only kick the waiters on the seqno with the same priority as the current task (i.e. in the realtime waiter scenario, only it is woken up immediately by the interrupt and simply queues the next waiter before returning to userspace, minimising its delay at the expense of the chain, and also reducing contention on its scheduler runqueue). This is effective at avoid long pauses in the interrupt handler and at avoiding the extra latency in realtime/high-priority waiters. v2: Convert from a kworker per engine into a dedicated kthread for the bottom-half. v3: Rename request members and tweak comments. v4: Use a per-engine spinlock in the breadcrumbs bottom-half. v5: Fix race in locklessly checking waiter status and kicking the task on adding a new waiter. v6: Fix deciding when to force the timer to hide missing interrupts. v7: Move the bottom-half from the kthread to the first client process. v8: Reword a few comments v9: Break the busy loop when the interrupt is unmasked or has fired. v10: Comments, unnecessary churn, better debugging from Tvrtko v11: Wake all completed waiters on removing the current bottom-half to reduce the latency of waking up a herd of clients all waiting on the same request. v12: Rearrange missed-interrupt fault injection so that it works with igt/drv_missed_irq_hang v13: Rename intel_breadcrumb and friends to intel_wait in preparation for signal handling. v14: RCU commentary, assert_spin_locked v15: Hide BUG_ON behind the compiler; report on gem_latency findings. v16: Sort seqno-groups by priority so that first-waiter has the highest task priority (and so avoid priority inversion). v17: Add waiters to post-mortem GPU hang state. v18: Return early for a completed wait after acquiring the spinlock. Avoids adding ourselves to the tree if the is already complete, and skips the awkward question of why we don't do completion wakeups for waits earlier than or equal to ourselves. v19: Prepare for init_breadcrumbs to fail. Later patches may want to allocate during init, so be prepared to propagate back the error code. Testcase: igt/gem_concurrent_blit Testcase: igt/benchmarks/gem_latency Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: "Goel, Akash" <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> #v18 Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-6-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Currently __i915_wait_request uses a per-engine wait_queue_t for the dual purpose of waking after the GPU advances or for waking after an error. In the future, we may add even more wake sources and require greater separation, but for now we can conceptually simplify wakeups by separating the two sources. In particular, this allows us to use different wait-queues (e.g. one on the engine advancement, a global one for errors and one on each requests) without any hassle. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-5-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Since the function is a small wrapper around schedule_delayed_work(), move it inline to remove the function call overhead for the principle caller. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-4-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. v2: Use the system_long_wq as we may wish to capture the error state after detecting the hang - which may take a bit of time. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-3-git-send-email-chris@chris-wilson.co.uk
-
- 30 6月, 2016 3 次提交
-
-
由 Chris Wilson 提交于
Since we have a sequence of register reads and writes, we can reduce the latency of starting the BSD ring by performing all the mmio operations under the same forcewake wakeref. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-62-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Ville Syrjälä reported that in the majority of wait_for(I915_READ()) he inspect, most completed within the first couple of reads and that the delay between those wait_for() reads was the ratelimiting step for many code paths. For example, __gen6_update_ring_freq() was blamed for slowing down boot by many milliseconds, but under Ville's scrutiny the issue was just excessive delay waiting for sandybridge_pcode_write(). We can eliminate the wait by initially using a busyspin upon the register read and only fallback to the sleeping loop in cases where the hardware is indeed too slow. A threshold of 2 microseconds is used as the initial ballpark. To avoid excessive code bloating from converting every wait_for() into a hybrid busy/sleep loop, we extend wait_for_register_fw() and export it for use by other callers. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-1-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Since commit 2ed53a94 ("drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno") once a hang is completed, the seqno is advanced past all current requests. With this we know that if we wake up from waiting for a request, if a hang has occurred and reset completed, our request will be considered complete (i.e. i915_gem_request_completed() returns true). Therefore we only need to worry about the situation where a hang has occurred, but not yet reset, where we may need to release our struct_mutex. Since we don't need to detect the completed reset using the global gpu_error->reset_counter anymore, we do not need to track the reset_counter epoch inside the request. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467211874-11552-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
-
- 28 6月, 2016 1 次提交
-
-
由 Randy Dunlap 提交于
Fix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister' [-Werror=implicit-function-declaration] intel_opregion_unregister(dev_priv); ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume': ../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of function 'intel_opregion_register' [-Werror=implicit-function-declaration] intel_opregion_register(dev_priv); Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Fixes: 03d92e47 ("drm/i915/opregion: Rename init/fini functions to register/unregister") Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [Jani: dropped the stale init/fini declarations] Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467028399-9965-1-git-send-email-jani.nikula@intel.com
-
- 24 6月, 2016 10 次提交
-
-
由 Chris Wilson 提交于
We only need to force a switch to the kernel context placeholder during eviction. All other uses of i915_gpu_idle() just want to wait until existing work on the GPU is idle. Rename i915_gpu_idle() to i915_gem_wait_for_idle() to avoid any implications about "parking" the context first. v2: Tweak an error message if the wait fails for the ilk vtd w/a Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-6-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
This is so that we have symmetry with intel_lrc.c and avoid a source of if (i915.enable_execlists) layering violation within i915_gem_context.c - that is we move the specific handling of the dev_priv->kernel_context for legacy submission into the legacy submission code. This depends upon the init/fini ordering between contexts and engines already defined by intel_lrc.c, and also exporting the context alignment required for pinning the legacy context. v2: Separate out pin/unpin context funcs for greater symmetry with intel_lrc. One more step towards unifying behaviour between the two classes of engines and towards fixing another bug in i915_switch_context vs requests. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-2-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
i915_dma.c used to contain the DRI1/UMS horror show, but now all that remains are the out-of-place driver level interfaces (such as allocating, initialising and registering the driver). These should be in i915_drv.c alongside similar routines for suspend/resume. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-10-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Baby step, update to_i915() conversion from drm_device to drm_i915_private: text data bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-9-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
drm_connector_register_all() is now automatically called by drm_dev_register(), and so we no longer have to do so ourselves (via intel_modeset_register() after calling drm_dev_register()). Similarly for unregistering. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-8-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering makes the driver visible to userspace first (in order to coordinate with removed DRI1 userspace), but that ordering incurs risk. The risk increases as we strive for more asynchronous loading. One side effect of controlling the allocation is that we can allocate both the drm_device + drm_i915_private in one block, the next step towards subclassing. Unload is still left as before, a mix of midlayer and driver. v2: After drm_dev_init(), we should call drm_dev_unref() so that we call drm_dev_release() and free everything from drm_dev_init(). v3: Fixup missed error code for failing to allocate dev_priv Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-6-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our registration phase, where we announce our presence to the world when we are ready, i.e the sequence changes from drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_debugfs_init() -> i915_driver_load() to drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_driver_load() -> i915_debugfs_register() Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-5-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-4-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-3-git-send-email-chris@chris-wilson.co.uk
-
由 Tvrtko Ursulin 提交于
Effectively removes one layer of indirection between the mask of possible engines and the engine constructors. Instead of spelling out in code the mapping of HAS_<engine> to constructors, makes more use of the recently added data driven approach by putting engine constructor vfuncs into the table as well. Effect is fewer lines of source and smaller binary. At the same time simplify the error handling since engine destructors can run on unitialized engines anyway. Similar approach could be done for legacy submission is wanted. v2: Removed ugly BUILD_BUG_ONs in favour of newly introduced ENGINE_MASK and HAS_ENGINE macros. Also removed the forward declarations by shuffling functions around. v3: Warn when logical_rings table does not contain enough data and disable the engines which could not be initialized. (Chris Wilson) v4: Chris Wilson suggested a nicer engine init loop. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1466689961-23232-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
- 22 6月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
Also extract drm_auth.h for nicer grouping. v2: Nuke the other comments since they don't really explain a lot, and within the drm core we generally only document functions exported to drivers: The main audience for these docs are driver writers. v3: Limit the exposure of drm_master internals by only including drm_auth.h where it is neede (Chris). v4: Spelling polish (Emil). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 21 6月, 2016 2 次提交
-
-
由 Tvrtko Ursulin 提交于
No need for local struct drm_device * since dev_priv is the correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating anyway. Changed the macro definition for the latter to reflect that as well. v2: Alignment bikeshed. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466518034-24838-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
由 Chris Wilson 提交于
... instead of the previous ORIGIN_GTT. This should actually invalidate FBC once something is written on the frontbuffer using WC mmaps. The problem with ORIGIN_GTT is that the automatic hardware tracking is not able to detect the WC writes as it can detect the GTT writes. This should help fix the SKL bug where nothing happens when you type your username/password on lightdm. This patch was originally pasted on an email by Chris and converted to an actual git patch by Paulo. v2 (from Paulo): - Make it a full variable instead of a bit-field (Daniel) - Use WRITE_ONCE (Chris) v3 (from Paulo): - Remove huge comment since now we have WRITE_ONCE (Chris) - Remove uneeded new line (Chris) - Add Chris' Signed-off-by, authorized via IRC Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466185599-26401-1-git-send-email-paulo.r.zanoni@intel.com
-
- 20 6月, 2016 2 次提交
-
-
由 Chris Wilson 提交于
Currently to see if an object is backed by struct pages (as opposed to being a simple pointer to stolen memory, for example) we do a manual check on the obj->ops->flags. This is quite shouty and before adding more checks in future, we should make it a bit calmer. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466431552-17860-1-git-send-email-chris@chris-wilson.co.uk
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 19 6月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466160034-12173-2-git-send-email-chris@chris-wilson.co.uk
-
- 18 6月, 2016 6 次提交
-
-
由 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
-
由 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
-
由 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>
-
由 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
-
由 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
-
由 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>
-
- 14 6月, 2016 1 次提交
-
-
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>
-
- 13 6月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with any page within the object. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NAnkitprasad Sharma <ankitprasad.r.sharma@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- 08 6月, 2016 2 次提交
-
-
由 Mika Kuoppala 提交于
Extend the scope of this workaround, already used in skl, to also take effect in kbl. v2: Fix KBL_REVID_E0 (Matthew) References: HSD#2132677 Cc: Matthew Auld <matthew.william.auld@gmail.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-12-git-send-email-mika.kuoppala@intel.com
-
由 Mika Kuoppala 提交于
Add REVID macro for kbl to limit wa applicability to particular revision range. Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-4-git-send-email-mika.kuoppala@intel.com
-
- 07 6月, 2016 1 次提交
-
-
由 Ville Syrjälä 提交于
Apparently some CHV boards failed to hook up the port presence straps for HDMI ports as well (earlier we assumed this problem only affected eDP ports). So let's check the VBT in addition to the strap, and if either one claims that the port is present go ahead and register the relevant connector. While at it, change port D to register DP before HDMI as we do for ports B and C since commit 457c52d8 ("drm/i915: Only ignore eDP ports that are connected") Also print a debug message when we register a HDMI connector to aid in diagnosing missing/incorrect ports. We already had such a print for DP/eDP. v2: Improve the comment in the code a bit, note the port D change in the commit message Cc: Radoslav Duda <radosd@radosd.com> Tested-by: NRadoslav Duda <radosd@radosd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96321Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464945463-14364-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 06 6月, 2016 1 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 6月, 2016 2 次提交
-
-
由 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>
-
由 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
-
- 25 5月, 2016 1 次提交
-
-
由 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>
-