| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Most of struct ast_dramstruct stores hardware state. Some index
values have known or special meaning. The known values are
- 0xffff - Terminal entry in the array
- 0xff00 - Delays the programming for usecs
- 0x0004 - Sets the type of DRAM
Add constants and helper macros for these cases. Also add a helper
macro for testing. Update Gen1 and Gen2+ accordingly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-8-tzimmermann@suse.de
|
|
Declare struct ast_dramstruct in ast_post.h and remove its original
header file.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-7-tzimmermann@suse.de
|
|
Move POST code for Gen2+ and Gen1 to separate source files and
hide it in ast_2100_post() ans ast_2000_post(). With P2A
configuration, the POST logic for these chip generations has
been mingled in ast_init_dram_reg(). Hence, handle all generations
in a single change. The split simplifies both cases. Also move
the DRAM init tables for each Gen into the respective source
file. No changes to the overall logic.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-6-tzimmermann@suse.de
|
|
Move POST code for Gen4+ to separate source file and hide it in
ast_2300_post(). With P2A configuration, it performs a full board
POST and enables the transmitter chip; otherwise it only enables the
transmitter chip.
Also fix coding style in several places. No changes to the overall
logic.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-5-tzimmermann@suse.de
|
|
Move POST code for Gen6+ to separate source file and hide it in
ast_2500_post(). With P2A configuration, it performs a full board
POST; otherwise it enables the transmitter chip. No changes to the
overall logic.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-4-tzimmermann@suse.de
|
|
Move POST code for Gen7+ to separate source file and hide it in
ast_2600_post(). There's not much going on here except for enabling
the DP transmitter chip.
v2:
- simplify logic (Jocelyn)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-3-tzimmermann@suse.de
|
|
Provide POST helpers in header file before splitting up the AST
POST code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-2-tzimmermann@suse.de
|
|
Acquire GEM handles in drm_framebuffer_init() and release them in
the corresponding drm_framebuffer_cleanup(). Ties the handle's
lifetime to the framebuffer. Not all GEM buffer objects have GEM
handles. If not set, no refcounting takes place. This is the case
for some fbdev emulation. This is not a problem as these GEM objects
do not use dma-bufs and drivers will not release them while fbdev
emulation is running. Framebuffer flags keep a bit per color plane
of which the framebuffer holds a GEM handle reference.
As all drivers use drm_framebuffer_init(), they will now all hold
dma-buf references as fixed in commit 5307dce878d4 ("drm/gem: Acquire
references on GEM handles for framebuffers").
In the GEM framebuffer helpers, restore the original ref counting
on buffer objects. As the helpers for handle refcounting are now
no longer called from outside the DRM core, unexport the symbols.
v3:
- don't mix internal flags with mode flags (Christian)
v2:
- track framebuffer handle refs by flag
- drop gma500 cleanup (Christian)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers")
Reported-by: Bert Karwatzki <spasswolf@web.de>
Closes: https://lore.kernel.org/dri-devel/20250703115915.3096-1-spasswolf@web.de/
Tested-by: Bert Karwatzki <spasswolf@web.de>
Tested-by: Mario Limonciello <superm1@kernel.org>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Anusha Srivatsa <asrivats@redhat.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: <stable@vger.kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250707131224.249496-1-tzimmermann@suse.de
|
|
When debugfs file has been created by debugfs_create_file_unsafe(),
we do need the file_operations methods to use debugfs_file_{get,put}()
to prevent concurrent removal; for files created by debugfs_create_file()
that is done in the wrappers that call underlying methods, so there's
no point whatsoever duplicating that in the underlying methods themselves.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lore.kernel.org/r/20250702211408.GA3406663@ZenIV
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Extract out two copies of the identical code to
drm_sched_rq_select_entity_rr()'s epilogue to make it smaller and more
readable.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
[phasta: commit message]
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250708122121.75689-1-tvrtko.ursulin@igalia.com
|
|
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit
9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_bridge_alloc() API") and following commits.
The lack of conversion for this driver is a bug since commit a7748dd127ea
("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
which is the first commmit having added a drm_bridge_get/put() pair and
thus exposing the incorrect initial refcount issue.
Fix this by switching the driver to the new API.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/
Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-2-6285de8c3759@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit
9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_bridge_alloc() API") and following commits.
The lack of conversion for this driver is a bug since commit a7748dd127ea
("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
which is the first commmit having added a drm_bridge_get/put() pair and
thus exposing the incorrect initial refcount issue.
Fix this by switching the driver to the new API.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/
Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-1-6285de8c3759@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Fix the smatch warning,
smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:2146 amdgpu_pt_info_read()
error: we previously assumed 'fpriv' could be null (see line 2146)
"if (!fpriv && !fpriv->vm.root.bo)", It has to be an OR condition
rather than an AND which makes an NULL dereference in case fpriv is NULL.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202507090525.9rDWGhz3-lkp@intel.com/
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Link: https://lore.kernel.org/r/20250709071618.591866-1-sunil.khatri@amd.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
Fix undefined reference to amdgpu_mqd_info_fops during
debugfs_create_file if DEBUG_FS=n
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Link: https://lore.kernel.org/r/20250708101551.68033-1-sunil.khatri@amd.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
The second form is preferred, and there was no reason to use the first.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250708-nova-docs-v4-4-9d188772c4c7@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add documentation strings, comments and AES mode for completeness
to the Falcon signatures.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250708-nova-docs-v4-3-9d188772c4c7@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
sysmembar is a critical operation that the GSP falcon needs to perform
in the reset sequence. Add some code comments to clarify.
[acourbot@nvdidia.com: move relevant documentation to SysmemFlush type]
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250708-nova-docs-v4-2-9d188772c4c7@nvidia.com
[ Minor grammar fix in the PFB register documentation. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
xe_pm_runtime_put() is missed to be called for the error path in
xe_devcoredump_read().
Add function description comments for xe_devcoredump_read() to help
understand it.
v2: more detail function comments and refine goto logic (Matt)
Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking")
Cc: stable@vger.kernel.org
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250707004911.3502904-6-shuicheng.lin@intel.com
|
|
The deleted code is no longer needed because patch "drm/xe/guc: Plumb
GuC-capture into dev coredump" has removed the related usage code.
Remove the code to tidy up the function.
v2: s/bacause/because
Reviewed-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250707004911.3502904-5-shuicheng.lin@intel.com
|
|
Add several code comments to reduce acronym soup and explain how devinit
magic and bootflow works before driver loads. These are essential for
debug and development of the nova driver.
[acourbot@nvidia.com: reformat and reword a couple of sentences]
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250708-nova-docs-v4-1-9d188772c4c7@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Disable GuC communication on Xe micro controller hardware initialization
error.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4917
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250707231108.3217573-1-zhanjun.dong@intel.com
|
|
xe_bo_evict_all() is called after xe_display_pm_suspend(). So if there
is error with xe_bo_evict_all(), display pm should be restored.
Fixes: 51462211f4a9 ("drm/xe/pxp: add PXP PM support")
Fixes: cb8f81c17531 ("drm/xe/display: Make display suspend/resume work on discrete")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://lore.kernel.org/r/20250708035424.3608190-2-shuicheng.lin@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Move the source to a better place in Device Drivers -> Graphics support
now that its configurable.
v4:
- Move source location (Tvrtko)
v3:
- Patch introduced to replace per-driver config (Lucas)
Signed-off-by: Juston Li <justonli@chromium.org>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250611225145.1739201-1-justonli@chromium.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
are multi display output on rk3588/rk3568
The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL
and OVL_PORT_SEL registers, and the configuration of these two registers
can be set to take effect when the vsync signal arrives at a certain Video
Port.
If two threads for two display output choose to update these two registers
simultaneously to meet their own plane adjustment requirements(change plane
zpos or switch plane from one crtc to another), then no matter which Video
Port'svsync signal we choose to follow for these two registers, the display
output of the other Video Port will be abnormal.
This is because the configuration of this Video Port does not take
effect at the right time (its configuration should take effect when its
VSYNC signal arrives).
In order to solve this problem, when performing plane migration or
change the zpos of planes, there are two things to be observed and
followed:
1. When a plane is migrated from one VP to another, the configuration of
the layer can only take effect after the Port mux configuration is
enabled.
2. When change the zpos of planes, we must ensure that the change for
the previous VP takes effect before we proceed to change the next VP.
Otherwise, the new configuration might overwrite the previous one for
the previous VP, or it could lead to the configuration of the previous
VP being take effect along with the VSYNC of the new VP.
This issue only occurs in scenarios where multi-display output is enabled.
Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync")
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250421102156.424480-1-andyshrk@163.com
|
|
Make use of devm_clk_get_enabled() to replace devm_clk_get() and
clk_prepare_enable(), which will make the cleanup of clk code simpler.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-9-andyshrk@163.com
|
|
Switch from i2c_add_adapter() to resource managed
devm_i2c_add_adapter(), which will make the cleanup code more simpler.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-8-andyshrk@163.com
|
|
usleep_range is preferred over udelay.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-7-andyshrk@163.com
|
|
inno_hdmi_init_hw
Putting these scattered initialization code together is helpful
for the following migration to the DRM bridge driver mode.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-6-andyshrk@163.com
|
|
This function not only configure hardware reset register, but also
do some other configurations. Therefore, it is more appropriate to
name it inno_hdmi_init_hw, which will also facilitate the addition
of other functions to this function in the following patch.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-5-andyshrk@163.com
|
|
Remove unnecessary parentheses to make checkpatch happy.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-4-andyshrk@163.com
|
|
1. Prefer using the BIT macro
2. Macro argument 'n' as '(n)' to avoid precedence issues
3. Add a blank line after enum declarations
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-3-andyshrk@163.com
|
|
Since this register definition is only use in one single c
file, there is no need to put it in a separate header.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250512124615.2848731-2-andyshrk@163.com
|
|
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Signed-off-by: Yumeng Fang <fang.yumeng@zte.com.cn>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250515203554564-j1jBXUXR6bdiN6zARicC@zte.com.cn
|
|
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Considering that some code depend on the connector, the following
changes have been made:
- Only process edid in &drm_bridge_funcs.edid_read(), so no need to
store additional edid info.
- Now cdn_dp_get_sink_capability() only focused on reading DPCD_REV.
- Update bpc info in cdn_dp_bridge_atomic_enable() instead of
cdn_dp_encoder_mode_set(). Actually, the bpc data will be used in
cdn_dp_bridge_atomic_enable().
- Switch to use DRM_BRIDGE_OP_DP_AUDIO helpers.
This patch also convert to use devm_drm_bridge_alloc() API.
Tested with RK3399 EVB IND board.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250529071334.441-1-kernel@airkyi.com
|
|
Each window of a vop2 is usable by a specific set of video ports, so while
binding the vop2, we look through the list of available windows trying to
find one designated as primary-plane and usable by that specific port.
The code later wants to use drm_crtc_init_with_planes with that found
primary plane, but nothing has checked so far if a primary plane was
actually found.
For whatever reason, the rk3576 vp2 does not have a usable primary window
(if vp0 is also in use) which brought the issue to light and ended in a
null-pointer dereference further down.
As we expect a primary-plane to exist for a video-port, add a check at
the end of the window-iteration and fail probing if none was found.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250610212748.1062375-1-heiko@sntech.de
|
|
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
[on a not-upstream px30 board with lvds display]
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250526015834.102-1-kernel@airkyi.com
|
|
Pull in drm-intel-next for the updates to drm panic handling.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Panther Lake has proven to be stable through testing and use.
Remove the force_probe requirement and enable the platform by default.
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://lore.kernel.org/r/20250707201959.319406-1-matthew.s.atwood@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.17
CI:
- uprev mesa and ci-templates
- use shallow clone to speed up build jobs
- remove sdm845/cheza jobs. These runners are no more (RIP
dear chezas)
- fix runner tag for i915 cml runners
- uprev igt to pull in msm test fixes
Core:
- VM_BIND support!
- single source of truth for UBWC configuration. Adds a global soc
driver for UBWC config which is used from display and GPU. (And
later vidc/camera/etc)
- Decouple ties between GPU and KMS, adding a `separate_gpu_kms`
modparam to allow the GPU and KMS to bind to separate DRM devices.
This should better deal with more exotic SoC configurations where
the number of GPUs is different from number of DPUs. The default
behavior is to still come up as a single unified DRM device to
avoid surprising userspace.
DP:
- major rework of the I/O accessors
DPU:
- use version checks instead of feature bits
- SM8750 support
- set min_prefill_lines for SC8180X
DSI:
- SM8750 support
GPU:
- speedbin support for X1-85
- X1-45 support
MDSS:
- SM8750 support
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Robin Clark <robin.clark@oss.qualcomm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACSVV0217R+kpoWQJeuYGHf6q_4aFyEJuKa=dZZKOnLQzFwppg@mail.gmail.com
|
|
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
drm/i915 feature pull #2 for v6.17:
Features and functionality:
- Add drm_panic support for both i915 and xe drivers (Jocelyn Falempe)
- Add initial flip queue implementation, disabled by default, for LNL and PTL
(Ville)
- Add support for Wildcat Lake (WCL) display, version 30.02 (Matt Roper, Matt
Atwood, Dnyaneshwar)
- Extend drm_panel and follower support to DDI eDP (Arun)
Refactoring and cleanups:
- Make all global state objects opaque (Jani)
- Move display works to display specific unordered workqueue (Luca)
- Add and use struct drm_device based pcode interface (Jani, Lucas)
- Use clamp() instead of max()+min() combo (Ankit)
- Simplify wait for power well disable (Jani)
- Various stylistics cleanups and renames (Jani)
Fixes:
- Deal with loss of pipe DMC state (Ville)
- Fix PTL HDCP2 stream status check (Suraj)
- Add workaround for ADL-P DKL PHY DP and HDMI (Nemesa)
- Fix skl_print_wm_changes() stack usage with KMSAN (Arnd Bergmann)
- Fix PCON capability reads on non-branch devices (Chaitanya)
- Fix which platforms have ultra joiner (Ankit)
DRM core changes:
- Add ttm_bo_kmap_try_from_panic() for xe drm_panic support (Jocelyn Falempe)
- Add private pointer to struct drm_scanout buffer for xe/i915 drm_panic support
(Jocelyn Falempe)
Merges:
- Backmerge drm-next for drm_panel and xe changes (Jani)
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6d728bf6ef23681b00dfbc7da9aeae41042dee02@intel.com
|
|
There looks to be an issue in our compression handling when the BO pages
are very fragmented, where we choose to skip the identity map and
instead fall back to emitting the PTEs by hand when migrating memory,
such that we can hopefully do more work per blit operation. However in
such a case we need to ensure the src PTEs are correctly tagged with a
compression enabled PAT index on dgpu xe2+, otherwise the copy will
simply treat the src memory as uncompressed, leading to corruption if
the memory was compressed by the user.
To fix this pass along use_comp_pat into emit_pte() on the src side, to
indicate that compression should be considered.
v2 (Jonathan): tweak the commit message
Fixes: 523f191cc0c7 ("drm/xe/xe_migrate: Handle migration logic for xe2+ dgfx")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Akshata Jahagirdar <akshata.jahagirdar@intel.com>
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://lore.kernel.org/r/20250701103949.83116-2-matthew.auld@intel.com
(cherry picked from commit f7a2fd776e57bd6468644bdecd91ab3aba57ba58)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
This reverts commit fe0154cf8222d9e38c60ccc124adb2f9b5272371.
Seeing some unexplained random failures during LRC context switches with
indirect ring state enabled. The failures were always there, but the
repro rate increased with the addition of WA BB as a separate BO.
Commit 3a1edef8f4b5 ("drm/xe: Make WA BB part of LRC BO") helped to
reduce the issues in the context switches, but didn't eliminate them
completely.
Indirect ring state is not required for any current features, so disable
for now until failures can be root caused.
Cc: stable@vger.kernel.org
Fixes: fe0154cf8222 ("drm/xe/xe2: Enable Indirect Ring State support for Xe2")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250702035846.3178344-1-matthew.brost@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 03d85ab36bcbcbe9dc962fccd3f8e54d7bb93b35)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
CIRC_SPACE does not work unless the size argument is a power of 2,
allocate PF queue size on power of 2 boundary.
Cc: stable@vger.kernel.org
Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size")
Fixes: 29582e0ea75c ("drm/xe: Add page queue multiplier")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Link: https://lore.kernel.org/r/20250702213511.3226167-1-matthew.brost@intel.com
(cherry picked from commit 491b9783126303755717c0cbde0b08ee59b6abab)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Our LMEM buffer objects are not cleared by default on alloc
and during VF provisioning we only setup LMTT PTEs for the
actually provisioned LMEM range. But beyond that valid range
we might leave some stale data that could either point to some
other VFs allocations or even to the PF pages.
Explicitly clear all new LMTT page to avoid the risk that a
malicious VF would try to exploit that gap.
While around add asserts to catch any undesired PTE overwrites
and low-level debug traces to track LMTT PT life-cycle.
Fixes: b1d204058218 ("drm/xe/pf: Introduce Local Memory Translation Table")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20250701220052.1612-1-michal.wajdeczko@intel.com
(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
Calling dev_pm_domain_attach()/dev_pm_domain_detach() in bus driver
probe/remove functions can affect system behavior when the drivers
attached to the bus use devres-managed resources. Since devres actions
may need to access device registers, calling dev_pm_domain_detach() too
early, i.e., before these actions complete, can cause failures on some
systems. One such example is Renesas RZ/G3S SoC-based platforms.
If the device clocks are managed via PM domains, invoking
dev_pm_domain_detach() in the bus driver's remove function removes the
device's clocks from the PM domain, preventing any subsequent
pm_runtime_resume*() calls from enabling those clocks.
The second argument of dev_pm_domain_attach() specifies whether the PM
domain should be powered on during attachment. Likewise, the second
argument of dev_pm_domain_detach() indicates whether the domain should be
powered off during detachment.
Upcoming changes address the issue described above (initially for the
platform bus only) by deferring the call to dev_pm_domain_detach() until
after devres_release_all() in device_unbind_cleanup(). The detach_power_off
field in struct dev_pm_info stores the detach power off info from the
second argument of dev_pm_domain_attach().
Because there are cases where the device's PM domain power-on/off behavior
must be conditional (e.g., in i2c_device_probe()), the patch introduces
PD_FLAG_ATTACH_POWER_ON and PD_FLAG_DETACH_POWER_OFF flags to be passed
to dev_pm_domain_attach().
Finally, dev_pm_domain_attach() and its users are updated to use the newly
introduced PD_FLAG_ATTACH_POWER_ON and PD_FLAG_DETACH_POWER_OFF macros.
This change is preparatory.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # I2C
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20250703112708.1621607-2-claudiu.beznea.uj@bp.renesas.com
[ rjw: Changelog adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
[ +0.000020] BUG: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]
[ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733
[ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2
[ +0.000009] Tainted: [W]=WARN
[ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000004] Call Trace:
[ +0.000004] <TASK>
[ +0.000003] dump_stack_lvl+0x76/0xa0
[ +0.000011] print_report+0xce/0x600
[ +0.000009] ? srso_return_thunk+0x5/0x5f
[ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200
[ +0.000007] ? kasan_addr_to_slab+0xd/0xb0
[ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]
[ +0.000707] kasan_report+0xbe/0x110
[ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]
[ +0.000541] __asan_report_load8_noabort+0x14/0x30
[ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]
[ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu]
[ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu]
[ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu]
[ +0.000536] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu]
[ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu]
[ +0.000485] ? down_write+0xbb/0x140
[ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360
[ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu]
[ +0.000482] ? __kasan_check_write+0x14/0x30
[ +0.000004] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? up_write+0x55/0xb0
[ +0.000007] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0
[ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu]
[ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu]
[ +0.000482] pci_device_remove+0xae/0x1e0
[ +0.000008] device_remove+0xc7/0x180
[ +0.000008] device_release_driver_internal+0x3d4/0x5a0
[ +0.000007] device_release_driver+0x12/0x20
[ +0.000004] pci_stop_bus_device+0x104/0x150
[ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40
[ +0.000005] remove_store+0xd7/0xf0
[ +0.000005] ? __pfx_remove_store+0x10/0x10
[ +0.000006] ? __pfx__copy_from_iter+0x10/0x10
[ +0.000006] ? __pfx_dev_attr_store+0x10/0x10
[ +0.000006] dev_attr_store+0x3f/0x80
[ +0.000006] sysfs_kf_write+0x125/0x1d0
[ +0.000004] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? __kasan_check_write+0x14/0x30
[ +0.000005] kernfs_fop_write_iter+0x2ea/0x490
[ +0.000005] ? rw_verify_area+0x70/0x420
[ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10
[ +0.000006] vfs_write+0x90d/0xe70
[ +0.000005] ? srso_return_thunk+0x5/0x5f
[ +0.000005] ? __pfx_vfs_write+0x10/0x10
[ +0.000004] ? local_clock+0x15/0x30
[ +0.000008] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? __kasan_slab_free+0x5f/0x80
[ +0.000005] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? __kasan_check_read+0x11/0x20
[ +0.000004] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? fdget_pos+0x1d3/0x500
[ +0.000007] ksys_write+0x119/0x220
[ +0.000005] ? putname+0x1c/0x30
[ +0.000006] ? __pfx_ksys_write+0x10/0x10
[ +0.000007] __x64_sys_write+0x72/0xc0
[ +0.000006] x64_sys_call+0x18ab/0x26f0
[ +0.000006] do_syscall_64+0x7c/0x170
[ +0.000004] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10
[ +0.000006] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? __kasan_check_read+0x11/0x20
[ +0.000003] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0
[ +0.000006] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240
[ +0.000005] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? do_syscall_64+0x88/0x170
[ +0.000003] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? irqentry_exit+0x43/0x50
[ +0.000004] ? srso_return_thunk+0x5/0x5f
[ +0.000004] ? exc_page_fault+0x7c/0x110
[ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000006] RIP: 0033:0x7480c0b14887
[ +0.000005] Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[ +0.000005] RSP: 002b:00007fff142b0058 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ +0.000006] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007480c0b14887
[ +0.000003] RDX: 0000000000000001 RSI: 00007480c0e7365a RDI: 0000000000000004
[ +0.000003] RBP: 00007fff142b0080 R08: 0000563b2e73c170 R09: 0000000000000000
[ +0.000003] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff142b02f8
[ +0.000003] R13: 0000563b159a72a9 R14: 0000563b159a9d48 R15: 00007480c0f19040
[ +0.000008] </TASK>
[ +0.000445] Allocated by task 427 on cpu 5 at 29.342331s:
[ +0.000011] kasan_save_stack+0x28/0x60
[ +0.000006] kasan_save_track+0x18/0x70
[ +0.000006] kasan_save_alloc_info+0x38/0x60
[ +0.000005] __kasan_kmalloc+0xc1/0xd0
[ +0.000006] __kmalloc_cache_noprof+0x1bd/0x430
[ +0.000007] amdgpu_driver_open_kms+0x172/0x760 [amdgpu]
[ +0.000493] drm_file_alloc+0x569/0x9a0
[ +0.000007] drm_client_init+0x1b7/0x410
[ +0.000007] drm_fbdev_client_setup+0x174/0x470
[ +0.000006] drm_client_setup+0x8a/0xf0
[ +0.000006] amdgpu_pci_probe+0x510/0x10c0 [amdgpu]
[ +0.000483] local_pci_probe+0xe7/0x1b0
[ +0.000006] pci_device_probe+0x5bf/0x890
[ +0.000006] really_probe+0x1fd/0x950
[ +0.000005] __driver_probe_device+0x307/0x410
[ +0.000006] driver_probe_device+0x4e/0x150
[ +0.000005] __driver_attach+0x223/0x510
[ +0.000006] bus_for_each_dev+0x102/0x1a0
[ +0.000005] driver_attach+0x3d/0x60
[ +0.000006] bus_add_driver+0x309/0x650
[ +0.000005] driver_register+0x13d/0x490
[ +0.000006] __pci_register_driver+0x1ee/0x2b0
[ +0.000006] rfcomm_dlc_clear_state+0x69/0x220 [rfcomm]
[ +0.000011] do_one_initcall+0x9c/0x3e0
[ +0.000007] do_init_module+0x29e/0x7f0
[ +0.000006] load_module+0x5c75/0x7c80
[ +0.000006] init_module_from_file+0x106/0x180
[ +0.000006] idempotent_init_module+0x377/0x740
[ +0.000006] __x64_sys_finit_module+0xd7/0x180
[ +0.000006] x64_sys_call+0x1f0b/0x26f0
[ +0.000006] do_syscall_64+0x7c/0x170
[ +0.000005] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000013] Freed by task 1733 on cpu 5 at 59.907086s:
[ +0.000011] kasan_save_stack+0x28/0x60
[ +0.000006] kasan_save_track+0x18/0x70
[ +0.000005] kasan_save_free_info+0x3b/0x60
[ +0.000005] __kasan_slab_free+0x54/0x80
[ +0.000006] kfree+0x127/0x470
[ +0.000006] amdgpu_driver_postclose_kms+0x455/0x760 [amdgpu]
[ +0.000493] drm_file_free.part.0+0x5b1/0xba0
[ +0.000006] drm_file_free+0x13/0x30
[ +0.000006] drm_client_release+0x1c4/0x2b0
[ +0.000006] drm_fbdev_ttm_fb_destroy+0xd2/0x120 [drm_ttm_helper]
[ +0.000007] put_fb_info+0x97/0xe0
[ +0.000007] unregister_framebuffer+0x197/0x380
[ +0.000005] drm_fb_helper_unregister_info+0x94/0x100
[ +0.000005] drm_fbdev_client_unregister+0x3c/0x80
[ +0.000007] drm_client_dev_unregister+0x144/0x330
[ +0.000006] drm_dev_unregister+0x49/0x1b0
[ +0.000006] drm_dev_unplug+0x4c/0xd0
[ +0.000006] amdgpu_pci_remove+0x58/0x130 [amdgpu]
[ +0.000484] pci_device_remove+0xae/0x1e0
[ +0.000008] device_remove+0xc7/0x180
[ +0.000007] device_release_driver_internal+0x3d4/0x5a0
[ +0.000006] device_release_driver+0x12/0x20
[ +0.000007] pci_stop_bus_device+0x104/0x150
[ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40
[ +0.000006] remove_store+0xd7/0xf0
[ +0.000006] dev_attr_store+0x3f/0x80
[ +0.000005] sysfs_kf_write+0x125/0x1d0
[ +0.000006] kernfs_fop_write_iter+0x2ea/0x490
[ +0.000006] vfs_write+0x90d/0xe70
[ +0.000006] ksys_write+0x119/0x220
[ +0.000006] __x64_sys_write+0x72/0xc0
[ +0.000006] x64_sys_call+0x18ab/0x26f0
[ +0.000005] do_syscall_64+0x7c/0x170
[ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ +0.000012] The buggy address belongs to the object at ffff88812eec8000
which belongs to the cache kmalloc-rnd-07-4k of size 4096
[ +0.000016] The buggy address is located 3160 bytes inside of
freed 4096-byte region [ffff88812eec8000, ffff88812eec9000)
[ +0.000023] The buggy address belongs to the physical page:
[ +0.000009] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12eec8
[ +0.000007] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ +0.000005] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
[ +0.000007] page_type: f5(slab)
[ +0.000008] raw: 0017ffffc0000040 ffff888100054500 dead000000000122 0000000000000000
[ +0.000005] raw: 0000000000000000 0000000080040004 00000000f5000000 0000000000000000
[ +0.000006] head: 0017ffffc0000040 ffff888100054500 dead000000000122 0000000000000000
[ +0.000005] head: 0000000000000000 0000000080040004 00000000f5000000 0000000000000000
[ +0.000006] head: 0017ffffc0000003 ffffea0004bbb201 ffffffffffffffff 0000000000000000
[ +0.000005] head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
[ +0.000005] page dumped because: kasan: bad access detected
[ +0.000010] Memory state around the buggy address:
[ +0.000009] ffff88812eec8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000012] ffff88812eec8b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000011] >ffff88812eec8c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000011] ^
[ +0.000010] ffff88812eec8c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000011] ffff88812eec8d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000011] ==================================================================
The use-after-free occurs because a delayed work item (`suspend_work`) may still
be pending or running when resources it accesses are freed during device removal
or file close. The previous code used `flush_work(&fpriv->evf_mgr.suspend_work.work)`,
which does not wait for delayed work that has not yet started. As a result, the
delayed work could run after its memory was freed, causing a use-after-free.
By switching to `flush_delayed_work(&fpriv->evf_mgr.suspend_work)`, we ensure that
the kernel waits for both queued and delayed work to finish before
freeing memory, closing this race.
Fixes: adba0929736a ("drm/amdgpu: Fix Illegal opcode in command stream Error")
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit 5fb90421fa0fbe0a968274912101fe917bf1c47b.
The original patch moved `amdgpu_userq_mgr_fini()` to the driver's
`postclose` callback, which is called after `drm_gem_release()` in
the DRM file cleanup sequence.If a user application crashes or aborts
without cleaning up its user queues, 'drm_gem_release()` may free
GEM objects that are still referenced by active user queues, leading
to use-after-free. By reverting, we ensure that user queues are
disabled and cleaned up before any GEM objects are released,
preventing this class of bug. However, this reintroduces a race
during PCI hot-unplug, where device removal can race with per-file
cleanup, leading to use-after-free in suspend/unplug paths.
This will be fixed in the next patch.
Fixes: 5fb90421fa0f ("drm/amdgpu: fix slab-use-after-free in amdgpu_userq_mgr_fini+0x70c")
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Common resolutions are added to supported modes to enable compatibility
scenarios that compositors may use to do things like clone displays. There
is no guarantee however that the panel will natively support these modes.
[How]
If the compositor hasn't enabled scaling but a non-native resolution has
been picked for an LVDS panel turn the scaler on anyway. This will ensure
compatibility.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
Common modes are added to LVDS for compatibility in clone mode, but
not all panels support them. Non-native modes were disabled in the past
but this caused problems because compositors didn't use scaling for non
native modes. Now non-native modes on LVDS will enable the scaler by
default.
[How]
Check the connector type. If the connector is LVDS avoid adding common
modes.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add a parameter to amdgpu_sdma_reset_engine() to let the
caller handle the kernel rings. This allows the kernel
rings to back up their unprocessed state if the reset comes in
via the drm scheduler rather than KFD.
Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
