| Age | Commit message (Collapse) | Author |
|---|
|
The BMC side of the RPC configuration is driven entirely out of the
capabilities message: it carries the BMC presence, its MAC addresses and
the all-multi request, and the reinit flag raised off it is what gets the
service task to reprogram the MACDA and action TCAMs. Pull that out of
fbnic_fw_parse_cap_resp() into a helper and rework the state it publishes.
The firmware reports the BMC present as soon as its NC-SI channel is
enabled, before the BMC has been assigned a MAC address. Such a message
carries no BMC MAC array and is rejected with -EINVAL, discarding the rest
of it. Treat a present BMC with no MAC as absent instead. There is no entry
to steer traffic to without one, so the BMC paths stay disabled either way,
and the link speed, FEC and anti-rollback version in the same message are
no longer thrown out with it.
bmc_present, need_bmc_tcam_reinit, need_bmc_macda_sync and all_multi are
single bit members of one bitfield, so every write to one is a
read-modify-write of all four. The mailbox writes three of them and the
service task writes the other two. Move them into an unsigned long state
field driven by the atomic bitops. Putting it at the top of the struct
keeps the cost to the word itself: 152 bytes grows to 160, still three
cachelines, with a 1 byte hole left ahead of anti_rollback_version.
Order the reinit handoff while there. The mailbox publishes the BMC state
before raising the flag and the service task tests the flag before
consuming it, so pair an smp_mb__before_atomic() on the raise with a
test_and_clear_bit() on the consume. Claiming the flag atomically also
keeps a raise that lands mid-pass instead of dropping it.
Commit all_multi unconditionally rather than only when the firmware
supplied the attribute. An absent attribute means the BMC is not asking for
all-multi, so holding the previous value just kept stale state. It is read
out of the message only when a BMC is present, so it is never set on its
own and the three callers that paired it with the presence check can test
it alone.
fbnic_write_macda() tests the reinit flag to force a MACDA sync and now
always sees it clear when reached from fbnic_bmc_rpc_check(). That path is
unaffected, as fbnic_bmc_rpc_init() unconditionally marks the broadcast
entry, so the update count is never zero while a BMC is present.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Fixes: 20d2e88cc746 ("eth: fbnic: Add initial messaging to notify FW of our presence")
Fixes: 04a230b27d8f ("fbnic: Add logic to repopulate RPC TCAM if BMC enables channel")
Fixes: cee8d21d8091 ("fbnic: Push local unicast MAC addresses to FW to populate TCAMs")
Link: https://patch.msgid.link/179061192791.414394.2161969547553719796.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
NPA and NIX interrupt handlers queue health-reporting work whose
containers are freed by rvu_health_reporters_destroy(). Interrupt
unregistration does not drain queued work. In addition, each reporter
setup creates a workqueue in the same field, leaking the NPA queue and
leaving no teardown handle for work queued on it.
Initialize work before later allocations can fail, share one workqueue,
unregister each set of interrupts, and cancel its work before freeing
the reporters. Destroy the shared workqueue once both reporter sets are
gone.
Cc: stable+noautosel@kernel.org # untested fix for a driver (de)init path race
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://patch.msgid.link/20260928134129.145-1-getshell@seu.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The interrupt handler schedules tx_clean_tasklet, which dereferences the
private state and TX ring. free_irq() prevents new scheduling but does
not wait for a tasklet that was already queued.
Kill the tasklet after freeing the interrupt and before purging and
freeing the DMA rings.
Cc: stable+noautosel@kernel.org # untested fix for a driver init path race
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://patch.msgid.link/20260928134125.2003-1-getshell@seu.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Add missing @txqueue parameter description to atlx_tx_timeout
to eliminate kernel-doc warning.
Signed-off-by: Ayush Yaduvanshi <ayush37735@gmail.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260929101714.51579-1-ayush37735@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Remove excess @valid struct member description from
efx_ptp_timeset.
Signed-off-by: Ayush Yaduvanshi <ayush37735@gmail.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260929094211.48125-1-ayush37735@gmail.com
Link: https://patch.msgid.link/20260929100625.50380-1-ayush37735@gmail.com
[Jakub: squash with the siena patch]
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Short-read handling was added to asix_read_cmd() by commit
920a9fa27e78 ("net: asix: add proper error handling of usb read errors").
The helper converts short reads to -ENODATA while preserving negative
errors from the underlying USB read operation.
Remove the redundant short-read check in asix_read_phy_addr()
and its unreachable -EIO assignment. The existing negative-return check
handles both short reads and underlying USB read errors.
Signed-off-by: Xinsheng Zhu <xinsheng.zhu.ny@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260928192119.73351-1-xinsheng.zhu.ny@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
A DPNI whose endpoint is not a DPMAC has no physical connector: it
may have no endpoint at all, or be connected to another DPNI or to a
DPSW port. Until now, such a DPNI was still registered as a physical
devlink port with number 0, so userspace saw a physical port that does
not exist.
Register these DPNIs as virtual devlink ports instead. A virtual port
has no phys_port_name, so only the DPNIs that serve a DPMAC at probe
time report one, "p<dpmac id>", and those names do not collide.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260928-for-upstream-dpaa2_ports-v2-2-1cda148530bf@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
dpaa2-eth registers every DPNI as a devlink port of flavour physical
without setting a port number. All DPAA2 interfaces report the same
phys_port_name, p0 (see devlink port show).
The DPNI endpoint can change at runtime while the attributes of a
registered devlink port cannot, so log a warning when it happens.
Another benefit: udev rules can match ATTR{phys_port_name} to name an
interface based on its DPMAC.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260928-for-upstream-dpaa2_ports-v2-1-1cda148530bf@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
mtk_drm_probe() creates an OVL adaptor platform device with
platform_device_register_data() when the display pipeline requires the
OVL adaptor.
If a later initialization step fails, the probe error path releases
the DRM resources without unregistering the already registered OVL
adaptor device. The normal remove path likewise leaves the device
registered after the DRM driver is unbound.
Keep track of whether the OVL adaptor was successfully registered and
unregister it on probe failure. Also recover the platform device from
the stored DDP component device and unregister it during normal
removal.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260921131156.403652-1-lgs201920130244@gmail.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
Currently all syncobj_in fences are waited synchronously on the CPU.
However, since Host1x channels are capable of waiting for syncpoint
fences on the hardware, let's use that capability.
This filters the any non-syncpoint (or different host1x instance) fences
in syncobj_in, waits only those on the CPU, and adds the rest as waits
to the channel before the actual job contents.
Also make minor clarifications to the doc comments in the UAPI header.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-6-afa730410392@nvidia.com
|
|
Syncpoint fences are backed by a hardware syncpoint / threshold, which
various hardware is capable of waiting for directly without CPU
intervention. Add a function to allow drivers for such devices to
extract the details to allow programming the hardware accordingly.
The function also provides the host1x instance corresponding to the
syncpoint since a system may contain multiple instances of host1x with
separate sets of syncpoints.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-5-afa730410392@nvidia.com
|
|
The dma-fence-array.h and sync_file.h headers are not used. Drop the
includes.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-4-afa730410392@nvidia.com
|
|
drm_syncobj_replace_fence() calls dma_fence_get() on the parameter
fence, so we need to drop ours. Add a call to dma_fence_put() to do
that.
Fixes: 13abe0bb15ce ("drm/tegra: Implement job submission part of new UAPI")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-3-afa730410392@nvidia.com
|
|
When host1x_fence_create() fails, avoid trying to attach the error
pointer to the out syncobj.
Fixes: 13abe0bb15ce ("drm/tegra: Implement job submission part of new UAPI")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-2-afa730410392@nvidia.com
|
|
dma_fence_wait_timeout() returns the remaining timeout in jiffies on
success, zero on timeout, and a negative error code if interrupted. The
return value was assigned to 'err' and checked as if it were an errno,
the opposite of the correct logic.
Fix the code to use a properly typed variable and check each condition
correctly.
Fixes: 13abe0bb15ce ("drm/tegra: Implement job submission part of new UAPI")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/all/aJM_te551jUwnRv7@stanley.mountain/
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260730-b4-host1x-syncobj-wait-v1-1-afa730410392@nvidia.com
|
|
Add kernel module parameter to allow disabling context stealing in cases
where reliability and consistency is preferred.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260710-b4-host1x-ctxsteal-v1-2-b1f8f6b37cc5@nvidia.com
|
|
out_free_buffer_pools reuses open()'s loop index for the TX LTB
walk. After the pool unwind i is -1, so the TX buffers allocated
earlier are leaked. request_irq() failure has the same leak.
The TX-fail goto on that walk also skips dma_unmap of the filter
list (pre-existing since the LTB was added). Rewrite the TX walk
to real_num_tx_queues with a pointer check, and unmap the filter
list before those frees.
Fixes: d926793c1de9 ("ibmveth: Implement multi queue on xmit")
Cc: stable@vger.kernel.org
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Link: https://patch.msgid.link/d14314c2b10f125f5e578782484ba3cc50564d53.1790357373.git.mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ibmveth_open() registers the logical LAN, then allocates the RX
buffer pools. A pool failure jumps to out_free_buffer_pools without
h_free_logical_lan(), so PHYP still owns the buffer-list page when
it is unmapped. request_irq() failure already issued the hypercall
before taking the same label.
Move that h_free to the shared post-register unwind so both paths
deregister before the buffer list is unmapped.
Fixes: d43732ce021f ("ibmveth: properly unwind on init errors")
Cc: stable@vger.kernel.org
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
Reviewed-by: Dave Marquardt <davemarq@linux.ibm.com>
Link: https://patch.msgid.link/7a56fbfb9e0674f011f4e310fbd7dfd8e67c30aa.1790357373.git.mmc@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
pm_runtime_get_sync() unconditionally bumps the usage counter, but
nothing puts it back when devm_i2c_add_adapter() fails, leaving the DDC
runtime-resumed after a failed probe. Drop the reference on that error
path.
Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174229.2088824-1-vulab@iscas.ac.cn/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
Currently, each process holding an open TegraDRM channel reserves for
itself one of the limited number of hardware memory contexts. Attempting
to allocate a channel when all contexts are in use results in failure.
While we cannot have more contexts than the hardware supports in active
use, idle channels don't necessarily need to have a backing memory
context. As such, in this patch, we add another layer to allow hardware
memory contexts to be "stolen away" by channels that are in active use,
from idle processes.
The way this is implemented, is by keeping track of memory mappings on
each abstracted memory context. If we need to steal that memory
context's backing hardware context, we unmap everything from it and give
it away. When that abstracted memory context is needed again
(re-activated), we attempt to allocate or steal another hardware context
and re-map the previously unmapped buffers.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260710-b4-host1x-ctxsteal-v1-1-b1f8f6b37cc5@nvidia.com
|
|
Allow specifying usable channel, and allocatable syncpoint ranges
through the device tree. This is necessary when Host1x resources
are shared between multiple operating systems or independent hardware
units and Linux has limited access to them.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260702-host1x-nohv-v2-4-e6d88bac0af6@nvidia.com
|
|
Host1x can be used without access to the hypervisor or common regions
when they are configured by other components in the system. Add support
for running without access to them.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260702-host1x-nohv-v2-3-e6d88bac0af6@nvidia.com
|
|
When the device is not the mmsys master, mtk_drm_bind() returns early
after taking a reference on the disp-mutex device via
of_find_device_by_node(), without ever dropping it: mtk_drm_unbind()
only puts mutex_dev for the master. Drop the reference before returning
from the non-master path.
Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260916174058.2088709-1-vulab@iscas.ac.cn/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
`SGEntry::dma_len()` returns `ResourceSize`, but the length of a DMA
segment is not the size of a resource. The C side stores it as an
`unsigned int` (`dma_length` in `struct scatterlist`), the helper
returns `unsigned int`, and a single segment is bounded by the
device's `max_segment_size`, which is an `unsigned int` as well. The
method only widens the value to `resource_size_t`.
Return `u32`, which is what the binding already produces, and drop the
`.into()` along with its `clippy::useless_conversion` allow.
Tyr widens the length to `u64`, which is now a real conversion on
every architecture, so drop its `useless_conversion` allow too.
nova-core converts it to `usize` through `FromSafeCast`, which already
covers `u32`, so it needs no change.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/DLNPXJ4WPH4L.2MBUGV1TAESYY@kernel.org
Signed-off-by: Lorenzo Delgado <lnsdev@proton.me>
Link: https://patch.msgid.link/20260927-resource-size-newtype-v4-1-447a08af23fb@proton.me
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
UAPI Changes:
- New sysfs to expose device UID (Badal)
Driver Changes:
- Nuke PTs only after unlinking contested VMAs (Auld)
- Limit sg segment size to PAGE_SIZE on Xen PV (Szymon)
- Move locking to xe_sriov_pf_reprovision_default (Michal)
- New workarounds (Tilak, Tales, Daniel)
- Keep VF LMEM BAR size low if no VFs enabled (Marcin)
- Drop ratelimiting from dev_unhold_work debug trace (Varun)
- System Controller's Maibox response improvement (Anoop)
- General clean-ups (Roper, Lin)
- Revert "drm/xe: Set mask bits for CCS_MODE register" (Roper)
- CPU binds and ULLS on migration queue (Brost)
- Re-apply an i2c patch silently removed by a merge (Bartosz)
- New PTL PCI ID (Atwood)
- Enable PXP for NVL-S (Alan)
- Let xe_guc_ct_send_locked() callers reserve G2H credit (Sujaritha)
- Implement print vfunc for page fault info logging (Brian)
- Do not dma_fence_put zero fences in err_out path (Jonathan)
- Add focused VM teardown and page fault tracing (Daniel)
- Fix ULLS chained job loss and GT reset replay (Varun)
- Refresh TTM LRU on SVM prefetch (Himal)
- Fix xe_mmio_wait32() to honor delay/sleep maximums (Alan)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/ar5YsqAK3bS4Ta6Z@intel.com
|
|
* icc-misc
interconnect: qcom: Constify struct qcom_icc_qosbox
interconnect: fix typo "commited" in comments
interconnect: Add kernel-doc for devm_of_icc_get(), icc_enable() and icc_disable()
interconnect: exynos: Remove the PM QoS request on unbind
interconnect: qcom: implement get_bw with rpmh_read
interconnect: qcom: Skip get_bw on QoS programming providers
interconnect: qcom: fix endian annotations of BCM aux data
interconnect: mediatek: fix Makefile typo for mt8196
Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
|
Correct a copy-paste typo in the MediaTek interconnect Makefile that
mapped mt8196.o to CONFIG_INTERCONNECT_MTK_MT8195 instead of MT8196.
Assisted-by: OpenCode AI
Signed-off-by: Breno Rodrigues Alves <breno3011alves@gmail.com>
Link: https://patch.msgid.link/20260905140113.21638-1-breno3011alves@gmail.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
|
struct qcom_icc_bcm::aux_data keeps a copy of the struct bcm_db read
from the command db, whose unit and width fields are annotated as
__le32/__le16 to describe the little-endian on-disk format. Using
those restricted types directly in bandwidth calculations makes sparse
complain about endianness.
Keep aux_data typed as struct bcm_db, copied verbatim from the command
db buffer, and convert the fields with le32_to_cpu()/le16_to_cpu() at
the places where unit and width are used. No functional change.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609221350.3Y8MOce9-lkp@intel.com/
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260923185059.25196-1-rosenp@gmail.com
Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
|
On a MacBookPro14,3 with a Radeon Pro 555 (Polaris11), the framebuffer
is at MC address 0 when amdgpu loads after a cold boot, as the firmware
leaves it (MC_VM_FB_LOCATION = 0x007f0000), while the VBIOS ASIC_Init
table places it at 0xF4_0000_0000 (0xf47ff400). amdgpu reads the
location once, at init, so after a re-POST (S3 resume or GPU reset)
the framebuffer has moved and the driver keeps programming the old
one: the SMU is handed a table that was never written and the GPU
does not come back, which leaves the internal panel black.
Resetting the ASIC on load makes ASIC_Init run before the driver reads
the location, so the driver uses the VBIOS placement from the start and
every later re-POST puts the framebuffer back where it already is.
Add the Radeon Pro 555 used in this machine to the existing VI reset
quirk table.
Tested on a MacBookPro14,3 on 6.18.49 with the quirk table backported
(the kernel also carries unrelated local PCI and ACPI patches for this
machine). The framebuffer is at 0x000000F400000000 after both cold and
warm boot, and the GPU survived 9 S3 cycles (lid close and rtcwake, one
of them with the lid closed for about 7.5 minutes and a USB-C disk
attached), each followed by a few minutes of 3D load; no ring timeouts
or VM faults were reported. The reset adds about 0.23 s to amdgpu init.
Suggested-by: Christian König <christian.koenig@amd.com>
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/all/20260924132952.25054-1-fbeltranmillalen@gmail.com/
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Francisco Beltrán Millalén <fbeltranmillalen@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b6b1d97218518003107d4446fac278fa3e0a19a0)
Cc: stable@vger.kernel.org
|
|
Assume that the AC limits are the maximum of all power states,
and the DC limits are the maximum of battery power states.
This shouldn't make any difference in practice, but is
cleaner and more robust against bogus information in the VBIOS.
Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states")
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260923120354.1027996-2-timur.kristof@gmail.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ef8cb9dcc7db7b7abcbdbe870a080cc81e4f0bf3)
Cc: stable@vger.kernel.org
|
|
[Why]
mod_power_remove_stream() shifts the remaining power_entity slots down
but does not move replay_events, and mod_power_add_stream() does not
initialize it. replay_events therefore stay bound to the map slot
instead of the stream.
When several streams are disabled in one atomic commit,
amdgpu_dm_mod_power_update_streams() removes them one after another.
The eDP stream can then be looked up in a slot whose stale
replay_events already have replay_event_hw_programming set, so
amdgpu_dm_replay_set_event() returns early ("already in desired state")
without calling mod_power_set_replay_event(). Replay is not disabled
before the eDP panel is powered off. After DPMS on, the sink reports
neither replay state nor frame lock (DPCD 0x378 = 0x00, no error bits),
so the HPD IRQ recovery does not trigger and the panel stays black
until a full modeset.
Seen with an eDP panel using FreeSync Replay plus two DP-MST displays:
DPMS off/on of all outputs leaves eDP black, while DPMS of eDP alone
works. Doing an eDP-only DPMS first makes the next all-output DPMS
fail reliably.
[How]
Shift replay_events together with the PSR cached fields in
mod_power_remove_stream() and initialize it to replay_event_vsync in
mod_power_add_stream(), matching the psr_event_vsync initial value used
for PSR (both vsync events are driven together by
amdgpu_dm_crtc_set_static_screen_optimze()).
Tested on 7.3.0-rc3 (238650ef6c7c): the reproducer above now recovers
reliably, and Replay still engages when the screen is idle.
The issue was debugged with help from an AI assistant (Claude), which
analysed ftrace/kprobe traces and the driver source, pointed to the
missing replay_events handling and suggested this change. I collected
the traces and built and tested the fix on the affected hardware.
Fixes: 4cef2ac4c795 ("drm/amd/display: Introduce power module on Linux")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Reviewed-by: Ray Wu <ray.wu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3d47e38e271195435e125527b224d11cfdb777b1)
Cc: stable@vger.kernel.org
|
|
igp_read_bios_from_vram() checked bios[0]/bios[1] with a plain
__iomem load, which faults on sparc64 before the copy runs at all.
radeon_read_bios() already reads its two signature bytes with
readb() ahead of its own copy; use the same accessor here, keeping
the check before the allocation.
Fixes: b442962a9e82 ("drm/radeon/kms: add support for "Surround View"")
Signed-off-by: Imre Kaloz <kaloz@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 09155b8932e5013dbce0f5cdff7d75264a279ee5)
Cc: stable@vger.kernel.org
|
|
dm_dp_mst_is_port_support_mode() reads
aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check,
and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads
aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL
check. dc_sink is cleared asynchronously on MST unplug, and both
functions run from paths that the driver's own comments document as
racing that teardown: the connector probe worker's ->mode_valid
callback and a compositor's atomic check, neither of which holds the
MST manager lock that the teardown path uses. The former does have an
existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in
every path that clears dc_sink, so it doesn't cover this.
Fail the port-support check and skip the FRL conversion path when the
sink is already gone.
Fixes: f04d275d94e1 ("drm/amd/display: add mst port output bw check")
Fixes: 5c9b8b27a883 ("drm/amd/display: Tie FRL support into amdgpu_dm")
Assisted-by: gkh_clanker_t1000
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
Reviewed-by: Fangzhi Zuo <jerry.zuo@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7)
Cc: stable@vger.kernel.org
|
|
amdgpu_dm_create_validate_stream_for_sink() walks encoding_order[] and
uses the first encoding that validates. YCbCr 4:4:4 is listed before
RGB, so an HDMI sink that advertises 4:4:4 gets YCbCr 4:4:4 whenever the
"color format" property is left at AUTO, even though RGB fits the same
link.
That contradicts the documented AUTO behaviour for HDMI in enum
drm_connector_color_format (RGB, falling back to YCbCr 4:2:0 only when
the bandwidth is not available or the mode is 4:2:0-only), which the
amdgpu implementation of the property also describes. It also leaves
the "Broadcast RGB" property without effect on such sinks, since the
quantization range it selects only applies to RGB output.
Try RGB first. The mask still holds every encoding the sink supports,
so a mode that cannot carry RGB falls back exactly as before.
For reference, v7.2 picked RGB here unless YCbCr 4:4:4 was forced
through debugfs, while earlier kernels picked YCbCr 4:4:4 for any HDMI
sink that advertised it.
Fixes: 0b0ff65d3ca1 ("drm/amd/display: Refactor stream validation")
Suggested-by: Adolfo Rodrigues <adolfotregosa@gmail.com>
Assisted-by: Claude Code:claude-fable-5-1
Signed-off-by: Adrian Betschart <adrian.betschart@cinemaone.ch>
Reviewed-by: Fangzhi Zuo <jerry.zuo@amd.com>
Tested-by: Adolfo Rodrigues <adolfotregosa@gmail.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7de432bc753133764dc40d37f9388da56de251e7)
|
|
Building x86_64 allmodconfig with clang fails:
.../dml2_0/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:10491:13:
error: stack frame size (3128) exceeds limit (3072) in
'dml_core_mode_programming' [-Werror,-Wframe-larger-than]
That config enables both KASAN and UBSAN, and should get the 4096
byte limit meant for clang COMPILE_TEST sanitizer builds. The check
in the dml and dml2_0 Makefiles concatenates the three symbols with
no separator:
ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)$(CONFIG_UBSAN)),y)
KASAN and KCSAN cannot be enabled together, so before UBSAN was
added the string was at most "y". UBSAN can be enabled alongside
either of them, and with both set the string becomes "yy",
$(filter y,yy) is empty, and the build falls through to the
non-sanitizer limit of 3072. Adding UBSAN to the check therefore
lowered the limit for the most heavily instrumented builds instead
of raising it.
Separate the symbols with spaces so that $(filter) sees individual
words, and test for a non-empty result. Only the configs with two
sanitizers enabled change behaviour.
Found by KernelCI builds of the linus-next tree.
Fixes: ebf8b0fd8508 ("drm/amd/display: Relax DML frame limit with UBSAN")
Assisted-by: LLM
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0400d53fd03e7d4beb09fdabda42a7b2c4ca465d)
Cc: stable@vger.kernel.org
|
|
In gmc_v12_1_flush_gpu_tlb(), flush_type was not properly
passed to gmc_v12_1_flush_vm_hub(). This only affected
the MMIO path. In most cases the flush would go through
MES.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1f0f66fab18dfa8f14db82b8a6b82dcc21926248)
Cc: stable@vger.kernel.org
|
|
Not enabled in 7.1 so drop the assignment.
Cc: Horatio Zhang <hongkun.zhang@amd.com>
Cc: Hawking.Zhang@amd.com
Fixes: 4ed5116aacf6 ("drm/amdgpu: Add sdma v7_1_0 support")
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 106e19f69a066fb6354dac04e5f5ed43a06727f7)
Cc: stable@vger.kernel.org
|
|
The firmware requested in gfx_v6_0_init_microcode() is not released
when the GFX block is torn down, leaking the firmware resources.
Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini()
to release the PFP, ME, CE and RLC firmware.
Signed-off-by: Willian Oliveira <williandossantosdeoliveira287@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924)
Cc: stable@vger.kernel.org
|
|
acp_hw_init() registers ACP child devices with mfd_add_devices() before
attaching them to the ACP power domain and initializing the hardware.
If attaching a child to the power domain fails, or if the ACP reset or
clock enable operation times out, the failure path frees only the
source cell, resource, and platform-data allocations. The child
platform devices already registered by mfd_add_devices() remain
registered and are never released.
Remove the children from the power domain and unregister the MFD
devices on failures that occur after mfd_add_devices() succeeds. Keep
mfd_add_devices() failures on the existing cleanup path since the MFD
core already rolls back partially registered children itself.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560)
Cc: stable@vger.kernel.org
|
|
amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with
kzalloc_flex() and initializes its embedded kobject before calling
kobject_add().
If kobject_add() fails, the return value is ignored and execution
continues without dropping the initial kobject reference. The failed
kobject is not retained in the kset list, so the normal sysfs teardown
path cannot find it. As a result, ip_hw_instance_release() is never
called and the ip_hw_instance allocation is leaked.
Call kobject_put() when kobject_add() fails so the initial reference is
dropped and ip_hw_instance_release() can free the allocation. Keep the
existing best-effort sysfs behavior by continuing with the remaining IP
entries after the failed registration.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in sysfs")
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1)
Cc: stable@vger.kernel.org
|
|
amdgpu_pmops_suspend_noirq() resets the ASIC unconditionally. When the GPU
has been parked by vga_switcheroo it has neither power nor a PCIe link, so
the reset cannot reach it: pci_set_power_state() reports the device as
inaccessible and amdgpu_asic_reset() returns -EINVAL. A failure there
aborts the entire noirq suspend phase, and with it the system suspend, so
the machine cannot sleep at all while the GPU is switched off.
amdgpu_device_prepare(), amdgpu_device_suspend() and amdgpu_device_resume()
all bail out early on DRM_SWITCH_POWER_OFF. This callback was added later,
for an unrelated reason, and did not inherit the check. nouveau guards
every one of its PM callbacks the same way.
Bail out the same way here. On a single-GPU system switch_power_state is
never DRM_SWITCH_POWER_OFF, so this is a no-op there.
Found on a MacBookPro11,5, where the Radeon is powered down through
apple-gmux so that the internal panel can be driven by the iGPU instead.
Every suspend failed in amdgpu_pmops_suspend_noirq() while the card was
off; with this check a full S3 cycle completes.
Fixes: 9e051720f9d3 ("drm/amdgpu: Ensure HDA function is suspended before ASIC reset")
Signed-off-by: Theo Andersen Carton <andersen.theo@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 539d0558638a6dcc066f1cf592b6b9a52adc8ea4)
Cc: stable@vger.kernel.org
|
|
In gmc_v12_0_flush_gpu_tlb(), flush_type was not properly
passed to gmc_v12_0_flush_vm_hub(). This only affected
the MMIO path. In most cases the flush would go through
MES.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6498e33f22a12fdc759a0c78bfe0547819277a36)
Cc: stable@vger.kernel.org
|
|
[Why/How]
On the PWM path, convert the userspace brightness to an input signal and
derive the target luminance from the custom backlight curve, then pass
the resulting millipercent to the power module.
This keeps PWM programming and backlight curve mapping in the power
module, aligning the Linux path with the Windows behavior.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5723
Fixes: 3c108046e1d6 ("drm/amd/display: Add power module on Linux")
Assisted-by: Cursor:Claude-Opus-4.8
Signed-off-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com>
Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bc4e099caa85e8d4c3555851a0feb07058c4a1fe)
Cc: stable@vger.kernel.org
|
|
For unknown reasons, on gfx12 using multiple entities can causes
random corruption of BOs with DCC.
This workaround seems to prevent the issue until the root cause
is understood and fixed.
Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5663
Fixes: 3a6f6eeb3db5 ("drm/amdgpu: give ttm entities access to all the sdma scheds")
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-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>
(cherry picked from commit cd647796ac1334acec0468fae49a0dacbba2a34c)
Cc: stable@vger.kernel.org
|
|
CWSR ranges use the always mapped flag and only need a mapping on the
GPU running the queue. However, svm_range_validate_and_map now updates
the mapping on every GPU with the ACCESS attribute, which is all
supported GPUs when XNACK is on. After the range is prefetched to VRAM,
those GPUs may span different XGMI hives, so the page owner mismatches
and is set to NULL. hmm_range_fault then tries to migrate the VRAM
pages back to system memory, but svm_migrate_to_ram skips it because
migrating pages back to system memory is not allowed while the GPU
mapping is being updated, so the CPU page fault is never resolved.
Only map to the ACCESS GPUs if the range is not mapped to any GPU and
is not in VRAM.
Fixes: b96f26104946 ("drm/amdkfd: Unmap svm range from GPU set to no-access")
Signed-off-by: Andrew Martin <andrew.martin@amd.com>
Assisted-by: Claude:claude-opus-5
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 093cf8842ace35ce212858d5059fee007ec8e778)
Cc: stable@vger.kernel.org
|
|
Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP
preserves kernel IB VMIDs instead of replacing them with the queue VMID.
Use prop->kernel_queue to distinguish kernel and user MQDs.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 893642e0e3b2f5aa818e0ee4a49e2d401d541e3a)
|
|
Set KMD_QUEUE in the GFX MQD and kernel ring control registers so CP
preserves kernel IB VMIDs instead of replacing them with the queue VMID.
Use prop->kernel_queue to distinguish kernel and user MQDs.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 14741c01680a803050e949744089b57fa53e02f7)
|
|
amdgpu_ring_set_fence_errors_and_reemit() and
amdgpu_ring_backup_unprocessed_commands() masked last_seq and sync_seq to
fence-array indices before the loop, then walked a do/while until the two
indices met. When hardware completed every command before the driver
signalled the fences, last_seq == sync_seq, but the masked-index do/while
could not tell that empty interval from a full table and walked the whole
fence array, backing up and replaying already-completed commands.
Read the raw sequence numbers, return early through amdgpu_fence_process()
when they are equal, and mask only at the array index. Guard the
force-completion against a NULL guilty_fence so a non-guilty backup does
not dereference it.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 78fbe156637a11456fcd29615a56e098ec8a6990)
|
|
amdgpu_ring_backup_unprocessed_commands() is also used to preserve a
ring that carries no guilty command - for example a collateral kernel
gfx ring that shares the faulting pipe during a gfx user-queue pipe
reset. Such a ring is backed up with a NULL guilty_fence and all of its
unprocessed commands must be saved so they can be replayed after the
reset rebuilds the ring's MQD.
The early-return that skips an already-seen guilty fence compared
"ring->guilty_fence == guilty_fence", which is also true when both are
NULL. A non-guilty save therefore hit the early return and left
ring_backup_entries_to_copy at 0, so the pending commands were dropped
when the ring was rebuilt.
Guard the early return with a non-NULL guilty_fence so a NULL fence
never takes it and every unprocessed command is backed up.
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b3f73daa1c2498273981b68b7534e540614069e3)
|
|
Unfortunately, some desktop boards eg. the FirePro D500
have the HARDWAREDC platform flag set and also have
a battery power state configured in their VBIOS.
This makes no sense for a desktop GPU and results in
incorrect behaviour: the clocks are stuck at lowest.
We observed that the kernel driver can work around
the issue in two possible ways:
1. Set PPSMC_SWSTATE_FLAG_DC on all power states
2. Clear PPSMC_SYSTEMFLAG_GPIO_DC
We think that the PPSMC_SYSTEMFLAG_GPIO_DC flag
makes the SMC assume it's running on battery even
though this is a desktop machine with no battery,
and that's why it doesn't do DPM on power states
without PPSMC_SYSTEMFLAG_GPIO_DC.
Issue was uncovered by "Fix updating clock limits from
power states" because previously the limits for the
battery state were not tracked separately. However,
battery power state has lower frequencies and voltages,
so the kernel doesn't set the DC flag on the current
power state anymore. That causes the SMC to be stuck
on the lowest clocks.
Let's clear PPSMC_SYSTEMFLAG_GPIO_DC on desktop GPUs.
We can use the AMD_IS_MOBILITY flag to determine that.
Fixes: e6c5d36756e7 ("drm/amd/pm/si: Fix updating clock limits from power states")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16352
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260923120354.1027996-1-timur.kristof@gmail.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 58473c7c49ce9f5f5a4a1c24ffb9aa1d3c8771f4)
Cc: stable@vger.kernel.org
|
