aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-12-03drm/amdgpu: should stop GFX ring in hw_finiMonk Liu1-1/+1
To align with the scheme from gfx9 disabling GFX ring after VM shutdown could avoid garbage data be fetched to GFX RB which may lead to unnecessary screw up on GFX Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu: do autoload right after MEC loaded for SRIOV VFMonk Liu1-2/+2
since we don't have RLCG ucode loading and no SRlist as well Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu: skip rlc ucode loading for SRIOV gfx10Monk Liu1-39/+41
Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu: fix calltrace during kmd unload(v3)Monk Liu5-144/+6
issue: kernel would report a warning from a double unpin during the driver unloading on the CSB bo why: we unpin it during hw_fini, and there will be another unpin in sw_fini on CSB bo. fix: actually we don't need to pin/unpin it during hw_init/fini since it is created with kernel pinned, we only need to fullfill the CSB again during hw_init to prevent CSB/VRAM lost after S3 v2: get_csb in init_rlc so hw_init() will make CSIB content back even after reset or s3 v3: use bo_create_kernel instead of bo_create_reserved for CSB otherwise the bo_free_kernel() on CSB is not aligned and would lead to its internal reserve pending there forever take care of gfx7/8 as well Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Reviewed-by: Xiaojie Yuan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu/gfx10: unlock srbm_mutex after queue programming finishXiaojie Yuan1-2/+3
srbm_mutex is to guarantee atomicity for r/w of gfx indexed registers Signed-off-by: Xiaojie Yuan <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu: Added ASIC specific checks in gfxhub V1.1 get XGMI infoJohn Clements1-2/+17
Added max hive/node info checks per supported ASIC Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: John Clements <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu/powerplay: unify smu send message functionLikun Gao11-67/+21
Drop smu_send_smc_msg function from ASIC specify structure. Reuse smu_send_smc_msg_with_param function for smu_send_smc_msg. Set paramer to 0 for smu_send_msg function, otherwise it will send with previous paramer value (Not a certain value). Materialize msg type for smu send message function definition. Signed-off-by: Likun Gao <[email protected]> Reviewed-by: Kevin Wang <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amd/display: re-enable wait in pipelock, but add timeoutAlex Deucher1-0/+19
Removing this causes hangs in some games, so re-add it, but add a timeout so we don't hang while switching flip types. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205169 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=112266 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-12-03drm/amd/display: Get NV14 specific ip params as neededZhan liu1-0/+4
[Why] NV14 is using its own ip params that's different from other DCN2.0 ASICs. [How] Add ASIC revision check to make sure NV14 gets correct ip params. Signed-off-by: Zhan Liu <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amd/display: Adding NV14 IP ParametersZhan liu1-0/+68
[Why] NV14 IP Parameters are missing. [How] Add IP Parameters in. Signed-off-by: Zhan liu <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amd/display: Include num_vmid and num_dsc within NV14's resource capsZhan Liu1-0/+2
[Why] "num_vmid" and "num_dsc" are missing within NV14's resource caps structure. [How] Add the missing parts. Signed-off-by: Zhan Liu <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-03drm/amdgpu: use CPU to flush vmhub if sched stoppedMonk Liu1-1/+2
otherwse the flush_gpu_tlb will hang if we unload the KMD becuase the schedulers already stopped Signed-off-by: Monk Liu <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-02Merge tag 'drm-intel-next-fixes-2019-11-28' of ↵Dave Airlie24-93/+354
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Important fix to uAPI alignment on query IOCTL - Fixes for the power regression introduced by the previous security patches - Avoid regressing super heavy benchmarks by increasing the default request pre-emption timeout from 100 ms to 640 ms to - Resulting set of smaller fixes done while problem was inspected - Display fixes for EHL voltage level programming and TGL DKL PHY vswing for HDMI Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-12-02Merge tag 'drm-msm-next-2019-11-05' of ↵Dave Airlie49-307/+1235
https://gitlab.freedesktop.org/drm/msm into drm-next + OCMEM support to enable the couple generations that had shared OCMEM rather than GMEM exclusively for the GPU (late a3xx and I think basically all of a4xx). Bjorn and Brian decided to land this through the drm tree to avoid having to coordinate merge requests. + a510 support, and various associated display support + the usual misc cleanups and fixes Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGv-JWswEJRxe5AmnGQO1SZnpxK05kO1E29K6UUzC9GMMw@mail.gmail.com
2019-11-27drm/i915: Reduce nested prepare_remote_context() to a trylockChris Wilson1-4/+17
On context retiring, we may invoke the kernel_context to unpin this context. Elsewhere, we may use the kernel_context to modify this context. This currently leads to an AB-BA lock inversion, so we need to back-off from the contended lock, and repeat. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111732 Signed-off-by: Chris Wilson <[email protected]> Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly") Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 58b4c1a07ada7fb91ea757bdb9bd47df02207357) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-27drm/i915: Default to a more lenient forced preemption timeoutChris Wilson1-1/+1
Based on a sampling of a number of benchmarks across platforms, by default opt for a much more lenient timeout so that we should not adversely affect existing "good" clients. 640ms ought to be enough for anyone. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169 Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: Dmitry Rogozhkin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 5766a5ffc6a69595903865518c43636bde0e4ac4) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-27drm/mgag200: Add workaround for HW that does not support 'startadd'Thomas Zimmermann2-1/+38
There's at least one system that does not interpret the value of the device's 'startadd' field correctly, which leads to incorrectly displayed scanout buffers. Always placing the active scanout buffer at offset 0 works around the problem. Signed-off-by: Thomas Zimmermann <[email protected]> Reported-by: John Donnelly <[email protected]> Tested-by: John Donnelly <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin") Cc: Gerd Hoffmann <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: "Y.C. Chen" <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: "José Roberto de Souza" <[email protected]> Cc: Andrzej Pietrasiewicz <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.3+ Link: https://gitlab.freedesktop.org/drm/misc/issues/7 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-27drm/mgag200: Store flags from PCI driver data in device structureThomas Zimmermann2-0/+9
The flags field in struct mga_device has been unused so far. We now use it to store flag bits from the PCI driver. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin") Cc: John Donnelly <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: "Y.C. Chen" <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: "José Roberto de Souza" <[email protected]> Cc: Andrzej Pietrasiewicz <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.3+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-27drm/mgag200: Extract device type from flagsThomas Zimmermann2-1/+8
Adds a conversion function that extracts the device type from the PCI id-table flags. Allows for storing additional information in the other flag bits. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin") Reviewed-by: Daniel Vetter <[email protected]> Cc: John Donnelly <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: David Airlie <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Emil Velikov <[email protected]> Cc: "Y.C. Chen" <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: "José Roberto de Souza" <[email protected]> Cc: Andrzej Pietrasiewicz <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.3+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-26amdgpu: Enable KFD on POWER systemsTimothy Pearson1-1/+1
KFD has been verified to function on POWER systems (Talos II / Vega 64). It should be available as a kernel configuration option on these systems. Signed-off-by: Timothy Pearson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-26drm/amdgpu: Optimize KFD page table reservationFelix Kuehling1-1/+14
Be less pessimistic about estimated page table use for KFD. Most allocations use 2MB pages and therefore need less VRAM for page tables. This allows more VRAM to be used for applications especially on large systems with many GPUs and hundreds of GB of system memory. Example: 8 GPUs with 32GB VRAM each + 256GB system memory = 512GB Old page table reservation per GPU: 1GB New page table reservation per GPU: 32MB Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: xinhui pan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-26drm/amdgpu: flag vram lost on baco reset for VI/CIKAlex Deucher2-4/+10
VI/CIK BACO was inflight when this fix landed for SOC15/NV. Add the fix to VI/CIK as well. Acked-by: Evan Quan <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-26MAINTAINERS: Drop Rex Zhu for amdgpu powerplayAlex Deucher1-1/+0
No longer works on the driver. Reviewed-by: Christian König <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-26drm/amdgpu: Resolved offchip EEPROM I/O issueJohn Clements2-5/+13
Updated target I2C address Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: John Clements <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-26drm/amd/display: add default clocks if not able to fetch themAlex Deucher1-1/+2
dm_pp_get_clock_levels_by_type needs to add the default clocks to the powerplay case as well. This was accidently dropped. Fixes: b3ea88fef321de ("drm/amd/powerplay: add get_clock_by_type interface for display") Bug: https://gitlab.freedesktop.org/drm/amd/issues/906 Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-26drm/i915/gt: Make intel_ring_unpin() safe for concurrent pintChris Wilson1-9/+4
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") allowed the intel_ring unpinning to be run concurrently with the next context pinning it. Thus each step in intel_ring_unpin() needed to be atomic and ordered in a nice onion with intel_ring_pin() so that the lifetimes overlapped and were always safe. Sadly, a few steps in intel_ring_unpin() were overlooked, such as closing the read/write pointers of the ring and discarding the intel_ring.vaddr, as these steps were not serialised with intel_ring_pin() and so could leave the ring in disarray. Fixes: 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a266bf42006004306dd48a9082c35dfbff153307) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-26Merge tag 'drm-next-5.5-2019-11-22' of ↵Dave Airlie32-53/+362
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.5-2019-11-22: amdgpu: - Fix bad DMA on some PPC platforms - MMHUB fix for powergating - BACO fix for Navi - Misc raven fixes - Enable vbios fetch directly from rom on navi - debugfs fix for DC - SR-IOV fixes for arcturus - Misc power fixes radeon: - Fix bad DMA on some PPC platforms Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-26Merge tag 'drm-intel-next-fixes-2019-11-22' of ↵Dave Airlie1-2/+7
git://anongit.freedesktop.org/drm/drm-intel into drm-next - Reverts a patch to avoid spinning forever when context's timeline is active but has no requests Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-11-25drm/i915/gt: Schedule request retirement when timeline idlesChris Wilson7-3/+108
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA") is that it disables RC6 while Skylake (and friends) is active, and we do not consider the GPU idle until all outstanding requests have been retired and the engine switched over to the kernel context. If userspace is idle, this task falls onto our background idle worker, which only runs roughly once a second, meaning that userspace has to have been idle for a couple of seconds before we enable RC6 again. Naturally, this causes us to consume considerably more energy than before as powersaving is effectively disabled while a display server (here's looking at you Xorg) is running. As execlists will get a completion event as each context is completed, we can use this interrupt to queue a retire worker bound to this engine to cleanup idle timelines. We will then immediately notice the idle engine (without userspace intervention or the aid of the background retire worker) and start parking the GPU. Thus during light workloads, we will do much more work to idle the GPU faster... Hopefully with commensurate power saving! v2: Watch context completions and only look at those local to the engine when retiring to reduce the amount of excess work we perform. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112315 References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA") References: 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 4f88f8747fa43c97c3b3712d8d87295ea757cc51) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/gt: Adapt engine_park synchronisation rules for engine_retireChris Wilson1-6/+21
In the next patch, we will introduce a new asynchronous retirement worker, fed by execlists CS events. Here we may queue a retirement as soon as a request is submitted to HW (and completes instantly), and we also want to process that retirement as early as possible and cannot afford to postpone (as there may not be another opportunity to retire it for a few seconds). To allow the new async retirer to run in parallel with our submission, pull the __i915_request_queue (that passes the request to HW) inside the timelines spinlock so that the retirement cannot release the timeline before we have completed the submission. v2: Actually to play nicely with engine_retire, we have to raise the timeline.active_lock before releasing the HW. intel_gt_retire_requsts() is still serialised by the outer lock so they cannot see this intermediate state, and engine_retire is serialised by HW submission. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 88a4655e75ac8f55eea5e3f38b176cba9cf653b5) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/execlists: Fixup cancel_port_requests()Chris Wilson1-9/+7
I rushed a last minute correction to cancel_port_requests() to prevent the snooping of *execlists->active as the inflight array was being updated, without noticing we iterated the inflight array starting from active! Oops. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112387 Fixes: 97f9af78f38d ("drm/i915/gt: Mark the execlists->active as the primary volatile access") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit da0ef77e1e0ccff703efee82406c629d5c4f4bbb) [Joonas: Fixed Fixes: tag to match drm-intel-next-fixes] Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/gt: Mark the execlists->active as the primary volatile accessChris Wilson2-13/+18
Since we want to do a lockless read of the current active request, and that request is written to by process_csb also without serialisation, we need to instruct gcc to take care in reading the pointer itself. Otherwise, we have observed execlists_active() to report 0x40. [ 2400.760381] igt/para-4098 1..s. 2376479300us : process_csb: rcs0 cs-irq head=3, tail=4 [ 2400.760826] igt/para-4098 1..s. 2376479303us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 [ 2400.761271] igt/para-4098 1..s. 2376479306us : trace_ports: rcs0: promote { b9c59:2622, b9c55:2624 } [ 2400.761726] igt/para-4097 0d... 2376479311us : __i915_schedule: rcs0: -2147483648->3, inflight:0000000000000040, rq:ffff888208c1e940 which is impossible! The answer is that as we keep the existing execlists->active pointing into the array as we copy over that array, the unserialised read may see a partial pointer value. Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 331bf90591573dfe6c8e892239713ef9702f1396) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/gt: Unlock engine-pm after queuing the kernel context switchChris Wilson1-7/+40
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend"), I erroneously concluded that we last modify the engine inside __i915_request_commit() meaning that we could enable concurrent submission for userspace as we enqueued this request. However, this falls into a trap with other users of the engine->kernel_context waking up and submitting their request before the idle-switch is queued, with the result that the kernel_context is executed out-of-sequence most likely upsetting the GPU and certainly ourselves when we try to retire the out-of-sequence requests. As such we need to hold onto the effective engine->kernel_context mutex lock (via the engine pm mutex proxy) until we have finish queuing the request to the engine. v2: Serialise against concurrent intel_gt_retire_requests() v3: Describe the hairy locking scheme with intel_gt_retire_requests() for future reference. v4: Combine timeline->lock and engine pm release; it's hairy. Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 5cba288466e9b229feb68295675246e7522fb5eb) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/gt: Close race between engine_park and intel_gt_retire_requestsChris Wilson3-12/+32
The general concept was that intel_timeline.active_count was locked by the intel_timeline.mutex. The exception was for power management, where the engine->kernel_context->timeline could be manipulated under the global wakeref.mutex. This was quite solid, as we always manipulated the timeline only while we held an engine wakeref. And then we started retiring requests outside of struct_mutex, only using the timelines.active_list and the timeline->mutex. There we started manipulating intel_timeline.active_count outside of an engine wakeref, and so introduced a race between __engine_park() and intel_gt_retire_requests(), a race that could result in the engine->kernel_context not being added to the active timelines and so losing requests, which caused us to keep the system permanently powered up [and unloadable]. The race would be easy to close if we could take the engine wakeref for the timeline before we retire -- except timelines are not bound to any engine and so we would need to keep all active engines awake. The alternative is to guard intel_timeline_enter/intel_timeline_exit for use outside of the timeline->mutex. Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a6edbca74b305adc165e67065d7ee766006e6a48) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915: Mark up the calling context for intel_wakeref_put()Chris Wilson11-25/+54
Previously, we assumed we could use mutex_trylock() within an atomic context, falling back to a worker if contended. However, such trickery is illegal inside interrupt context, and so we need to always use a worker under such circumstances. As we normally are in process context, we can typically use a plain mutex, and only defer to a work when we know we are being called from an interrupt path. Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref") References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") References: https://bugs.freedesktop.org/show_bug.cgi?id=111626 Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 07779a76ee1f93f930cf697b22be73d16e14f50c) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915: Wait until the intel_wakeref idle callback is completeChris Wilson2-2/+26
When waiting for idle, serialise with any ongoing callback so that it will have completed before completing the wait. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f4ba0707c825d60f1d0f5ce7bd3d875e68f3e204) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_stateChris Wilson1-1/+1
pm_suspend_target_state is declared under CONFIG_PM_SLEEP but only defined under CONFIG_SUSPEND. Play safe and only use the symbol if it is both declared and defined. Reported-by: [email protected] Signed-off-by: Chris Wilson <[email protected]> Fixes: a70a9e998e8e ("drm/i915: Defer rc6 shutdown to suspend_late") Cc: Andi Shyti <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/query: Align flavour of engine data lookupTvrtko Ursulin1-2/+5
Commit 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") changed the engine query to iterate over uabi engines but left the buffer size calculation look at the physical engine count. Difference has no practical consequence but it is nicer to align both queries. Signed-off-by: Tvrtko Ursulin <[email protected]> Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 9acc99d8f278e3da398e927774431bd3e947ab2e) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/tgl: Add DKL PHY vswing table for HDMIMatt Roper1-5/+24
The bspec initially provided a single DKL PHY vswing table for both HDMI and DP, but was recently updated to include an independent table for HDMI. Bspec: 49292 Fixes: 978c3e539be2 ("drm/i915/tgl: Add dkl phy programming sequences") Cc: Clinton A Taylor <[email protected]> Cc: Lucas De Marchi <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit 362bfb995b78394aefe61f7cc0511ef7c50bb11e) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-25drm/i915/ehl: Update voltage level checksMatt Roper1-1/+3
The bspec was recently updated with new cdclk -> voltage level tables to accommodate the new 324/326.4 cdclk values. Bspec: 21809 Fixes: 63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table") Cc: José Roberto de Souza <[email protected]> Cc: Vivek Kasireddy <[email protected]> Cc: Bob Paauwe <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit d147483884ed08ee6bb618ef610ee0329a27fda7) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-11-22drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10changzhu3-2/+116
It may lose gpuvm invalidate acknowldege state across power-gating off cycle. To avoid this issue in gmc9/gmc10 invalidation, add semaphore acquire before invalidation and semaphore release after invalidation. After adding semaphore acquire before invalidation, the semaphore register become read-only if another process try to acquire semaphore. Then it will not be able to release this semaphore. Then it may cause deadlock problem. If this deadlock problem happens, it needs a semaphore firmware fix. Signed-off-by: changzhu <[email protected]> Acked-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-22drm/amdgpu: initialize vm_inv_eng0_sem for gfxhub and mmhubchangzhu6-0/+13
SW must acquire/release one of the vm_invalidate_eng*_sem around the invalidation req/ack. Through this way,it can avoid losing invalidate acknowledge state across power-gating off cycle. To use vm_invalidate_eng*_sem, it needs to initialize vm_invalidate_eng*_sem firstly. Signed-off-by: changzhu <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-22drm/amd/amdgpu/sriov skip RLCG s/r list for arcturus VF.Jack Zhang1-1/+4
After rlcg fw 2.1, kmd driver starts to load extra fw for LIST_CNTL,GPM_MEM,SRM_MEM. We needs to skip the three fw because all rlcg related fw have been loaded by host driver. Guest driver would load the three fw fail without this change. Signed-off-by: Jack Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-22drm/amd/amdgpu/sriov temporarily skip ras,dtm,hdcp for arcturus VFJack Zhang1-0/+36
Temporarily skip ras,dtm,hdcp initialize and terminate for arcturus VF Currently the three features haven't been enabled at SRIOV, it would trigger guest driver load fail with the bare-metal path of the three features. Signed-off-by: Jack Zhang <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-22drm/amdgpu/gfx10: re-init clear state buffer after gpu resetXiaojie Yuan1-6/+37
This patch fixes 2nd baco reset failure with gfxoff enabled on navi1x. clear state buffer (resides in vram) is corrupted after 1st baco reset, upon gfxoff exit, CPF gets garbage header in CSIB and hangs. Signed-off-by: Xiaojie Yuan <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-22merge fix for "ftrace: Rework event_create_dir()"Stephen Rothwell1-1/+1
Reviewed-by: Kevin Wang <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-22drm/amdgpu: Update Arcturus golden registersJay Cornwall1-0/+1
Signed-off-by: Jay Cornwall <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-22drm/amdgpu/gfx10: fix out-of-bound mqd_backup array accessXiaojie Yuan1-2/+0
Fixes: 0900a9efdb7909 ("drm/amdgpu/gfx10: fix mqd backup/restore for gfx rings (v2)") Signed-off-by: Xiaojie Yuan <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-11-22drm/amdgpu/gfx10: explicitly wait for cp idle after halt/unhaltXiaojie Yuan1-2/+12
50us is not enough to wait for cp ready after gpu reset on some navi asics. Signed-off-by: Xiaojie Yuan <[email protected]> Suggested-by: Jack Xiao <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-11-22Revert "drm/amd/display: enable S/G for RAVEN chip"Alex Deucher2-2/+2
This reverts commit 1c4259159132ae4ceaf7c6db37a6cf76417f73d9. S/G display is not stable with the IOMMU enabled on some platforms. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205523 Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.