The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-12-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-11-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-10-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-9-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-8-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_atomic_helper_bridge_reset() helper is deprecated in favour
of the new atomic_create_state callback.
Add drm_atomic_helper_bridge_create_state() as the counterpart helper
for this new callback, and make drm_atomic_helper_bridge_reset() call
this new helper.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-7-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Commit 47b5ac7daa ("drm/atomic: Add new atomic_create_state callback
to drm_private_obj") introduced a new pattern for allocating drm object
states: atomic_create_state, a dedicated hook that allocates and
initializes a pristine state without any side effect.
The bridge atomic_reset callback is already fallible and in practice
only allocates and initializes state without touching hardware.
However, the reset name does not make this contract clear: callers
and implementers cannot tell from the name alone whether the hardware
will be affected or when the hook is safe to call.
Add an atomic_create_state callback to drm_bridge_funcs to make the
contract explicit: allocate a pristine state, initialize it, no side
effects. The core calls it when available, falling back to
atomic_reset otherwise.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-6-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
__drm_atomic_helper_bridge_state_init() is always called on a freshly
kzalloc-ed state, so the memset is redundant.
Drop it and document the expectation that the state is already zeroed.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-5-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The convention for state init helpers is to pass the state pointer
as the first argument and the object pointer second.
__drm_atomic_helper_bridge_state_init() has them in the opposite
order. Swap the arguments to follow the convention, and update the
cdns-mhdp8546 caller.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-4-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
__drm_atomic_helper_bridge_reset() is used to initialize a
newly allocated drm_bridge_state, and is being typically called by the
drm_bridge_funcs.atomic_reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_bridge_state instance, we will need to call
__drm_atomic_helper_bridge_reset() from both the atomic_reset and
atomic_create_state hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_bridge_reset() to
__drm_atomic_helper_bridge_state_init().
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-3-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset documentation states that the hook
must return either a valid drm_bridge_state object or an ERR_PTR().
The cdns_mhdp_bridge_atomic_reset() callback returns NULL when the
allocation of its state fails, violating this contract.
Return ERR_PTR(-ENOMEM) instead.
Fixes: fb43aa0acd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-2-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge_funcs.atomic_reset documentation states that the hook
must return either a valid drm_bridge_state object or an ERR_PTR().
The cdns_dsi_bridge_atomic_reset() callback returns NULL when the
allocation of its state fails, violating this contract.
Return ERR_PTR(-ENOMEM) instead.
Fixes: a53d987756 ("drm/bridge: cdns-dsi: Move DSI mode check to _atomic_check()")
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug
Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-1-ff399263111b@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Lets simplify and make clearer the fence lock cycling workaround in
nouveau_cli_work().
The reason for the workaround is that the worker processes the list of
pending work items (and so fence callbacks) opportunisticaly, while
dma_fence_is_signaled() returns true as soon as a the fence is signaled.
It is therefore not allowed for the opportunistic processing to free the
work item, since the fence callback processing can still be in the process
of dereferencing work->cb.
This wasn't very clear in the code so clarify it with a nice comment.
In the process we replace the somewhat interleaved and not very readable
nouveau_cli_work_ready() helper with a direct dma_fence_is_signaled, which
is even faster since it removes the lock cycling from the unsignaled fence
path.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: nouveau@lists.freedesktop.org
Link: https://patch.msgid.link/20260615092607.80917-1-tvrtko.ursulin@igalia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
We've had an unknown Turing issue for a while with page faults since
large pages and compression.
I've got a patch series that syncs all our L2 handling with ogkm and it
made this fault happen more.
After writing a bunch of debugging patches, I spotted an invalid LPT
entry where there should have been a valid one.
A 64K MAP succeeds on a range, but a subsequent SPT put drops SPT refs
across multiple ranges,
We shouldn't assume all ranges where SPTEs go away will have the same
sparse/invalid/valid state, just iterate over each instead and do the
right thing.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes: d19512f5ab ("nouveau/vmm: start tracking if the LPT PTE is valid. (v6)")
Link: https://patch.msgid.link/20260615044737.3419585-1-airlied@gmail.com
[ Properly format commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
In the non-uvmm path, there could be a race between the info lookup
finding the vma, and the gem close path closing the vma leading
to a use-after-free.
Spotted with the help of Opus 4.6.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes: e758a31119 ("drm/nouveau: fixup gem_info ioctl to return client-specific bo virtual")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260612020658.3176270-1-airlied@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The backlight, when managed by the panel controller, could be powered by
an external regulator, and shutting down the regulator could power off
the backlight.
Add support for such a regulator. It's powered off when the backlight is
0 (either by setting brightness to 0 or setting bl_power), and powered
on when the backlight should be operating.
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260608162622.403713-3-zhengxingda@iscas.ac.cn
As backlight powering on/off support will be added, more fields of the
panel context will be accessed in the backlight update function.
Pass the whole panel struct instead of the DSI device when creating the
backlight device.
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260608162622.403713-2-zhengxingda@iscas.ac.cn
When the backlight is managed by the panel controller IC, an external
power rail might be powering the backlight.
Add an optional `bl-supply` property to describe such power rail, thus
allow disabling the backlight.
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260608162622.403713-1-zhengxingda@iscas.ac.cn
Add support for Ilitek ILI9488 DSI controller which is used in
FocusLCDs E35GH-I-MW800-CB 320x480 MIPI DSI panel. The mode timing
was adjusted after STM32MP157 testing. The previous 14.256 MHz mode
worked on AM62P, but was awkward for STM32 DSI/LTDC clock synthesis.
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260617143245.372182-3-igor@reznichenko.net
Add binding for the Ilitek ILI9488 panel controller which is found on
the FocusLCDs E35GH-I-MW800-CB MIPI DSI panel. Add "focuslcds" to
vendor-prefixes.yaml as it's a brandname and a website
(https://focuslcds.com/) for Focus Display Solutions, Inc.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Igor Reznichenko <igor@reznichenko.net>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260617143245.372182-2-igor@reznichenko.net
This adds support for the ICNA3512 and ICNA3520 DDICs used in both the
AYN Odin 2 Portal and Ayaneo Pocket DS top panel respectively and for
for both the AYN Odin 3 and the AYN Thor top panel respectively.
These all have unique compatibles because the panels themselves are
likely unique hardware with only the ddic's and thus api and driver
handling shared.
Signed-off-by: Teguh Sobirin <teguh@sobir.in>
Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260607-icna35xx-v4-2-64de514add34@gmail.com
The Chipone ICNA3512 and ICNA3520 DDICs are high refresh, low power
MIPI-DSI drivers for OLED panels. The icna3512 is used by the Ayn Odin 2
Portal and the Ayaneo Pocket DS top panel while the icna3520 is used by
the Ayn Thor top panel and the Ayn Odin 3.
These ddic's are generally compatible, but some MIPI vendor commands
differ between them, so they are not fully fallback compatible.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260607-icna35xx-v4-1-64de514add34@gmail.com
The panel used by Anbernic in the RG Vita-Pro is a DSI panel based
on the TD4310 controller IC. It measures approximately 5.5 inches
diagonally and is 1080x1920 in resolution.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260610144407.438846-5-macroalpha82@gmail.com
The panel used by Anbernic in the RG Vita-Pro is a DSI panel based
on the TD4310 controller IC. It measures approximately 5.5 inches
diagonally and is 1080x1920 in resolution.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260610144407.438846-4-macroalpha82@gmail.com
When a driver specifies a beneficial order, TTM should make a reasonable
effort to allocate pages at that order.
Use __GFP_RETRY_MAYFAIL instead of __GFP_NORETRY when allocating at the
beneficial order. This allows reclaim to try harder before falling back to
smaller orders, at the cost of longer allocation setup time.
That tradeoff is acceptable for beneficial-order allocations: higher-order
backing pages can improve TLB hit rates and reduce the number of TLB
invalidations needed when moving memory.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260617022248.1165101-1-matthew.brost@intel.com
Recommend forking drm/kernel instead of uploading a distinct copy,
as this allows GitLab to internally track that these are the same
git objects.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Vignesh Raman <vignesh.raman@collabora.com>
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Link: https://patch.msgid.link/20260219135645.261192-1-eric@engestrom.ch
The IPC RX hardirq handler matches consumers under a spinlock and
allocates rx_msg buffers. On PREEMPT_RT these spinlocks become sleeping
locks and the allocation may sleep, neither of which is allowed in true
hardirq context, resulting in "sleeping function called from invalid
context" splats.
IRQF_ONESHOT makes genirq keep the primary handler in hardirq even when
forced threading is enabled, so on PREEMPT_RT the handler cannot be
threaded. Drop the flag so the primary handler is threaded on PREEMPT_RT
and the IPC RX path runs in a context where sleeping is allowed. On the
MSI interrupt chip (IRQCHIP_ONESHOT_SAFE) the flag was stripped anyway,
so non-RT behaviour is unchanged.
Fixes: 85c9cc2d25 ("accel/ivpu: Use threaded IRQ for IPC callback processing")
Cc: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Cc: Karol Wachowski <karol.wachowski@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260617092031.3016582-1-karol.wachowski@linux.intel.com
The .driver_data member of the various struct pci_device_id arrays were
initialized by list expressions. This isn't easily readable if you're
not into PCI. Using the PCI_DEVICE macro and named initializers is more
explicit and thus easier to parse. Also skip explicit assignments of 0
(which the compiler then takes care of).
This change doesn't introduce changes to the compiled pci_device_id
arrays. Tested on x86 and arm64.
v2:
- gma500: fix coding style in cast
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260504150537.2136760-2-u.kleine-koenig@baylibre.com
The current DSI mode configuration disables horizontal front porch
(HFP) and back porch (HBP) transmission using
MIPI_DSI_MODE_VIDEO_NO_HFP and MIPI_DSI_MODE_VIDEO_NO_HBP.
However, the SN65DSI83/84 bridge relies on receiving full horizontal
timing information over DSI in order to correctly reconstruct the
LVDS output timings. When HFP and HBP are not transmitted, the bridge
cannot recreate the required timing parameters, resulting in unstable
or missing display output on some panels.
The SN65DSI84 datasheet also describes transmission of complete
horizontal timing information as part of the DSI video stream.
Remove MIPI_DSI_MODE_VIDEO_NO_HFP and MIPI_DSI_MODE_VIDEO_NO_HBP
so that HFP and HBP timing information is transmitted to the bridge.
Reference:
SN65DSI84 Datasheet, Section 7.4.7 (page 20):
https://www.ti.com/lit/ds/symlink/sn65dsi84.pdf
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Sudarshan Shetty <tessolveupstream@gmail.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260527085736.920390-2-tessolveupstream@gmail.com
[Luca: cleaned up datasheet URL]
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260517172136.3321-2-thorsten.blum@linux.dev
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Replace individual ssd130x_write_cmd() calls and per-command error
checks with a flat command array dispatched through ssd130x_run_cmd_seq().
Signed-off-by: Alberto Ruiz <aruiz@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260612-ssd-batchcmd-v1-4-c61e5f7c24bc@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Replace individual ssd130x_write_cmd() calls and per-command error
checks with a flat command array dispatched through ssd130x_run_cmd_seq().
Signed-off-by: Alberto Ruiz <aruiz@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260612-ssd-batchcmd-v1-3-c61e5f7c24bc@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Introduce ssd130x_run_cmd_seq() that interprets a flat byte array of
length-prefixed command entries terminated by a zero byte, removing the
need for per-command error checking at each call site.
Signed-off-by: Alberto Ruiz <aruiz@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260612-ssd-batchcmd-v1-1-c61e5f7c24bc@redhat.com
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Currently we have not explicitly defined the behaviour when the width
and height of the writeback framebuffer do not match the width and
height of the attached CRTC.
Allow the driver to perform a scale operation to fit the content, so
systems with scaling blocks in the writeback path can easily expose them.
A partially filled buffer should never be returned, so failure remains
an option for all the systems that don't have a scaler, or when scaler
limits are exceeded.
Cropping would make less sense, as the region to crop is underspecified
without some other properties to define an origin.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Link: https://patch.msgid.link/20260602191754.79047-1-derek.foreman@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Having the test EDID arrays defined in the .h directly will duplicate
them across every user of the EDID arrays. This works fine as long as
there's only one user, but may produce build warnings/errors when there
are multiple users and not all of them use all definitions.
Move the array definitions to a new .c file, and mark the declarations
in the header as "extern" to avoid the linker throwing a fit, and give
them an explicit size (either 128 or 256, depending on EDID) to avoid
the compiler inferring that they must be size 1.
Reported-by: Jani Nikula <jani.nikula@linux.intel.com>
Closes: https://lore.kernel.org/r/04ff70850213ae0f75486b1a27a7edb6fb4e71c3@intel.com/
Fixes: ce1d0139ad ("drm/tests: bridge: Add test for HDMI output bus formats helper")
Fixes: 082fbc179c ("drm/tests: bridge: Add KUnit tests for bridge chain format selection")
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260610-test-edid-array-definition-fix-v3-1-8ba947c1c453@collabora.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use a dedicated kmem_cache for ivpu_ipc_rx_msg allocations instead of
the generic kmalloc. This gives each CPU its own hot freelist for this
object type, reducing allocator overhead in the IRQ handler and threaded
IRQ path where rx_msg objects are allocated and freed at high frequency.
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260611055214.948748-1-karol.wachowski@linux.intel.com
Dispatching IPC callbacks from system_percpu_wq adds scheduling latency
that is neither bounded nor predictable, which hurts job completion
turnaround. Handle them from a threaded IRQ instead: the hard-IRQ
handler drains the IPC FIFO and wakes the thread, which runs the
callback consumers such as job-done processing.
Job resource teardown can trigger IOMMU unmapping and context teardown,
which is too slow to run from the IRQ thread. Defer it to a dedicated
WQ_UNBOUND | WQ_MEM_RECLAIM workqueue via a per-device lockless list.
UNBOUND keeps the long-running cleanup off the percpu workers and
MEM_RECLAIM guarantees forward progress because the work frees buffer
objects. The runtime PM reference taken at submission is released only
after cleanup completes, otherwise runtime suspend could race the
pending work and deadlock.
Because cleanup is now asynchronous, userspace that rapidly recycles
file descriptors or command queues can momentarily observe stale
per-context resources and fail with -EMFILE or -EBUSY. Flush the
cleanup work once and retry before giving up.
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Link: https://patch.msgid.link/20260611055201.948726-1-karol.wachowski@linux.intel.com
Triggering kswap at an order higher than beneficial_order makes little
sense, as the driver has already indicated the optimal order at which
reclaim is effective. Similarly, issuing direct reclaim or triggering
kswap at a lower order than beneficial_order is ineffective, since the
driver does not benefit from reclaiming lower-order pages.
As a result, direct reclaim should only be issued with __GFP_NORETRY at
exactly beneficial_order, or as a fallback, direct reclaim without
__GFP_NORETRY at order 0 when failure is not an option.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Christian Koenig <christian.koenig@amd.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260612225757.3844350-1-matthew.brost@intel.com
A comment in <linux/sysfb.h> incorrectly refers to CONFIG_SYSFB_SIMPLE
instead of CONFIG_SYSFB_SIMPLEFB. Correct it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260610195248.19442-1-enelsonmoore@gmail.com
There is no need for a double space after an assignment.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://patch.msgid.link/80e30578b6dd86664112320616c460c48dbd79f6.1777881435.git.geert+renesas@glider.be
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Commit
28c5bf2876 ("drm/sched: Disallow initializing entities with no schedulers")
failed to notice clearing of entity->rq in drm_sched_entity_init() is now
redundant and can be removed.
Given that entity->rq can now never be NULL, we also remove two impossible
checks, from drm_sched_entity_kill() and drm_sched_entity_flush()
respectively.
Similarly, we can also remove the !entity->rq check in
drm_sched_job_init(). And for the better, given that the error message, if
it ever triggered, would have dereferenced the yet un-initialized job->
sched (only initialized later in drm_sched_job_arm()). This appears to
have been theoretically broken ever since commit
56e449603f ("drm/sched: Convert the GPU scheduler to variable number of run-queues")
.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260602153339.43453-1-tvrtko.ursulin@igalia.com
The colorspace property's documentation states that BT2020_RGB and
BT2020_YCC are equivalent, and the output format depends on the driver.
Now that there is a "color format" property that userspace can use to
explicitly set a format, update the colorspace docs to mention this.
The behaviour here is not changed for userspace that doesn't know about
the color format property yet, as the color format property defaults to
"AUTO", where the choice of output format is left up to drivers.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260609-color-format-v17-24-35739b5782cc@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
The bridge chain format selection behaviour was, until now,
undocumented. With the addition of the "color format" DRM property, it's
not sufficiently complex enough that documentation is warranted,
especially for driver authors trying to do the right thing.
Add a high-level overview of how the process is supposed to work, and
mention what the display driver is supposed to do if it wants to make
use of this functionality.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260609-color-format-v17-23-35739b5782cc@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
The common atomic_get_output_bus_fmts helper for HDMI bridge connectors,
called drm_atomic_helper_bridge_get_hdmi_output_bus_fmts, should return
an array of output bus formats depending on the supported formats of the
connector, and the current output BPC.
Add a test to exercise some of this helper.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260609-color-format-v17-22-35739b5782cc@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
With the "color format" property, the bridge chain format selection has
gained increased complexity. Instead of simply finding any sequence of
bus formats that works, the bridge chain format selection needs to pick
a sequence that results in the requested color format.
Add KUnit tests for this new logic. These take the form of some pleasant
preprocessor macros to make it less cumbersome to define test bridges
with a set of possible input and output formats.
The input and output formats are defined for bridges in the form of
tuples, where the first member defines the input format, and the second
member defines the output format that can be produced from this input
format. This means the tests can construct scenarios in which not all
inputs can be converted to all outputs.
Some tests are added to test interesting scenarios to exercise the bus
format selection in the presence of a specific color format request.
Furthermore, tests are added to verify that bridge chains that end in an
HDMI connector will always prefer RGB when the color format is
DRM_CONNECTOR_COLOR_FORMAT_AUTO, as is the behaviour in the HDMI state
helpers.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260609-color-format-v17-21-35739b5782cc@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add some KUnit tests to verify that the HDMI state helper's mode_valid
implementation does not improperly reject chroma subsampled modes on the
basis of their clock rate not being satisfiable in RGB.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://patch.msgid.link/20260609-color-format-v17-20-35739b5782cc@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
