aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2019-10-30drm/amdgpu: fix no ACK from LDS read during stress test for ArcturusLe Ma1-0/+1
Set mmSQ_CONFIG.DISABLE_SMEM_SOFT_CLAUSE as W/R. Signed-off-by: Le Ma <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu: fix gfx VF FLR test fail on naviHaiJun Chang1-0/+1
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 <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu: bypass some cleanup work after err_event_athub (v2)Le Ma4-11/+30
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 <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu: clear UVD VCPU buffer when err_event_athub generatedLe Ma1-1/+9
The err_event_athub error will mess up the buffer and cause UVD resume hang. Signed-off-by: Le Ma <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu/SRIOV: SRIOV VF doesn't support BACOJiange Zhao1-1/+1
SRIOV VF doesn't support BACO. Only PF with BACO capability can do it. Signed-off-by: Jiange Zhao <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu: Remove superfluous void * cast in debugfs_create_file() callGeert Uytterhoeven1-2/+2
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 <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdgpu: remove set but not used variable 'adev'YueHaibing1-9/+0
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 <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdkfd: bug fix for out of bounds mem on gpu cache filling infoAlex Sierra1-1/+1
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 <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdkfd: Delete duplicated queue bit map reservationYong Zhao1-8/+0
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 <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/amdkfd: Delete unnecessary pr_fmt switchYong Zhao4-13/+0
Given amdkfd.ko has been merged into amdgpu.ko, this switch is no longer useful. Signed-off-by: Yong Zhao <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-10-30drm/i915: Avoid HPD poll detect triggering a new detect cycleImre Deak3-0/+19
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 <[email protected]> Reported-and-tested-by: wangqr <[email protected]> Cc: Val Kulkov <[email protected]> Cc: wangqr <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30drm/i915/gt: Always track callers to intel_rps_mark_interactive()Chris Wilson3-6/+9
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 <[email protected]> Cc: Andi Shyti <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30drm/i915/tgl: Add gam instdoneMika Kuoppala3-0/+6
This has been asked from us already. Prepare for the next time. Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30drm/i915/tgl: Add SFC instdone to error stateMika Kuoppala3-0/+19
On debugging media workload hangs, sfc instdone might prove useful in future. Be prepared. Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/tgl: add support to one DP-MST streamLucas De Marchi2-0/+6
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 <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30Merge tag 'topic/mst-suspend-resume-reprobe-2019-10-29-2' of ↵Dave Airlie10-379/+988
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 <[email protected]> From: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/gem: Make context persistence optionalChris Wilson4-1/+67
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 <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: Jon Bloomfield <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30Merge tag 'exynos-drm-next-for-v5.5' of ↵Dave Airlie1-2/+2
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 <[email protected]> # 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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-30Merge tag 'drm-misc-next-2019-10-24-2' of ↵Dave Airlie118-1742/+1624
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 <[email protected]> Cc: Adam Jackson <[email protected]> Cc: Sean Paul <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Kangjie Lu <[email protected]> Cc: Mihail Atanassov <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20191024155535.GA10294@art_vandelay
2019-10-29drm/i915: Provide more information on DP AUX failuresMatt Roper1-2/+4
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 <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lucas De Marchi <[email protected]>
2019-10-30Merge tag 'drm-next-5.5-2019-10-25' of ↵Dave Airlie163-1034/+5791
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 <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/display/cnl+: Handle fused off DSCJosé Roberto de Souza5-0/+10
DSC could be fused off, so not all GEN10+ platforms will support it. Cc: Manasi Navare <[email protected]> Cc: Martin Peres <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/display/icl+: Check if DMC is fused offJosé Roberto de Souza2-0/+4
Check if DMC is fused off and handle it. Cc: Ville Syrjälä <[email protected]> Cc: Martin Peres <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/display: Check if FBC is fused offJosé Roberto de Souza2-0/+4
Check if FBC is fused off and handle it. Cc: Ville Syrjälä <[email protected]> Cc: Martin Peres <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/display: Handle fused off HDCPJosé Roberto de Souza5-1/+8
HDCP could be fused off, so not all GEN9+ platforms will support it. Cc: Ville Syrjälä <[email protected]> Cc: Martin Peres <[email protected]> Reviewed-by: Ramalingam C <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915: Add two spaces before the SKL_DFSM registersJosé Roberto de Souza1-9/+9
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 <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/perf: ensure selftests select valid formatLionel Landwerlin1-1/+2
Gen12 only support a single report format : I915_OA_FORMAT_A32u40_A4u32_B8_C8 Signed-off-by: Lionel Landwerlin <[email protected]> Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmapRob Herring3-3/+10
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 <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rob Herring <[email protected]> Acked-by: Gerd Hoffmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/panfrost: Simplify devfreq utilisation trackingSteven Price4-56/+38
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 <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/panfrost: Use generic code for devfreqSteven Price2-52/+10
Use dev_pm_opp_set_rate() instead of open coding the devfreq integration, simplifying the code. Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Tomeu Vizoso <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Signed-off-by: Steven Price <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/tgl: Add AUX B & C to DC_OFF_POWER_DOMAINSMatt Roper1-0/+2
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 <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2019-10-29drm/i915: Drop unused AUX register offsetsMatt Roper2-43/+10
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 <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/gt: Make timeslice duration configurableChris Wilson6-18/+69
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 <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915: Rename "inject_load_failure" module parameterJanusz Krzysztofik3-7/+7
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 <[email protected]> Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: Michał Wajdeczko <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: Piotr Piórkowski <[email protected]> Cc: Tomasz Lis <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915: Fix i915_inject_load_error() name to read *_probe_*Janusz Krzysztofik7-25/+27
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 <[email protected]> Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: Michał Wajdeczko <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: Piotr Piórkowski <[email protected]> Cc: Tomasz Lis <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/tegra: Optionally attach clients to the IOMMUThierry Reding2-18/+49
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 <[email protected]>
2019-10-29drm/tegra: Support DMA API for display controllersThierry Reding4-6/+120
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 <[email protected]>
2019-10-29drm/tegra: falcon: Clarify address usageThierry Reding3-41/+34
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 <[email protected]>
2019-10-29drm/tegra: Remove memory allocation from Falcon libraryThierry Reding3-84/+68
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 <[email protected]>
2019-10-29gpu: host1x: Support DMA mapping of buffersThierry Reding1-3/+15
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 <[email protected]>
2019-10-29gpu: host1x: Add direction flags to relocationsThierry Reding1-0/+2
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 <[email protected]>
2019-10-29gpu: host1x: Overhaul host1x_bo_{pin,unpin}() APIThierry Reding1-4/+30
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 <[email protected]>
2019-10-29drm/tegra: Simplify IOMMU group selectionThierry Reding6-20/+25
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 <[email protected]>
2019-10-29drm/tegra: Do not use ->load() and ->unload() callbacksThierry Reding1-167/+154
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2019-10-29drm/i915: Fix i845/i865 cursor widthVille Syrjälä1-1/+1
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 <[email protected]> Fixes: 3a612765f423 ("drm/i915: Remove cursor use of properties for coordinates") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Maarten Lankhorst <[email protected]>
2019-10-29drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_createHans de Goede1-1/+1
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 <[email protected]> Fixes: 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation") Signed-off-by: Hans de Goede <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/tgl: Add perf support on TGLLionel Landwerlin6-35/+560
The design of the OA unit has been split into several units. We now have a global unit (OAG) and a render specific unit (OAR). This leads to some changes on how we program things. Some details : OAR: - has its own set of counter registers, they are per-context saved/restored - counters are not written to the circular OA buffer - a snapshot of the counters can be acquired with MI_RECORD_PERF_COUNT, or a single counter can be read with MI_STORE_REGISTER_MEM. OAG: - has global counters that increment across context switches - counters are written into the circular OA buffer (if requested) v2: Fix checkpatch warnings on code style (Lucas) v3: (Umesh) - Update register from which tail, status and head are read - Update logic to sample context reports - Update whitelist mux and b counter regs v4: Fix a bug when updating context image for new contexts (Umesh) v5: Squash patch enabling save/restore of counters into context image We want this so we can preempt performance queries and keep the system responsive even when long running queries are ongoing. We avoid doing it for all contexts. - use LRI to modify context control (Chris) - use MASKED_FIELD to program just the masked bits (Chris) - disable save/restore of counters on cleanup (Chris) v6: Do not use implicit parameters (Chris) BSpec: 28727, 30021 Signed-off-by: Lionel Landwerlin <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Acked-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/perf: Add helper macros for comparing with whitelisted registersUmesh Nerlige Ramappa1-26/+28
Add helper macros for range and equality comparisons and use them to check with whitelisted registers in oa configurations. Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Signed-off-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915/selftests: check for missing apertureMatthew Auld5-5/+29
We may be missing support for the mappable aperture on some platforms. Signed-off-by: Matthew Auld <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-29drm/i915: don't allocate the ring in stolen if we lack apertureMatthew Auld1-1/+3
Since we have no way access it from the CPU. For such cases just fallback to internal objects. Signed-off-by: Matthew Auld <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.