aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-11-06drm/sched: Fix passing zero to 'PTR_ERR' warning v2Andrey Grodzovsky1-2/+5
Fix a static code checker warning. v2: Drop PTR_ERR_OR_ZERO. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu/discovery: Need to free discovery memoryEmily Deng1-3/+3
When unloading driver, need to free discovery memory. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amd/powerplay: print the pptable providerXiaojie Yuan1-0/+2
So we know where the tables came from. Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06Revert "drm/amd/display: setting the DIG_MODE to the correct value."Zhan Liu1-9/+0
This reverts commit 967a3b85bac91c55eff740e61bf270c2732f48b2. Reason for revert: Root cause of this issue is found. The workaround is not needed anymore. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14Zhan Liu1-0/+5
[Why] Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is because there is no ENGINE_ID_DIGD in Navi14. Without this patch, many HDMI related issues (e.g. HDMI S3 resume failure, HDMI pink screen on boot) will be observed. [How] If "eng_id" is larger than ENGINE_ID_DIGD, then add "eng_id" by 1. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: Show resolution correctly in mode validation debug outputNeil Mayhew1-1/+1
Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Neil Mayhew <neil@neil.mayhew.name> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu/gpuvm: add some additional comments in amdgpu_vm_update_ptesAlex Deucher1-1/+9
To better clarify what is happening in this function. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: enable VCN DPG on Raven and Raven2Alex Deucher1-2/+6
It's safe to enable dynamic VCN powergating on raven and raven2 for increased power savings. Reviewed-by: James Zhu <James.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: add navi14 PCI IDTianci.Yin1-0/+1
Add the navi14 PCI device id. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amd/powerplay: support xgmi pstate setting on powerplay routine V2Evan Quan6-4/+44
Add xgmi pstate setting on powerplay routine. V2: split the change of is_support_sw_smu_xgmi into a separate patch Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amd/powerplay: update is_sw_smu_xgmi checkEvan Quan1-1/+1
Add check for is_sw_smu routine and drop check for amdgpu_dpm which seems non-sense. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: change pstate only after all XGMI device initializedEvan Quan1-3/+12
Pstate settings should be performed after all device of the XGMI setup get initialized. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: add navi14 PCI IDTianci.Yin1-0/+1
Add the navi14 PCI device id. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06Revert "drm/amd/display: setting the DIG_MODE to the correct value."Zhan Liu1-9/+0
This reverts commit 385857adb8154563840e5b0f200254126618f464. Reason for revert: Root cause of this issue is found. The workaround is not needed anymore. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14Zhan Liu1-0/+5
[Why] Navi10 has 6 PHY, but Navi14 only has 5 PHY, that is because there is no ENGINE_ID_DIGD in Navi14. Without this patch, many HDMI related issues (e.g. HDMI S3 resume failure, HDMI pink screen on boot) will be observed. [How] If "eng_id" is larger than ENGINE_ID_DIGD, then add "eng_id" by 1. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu: dont schedule jobs while in resetShirish S1-1/+4
[Why] doing kthread_park()/unpark() from drm_sched_entity_fini while GPU reset is in progress defeats all the purpose of drm_sched_stop->kthread_park. If drm_sched_entity_fini->kthread_unpark() happens AFTER drm_sched_stop->kthread_park nothing prevents from another (third) thread to keep submitting job to HW which will be picked up by the unparked scheduler thread and try to submit to HW but fail because the HW ring is deactivated. [How] grab the reset lock before calling drm_sched_entity_fini() Signed-off-by: Shirish S <shirish.s@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu/arcturus: properly set BANK_SELECT and FRAGMENT_SIZEAlex Deucher1-0/+9
These were not aligned for optimal performance for GPUVM. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/mst: Fix up u64 divisionSean Paul1-2/+2
Change rem_nsec to u32 since that's what do_div returns, this avoids the u64 divide in the drm_print args. Changes in v2: - Instead of doing do_div in drm_print, make rem_nsec u32 (Ville) Link to v1: https://patchwork.freedesktop.org/patch/msgid/20191106173622.15573-1-sean@poorly.run Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for debugging") Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191106194121.164458-1-sean@poorly.run
2019-11-06drm/amdgpu: dont schedule jobs while in resetShirish S1-1/+4
[Why] doing kthread_park()/unpark() from drm_sched_entity_fini while GPU reset is in progress defeats all the purpose of drm_sched_stop->kthread_park. If drm_sched_entity_fini->kthread_unpark() happens AFTER drm_sched_stop->kthread_park nothing prevents from another (third) thread to keep submitting job to HW which will be picked up by the unparked scheduler thread and try to submit to HW but fail because the HW ring is deactivated. [How] grab the reset lock before calling drm_sched_entity_fini() Signed-off-by: Shirish S <shirish.s@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/amdgpu/arcturus: properly set BANK_SELECT and FRAGMENT_SIZEAlex Deucher1-0/+9
These were not aligned for optimal performance for GPUVM. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-11-06drm/atomic: fix self-refresh helpers crtc state dereferenceRob Clark2-8/+25
drm_self_refresh_helper_update_avg_times() was incorrectly accessing the new incoming state after drm_atomic_helper_commit_hw_done(). But this state might have already been superceeded by an !nonblock atomic update resulting in dereferencing an already free'd crtc_state. TODO I *think* this will more or less do the right thing.. althought I'm not 100% sure if, for example, we enter psr in a nonblock commit, and then leave psr in a !nonblock commit that overtakes the completion of the nonblock commit. Not sure if this sort of scenario can happen in practice. But not crashing is better than crashing, so I guess we should either take this patch or rever the self-refresh helpers until Sean can figure out a better solution. Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid thrashing") Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org> [seanpaul fixed up some checkpatch warns] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173737.142558-1-robdclark@gmail.com
2019-11-06drm: msm: a6xx: fix debug bus register configurationSharat Masetty1-12/+12
Fix the cx debugbus related register configuration, to collect accurate bus data during gpu snapshot. This helps with complete snapshot dump and also complete proper GPU recovery. Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/339165
2019-11-06drm/komeda: Use devm_platform_ioremap_resource() in komeda_dev_create()Markus Elfring1-8/+1
Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/64a6ea39-3e4b-2ebe-74f7-98720e581e3e@web.de
2019-11-06drm/i915/gem: Fix error path to unlock if the GEM context is closedChris Wilson1-1/+1
When inside the lock, remember to unlock even if you want to leave early. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191106144155.25727-1-chris@chris-wilson.co.uk
2019-11-06drm/i915/gt: Only drop heartbeat.systole if the sole ownerChris Wilson1-2/+2
Mika spotted that only using cancel_delayed_work() could mean that we attempted to clear the heartbeat.systole while the worker was still running. Rectify the situation by only touching the systole from outside the worker if we suceeded in cancelling the worker before it could run. The worker is expected to clean up by itself upon idling. Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191106133129.17732-1-chris@chris-wilson.co.uk
2019-11-06drm/vmwgfx: Add surface dirty-tracking callbacksThomas Hellstrom3-6/+626
Add the callbacks necessary to implement emulated coherent memory for surfaces. Add a flag to the gb_surface_create ioctl to indicate that surface memory should be coherent. Also bump the drm minor version to signal the availability of coherent surfaces. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-11-06drm/i915/lmem: fixup fake lmem teardownMatthew Auld1-2/+4
We should not be unconditionally calling release_fake_lmem_bar. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191106123135.12441-1-matthew.auld@intel.com
2019-11-06drm/i915: Frob the correct crtc state in intel_crtc_disable_noatomic()Ville Syrjälä1-4/+6
The uapi vs. hw state split introduced a bug in intel_crtc_disable_noatomic() where it's now frobbing an already freed temp crtc state instead of adjusting the crtc state we are really left with. Fix that by making a cleaner separation beteen the two. This causes explosions on any machine that boots up with pipes already running but not hooked up to any encoder (typical behaviour for gen2-4 VBIOS). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 58d124ea2739 ("drm/i915: Complete crtc hw/uapi split, v6.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191105171447.22111-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-11-06drm/vmwgfx: Implement an infrastructure for read-coherent resourcesThomas Hellstrom5-11/+181
Similar to write-coherent resources, make sure that from the user-space point of view, GPU rendered contents is automatically available for reading by the CPU. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-11-06drm/vmwgfx: Use an RBtree instead of linked list for MOB resourcesThomas Hellstrom3-16/+32
With emulated coherent memory we need to be able to quickly look up a resource from the MOB offset. Instead of traversing a linked list with O(n) worst case, use an RBtree with O(log n) worst case complexity. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-11-06drm/i915/gem: Early rejection of no-aperture map_ggttChris Wilson1-0/+3
If the device does not have an aperture through which we can indirectly access and detile the buffers, simply reject the ioctl. Later we can extend the ioctl to support different modes, but as an extension the user must opt in and explicitly control the mmap type (viz MMAP_OFFSET_IOCTL). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191105145305.14314-1-chris@chris-wilson.co.uk
2019-11-06drm/vmwgfx: Implement an infrastructure for write-coherent resourcesThomas Hellstrom11-21/+602
This infrastructure will, for coherent resources, make sure that from the user-space point of view, data written by the CPU is immediately automatically available to the GPU at resource validation time. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rik van Riel <riel@surriel.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-11-06drm/ttm: Convert vm callbacks to helpersThomas Hellstrom1-63/+105
The default TTM fault handler may not be completely sufficient (vmwgfx needs to do some bookkeeping, control the write protectionand also needs to restrict the number of prefaults). Also make it possible replicate ttm_bo_vm_reserve() functionality for, for example, mkwrite handlers. So turn the TTM vm code into helpers: ttm_bo_vm_fault_reserved(), ttm_bo_vm_open(), ttm_bo_vm_close() and ttm_bo_vm_reserve(). Also provide a default TTM fault handler for other drivers to use. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2019-11-06drm/ttm: Remove explicit typecasts of vm_private_dataThomas Hellstrom1-5/+3
The explicit typcasts are meaningless, so remove them. Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2019-11-06drm/ttm: remove ttm_bo_wait_unreservedDaniel Vetter3-50/+5
With nouveau fixed all ttm-using drives have the correct nesting of mmap_sem vs dma_resv, and we can just lock the buffer. Assuming I didn't screw up anything with my audit of course. v2: - Dont forget wu_mutex (Christian König) - Keep the mmap_sem-less wait optimization (Thomas) - Use _lock_interruptible to be good citizens (Thomas) v3: Rebase over fault handler helperification. Reviewed-by: Christian König <christian.koenig@amd.com> (v2) Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-3-daniel.vetter@ffwll.ch
2019-11-06drm/nouveau: slowpath for pushbuf ioctlDaniel Vetter1-19/+38
We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-2-daniel.vetter@ffwll.ch
2019-11-06drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMATvrtko Ursulin1-1/+1
It sounds like the hardware only needs the DSB object to be in global GTT and not in the mappable region. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191017155810.21654-1-tvrtko.ursulin@linux.intel.com
2019-11-06drm/mediatek: Support 180 degree rotationSean Paul1-2/+2
Now that we support both reflections, we can expose 180 degree rotation and rely on the simplify routine to convert that into REFLECT_X | REFLECT_Y Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Support reflect-x plane rotationSean Paul1-1/+9
Add support for REFLECT_X rotations. Cc: Fritz Koenig <frkoenig@chromium.org> Cc: Daniele Castagna <dcastagna@chromium.org> Cc: Miguel Casas <mcasas@chromium.org> Cc: Mark Yacoub <markyacoub@google.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Support reflect-y plane rotationSean Paul1-0/+42
Expose the rotation property and handle REFLECT_Y rotations. Cc: Fritz Koenig <frkoenig@chromium.org> Cc: Daniele Castagna <dcastagna@chromium.org> Cc: Miguel Casas <mcasas@chromium.org> Cc: Mark Yacoub <markyacoub@google.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Plumb supported rotation values from components to plane initSean Paul4-3/+27
This patch adds the ability for components to expose supported rotations which will be exposed to userspace via a plane rotation property. No functional changes in this patch. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Add plumbing for layer_check hookSean Paul4-0/+30
This allows components to implement a .layer_check callback for their layers which is called during atomic_check. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Add helper to get component for a planeSean Paul1-21/+33
Instead of hard-coding which components have planes, add a helper function to walk the components and map a plane index to a component layer. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Refactor plane initSean Paul1-17/+58
Add a couple of functions which enumerate the number of planes for a component and initialize the planes for a component. No functional changes in this patch, but it will allow us to selectively support rotation if the component supports it. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/mediatek: Add RGB[A] variants to published plane formatsSean Paul1-0/+6
These formats are handled in the rdma code, but for some reason they're not published as supported formats for the planes. So add them to the list. Cc: Nicolas Boichat <drinkcat@chromium.org> Cc: Daniele Castagna <dcastagna@chromium.org> Cc: Miguel Casas <mcasas@chromium.org> Tested-by: Miguel Casas <mcasas@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-11-06drm/i915: Don't select BROKENDaniel Vetter1-1/+0
It's broken. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> References: https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191105193829.11599-1-daniel.vetter@ffwll.ch
2019-11-06drm/dp_mst: fix gcc compile errorChenwandun1-1/+1
drivers/gpu/drm/drm_dp_mst_topology.c: In function __topology_ref_save: drivers/gpu/drm/drm_dp_mst_topology.c:1424:6: error: implicit declaration of function stack_trace_save; did you mean stack_depot_save? [-Werror=implicit-function-declaration] n = stack_trace_save(stack_entries, ARRAY_SIZE(stack_entries), 1); ^~~~~~~~~~~~~~~~ stack_depot_save drivers/gpu/drm/drm_dp_mst_topology.c: In function __dump_topology_ref_history: drivers/gpu/drm/drm_dp_mst_topology.c:1513:3: error: implicit declaration of function stack_trace_snprint; did you mean acpi_trace_point? [-Werror=implicit-function-declaration] stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4); ^~~~~~~~~~~~~~~~~~~ acpi_trace_point stack_trace_save and stack_trace_snprint are declared in <linux/stacktrace.h>, so there is need to include it, and <linux/stackdepot.h> is already included by practices, so just replace <linux/stackdepot.h> by <linux/stacktrace.h>. Signed-off-by: Chenwandun <chenwandun@huawei.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1572515029-42087-1-git-send-email-chenwandun@huawei.com
2019-11-05drm/i915/gen8+: Add RC6 CTX corruption WAImre Deak6-4/+135
In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: rebased on gem/gt split (Mika) Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2019-11-05drm/i915: Lower RM timeout to avoid DSI hard hangsUma Shankar2-0/+12
In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL to be turned ON. When MIPI PLL is turned off (MIPI Display is not active or connected), and someone (host or GT engine) tries to read MIPI registers, it causes hard hang. This is a hardware restriction or limitation. Driver by itself doesn't read MIPI registers when MIPI display is off. But any userspace application can submit unprivileged batch buffer for execution. In that batch buffer there can be mmio reads. And these reads are allowed even for unprivileged applications. If these register reads are for MIPI DSI controller and MIPI display is not active during that time, then the MMIO read operation causes system hard hang and only way to recover is hard reboot. A genuine process/application won't submit batch buffer like this and doesn't cause any issue. But on a compromised system, a malign userspace process/app can generate such batch buffer and can trigger system hard hang (denial of service attack). The fix is to lower the internal MMIO timeout value to an optimum value of 950us as recommended by hardware team. If the timeout is beyond 1ms (which will hit for any value we choose if MMIO READ on a DSI specific register is performed without PLL ON), it causes the system hang. But if the timeout value is lower than it will be below the threshold (even if timeout happens) and system will not get into a hung state. This will avoid a system hang without losing any programming or GT interrupts, taking the worst case of lowest CDCLK frequency and early DC5 abort into account. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
2019-11-05drm/i915/cmdparser: Ignore Length operands during command matchingJon Bloomfield1-1/+1
Some of the gen instruction macros (e.g. MI_DISPLAY_FLIP) have the length directly encoded in them. Since these are used directly in the tables, the Length becomes part of the comparison used for matching during parsing. Thus, if the cmd being parsed has a different length to that in the table, it is not matched and the cmd is accepted via the default variable length path. Fix by masking out everything except the Opcode in the cmd tables Cc: Tony Luck <tony.luck@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Chris Wilson <chris.p.wilson@intel.com>