[Why]
DCE legacy optimization path isn't well tested under new DC optimization
flow which can result in underflow occuring when initializing X11 on
Carrizo.
[How]
Retain the legacy optimization flow for DCE and keep the new one for DCN
to satisfy optimizations being correctly applied for ASIC that can
support it.
Fixes: 34316c1e56 ("drm/amd/display: Optimize bandwidth on following fast update")
Reported-by: Tom St Denis <tom.stdenis@amd.com>
Tested-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
For optimal power savings on panels that can support it.
This was previously left disabled by default because of issues with
compositors that do not pageflip and scan out directly to the
frontbuffer.
For these compositors we now have detection methods that wait for x
number of pageflips after a full update - triggered by a buffer or
format change typically.
This may introduce bugs or new cases not tested by users so this is
only currently targeting newer DCN.
[How]
Add code in DM to set PSR state by default for newer DCN while falling
back to the feature mask for older.
Add a global debug flag that can be set to disable it for either.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
Avoid conflict with address ranges mapped by SVM
mechanism that try to be allocated again through
ioctl_alloc in the same process. And viceversa.
[How]
For ioctl_alloc_memory_of_gpu allocations
Check if the address range passed into ioctl memory
alloc does not exist already in the kfd_process
svms->objects interval tree.
For SVM allocations
Look for the address range into the interval tree VA from
the VM inside of each pdds used in a kfd_process.
Signed-off-by: Alex Sierra <alex.sierra@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's used internally by firmware. Using it in the driver
could conflict with firmware.
v2: squash in fix for navi1x (Alex)
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop
all currently held locks using drm_modeset_backoff(). Failing to do so
will result in warnings and backtraces on the paths trying to lock a
contended lock. Add support for optionally printing the backtrace on the
path that hit the deadlock and didn't gracefully handle the situation.
For example, the patch [1] inadvertently dropped the return value check
and error return on replacing calc_watermark_data() with
intel_compute_global_watermarks(). The backtraces on the subsequent
locking paths hitting WARN_ON(ctx->contended) were unhelpful, but adding
the backtrace to the deadlock path produced this helpful printout:
<7> [98.002465] drm_modeset_lock attempting to lock a contended lock without backoff:
drm_modeset_lock+0x107/0x130
drm_atomic_get_plane_state+0x76/0x150
skl_compute_wm+0x251d/0x2b20 [i915]
intel_atomic_check+0x1942/0x29e0 [i915]
drm_atomic_check_only+0x554/0x910
drm_atomic_nonblocking_commit+0xe/0x50
drm_mode_atomic_ioctl+0x8c2/0xab0
drm_ioctl_kernel+0xac/0x140
Add new CONFIG_DRM_DEBUG_MODESET_LOCK to enable modeset lock debugging
with stack depot and trace.
[1] https://lore.kernel.org/r/20210924114741.15940-4-jani.nikula@intel.com
v2:
- default y if DEBUG_WW_MUTEX_SLOWPATH (Daniel)
- depends on DEBUG_KERNEL
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211001091444.8177-1-jani.nikula@intel.com
As per the comment on top of acpi_evaluate_dsm():
| * Evaluate device's _DSM method with specified GUID, revision id and
| * function number. Caller needs to free the returned object.
We should free the returned object of acpi_evaluate_dsm() to avoid memory
leakage. Otherwise the kmemleak splat will be triggered at boot time (if we
compile kernel with CONFIG_DEBUG_TEST_DRIVER_REMOVE=y).
Fixes: 8e55f99c51 ("drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops")
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210906033541.862-1-yuzenghui@huawei.com
(cherry picked from commit 149ac2e7ae)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
even when LVDS outputs are not used. For this reason, the rcar-lvds
driver probes successfully on those platforms even if no further bridge
or panel is connected to the LVDS output, in order to provide the
rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU
driver.
If an LVDS output isn't connected, trying to create a DRM connector for
the output will fail. Fix this by skipping connector creation in that
case, and also skip creation of the DRM encoder as there's no point in
an encoder without a connector.
Fixes: e9e056949c ("drm: rcar-du: lvds: Convert to DRM panel bridge helper")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
(cherry picked from commit 187502afe8)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Need to resync drm-intel-next with TTM and PXP stuff from
drm-intel-gt-next that is now in drm/drm-next.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Components further up in the chain might ask us for supported formats.
Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display
output with mxsfb since it can't determine a proper bus format.
We handle the bus formats that correspond to the DSI formats the bridge
can potentially output (see chapter 13.6 of the i.MX 8MQ reference
manual) - which matches what xsfb can input.
Fixes: b776b0f00f ("drm: mxsfb: Use bus_format from the nearest bridge if present")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1712f2b952694fd4484dfd8576fbc5b4d7adf042.1633959458.git.agx@sigxcpu.org
The 128b/132b channel coding link training uses more straightforward TX
FFE preset values. Reuse voltage tries and max vswing for retry logic.
The delays for 128b/132b are still all wrong, but this is regardless a
step forward.
v2: Fix UHBR rate checks, use intel_dp_is_uhbr() helper
v3:
- Rebase
- Modify intel_dp_adjust_request_changed() and
intel_dp_link_max_vswing_reached() to take 128b/132b into
account. (Ville)
v4:
- Train request printing for TX FFE (Ville)
- Log 8b/10b vs. 128b/132b (Ville)
- Add helper for per-lane max vswing / tx ffe (Ville)
- Name functions with tx_ffe/vswing instead of 128b132b/8b10b
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/20211011182144.22074-2-jani.nikula@intel.com
Since commit 98659487b8 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 30000000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[ 3.305244] pgd = (ptrval)
[ 3.307989] [00000028] *pgd=00000000
[ 3.311624] Internal error: Oops: 805 [#1] SMP ARM
[ 3.316430] Modules linked in:
[ 3.319503] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+g682d702b426b #1
[ 3.326652] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.332754] PC is at __mutex_init+0x14/0x54
[ 3.336969] LR is at msm_disp_snapshot_init+0x24/0xa0
i.MX53 does not use the DPU controller.
Fix the problem by only calling msm_disp_snapshot_init() on platforms that
use the DPU controller.
Cc: stable@vger.kernel.org
Fixes: 98659487b8 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210914174831.2044420-1-festevam@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
These error paths returned 1 on failure, instead of a negative error
code. This would lead to an Oops in the caller. A second problem is
that the check for "if (ret != -ENODATA)" did not work because "ret" was
set to 1.
Fixes: 5785dd7a8e ("drm/msm: Fix duplicate gpu node in icc summary")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211001125904.GK2283@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
The return type of ktime_divns() is s64. The timeout_to_jiffies() currently
assigns the result of this ktime_divns() to unsigned long, which on 32 bit
systems may overflow. Furthermore, the result of this function is sometimes
also passed to functions which expect signed long, dma_fence_wait_timeout()
is one such example.
Fix this by adjusting the type of remaining_jiffies to s64, so we do not
suffer overflow there, and return a value limited to range of 0..INT_MAX,
which is safe for all usecases of this timeout.
The above overflow can be triggered if userspace passes in too large timeout
value, larger than INT_MAX / HZ seconds. The kernel detects it and complains
about "schedule_timeout: wrong timeout value %lx" and generates a warning
backtrace.
Note that this fixes commit 6cedb8b377 ("drm/msm: avoid using 'timespec'"),
because the previously used timespec_to_jiffies() function returned unsigned
long instead of s64:
static inline unsigned long timespec_to_jiffies(const struct timespec *value)
Fixes: 6cedb8b377 ("drm/msm: avoid using 'timespec'")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: stable@vger.kernel.org # 5.6+
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210917005913.157379-1-marex@denx.de
Signed-off-by: Rob Clark <robdclark@chromium.org>
There is no devfreq on a3xx at the moment since gpu_busy is not
implemented. This means that msm_devfreq_init() will return early
and the entire devfreq setup is skipped.
However, msm_devfreq_active() and msm_devfreq_idle() are still called
unconditionally later, causing a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Internal error: Oops: 96000004 [#1] PREEMPT SMP
CPU: 0 PID: 133 Comm: ring0 Not tainted 5.15.0-rc1 #4
Hardware name: Longcheer L8150 (DT)
pc : mutex_lock_io+0x2bc/0x2f0
lr : msm_devfreq_active+0x3c/0xe0 [msm]
Call trace:
mutex_lock_io+0x2bc/0x2f0
msm_gpu_submit+0x164/0x180 [msm]
msm_job_run+0x54/0xe0 [msm]
drm_sched_main+0x2b0/0x4a0 [gpu_sched]
kthread+0x154/0x160
ret_from_fork+0x10/0x20
Fix this by adding a check in msm_devfreq_active/idle() which ensures
that devfreq was actually initialized earlier.
Fixes: 9bc9557017 ("drm/msm: Devfreq tuning")
Reported-by: Nikita Travkin <nikita@trvn.ru>
Tested-by: Nikita Travkin <nikita@trvn.ru>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210913164556.16284-1-stephan@gerhold.net
Signed-off-by: Rob Clark <robdclark@chromium.org>
Currently there is audio not working problem after system resume from suspend
if hdmi monitor stay plugged in at DUT. However this problem does not happen
at normal operation but at a particular test case. The root cause is DP driver
signal audio with connected state at resume which trigger audio trying to setup
audio data path through DP main link but failed due to display port is not setup
and enabled by upper layer framework yet. This patch only have DP driver signal
audio only when DP is in disconnected state so that audio option shows correct
state after system resume. DP driver will not signal audio with connected state
until display enabled executed by upper layer framework where display port is
setup completed and main link is running.
Changes in V2:
-- add details commit text
Fixes: afc9b8b6ba ("drm/msm/dp: signal audio plugged change at dp_pm_resume")
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1632932224-25102-1-git-send-email-khsieh@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
This reverts commit f4be17cd5b.
Commit c1ec54b7b5
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:
WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0
So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
This reverts commit 8cdcb36534.
Commit c1ec54b7b5
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:
WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0
So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
This reverts commit bc9241be73.
Commit c1ec54b7b5
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:
WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0
So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
This reverts commit 9efb16c2fd.
Commit c1ec54b7b5
("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
would cause numerous mtk cmdq mailbox driver warning:
WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
cmdq_task_exec_done+0xb8/0xe0
So revert that patch and all the patches depend on that patch.
Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo Serra <eballetbo@gmail.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
