| Age | Commit message (Collapse) | Author |
|---|
|
Properly handle power up failures during .atomic_pre_enable() by
aborting the .atomic_pre_enable() to avoid accessing registers why
blocks did not bring up. Otherwise this could lead to imprecise aborts
when accessing MMIO while entire power domain is off.
Cc: <stable@vger.kernel.org>
Fixes: ba3d7bf3a7ab ("drm/msm/hdmi: Convert PHY files according to new design")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/752652/
Link: https://lore.kernel.org/r/20260911-drm-msm-hdmi-fixes-before-eliza-v4-2-87bdb9f1987f@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
If msm_hdmi_phy_resource_enable() fails, e.g. when enabling regulators,
it should reverse the state of things already changed.
msm_hdmi_phy_resource_enable() is used also in probe path, thus such
failure, which could be simple deferred probe, would leave these
resources permanently enabled for the rest of the runtime.
Cc: <stable@vger.kernel.org>
Fixes: 15b4a4523859 ("drm/msm/hdmi: Create a separate HDMI PHY driver")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/752654/
Link: https://lore.kernel.org/r/20260911-drm-msm-hdmi-fixes-before-eliza-v4-1-87bdb9f1987f@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
In turing systems where gsp exists, but can end up not being used,
we need to add a second check.
Fixes: cb4c7603678c ("drm/nouveau/gsp/r570: Add support for INTERNAL_GCX_ENTRY_PREREQUISITE")
Reported-by: Woody Suwalski <terraluna977@gmail.com>
Tested-by: Woody Suwalski <terraluna977@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/nouveau/20260930212151.3926202-1-airlied@gmail.com/T/#u
|
|
Now that the timeout-related functions were removed from drm_utils.h,
the header has exclusively panel orientation and backlight quirk getters.
Therefore, rename the header accordingly and update all files that
include it. The files amdgpu_dm.c, amdgpu_dm_connector.c and panthor_drv.c
include the header but don't use it, so drop the include there.
No functional change.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-7-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
vc4_wait_bo_ioctl() converts its timeout with usecs_to_jiffies(), which
takes an unsigned int. The microsecond value derived from the u64
timeout_ns is narrowed to fit, so any timeout above UINT_MAX microseconds,
around ~71 minutes, wraps into a much shorter one. Unlike the equivalent
problem in the other drivers, this one is not limited to 32-bit.
Use the shared helper, which takes the duration in ns and clamps the
result to MAX_JIFFY_OFFSET.
Fixes: 21bd85f82ec2 ("drm/vc4: Use DMA Resv to implement VC4 wait BO IOCTL")
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-6-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
nsecs_to_jiffies_timeout() originated here and has since been copied into
another driver. It is now available in "drm_timeout.c", so use it and drop
the local definition.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-5-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
v3d carried an exact copy of i915's nsecs_to_jiffies_timeout(). Now
that the conversion lives in "drm_timeout.c", drop the copy and use it.
The core helper also returns 0 for a zero timeout. i915 has that check in
to_wait_timeout(), but v3d only ever copied the conversion, so
DRM_IOCTL_V3D_WAIT_BO with timeout_ns == 0 was turned into a one jiffy
wait and could block for a tick before reporting -ETIME. It now returns
without waiting.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-4-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
amdgpu_gem_timeout() converts an absolute deadline in ns into jiffies,
which is what drm_timeout_abs_to_jiffies() already does for the other
drivers whose wait UAPI takes a deadline. Use the shared helper and keep
only the part that is specific to amdgpu, which was improved with a
clearer comment.
Two details change along this conversion: the helper rounds up rather than
truncating, so a deadline less than a tick away now waits for one jiffy
instead of returning 0. It also uses nsecs_to_jiffies64(), so the
conversion no longer truncates on 32-bit, where a large deadline could
previously be reduced to an arbitrary shorter one.
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-3-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
drm_timeout_abs_to_jiffies() covers the drivers whose wait UAPI takes an
absolute deadline, but there is no equivalent for the drivers that
express a wait as a duration. Drivers such as i915 and v3d convert the
value themselves.
Converting a nanosecond duration to jiffies needs some care.
nsecs_to_jiffies() returns unsigned long, so on 32-bit a large
userspace-supplied timeout overflows its range and is silently truncated.
i915 already handles both cases in a local helper, which v3d has a copy
of. Add the same conversion to the core, so that it is available to any
driver and both copies can be dropped.
Differently from drm_timeout_abs_to_jiffies(), the new function enforces
that a timeout in jiffies is a positive value and therefore, returns an
unsigned value.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-2-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
drm_timeout_abs_to_jiffies() began as a static helper inside the syncobj
wait implementation and was later exported in place, so that it could be
called by multiple drivers (e.g. panfrost, lima, tegra and accel
drivers). All of them reach it through drm_utils.h.
Give it a file of its own, so that timeout conversion helpers have a
home, which will be useful when we add new timeout handlers. Also create
a drm_timeout.h header to host all timeout-related helpers.
The function was moved to the new file as it is, including the use of
"signed long" as the return type. Note that the return and parameters
types should be reconsidered in the future to better represent the
non-negative nature of a timeout.
No functional change.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-1-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
Switch amdgpu_dm test helpers from the local STATIC_IFN_KUNIT
macro to VISIBLE_IF_KUNIT.
The two are not identical: STATIC_IFN_KUNIT was gated on
CONFIG_DRM_AMD_DC_KUNIT_TEST, while VISIBLE_IF_KUNIT is gated on
CONFIG_KUNIT. Helpers therefore become non-static whenever KUnit
is enabled, not only when the AMD DC tests are built.
However, given that DRM_AMD_DC_KUNIT_TEST depends on KUNIT,
tests remain behaviourally unchanged.
kernel-doc still needs to strip the qualifier. amdgpu_dm_color.c
is pulled into Documentation/gpu and several documented functions
use it.
Include <kunit/visibility.h> from dm_helpers.h, which is where the
local macros used to live.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use plane_descriptors[k] for the loop bound, matching the loop body.
Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6")
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
dc_state_create_copy() can return NULL on allocation failure.
dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts()
and continues execution, returning success. dm_resume() then
dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the
following dc_state->stream_count loop, crashing during GPU reset
recovery.
Return -ENOMEM immediately if the copy fails, so the caller aborts
suspend instead of leaving a NULL cached state for resume.
Fixes: 8092aa3ab8f7 ("drm/amd/display: Add null checker before passing variables")
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If drm_edp_backlight_enable() fails, dp_aux_backlight_update_status()
still marks the backlight as enabled. From then on every brightness
change only updates the level and the enable is never retried, so the
panel stays dark until something blanks and unblanks the backlight.
Return the error instead, so the next update tries to enable again.
Fixes: 10f7b40e4f30 ("drm/panel: add basic DP AUX backlight support")
Signed-off-by: Oleg Keri <okerixx@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260925132558.27518-1-okerixx@gmail.com
|
|
NV140WU2-M70 raw edid:
00 ff ff ff ff ff ff 00 09 e5 ae 38 00 00 00 00
14 24 01 04 a5 1e 13 78 07 7a 95 97 5d 59 95 29
20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 24 31 80 a0 70 b0 3c 40 30 20
36 00 2d bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c
4c 10 01 0a 20 20 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
00 4e 56 31 34 30 57 55 32 2d 4d 37 30 0a 01 35
70 20 79 02 00 20 00 0c 9a 0e 00 ae 38 00 00 00
00 14 1a 00 21 01 1d c8 0b 5d 07 80 07 b0 04 88
74 b9 5d 99 85 95 97 42 20 02 35 54 b0 5c b0 5c
66 32 12 78 22 00 14 3f 66 02 85 7f 07 9f 00 2f
00 1f 00 af 04 3b 00 02 00 05 00 81 00 15 74 1a
00 00 03 01 28 3c 00 00 53 42 53 42 3c 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 8d 90
Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260930063856.183763-1-zhouhaikun5@huaqin.corp-partner.google.com
|
|
This is a high value thing to print, because it acts as kind of a
bookend, showing the beginning of trying to boot up.
Cc: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260929210749.409380-1-jhubbard@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Commit 2563a4524febe ("drm/i915: restrict kernel address leak in
debugfs") introduced the %pK modifier in order not to leak kernel
pointer.
Since commit ad67b74d2469d ("printk: hash addresses printed with
%p") pointers are hashed by default and the behaviour can be controller
by `hash_pointers' boot argument.
The policy on %p is to not introduce new ones. Keeping the %p allows
to assign an id to the object.
Removing %pK makes it possible to remove its handling from the library.
Use %p instead %pK to allow debugging if needed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260918103725.cfYzL1Wt@linutronix.de
|
|
slot count
In panthor_drv.c:panthor_ioctl_group_create(),
the queue count is validated against the hardcoded maximum:
if (!args->queues.count || args->queues.count > MAX_CS_PER_CSG)
return -EINVAL;
However, if the firmware reports fewer slots than MAX_CS_PER_CSG,
panthor_fw_init_ifaces() will only initialize that smaller number of
stream interfaces.
If unprivileged userspace requests more queues than the firmware reported
(but no more than MAX_CS_PER_CSG), cs_slot_prog_locked() fetches an
uninitialized stream interface and may crash when dereferencing
cs_iface->input->ringbuf_base.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Cc: stable@vger.kernel.org
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260803141149.68182-1-osama.abdelkader@gmail.com?part=1
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260804160048.174148-1-osama.abdelkader@gmail.com
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
|
|
slot count
In panthor_drv.c:panthor_ioctl_group_create(),
the queue count is validated against the hardcoded maximum:
if (!args->queues.count || args->queues.count > MAX_CS_PER_CSG)
return -EINVAL;
However, if the firmware reports fewer slots than MAX_CS_PER_CSG,
panthor_fw_init_ifaces() will only initialize that smaller number of
stream interfaces.
If unprivileged userspace requests more queues than the firmware reported
(but no more than MAX_CS_PER_CSG), cs_slot_prog_locked() fetches an
uninitialized stream interface and may crash when dereferencing
cs_iface->input->ringbuf_base.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Cc: stable@vger.kernel.org
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260803141149.68182-1-osama.abdelkader@gmail.com?part=1
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260804160048.174148-1-osama.abdelkader@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
|
|
`SectionFlags` and `MMU_MEMATTR_STAGE1` are not registers themselves. Use
`bitfield!` directly.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260910165734.80378-1-gary@kernel.org
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
The entity->last_scheduled field has always been set and read with
special RCU functions in addition to memory barriers.
This was added in
commit 70102d77ff22 ("drm/scheduler: add drm_sched_entity_error and use rcu for last_scheduled")
however, no proper justification for that mechanism was provided. There
seems to be no obvious reason, since the entity lock is available and
taken at all places that evaluate the last_scheduled field. The only
exception is drm_sched_entity_error(), which is not performance critical
in any way.
Improve robustness, readability and maintainability by replacing RCU and
barriers with the lock.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260922145441.619097-2-phasta@kernel.org
|
|
drm_bridge_attach() inspects bridge->list to warn about bridges being
attached without a previous drm_bridge_add() call, but it does so
without holding bridge_lock.
The list head can be concurrently written by drm_bridge_add(),
drm_bridge_remove() and __drm_bridge_free() while they operate on
neighbouring entries of bridge_list or bridge_lingering_list, all of
them under bridge_lock. Hence the unlocked read is a data race, even
though it is unlikely to change the outcome of list_empty() in practice.
Perform the check with bridge_lock held.
Fixes: 76f1a9711b83 ("drm/bridge: add warning for bridges attached without being added")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-14-bc12954a0688@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
When re-adding a bridge that was previously removed, drm_bridge_add()
drops it from bridge_lingering_list without holding bridge_lock.
Both bridge_list and bridge_lingering_list are protected by bridge_lock,
as they are concurrently modified by drm_bridge_remove() and
__drm_bridge_free(), and walked by the debugfs 'bridges' file. Running
the list_empty() test and the list_del_init() outside of the lock may
therefore corrupt either list.
Perform both under bridge_lock.
Fixes: 17805a15d175 ("drm/bridge: add list of removed refcounted bridges")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260723015004.1F5711F000E9@smtp.kernel.org/
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, dual HDMI
Tested-by: Robin Räber <robin.raebi@gmail.com>
Link: https://patch.msgid.link/20260901-dw-hdmi-qp-scramb-v11-12-bc12954a0688@collabora.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
format reported by the downstream panel or bridge describes the display
input, but it does not describe how the LCDIF data pins are physically
wired on the board.
These can differ. For example, a 16-bit LCDIF bus can be connected to a
24-bit display by wiring the available color bits to the corresponding
display inputs. In that case, using the display's 24-bit format to
configure LCDIF selects the wrong data-bus mode and changes the assignment
of color bits on the LCD_DATA pins.
Read the optional bus-width endpoint property from the LCDIF output port
and use it to select the media bus format used to configure LCDIF. This
allows the LCDIF bus mode to describe the physical interface
independently of the downstream display format.
When the property is absent, continue using the format reported by the
downstream display device, preserving the previous behavior. The
devicetree binding restricts bus-width to 16, 18 or 24; any other value
means the devicetree is broken, so fail the probe instead of silently
falling back to the previous behavior.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260917140042.118181-3-francesco@dolcini.it
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
There is a small race window between intel_rps_boost() reading
a stale ACTIVE state and queuing rps->work, where ACTIVE may be
changed via asynchronous calls triggered by wakeref drop.
This means that rps_work() could be triggered after the GT has
been parked, so unmasking RPS PM interrupts would happen without
holding PM wakelock. This sequence of events may be observed
during live_rc6_ctx_wa() selftest:
1) live_rc6_ctx_wa()
-> intel_engine_pm_put()
-> wakeref_put()
ASYNC1) wakeref_put() callback
-> __engine_park()
-> intel_gt_pm_put_async()
-> intel_gt_pm_put_async_untracked()
-> intel_wakeref_put_async()
ASYNC2) wakeref_put_async() callback
-> __gt_park()
-> intel_rps_park()
-> intel_rps_clear_active() [clear ACTIVE]
WITH INTERRUPTS:
-> rps_disable_interrupts()
-> cancel_work_sync(rps->work)
-> rps_reset_interrupts() [rps->pm_iir = 0]
WITHOUT INTERRUPTS (TIMER mode):
-> rps_stop_timer()
-> cancel_work_sync(rps->work)
2) live_rc6_ctx_wa()
-> intel_gt_wait_for_idle()
-> intel_gt_retire_requests_timeout()
-> dma_fence_wait_timeout()
-> ops->wait() [i915_fence_wait()]
-> i915_request_wait_timeout()
-> intel_rps_boost()
-> intel_rps_is_active() [check ACTIVE]
[OPEN RACE WINDOW]
-> queue_work(rps->work)
-> retire_requests()
-> i915_request_retire()
-> intel_rps_dec_waiters() [from 1 to 0]
If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW],
then:
3) rps_work() executes from the workqueue and may satisfy
"(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir
is zeroed by an earlier rps_work() call or never gets a new
value after previous intel_rps_unpark() event), so it jumps
to "out" label, bypassing intel_rps_is_active() guard and
executes gen6_gt_pm_unmask_irq();
4) GT is parked and runtime PM wakelock is dropped, so only
a raw reference in __gt_park() ->
intel_display_power_put_async() remains for 100ms, then the
MMIO write in gen6_gt_pm_unmask_irq() detects missing
wakelock via assert_rpm_wakelock_held() and emits
"RPM wakelock ref not held during HW access" tainting kernel.
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management")
dropped the "if (rps->interrupts_enabled)" guard that
gen6_pm_rps_work() had around this unmask in i915_irq.c.
INTEL_RPS_ACTIVE brackets the same window, since it is set in
intel_rps_unpark() before rps_enable_interrupts() and
rps_start_timer() and cleared in intel_rps_park() before
rps_stop_timer() and rps_disable_interrupts().
Skip unmasking when RPS is no longer active (reaching unmask
operation is independent of INTERRUPT mode). This does not
prevent RPS operation from resuming on the next unpark.
In interrupt mode, intel_rps_unpark() calls
rps_enable_interrupts(), which enables and unmasks the PM
interrupts. In timer mode, it calls rps_start_timer(),
restarting periodic engine-busyness evaluation. The timer
generates software RPS events and queues rps_work() directly,
independently of PM interrupt delivery. Neither mode requires
the late worker to unmask interrupts while the GT is parked
Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16562
Cc: stable@vger.kernel.org # v5.5+
Assisted-by: GitHub-Copilot:claude-opus-5
Assisted-by: GitHub-Copilot:gpt-6-astra
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260910081329.3300417-1-krzysztof.karas@intel.com
|
|
This changes the vgaarb client API so that the user can pass a
private data pointer into the register that will get used in
the decode callback.
This allows a bunch of pdev conversions in the drivers, and lets
some future vfio cleanups be nicer.
I'd like to merge this via the drm next tree but also fine with
it going via pci.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Alex Williamson <alex@shazbot.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/dri-devel/20260922071807.2533884-1-airlied@gmail.com/
|
|
It is possible for eb_relocate_parse_slow() to call kvfree() on
entries outside the original exec array during following
scenario inside eb_relocate_parse_slow():
1) eb_copy_relocations() allocates as many as eb->buffer_count
copies for exec entries;
2) eb_parse() appends up to two VMAs, right after incrementing
eb->buffer_count;
3) cleanup under "out" label uses this incremented buffer_count
to release relocation pointers from exec array via kvfree(),
not from VMA array.
To amend this problem, ensure that relocation cleanup uses the
original exec object count, excluding the VMAs appended by the
command parser.
Fixes: 8e4ba491b0ba ("drm/i915: Parse command buffer earlier in eb_relocate(slow)")
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Assisted-by: GitHub-Copilot:gpt-6-astra
Cc: stable@vger.kernel.org # 5.10+
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260911061145.3535489-1-krzysztof.karas@intel.com
|
|
DP v2.1b specifies that REMOTE_DPCD_READ and REMOTE_DPCD_WRITE
transactions should only be issued to downstream ports where ddps=1
(device plug status indicates a device is connected). Issuing these
transactions to empty ports (ddps=0) is non-compliant and causes
problems in practice: some MST hubs NAK the request, and all hubs
introduce a delay waiting for the transaction to complete or fail
before the driver can proceed, increasing link training latency.
Guard drm_dp_mst_dpcd_read() and drm_dp_mst_dpcd_write() with a
ddps check and return -EIO immediately for unoccupied ports. This
avoids the spurious sideband transactions without changing connector
lifetime semantics — connectors for all output ports are still
created at enumeration time, regardless of ddps.
Signed-off-by: Xiao Lu <xiaolu.xie@intel.com>
Changes in v2:
- Instead of skipping connector creation for ddps=0 ports (v1),
keep connectors around and guard DPCD transactions at the
drm_dp_mst_dpcd_read/write level. This avoids changing connector
lifetime semantics visible to userspace, per Lyude's review.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260920022144.2209244-1-xiaolu.xie@intel.com
|
|
Just like in Gpu::new() a single try_pin_init!() block makes the code
more readable.
Besides that, it prepares the code for a proper PCI device enable guard
that we will get soon.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260927144417.1280385-1-dakr@kernel.org
[ Drop useless dev_dbg!() in probe(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
ssd132x_clear_screen() writes a full screen of data without setting
the column and row ranges first, unlike ssd130x_clear_screen(). The
clear is not reachable today: the plane disable returns before it,
and the encoder is powered down by then.
Factor the range commands into ssd132x_set_col_range() and
ssd132x_set_row_range() and use them from ssd132x_update_rect() and
ssd132x_clear_screen().
Assisted-by: LLM
Signed-off-by: Fabio Piparo <holofermes@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260922225445.1525837-1-holofermes@gmail.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
Commit bfa597238073 ("drm/i915/dip: Enable Common SDP Transmission line")
enabled the CMN_SDP_TL for the modeset path, but missed to add it to the
fastset path.
Since dip.cmn_sdp_tl is already skipped from the strict pipe-config
comparison during fastsets, it was always intended to get updated
without full modeset, but the update to the register was missed.
During a fastset, if CMN_SDP_TL changes, update the register
similar to the EMP_AS_SDP_TL, which gets updated in
intel_vrr_set_transcoder_timings().
v2: Update cmn_sdp_changed() to also compare gmp_sdp_tl, pps_sdp_tl and
vsc_ext_sdp_tl, not just cmn_sdp_tl. (Sashiko)
Fixes: bfa597238073 ("drm/i915/dip: Enable Common SDP Transmission line")
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260924021950.350207-1-ankit.k.nautiyal@intel.com
|
|
According to the datasheet, VID_DOWNSAMPLE_CONFIG is at offset 0x8f0;
0x8d0 is the VID_CSC_COEFF_0 register.
Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188")
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260828-mtk-hdmi-v2-fix-register-offset-v1-1-118ad5d7ebe3@baylibre.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
platform_device_register_data() can fail and return an ERR_PTR, but the
return value is used without checking, leading to an invalid pointer
being stored in ddp_comp[].dev and passed to component_match_add() and
mtk_ddp_comp_init(), which could result in a kernel crash.
Add an IS_ERR() check to jump to the error handling path on failure.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Cc: stable@vger.kernel.org
Signed-off-by: Haojie Li <lihaojie@kylinos.cn>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260825100845.438893-1-lihaojie@kylinos.cn/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
|
This stops the log spamming introduced by the referenced fixes commit.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://patch.msgid.link/20260916190144.2080777-1-ian.forbes@broadcom.com
|
|
Validate the pitch, alongside the box dimensions before trying
to copy data from the underlying surface. Fixes possible
out of bounds reads with cursor snooping.
Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes")
Cc: stable@vger.kernel.org
Reported-by: Youness HFA <hfa.youness@gmail.com>
Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
Link: https://patch.msgid.link/20260809204515.211045-1-zack.rusin@broadcom.com
|
|
When VFs are enabled on dGFX the driver resizes the PF VF_LMEM_BAR to
fit the requested layout. After VFs are disabled the PF VF BAR
size is left as-is. On platforms with tight MMIO apertures a
subsequent unplug/rescan followed by another enable may fail with:
"VF BAR …: can't assign; no space"
because the PCI core reserves address space based on the (now large) VF
template, often multiplied by totalvfs.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5937
Fixes: 94eae6ee4c2d ("drm/xe/pf: Set VF LMEM BAR size")
Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com>
Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260918110130.700332-1-marcin.bernatowicz@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 0646547a67d25c407f5a4ac71b4eefe8b941202b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Improve and move diagnostics messages to the helper function to
keep the caller function tidy.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260911182306.14973-1-michal.wajdeczko@intel.com
(cherry picked from commit 10628c52a3732a10426499a3d462cc2e6bc371ae)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
exynos_fimd_resume() can fail when clk_prepare_enable() succeeds for
bus_clk but fails for lcd_clk. The function returns the error without
disabling bus_clk, leaving it prepared and enabled.
Disable bus_clk before returning the error to keep the clock state
balanced.
Signed-off-by: jiawen <1298662399@qq.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Use memdup_user() to replace the open-coded kmalloc() and
copy_from_user() sequence.
This simplifies the code while preserving the existing behavior.
This issue was reported by memdup_user.cocci.
Signed-off-by: Mohammad Shahid <mdshahid03@gmail.com>
Included linux/string.h header file on top of exynos_drm_vidi.c
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Sparse reports:
exynos_drm_fimd.c:992:39: warning: incorrect type in initializer (different address spaces)
exynos_drm_fimd.c:992:39: expected void *timing_base
exynos_drm_fimd.c:992:39: got void [noderef] __iomem *
exynos_drm_fimd.c:1005:33: warning: incorrect type in argument 1 (different address spaces)
exynos_drm_fimd.c:1005:33: expected void const volatile [noderef] __iomem *addr
exynos_drm_fimd.c:1005:33: got void *
exynos_drm_fimd.c:1007:33: warning: incorrect type in argument 2 (different address spaces)
exynos_drm_fimd.c:1007:33: expected void volatile [noderef] __iomem *addr
exynos_drm_fimd.c:1007:33: got void *
Add "__iomem" to *timing_base to fix its type.
Fixes: 3854fab24e89 ("drm/exynos: fimd: support LCD I80 interface")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Disable VRR DC balance by default due to timing issues observed on some
panel/TCON combinations.
Keep the module parameter to enable DC balance during debugging and to
isolate DC balance effects from underlying VRR/display timing issues.
--v2:
- Make enable_dc_balance a bool and keep it disabled by default; fix the
parameter type/value mismatch and correct the description (Chaitanya
Kumar Borah, Jani Nikula)
- Explain in the commit message why the feature is gated and why a
module parameter is used (Jani Nikula)
--v3:
- Commit message update (Jani Nikula)
Fixes: 555819270707 ("drm/i915/vrr: Enable DC Balance")
Cc: <stable@vger.kernel.org> # v7.0+
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260917074322.2606738-1-mitulkumar.ajitkumar.golani@intel.com
(cherry picked from commit d1ef78f0581e856c4238c751e9ae2884ce58c275)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
As of_drm_get_bridge_by_endpoint() returns a refcounted bridge, take care
of putting the bridge reference. This is not easily done in the remove path
due to the different probe paths of the user drivers, so add a devm action
to ensure the reference is put only when it was taken.
Assisted-by: opencode:deepseek-v4-flash-0731
Tested-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-19-83afb4f1a707@bootlin.com
[Luca: remove now unused variable]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
And since of_drm_find_and_get_bridge() returns a refcounted bridge, take
care of putting the bridge reference.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-18-83afb4f1a707@bootlin.com
[Luca: fix build error due to patch conflict on current drm-misc-next]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-17-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
As of_drm_get_bridge_by_endpoint() returns a refcounted bridge, take care
of putting the bridge reference when not used anymore.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-16-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
As of_drm_get_bridge_by_endpoint() returns a refcounted bridge, take care
of putting the bridge reference when not used anymore.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-15-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_find_and_get_bridge().
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-14-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_find_and_get_bridge().
And since of_drm_find_and_get_bridge() returns a refcounted bridge, take
care of putting the bridge reference by using bridge->next_bridge.
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-13-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_find_and_get_bridge().
Also keep the "connected to non-panel bridge (unsupported)\n" error logic
by using the drm_bridge_is_panel() function.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-12-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
The helpers are included but unused.
However symbols from drm_atomic_helper.h are used, and were previously
available as a side effect of drm_atomic_helper.h including
drm_atomic_state_helper.h. Add drm_atomic_state_helper.h.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-11-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
