- 15 11月, 2017 1 次提交
-
-
由 Hans de Goede 提交于
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable@vger.kernel.org Reported-by: NFKr <bugs-freedesktop@ubermail.me> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
-
- 14 11月, 2017 1 次提交
-
-
由 Michel Thierry 提交于
From gen6, the hardware tracks address lookup failures and we should clear those registers upon startup to prevent false positives. However, this was happening before we have the engines defined (intel_uncore_init()) and the for_each_engine loop was just a nop. The earliest we can call this is inside intel_engines_init_mmio(). Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171111004448.12360-1-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 10 11月, 2017 1 次提交
-
-
由 Hans de Goede 提交于
intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which does an intel_uncore_forcewake_get(FORCEWAKE_ALL) when some other driver tries to access the PMIC bus, so that later forcewake gets are no-ops (for the duration of the bus access). But intel_uncore_forcewake_reset gets called in 3 cases: 1) Before registering the pmic_bus_access_notifier 2) After unregistering the pmic_bus_access_notifier 3) To reset forcewake state on a GPU reset In all 3 cases the i915_pmic_bus_access_notifier() protection is insufficient. This commit fixes this race by calling iosf_mbi_punit_acquire() before calling intel_uncore_forcewake_reset(). In the case where it is called directly after unregistering the pmic_bus_access_notifier, we need to hold the punit-lock over both calls to avoid a race where intel_uncore_fw_release_timer() may execute between the 2 calls. Reviewed-by: NImre Deak <imre.deak@intel.com> Acked-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019111620.26761-3-hdegoede@redhat.com
-
- 02 11月, 2017 3 次提交
-
-
由 Mika Kuoppala 提交于
There is a possibility on gen9 hardware to miss the forcewake ack message. The recommended workaround is to use another free bit and toggle it until original bit is successfully acknowledged. Some future gen9 revs might or might not fix the underlying issue but using fallback forcewake bit dance can be considered as harmless: without the ack timeout we never reach the fallback bit forcewake. Thus as of now we adopt a blanket approach for all gen9 and leave the bypassing the fallback bit approach for future patches if corresponding hw revisions do appear. Commit 83e33372 ("drm/i915: Increase maximum polling time to 50ms for forcewake request/clear ack") did increase the forcewake timeout. If the issue was a delayed ack, future work could include finding a suitable timeout value both for primary ack and reserve toggle to reduce the worst case latency. v2: use bit 15, naming, comment (Chris), only wait fallback ack v3: fix return on fallback, backoff after fallback write (Chris) v4: udelay on first pass, grammar (Chris) v4: s/reserve/fallback References: HSDES #1604254524 References: https://bugs.freedesktop.org/show_bug.cgi?id=102051 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171102094836.2506-1-mika.kuoppala@linux.intel.com
-
由 Michel Thierry 提交于
This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and GuC. i915 is still responsible for detecting a hang, and when it does it only requests GuC to reset that Engine. GuC internally manages acquiring forcewake and idling the engine before resetting it. Once the reset is successful, i915 takes over again and handles the resubmission. The scheduler in i915 knows which requests are pending so after resetting a engine, pending workloads/requests are resubmitted again. v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the non-guc function names. v3: Removed debug message about engine restarting from which request, since the new baseline do it regardless of submission mode. (Chris) v4: Rebase. v5: Do not pass unnecessary reporting flags to the fw (Jeff); tasklet_schedule(&execlists->irq_tasklet) handles the resubmit; rebase. v6: Rename the existing reset engine function and share a similar interface between guc and non-guc paths (Chris). Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171031225309.10888-1-michel.thierry@intel.comReviewed-by: NJeff McGee <jeff.mcgee@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Michel Thierry 提交于
intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. v2: Print error message in English (Tvrtko). Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171030185616.32836-2-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 27 10月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
An interesting snippet from Sandybridge's prm: "Although a Ring Buffer can be enabled in the non-empty state, it must not be disabled unless it is empty. Attempting to disable a Ring Buffer in the non-empty state is UNDEFINED." Let's avoid the undefined behaviour as we disable the rings prior to reset and resume. v2: Tell HEAD to catch up to TAIL (empty ring) first, then reset both to 0 (supposedly while stopped). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027094311.30380-1-chris@chris-wilson.co.uk
-
- 14 10月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
Always try to stop the rings, even if the GPU reset itself has been disabled (via modparam i915.reset). This should at least stop the hw from spinning in the background consuming resources (e.g. power and memory bandwidth) letting the system rest-in-peace. References: https://bugs.freedesktop.org/show_bug.cgi?id=103260Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171013131218.18013-2-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
-
- 10 10月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
Add assert_forcewakes_active() (the complementary function to assert_forcewakes_inactive) that documents the requirement of a function for its callers to be holding the forcewake ref (i.e. the function is part of a sequence over which RC6 must be prevented). One such example is during ringbuffer reset, where RC6 must be held across the whole reinitialisation sequence. v2: Include debug information in the WARN so we know which fw domain is missing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20171009110301.21705-5-chris@chris-wilson.co.uk
-
- 22 9月, 2017 1 次提交
-
-
由 Michal Wajdeczko 提交于
Our global struct with params is named exactly the same way as new preferred name for the drm_i915_private function parameter. To avoid such name reuse lets use different name for the global. v5: pure rename v6: fix Credits-to: Coccinelle @@ identifier n; @@ ( - i915.n + i915_modparams.n ) Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
-
- 20 9月, 2017 1 次提交
-
-
由 Mika Kuoppala 提交于
On kbl evidence indicates that even if the hardware happily tells us to proceed with reset, it really isn't ready. Resetting a freely running batchbuffer after we have ack for readiness, still can cause a system hang. We also have similar experiences on older gens. So now attempt to stop engines before proceeding for reset, on all gens where we have a gpu reset. This has shown to improve reset reliability and reduce the risk of losing the machine. v2: Add fixme for wa (Joonas) Testcase: igt/prime_busy/hang-* # kbl Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919144128.25506-1-mika.kuoppala@intel.com
-
- 14 9月, 2017 1 次提交
-
-
由 Joonas Lahtinen 提交于
Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with 'entry->size - 1' (Chris) v4: - Add GEM_BUG_ON on for flags vs entry offset (Chris) v5: - Use 'u16' to match 'dev_priv' (Ville) v6: - Fix checkpatch.pl errors Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170913115255.13851-2-joonas.lahtinen@linux.intel.com
-
- 08 9月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
If the user bypasses i915 and accesses mmio directly, that easily confuses our automatic mmio debugging (any error we then detect is likely to be as a result of the user). Since we expect userspace to open debugfs/i915_forcewake_user if i915.ko is loaded and they want mmio access, that makes the opportune time to disable our debugging for duration of the bypass. v2: Move the fiddling of uncore internals to uncore.c References: https://bugs.freedesktop.org/show_bug.cgi?id=102543Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170907134441.12881-1-chris@chris-wilson.co.uk
-
- 07 9月, 2017 1 次提交
-
-
由 Nanley Chery 提交于
This enables the Mesa driver to advertise support for ARB_timer_query, and thus an OpenGL version higher than 3.2. Suggested-by: NBen Widawsky <ben@bwidawsk.net> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NNanley Chery <nanley.g.chery@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170905184507.30046-1-nanley.g.chery@intel.com
-
- 18 8月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2: Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by: NMichel Thierry <michel.thierry@intel.com> Fixes: 142bc7d9 ("drm/i915: Modify error handler for per engine hang recovery") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817173229.20324-1-chris@chris-wilson.co.ukReviewed-by: NMichel Thierry <michel.thierry@intel.com> Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
-
- 07 7月, 2017 1 次提交
-
-
由 Rodrigo Vivi 提交于
By spec there is no change on force wake registers for Cannonlake. Let's reuse gen9 one. v2: Adding missing case for the write part. (Tvrtko) v3: Rebase on recent tree. v4: Make it for gen9+ instead adding gen10 only. (by Joonas). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499302831-17773-1-git-send-email-rodrigo.vivi@intel.com
-
- 21 6月, 2017 1 次提交
-
-
由 Michel Thierry 提交于
This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because core implementation is lacking) and continue recovery using legacy full gpu reset. A helper function is also added to query the availability of engine reset. A subsequent patch will add the capability to query which type of reset is present (engine -> full -> no-reset) via the get-param ioctl. It has been decided that the error events that are used to notify user of reset will only be sent in case if full chip reset. In case of just single (or multiple) engine resets, userspace won't be notified by these events. Note that this implementation of engine reset is for i915 directly submitting to the ELSP, where the driver manages the hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and firmware; i915 will still responsible for detecting a hang, and when it does it will have to request GuC to reset that Engine and remind the firmware about the outstanding submissions. This will be added in different patch. v2: rebase, advertise engine reset availability in platform definition, add note about GuC submission. v3: s/*engine_reset*/*reset_engine*/. (Chris) Handle reset as 2 level resets, by first going to engine only and fall backing to full/chip reset as needed, i.e. reset_engine will need the struct_mutex. v4: Pass the engine mask to i915_reset. (Chris) v5: Rebase, update selftests. v6: Rebase, prepare for mutex-less reset engine. v7: Pass reset_engine mask as a function parameter, and iterate over the engine mask for reset_engine. (Chris) v8: Use i915.reset >=2 in has_reset_engine; remove redundant reset logging; add a reset-engine-in-progress flag to prevent concurrent resets, and avoid dual purposing of reset-backoff. (Chris) v9: Support reset of different engines in parallel (Chris) v10: Handle reset-engine flag locking better (Chris) v11: Squash in reporting of per-engine-reset availability. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NIan Lister <ian.lister@intel.com> Signed-off-by: NTomas Elf <tomas.elf@intel.com> Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-4-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-5-chris@chris-wilson.co.uk
-
- 30 5月, 2017 1 次提交
-
-
由 Kai Chen 提交于
This is a follow-up patch to the previous patch ([PATCH[1/2] drm/i915: Disable decoupled MMIO) to remove the dead code for decoupled MMIO implementation, as it won't be used any longer on GEN9LP. Therefore, this patch reverts: commit 85ee17eb Author: Praveen Paneri <praveen.paneri@intel.com> Date: Tue Nov 15 22:49:20 2016 +0530 drm/i915/bxt: Broxton decoupled MMIO Signed-off-by: NKai Chen <kai.chen@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170523215812.18328-3-kai.chen@intel.com
-
- 26 5月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
Currently the timer is armed for 1ms after the first use and is killed immediately, dropping the forcewake as early as possible. However, for very frequent operations the forcewake dance has a large impact on latency and keeping the timer alive until we are idle is preferred. To achieve this, if we call intel_uncore_forcewake_get whilst the timer is alive (repeated use), then set a flag to restart the timer on expiry rather than drop the forcewake usage count. The timer is racy, the consequence of the race is to expire the timer earlier than is now desired but does not impact on correct behaviour. The offset the race slightly, we set the active flag again on intel_uncore_forcewake_put. The effect should be to reduce the jitter of reacquiring the fw every 1ms on a busy system. However, the cost is to keep the timer alive for an extra 1ms on a nearly idle system. We chose to incur the jitter previously to keep the timer off for as much as possible. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170526132209.14640-1-chris@chris-wilson.co.uk
-
- 22 5月, 2017 1 次提交
-
-
由 Mika Kuoppala 提交于
We improved the reset reliablity on gen4 with stopping all engines before commencing reset, in commit 2c80353f ("drm/i915/g4x: Improve gpu reset reliability") Evidence indicates that this same trick works with g33. v2: proper gen naming, comment readability (Chris) Testcase: igt/gem_busy/*-hang #blb-e6850 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170522090244.2557-1-mika.kuoppala@intel.com
-
- 19 5月, 2017 3 次提交
-
-
由 Mika Kuoppala 提交于
ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings before resetting. It is unclear what cleanup exactly means but evidence shows that stopping the ring does have an effect on reset reliability. This patch makes reset successful on hangs induced by chained batches (the igt ones). Note that if the hang is inside a shader, it is possible that our attempts to stop the ring achieves anything. v2: zero ctl,head,tail also. bug ref. use driver debugs (Chris) v3: specify platform on testcases, comment tidyup (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Testcase: igt/gem_busy/*-hang #elk Testcase: igt/gem_ringfill/hang-* #elk Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170519091340.21439-1-mika.kuoppala@intel.com
-
由 Chris Wilson 提交于
Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170518204811.7408-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Repeat the reset a couple of times if at first we do not succeed. v2: differentiate which path/engine failed with a debug message Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170518204811.7408-1-chris@chris-wilson.co.uk
-
- 11 5月, 2017 1 次提交
-
-
由 Daniel Vetter 提交于
The unconditionally fallback to the blocking wait_for resulted in impressive fireworks at boot-up on my snb here. Make sure if we set the slow timeout to 0 that we never ever sleep. The tail of the callchain was intel_wait_for_register -> __intel_wait_for_register_fw -> usleep_range -> BOOM It blew up in intel_crt_detect load detection code on the ADPA_CRT_HOTPLUG_FORCE_TRIGGER in the ADPA register. v2: Shut up gcc. v3: Use uninitialized_var() (Chris). Fixes: 05646543 ("drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1494429572-15118-1-git-send-email-daniel.vetter@ffwll.ch
-
- 09 5月, 2017 1 次提交
-
-
由 Michal Wajdeczko 提交于
In order to allow use of e.g. forcewake_domains in a other feature headers included from the top of i915_drv.h, move all uncore related definitions into their own header. v2: move __mask_next_bit macro to utils header (Mika) Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
-
- 03 5月, 2017 2 次提交
-
-
由 Mika Kuoppala 提交于
Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested that we should fail silently as the fifo debug handler, now attached to unclaimed mmio handling, will take care of the possible errors at later stage. Note that the decision to wait was changed so that we avoid allocating the first reserved entry. Nor do we reduce the count if we fail the wait, removing the possiblity to wrap the count if the hw fifo returned zero. v2: remove unclaimed check on timeout (Chris) v3: use void return (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=100247Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1491493182-31540-1-git-send-email-mika.kuoppala@intel.com
-
由 Mika Kuoppala 提交于
Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Based on patch from Chris Wilson. v2: postpone warn on fifodbg for unclaimed reg debugs Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 28 4月, 2017 1 次提交
-
-
由 Tvrtko Ursulin 提交于
Looks like intel_guc_reset had the ability to sleep under the uncore spinlock since forever but it wasn't detected until the recent changes annotated the wait for register with might_sleep. I have fixed it by removing holding of the uncore spinlock over the call to gen6_hw_domain_reset, since I do not see that is really needed. But there is always a possibility I am missing some nasty detail so please double check. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Acked-by: NMichel Thierry <michel.thierry@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 27 4月, 2017 1 次提交
-
-
由 Michel Thierry 提交于
As all other functions related to resetting engines are using reset_engine. v2: remove _request_ and use start/cancel instead (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMichel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170418202335.35232-3-michel.thierry@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 12 4月, 2017 1 次提交
-
-
由 Chris Wilson 提交于
Provide dummy function pointers for the mock device in case we do hit mmio during testing. v2: Use ASSIGN_READ/WRITE_MMIO_FUNCS macros 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/20170412092143.3822-1-chris@chris-wilson.co.uk
-
- 11 4月, 2017 2 次提交
-
-
由 Chris Wilson 提交于
We acquire the forcewake and use I915_READ_FW instead for the atomic wait within intel_uncore_wait_for_register. However, this still leaves us vulnerable to concurrent mmio access to the register, which can cause system hangs on gen7. The protection is to acquire uncore.lock around each register, so lets add it back. v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for loop and spare adding another for ourselves. v3: Add might_sleep() annotation Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170411101340.31994-3-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
-
由 Chris Wilson 提交于
Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. v2: Reinforce kerneldoc fast_timeout_us limit with a GEM_BUG_ON Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170411112705.12656-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
-
- 10 4月, 2017 2 次提交
-
-
由 Michal Wajdeczko 提交于
This function should not be called with long timeouts in atomic context. Annotate it as might_sleep if timeout is longer than 10us. v2: fix comment (Michal) Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170410121747.209200-1-michal.wajdeczko@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Michal Wajdeczko 提交于
These params are passed by value, const qualifiers are ignored any way. While around, unify timeout_ms type from long to int. Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170410093817.151280-1-michal.wajdeczko@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 08 4月, 2017 1 次提交
-
-
由 Michal Wajdeczko 提交于
In some cases we may want to spend more time in atomic wait than hardcoded 2us. Let's add additional fast timeout parameter to allow flexible configuration of atomic timeout before switching into heavy wait. Add also possibility to return registry value to avoid extra read. v2: use explicit fast timeout (Tvrtko/Chris) allow returning register value (Chris) Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170407160145.181328-1-michal.wajdeczko@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 07 4月, 2017 1 次提交
-
-
由 Michal Wajdeczko 提交于
There is no need to specify timeout as unsigned long since this parameter will be consumed by usecs_to_jiffies() which expects unsigned int only. Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170407133212.174608-1-michal.wajdeczko@intel.comReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 23 3月, 2017 4 次提交
-
-
由 Chris Wilson 提交于
Since we reuse the same values for each fw_domain, move them onto uncore. 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/20170323101944.21627-6-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
We can relax the requirement upon ourselves that the forcewake is released immediately and just allow it to occur naturally following our mmio request. 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/20170323101944.21627-5-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Use find-first-set bitop to quickly scan through the fw_domains mask and skip iterating over unused domains. v2: Move the WARN into the caller, to prevent compiler warnings in normal builds. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-4-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
In the next patch we will begin to sanity check that we do not attempt to obtain the forcewake on an unsupport domain. However, that is exactly what we do during reset of the fw_domains - rectify it before it explodes. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323101944.21627-3-chris@chris-wilson.co.uk
-