[Why]
Receive warning message below:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:380: warning: Function
parameter or member 'crc_rd_wrk' not described in 'amdgpu_display_manager'
[How]
Add documentation for crc_rd_wrk.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The pmfw structs are specific to the asic and should not be
present in base clk_mgr struct
v2: squash in SI fix (Alex)
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Dcn2.1 socclk entries in bandwidth params are not initialized.
They are not used now, but will be needed for dml validation.
[How]
Populate socclk bw params from dpm clock table
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Roman Li <roman.li@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To make size is 4 byte aligned. Use &~0x3ULL instead of &3ULL.
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Instead of blocking varied unsupported MP1 state in upper level,
defer and skip such MP1 state handling in specific ASIC.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Guchun Chen <guchun.chen@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Skip PP_MP1_STATE_NONE in MP1 state setting, otherwise, it will
break S3 sequence.
[ 50.188269] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* SMC failed to set mp1 state 0, -22
[ 50.969901] amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
[ 50.970024] sd 0:0:0:0: [sda] Starting disk
[ 50.979723] serial 00:02: activated
[ 51.353644] ata4: SATA link down (SStatus 4 SControl 300)
[ 51.353669] ata3: SATA link down (SStatus 4 SControl 300)
[ 51.353747] ata6: SATA link down (SStatus 4 SControl 300)
[ 51.357694] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 51.357711] ata5: SATA link down (SStatus 4 SControl 300)
[ 51.357729] ata2: SATA link down (SStatus 4 SControl 300)
[ 51.358005] ata1.00: supports DRM functions and may not be fully accessible
[ 51.360491] ata1.00: supports DRM functions and may not be fully accessible
[ 51.362573] ata1.00: configured for UDMA/133
[ 51.362610] ahci 0000:00:17.0: port does not support device sleep
[ 51.362946] ata1.00: Enabling discard_zeroes_data
[ 52.566438] amdgpu 0000:03:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state!
[ 54.126316] amdgpu 0000:03:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state!
[ 54.126317] amdgpu 0000:03:00.0: amdgpu: Failed to SetDriverDramAddr!
[ 54.126318] amdgpu 0000:03:00.0: amdgpu: Failed to setup smc hw!
[ 54.126319] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <smu> failed -62
[ 54.126398] amdgpu 0000:03:00.0: amdgpu: amdgpu_device_ip_resume failed (-62).
[ 54.126399] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -62
[ 54.126403] PM: Device 0000:03:00.0 failed to resume async: error -62
Fixes: 1689fca0d6 ("drm/amd/pm: fix Navi1x runtime resume failure V2")
Signed-off-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Guchun Chen <guchun.chen@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
refactor AMDGPU_PP_SENSOR_GPU_LOAD to ensure code consistency with other
commands
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix size comparison in the resource cursor.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit 098214999c added fetching of the AUX_DPHY register
values from the vbios, but it also changed the default values
in the case when there are no values in the vbios. This causes
problems with displays with high refresh rates. To fix this,
switch back to the original default value for AUX_DPHY_TX_CONTROL.
Fixes: 098214999c ("drm/amd/display: Read VBIOS Golden Settings Tbl")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1426
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Igor Kravchenko <Igor.Kravchenko@amd.com>
Cc: Aric Cyr <Aric.Cyr@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Replace GFP_KERNEL with GFP_ATOMIC as dcn20_resource_construct()
can't sleep.
Partially fixes: https://bugzilla.kernel.org/show_bug.cgi?id=212311
as dcn20_resource_construct() also calls into SMU functions which does
mutex_lock().
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function ‘bw_calcs_init’:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2726:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
v2: squash in sizeof fix
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function ‘calculate_bandwidth’:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: warning: the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:527:17: warning: no previous prototype for ‘dce80_aux_engine_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:565:20: warning: no previous prototype for ‘dce80_i2c_hw_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:581:20: warning: no previous prototype for ‘dce80_i2c_sw_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:715:22: warning: no previous prototype for ‘dce80_link_encoder_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:754:22: warning: no previous prototype for ‘dce80_clock_source_create’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:778:6: warning: no previous prototype for ‘dce80_clock_source_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:868:6: warning: no previous prototype for ‘dce80_validate_bandwidth’ [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:913:16: warning: no previous prototype for ‘dce80_validate_global’ [-Wmissing-prototypes]
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Anthony Koo <Anthony.Koo@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The RLC was put into a wrong state on runtime suspend. Thus the RLC
autoload will fail on the succeeding runtime resume. By adding an
intermediate PPSMC_MSG_PrepareMp1ForUnload(some GC hard reset involved,
designed for PnP), we can bring RLC back into the desired state.
V2: integrate INTERRUPTS_ENABLED flag clearing into current
mp1 state set routines
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable clockgating for VCN and JPEG blocks on aldebaran
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
s/traing/training/
...Plus the entire sentence construction for better readability.
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If userptr pages have been pinned but not bounded,
they remain uncleared.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Gomez <daniel@qtec.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If userptr pages have been pinned but not bounded,
they remain uncleared.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Gomez <daniel@qtec.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
GFX is in gfxoff mode during s0ix so we shouldn't need to
actually tear anything down and restore it.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We handle it properly within the CG/PG functions directly
now.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Not needed as the device is in gfxoff state so the CG/PG state
is handled just like it would be for gfxoff during runtime gfxoff.
This should also prevent delays on resume.
Reworked from Pratik's original patch (Alex)
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Provide and explanation as to why we skip GFX and PSP for
S0ix. GFX goes into gfxoff, same as runtime, so no need
to tear down and re-init. PSP is part of the always on
state, so no need to touch it.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The SMU expects CGPG to be enabled when entering S0ix.
with this we can re-enable SMU suspend.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This really needs to be done to properly tear down
the device. SMC, PSP, and GFX are still problematic,
need to dig deeper into what aspect of them that is
problematic.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No functional change.
v2: use correct dev
v3: rework
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move the non-DC specific code into the DCE IP blocks similar
to how we handle DC. This cleans up the common suspend
and resume pathes.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Vram is system memory, so no need to evict.
v2: use PM_EVENT messages
v3: use correct dev
v4: use driver flags
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Set flags at the top level pmops callbacks to track
state. This cleans up the current set of flags and
properly handles S4 on S0ix capable systems.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
During system hibernation suspend still need un-gate gfx CG/PG firstly to handle HW
status check before HW resource destory.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There's no need to keep vgaswitcheroo around for HG
systems. They don't use muxes and their power control
is handled via ACPI.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Once the device has runtime suspended, we don't need to power it
back up again for system suspend. Likewise for resume, we don't
to power up the device again on resume only to power it back off
again via runtime pm because it's still idle.
v2: add DPM_FLAG_SMART_PREPARE as well
Reviewed-by: Evan Quan <evan.quan@amd.com>
Acked-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> (v1)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
as per:
https://www.kernel.org/doc/html/latest/driver-api/pm/devices.html
The prepare callback is required to support the DPM_FLAG_SMART_SUSPEND
driver flag. This allows runtime pm to auto complete when the
system goes into suspend avoiding a wake up on suspend and on resume.
Apply this for hybrid gfx and BOCO systems where d3cold is
provided by the ACPI platform.
v2: check if device is runtime suspended in prepare.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Added a new parameter and forgot to update the documentation.
Fixes: b6f91fc183 ("drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work")
Reviewed-by: Xiaogang Chen <xiaogang.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Xiaogang Chen <xiaogang.chen@amd.com>
KIQ ring is being operated by kfd as well as amdgpu.
KFD is using kiq lock, we should the same from amdgpu side
as well.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 33cf440d59.
And it will enable mode-2 gpu reset for vangogh,
it asks PSP firmware version is 00.1A.00.0F or newer.
Signed-off-by: Xiaojian Du <Xiaojian.Du@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When recovery thread has begun GPU reset, there should be not other
threads to access hardware, otherwise system randomly hang.
v2 (chk): rewritten from scratch, use trylock and lockdep instead of
hand wiring the logic.
v3: add in_irq check
v4: change to check in_task
Signed-off-by: Dennis Li <Dennis.Li@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Fix use-after-free in xen.
- Reduce fifo threshold on hvs4 to fix a fifo full error.
- Disable TE support for Droid4 and N950.
- Small compiler fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAmBwDwIACgkQ/lWMcqZw
E8MWag/+I50pINOURmQ2RneFatmc+Fj/C0+6KU0FKLAZFvFEsgbtzmJL2Dm8cPqA
liThf85WEkjzf8PupN7mSvXlGqc9EywnPYr8estXo08GSGCxAjbs7+4p4UkeGhyh
5N/rK5NodV2mG65l5YLl5NRlqoQEkcmKyU/NztWgrU/1GgBM08lIxrRIIbWw1C5I
MvmzPDt/S9EP9A1S7LcStTGtU3Ir4TvzL5bEzKkBOgv9v7aqCW6VEyrjq2MdYJ3F
8NWd84UGaM5QHdQm5YI2bujtWBmwcb1d5dNww4JdrfIZPmXj1f2gl5PLfFis+SxA
Gbf6nNyMJ+eiFm6gJHrb1HqxcPzMo/qB2JQQqKDLM8J+sP90aJzZIAq2Iwe85RuV
rwTTsNhKYk0sqNJPLqqO5cI9bmmd7XC8UJpAXqY3t6zDLVE+iilkYcQy/VmsgPgC
PF60aO+uBem1CSdXOvLDBgGhcH2xoXIZ1RLmT2JvwQjlTl2tWHYRVbs03+moz00X
OonR/q96xvbfrQghd++JeLpoCbrOu1v8LzJLm43MB44x08sB4AGFNRob4UryQnyL
/XqoywaMCC/9EzZiNvmORkDZnKJ/UTtn1IyiQnkl/suY850PUuaCz+HI+9FmcYnz
OoWBDNsOh/bCJKMMo4S+t0oNxDYZ7QXnMk2UflD8Vf98vjFKQX0=
=iots
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2021-04-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.12-rc7:
- Fix use-after-free in xen.
- Reduce fifo threshold on hvs4 to fix a fifo full error.
- Disable TE support for Droid4 and N950.
- Small compiler fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e7647dd9-60c3-9dfd-a377-89d717212e13@linux.intel.com
During crtc disable, display perf structures are reset to 0
which includes state varibles which are immutable. On crtc
enable, we use the same structures and they don't refelect
the actual values
1) Fix is to avoid updating the state structures during disable.
2) Reset the perf structures during atomic check when there is no
modeset enable.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Reported-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/1616158446-19290-1-git-send-email-kalyan_t@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
If pp autorefresh is up (from bootloader splash), we will surely get
vblank and pp timeouts. Ensure it is turned off.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Link: https://lore.kernel.org/r/20210406214726.131534-4-marijn.suijten@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Leaving this at a close-to-maximum register value 0xFFF0 means it takes
very long for the MDSS to generate a software vsync interrupt when the
hardware TE interrupt doesn't arrive. Configuring this to double the
vtotal (like some downstream kernels) leads to a frame to take at most
twice before the vsync signal, until hardware TE comes up.
In this case the hardware interrupt responsible for providing this
signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at
all. This solves severe panel update issues observed on at least the
Xperia Loire and Tone series, until said gpio is properly hooked up to
an irq.
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210406214726.131534-2-marijn.suijten@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fix the following coccicheck warning:
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING:
use scnprintf or sprintf
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com
list_sort() internally casts the comparison function passed to it
to a different type with constant struct list_head pointers, and
uses this pointer to call the functions, which trips indirect call
Control-Flow Integrity (CFI) checking.
Instead of removing the consts, this change defines the
list_cmp_func_t type and changes the comparison function types of
all list_sort() callers to use const pointers, thus avoiding type
mismatches.
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com
Checkpatch was complaining about this - there's no need for us to print
errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
let's fix that before converting things to make checkpatch happy.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-20-lyude@redhat.com
As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device instead of being a grandchild of the DRM device.
Since we're about to add a backpointer to a DP AUX channel's respective DRM
device, let's fix this so that we don't potentially allow userspace to use
the AUX channel before we've associated it with it's DRM connector.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-3-lyude@redhat.com
Experimentally have found PV on hvs4 reports fifo full
error with expected settings and does not with one less
This appears as:
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:82:crtc-3] flip_done timed out
with bit 10 of PV_STAT set "HVS driving pixels when the PV FIFO is full"
Fixes: c8b75bca92 ("drm/vc4: Add KMS support for Raspberry Pi.")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161328.1471556-3-maxime@cerno.tech
The vc4_plane_atomic_async_update function assigns twice in a row the
src_h field in the drm_plane_state structure to the same value. Remove
the second one.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161328.1471556-2-maxime@cerno.tech
The dp->train_set[] for this driver is only two characters, not four so
this memsets too much. Fortunately, this ends up corrupting a struct
hole and not anything important.
Fixes: d76271d226 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/YGLwCBMotnrKZu6P@mwanda
If tbo.mem.bus.caching is cached, buffer is intended to be mapped
as cached from CPU. Map it with ioremap_cache.
This wasn't necessary before as device memory was never mapped
as cached from CPU side. It becomes necessary for aldebaran as
device memory is mapped cached from CPU.
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Christian Konig <Christian.Koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1614638628-10508-1-git-send-email-Oak.Zeng@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence is exported and queried with SYNC_IOC_FILE_INFO
should match when the fence's status was changed from the perspective of
userspace, which is during the respective ioctl.
When a static stub fence started being used in by these ioctls, this
behavior changed. Instead, the timestamp returned by SYNC_IOC_FILE_INFO
became the first time anything used the static stub fence, which has no
meaning to userspace.
Signed-off-by: David Stevens <stevensd@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408095428.3983055-1-stevensd@google.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while
compiling lontium-lt8912b.c
drivers/gpu/drm/bridge/lontium-lt8912b.c: In function
‘lt8912_hard_power_on’:
drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit
declaration of function ‘gpiod_set_value_cansleep’; did you mean
‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration]
gpiod_set_value_cansleep(lt->gp_reset, 0);
^~~~~~~~~~~~~~~~~~~~~~~~
gpio_set_value_cansleep
drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’:
drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit
declaration of function ‘devm_gpiod_get_optional’; did you mean
‘devm_gpio_request_one’? [-Werror=implicit-function-declaration]
gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
^~~~~~~~~~~~~~~~~~~~~~~
devm_gpio_request_one
drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’
undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’?
gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
^~~~~~~~~~~~~~
GPIOF_INIT_HIGH
Signed-off-by: Zhang Jianhua <zhangjianhua18@huawei.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408093822.207917-1-zhangjianhua18@huawei.com
We need to enable MC CAC for mclk switching to work.
Fixes: d765129a71 ("drm/amd/pm: correct sclk/mclk dpm enablement")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1561
Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly
Fixes: 230c079fdc ("drm/ttm: make num_pages uint32_t")
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly
Fixes: 230c079fdc ("drm/ttm: make num_pages uint32_t")
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Driver Changes:
- Prepare for local/device memory support on DG1 by starting
to use it for kernel internal allocations: context, ring
and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)
- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)
- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YGxksaZGXHnFxlwg@jlahtine-mobl.ger.corp.intel.com
1. Fine tune the line time for EOTp.
2. Add support mt8192 dpi.
3. Make crtc config-updating atomic.
4. Don't support hdmi connector creation.
-----BEGIN PGP SIGNATURE-----
iQJMBAABCgA2FiEEACwLKSDmq+9RDv5P4cpzo8lZTiQFAmBqxRIYHGNodW5rdWFu
Zy5odUBrZXJuZWwub3JnAAoJEOHKc6PJWU4kWdEQAIZPQks9r5kWnRQJoh4EiiqU
vupem3HbmGk2dtmJhZVr2URgmWCFeFPJ8sImN7qmECgBlGUH+0DW26+o3/nWUSjl
6wCWGl7RSPigsvoVkuJHKFnQMJTVAuaPjF77rs/TyExBxIk5vIwDvxOTCRaairyT
j90V78Wjx3EtSfTgw/RY3MSaLWmBN48VENRiQepM5AahG+DS3wg/eYsW6yNd0aM5
utxyhkH+25donMr+Dhs6XbqN+c5b90AiL+YdXh4oOZfncds9+FIwJ6/n8RHImBoE
gRo02AjewHjwcg60xcbn+hzH5ezoqUxjSbv5OH8IRd2IN03LYpQRzBEr2+Qijm5I
zO1Yg9n9pF8VAKXj60n1PMxfd6yRPAFYRHMKgotSwI5APSOA7oe6bNmK3JuL0XEy
SgvFXXe9OSqFbu+ZSXWuX/CCLfUH94adAMs9UJTLMHVxCGdiBvppdKAV/kkrIs7z
qLI/697ZMbszYZzw2OBzCY5DKEEPgs9rcH4VfZiwr4n+bvOO2+PLxy3Avg+/kVJv
gsfMjM5kU/HUvmPkXULvmEYl3ED2G6YOlNU6WhYyHw7sc/epYv4iCt7bL5EHIwcF
Om6vxIASWctSZoig71p7r+OvymfHDY/s+u/oWwQXTwOjBn0aVCLqP4JWTag5pYB1
RmiKV3Ch0iyuWEP2Xw/H
=VClB
-----END PGP SIGNATURE-----
Merge tag 'mediatek-drm-next-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next
Mediatek DRM Next for Linux 5.13
1. Fine tune the line time for EOTp.
2. Add support mt8192 dpi.
3. Make crtc config-updating atomic.
4. Don't support hdmi connector creation.
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
intel_dsm_platform_mux_info() tries to parse the ACPI package data
from _DSM for the debug information, but it assumes the fixed format
without checking what values are stored in the elements actually.
When an unexpected value is returned from BIOS, it may lead to GPF or
NULL dereference, as reported recently.
Add the checks of the contents in the returned values and skip the
values for invalid cases.
v1->v2: Check the info contents before dereferencing, too
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de
(cherry picked from commit 337d7a1621)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Why]
DCN3 is not reusing DCN1 mask_sh_list, causing
SURFACE_FLIP_INT_MASK missing in the mapping.
[How]
Add the corresponding entry to DCN3 list.
Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some irqs which are applicable for sdm845 target are no
longer applicable for sc7180 and sc7280 targets. Add a
flag to indicate the irqs which are obsolete for a
particular target so that these irqs are skipped while
checking for matching irq lookup index.
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1617688895-26275-4-git-send-email-mkrishn@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently, each register in the dpu interrupt set is allowed
to have a maximum of 32 interrupts. With the introduction
of INTF_5_VSYNC and INTF_5_UNDERRUN irqs for EDP panel,
the total number of interrupts under INTR_STATUS register
in dpu_irq_map will exceed 32. Increase the range of each
interrupt register to 64 to handle this.
This patch has dependency on the below series:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=461193
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1617688895-26275-2-git-send-email-mkrishn@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The reset value of INTF_CONFIG2 register is changed
for SC7280 family. Changes are added to program
this register correctly based on the target.
DATA_HCTL_EN in INTF_CONFIG2 register allows data
to be transferred at a different rate than video
timing. When this is set, the number of data per
line follows DISPLAY_DATA_HCTL register value.
This change adds support to program these
registers for sc7280 target.
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1617685792-14376-5-git-send-email-mkrishn@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
A new register called CTL_FETCH_ACTIVE is introduced in
SC7280 family which is used to inform the HW about
the pipes which are active in the current ctl path.
This change adds support to program this register
based on the active pipes in the current composition.
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1617685792-14376-4-git-send-email-mkrishn@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Interface block offsets are different for SC7280 family
when compared to existing targets. These offset values
are used to access the interface irq registers. This
change adds proper interface offsets for SC7280 target.
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1617685792-14376-3-git-send-email-mkrishn@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Now that tracking is wired up for potentially evictable GEM objects,
wire up shrinker and the remaining GEM bits for unpinning backing pages
of inactive objects.
Disabled by default for now, with an 'enable_eviction' module param to
enable so that we can get some more testing on the range of generations
(and iommu pairings) supported.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-9-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Shoot down any mmap's *first* before put_pages(). Also add a WARN_ON
that the object is locked (to make it clear that this doesn't race with
msm_gem_fault()) and remove a redundant WARN_ON (since is_purgable()
already covers that case).
Fixes: 68209390f1 ("drm/msm: shrinker support")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-8-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Objects that are potential for swapping out are (1) willneed (ie. if
they are purgable/MADV_WONTNEED we can just free the pages without them
having to land in swap), (2) not on an active list, (3) not dma-buf
imported or exported, and (4) not vmap'd. This repurposes the purged
list for objects that do not have backing pages (either because they
have not been pinned for the first time yet, or in a later patch because
they have been unpinned/evicted.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-7-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently nearly everything, other than newly allocated objects which
are not yet backed by pages, is pinned and resident in RAM. But it will
be nice to have some stats on what is unpinned once that is supported.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-6-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently these always go together, either when we purge MADV_WONTNEED
objects or when the object is freed. But for unpin, we want to be able
to purge (unmap from iommu) the vma, while keeping the iova range
allocated (so we can remap back to the same GPU virtual address when the
object is re-pinned.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-5-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently this doesn't matter since we keep the pages pinned until the
object is destroyed. But when we start unpinning pages to allow objects
to be evicted to swap, it will.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-4-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
So we don't have to duplicate the boilerplate for eviction.
This also lets us re-use the main scan loop for vmap shrinker.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-3-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
If you mess something up, you don't really need to see the same warn on
splat 4000 times pumped out a slow debug UART port..
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20210405174532.1441497-2-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently DPU driver scales bandwidth and core clock for sc7180 only,
while the rest of chips get static bandwidth votes. Make all chipsets
scale bandwidth and clock per composition requirements like sc7180 does.
Drop old voting path completely.
Tested on RB3 (SDM845) and RB5 (SM8250).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210401020533.3956787-2-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fill clk_inefficiency_factor, bw_inefficiency_factor and
min_prefill_lines in hw catalog data for sdm845 and sm8[12]50.
Efficiency factors are blindly copied from sc7180 data, while
min_prefill_lines is based on downstream display driver.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210401020533.3956787-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
SM8250 platform has a 8-Levels VIG QoS setting. This setting was missed
due to bad interaction with b8dab65b5a ("drm/msm/dpu: Move
DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks"), which was applied in
parallel.
Fixes: d21fc5dfc3 ("drm/msm/dpu1: add support for qseed3lite used on sm8250")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210318105435.2011222-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Phy driver already knows the source PLL id basing on the set usecase and
the current PLL id. Stop passing it to the phy_enable call. As a
reminder, dsi manager will always use DSI 0 as a clock master in a slave
mode, so PLL 0 is always a clocksource for DSI 0 and it is always a
clocksource for DSI 1 too unless DSI 1 is used in the standalone mode.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210331105735.3690009-25-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The src_truthtable config is not used for some of phys, which use other
means of configuring the master/slave usecases. Inline this function
with the goal of removing src_pll_id argument in the next commit.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210331105735.3690009-24-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The 7nm, 10nm and 14nm drivers would store interim data used during
VCO/PLL rate setting in the global dsi_pll_Nnm structure. Move this data
structures to the onstack storage. While we are at it, drop
unused/static 'config' data, unused config fields, etc.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-23-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Drop duplicate fields pdev and id from dsi_pll_Nnm instances. Reuse
those fields from the provided msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-22-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
All PHY drivers would map dsi_pll area. Some PHY drivers would also
map dsi_phy area again (a leftover from old PHY/PLL separation). Move
all ioremaps to the common dsi_phy driver code and drop individual
ioremapped areas from PHY drivers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-21-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Drop the struct msm_dsi_pll abstraction, by including vco's clk_hw
directly into struct msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210331105735.3690009-19-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Make save_state/restore callbacks accept struct msm_dsi_phy rather than
struct msm_dsi_pll. This moves them to struct msm_dsi_phy_ops, allowing
us to drop struct msm_dsi_pll_ops.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210331105735.3690009-18-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
10nm and 7nm already do not use these helpers, as they handle setting
slave DSI clocks after enabling VCO. Modify the rest of PHY drivers to
remove unnecessary indirection and drop enable_seq/disable_seq PLL
callbacks.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-17-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Instead of setting the variable and then using it just in the one place,
determine vco_delay directly at the PLL configuration time.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-16-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
These drivers do not use vco_delay variable, so drop it from all of
them.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-15-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Morph msm_dsi_pll_save/restore_state() into msm_dsi_phy_save/restore_state(),
thus removing last bits of knowledge about msm_dsi_pll from dsi_manager.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-14-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Use devm_of_clk_add_hw_provider() to register provided clocks. This
allows dropping the remove function alltogether.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-13-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Use devres-enabled version of clock registration functions. This lets us
remove dsi_pll destroy callbacks completely.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-12-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
All MSM DSI PHYs provide two clocks: byte and pixel ones.
Register/unregister provided clocks from the generic place, removing
boilerplate code from all MSM DSI PHY drivers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-11-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
msm_dsi_pll_set_usecase() function is not used outside of individual DSI
PHY drivers, so drop it in favour of calling the the respective
set_usecase functions directly.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-10-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
With the current upstream driver the msm_dsi_phy_type enum does not make
much sense: all DSI PHYs are probed using the dt bindings, the phy type
is not passed between drivers. Use quirks in phy individual PHY drivers
to differentiate minor harware differences and drop the enum.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-8-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Move all PLL-related callbacks into struct msm_dsi_phy_cfg. This limits
the amount of data in the struct msm_dsi_pll.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-7-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The only PLL using multiple enable sequences is the 28nm PLL, which just
does the single step in the loop. Push that support back into the PLL
code.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-6-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Each phy version is tightly coupled with the corresponding PLL code,
there is no need to keep them separate. Fuse source files together in
order to simplify DSI code.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-5-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
DSI PHY init callback would either map dsi_phy_regulator or dsi_phy_lane
depending on the PHY type. Replace those callbacks with configuration
options governing mapping those regions.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Tested-by: Stephen Boyd <swboyd@chromium.org> # on sc7180 lazor
Link: https://lore.kernel.org/r/20210331105735.3690009-4-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently the error checking logic in the dp_debug module could
pass zero to PTR_ERR and it causes the below kbot warnings:
drivers/gpu/drm/msm/dp/dp_debug.c:378 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:387 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:396 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:405 dp_debug_init()
warn: passing zero to 'PTR_ERR'
Debugfs functions are not supposed to be checked in the normal
case so delete this code. Also it silences the above Smatch
warnings that we're checking for NULL when these functions only
return error pointers.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1614971839-2686-3-git-send-email-abhinavk@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fix an incorrect NULL check reported by kbot in the MSM DP driver
smatch warnings:
drivers/gpu/drm/msm/dp/dp_hpd.c:37 dp_hpd_connect()
error: we previously assumed 'hpd_priv->dp_cb' could be null
(see line 37)
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1614971839-2686-2-git-send-email-abhinavk@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fix a couple of indentation warnings reported by
kbot across MSM DP driver:
New smatch warnings:
drivers/gpu/drm/msm/dp/dp_debug.c:229 dp_test_data_show()
warn: inconsistent indenting
drivers/gpu/drm/msm/dp/dp_power.c:203 dp_power_clk_enable()
warn: inconsistent indenting
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1614971839-2686-1-git-send-email-abhinavk@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The MSM8996 core_mmss clock was commented out due to some
strange issues that others were experiencing.
At least SONY Tone family is working perfectly fine with this clock
declared and gets it up and running without any error.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210228124328.136397-1-konrad.dybcio@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Set the flag vblank_disable_immediate = true to turn off vblank irqs
immediately as soon as drm_vblank_put is requested so that there are
no irqs triggered during idle state. This will reduce cpu wakeups
and help in power saving.
To enable vblank_disable_immediate flag the underlying KMS driver
needs to support high precision vblank timestamping and also a
reliable way of providing vblank counter which is incrementing
at the leading edge of vblank.
This patch also brings in changes to support vblank_disable_immediate
requirement in dpu driver.
Changes in v1:
- Specify reason to add vblank timestamp support. (Rob).
- Add changes to provide vblank counter from dpu driver.
Changes in v2:
- Fix warn stack reported by Rob Clark with v2 patch.
Changes in v3:
- Move back to HW frame counter (Rob).
Changes in v4:
- Frame count mismatch was causing a DRM WARN stack spew.
DPU HW will increment the frame count at the end of
the sync, where as vblank will be triggered at the
fetch_start counter which is calculated as v_total - vfp.
This is to start fetching early for panels with low
vbp w.r.t hw latency lines.
Add logic to detect the line count if it falls between
vactive and v_total then return incremented frame count value.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Link: https://lore.kernel.org/r/1613651746-12783-1-git-send-email-kalyan_t@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Performance counts, and ALWAYS_ON counters used for capturing GPU
timestamps, lose their state across suspend/resume cycles. Userspace
tooling for performance monitoring needs to be aware of this. For
example, after a suspend userspace needs to recalibrate it's offset
between CPU and GPU time.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Jordan Crouse <jordan@cosmicpenguin.net>
Link: https://lore.kernel.org/r/20210325012358.1759770-3-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
We were not programing the correct bit while clearing the perfcounter oob.
So, clear it correctly using the new 'clear' bit. This fixes the below
error:
[drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set PERFCOUNTER: 0x80000000
Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Link: https://lore.kernel.org/r/1617630433-36506-1-git-send-email-akhilpo@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The driver already has support for sm8150/sm8250, but the compatibles were
never added.
Also inverse the non-mdp4 condition in add_display_components() to avoid
having to check every new compatible in the condition.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210329120051.3401567-4-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
After spending a non-negligible time trying to figure out why
dpu_kms_init() would dereference a NULL dpu_kms->pdev, it turns out that
in addition to adding the new compatible to the msm_drv of_match_table
one also need to teach add_display_components() to register the child
nodes - which includes the DPU platform_device.
Replace the open coded test for compatibles with a check against the
match data of the mdss device to save others this trouble in the future.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210317025634.3987908-1-bjorn.andersson@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
There is a spelling mistake in debugfs gem stats. Fix it. Also
re-align output to cater for the extra 1 character.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210406133939.425987-1-colin.king@canonical.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
The last patch lost the breakdown of active vs inactive GEM objects in
$debugfs/gem. But we can add some better stats to summarize not just
active vs inactive, but also purgable/purged to make up for that.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210401012722.527712-5-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
In normal cases the gem obj lock is acquired first before mm_lock. The
exception is iterating the various object lists. In the shrinker path,
deadlock is avoided by using msm_gem_trylock() and skipping over objects
that cannot be locked. But for debugfs the straightforward thing is to
split things out into a separate list of all objects protected by it's
own lock.
Fixes: d984457b31 ("drm/msm: Add priv->mm_lock to protect active/inactive lists")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210401012722.527712-4-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
When the system is under heavy memory pressure, we can end up with lots
of concurrent calls into the shrinker. Keeping a running tab on what we
can shrink avoids grabbing a lock in shrinker->count(), and avoids
shrinker->scan() getting called when not profitable.
Also, we can keep purged objects in their own list to avoid re-traversing
them to help cut down time in the critical section further.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210401012722.527712-3-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Unused since commit c951a9b284 ("drm/msm: Remove msm_gem_free_work")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210401012722.527712-2-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
A few functions that were intentended for the perf events support are
currently declared in arch/x86/events/amd/iommu.h, which mens they are
not in scope for the actual function definition. Also amdkfd has started
using a few of them using externs in a .c file. End that misery by
moving the prototypes to the proper header.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210402143312.372386-5-hch@lst.de
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Use an explicit set_pgtable_quirks method instead that just passes
the actual quirk bitmask instead.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Li Yang <leoyang.li@nxp.com>
Link: https://lore.kernel.org/r/20210401155256.298656-20-hch@lst.de
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Disable TE for Droid 4 panel, since implementation is currently
broken. Also disable it for N950 panel, which is untested.
Reported-by: Tony Lindgren <tony@atomide.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Fixes: 4c1b935fea ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210227214542.99961-1-sebastian.reichel@collabora.com
Update the 3d merge as active in the data path only if
the hw block is selected in the configuration.
Reported-by: Stephen Boyd <swboyd@chromium.org>
Fixes: 73bfb790ac ("msm:disp:dpu1: setup display datapath for SC7180 target")
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Message-Id: <1617364493-13518-1-git-send-email-kalyan_t@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
I suppose the microcode version check for a650 is incorrect. It checks
for the version 1.95, while the firmware released have major version of 0:
0.91 (vulnerable), 0.99 (fixing the issue).
Lower version requirements to accept firmware 0.99.
Fixes: 8490f02a3c ("drm/msm: a6xx: Make sure the SQE microcode is safe")
Cc: Akhil P Oommen <akhilpo@codeaurora.org>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Jordan Crouse <jordan@cosmicpenguin.net>
Message-Id: <20210331140223.3771449-1-dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
They were reading a counter that was configured to ALWAYS_COUNT (ie.
cycles that the GPU is doing something) rather than ALWAYS_ON. This
isn't the thing that userspace is looking for.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Acked-by: Jordan Crouse <jordan@cosmicpenguin.net>
Message-Id: <20210325012358.1759770-2-robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Commit 7bf168c8fe ("drm/msm: Fix speed-bin support not to
access outside valid memory"), reworked the nvmem reading of
"speed_bin", but in doing so dropped handling of the -ENOENT
case which was previously documented as "fine".
That change resulted in the db845c board display to fail to
start, with the following error:
adreno 5000000.gpu: [drm:a6xx_gpu_init] *ERROR* failed to read speed-bin (-2). Some OPPs may not be supported by hardware
Thus, this patch simply re-adds the ENOENT handling so the lack
of the speed_bin entry isn't fatal for display, and gets things
working on db845c.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: YongQin Liu <yongqin.liu@linaro.org>
Reported-by: YongQin Liu <yongqin.liu@linaro.org>
Fixes: 7bf168c8fe ("drm/msm: Fix speed-bin support not to access outside valid memory")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Akhil P Oommen <akhilpo@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Message-Id: <20210330013408.2532048-1-john.stultz@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
We should set the platform device's driver data to NULL here so that
code doesn't assume the struct drm_device pointer is valid when it could
have been destroyed. The lifetime of this pointer is managed by a kref
but when msm_drm_init() fails we call drm_dev_put() on the pointer which
will free the pointer's memory. This driver uses the component model, so
there's sort of two "probes" in this file, one for the platform device
i.e. msm_pdev_probe() and one for the component i.e. msm_drm_bind(). The
msm_drm_bind() code is using the platform device's driver data to store
struct drm_device so the two functions are intertwined.
This relationship becomes a problem for msm_pdev_shutdown() when it
tests the NULL-ness of the pointer to see if it should call
drm_atomic_helper_shutdown(). The NULL test is a proxy check for if the
pointer has been freed by kref_put(). If the drm_device has been
destroyed, then we shouldn't call the shutdown helper, and we know that
is the case if msm_drm_init() failed, therefore set the driver data to
NULL so that this pointer liveness is tracked properly.
Fixes: 9d5cbf5fe4 ("drm/msm: add shutdown support for display platform_driver")
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krishna Manikandan <mkrishn@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Message-Id: <20210325212822.3663144-1-swboyd@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fix a memory leak in an error path during DRM device initialization,
fix the LDB driver to register channel 1 even if channel 0 is unused,
and fix an out of bounds array access warning in the LDB driver.
-----BEGIN PGP SIGNATURE-----
iI4EABYIADYWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCYGWEMBgccGhpbGlwcC56
YWJlbEBnbWFpbC5jb20ACgkQ1YWnJRg3YsANIgD+Kb7yLjv17TC1lfEVYK8k5nDf
QKDXJJPnQm2O3KvbXDIBAPDQwEGAG3fcT1AjzahbzpntIJsqlyD0aMVSDgK4Dq4H
=jeDO
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-2021-04-01' of git://git.pengutronix.de/git/pza/linux into drm-fixes
drm/imx: imx-drm-core and imx-ldb fixes
Fix a memory leak in an error path during DRM device initialization,
fix the LDB driver to register channel 1 even if channel 0 is unused,
and fix an out of bounds array access warning in the LDB driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401092235.GA13586@pengutronix.de
This contains a couple of fixes for various issues such as lockdep
warnings, runtime PM references, coupled display controllers and
misconfigured PLLs.
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmBl9PoTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoYsUD/YjsgwhLKF6BWMZDOR7BFigO0guqmSL
3VHpWKjGtanp/tR8fpScfdYCyhhAWHZ/EcHqtZofUefNMjL1c7UXzZaxdcxHazWA
ygy3CP00ch+ldm0jiajTdj60hVoZ6RJEPh7R2E9gdXkpwjksJhsjhNNYR9qSej4c
HJsjOIB7cPP1Xnc6HQZm+3+jWwS4ZhMxJbZ6sS5xBxG+Pep03ZOeualM129QW91U
tbca/QZtmWwtmXaTOnm+FlzhEqVLawOuhx/oWMMckVjLBzQy0UGhulTkDIUQ64gH
gCVTfFY6t08CZIoRvLnx8dsOtJx9b4Gg454C7pBzGl0IlsNwPQnZ2NWhn2tvkJeb
S6A7V8TZtshuJ2tqZOJJqaq0fAdKFh9PI2HupdXX1RA/gS23CXXbzPTjsHxQcknm
E1WHo1cdqc/mMhPq8mZfg8OsVHt2dca7H8fBHmzsWsSo5fdwrKDEAl6HogE/XGn0
myC1IxCi/qQ3CkzezML3oh76XDY7JA09SSDYbOCwHzIv8MhJkBY+XRySVOh1zf6g
W2sWVk8QsIDG7pnlojfTrh3jRvWz99l4x1aTntX64mONte91nHxLW2Sgyk5C3emT
iIiUNV2nfuvjtL7lCI0tPqi2Wx7/YwPmVV2C4QSBMnRXF3GNCIxn10XWORZmqmBo
Ldqdstr2pceo
=fDaE
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-5.12-rc6' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes
drm/tegra: Fixes for v5.12-rc6
This contains a couple of fixes for various issues such as lockdep
warnings, runtime PM references, coupled display controllers and
misconfigured PLLs.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401163352.3348296-1-thierry.reding@gmail.com
drm_vblank_restore() exists because certain power saving states
can clobber the hardware frame counter. The way it does this is
by guesstimating how many frames were missed purely based on
the difference between the last stored timestamp vs. a newly
sampled timestamp.
If we should call this function before a full frame has
elapsed since we sampled the last timestamp we would end up
with a possibly slightly different timestamp value for the
same frame. Currently we will happily overwrite the already
stored timestamp for the frame with the new value. This
could cause userspace to observe two different timestamps
for the same frame (and the timestamp could even go
backwards depending on how much error we introduce when
correcting the timestamp based on the scanout position).
To avoid that let's not update the stored timestamp at all,
and instead we just fix up the last recorded hw vblank counter
value such that the already stored timestamp/seq number will
match. Thus the next time a vblank irq happens it will calculate
the correct diff between the current and stored hw vblank counter
values.
Sidenote: Another possible idea that came to mind would be to
do this correction only if the power really was removed since
the last time we sampled the hw frame counter. But to do that
we would need a robust way to detect when it has occurred. Some
possibilities could involve some kind of hardare power well
transition counter, or potentially we could store a magic value
in a scratch register that lives in the same power well. But
I'm not sure either of those exist, so would need an actual
investigation to find out. All of that is very hardware specific
of course, so would have to be done in the driver code.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210218160305.16711-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the user specifies zero width/height cmdline mode i915 will
blow up as the fbdev path will bypass the regular fb sanity
check that would otherwise have refused to create a framebuffer
with zero width/height.
The reason I thought to try this is so that I can force a specific
depth for fbdev without actually having to hardcode the mode
on the kernel cmdline. Eg. if I pass video=0x0-8 I will get an
8bpp framebuffer at my monitor's native resolution.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607162611.23514-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n]
Selected by [y]:
- DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y]
This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE,
without depending on or selecting DRM_KMS_HELPER,
despite that config option depending on DRM_KMS_HELPER.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222215502.24487-1-julianbraha@gmail.com
commit f011951489 ("drm/mediatek: mtk_dpi: Create connector for bridges")
broke the display support for elm device since mtk_dpi calls
drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
while mtk_hdmi does not yet support this flag.
Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment.
Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
call drm_bridge_hpd_notify() to report HPD. This provides the
necessary API to support disabling connector creation.
In addition, the field 'conn' is removed from the mtk_hdmi struct since
mtk_hdmi don't create a connector. It is replaced with a pointer
'curr_conn' that points to the current connector which can be access
through the global state.
This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c:
commit ec971aaa67
("drm: bridge: dw-hdmi: Make connector creation optional")
But with the difference that in mtk-hdmi only the option of not creating
a connector is supported.
Fixes: f011951489 ("drm/mediatek: mtk_dpi: Create connector for bridges")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
The bridge operation '.enable' and the audio cb '.get_eld'
access hdmi->conn. In the future we will want to support
the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
not have direct access to the connector.
The atomic version '.atomic_enable' allows accessing the
current connector from the state.
This patch switches the bridge to the atomic version to
prepare access to the connector in later patches.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: James Qian Wang <james.qian.wang@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210204131102.68658-1-carsten.haitzler@foss.arm.com
Fix the following coccicheck warning:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING:
use scnprintf or sprintf
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: James Qian Wang <james.qian.wang@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1617067518-31091-1-git-send-email-tiantao6@hisilicon.com
When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Xin Ji <xji@analogixsemi.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401053202.159302-2-hsinyi@chromium.org
The page table of AMDGPU requires an alignment to CPU page so we should
check ioctl parameters for it. Return -EINVAL if some parameter is
unaligned to CPU page, instead of corrupt the page table sliently.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
In Mesa, dev_info.gart_page_size is used for alignment and it was
set to AMDGPU_GPU_PAGE_SIZE(4KB). However, the page table of AMDGPU
driver requires an alignment on CPU pages. So, for non-4KB page system,
gart_page_size should be max_t(u32, PAGE_SIZE, AMDGPU_GPU_PAGE_SIZE).
Signed-off-by: Rui Wang <wangr@lemote.com>
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Link: https://github.com/loongson-community/linux-stable/commit/caa9c0a1
[Xi: rebased for drm-next, use max_t for checkpatch,
and reworded commit message.]
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
Tested-by: Dan Horák <dan@danny.cz>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Do the same thing we do for Renoir. We can check, but since
the sbios has started DPM, it will always return true which
causes the driver to skip some of the SMU init when it shouldn't.
Reviewed-by: Zhan Liu <zhan.liu@amd.com>
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Amdgpu driver uses 4-byte data type as DQM fence memory,
and transmits GPU address of fence memory to microcode
through query status PM4 message. However, query status
PM4 message definition and microcode processing are all
processed according to 8 bytes. Fence memory only allocates
4 bytes of memory, but microcode does write 8 bytes of memory,
so there is a memory corruption.
Changes since v1:
* Change dqm->fence_addr as a u64 pointer to fix this issue,
also fix up query_status and amdkfd_fence_wait_timeout function
uses 64 bit fence value to make them consistent.
Signed-off-by: Qu Huang <jinsdb@126.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
- Based on the patch[1], clean up the use of request_irq function
series.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJgYr3pAAoJEFc4NIkMQxK4Ho8P/Reg5t/7Ghi7tNrXlGhaifkc
8vV4UELMRwVF2BzWM3lYl7iisGW8L9zTKGDHvu6VHMU8urBWYM/l97fnpiHEJN6v
PTGS/KaYUkuEEuYgkeRFQimCDW3dwKPxOlIW5TWZ/UyvNNKBVZkHELY+bVeMNCZt
xVnG6lsD291Wq2Dk0OoP8JI2K4Ddn9f9MfZIlwd1XrpnKQrGGDfHcIQq/DP6cPrt
tD0Rkh6RCXOP4l8OW+YQlkSKHfNueVfmW5AuKvpVPxMf/0ppel5HRVnDhR1ytfFh
iAtATwHc74NBjsjwYKYh3bLFrOpu45E9Ktem/dRL3GC4Yq738sEt5IbwO1E5BU4Y
b46bIvQ1z5nxUg8j52eqLjTttxFi51L0WrYBA+NtiAAA1F1wv8AjZplDyIydNgDh
14oh9igE5mlN+oTil1ImTPPA1qao/pVC0O6uGvv7yW+VFCe9tMJW2/AyD5Q5hrU1
MJTZo5m3eehivoyWsgHEh/prqjpcPGBm7EQpQA+hqA5F8EXrQ5JbICi+uq3LVG4G
JP/4Vrr0SahT2zactoMWr2tMyzRS/Y6ZKv/IB9tIIdNRwauVMrG7lUm+7IepPOk3
Z+wkEUKipKytTycqRLtE3NertERFnU6b9wqtfTavJ8UTz0m1OqejLkaP4gQcF22h
nMFFGtZPb/1s0wmkOvIu
=AJJ8
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-next-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
One cleanup
- Based on the patch[1], clean up the use of request_irq function
series.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1617092998-23645-1-git-send-email-inki.dae@samsung.com
- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i915-gem TODO and RFC process doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
and put it in here too
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEb4nG6jLu8Y5XI+PfTA9ye/CYqnEFAmBdtqYACgkQTA9ye/CY
qnGwvBAAh7GJhv+KqQP/hjdaM3k8gEeNyMpAZyb1fuaVDp3EEzP9UQOBZQXiTAgZ
ZSY3h3zN47NLJ3q22MqmUxMQwhi7OES7rN9f76jApkG1Lvq8C+NepknDDhDIQ+DZ
Stla0mT89tCJcMMVGCsKonWhg/qWm04mxBrxArZMoIRRnduoHxqKiVPG++pUxDYh
v3CTJuqdOUOtyLi8KV2pKBaYRo6oswiW6EAsqlMicfcC2X2/NVEHOxKQt6p57omH
amZMroW9w28qpW6MKNxP91N5sbgQc59heNWdtdMgCbHKMoMa96aL27J0tX+rG/Vx
3ZR6KQje8jv0I+pN8K1uC85ufry3kcx6CBmA8+GU2rZqfvaMAugD2B8kkrqFYDa3
0SFI9XwoDViFOwbLMm1DkRkyuee+cfvBS7BxK2zW4JjFpG5jLtfPwh8Li6CmzP8I
HrYU43SHM+fuXhKyEbvhnpjR7JIwRW9PUK3RBoRq2yPM+OlPpXpvMEzQHeTeRh8W
y/cC6Z1WtJ7BZZ4J6clznAw6PMuo3JD/5oG2sdrw0vzPojUIgonoUDBzWojla9hi
J/RcxAYEhXvUHOMuWtls4AAc2KRD2JgWbGW6W1gLC5wsEs8qfuYe+USN4eYnuX92
mPdj7BjtbEg23Qm4fPl/m9G+dDbshEcfKUPpplFEIUNv5A/v1LY=
=P0yC
-----END PGP SIGNATURE-----
Merge tag 'topic/i915-gem-next-2021-03-26' of ssh://git.freedesktop.org/git/drm/drm into drm-next
special i915-gem-next pull as requested
- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i915-gem TODO and RFC process doc (me)
- i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it
and put it in here too
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/YF24MHoOSjpKFEXA@phenom.ffwll.local
Tegra194 has a special physical address bit that enables some memory
swizzling logic to support different sector layouts. Support the bit
that selects the sector layout which is passed in the framebuffer
modifier.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In order to be able to attach planes to all possible display controllers
the exact number of CRTCs must be known. Keep track of the number of the
display controllers that register during initialization.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Clarify when a fixed IOV address can be used and when a buffer has to
be mapped before the IOVA can be used.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The hardware cursor on Tegra186 differs slightly from the implementation
on older SoC generations. In particular the new implementation relies on
software for clipping the cursor against the screen. Fortunately, atomic
KMS already computes clipped coordinates for (cursor) planes, so this is
trivial to implement.
The format supported by the hardware cursor is also slightly different.
v2: use more drm_rect helpers (Dmitry)
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra186 and later support a higher maximum resolution than earlier
chips, so make sure to reflect that in the mode configuration.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Inherit the DMA mask from host1x (on Tegra210 and earlier) or the
display hub (on Tegra186 and later). This is necessary in order to
properly map buffers without SMMU support and use the maximum IOVA
space available with SMMU support.
Signed-off-by: Thierry Reding <treding@nvidia.com>
These callbacks can be used by client drivers to run code during early
init and during late exit. Early init callbacks are run prior to the
regular init callbacks while late exit callbacks run after the regular
exit callbacks.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Syncpoint interrupts are not working as expected on Tegra194. The
problem is that the syncpoint interrupt threshold being used is the
global interrupt threshold and not the virtual interrupt threshold.
Fix this by using the virtual interrupt threshold which aligns with
downstream.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Move the assignment of the ref out-pointer in host1x_intr_add_action
to happen within the spinlock. With the current arrangement,
it is possible for the waiter to complete before the assignment
has happened, which breaks horribly if the waiter completion
callback tries to use the reference.
In practice, there is currently no situation where this issue can
manifest -- it was first noticed with the upcoming DMA fence
implementation patches. As such this doesn't need to be backported.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
On T20-T148 chips, the bootloader can set up a boot splash
screen with DC configured to increment syncpoint 26/27
at VBLANK. Because of this we shouldn't allow these syncpoints
to be allocated until DC has been reset and will no longer
increment them in the background.
As such, on these chips, reserve those two syncpoints at
initialization, and only mark them free once the DC
driver has indicated it's safe to do so.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in a sane state for the next user.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add reference counting for allocated syncpoints to allow keeping
them allocated while jobs are referencing them. Additionally,
clean up various places using syncpoint IDs to use host1x_syncpt
pointers instead.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fix the
Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string.
warning from the htmldocs build.
Fixes: 9d58aa4629 ("drm/i915: Fix the GT fence revocation runtime PM logic")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com
The DisplayID specifications explicitly call out 0 as a valid payload
length for data blocks. The mere presence of a data block, or the
information coded in the block specific data (bits 7:3 in offset 1), may
be enough to convey the necessary information.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d562dff99ba7c92accb654a99b433bed471e8507.1617024940.git.jani.nikula@intel.com
Iterating DisplayID blocks across sections (in EDID extensions) is
unnecessarily complicated for the caller. Implement DisplayID iterators
to go through all blocks in all sections.
Usage example:
const struct displayid_block *block;
struct displayid_iter iter;
displayid_iter_edid_begin(edid, &iter);
displayid_iter_for_each(block, &iter) {
/* operate on block */
}
displayid_iter_end(&iter);
When DisplayID is stored in EDID extensions, the DisplayID sections map
to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID
as an EDID Extension. This is implemented here.
When DisplayID is stored in its dedicated DDC device 0xA4, according to
VESA E-DDC v1.3, different rules apply for the structure. This is not
implemented here, as we don't currently use it, but the idea is you'd
have a different call for beginning the iteration, for example simply:
displayid_iter_begin(displayid, &iter);
instead of displayid_iter_edid_begin(), and everything else would be
hidden away in the iterator functions.
v2:
- sizeof(struct displayid_block) -> sizeof(*block) (Ville)
- remove __ prefix from displayid_iter_block
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/da3dead1752ab16c061f7bd248ac1a4268f7fefb.1617024940.git.jani.nikula@intel.com
We'll be adding more DisplayID specific functions going forward, so
start off by splitting out a few functions to a separate file.
We don't bother with exporting the functions; at least for now they
should be needed solely within drm.ko.
No functional changes.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/07942d5011891b8e8f77245c78b34f4af97a9315.1617024940.git.jani.nikula@intel.com
This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
As documented in HDCP 2.2 DP Errata spec transmitter should abort the
authentication protocol in case transmitter has not received the
entire {AKE_Send_Cert, AKE_Send_H_prime, AKE_Send_Paring_Info} msg
within {110,7,5} miliseconds.
Adding above msg timeout values and aborting the HDCP authentication
in case it timedout to read entire msg.
https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf
v2:
- Removed redundant variable msg_can_timedout. [Ankit]
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324113012.7564-2-anshuman.gupta@intel.com
Add the check if source control mode is supported by the
PCON, before starting configuring PCON for FRL training,
as per spec VESA DP2.0-HDMI2.1 PCON Draft-1 Sec-7.
v2: Added spec details for the change. (Uma)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323112422.1211-3-ankit.k.nautiyal@intel.com
Currently the FRL training mode (Concurrent, Sequential) and
training type (Normal, Extended) are not defined properly and
are passed as bool values in drm_helpers for pcon
configuration for FRL training.
This patch:
-Add register masks for Sequential and Normal FRL training options.
-Fixes the drm_helpers for FRL Training configuration to use the
appropriate masks.
-Modifies the calls to the above drm_helpers in i915/intel_dp as per
the above change.
v2: Re-used the register masks for these options, instead of enum. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323112422.1211-2-ankit.k.nautiyal@intel.com
Make syncpoint expiration checks always use the same logic used by
the hardware. This ensures that there are no race conditions that
could occur because of the hardware triggering a syncpoint interrupt
and then the driver disagreeing.
One situation where this could occur is if a job incremented a
syncpoint too many times -- then the hardware would trigger an
interrupt, but the driver would assume that a syncpoint value
greater than the syncpoint's max value is in the future, and not
clean up the job.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Before this patch, cancelled waiters would only be cleaned up
once their threshold value was reached. Make host1x_intr_put_ref
process the cancellation immediately to fix this.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Show the number of pending waiters in the debugfs status file.
This is useful for testing to verify that waiters do not leak
or accumulate incorrectly.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Syncpoints don't need to be associated with any client,
so remove the property, and expose host1x_syncpt_alloc.
This will allow allocating syncpoints without prior knowledge
of the engine that it will be used with.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SOR resets are exclusively shared with the SOR power domain. This
means that exclusive access can only be granted temporarily and in order
for that to work, a rigorous sequence must be observed. To ensure that a
single consumer gets exclusive access to a reset, each consumer must
implement a rigorous protocol using the reset_control_acquire() and
reset_control_release() functions.
However, these functions alone don't provide any guarantees at the
system level. Drivers need to ensure that the only a single consumer has
access to the reset at the same time. In order for the SOR to be able to
exclusively access its reset, it must therefore ensure that the SOR
power domain is not powered off by holding on to a runtime PM reference
to that power domain across the reset assert/deassert operation.
This used to work fine by accident, but was revealed when recently more
devices started to rely on the SOR power domain.
Fixes: 11c632e1cf ("drm/tegra: sor: Implement acquire/release for reset")
Reported-by: Jonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Coupling of display controllers used to rely on runtime PM to take the
companion controller out of reset. Commit fd67e9c6ed ("drm/tegra: Do
not implement runtime PM") accidentally broke this when runtime PM was
removed.
Restore this functionality by reusing the hierarchical host1x client
suspend/resume infrastructure that's similar to runtime PM and which
perfectly fits this use-case.
Fixes: fd67e9c6ed ("drm/tegra: Do not implement runtime PM")
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Reported-by: Paul Fertser <fercerpav@gmail.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
RGB output doesn't allow to change parent clock rate of the display and
PCLK rate is set to 0Hz in this case. The tegra_dc_commit_state() shall
not set the display clock to 0Hz since this change propagates to the
parent clock. The DISP clock is defined as a NODIV clock by the tegra-clk
driver and all NODIV clocks use the CLK_SET_RATE_PARENT flag.
This bug stayed unnoticed because by default PLLP is used as the parent
clock for the display controller and PLLP silently skips the erroneous 0Hz
rate changes because it always has active child clocks that don't permit
rate changes. The PLLP isn't acceptable for some devices that we want to
upstream (like Samsung Galaxy Tab and ASUS TF700T) due to a display panel
clock rate requirements that can't be fulfilled by using PLLP and then the
bug pops up in this case since parent clock is set to 0Hz, killing the
display output.
Don't touch DC clock if pclk=0 in order to fix the problem.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
An upcoming platform has a restriction that the FB stride must be
power-of-two aligned. To support framebuffer layouts that are not in
this layout add a logic that pads the tile rows to the POT aligned size.
The HW won't read the padding PTEs, so these don't have to point to an
allocated address, or even have their valid flag set. So use a NULL PTE
instead for instance the scratch page, which is simple and keeps the SG
table compact.
v2:
- Simplify plane_view_dst_stride(). (Ville)
- Pass pitch_tiles as unsigned int.
v3:
- Drop unintentional s/plane_state->rotation/plane_config->rotation/
change.
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/20210325214808.2071517-24-imre.deak@intel.com
Always use the modified copy of the intel_remapped_plane_info variables.
An upcoming patch updates the dst_stride field in these copies after
which we can't use the original versions.
v2: Init view in igt_vma_rotate_remap() when declaring it. (Ville)
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/20210325214808.2071517-22-imre.deak@intel.com
Save some place in the GTT VMAs by using a u16 instead of unsigned int
to store the view dimensions. The maximum FB stride is 256kB which is
4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k
pixels, which is 16384 tiles in the worst case (linear 4x1 tiled FB).
v2:
- Fix worst case tile height formula in commit log. (Ville)
- Add an assign_chk_ovf helper to simplify the related assignments.
v3:
- Enclose params of the assign_chk_ovf macro in parentheses.
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/20210325214808.2071517-21-imre.deak@intel.com
Factor out to a new function the logic to calculate the FB remapping
parameters both during creating the FB and when flipping to it.
v2:
- Keep stride next to offset calculation. (Ville)
- Enclose check_array_bounds macro arguments in parentheses.
v3:
- Rebase on top of the struct intel_fb_view refactoring.
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/20210325214808.2071517-20-imre.deak@intel.com
Instead of copying separately the GTT remapped and color plane view info
from the FB to the plane state, do this by copying the whole
intel_fb_view struct. For this we make sure the FB view state is fully
inited (that is also including the view type) already during FB
creation, so this init is not required during atomic check time. This
also means the we don't need to reset the unused color plane info during
atomic check, as these are already reset during FB creation.
I noticed that initial FBs will only work atm if they are page aligned
(which BIOS most probably always ensures), but add a comment to sanitize
this part once. Also we won't disable the plane if
get_initial_plane_config() failed for some reason (for instance due to
unsupported rotation), add a TODO: comment for this too.
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/20210325214808.2071517-19-imre.deak@intel.com
Instead of special casing getting the pitch for the normal view, store
it during FB creation to the FB normal view struct and retrieve it from
there during atomic check, as it's done for the rotated view. A
follow-up patch does the same for a new FB remapped view.
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/20210325214808.2071517-18-imre.deak@intel.com
To allow the simplification of FB/plane view computation in the
follow-up patches, unify the corresponding state in the
intel_framebuffer and intel_plane_state structs into a new intel_fb_view
struct.
This adds some overhead to intel_framebuffer as the rotated view will
have now space for 4 color planes instead of the required 2 and it'll
also contain the unused offset for each color_plane info. Imo this is an
acceptable trade-off to get a simplified way of the remap computation.
Use the new intel_fb_view struct for the FB normal view as well, so (in
the follow-up patches) we can remove the special casing for normal view
calculation wrt. the calculation of remapped/rotated views. This also
adds an overhead to the intel_framebuffer struct, as the gtt remap info
and per-color plane offset/pitch is not required for the normal view,
but imo this is an acceptable trade-off as above. The per-color plane
pitch filed will be used by a follow-up patch, so we can retrieve the
pitch for each view in the same way.
No functional changes in this patch.
v2:
- Make the patch have _no functional change_.
(fix skl_check_nv12_aux_surface() and skl_check_main_surface()).
- s/i915_color_plane_view::pitch/stride/ (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.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/20210325214808.2071517-17-imre.deak@intel.com
Factor out to a new function the logic to calculate an FB plane's
normal-view size.
Instead of using intel_remapped_plane_info, which is related only to
remapping, add a helper to get the tile pitch and rows for an FB plane,
so these helpers can be used both by the normal size calculation and the
remapping code.
Also add a new fb_plane_view_dims struct in which we can pass around the
view (either FB plane or plane source) and tile dimensions conveniently
to functions calculating further view parameters.
v2:
- Add back the +1 tile adjustment for x!=0 in calc_plane_normal_size(). (Ville)
- s/pages/tiles/ in calc_plane_normal_size(). (Ville)
- Add a helper for the plane view width calculation. (Ville)
- Return tiles as unsigned int from calc_plane_normal_size().
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/20210325214808.2071517-16-imre.deak@intel.com
Factor out to a new function the logic to convert the FB plane x/y
values to a tile size based offset and new x/y relative to this offset.
This makes intel_fill_fb_info() and intel_plane_remap_gtt() somewhat
more readable.
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/20210325214808.2071517-15-imre.deak@intel.com
Factor out to a new function the logic to convert the FB plane offset to
x/y and check the validity of x/y, with the goal to make
intel_fill_fb_info() more readable.
v2: Use &fb->base instead of a drm_fb alias. (Ville)
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/20210325214808.2071517-14-imre.deak@intel.com
Move the FB plane specific functions from intel_display.c to intel_fb.c.
There's more functions like this, but I leave moving those as well for a
follow up, and for now moving only the ones needed by the end of this
patchset (adding support for padding tile-rows in an FB GGTT view).
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/20210325214808.2071517-11-imre.deak@intel.com
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
v2: Use {} instead of { } struct intializer. (Ville)
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/20210325214808.2071517-6-imre.deak@intel.com
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
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/20210325214808.2071517-5-imre.deak@intel.com
The HW plane state is cleared and inited after we store the rotation to
it, so store it instead to the uapi state to match what we do with all
other plane state until intel_plane_copy_uapi_to_hw_state() is called.
Rotation for initial FBs is not supported atm, but let's still fix the
plane state setup here.
While at it remove the redundant intel_state->uapi.src/dst init, which
will be done in intel_plane_copy_uapi_to_hw_state().
v2: Remove redundant intel_state->uapi.src/dst init. (Ville)
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/20210325214808.2071517-2-imre.deak@intel.com
struct drm_i915_private, struct intel_crtc_state and
struct intel_crtc is declared twice.
Remove the duplicate.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326012527.875026-1-wanjiabing@vivo.com
Offset calculation wasn't correct as start addresses are in pfn
not in bytes.
CC: stable@vger.kernel.org
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Correct the check for vblank short.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The dbuf bandwidth calculations don't need the planes to be
added to the state. Each plane's data rate has already been
precalculated and stored in the crtc state, and that with
the dbuf slice usage for each plane is all the dbuf bandwidth
code needs to figure out what the minimum cdclk is.
What we're trying to do here is make sure each plane recalculates
its minimum cdclk (ie. plane->min_cdclk()) on those platforms where
the number of active planes affects the result of said calculation.
Nothing to do with any dbuf cdclk requirements.
Not sure if we had stuff in slightly different order or what,
but at least in the current scheme this is not necessary.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325004415.17432-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
While updating config, the irq would occur and get the partial
config, so use variable config_updating to make updating atomic.
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
v3: Use the new drmm_plain_simple_encoder_alloc() macro
v4: Use drmm_plain_encoder_alloc() macro
Fixes: c369cb27c2 ("drm/ingenic: Support multiple panels/bridges")
Cc: <stable@vger.kernel.org> # 5.8+
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-4-paul@crapouillou.net
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
v2: Cleanup connector only if it was created
v3: Add FIXME
v4: (Use connector->dev) directly in if() block
Fixes: 13dfc0540a ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.")
Cc: <stable@vger.kernel.org> # 4.12+
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210327115742.18986-2-paul@crapouillou.net
This changes the way revids not present in the array are handled:
- For gaps in the array, the next present revid is used.
- For revids beyond the array, the new STEP_FUTURE is used instead of
the last revid in the array.
In both cases, we'll get debug logging of what's going on.
v2: Rename stepping->step
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/756fe3d75b1e91ef812fc1fd3f70337e9c571d91.1616764798.git.jani.nikula@intel.com
Add new symbolic names for revision ids, and convert KBL revids to use
them via the new stepping check macros.
This also fixes theoretical out of bounds access to kbl_revids array.
v3: upgrade dbg to warn on unknown revid (José)
v2: Rename stepping->step
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/79b6c48211c6b214165391d350d556bad748f747.1616764798.git.jani.nikula@intel.com
Add new runtime info field for stepping. Add new helpers for accessing
them. As we'll be switching platforms over to the new scheme
incrementally, check for non-initialized steppings.
In case a platform does not have separate display and gt steppings, it's
okay to use a common shorthand. However, in this case the display
stepping must not be initialized, and gt stepping is the single point of
truth.
v3: Remove IS_STEP() (José)
v2: Rename stepping->step
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bb4275733fa390ea3dbf6f62794d55b616665230.1616764798.git.jani.nikula@intel.com
After this patch cbe16f35be genirq: Add IRQF_NO_AUTOEN for
request_irq/nmi() is merged. request_irq() after setting
IRQ_NOAUTOEN as below
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(dev, irq...);
can be replaced by request_irq() with IRQF_NO_AUTOEN flag.
v2:
Fix the problem of using wrong flags
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The shrinker based approach still has some flaws. Especially that we need
temporary pages to free up the pages allocated to the driver is problematic
in a shrinker.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324134845.2338-1-christian.koenig@amd.com
[why]
MST topology print was missing fec logging and pdt printed
as an int wasn't clear. vcpi and payload info was printed as an
arbitrary series of ints which requires user to know the ordering
of the prints, making the logs difficult to use.
[how]
-add fec logging
-add pdt parsing into strings
-format vcpi and payload info into tables with headings
-clean up topology prints
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Eryk Brol <eryk.brol@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325180614.37060-1-eryk.brol@amd.com
amd-drm-next-5.13-2021-03-23:
amdgpu:
- Debugfs cleanup
- Various cleanups and spelling fixes
- Flexible array cleanups
- Initial AMD Freesync HDMI
- Display fixes
- 10bpc dithering improvements
- Display ASSR support
- Clean up and unify powerplay and swsmu interfaces
- Vangogh fixes
- Add SMU gfx busy queues for RV/PCO
- PCIE DPM fixes
- S0ix fixes
- GPU metrics data fixes
- DCN secure display support
- Backlight type override
- Add initial support for Aldebaran
- RAS fixes
- Prime fixes for A+A systems
- Reset fixes
- Initial resource cursor support
- Drop legacy IO BAR requirements
- Various power fixes
amdkfd:
- MMU notifier fixes
- APU fixes
radeon:
- Debugfs cleanups
- Flexible array cleanups
UAPI:
- amdgpu: Add a new INFO ioctl interface to query video capabilities
rather than hardcoding them in userspace. This allows us to provide
fine grained asic capabilities (e.g., if a particular part is
bandwidth limited, we can limit the capabilities). Proposed userspace:
https://gitlab.freedesktop.org/leoliu/drm/-/commits/info_video_capshttps://gitlab.freedesktop.org/leoliu/mesa/-/commits/info_video_caps
- amdkfd: bump the driver version. There was a problem with reporting
some RAS features on older versions of the driver. Proposed userspace:
7cdd63475c
Danvet: A bunch of conflicts all over, but it seems to compile ... I
did put the call to dc_allow_idle_optimizations() on a single line
since it looked a bit too jarring to be left alone.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324040147.1990338-1-alexander.deucher@amd.com
Fix the following typos:
1. When mentioning a list of functions, the function
drm_atomic_helper_disable_plane is mentioned twice.
2. drop the word 'afterwards':
s/afterwards after that/after that/'
3. drop extra 'the':
s/but do not the support the full/but do not support the full/
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20210326103216.7918-1-dafna.hirschfeld@collabora.com
We've discussed a bit how to get the gem/gt team better integrated
and collaborate more with the wider community and agreed to the
following:
- all gem/gt patches are reviewed on dri-devel for now. That's
overkill, but in the past there was definitely too little of that.
- i915-gem folks are encouraged to cross review core patches from
other teams
- big features (especially uapi changes) need to be discussed in an
rfc patch that documents the interface and big picture design,
before we get lost in the details of the code
- Also a rough TODO (can be refined as we go ofc) to get gem/gt back
on track, like we've e.g. done with DAL/DC to get that in shape.
v2:
- add dma_fence annotations (Dave)
- tasklet helpers (Jani on irc)
There was also a discussion about moving these into gitlab issues, or
gitlab issues as additional discussion place at least. For now it's
just the TODO file
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324211041.1354941-1-daniel.vetter@ffwll.ch
struct dss_device has been declared. Remove the duplicate.
And sort these forward declarations alphabetically.
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325111028.864628-1-wanjiabing@vivo.com
fixed the following coccicheck:
./drivers/gpu/drm/omapdrm/dss/dsi.c:4329:7-27: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Fixes: 4c1b935fea ("drm/omap: dsi: move TE GPIO handling into core")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1616492093-68237-1-git-send-email-yang.lee@linux.alibaba.com
An old patch added a 'return' statement after each BUG() in this driver,
which was necessary at the time, but has become redundant after the BUG()
definition was updated to handle this properly.
gcc-11 now warns about one such instance, where the 'return' statement
was incorrectly indented:
drivers/gpu/drm/omapdrm/dss/dispc.c: In function ‘pixinc’:
drivers/gpu/drm/omapdrm/dss/dispc.c:2093:9: error: this ‘else’ clause does not guard... [-Werror=misleading-indentation]
2093 | else
| ^~~~
drivers/gpu/drm/omapdrm/dss/dispc.c:2095:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’
2095 | return 0;
| ^~~~~~
Address this by removing the return again and changing the BUG()
to be unconditional to make this more intuitive.
Fixes: c6eee968d4 ("OMAPDSS: remove compiler warnings when CONFIG_BUG=n")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322164203.827324-1-arnd@kernel.org
In function displback_changed, has the call chain
displback_connect(front_info)->xen_drm_drv_init(front_info).
We can see that drm_info is assigned to front_info->drm_info
and drm_info is freed in fail branch in xen_drm_drv_init().
Later displback_disconnect(front_info) is called and it calls
xen_drm_drv_fini(front_info) cause a use after free by
drm_info = front_info->drm_info statement.
My patch has done two things. First fixes the fail label which
drm_info = kzalloc() failed and still free the drm_info.
Second sets front_info->drm_info to NULL to avoid uaf.
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323014656.10068-1-lyl2019@mail.ustc.edu.cn
Accidentally transposed the arguments to skl_plane_wm_level()
which is causing us to mistakenly think that the plane watermarks
have/have not changed when the opposite may be true. Swap the
arguments so this actually works.
The other uses of this look OK.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: 2871b2fde4 ("drm/i915: Fix TGL+ plane SAGV watermark programming")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325004415.17432-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Module parameter is added (request_timeout_ms) to allow configuring the
default request/fence expiry.
Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-8-tvrtko.ursulin@linux.intel.com
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.
This can have an effect that workloads which used to work fine will
suddenly start failing. Even workloads comprised of short batches but in
long dependency chains can be terminated.
And because of lack of agreement on usefulness and safety of fence error
propagation this partial execution can be invisible to userspace even if
it is "listening" to returned fence status.
Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.
Given all this I am personally not convinced the scheme is a good idea.
Intuitively it feels object importers would be better positioned to
enforce the time they are willing to wait for something to complete.
v2:
* Improved commit message and Kconfig text.
* Pull in some helper code from patch which got dropped.
v3:
* Bump timeout to 20s to see if it helps Tigerlake.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-7-tvrtko.ursulin@linux.intel.com
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activated due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.
If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.
Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().
Associated timeout value is stored in rq->context.watchdog.timeout_us.
v2:
* Log expiration.
v3:
* Include more information about user timeline in the log message.
v4:
* Remove obsolete comment and fix formatting. (Matt)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-6-tvrtko.ursulin@linux.intel.com
With the watchdog cancelling requests asynchronously to preempt-to-busy we
need to relax one assert making it apply only to requests not in error.
v2:
* Check against the correct request!
v3:
* Simplify the check to avoid the question of when to sample the fence
error vs sentinel bit.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-5-tvrtko.ursulin@linux.intel.com
Disallow sentinel requests follow previous sentinels to make request
cancellation work better when faced with a chain of requests which have
all been marked as in error.
Because in cases where we end up with a stream of cancelled requests we
want to turn off request coalescing so they each will get individually
skipped by the execlists_schedule_in (which is called per ELSP port, not
per request).
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
[danvet: Fix typo in the commit message that Matthew spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-4-tvrtko.ursulin@linux.intel.com
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests.
v3 (Tvrtko):
* Remove error propagation to waiters for now.
v4 (Tvrtko):
* Rebase for extracted i915_request_active_engine. (Matt)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
[danvet: Resolve conflict because intel_engine_flush_scheduler is
still called intel_engine_flush_submission]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-3-tvrtko.ursulin@linux.intel.com
Move active engine lookup to exported i915_request_active_engine.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
[danvet: Slight rebase, engine->sched.lock is still called
engine->active.lock.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324121335.2307063-2-tvrtko.ursulin@linux.intel.com
- Use FOLL_FORCE and FOLL_LONGTERM in etnaviv
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAmBcd18ACgkQ/lWMcqZw
E8O93Q/8CIWUUSz3gjsyGbXi1zGFkWFAvVTrao6+G8rk+n1tH2w3hH8NzdL0HMOT
od892bChpYxovVrY0J4t4BTLoUYunP9/8cEQ7Y0Bk5e26vZffmz5eWHmW37Dz6Nl
MEG2PEHhqmjHQ7+/jZSjvMFfAnxTKYqWtvqE7ZGHPGq71jyL35Fdwuei54AlVOW7
lMFlRkkvhqr+d9h4OGZt1JNfBw//kyKJtksSiRM99MJhlUCygSF/889GR/U6txED
MclR2W3nQ3BcmqC6TI68KDtI4jbbB/JThPjKq8pzRrNKCvlOsa7NYpbDUu+UKupF
KEZ43Jgdq6GgpKknQfLjvMq0b0k55TvS1wSNSQaAvKYrByPRBSvzjj5dZD6bWxbX
ISCy1cjDvEw943MrH94ZYwgZ6aoq++3WDHpGyd0HsKSTkixIx5xDrx4qGh60oAQZ
gRagXzh4i8WHupTc5uhB0w0+ekEb5P8X8Hy5A/qi0CPcPCphbdegsfsMeoE06Ev+
UbZ7cDKMHN35WtLE41BC9/f7ztORLs1x3QF7XVr2UUciegtP5vt9LEshl0UyVCbq
yh/+mdVUAYQ+0E9yFL+Ks9MZ5+A9bT8NfORokS77Iu1YZATGkaJUyiQRRc7AVuD+
nPK2XFbPOY9gP3wZomNJ/O8pR/Y0mV5F2JfnwK3/aDoL/lU5kgM=
=MdU9
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2021-03-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.12:
- Use FOLL_FORCE and FOLL_LONGTERM in etnaviv
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/72d4c9ce-6709-4e0f-a715-79fdcebb48e7@linux.intel.com
The i915 driver has its own tasklet interface which was overseen in the
tasklet rework. __tasklet_disable_sync_once() is a wrapper around
tasklet_unlock_wait(). tasklet_unlock_wait() might sleep, but the i915
wrappers invokes it from non-preemtible contexts with bottom halves disabled.
Use tasklet_unlock_spin_wait() instead which can be invoked from
non-preemptible contexts.
Fixes: da04474740 ("tasklets: Replace spin wait in tasklet_unlock_wait()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210323092221.awq7g5b2muzypjw3@flow
ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
It has a flexible configuration of MIPI DSI signal input and
produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322103328.66442-2-jagan@amarulasolutions.com
Fix the following coccicheck warning:
drivers/gpu/drm/bridge/lontium-lt9611uxc.c:858:8-16: WARNING: use
scnprintf or sprintf.
Reported-by: Abaci Robot<abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1612689000-64577-1-git-send-email-jiapeng.chong@linux.alibaba.com
4k requires two dsi pipes, so don't report MODE_OK when only a
single pipe is configured. But rather report MODE_PANEL to
signal that requirements of the panel are not being met.
Reported-by: Peter Collingbourne <pcc@google.com>
Suggested-by: Peter Collingbourne <pcc@google.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Anibal Limon <anibal.limon@linaro.org>
Tested-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org
When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:
drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]
Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.
The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
LDB channel1 should be registered if it is the only channel to be used.
Without this patch, imx_ldb_bind() would skip registering LDB channel1
if LDB channel0 is not used, no matter LDB channel1 needs to be used or
not.
Fixes: 8767f4711b (drm/imx: imx-ldb: move initialization into probe)
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Put DRM device on initialization failure path rather than directly
return error code.
Fixes: a67d5088ce ("drm/imx: drop explicit drm_mode_config_cleanup")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
While Kepler does technically support 256x256 cursors, it turns out that
Kepler actually has some additional requirements for scanout surfaces that
we're not enforcing correctly, which aren't present on Maxwell and later.
Cursor surfaces must always use small pages (4K), and overlay surfaces must
always use large pages (128K).
Fixing this correctly though will take a bit more work: as we'll need to
add some code in prepare_fb() to move cursor FBs in large pages to small
pages, and vice-versa for overlay FBs. So until we have the time to do
that, just limit cursor surfaces to 128x128 - a size small enough to always
default to small pages.
This means small ovlys are still broken on Kepler, but it is extremely
unlikely anyone cares about those anyway :).
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: d3b2f0f792 ("drm/nouveau/kms/nv50-: Report max cursor size to userspace")
Cc: <stable@vger.kernel.org> # v5.11+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We check for idle during debug prints and other debugging actions.
Simplify the flow by not touching execlists state.
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/20210205174358.28465-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Wait for the GPU to wake up from the semaphore before measuring the
time, so that we coordinate the sampling on both the CPU and GPU for
more accurate comparisons.
v2: Switch to local_irq_disable() as once suggested by Mika.
Reported-by: Bruce Chang <yu.bruce.chang@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: CQ Tang <cq.tang@intel.com>
Reviewed-by: Bruce Chang <yu.bruce.chang@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205112912.22978-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some future patches we will need to also support a stolen region
carved from device local memory, on platforms like DG1. To handle this
we can simply describe each in terms of its own memory class.
Signed-off-by: Matthew Auld <matthew.auld@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/20210205102026.806699-2-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Get rid of the strange REGION_MAP encoding stuff and just use an
explicit class/instance pair for each region. This better matches our
future uAPI where all queryable regions are identified with a u16 class
and u16 instance.
v2: fix whitespace
Signed-off-by: Matthew Auld <matthew.auld@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/20210205102026.806699-1-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the defaults we store on the engine when resetting the heartbeat as
we may have had to adjust it from the config value during initialisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210204211303.21347-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For the PTEs we get an LM bit, to signal whether the page resides in
SMEM or LMEM.
Based on a patch from Michel Thierry.
BSpec: 45015
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20210203171231.551338-3-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For the PTEs we get an LM bit, to signal whether the page resides in
SMEM or LMEM.
BSpec: 45040
v2: just use gen8_pte_encode for dg1
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@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/20210203171231.551338-2-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for Xe HP multi-tile architecture with multiple memory
regions, we need to be able differentiate multiple instances of device
local-memory.
Note that the region name is just to give it a human friendly
identifier, instead of using class/instance which also uniquely
identifies the region. So far the region name is only for our own
internal debugging in the kernel(like in the selftests), or debugfs
which prints the list of regions, including the regions name.
v2: add commentary for our current region name use
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210203171231.551338-1-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have not seen an occurrence of the false restart state recenty, and if
we did see such an event from inside engine-reset, it would deadlock on
trying to suspend the tasklet to read the register state (from inside
the tasklet). Instead, we inspect the context state before submission
which will alert us to any issues prior to execution on HW.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210201164222.14455-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of copying the whole table to each category (mocs, l3cc), use a
single table with a pointer to it if the category is enabled.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210201100448.9802-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As soon as we mark a request as completed, it may be retired. So when
cancelling a request and marking it complete, make sure we first keep a
reference to the request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210201085715.27435-4-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prefer allocating the cmd ring from LMEM on dgfx.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-8-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prefer allocating the engine scratch from LMEM on dgfx.
v2: flatten the chain
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-7-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prefer allocating the context from LMEM on dgfx.
Based on a patch from Michel Thierry.
v2: flatten the chain
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-6-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On DG1 A0/B0 steppings the first 1MB of local memory must be reserved.
One reason for this is that the 0xA0000-0xB0000 range is not accessible
by the display, probably since this region is redirected to another
memory location for legacy VGA compatibility.
BSpec: 50586
Testcase: igt/kms_big_fb/linear-64bpp-rotate-0
v2:
- Reserve the memory on B0 as well.
v3: replace DRM_DEBUG/DRM_ERROR with drm_dbg/drm_err
v4: fix the insanity
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-5-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the following patch we need to reserve regions unaccessible to the
driver during initialization, so add mem->reserved for collecting such
regions.
v2: turn into an actual intel_memory_region_reserve api
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-4-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The lmem region needs to remove the stolen part, which should just be a
case of snipping it off the end.
Signed-off-by: CQ Tang <cq.tang@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-3-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Hook up the LMEM region. Addresses will start from zero, and for CPU
access we get LMEM_BAR which is just a 1:1 mapping of said region.
Based on a patch from Michel Thierry.
v2 by Jani:
- use intel_uncore_read/intel_uncore_write
- remove trailing blank line
v3: s/drm_info/drm_dbg for info which in non-pertinent for the user
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@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/20210127131417.393872-2-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Device local memory is very much a GT thing, therefore it should be the
responsibility of the GT to setup the device local memory region.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@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/20210127131417.393872-1-matthew.auld@intel.com
[danvet: Rebase conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This converts the driver to use the new tasklet API introduced in
commit 12cc923f1c ("tasklet: Introduce new initialization API")
v2: Fix up selftests/execlists.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
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/20210126150155.1617-1-kernel@esmil.dk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The largest possible order is (63-PAGE_SHIFT), given that our min chunk
size is PAGE_SIZE. With that we should only need at most 6 bits to
represent all possible orders, giving us back 4 bits for other potential
uses. Include a simple selftest to verify this.
Signed-off-by: Matthew Auld <matthew.auld@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/20210126103019.177622-1-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In defer_request() we start with the request we just unsubmitted (that
should be the active request on the gpu) and then defer all of its
waiters. No waiter should be ahead of the active request, so none should
be marked as active. That assert failed.
Of particular note this machine was undergoing persistent GPU resets due
to underlying HW issues, so that may be a clue. A request is also marked
as active when it is retired, regardless of current queue status, and so
this assertion failure may be a result of the queue being completed by
the reset and then subsequently processed by the tasklet.
We can filter out retired requests here by doing the assertion check
after the is-ready check (active is a subset of being ready).
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2978
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/20210125140136.10494-2-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Throw it into a simple helper, and throw a warning if we encounter an
object which has been initialised with an object size that exceeds our
limit of INT_MAX pages.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@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/20210122181514.541436-2-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least for the time being, we need to limit our object sizes such that
the number of pages can fit within a 32b signed int. It looks like we
should also apply the same restriction to any imported dma-buf.
Signed-off-by: Matthew Auld <matthew.auld@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/20210122181514.541436-1-matthew.auld@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Checkpatch worries that the 'return' before an else clause might be
redundant. In this case, it is avoiding hitting the MISSING_CASE()
warning. Let us appease checkpatch by falling through to the end of the
function, which typically means that we then clean up the unused
wa_list.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122192913.4518-10-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Checkpatch spotted a couple of commas where we can use the more common
';', and so not worry about the subtle implications of sequence points.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122192913.4518-8-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit 6ce1c33d6c ("drm/i915: Kill INTEL_SUBPLATFORM_AML") removed the
only platform which used bit 2 so could also decrease the
INTEL_SUBPLATFORM_BITS definition.
This is not a fixes material but still lets make it precise.
v2:
* Fix assert in intel_device_info_subplatform_init by introducing
INTEL_SUBPLATFORM_MASK. (Chris)
* Update intel_subplatform().
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
References: 6ce1c33d6c ("drm/i915: Kill INTEL_SUBPLATFORM_AML")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121161936.746591-2-tvrtko.ursulin@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For reasons I cannot explain, except to say this is Sandybridge after
all, call stop_ring() again dring ring resume in order to prevent
mysterious hard hangs.
Testcase: igt/i915_selftest/hangcheck # snb
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210121154950.19898-3-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we are not using any internal priority levels, and in the next few
patches will introduce a new index for which the optimisation is not so
lear cut, discard the small table within the priolist.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210120121439.17600-1-chris@chris-wilson.co.uk
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Update logic to program AUD_FREQ_CNTRL register based on new guidance.
Earlier this register was configured by BIOS and driver discovered the
value at init. This is no longer recommended and instead driver should
set the values based on the hardware revision.
Add the recommended values for all supported hardware. This change applies
for all GEN12+ hardware. For TGL, some special case handling is needed
to not break existing systems.
Extend the debug print to also include values of the register as written
by BIOS. This can help debug rare cases where BIOS has configured the link
settings to incorrect values.
Bspec: 49279
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324123725.4170214-1-kai.vehmanen@linux.intel.com
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts with the mmu notifier we have,
because we recurse between reset mutex and mmap lock -> mmu notifier.
Remove this recursion by calling revoke_mmaps before taking the lock.
The reset code still needs fixing, as taking mmap locks during reset
is not allowed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
[danvet: Add FIXME.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-64-maarten.lankhorst@linux.intel.com
Instead of force unbinding and rebinding every time, we try to check
if our notifier seqcount is still correct when pages are bound. This
way we only rebind userptr when we need to, and prevent stalls.
Changes since v1:
- Missing mutex_unlock, reported by kbuild.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-63-maarten.lankhorst@linux.intel.com
We need to lock the global gtt dma_resv, use i915_vm_lock_objects
to handle this correctly. Add ww handling for this where required.
Add the object lock around unpin/put pages, and use the unlocked
versions of pin_pages and pin_map where required.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-61-maarten.lankhorst@linux.intel.com
igt_emit_store_dw needs to use the unlocked version, as it's not
holding a lock. This fixes igt_gpu_fill_dw() which is used by
some other selftests.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-51-maarten.lankhorst@linux.intel.com
We may create page table objects on the fly, but we may need to
wait with the ww lock held. Instead of waiting on a freed obj
lock, ensure we have the same lock for each object to keep
-EDEADLK working. This ensures that i915_vma_pin_ww can lock
the page tables when required.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-41-maarten.lankhorst@linux.intel.com
Because of the long lifetime of the mapping, we cannot wrap this in a
simple limited ww lock. Just use the unlocked version of pin_map,
because we'll likely release the mapping a lot later, in a different
thread.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-39-maarten.lankhorst@linux.intel.com
vmap is using pin_pages, but needs to use ww locking,
add pin_pages_unlocked to correctly lock the mapping.
Also add ww locking to begin/end cpu access.
Changes since v1:
- Fix i915_gem_map_dma_buf by using pin_pages_unlocked().
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-38-maarten.lankhorst@linux.intel.com
In the ucode functions, the calls are done before userspace runs,
when debugging using debugfs, or when creating semi-permanent mappings;
we can safely use the unlocked versions that does the ww dance for us.
Because there is no pin_pages_unlocked yet, add it as convenience function.
This removes possible lockdep splats about missing resv lock for ucode.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-37-maarten.lankhorst@linux.intel.com
By default, we assume that it's called inside igt_create_request
to keep existing selftests working, but allow for manual pinning
when passing a ww context.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-34-maarten.lankhorst@linux.intel.com
Stolen objects need to lock, and we may call put_pages when
refcount drops to 0, ensure all calls are handled correctly.
Changes since v1:
- Rebase on top of upstream changes.
Idea-from: Thomas Hellström <thomas.hellstrom@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-33-maarten.lankhorst@linux.intel.com
We need to take the obj lock to pin pages, so wait until the callers
have done so, before making the object unshrinkable.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-30-maarten.lankhorst@linux.intel.com
Take the ww lock around engine_unpark. Because of the
many many places where rpm is used, I chose the safest option
and used a trylock to opportunistically take this lock for
__engine_unpark.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-28-maarten.lankhorst@linux.intel.com
Make creation separate from pinning, in order to take the lock only
once, and pin the mapping with the lock held.
Changes since v1:
- Rebase on top of upstream changes.
Changes since v2:
- Fully clear wa_ctx on error.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-27-maarten.lankhorst@linux.intel.com
We previously complained when ww == NULL.
This function is now only used in selftests to pin an object,
and ww locking is now fixed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
[danvet: Resolve conflict because we don't have a set-domain refactor,
see
https://lore.kernel.org/intel-gfx/20210203090205.25818-8-chris@chris-wilson.co.uk/
The really worrying thing here is that the above patch had a change in
arguments for i915_gem_object_set_to_gtt_domain(), without any
explanation. I decided to just faithfully apply Maarten's change but
not the argument change which was in Maarten's context diff.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-26-maarten.lankhorst@linux.intel.com
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-25-maarten.lankhorst@linux.intel.com
We map the initial context during first pin.
This allows us to remove pin_map from state allocation, which saves
us a few retry loops. We won't need this until first pin anyway.
intel_ring_submission_setup() is also reworked slightly to do all
pinning in a single ww loop.
Changes since v1:
- Handle -EDEADLK backoff in intel_ring_submission_setup() better.
- Handle smatch errors reported by Dan and testbot.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-20-maarten.lankhorst@linux.intel.com
With userptr fixed, there is no need for all separate lockdep classes
now, and we can remove all lockdep tricks used. A trylock in the
shrinker is all we need now to flatten the locking hierarchy.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
[danvet: Resolve conflict because we don't have the patch from Chris
to rebrand i915_gem_shrinker_taints_mutex to fs_reclaim_taints_mutex.
It's not a bad idea, but if we do it, it should be moved to the right
header. See
https://lore.kernel.org/intel-gfx/20210202154318.19246-1-chris@chris-wilson.co.uk/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-18-maarten.lankhorst@linux.intel.com
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.
Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
[danvet: s/kfree/kvfree/ in i915_gem_object_userptr_drop_ref in the
previous review round, but which got lost. The other open questions
around page refcount are imo better discussed in a separate series,
with amdgpu folks involved].
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-17-maarten.lankhorst@linux.intel.com
Now that unsynchronized mappings are removed, the only time userptr
works is when the MMU notifier is enabled. Put all of the userptr
code behind a mmu notifier ifdef.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-16-maarten.lankhorst@linux.intel.com
We should not allow this any more, as it will break with the new userptr
implementation, it could still be made to work, but there's no point in
doing so.
Inspection of the beignet opencl driver shows that it's only used
when normal userptr is not available, which means for new kernels
you will need CONFIG_I915_USERPTR.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-15-maarten.lankhorst@linux.intel.com
There are a couple of ioctl's related to tiling and cache placement,
that make no sense for userptr, reject those:
- i915_gem_set_tiling_ioctl()
Tiling should always be linear for userptr. Changing placement will
fail with -ENXIO.
- i915_gem_set_caching_ioctl()
Userptr memory should always be cached. Changing caching mode will
fail with -ENXIO.
- i915_gem_set_domain_ioctl()
Still temporarily allowed to work as intended, it's used to check
userptr validity. With the reworked userptr code, it will keep
working for this usecase.
This plus the previous changes have been tested against beignet
by using its own unit tests, and intel-video-compute by using
piglit's opencl tests.
Changes since v1:
- set_domain was apparently used in iris for checking userptr validity,
keep it working as intended.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-14-maarten.lankhorst@linux.intel.com
It doesn't make sense to export a memory address, we will prevent
allowing access this way to different address spaces when we
rework userptr handling, so best to explicitly disable it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-13-maarten.lankhorst@linux.intel.com
Userptr should not need the kernel for a userspace memcpy, userspace
needs to call memcpy directly.
Specifically, disable i915_gem_pwrite_ioctl() and i915_gem_pread_ioctl().
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-12-maarten.lankhorst@linux.intel.com
Instead of having a global lock for potentially less contention.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/424010/
Instead evict round robin from each devices SYSTEM and TT domain.
v2: reorder num_pages access reported by Dan's script
v3: fix rebase fallout, num_pages should be 32bit
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/424009/
Move the iteration of the global lru into the new function
ttm_global_swapout() and use that instead in drivers.
v2: consistently return int
v3: fix build fail
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/424008/
To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done
w/o the overhead of runtime resume), we have to use the runtime PM
get-if-active logic: If the runtime PM usage count is 0 (and so
get-if-in-use would return false) the runtime suspend handler is not
necessarily called yet (it could be just pending), so the device is not
necessarily powered down, and so the runtime resume handler is not
guaranteed to be called.
The fence revocation depends on the above deferral, so add a
get-if-active helper and use it during fence revocation.
v2:
- Add code comment explaining the fence reg programming deferral logic
to i915_vma_revoke_fence(). (Chris)
- Add Cc: stable and Fixes: tags. (Chris)
- Fix the function docbook comment.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.12+
Fixes: 181df2d458 ("drm/i915: Take rpm wakelock for releasing the fence on unbind")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com
(cherry picked from commit 9d58aa4629)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
As soon as we install fences, we should stop allocating memory
in order to prevent any potential deadlocks.
This is required later on, when we start adding support for
dma-fence annotations.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-11-maarten.lankhorst@linux.intel.com
Simple adding of i915_gem_object_lock, we may start to pass ww to
get_pages() in the future, but that won't be the case here;
We override shmem's get_pages() handling by calling
i915_gem_object_get_pages_phys(), no ww is needed.
Changes since v1:
- Call shmem put pages directly, the callback would
go down the phys free path.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-10-maarten.lankhorst@linux.intel.com
Instead of creating a separate object type, we make changes to
the shmem type, to clear struct page backing. This will allow us to
ensure we never run into a race when we exchange obj->ops with other
function pointers.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-9-maarten.lankhorst@linux.intel.com
We want to remove the changing of ops structure for attaching
phys pages, so we need to kill off HAS_STRUCT_PAGE from ops->flags,
and put it in the bo.
This will remove a potential race of dereferencing the wrong obj->ops
without ww mutex held.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
[danvet: apply with wiggle]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-8-maarten.lankhorst@linux.intel.com
Currently we have a lot of places where we hold the gem object lock,
but haven't yet been converted to the ww dance. Complain loudly about
those places.
i915_vma_pin shouldn't have the obj lock held, so we can do a ww dance,
while i915_vma_pin_ww should.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> #irc
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-6-maarten.lankhorst@linux.intel.com
i915_vma_pin may fail with -EDEADLK when we start locking page tables,
so ensure we handle this correctly.
Changes since v1:
- Drop -EDEADLK todo, this commit handles it.
- Change eb_pin_vma from sort-of-bool + -EDEADLK to a proper int. (Matt)
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-5-maarten.lankhorst@linux.intel.com
We need to get rid of allocations in the cmd parser, because it needs
to be called from a signaling context, first move all pinning to
execbuf, where we already hold all locks.
Allocate jump_whitelist in the execbuffer, and add annotations around
intel_engine_cmd_parser(), to ensure we only call the command parser
without allocating any memory, or taking any locks we're not supposed to.
Because i915_gem_object_get_page() may also allocate memory, add a
path to i915_gem_object_get_sg() that prevents memory allocations,
and walk the sg list manually. It should be similarly fast.
This has the added benefit of being able to catch all memory allocation
errors before the point of no return, and return -ENOMEM safely to the
execbuf submitter.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-4-maarten.lankhorst@linux.intel.com
We're starting to require the reservation lock for pinning,
so wait until we have that.
Update the selftests to handle this correctly, and ensure pin is
called in live_hwsp_rollover_user() and mock_hwsp_freelist().
Changes since v1:
- Fix NULL + XX arithmatic, use casts. (kbuild)
Changes since v2:
- Clear entire cacheline when pinning.
Changes since v3:
- CACHELINE_BYTES -> TIMELINE_SEQNO_BYTES. (jekstrand)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-3-maarten.lankhorst@linux.intel.com
Instead of sharing pages with breadcrumbs, give each timeline a
single page. This allows unrelated timelines not to share locks
any more during command submission.
As an additional benefit, seqno wraparound no longer requires
i915_vma_pin, which means we no longer need to worry about a
potential -EDEADLK at a point where we are ready to submit.
Changes since v1:
- Fix erroneous i915_vma_acquire that should be a i915_vma_release (ickle).
- Extra check for completion in intel_read_hwsp().
Changes since v2:
- Fix inconsistent indent in hwsp_alloc() (kbuild)
- memset entire cacheline to 0.
Changes since v3:
- Do same in intel_timeline_reset_seqno(), and clflush for good measure.
Changes since v4:
- Use refcounting on timeline, instead of relying on i915_active.
- Fix waiting on kernel requests.
Changes since v5:
- Bump amount of slots to maximum (256), for best wraparounds.
- Add hwsp_offset to i915_request to fix potential wraparound hang.
- Ensure timeline wrap test works with the changes.
- Assign hwsp in intel_timeline_read_hwsp() within the rcu lock to
fix a hang.
Changes since v6:
- Rename i915_request_active_offset to i915_request_active_seqno(),
and elaborate the function. (tvrtko)
Changes since v7:
- Move hunk to where it belongs. (jekstrand)
- Replace CACHELINE_BYTES with TIMELINE_SEQNO_BYTES. (jekstrand)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> #v1
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-2-maarten.lankhorst@linux.intel.com
The warning message did not printed the LCD pixel clock rate but the LCD
clock divisor input rate. As a consequence, the required and real pixel
clock rates are now passed to the tilcdc_pclk_diff().
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322213337.26667-4-dariobin@libero.it
The tilcdc_pclk_diff() compares the requested pixel clock rate to the
real one, so passing it clk_rate instead of clk_rate / clkdiv caused
it to fail even if the clk_rate was properly set. Adding the
real_pclk_rate variable makes the code more readable.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322213337.26667-3-dariobin@libero.it
The req_rate name is a little misleading, so let's rename to pclk_rate
(pixel clock rate).
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322213337.26667-2-dariobin@libero.it
./drivers/gpu/drm/tilcdc/tilcdc_panel.c:402:3-8: No need to set .owner
here. The core will do it.
Remove .owner field if calls are used which set it automatically
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Jyri Sarha <jyri.sarha@iki.fi>
Link: https://patchwork.freedesktop.org/patch/msgid/1614762267-98454-1-git-send-email-yang.lee@linux.alibaba.com
Commit 977697e20b ("drm/atomic: Pass the full state to planes atomic
disable and update") added the old_state variable instead of what used
to be a parameter, but it also removed the sole user of that variable in
the vop_plane_atomic_update function leading to an usused variable.
Remove it.
Fixes: 977697e20b ("drm/atomic: Pass the full state to planes atomic disable and update")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319152920.262035-1-maxime@cerno.tech
To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done
w/o the overhead of runtime resume), we have to use the runtime PM
get-if-active logic: If the runtime PM usage count is 0 (and so
get-if-in-use would return false) the runtime suspend handler is not
necessarily called yet (it could be just pending), so the device is not
necessarily powered down, and so the runtime resume handler is not
guaranteed to be called.
The fence revocation depends on the above deferral, so add a
get-if-active helper and use it during fence revocation.
v2:
- Add code comment explaining the fence reg programming deferral logic
to i915_vma_revoke_fence(). (Chris)
- Add Cc: stable and Fixes: tags. (Chris)
- Fix the function docbook comment.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.12+
Fixes: 181df2d458 ("drm/i915: Take rpm wakelock for releasing the fence on unbind")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322204223.919936-1-imre.deak@intel.com
Commit 098214999c added fetching of the AUX_DPHY register
values from the vbios, but it also changed the default values
in the case when there are no values in the vbios. This causes
problems with displays with high refresh rates. To fix this,
switch back to the original default value for AUX_DPHY_TX_CONTROL.
Fixes: 098214999c ("drm/amd/display: Read VBIOS Golden Settings Tbl")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1426
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Igor Kravchenko <Igor.Kravchenko@amd.com>
Cc: Aric Cyr <Aric.Cyr@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: stable@vger.kernel.org
The HW is not in production yet. Driver support is still in development.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As noted during the review this approach doesn't make sense at all.
We should not apply any limitation on the VRAM applications can use inside the kernel.
If an application or end user wants to reserve a certain amount of VRAM for bad pages handling we should do this in the upper layer.
This reverts commit f89b881c81.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We are seeing VM page faults with this. Revert the change until the bugs
are fixed.
This reverts commit 94ae8dc557.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move the function protoype to the right header and guard
the call with CONFIG_DRM_AMD_DC_DCN as DSC is only available
with DCN.
Fixes: 8c2f14c36f ("drm/amd/display: Add changes for dsc bpp in 16ths and unify bw calculations")
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Dillon Varone <dillon.varone@amd.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dwb_cm.c:220:65-70:
WARNING: conversion to bool not needed here.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:721:65-70: WARNING:
conversion to bool not needed here.
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c:1139:67-72: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm_gem_object_put() should be paired with drm_gem_object_lookup().
All gem objs are saved in fb->base.obj[]. Need put the old first before
assign a new obj.
Trigger VRAM leak by running command below
$ service gdm restart
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
kvmalloc_array + __GFP_ZERO is the same with kvcalloc.
As for p->chunks, it will be used in:
```
if (ib_chunk->kdata)
memcpy(parser->ib.ptr, ib_chunk->kdata, ib_chunk->length_dw * 4);
```
If chunks doesn't zero out with __GFP_ZERO, it may point to somewhere else, e.g.,
```
Unable to handle kernel paging request at virtual address 0000000000010000
...
pc is at memcpy+0x84/0x250
ra is at radeon_cs_ioctl+0x368/0xb90 [radeon]
```
after allocating chunks with __GFP_KERNEL/kvcalloc, this bug is fixed.
Fixes: 3fcb4f01de ("drm/radeon: Use kvmalloc for CS chunks")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chen Li <chenli@uniontech.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We set the same variable a few lines above. Drop the duplicate
setting.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When CONFIG_DRM_AMD_SECURE_DISPLAY is enabled, it will try
to register vertical interrupt 0 for specific task.
Currently, only dcn10 have defined relevant info for vertical interrupt
0. If we enable CONFIG_DRM_AMD_SECURE_DISPLAY for other dcn ASIC, will
get DC_IRQ_SOURCE_INVALID while calling dc_interrupt_to_irq_source() and
cause pointer errors.
[How]
Add support of vertical interrupt 0 for all dcn ASIC.
v2: squash in build fix (Alex)
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Find out that when we are registering vertical interrupt0, we get
DC_IRQ_SOURCE_INVALID when call dc_interrupt_to_irq_source for
DCN_1_0__SRCID__OTG6_VERTICAL_INTERRUPT0_CONTROL.
After analyzing, it's due to the defined value for
DCN_1_0__SRCID__OTG6_VERTICAL_INTERRUPT0_CONTROL is not
(DCN_1_0__SRCID__OTG5_VERTICAL_INTERRUPT0_CONTROL + 1). It's not
incremental sequence.
[How]
Use an array to record all vertical interrupt0 SRCID. While registering
interrupt, use an incremental index to visit the array to get the right
SRCID to register.
Also add error handling to avoid potential pointer problem.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For V1_0 and V1_1, they come with different size. Misuse may cause
out of memory access.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since this is a "revert of a revert", the end effect is that freesync
video is back to its original state, the way it was before the first
revert.
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With arg 1 BACO reset, it will try to reload the SMU FW after reset.
This might failed if driver already in a pending reset status during probe period.
Arg 0 reset will bring asic back to a clean state and driver will re-init
everythign including SMU FW
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
SMU internal might need to check this pending_reset setting to decide the reset method
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is to fix the case where it only enable the light SMU
on normal device init. This feature actually need to be enabled after ASIC
been reset as well.
Signed-off-by: shaoyunl <shaoyun.liu@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
vblank_workqueue is never released.
[How]
Free it upon dm finish.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When driver disabled, we driver force the YCbCr420 to RGB,
which means some register will be changed, such as
RDPCS_PHY_DP_MPLLB_TX_CLK_DIV changed from 1 to 0
When driver re-enabled, OS will Set Mode YCbCr420 again,
which means the register RDPCS_PHY_DP_MPLLB_TX_CLK_DIV
should to be 1 again, but dmub fw can’t update the
register to 1 due to the mpll is not off
[How]
Adds an interface to disable accelerated mode bit,
which allows DM to decide to call during driver
disable/unload scenarios.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Yao Wang1 <Yao.Wang1@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
SOC needs to be updated to the WM set A values before validation
happens.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* Add debug out when viewport too small
* use max lb for latency hiding
* System black screen hangs on driver load
* Fix UBSAN warning for not a valid value for type '_Bool'
* Fix for outbox1 ring buffer typecasting issue
* Bypass sink detect when there are no eDPs connected
* Increase precision for bpp in DSC calculations
* Add changes for dsc bpp in 16ths and unify bw calculations
* Correct algorithm for reversed gamma
* Remove MPC gamut remap logic for DCN30
* Fix typo for helpers function name
* Fix secure display lock problems
* Fix no previous prototype warning
* Separate caps for maximum RGB and YUV plane counts
* Add debugfs to control DMUB trace buffer events
* [FW Promotion] Release 0.0.56
* DCHUB underflow counter increasing in some scenarios
* fix dml prefetch validation
* fix dcn3+ bw validation soc param update sequence
* add a func to disable accelerated mode
* Fix potential memory leak
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
When unplugging a display, the underflow counter can be seen to
increase because PSTATE switch is allowed even when some planes are not
blanked.
[How]
Check that all planes are not active instead of all streams before
allowing PSTATE change.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
More updates to the comments to better describe the function of
different cmds and parameters in the dmub interface.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Anthony Koo <Anthony.Koo@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
We want to have a debugfs interface to enable or disable DMCUB
trace buffer events.
[How]
Add debugfs interface to enable or disable trace buffer events.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Not all ASICs have same plane capabilities so need to split them
out for proper support handling.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Atufa Khan <Atufa.Khan@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Received compiling warning:
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5574:5:
warning: no previous prototype for 'amdgpu_dm_crtc_late_register'
[-Wmissing-prototypes]
5574 | int amdgpu_dm_crtc_late_register(struct drm_crtc *crtc)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In
function 'dm_update_mst_vcpi_slots_for_dsc':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6405:46:
warning: variable 'old_con_state' set but not used
[-Wunused-but-set-variable]
6405 | struct drm_connector_state *new_con_state, *old_con_state;
| ^~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In
function 'amdgpu_dm_commit_cursors':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8006:44:
warning: variable 'new_plane_state' set but not used
[-Wunused-but-set-variable]
8006 | struct drm_plane_state *old_plane_state, *new_plane_state;
| ^~~~~~~~~~~~~~~
vim +/amdgpu_dm_crtc_late_register +5574
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
5572
5573 #ifdef CONFIG_DRM_AMD_SECURE_DISPLAY
> 5574 int amdgpu_dm_crtc_late_register(struct drm_crtc *crtc)
5575 {
5576 crtc_debugfs_init(crtc);
5577
5578 return 0;
5579 }
5580 #endif
5581
[How]
Fix it with declaration as "static"
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Find out few locks problems while doing secure display. They are
following few parts:
1. crc_rd_work_lock in amdgpu_dm_crtc_handle_crc_window_irq() should
also use spin_lock_irqsave instead of spin_lock_irq.
2. In crc_win_update_set(), crc_rd_work_lock should be grabbed after
obtaining lock event_lock. Otherwise, will cause deadlock by conflicting
the lock order in amdgpu_dm_crtc_handle_crc_window_irq()
3. flush_work() in crc_win_update_set() is no need and will cause
deadlock since amdgpu_dm_crtc_notify_ta_to_read() also tries to grab
lock crc_rd_work_lock.
[How]
Fix above problems.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Solomon Chiu <Solomon.Chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
Word "helper" was misspelled as "helpes" in
dm_helpes_dmub_outbox0_interrupt_control function.
[how]
Fix the spelling.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Reviewed-by: Yongqiang Sun <yongqiang.sun@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why?]
Should only reroute gamut remap to mpc unless 3D LUT is not used and all
planes are using the same src->dest.
[How?]
Remove DCN30 specific logic for rerouting gamut remap to mpc.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
DCN30 needs to correctly program reversed gamma curve, which DCN20
already has.
Also needs to fix a bug that 252-255 values are clipped.
[How]
Apply two fixes into DCN30.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Calvin Hou <Calvin.Hou@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Acked-by: Vladimir Stempen <Vladimir.Stempen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why?]
Some code still expected bpp to be used in whole bits, not 16ths. dsc.c uses
redundant function now found in dc to calculate stream bandwidth from timing.
[How?]
Fix code to work with 16ths instead of whole bits for dsc bpp.
Refactor get_dsc_bandwidth to accept inputs in 16ths of a bit.
Use dc function to calculate bandwidth from timing, and make dsc bw calculation
a part of dsc.c.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dillon Varone <dillon.varone@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why?]
Many DSC variables and related functions use whole bits for bpp.
[How?]
Change variables and related functions to use 16ths of a bit for bpp.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Jun Lei <jun.lei@amd.com>
Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[How & Why]
Check DC config to determine if there are any eDPs connected. If there
are no eDPs connected, bypass sink detect when querying eDP presence.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Jake Wang <haonan.wang2@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
Compiler warning "pointer to integer of different size" reported on
outbox1 ring buffer address typecasting.
Reported-by: kernel test robot <lkp@intel.com>
[HOW]
Fixed the issue by typecasting with character pointer.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
dc_cursor_position do not initialise position.translate_by_source when
crtc or plane->state->fb is NULL. UBSAN caught this error in
dce110_set_cursor_position, as the value was garbage.
[How]
Initialise dc_cursor_position structure elements to 0 in handle_cursor_update
before calling get_cursor_position.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1471
Reported-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Reviewed-by: Aurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit dbc43d5fdf
as it causes crash on driver load in some scenarios.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Martin Leung <Martin.Leung@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable max memory lb config to improve stutter efficiency and
latency hiding. Also increase max number of lb lines to be
used by dml since experiments have shown that there isnt a hard max
beyond what fits in lb.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Eric Bernstein <Eric.Bernstein@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Bumping DC version for DMU FW fix
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Workload number mapped to the correct one.
This issue is only on vega10.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Some ASICs do not have GOP driver to copy vbios image into
VFCT table. And it will go to next check.
Signed-off-by: Feifei Xu <Feifei.Xu@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It was leftover from radeon where it was required for some
specific old hardware. It hasn't been required for ages
and the driver already falls back to MMIO when legacy IO
is not available. Legacy IO also seems to be problematic on
on some thunderbolt devices. Drop it.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c:358:69-74: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The variable result is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is a spelling mistake in an assert message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Driver doesn't keep the default bootup power limit and expose it
to user. As requested we add it in driver.
Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Interrupts on are non-reentrant on linux. This is just an ancient
leftover from radeon where irq processing was kicked of from different
places.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
memalloc_nofs_save/restore are no longer sufficient to prevent recursive
lock warnings when holding locks that can be taken in MMU notifiers. Use
memalloc_noreclaim_save/restore instead.
Fixes: f920e413ff ("mm: track mmu notifiers in fs_reclaim_acquire/release")
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
cause:
It is necessary to send ras disable command to ras-ta during gfx
block ras later init, because the ras capability is disable read
from vbios for vega20 gaming, but the ras context is released
during ras init process, this will cause send ras disable command
to ras-to failed.
how:
Delay releasing ras context, the ras context
will be released after gfx block later init done.
Changed from V1:
move release_ras_context into ras_resume
Changed from V2:
check BIT(UMC) is more reasonable before access eeprom table
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[why]
the dcn301_calculate_wm_and_dl() calculation exposed a issue
- switch to dcn30 version for now.
still need to follow up with dcn301 watermark updates version.
v2: squash in warning fix
Signed-off-by: Charles Sun <charles.sun@amd.com>
Reviewed-by: Nikola Cornij <nikola.cornij@amd.com>
Acked-by: Charles Sun <charles.sun@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
arcturus and sienna_cichlid share the same version
of umc_info interface (umc_info v33). arcturus uses
umc_config to indicate ECC capability, while
sienna_cichlid uses umc_config1 to indicate ECC
capability. driver needs to check either umc_config
or umc_config1 to decide ECC capability for ASICs
that use umc_info v33 interface.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Frank Min <Frank.Min@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Separate the drm_mm_node walking from the actual handling.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Allows to walk over the drm_mm nodes in a TTM resource object.
v2: squash in fix from Felix
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Oak Zeng <Oak.Zeng@amd.com>
Tested-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cleanup pdb0 bo before bo_fini gets called
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
new member introduced in umc_info v3_3 to indicate
ECC capability
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
1. make function mmhub_v1_7_setup_vm_pt_regs static
2. indent a if statement
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
ioremap_cache is not supported on some architecture
such as s390. Put the codes into a #ifdef to fix
some compile error reported by test robot.
v2: squash in non-x86 fix
Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
Reported-by: Kernel test robot <lkp@intel.com>
Reviewed-by: Christian Konig <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 73bf5cad26.
Fixed in newer firmware
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to `amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to `amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to `amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to `amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to `amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to `amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to `amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to `amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
gfx_v8_0_parse_sq_irq() is using in_task() to distinguish if it is
invoked from a workqueue worker or directly from the interrupt handler.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
gfx_v8_0_parse_sq_irq() is invoked directly either from a worker or from
the interrupt service routine. The worker is only bypassed if the worker
is already busy.
Add an argument `from_wq' to gfx_v8_0_parse_sq_irq() which is true if
invoked from the worker.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
gfx_v9_0_get_gpu_clock_counter() acquires a mutex_t lock and is the only
caller of gfx_v9_0_kiq_read_clock().
If it safe to acquire a mutex_t then gfx_v9_0_get_gpu_clock_counter() is
always invoked from preemptible context.
Remove in_interrupt() because it superfluous as it will always return
false.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
