aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-10-17drm/amd/display: fix incorrect page table address for renoirBhawanpreet Lakha1-6/+17
Incorrect page table address and programming sys aperture for stutter gather, so fix it. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: enable hostvm based on roimmu active for dcn2.1Dmytro Laktyushkin1-15/+25
Enabling hostvm when ROIMMU is not active seems to break GPUVM. This fixes the issue by not enabling hostvm if ROIMMU is not activated. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: move the bounding box patch before calculate wmLewis Huang1-0/+25
[why] driver updateis the dcn2_1_soc into dml before call update_bw_bounding_box [How] Move the patch function before calculate wm. Signed-off-by: Lewis Huang <Lewis.Huang@amd.com> Signed-off-by: joseph graveno <joseph.gravenor@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: add REFCYC_PER_TRIP_TO_MEMORY programmingBhawanpreet Lakha4-4/+69
it allows us to do urgent latency programming Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: create dcn21_link_encoder filesBhawanpreet Lakha6-4/+555
[Why] DCN20 and DCN21 have different phy programming sequences. [How] Create a separate dcn21_link_encoder for Renoir Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: Add renoir hw_seqBhawanpreet Lakha7-28/+255
This change adds renoir hw_seq, needed to do renoir specific hw programing Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: Add DCN_BASE regsBhawanpreet Lakha1-0/+34
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: Add DP_DPHY_INTERNAL_CTR regsBhawanpreet Lakha1-0/+10
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: disable ext aux support for vegaRoman Li1-1/+1
[Why] Earlier changes to support configurable aux timeout caused dc init failure on vega due to missing reg defs. Needs to be disabled until implemented for vega. [How] Set extended aux timeout cap for vega to false. Signed-off-by: Roman Li <Roman.Li@amd.com> Reviewed-By: abdoulaye berthe <abdoulaye.berthe@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: configurable aux timeout supportabdoulaye berthe15-17/+132
[Description] 1-add configurable timeout support to aux engine. 2-add timeout support field to dc_caps 3-add reg_key to override extended timeout support Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/display: update register field access mechanismabdoulaye berthe10-12/+271
1-add timeout length and multiplier fields to aux_control1 register 2-update access mechanism from macro constructed name to uint32_t defined addresses. 3-define registers and field per asic family Signed-off-by: abdoulaye berthe <abdoulaye.berthe@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amdgpu: No need to check gfxoff status after enable gfxoff featurechen gong1-9/+0
smu_send_smc_msg(smu, SMU_MSG_AllowGfxOff) Just turn on a switch. As to when GPU get into "GFXoff" will be up to drawing load. So we can not sure which state GPU should be in after enable gfxoff feature. Signed-off-by: chen gong <curry.gong@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amd/powerplay: bug fix for memory clock request from displayKenneth Feng1-0/+2
In some cases, display fixes memory clock frequency to a high value rather than the natural memory clock switching. When we comes back from s3 resume, the request from display is not reset, this causes the bug which makes the memory clock goes into a low value. Then due to the insuffcient memory clock, the screen flicks. Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Jack Xiao <Jack.Xiao@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amdgpu: fix S3 failed as RLC safe mode entry stucked in polloing gfx acqPrike Liang2-5/+4
Fix gfx cgpg setting sequence for RLC deadlock at safe mode entry in polling gfx response. The patch can fix VCN IB test failed and DAL get dispaly count failed issue. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/amdgpu: add GFX_PIPELINE capacity check for updating gfx cgpgPrike Liang1-1/+2
Before disable gfx pipeline power gating need check the flag AMD_PG_SUPPORT_GFX_PIPELINE. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-17drm/i915/selftests: Teach requests to use all available enginesChris Wilson1-112/+175
The request selftests straddle the boundary between checking the driver and the hardware. They are subject to the quirks of the underlying HW, but operate on top of the backend abstractions. The tests focus on the scheduler elements and so should check for interactions of the scheduler across all exposed engines. 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/20191016125236.17960-1-chris@chris-wilson.co.uk
2019-10-18Merge tag 'drm-fixes-5.4-2019-10-16' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie6-46/+38
drm-fixes-5.4-2019-10-16: amdgpu: - Powerplay fix for SMU7 parts - Bail earlier when cik/si support is not set to 1 - Fix an SDMA issue on navi radeon: - revert a PPC fix which broken x86 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191017022443.3853-1-alexander.deucher@amd.com
2019-10-17drm/i915/huc: improve documentationDaniele Ceraolo Spurio2-19/+31
Better explain the usage of the microcontroller and what i915 is responsible of. While at it, fix the documentation for the auth function, which doesn't do any pinning anymore. v2: add a comment on HuC being optional and descrive how HuC accesses memory (Martin) v3: add extra newline for better text organization (Martin) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Acked-by: Anna Karas <anna.karas@intel.com> Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-3-daniele.ceraolospurio@intel.com
2019-10-17drm/i915/guc: improve documentationDaniele Ceraolo Spurio3-5/+35
Add a short description of what we expect from GuC and some minor improvements to existing documentation. Also remove a comment about a difference between GuC and HuC that is not true anymore. v2: add that the GuC is not mandatory (Martin) v3: add extra newline for better text organization (Martin) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Acked-by: Anna Karas <anna.karas@intel.com> Reviewed-by: Martin Peres <martin.peres@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014183602.3643-2-daniele.ceraolospurio@intel.com
2019-10-17drm/lima: add __GFP_NOWARN flag to all dma_alloc_wcQiang Yu2-3/+3
This prevent CMA printing dumy "PFNs busy" info which is caused by alloc fail re-try case. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010140152.17747-4-yuq825@gmail.com
2019-10-17drm/lima: use drm_gem_(un)lock_reservationsQiang Yu1-58/+6
Simplify the driver code with DRM GEM helper function. v2: improve commit comment. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010140152.17747-3-yuq825@gmail.com
2019-10-17drm/lima: use drm_gem_shmem_helpersQiang Yu12-357/+142
Do not need to maintain our own shmem memory management code as drm_gem_shmem_helpers provides it. And we can also benifit from the work of others with shared code. This is also a preparation for implementing buffer madv. Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010140152.17747-2-yuq825@gmail.com
2019-10-17drm/qxl: Fix randbuild errorYueHaibing1-0/+1
If DEM_QXL is y and DRM_TTM_HELPER is m, building fails: drivers/gpu/drm/qxl/qxl_object.o: undefined reference to `drm_gem_ttm_print_info' Select DRM_TTM_HELPER to fix this. Fixes: 78d54f1f6a33 ("drm/qxl: use drm_gem_ttm_print_info") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191008024054.32368-1-yuehaibing@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-17drm/cirrus: Remove obsolete header fileThomas Zimmermann1-247/+0
The cirrus driver's header file is left over from a recent rewrite. Remove it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20191017113427.2167-1-tzimmermann@suse.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-17drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONSGerd Hoffmann5-20/+5
Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-12-kraxel@redhat.com
2019-10-17drm/vram: drop verify_accessGerd Hoffmann1-22/+0
Not needed any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-11-kraxel@redhat.com
2019-10-17drm/vram: switch vram helper to &drm_gem_object_funcs.mmap()Gerd Hoffmann1-33/+1
Wire up the new drm_gem_ttm_mmap() helper function, use generic drm_gem_mmap for &fops.mmap and delete dead drm_vram_mm_file_operations_mmap(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-10-kraxel@redhat.com
2019-10-17drm/ttm: add drm_gem_ttm_mmap()Gerd Hoffmann1-0/+17
Add helper function to mmap ttm bo's using &drm_gem_object_funcs.mmap(). Note that with this code path access verification is done by drm_gem_mmap() (which calls drm_vma_node_is_allowed(()). The &ttm_bo_driver.verify_access() callback is is not used. v3: use ttm_bo_mmap_obj instead of ttm_bo_mmap_vma_setup Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-9-kraxel@redhat.com
2019-10-17drm/ttm: rename ttm_fbdev_mmapGerd Hoffmann2-7/+6
Rename ttm_fbdev_mmap to ttm_bo_mmap_obj. Move the vm_pgoff sanity check to amdgpu_bo_fbdev_mmap (only ttm_fbdev_mmap user in tree). The ttm_bo_mmap_obj function can now be used to map any buffer object. This allows to implement &drm_gem_object_funcs.mmap in gem ttm helpers. v3: patch added to series Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-8-kraxel@redhat.com
2019-10-17drm/ttm: factor out ttm_bo_mmap_vma_setupGerd Hoffmann1-22/+24
Factor out ttm vma setup to a new function. Reduces code duplication a bit. v2: don't change vm_flags (moved to separate patch). v4: make ttm_bo_mmap_vma_setup static. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-7-kraxel@redhat.com
2019-10-17drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPSGerd Hoffmann5-5/+5
DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now, drop it. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-6-kraxel@redhat.com
2019-10-17drm/shmem: drop VM_IOGerd Hoffmann1-1/+1
VM_IO is wrong here, shmem uses normal ram not io memory. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-5-kraxel@redhat.com
2019-10-17drm/shmem: drop VM_DONTDUMPGerd Hoffmann1-1/+1
Not obvious why this is needed. According to Deniel Vetter this is most likely a historic artefact dating back to the days where drm drivers exposed hardware registers as mmap'able gem objects, to avoid dumping touching those registers. shmem gem objects surely don't need that ... Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-4-kraxel@redhat.com
2019-10-17drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmapGerd Hoffmann4-21/+13
Switch gem shmem helper to the new mmap() workflow, from &gem_driver.fops.mmap to &drm_gem_object_funcs.mmap. v2: Fix vm_flags and vm_page_prot handling. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-3-kraxel@redhat.com
2019-10-17drm: add mmap() to drm_gem_object_funcsGerd Hoffmann2-9/+27
drm_gem_object_funcs->vm_ops alone can't handle everything which needs to be done for mmap(), tweaking vm_flags for example. So add a new mmap() callback to drm_gem_object_funcs where this code can go to. Note that the vm_ops field is not used in case the mmap callback is present, it is expected that the callback sets vma->vm_ops instead. Also setting vm_flags and vm_page_prot is the job of the new callback. so drivers have more control over these flags. drm_gem_mmap_obj() will use the new callback for object specific mmap setup. With this in place the need for driver-speific fops->mmap callbacks goes away, drm_gem_mmap can be hooked instead. drm_gem_prime_mmap() will use the new callback too to just mmap gem objects directly instead of jumping though loops to make drm_gem_object_lookup() and fops->mmap work. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20191016115203.20095-2-kraxel@redhat.com
2019-10-17drm/i915: Fix MST oops due to MSA changesVille Syrjälä1-1/+3
The MSA MISC computation now depends on the connector state, and we do it from the DDI .pre_enable() hook. All that is fine for DP SST but with MST we don't actually pass the connector state to the dig port's .pre_enable() hook which leads to an oops. Need to think more how to solve this in a cleaner fashion, but for now let's just add a NULL check to stop the oopsing. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Fixes: 0c06fa156006 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015190538.27539-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-10-17drm/i915/pmu: Support multiple GPUsTvrtko Ursulin2-2/+31
With discrete graphics system can have both integrated and discrete GPU handled by i915. Currently we use a fixed name ("i915") when registering as the uncore PMU provider which stops working in this case. To fix this we add the PCI device name string to non-integrated devices handled by us. Integrated devices keep the legacy name preserving backward compatibility. v2: * Detect IGP and keep legacy name. (Michal) * Use PCI device name as suffix. (Michal, Chris) v3: * Constify the name. (Chris) * Use pci_domain_nr. (Chris) v4: * Fix kfree_const usage. (Chris) v5: * kfree_const does not work for modules. (Chris) * Changed is_igp helper to take i915. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191016093802.12483-1-tvrtko.ursulin@linux.intel.com
2019-10-16drm/i915/tgl: Enable DDI/Port GKhaled Almahallawy5-0/+16
In TGL there we are missing the initialization of port G. Do the same as for other ports. Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008220905.18278-1-khaled.almahallawy@intel.com
2019-10-16drm/i810: Refer to `PREEMPTION' in commentSebastian Andrzej Siewior1-1/+1
The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect this change in the comment. Use `PREEMPTION' in the comment. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191015191821.11479-29-bigeasy@linutronix.de
2019-10-16drm/i915: Move swizzle_bit under i915_ggttChris Wilson6-24/+25
The HW performs swizzling as part of its fence tiling inside the Global GTT. We already do the probing of the HW settings from the GGTT setup, complete the picture by storing the information as part of the GGTT. The primary benefit is the consistency of our probe routines do not break the i915_ggtt encapsulation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-2-chris@chris-wilson.co.uk
2019-10-16drm/i915: Store i915_ggtt as the backpointer on fence registersChris Wilson7-41/+54
Now that i915_ggtt knows everything about its own paths to perform mmio, we can use that as our primary backpointer for individual fence registers. This reduces the amount of pointer dancing we have to perform on the common paths, but more importantly finishes our fence register encapsulation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-1-chris@chris-wilson.co.uk
2019-10-16drm/i915: Do initial mocs configuration directlyChris Wilson3-219/+65
Now that we record the default "goldenstate" context, we do not need to emit the mocs registers at the start of each context and can simply do mmio before the first context and capture the registers as part of its default image. As a consequence, this means that we repeat the mmio after each engine reset, fixing up any platform and registers that were zapped by the reset (for those platforms with global not context-saved settings). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111723 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111645 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016090749.7092-1-chris@chris-wilson.co.uk
2019-10-16drm/i915: Fixup preempt-to-busy vs resubmission of a virtual requestChris Wilson1-6/+26
As preempt-to-busy leaves the request on the HW as the resubmission is processed, that request may complete in the background and even cause a second virtual request to enter queue. This second virtual request breaks our "single request in the virtual pipeline" assumptions. Furthermore, as the virtual request may be completed and retired, we lose the reference the virtual engine assumes is held. Normally, just removing the request from the scheduler queue removes it from the engine, but the virtual engine keeps track of its singleton request via its ve->request. This pointer needs protecting with a reference. v2: Drop unnecessary motion of rq->engine = owner Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk (cherry picked from commit b647c7df01b75761b4c0b1cb6f4841088c0b1121) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16drm/i915/userptr: Never allow userptr into the mappable GGTTChris Wilson5-1/+19
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to invalidate userptr objects which also happen to be pulled into GGTT mmaps. That is when we unbind the userptr object (on mmu invalidation), we revoke all CPU mmaps, which may then recurse into mmu invalidation. We looked for ways of breaking the cycle, but the revocation on invalidation is required and cannot be avoided. The only solution we could see was to not allow such GGTT bindings of userptr objects in the first place. In practice, no one really wants to use a GGTT mmapping of a CPU pointer... Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got a genuine blip from CI: <4>[ 246.793958] ====================================================== <4>[ 246.793972] WARNING: possible circular locking dependency detected <4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U <4>[ 246.794003] ------------------------------------------------------ <4>[ 246.794017] kswapd0/145 is trying to acquire lock: <4>[ 246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794250] but task is already holding lock: <4>[ 246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0 <4>[ 246.794291] which lock already depends on the new lock. <4>[ 246.794307] the existing dependency chain (in reverse order) is: <4>[ 246.794322] -> #3 (&anon_vma->rwsem){++++}: <4>[ 246.794344] down_write+0x33/0x70 <4>[ 246.794357] __vma_adjust+0x3d9/0x7b0 <4>[ 246.794370] __split_vma+0x16a/0x180 <4>[ 246.794385] mprotect_fixup+0x2a5/0x320 <4>[ 246.794399] do_mprotect_pkey+0x208/0x2e0 <4>[ 246.794413] __x64_sys_mprotect+0x16/0x20 <4>[ 246.794429] do_syscall_64+0x55/0x1c0 <4>[ 246.794443] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794456] -> #2 (&mapping->i_mmap_rwsem){++++}: <4>[ 246.794478] down_write+0x33/0x70 <4>[ 246.794493] unmap_mapping_pages+0x48/0x130 <4>[ 246.794519] i915_vma_revoke_mmap+0x81/0x1b0 [i915] <4>[ 246.794519] i915_vma_unbind+0x11d/0x4a0 [i915] <4>[ 246.794519] i915_vma_destroy+0x31/0x300 [i915] <4>[ 246.794519] __i915_gem_free_objects+0xb8/0x4b0 [i915] <4>[ 246.794519] drm_file_free.part.0+0x1e6/0x290 <4>[ 246.794519] drm_release+0xa6/0xe0 <4>[ 246.794519] __fput+0xc2/0x250 <4>[ 246.794519] task_work_run+0x82/0xb0 <4>[ 246.794519] do_exit+0x35b/0xdb0 <4>[ 246.794519] do_group_exit+0x34/0xb0 <4>[ 246.794519] __x64_sys_exit_group+0xf/0x10 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #1 (&vm->mutex){+.+.}: <4>[ 246.794519] i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915] <4>[ 246.794519] i915_address_space_init+0x9f/0x160 [i915] <4>[ 246.794519] i915_ggtt_init_hw+0x55/0x170 [i915] <4>[ 246.794519] i915_driver_probe+0xc9f/0x1620 [i915] <4>[ 246.794519] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 246.794519] pci_device_probe+0x9e/0x120 <4>[ 246.794519] really_probe+0xea/0x3d0 <4>[ 246.794519] driver_probe_device+0x10b/0x120 <4>[ 246.794519] device_driver_attach+0x4a/0x50 <4>[ 246.794519] __driver_attach+0x97/0x130 <4>[ 246.794519] bus_for_each_dev+0x74/0xc0 <4>[ 246.794519] bus_add_driver+0x13f/0x210 <4>[ 246.794519] driver_register+0x56/0xe0 <4>[ 246.794519] do_one_initcall+0x58/0x300 <4>[ 246.794519] do_init_module+0x56/0x1f6 <4>[ 246.794519] load_module+0x25bd/0x2a40 <4>[ 246.794519] __se_sys_finit_module+0xd3/0xf0 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #0 (&dev->struct_mutex/1){+.+.}: <4>[ 246.794519] __lock_acquire+0x15d8/0x1e90 <4>[ 246.794519] lock_acquire+0xa6/0x1c0 <4>[ 246.794519] __mutex_lock+0x9d/0x9b0 <4>[ 246.794519] userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794519] __mmu_notifier_invalidate_range_start+0x85/0x110 <4>[ 246.794519] try_to_unmap_one+0x76b/0x860 <4>[ 246.794519] rmap_walk_anon+0x104/0x280 <4>[ 246.794519] try_to_unmap+0xc0/0xf0 <4>[ 246.794519] shrink_page_list+0x561/0xc10 <4>[ 246.794519] shrink_inactive_list+0x220/0x440 <4>[ 246.794519] shrink_node_memcg+0x36e/0x740 <4>[ 246.794519] shrink_node+0xcb/0x490 <4>[ 246.794519] balance_pgdat+0x241/0x580 <4>[ 246.794519] kswapd+0x16c/0x530 <4>[ 246.794519] kthread+0x119/0x130 <4>[ 246.794519] ret_from_fork+0x24/0x50 <4>[ 246.794519] other info that might help us debug this: <4>[ 246.794519] Chain exists of: &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem <4>[ 246.794519] Possible unsafe locking scenario: <4>[ 246.794519] CPU0 CPU1 <4>[ 246.794519] ---- ---- <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&mapping->i_mmap_rwsem); <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&dev->struct_mutex/1); <4>[ 246.794519] *** DEADLOCK *** v2: Say no to mmap_ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk (cherry picked from commit a4311745bba9763e3c965643d4531bd5765b0513) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pinVille Syrjälä1-6/+16
The first come first served apporoach to handling the VBT child device AUX ch conflicts has backfired. We have machines in the wild where the VBT specifies both port A eDP and port E DP (in that order) with port E being the real one. So let's try to flip the preference around and let the last child device win once again. Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Masami Ichikawa <masami256@gmail.com> Tested-by: Torsten <freedesktop201910@liggy.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 41e35ffb380bde1379e4030bb5b2ac824d5139cf) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16drm/i915/execlists: Refactor -EIO markup of hung requestsChris Wilson1-14/+17
Pull setting -EIO on the hung requests into its own utility function. Having allowed ourselves to short-circuit submission of completed requests, we can now do the mark_eio() prior to submission and avoid some redundant operations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk (cherry picked from commit 0d7cf7bc15e75bf79f2f65d61d19f896609f816a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16drm/i915/selftests: Teach timelines to take intel_gt as its argumentChris Wilson1-23/+25
The timelines selftests are [mostly] hardware centric and so want to use the gt as its target. 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/20191016113840.1106-1-chris@chris-wilson.co.uk
2019-10-16drm/i915/selftests: Teach workarounds to take intel_gt as its argumentChris Wilson1-63/+65
The workarounds selftests are hardware centric and so want to use the gt as its target. 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/20191016114902.24388-1-chris@chris-wilson.co.uk
2019-10-16drm/i915/selftests: Teach guc to take intel_gt as its argumentChris Wilson1-28/+14
The guc selftests are hardware^W firmare centric and so want to use the gt as its target. 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/20191016115311.12894-1-chris@chris-wilson.co.uk
2019-10-16drm/i915/selftests: Teach execlists to take intel_gt as its argumentChris Wilson1-147/+143
The execlists selftests are hardware centric and so want to use the gt as its target. 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/20191016120249.22714-1-chris@chris-wilson.co.uk
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.