summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2019-10-30drm/amdgpu/gmc10: properly set BANK_SELECT and FRAGMENT_SIZEAlex Deucher
These were not aligned for optimal performance for GPUVM. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Tianci Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: fix no ACK from LDS read during stress test for ArcturusLe Ma
Set mmSQ_CONFIG.DISABLE_SMEM_SOFT_CLAUSE as W/R. Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: fix gfx VF FLR test fail on naviHaiJun Chang
Cp wptr in wb buffer is outdated after VF FLR. The outdated wptr may cause cp to execute unexpected packets. Reset cp wptr in wb buffer. Signed-off-by: HaiJun Chang <HaiJun.Chang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: bypass some cleanup work after err_event_athub (v2)Le Ma
PSP lost connection when err_event_athub occurs. These cleanup work can be skipped in BACO reset. v2: squash in missing include (Alex) Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <hawking.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: clear UVD VCPU buffer when err_event_athub generatedLe Ma
The err_event_athub error will mess up the buffer and cause UVD resume hang. Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <hawking.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu/SRIOV: SRIOV VF doesn't support BACOJiange Zhao
SRIOV VF doesn't support BACO. Only PF with BACO capability can do it. Signed-off-by: Jiange Zhao <Jiange.Zhao@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: Remove superfluous void * cast in debugfs_create_file() callGeert Uytterhoeven
There is no need to cast a typed pointer to a void pointer when calling a function that accepts the latter. Remove it, as the cast prevents further compiler checks. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdgpu: remove set but not used variable 'adev'YueHaibing
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1221:24: warning: variable adev set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:488:24: warning: variable adev set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:547:24: warning: variable adev set but not used [-Wunused-but-set-variable] It is never used, so can removed it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdkfd: bug fix for out of bounds mem on gpu cache filling infoAlex Sierra
The bitmap in cu_info structure is defined as a 4x4 size array. In Acturus, this matrix is initialized as a 4x2. Based on the 8 shaders. In the gpu cache filling initialization, the access to the bitmap matrix was done as an 8x1 instead of 4x2. Causing an out of bounds memory access error. Due to this, the number of GPU cache entries was inconsistent. Signed-off-by: Alex Sierra <alex.sierra@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdkfd: Delete duplicated queue bit map reservationYong Zhao
The KIQ is on the second MEC and its reservation is covered in the latter logic, so no need to reserve its bit twice. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/amdkfd: Delete unnecessary pr_fmt switchYong Zhao
Given amdkfd.ko has been merged into amdgpu.ko, this switch is no longer useful. Signed-off-by: Yong Zhao <Yong.Zhao@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-30drm/i915: Avoid HPD poll detect triggering a new detect cycleImre Deak
For the HPD interrupt functionality the HW depends on power wells in the display core domain to be on. Accordingly when enabling these power wells the HPD polling logic will force an HPD detection cycle to account for hotplug events that may have happened when such a power well was off. Thus a detect cycle started by polling could start a new detect cycle if a power well in the display core domain gets enabled during detect and stays enabled after detect completes. That in turn can lead to a detection cycle runaway. To prevent re-triggering a poll-detect cycle make sure we drop all power references we acquired during detect synchronously by the end of detect. This will let the poll-detect logic continue with polling (matching the off state of the corresponding power wells) instead of scheduling a new detection cycle. Fixes: 6cfe7ec02e85 ("drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112125 Reported-and-tested-by: Val Kulkov <val.kulkov@gmail.com> Reported-and-tested-by: wangqr <wqr.prg@gmail.com> Cc: Val Kulkov <val.kulkov@gmail.com> Cc: wangqr <wqr.prg@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191028181517.22602-1-imre.deak@intel.com
2019-10-30drm/i915/gt: Always track callers to intel_rps_mark_interactive()Chris Wilson
During startup, we may find ourselves in an interesting position where we haven't fully enabled RPS before the display starts trying to use it. This may lead to an imbalance in our "interactive" counter: <3>[ 4.813326] intel_rps_mark_interactive:652 GEM_BUG_ON(!rps->power.interactive) <4>[ 4.813396] ------------[ cut here ]------------ <2>[ 4.813398] kernel BUG at drivers/gpu/drm/i915/gt/intel_rps.c:652! <4>[ 4.813430] invalid opcode: 0000 [#1] PREEMPT SMP PTI <4>[ 4.813438] CPU: 1 PID: 18 Comm: kworker/1:0H Not tainted 5.4.0-rc5-CI-CI_DRM_7209+ #1 <4>[ 4.813447] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017 <4>[ 4.813525] Workqueue: events_highpri intel_atomic_cleanup_work [i915] <4>[ 4.813589] RIP: 0010:intel_rps_mark_interactive+0xb3/0xc0 [i915] <4>[ 4.813597] Code: bc 3f de e0 48 8b 35 84 2e 24 00 49 c7 c0 f3 d4 4e a0 b9 8c 02 00 00 48 c7 c2 80 9c 48 a0 48 c7 c7 3e 73 34 a0 e8 8d 3b e5 e0 <0f> 0b 90 66 2e 0f 1f 84 00 00 00 00 00 80 bf c0 00 00 00 00 74 32 <4>[ 4.813616] RSP: 0018:ffffc900000efe00 EFLAGS: 00010286 <4>[ 4.813623] RAX: 000000000000000e RBX: ffff8882583cc7f0 RCX: 0000000000000000 <4>[ 4.813631] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888275969c00 <4>[ 4.813639] RBP: 0000000000000000 R08: 0000000000000008 R09: ffff888275ace000 <4>[ 4.813646] R10: ffffc900000efe00 R11: ffff888275969c00 R12: ffff8882583cc8d8 <4>[ 4.813654] R13: ffff888276abce00 R14: 0000000000000000 R15: ffff88825e878860 <4>[ 4.813662] FS: 0000000000000000(0000) GS:ffff888276a80000(0000) knlGS:0000000000000000 <4>[ 4.813672] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 4.813678] CR2: 00007f051d5ca0a8 CR3: 0000000262f48001 CR4: 00000000003606e0 <4>[ 4.813686] Call Trace: <4>[ 4.813755] intel_cleanup_plane_fb+0x4e/0x60 [i915] <4>[ 4.813764] drm_atomic_helper_cleanup_planes+0x4d/0x70 <4>[ 4.813833] intel_atomic_cleanup_work+0x15/0x80 [i915] <4>[ 4.813842] process_one_work+0x26a/0x620 <4>[ 4.813850] worker_thread+0x37/0x380 <4>[ 4.813857] ? process_one_work+0x620/0x620 <4>[ 4.813864] kthread+0x119/0x130 <4>[ 4.813870] ? kthread_park+0x80/0x80 <4>[ 4.813878] ret_from_fork+0x3a/0x50 <4>[ 4.813887] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul btusb btrtl btbcm btintel snd_hda_intel snd_intel_nhlt snd_hda_codec bluetooth snd_hwdep snd_hda_core ghash_clmulni_intel snd_pcm e1000e ecdh_generic ecc ptp pps_core mei_me mei prime_numbers <4>[ 4.813934] ---[ end trace c13289af88174ffc ]--- The solution employed is to not worry about RPS state and keep the tally of the interactive counter separate. When we do enable RPS, we will then take the display activity into account. Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Acked-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191030103827.2413-1-chris@chris-wilson.co.uk
2019-10-30drm/i915/tgl: Add gam instdoneMika Kuoppala
This has been asked from us already. Prepare for the next time. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> 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/20191029163841.5224-2-mika.kuoppala@linux.intel.com
2019-10-30drm/i915/tgl: Add SFC instdone to error stateMika Kuoppala
On debugging media workload hangs, sfc instdone might prove useful in future. Be prepared. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> 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/20191029163841.5224-1-mika.kuoppala@linux.intel.com
2019-10-29drm/i915/tgl: add support to one DP-MST streamLucas De Marchi
This is the minimum change to support 1 (and only 1) DP-MST monitor connected on Tiger Lake. This change was isolated from previous patch from José. In order to support more streams we will need to create a master-slave relation on the transcoders and that is not currently working yet. v2: remove unused macro and use REG_FIELD_PREP() (Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191029035049.5907-1-lucas.demarchi@intel.com
2019-10-30Merge tag 'topic/mst-suspend-resume-reprobe-2019-10-29-2' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next UAPI Changes: Cross-subsystem Changes: Core Changes: * Handle UP requests asynchronously in the DP MST helpers, fixing hotplug notifications and allowing us to implement suspend/resume reprobing * Add basic suspend/resume reprobing to the DP MST helpers * Improve locking for link address reprobing and connection status request handling in the DP MST helpers * Miscellaneous refactoring in the DP MST helpers * Add a Kconfig option to the DP MST helpers to enable tracking of gets/puts for topology references for debugging purposes Driver Changes: * nouveau: Resume hotplug interrupts earlier, so that sideband messages may be transmitted during resume and thus allow suspend/resume reprobing for DP MST to work * nouveau: Avoid grabbing runtime PM references when handling short DP pulses, so that handling sideband messages in resume codepaths with the DP MST helpers doesn't deadlock us * i915, nouveau, amdgpu, radeon: Use detect_ctx for probing MST connectors, so that we can grab the topology manager's atomic lock Note: there's some amdgpu patches that I didn't realize were pushed upstream already when creating this topic branch. When they fail to apply, you can just ignore and skip them. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/a74c6446bc960190d195a751cb6d8a00a98f3974.camel@redhat.com
2019-10-29drm/i915/gem: Make context persistence optionalChris Wilson
Our existing behaviour is to allow contexts and their GPU requests to persist past the point of closure until the requests are complete. This allows clients to operate in a 'fire-and-forget' manner where they can setup a rendering pipeline and hand it over to the display server and immediately exit. As the rendering pipeline is kept alive until completion, the display server (or other consumer) can use the results in the future and present them to the user. The compute model is a little different. They have little to no buffer sharing between processes as their kernels tend to operate on a continuous stream, feeding the results back to the client application. These kernels operate for an indeterminate length of time, with many clients wishing that the kernel was always running for as long as they keep feeding in the data, i.e. acting like a DSP. Not all clients want this persistent "desktop" behaviour and would prefer that the contexts are cleaned up immediately upon closure. This ensures that when clients are run without hangchecking (e.g. for compute kernels of indeterminate runtime), any GPU hang or other unexpected workloads are terminated with the process and does not continue to hog resources. The default behaviour for new contexts is the legacy persistence mode, as some desktop applications are dependent upon the existing behaviour. New clients will have to opt in to immediate cleanup on context closure. If the hangchecking modparam is disabled, so is persistent context support -- all contexts will be terminated on closure. We expect this behaviour change to be welcomed by compute users, who have often been caught between a rock and a hard place. They disable hangchecking to avoid their kernels being "unfairly" declared hung, but have also experienced true hangs that the system was then unable to clean up. Naturally, this leads to bug reports. Testcase: igt/gem_ctx_persistence Link: https://github.com/intel/compute-runtime/pull/228 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30Merge tag 'exynos-drm-next-for-v5.5' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Fix a build warning at mixer driver - it fixes a build warning message, 'static' is not at beginning of declaration [-Wold-style-declaration], by moving static keyword. Signed-off-by: Dave Airlie <airlied@redhat.com> # gpg: Signature made Mon 28 Oct 2019 10:31:25 PM AEST # gpg: using RSA key 020570887DBBB9A5 # gpg: Can't check signature: public key not found From: Inki Dae <daeinki@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191028123434.30034-1-daeinki@gmail.com
2019-10-30Merge tag 'drm-misc-next-2019-10-24-2' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.5: UAPI Changes: -syncobj: allow querying the last submitted timeline value (David) -fourcc: explicitly defineDRM_FORMAT_BIG_ENDIAN as unsigned (Adam) -omap: revert the OMAP_BO_* flags that were added -- no userspace (Sean) Cross-subsystem Changes: -MAINTAINERS: add Mihail as komeda co-maintainer (Mihail) Core Changes: -edid: a few cleanups, add AVI infoframe bar info (Ville) -todo: remove i915 device_link item and add difficulty levels (Daniel) -dp_helpers: add a few new helpers to parse dpcd (Thierry) Driver Changes: -gma500: fix a few memory disclosure leaks (Kangjie) -qxl: convert to use the new drm_gem_object_funcs.mmap (Gerd) -various: open code dp_link helpers in preparation for helper removal (Thierry) Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Kangjie Lu <kjlu@umn.edu> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191024155535.GA10294@art_vandelay
2019-10-29drm/i915: Provide more information on DP AUX failuresMatt Roper
We're seeing some failures where an aux transaction still shows as 'busy' well after the timeout limit that the hardware is supposed to enforce. Improve the error message so that we can see exactly which aux channel this error happened on and what the status bits were during this case that isn't supposed to happen. v2: - Make timeout a const variable so that the timeout & message will match if we decide to change it in the future. (Lucas) - Don't bother testing intel_dp->aux.name for NULL. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191029173102.9451-1-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2019-10-30Merge tag 'drm-next-5.5-2019-10-25' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.5-2019-10-25: amdgpu: - BACO support for CI and VI asics - Quick memory training support for navi - MSI-X support - RAS fixes - Display AVI infoframe fixes - Display ref clock fixes for renoir - Fix number of audio endpoints in renoir - Fix for discovery tables - Powerplay fixes - Documentation fixes - Misc cleanups radeon: - revert a PPC fix which broke x86 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191025221020.203546-1-alexander.deucher@amd.com
2019-10-29drm/i915/display/cnl+: Handle fused off DSCJosé Roberto de Souza
DSC could be fused off, so not all GEN10+ platforms will support it. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-5-jose.souza@intel.com
2019-10-29drm/i915/display/icl+: Check if DMC is fused offJosé Roberto de Souza
Check if DMC is fused off and handle it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-4-jose.souza@intel.com
2019-10-29drm/i915/display: Check if FBC is fused offJosé Roberto de Souza
Check if FBC is fused off and handle it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-3-jose.souza@intel.com
2019-10-29drm/i915/display: Handle fused off HDCPJosé Roberto de Souza
HDCP could be fused off, so not all GEN9+ platforms will support it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-2-jose.souza@intel.com
2019-10-29drm/i915: Add two spaces before the SKL_DFSM registersJosé Roberto de Souza
The next patches are going to touch this registers so here already fixing it for older registers and make it consistent with most of the other registers in this file. Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191026001323.216052-1-jose.souza@intel.com
2019-10-29drm/i915/perf: ensure selftests select valid formatLionel Landwerlin
Gen12 only support a single report format : I915_OA_FORMAT_A32u40_A4u32_B8_C8 Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") 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/20191029142826.20014-1-lionel.g.landwerlin@intel.com
2019-10-29drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmapRob Herring
Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs") introduced a GEM object mmap() hook which is expected to subtract the fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not a fake offset. To fix this, let's always call mmap() object callback with an offset of 0, and leave it up to drm_gem_mmap_obj() to remove the fake offset. TTM still needs the fake offset, so we have to add it back until that's fixed. Fixes: c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191024191859.31700-1-robh@kernel.org
2019-10-29drm/panfrost: Simplify devfreq utilisation trackingSteven Price
Instead of tracking per-slot utilisation track a single value for the entire GPU. Ultimately it doesn't matter if the GPU is busy with only vertex or a combination of vertex and fragment processing - if it's busy then it's busy and devfreq should be scaling appropriately. This also makes way for being able to submit multiple jobs per slot which requires more values than the original boolean per slot. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191025134143.14324-3-steven.price@arm.com
2019-10-29drm/panfrost: Use generic code for devfreqSteven Price
Use dev_pm_opp_set_rate() instead of open coding the devfreq integration, simplifying the code. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191025134143.14324-2-steven.price@arm.com
2019-10-29drm/i915/tgl: Add AUX B & C to DC_OFF_POWER_DOMAINSMatt Roper
Our TGL CI platforms are running into cases where aux transactions have failed to complete or declare a timeout well after the timeout limit that the hardware is supposed to enforce. From the logs it appears that these failures arise when aux transactions happen after we've entered DC6: <7> [622.523650] [drm:skl_enable_dc6 [i915]] Enabling DC6 <7> [622.523685] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02 ... <3> [622.535753] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout! <3> [622.547745] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout! <3> [622.559746] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout! <3> [622.571744] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout! <3> [622.583743] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not signal timeout! <3> [622.583780] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp_aux_ch not done status 0xad400bff <7> [622.863725] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110 On TGL AUX B & C are in PG1 (managed by the DMC firmware) rather than PG3 as they were on ICL, so allowing DC6 means the DMC firmware might shut off the power wells behind our backs when we're trying to use them. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191025230623.27829-6-matthew.d.roper@intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-10-29drm/i915: Drop unused AUX register offsetsMatt Roper
We reference DP AUX registers via the DP_AUX_CH_CTL() and DP_AUX_CH_DATA() macros that calculate all the register offsets for us automatically; there's no need to explicitly define every offset in i915_reg.h if they're never going to be used by the driver code. v2: Apparently GVT was directly using these raw definitions in a couple places. Switch GVT code over to using our preferred macros. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191026051226.30807-1-matthew.d.roper@intel.com
2019-10-29drm/i915/gt: Make timeslice duration configurableChris Wilson
Execlists uses a scheduling quantum (a timeslice) to alternate execution between ready-to-run contexts of equal priority. This ensures that all users (though only if they of equal importance) have the opportunity to run and prevents livelocks where contexts may have implicit ordering due to userspace semaphores. However, not all workloads necessarily benefit from timeslicing and in the extreme some sysadmin may want to disable or reduce the timeslicing granularity. The timeslicing mechanism can be compiled out^W^W disabled (but should DCE!) with ./scripts/config --set-val DRM_I915_TIMESLICE_DURATION 0 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191029091632.26281-1-chris@chris-wilson.co.uk
2019-10-29drm/i915: Rename "inject_load_failure" module parameterJanusz Krzysztofik
Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe" consequently") deliberately left the name of the module parameter unchanged as that would require a corresponding change on IGT size. Now as the IGT side change has been submitted, complete the switch to the "probe" nomenclature. Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> 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/20191029102036.6326-3-janusz.krzysztofik@linux.intel.com
2019-10-29drm/i915: Fix i915_inject_load_error() name to read *_probe_*Janusz Krzysztofik
Commit 50d84418f586 ("drm/i915: Add i915 to i915_inject_probe_failure") introduced new functions unfortunately named incompatibly with rules established by commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe" consequently"). Fix it for consistency. Suggested-by: Michał Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> 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/20191029102036.6326-2-janusz.krzysztofik@linux.intel.com
2019-10-29drm/tegra: Optionally attach clients to the IOMMUThierry Reding
If a client is already attached to an IOMMU domain that is not the shared domain, don't try to attach it again. This allows using the IOMMU-backed DMA API. Since the IOMMU-backed DMA API is now supported and there's no way to detach from it on 64-bit ARM, don't bother to detach from it on 32-bit ARM either. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/tegra: Support DMA API for display controllersThierry Reding
If a display controller is not attached to an explicit IOMMU domain, which usually means that it's connected to an IOMMU domain controlled by the DMA API, make sure to map the framebuffer to the display controller address space. This allows us to transparently handle setups where the display controller is attached to an IOMMU or setups where it isn't. It also allows the driver to work with a DMA API that is backed by an IOMMU. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/tegra: falcon: Clarify address usageThierry Reding
Rename paddr -> iova and vaddr -> virt to make it clearer how these addresses are used. This is important for a subsequent patch that makes a distinction between the physical address (physical address of the system memory from the CPU's point of view) and the IOVA (physical address of the system memory from the device's point of view). Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/tegra: Remove memory allocation from Falcon libraryThierry Reding
Having to provide allocator hooks to the Falcon library is somewhat cumbersome and it doesn't give the users of the library a lot of flexibility to deal with allocations. Instead, remove the notion of Falcon "operations" and let drivers deal with the memory allocations themselves. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Set DMA mask based on IOMMU setupThierry Reding
If the Tegra DRM clients are backed by an IOMMU, push buffers are likely to be allocated beyond the 32-bit boundary if sufficient system memory is available. This is problematic on earlier generations of Tegra where host1x supports a maximum of 32 address bits for the GATHER opcode. More recent versions of Tegra (Tegra186 and later) have a wide variant of the GATHER opcode, which allows addressing up to 64 bits of memory. If host1x itself is behind an IOMMU as well this doesn't matter because the IOMMU's input address space is restricted to 32 bits on generations without support for wide GATHER opcodes. However, if host1x is not behind an IOMMU, it won't be able to process push buffers beyond the 32-bit boundary on Tegra generations that don't support wide GATHER opcodes. Restrict the DMA mask to 32 bits on these generations prevents buffers from being allocated from beyond the 32-bit boundary. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Support DMA mapping of buffersThierry Reding
If host1x_bo_pin() returns an SG table, create a DMA mapping for the buffer. For buffers that the host1x client has already mapped itself, host1x_bo_pin() returns NULL and the existing DMA address is used. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Allocate gather copy for host1xThierry Reding
Currently when the gather buffers are copied, they are copied to a buffer that is allocated for the host1x client that wants to execute the command streams in the buffers. However, the gather buffers will be read by the host1x device, which causes SMMU faults if the DMA API is backed by an IOMMU. Fix this by allocating the gather buffer copy for the host1x device, which makes sure that it will be mapped into the host1x's IOVA space if the DMA API is backed by an IOMMU. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Add direction flags to relocationsThierry Reding
Add direction flags to host1x relocations performed during job pinning. These flags indicate the kinds of accesses that hardware is allowed to perform on the relocated buffers. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Clean up debugfs on removalThierry Reding
The debugfs files created for host1x are never removed, causing these files to be left dangling in debugfs. This results in a crash when any of these files are accessed after the host1x driver has been removed, as well as a failure to create the debugfs entries when they are added again on driver probe. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29gpu: host1x: Overhaul host1x_bo_{pin,unpin}() APIThierry Reding
The host1x_bo_pin() and host1x_bo_unpin() APIs are used to pin and unpin buffers during host1x job submission. Pinning currently returns the SG table and the DMA address (an IOVA if an IOMMU is used or a physical address if no IOMMU is used) of the buffer. The DMA address is only used for buffers that are relocated, whereas the host1x driver will map gather buffers into its own IOVA space so that they can be processed by the CDMA engine. This approach has a couple of issues. On one hand it's not very useful to return a DMA address for the buffer if host1x doesn't need it. On the other hand, returning the SG table of the buffer is suboptimal because a single SG table cannot be shared for multiple mappings, because the DMA address is stored within the SG table, and the DMA address may be different for different devices. Subsequent patches will move the host1x driver over to the DMA API which doesn't work with a single shared SG table. Fix this by returning a new SG table each time a buffer is pinned. This allows the buffer to be referenced by multiple jobs for different engines. Change the prototypes of host1x_bo_pin() and host1x_bo_unpin() to take a struct device *, specifying the device for which the buffer should be pinned. This is required in order to be able to properly construct the SG table. While at it, make host1x_bo_pin() return the SG table because that allows us to return an ERR_PTR()-encoded error code if we need to, or return NULL to signal that we don't need the SG table to be remapped and can simply use the DMA address as-is. At the same time, returning the DMA address is made optional because in the example of command buffers, host1x doesn't need to know the DMA address since it will have to create its own mapping anyway. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/tegra: Simplify IOMMU group selectionThierry Reding
All the devices that make up the DRM device are now part of the same IOMMU group. This simplifies the handling of the IOMMU attachment and also avoids exhausting the number of IOMMUs available on early Tegra SoC generations. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/tegra: Do not use ->load() and ->unload() callbacksThierry Reding
The ->load() and ->unload() drivers are midlayers and should be avoided in modern drivers. Fix this by moving the code into the driver ->probe() and ->remove() implementations, respectively. v2: kick out conflicting framebuffers before initializing fbdev v3: rebase onto drm/tegra/for-next Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-29drm/i915: Fix i845/i865 cursor widthVille Syrjälä
The change from the uapi coordinates to the internal coordinates broke the cursor on i845/i865 due to src and dst getting swapped. Fix it. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 3a612765f423 ("drm/i915: Remove cursor use of properties for coordinates") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191028113036.27553-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-10-29drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_createHans de Goede
Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation") removed the diy framebuffer code from the vboxvideo driver, resulting in a nice cleanup. But since the vboxvideo driver needs the generic dirty tracking code, it's drm_mode_config_funcs.fb_create should be set to drm_gem_fb_create_with_dirty not drm_gem_fb_create. This commit fixes this, fixing the framebuffer not always updating. Cc: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191028133159.236550-1-hdegoede@redhat.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 15:30:27 +0000