| Age | Commit message (Collapse) | Author |
|
Read temperature limits using pcode mailbox and expose shutdown
temperature limit as tempX_emergency, critical temperature limit as
tempX_crit and GPU max temperature limit as temp2_max.
Update Xe hwmon documentation with above entries.
v2:
- Resolve a documentation warning.
- Address below review comments from Raag.
- Update date and kernel version in Xe hwmon documentation.
- Remove explicit disable of has_mbx_thermal_info for unsupported
platforms.
- Remove unnecessary default case in switches.
- Remove obvious comments.
- Use TEMP_LIMIT_MAX to compute number of dwords needed in
xe_hwmon_thermal_info.
- Remove THERMAL_LIMITS_DWORDS macro.
- Use has_mbx_thermal_info for checking thermal mailbox support.
v3:
- Address below minor comments. (Raag)
- Group new temperature attributes with existing temperature attributes
as per channel index in Xe hwmon documentation.
- Rename enums of xe_temp_limit to improve clarity.
- Use DIV_ROUND_UP to calculate dwords needed for temperature limits.
- Use return instead of breaks in xe_hwmon_temp_read.
- Minor aesthetic refinements.
v4:
- Remove a redundant break. (Raag)
- Update drm_dbg to drm_warn to inform user of unavailability for
thermal mailbox on expected platforms.
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20260112203521.1014388-2-karthik.poosa@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Now that the GSC FW is defined, we can enable PXP for PTL. The feature
will only be turned on if the binary is found on disk.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260108011340.2562349-8-daniele.ceraolospurio@intel.com
|
|
PTL is identified by GSC major version 105. The compatibility version is
still 1.0.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patch.msgid.link/20260108011340.2562349-7-daniele.ceraolospurio@intel.com
|
|
On newer platforms GSC FW is only required for content protection
features, so the core driver features work perfectly fine without it
(and we did in fact not enable it to start with on PTL). Therefore, we
can selectively enable the GSC only if the FW is found on disk, without
failing if it is not found.
Note that this means that the FW can now be enabled (i.e., we're looking
for it) but not available (i.e., we haven't found it), so checks on FW
support should use the latter state to decide whether to go on or not.
As part of the rework, the message for FW not found has been cleaned up
to be more readable.
While at it, drop the comment about xe_uc_fw_init() since the code has
been reworked and the statement no longer applies.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com>
Link: https://patch.msgid.link/20260108011340.2562349-6-daniele.ceraolospurio@intel.com
|
|
Prior to lmem init check, driver is waiting for the pcode uncore_init
status. uncore_init status will be flagged after the complete boot and
initialization of the SoC by the pcode. uncore_init confirms that lmem
init and mmio unblock has been already completed.
It makes no sense to check for lmem init after the pcode uncore_init
check. So change the wait for lmem init check into an assert which
confirms lmem init is set.
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20251219145024.2955946-2-balasubramani.vivekanandan@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Nothing requires it any more, make the member private.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260108101014.579906-16-dev@lankhorst.se
|
|
Do not directly dereference xe_ggtt_node, and add
a function to retrieve the allocated GGTT size.
Reviewed-by: Matthew.brost@intel.com
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260108101014.579906-15-dev@lankhorst.se
|
|
A careful inspection of __xe_ggtt_insert_bo_at() shows that
the ggtt_node can always be seen as inserted from xe_bo.c
due to the way error handling is performed.
The checks are also a little bit too paranoid, since we
never create a bo with ggtt_node[id] initialised but not
inserted into the GGTT, which can be seen by looking at
__xe_ggtt_insert_bo_at()
Additionally, the size of the GGTT is never bigger than 4 GB,
so adding a check at that level is incorrect.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260108101014.579906-14-dev@lankhorst.se
|
|
Start using xe_ggtt_node_addr, and avoid comparing the base offset
as vma->node is dynamically allocated.
Also sneak in a xe_bo_size() for stolen, too small to put as separate
commit.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260108101014.579906-13-dev@lankhorst.se
|
|
This function makes it possible to add an offset that is applied to
all xe_ggtt_node's, and hides the internals from all its users.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260108101014.579906-12-dev@lankhorst.se
|
|
The rotation details belong in xe_fb_pin.c, while the operations involving
GGTT belong to xe_ggtt.c. As directly locking xe_ggtt etc results in
exposing all of xe_ggtt details anyway, create a special function that
allocates a ggtt_node, and allow display to populate it using a callback
as a compromise.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260108101014.579906-11-dev@lankhorst.se
|
|
Instead of having ggtt->size point to the end of ggtt, have ggtt->size
be the actual size of the GGTT, and introduce ggtt->start to point to
the beginning of GGTT.
This will allow a massive cleanup of GGTT in case of SRIOV-VF.
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260108101014.579906-10-dev@lankhorst.se
|
|
Although the dev_xx!() macro calls do not technically require terminating
newlines for the format strings, they should be added anyway to maintain
consistency, both within Rust code and with the C versions.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260107201647.2490140-2-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The NV_PFALCON_FALCON_DMATRFBASE/1 register pair supports DMA addresses
up to 49 bits only, but the write to DMATRFBASE1 could exceed that.
To mitigate, check first that the DMA address will fit.
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base code")
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260107201647.2490140-1-ttabi@nvidia.com
[ Import ::kernel::dma::DmaMask. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Most of the MERT code is already in dedicated file, no reason to
keep internal MERT data structure initialization elsewhere.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260109151219.26206-6-michal.wajdeczko@intel.com
|
|
There is no need to always refer to MERT data using tile pointer.
Use of local mert pointer will simplify the code and make it look
like other existing MERT function.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260109151219.26206-5-michal.wajdeczko@intel.com
|
|
There is only one MERT instance and while it is located on the root
tile, it is safer to refer to it using xe_device rather than xe_tile.
This will also allow to align signature with other MERT function.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260111213847.27869-1-michal.wajdeczko@intel.com
|
|
Add simple top level kernel-doc for the struct itself to allow the
script recognize that and fix tag of the one member.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260109151219.26206-3-michal.wajdeczko@intel.com
|
|
Most of our header files are using include guard names with single
underscore and we don't use trailing comments on final #endif.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://patch.msgid.link/20260109151219.26206-2-michal.wajdeczko@intel.com
|
|
Remove the (large) raw form of the PMU table entries. The resulting
PMULookupTable is still getting printed (in more useful form) later,
anyway, so this was redundant, even for debugging. This output (the
example is from an Ampere GPU) is what is being removed:
NovaCore 0000:e1:00.0: PMU entry: [01, 01, 54, 54, 01, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [07, 06, e0, b7, 03, 00]
NovaCore 0000:e1:00.0: PMU entry: [08, 01, bc, 56, 05, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [45, 07, 88, da, 01, 00]
NovaCore 0000:e1:00.0: PMU entry: [85, 07, 34, c9, 02, 00]
NovaCore 0000:e1:00.0: PMU entry: [49, 05, 7c, b3, 04, 00]
NovaCore 0000:e1:00.0: PMU entry: [89, 05, 1c, 05, 05, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
NovaCore 0000:e1:00.0: PMU entry: [00, 00, 00, 00, 00, 00]
And it is immediately followed by a more useful, interpreted list of
selected PMU table data, which is *not* being removed as part of this
commit. That looks like this:
NovaCore 0000:e1:00.0: PmuLookupTableEntry desc: FalconUCodeDescV3 {
hdr: 78381825,
stored_size: 59904,
pkc_data_offset: 1444,
interface_offset: 28,
imem_phys_base: 0,
imem_load_size: 57856,
imem_virt_base: 0,
dmem_phys_base: 0,
dmem_load_size: 2048,
engine_id_mask: 1024,
ucode_id: 9,
signature_count: 3,
signature_versions: 7,
_reserved: 37449,
}
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://patch.msgid.link/20260108005811.86014-3-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Change gpu_name() to return a Result instead of an Option. This avoids
silently discarding error information when parsing the GPU name string
from the GSP.
Update the callsite to log a warning with the error details on failure,
rather than just displaying "invalid GPU name".
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260108005811.86014-2-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The guc_hw_reg_state array is not exported, so make it static.
Fixes the following sparse warning:
drivers/gpu/drm/i915/i915_gpu_error.c:692:3: warning: symbol 'guc_hw_reg_state' was not declared. Should it be static?
Fixes: ba391a102ec11 ("drm/i915/guc: Include the GuC registers in the error state")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260108201202.59250-2-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 701c47493328a8173996e7590733be3493af572f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This is supposed to test for integer overflow but it is wrong and
unnecessary. The size_add()/mul() macros return SIZE_MAX when there is
an integer overflow. This code saves the SIZE_MAX to a u64 and then
tests if the result is greater than SIZE_MAX which it never will be.
Fortunately, when we try to allocate SIZE_MAX bytes the allocation
will fail. We even pass __GFP_NOWARN so the allocation fails
harmlessly and quietly.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/697596/
Link: https://lore.kernel.org/r/aWAMIhZLxUcecbLd@stanley.mountain
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Since commit 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as
sleeping"), the Rockchip GPIO chip operations potentially sleep, hence
the kernel complains when trying to make use of the non-sleeping API:
[ 16.653343] WARNING: drivers/gpio/gpiolib.c:3902 at gpiod_set_value+0xd0/0x108, CPU#5: kworker/5:1/93
...
[ 16.678470] Hardware name: Radxa ROCK 5B (DT)
[ 16.682374] Workqueue: events dw_hdmi_qp_rk3588_hpd_work [rockchipdrm]
...
[ 16.729314] Call trace:
[ 16.731846] gpiod_set_value+0xd0/0x108 (P)
[ 16.734548] dw_hdmi_qp_rockchip_encoder_enable+0xbc/0x3a8 [rockchipdrm]
[ 16.737487] drm_atomic_helper_commit_encoder_bridge_enable+0x314/0x380 [drm_kms_helper]
[ 16.740555] drm_atomic_helper_commit_tail_rpm+0xa4/0x100 [drm_kms_helper]
[ 16.743501] commit_tail+0x1e0/0x2c0 [drm_kms_helper]
[ 16.746290] drm_atomic_helper_commit+0x274/0x2b8 [drm_kms_helper]
[ 16.749178] drm_atomic_commit+0x1f0/0x248 [drm]
[ 16.752000] drm_client_modeset_commit_atomic+0x490/0x5d0 [drm]
[ 16.754954] drm_client_modeset_commit_locked+0xf4/0x400 [drm]
[ 16.757911] drm_client_modeset_commit+0x50/0x80 [drm]
[ 16.760791] __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0x170 [drm_kms_helper]
[ 16.763843] drm_fb_helper_hotplug_event+0x340/0x368 [drm_kms_helper]
[ 16.766780] drm_fbdev_client_hotplug+0x64/0x1d0 [drm_client_lib]
[ 16.769634] drm_client_hotplug+0x178/0x240 [drm]
[ 16.772455] drm_client_dev_hotplug+0x170/0x1c0 [drm]
[ 16.775303] drm_connector_helper_hpd_irq_event+0xa4/0x178 [drm_kms_helper]
[ 16.778248] dw_hdmi_qp_rk3588_hpd_work+0x44/0xb8 [rockchipdrm]
[ 16.781080] process_one_work+0xc3c/0x1658
[ 16.783719] worker_thread+0xa24/0xc40
[ 16.786333] kthread+0x3b4/0x3d8
[ 16.788889] ret_from_fork+0x10/0x20
Since gpiod_get_value() is called from a context that can sleep, switch
to its *_cansleep() variant and get rid of the issue.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260110-dw-hdmi-qp-cansleep-v1-1-1ce937c5b201@collabora.com
|
|
We now have proper infrastructure to accurately check the LRC timestamp
without toggling the scheduling state for non-VFs. For VFs, it is still
possible to get an inaccurate view if the context is on hardware. We
guard against free-running contexts on VFs by banning jobs whose
timestamps are not moving. In addition, VFs have a timeslice quantum
that naturally triggers context switches when more than one VF is
running, thus updating the LRC timestamp.
For multi-queue, it is desirable to avoid scheduling toggling in the TDR
because this scheduling state is shared among many queues. Furthermore,
this change simplifies the GuC state machine. The trade-off for VF cases
seems worthwhile.
v5:
- Add xe_lrc_timestamp helper (Umesh)
v6:
- Reduce number of tries on stuck timestamp (VF testing)
- Convert job timestamp save to a memory copy (VF testing)
v7:
- Save ctx timestamp to LRC when start VF job (VF testing)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patch.msgid.link/20260110012739.2888434-8-matthew.brost@intel.com
|
|
The timestamp WA does not work on a VF because it requires reading MMIO
registers, which are inaccessible on a VF. This timestamp WA confuses
LRC sampling on a VF during TDR, as the LRC timestamp would always read
as 1 for any active context. Disable the timestamp WA on VFs to avoid
this confusion.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization")
Link: https://patch.msgid.link/20260110012739.2888434-7-matthew.brost@intel.com
|
|
Now that LR jobs are tracked by the DRM scheduler, there's no longer a
need to special-case LR queues. This change removes all LR
queue-specific handling, including dedicated TDR logic, reference
counting schemes, and other related mechanisms.
v4:
- Remove xe_exec_queue_lr_cleanup tracepoint (Niranjana)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260110012739.2888434-6-matthew.brost@intel.com
|
|
Deregistering queues in the TDR introduces unnecessary complexity,
requiring reference-counting techniques to function correctly,
particularly to prevent use-after-free (UAF) issues while a
deregistration initiated from the TDR is in progress.
All that's needed in the TDR is to kick the queue off the hardware,
which is achieved by disabling scheduling. Queue deregistration should
be handled in a single, well-defined point in the cleanup path, tied to
the queue's reference count.
v4:
- Explain why extra ref were needed prior to this patch (Niranjana)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260110012739.2888434-5-matthew.brost@intel.com
|
|
If the firmware is not running during TDR (e.g., when the driver is
unloading), there's no need to toggle scheduling in the GuC. In such
cases, skip this step.
v4:
- Bail on wait UC not running (Niranjana)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260110012739.2888434-4-matthew.brost@intel.com
|
|
Use new pending job list iterator and new helper functions in Xe to
avoid reaching into DRM scheduler internals.
Part of this change involves removing pending jobs debug information
from debugfs and devcoredump. As agreed, the pending job list should
only be accessed when the scheduler is stopped. However, it's not
straightforward to determine whether the scheduler is stopped from the
shared debugfs/devcoredump code path. Additionally, the pending job list
provides little useful information, as pending jobs can be inferred from
seqnos and ring head/tail positions. Therefore, this debug information
is being removed.
v4:
- Add comment around DRM_GPU_SCHED_STAT_NO_HANG (Niranjana)
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260110012739.2888434-3-matthew.brost@intel.com
|
|
Stop abusing DRM scheduler job list lock for messages, add dedicated
message lock.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Acked-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260110012739.2888434-2-matthew.brost@intel.com
|
|
This version brings along the following updates:
- Cleanup, refactoring of panel replay code to prepare for non-eDP
replay
- Switch to drm_dbg_macros instead of DRM_DEBUG variants
- Add pwait status to DMCUB debug logging
- Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35
- Always update divider settings for DP tunnel
- correct clip x assignment in cursor programming
- Bump the HDMI clock to 340MHz
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Summary for changes in firmware:
* Fix 24/30FPS full screen video low residency
* Fix 60Hz video playback freeze
* Add Panel Replay command for VESA replay
Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Device pointer sources used:
- connector->dev - when a DRM connector was available
- old_plane_crtc->dev / new_plane_crtc->dev - for plane state functions
- pass in drm_device - for the stream scaling function
- aconnector->base.dev - for the VSDB parsing function
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DRM_DEBUG_ class of macros are depricated. Recommended drm_dbg_kms() has
the advantage of being able to distinguish the logs from devices in a
multi-gpu environment.
Where a pointer to struct amdgpu_device is available, use that to get
the drm device.
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
To know if DMCUB is idle at the time of the debug data being collected.
[How]
Extend the logging to include the field.
It's already captured as part of each ASIC's get_diagnostic_data.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
A backport of the change made for DCN401 that addresses an issue where
we turn off the PHY PLL when disabling TMDS output, which causes the
OTG to remain stuck.
The OTG being stuck can lead to a hang in the DCHVM's ability to ACK
invalidations when it thinks the HUBP is still on but it's not receiving
global sync.
The transition to PLL_ON needs to be atomic as there's no guarantee
that the thread isn't pre-empted or is able to complete before the
IOMMU watchdog times out.
[How]
Backport the implementation from dcn401 back to dcn35.
There's a functional difference in when the eDP output is disabled in
dcn401 code so we don't want to utilize it directly.
Reviewed-by: Yihan Zhu <yihan.zhu@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add a new field to replay_settings.
Reviewed-by: Robin Chen <robin.chen@amd.com>
Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Prepare for supporting panel replay on external monitors.
Reviewed-by: Robin Chen <robin.chen@amd.com>
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
IGT CRC tests fail on replay panels due to invalid CRC values
captured when replay is active.
[How]
- Disable replay when CRC source is enabled; set flag to
prevent unexpected re-enable
- Reset flag when CRC source is disabled to allow replay
Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
When transitioning from 640x480 at RBRx1 to HBR3x1,
both output pixel mode and pixel rate divider should update.
The needs_divider_update flag was only for 8b10b and 128b132b transition.
[How]
For DP tunneling, always update divider settings.
Reviewed-by: Jerry Zuo <jerry.zuo@amd.com>
Signed-off-by: Cruise Hung <Cruise.Hung@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit 08f133e932cc.
Commit causing backlight darker when the system wakes up
from standby mode, and green screen w/ secondary screen only
when the system wakes up from standby mode.
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Derek Lai <Derek.Lai@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why&how]
primary planes for external displays getting incorrect clip
values, detect such a scenario and pass correct parameters
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Ausef Yousof <auyousof@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Add the ability to enable/disable global fine grain clock gating within DCCG.
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This avoids any issues with dpia endpoints
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Add error handling for IRQ_HPD in Panel Replay
Reviewed-by: Robin Chen <robin.chen@amd.com>
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Jack Chang <jack.chang@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why&How]
Add flow to read selective update related info from DPCD,
and pass the info to DMUB.
Reviewed-by: Robin Chen <robin.chen@amd.com>
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Jack Chang <jack.chang@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DP-HDMI dongles can execeed bandwidth requirements on high resolution
monitors. This can lead to pruning the high resolution modes.
HDMI 1.3 bumped the clock to 340MHz, but display code never matched it.
[How]
Set default to (DVI) 165MHz. Once HDMI display is identified update
to 340MHz.
Reported-by: Dianne Skoll <dianne@skoll.ca>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4780
Reviewed-by: Chris Park <chris.park@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The PSR message was moved in commit 4321742c394e ("drm/amd/display:
Move PSR support message into amdgpu_dm"). This message however shows
for every single link without showing which link is which. This can
send a confusing message to the user.
[How]
Add link name into the message.
Fixes: 4321742c394e ("drm/amd/display: Move PSR support message into amdgpu_dm")
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHY]
Remove unused DMUB Replay set version command and related code.
Reviewed-by: Jack Chang <jack.chang@amd.com>
Signed-off-by: Robin Chen <robin.chen@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|