Luca Ceresoli [Fri, 14 Feb 2025 12:57:42 +0000 (13:57 +0100)]
drm/bridge: panel: use drm_bridge_is_panel() instead of open code
drm_panel_bridge_remove() reads bridge->funcs to find out whether this is a
panel bridge or another kind of bridge. drm_bridge_is_panel() is made
exactly for that, so use it.
Vitalii Mordan [Fri, 14 Feb 2025 15:46:32 +0000 (18:46 +0300)]
gpu: cdns-mhdp8546: fix call balance of mhdp->clk handling routines
If the clock mhdp->clk was not enabled in cdns_mhdp_probe(), it should not
be disabled in any path.
The return value of clk_prepare_enable() is not checked. If mhdp->clk was
not enabled, it may be disabled in the error path of cdns_mhdp_probe()
(e.g., if cdns_mhdp_load_firmware() fails) or in cdns_mhdp_remove() after
a successful cdns_mhdp_probe() call.
Use the devm_clk_get_enabled() helper function to ensure proper call
balance for mhdp->clk.
Found by Linux Verification Center (linuxtesting.org) with Klever.
Andrew Wyatt [Thu, 13 Feb 2025 22:24:53 +0000 (22:24 +0000)]
drm: panel-orientation-quirks: Add quirk for OneXPlayer Mini (Intel)
The Intel model of the OneXPlayer Mini uses a 1200x1920 portrait LCD panel.
The DMI strings are the same as the OneXPlayer, which already has a DMI
quirk, but the panel is different.
Add a DMI match to correctly rotate this panel.
Signed-off-by: Andrew Wyatt <fewtarius@steamfork.org> Co-developed-by: John Edwards <uejji@uejji.net> Signed-off-by: John Edwards <uejji@uejji.net> Tested-by: João Pedro Kurtz <joexkurtz@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-6-uejji@uejji.net
Andrew Wyatt [Thu, 13 Feb 2025 22:24:52 +0000 (22:24 +0000)]
drm: panel-orientation-quirks: Add new quirk for GPD Win 2
Some GPD Win 2 units shipped with the correct DMI strings.
Add a DMI match to correctly rotate the panel on these units.
Signed-off-by: Andrew Wyatt <fewtarius@steamfork.org> Signed-off-by: John Edwards <uejji@uejji.net> Tested-by: Paco Avelar <pacoavelar@hotmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-5-uejji@uejji.net
Andrew Wyatt [Thu, 13 Feb 2025 22:24:51 +0000 (22:24 +0000)]
drm: panel-orientation-quirks: Add quirk for AYA NEO Slide
The AYANEO Slide uses a 1080x1920 portrait LCD panel. This is the same
panel used on the AYANEO Air Plus, but the DMI data is too different to
match both with one entry.
Add a DMI match to correctly rotate the panel on the AYANEO Slide.
This also covers the Antec Core HS, which is a rebranded AYANEO Slide with
the exact same hardware and DMI strings.
Signed-off-by: Andrew Wyatt <fewtarius@steamfork.org> Signed-off-by: John Edwards <uejji@uejji.net> Tested-by: John Edwards <uejji@uejji.net> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-4-uejji@uejji.net
Andrew Wyatt [Thu, 13 Feb 2025 22:24:50 +0000 (22:24 +0000)]
drm: panel-orientation-quirks: Add quirks for AYA NEO Flip DS and KB
The AYA NEO Flip DS and KB both use a 1080x1920 portrait LCD panel. The
Flip DS additionally uses a 640x960 portrait LCD panel as a second display.
Add DMI matches to correctly rotate these panels.
Signed-off-by: Andrew Wyatt <fewtarius@steamfork.org> Co-developed-by: John Edwards <uejji@uejji.net> Signed-off-by: John Edwards <uejji@uejji.net> Tested-by: Paco Avelar <pacoavelar@hotmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-3-uejji@uejji.net
Andrew Wyatt [Thu, 13 Feb 2025 22:24:49 +0000 (22:24 +0000)]
drm: panel-orientation-quirks: Add support for AYANEO 2S
AYANEO 2S uses the same panel and orientation as the AYANEO 2.
Update the AYANEO 2 DMI match to also match AYANEO 2S.
Signed-off-by: Andrew Wyatt <fewtarius@steamfork.org> Signed-off-by: John Edwards <uejji@uejji.net> Tested-by: John Edwards <uejji@uejji.net> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250213222455.93533-2-uejji@uejji.net
It is required by firmware to wait up to 2 seconds for pending commands
before sending the destroy hardware context command. After 2 seconds
wait, if there are still pending commands, driver needs to cancel them.
So the context destroy steps need to be:
1. Stop drm scheduler. (drm_sched_entity_destroy)
2. Wait up to 2 seconds for pending commands.
3. Destroy hardware context and cancel the rest pending requests.
4. Wait all jobs associated with the hwctx are freed.
5. Free job resources.
André Almeida [Mon, 27 Jan 2025 19:59:39 +0000 (16:59 -0300)]
drm/atomic: Let drivers decide which planes to async flip
Currently, DRM atomic uAPI allows only primary planes to be flipped
asynchronously. However, each driver might be able to perform async
flips in other different plane types. To enable drivers to set their own
restrictions on which type of plane they can or cannot flip, use the
existing atomic_async_check() from struct drm_plane_helper_funcs to
enhance this flexibility, thus allowing different plane types to be able
to do async flips as well.
Create a new parameter for the atomic_async_check(), `bool flip`. This
parameter is used to distinguish when this function is being called from
a plane update from a full page flip.
In order to prevent regressions and such, we keep the current policy: we
skip the driver check for the primary plane, because it is always
allowed to do async flips on it.
Raag Jadav [Tue, 4 Feb 2025 07:05:27 +0000 (12:35 +0530)]
drm/i915: Use device wedged event
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Raag Jadav [Tue, 4 Feb 2025 07:05:26 +0000 (12:35 +0530)]
drm/xe: Use device wedged event
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place userspace will be notified of wedged device, on
the basis of which, userspace may take respective action to recover
the device.
$ udevadm monitor --property --kernel
monitor will print the received events for:
KERNEL - the kernel uevent
Raag Jadav [Tue, 4 Feb 2025 07:05:25 +0000 (12:35 +0530)]
drm/doc: Document device wedged event
Add documentation for device wedged event in a new "Device wedging"
chapter. This describes basic definitions, prerequisites and consumer
expectations along with an example.
Raag Jadav [Tue, 4 Feb 2025 07:05:24 +0000 (12:35 +0530)]
drm: Introduce device wedged event
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is to provide drivers a generic way to recover the
device with the help of userspace intervention without taking any drastic
measures (like resetting or re-enumerating the full bus, on which the
underlying physical device is sitting) in the driver.
A 'wedged' device is basically a device that is declared dead by the
driver after exhausting all possible attempts to recover it from driver
context. The uevent is the notification that is sent to userspace along
with a hint about what could possibly be attempted to recover the device
from userspace and bring it back to usable state. Different drivers may
have different ideas of a 'wedged' device depending on hardware
implementation of the underlying physical device, and hence the vendor
agnostic nature of the event. It is up to the drivers to decide when they
see the need for device recovery and how they want to recover from the
available methods.
Driver prerequisites
--------------------
The driver, before opting for recovery, needs to make sure that the
'wedged' device doesn't harm the system as a whole by taking care of the
prerequisites. Necessary actions must include disabling DMA to system
memory as well as any communication channels with other devices. Further,
the driver must ensure that all dma_fences are signalled and any device
state that the core kernel might depend on is cleaned up. All existing
mmaps should be invalidated and page faults should be redirected to a
dummy page. Once the event is sent, the device must be kept in 'wedged'
state until the recovery is performed. New accesses to the device
(IOCTLs) should be rejected, preferably with an error code that resembles
the type of failure the device has encountered. This will signify the
reason for wedging, which can be reported to the application if needed.
Recovery
--------
Current implementation defines three recovery methods, out of which,
drivers can use any one, multiple or none. Method(s) of choice will be
sent in the uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in
order of less to more side-effects. If driver is unsure about recovery
or method is unknown (like soft/hard system reboot, firmware flashing,
physical device replacement or any other procedure which can't be
attempted on the fly), ``WEDGED=unknown`` will be sent instead.
Userspace consumers can parse this event and attempt recovery as per the
following expectations.
The only exception to this is ``WEDGED=none``, which signifies that the
device was temporarily 'wedged' at some point but was recovered from driver
context using device specific methods like reset. No explicit recovery is
expected from the consumer in this case, but it can still take additional
steps like gathering telemetry information (devcoredump, syslog). This is
useful because the first hang is usually the most critical one which can
result in consequential hangs or complete wedging.
Consumer prerequisites
----------------------
It is the responsibility of the consumer to make sure that the device or
its resources are not in use by any process before attempting recovery.
With IOCTLs erroring out, all device memory should be unmapped and file
descriptors should be closed to prevent leaks or undefined behaviour. The
idea here is to clear the device of all user context beforehand and set
the stage for a clean recovery.
Although basic recovery is possible with a simple script, consumers can
define custom policies around recovery. For example, if the driver supports
multiple recovery methods, consumers can opt for the suitable one depending
on scenarios like repeat offences or vendor specific failures. Consumers
can also choose to have the device available for debugging or telemetry
collection and base their recovery decision on the findings. This is useful
especially when the driver is unsure about recovery or method is unknown.
v4: s/drm_dev_wedged/drm_dev_wedged_event
Use drm_info() (Jani)
Kernel doc adjustment (Aravind)
v5: Send recovery method with uevent (Lina)
v6: Access wedge_recovery_opts[] using helper function (Jani)
Use snprintf() (Jani)
v7: Convert recovery helpers into regular functions (Andy, Jani)
Aesthetic adjustments (Andy)
Handle invalid recovery method
v8: Allow sending multiple methods with uevent (Lucas, Michal)
static_assert() globally (Andy)
v9: Provide 'none' method for device reset (Christian)
Provide recovery opts using switch cases
v11: Log device reset (André)
In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
from errors by itself. A full restart of the bridge is needed in those
cases to have the bridge output LVDS signals again.
Also, during tests, cases were observed where reading the status of the
bridge was not even possible. Indeed, in those cases, the bridge stops
to acknowledge I2C transactions. Only a full reset of the bridge (power
off/on) brings back the bridge to a functional state.
The TI SN65DSI83 has some error detection capabilities. Introduce an
error recovery mechanism based on this detection.
The errors detected are signaled through an interrupt. On system where
this interrupt is not available, the driver uses a polling monitoring
fallback to check for errors. When an error is present or when reading
the bridge status leads to an I2C failure, the recovery process is
launched.
Restarting the bridge needs to redo the initialization sequence. This
initialization sequence has to be done with the DSI data lanes driven in
LP11 state. In order to do that, the recovery process resets the whole
output path (i.e the path from the encoder to the connector) where the
bridge is located.
José Expósito [Wed, 12 Feb 2025 08:49:12 +0000 (09:49 +0100)]
drm/vkms: Fix use after free and double free on init error
If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.
Fix both possible errors by initializing default_config only when the
driver initialization succeeded.
Reported-by: Louis Chauvet <louis.chauvet@bootlin.com> Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmremann@suse.de> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Dmitry Baryshkov [Thu, 13 Feb 2025 00:49:41 +0000 (02:49 +0200)]
drm: drop i2c subdir from Makefile
The commit 325ba852d148 ("drm/i2c: move TDA998x driver under
drivers/gpu/drm/bridge") deleted the drivers/gpu/drm/i2c/ subdir, but
didn't update upper level Makefile. Drop corresponding line to fix build
issues.
Fixes: 325ba852d148 ("drm/i2c: move TDA998x driver under drivers/gpu/drm/bridge") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20250213113841.7645b74c@canb.auug.org.au Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250213-fix-tda-v1-1-d3d34b2dc907@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Mon, 13 Jan 2025 09:53:46 +0000 (11:53 +0200)]
drm/i2c: move TDA998x driver under drivers/gpu/drm/bridge
TDA998x is the HDMI bridge driver, incorporating drm_connector and
optional drm_encoder (created via the component bind API by the TICLDC
and HDLCD drivers). Thus it should be residing together with the other
DRM bridge drivers under drivers/gpu/drm/bridge/.
Dmitry Baryshkov [Mon, 13 Jan 2025 09:53:45 +0000 (11:53 +0200)]
media: cec: move driver for TDA9950 from drm/i2c
Move the driver for NXP TDA9950 / CEC part of TDA998x together to
drivers/media/i2c, close to other CEC drivers. Specify 'default
DRM_I2C_NXP_TDA998X' in order to simplify migration from old config
files as the Kconfig name has been changed to follow media/cec style.
Dmitry Baryshkov [Mon, 13 Jan 2025 09:53:44 +0000 (11:53 +0200)]
drm/i2c: tda998x: drop support for platform_data
After the commit 0fb2970b4b6b ("drm/armada: remove non-component
support") there are no remaining users of the struct
tda998x_encoder_params. Drop the header and corresponding API from the
TDA998x driver.
Tejas Vipin [Mon, 10 Feb 2025 09:23:42 +0000 (14:53 +0530)]
drm/panel: visionox-r66451: transition to mipi_dsi wrapped functions
Change the visionox-r66451 panel to use multi style functions for
improved error handling. Additionally, always drop LPM flag after
sending init sequence.
Thomas Hellström [Thu, 6 Feb 2025 10:35:44 +0000 (11:35 +0100)]
MAINTAINERS: Add TTM reviewers
Add Matthew Auld and Matthew Brost as TTM reviewers
Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250206103544.36971-1-thomas.hellstrom@linux.intel.com
Stefan Wahren [Sat, 1 Feb 2025 12:50:46 +0000 (13:50 +0100)]
drm/v3d: Add clock handling
Since the initial commit 57692c94dcbe ("drm/v3d: Introduce a new DRM driver
for Broadcom V3D V3.x+") the struct v3d_dev reserved a pointer for
an optional V3D clock. But there wasn't any code, which fetched it.
So add the missing clock handling before accessing any V3D registers.
Philipp Stanner [Tue, 11 Feb 2025 11:14:23 +0000 (12:14 +0100)]
drm/sched: Use struct for drm_sched_init() params
drm_sched_init() has a great many parameters and upcoming new
functionality for the scheduler might add even more. Generally, the
great number of parameters reduces readability and has already caused
one missnaming, addressed in:
commit 6f1cacf4eba7 ("drm/nouveau: Improve variable name in
nouveau_sched_init()").
Introduce a new struct for the scheduler init parameters and port all
users.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Matthew Brost <matthew.brost@intel.com> # for Xe Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> # for Panfrost and Panthor Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> # for Etnaviv Reviewed-by: Frank Binns <frank.binns@imgtec.com> # for Imagination Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> # for Sched Reviewed-by: Maíra Canal <mcanal@igalia.com> # for v3d Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> # for amdxdna Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250211111422.21235-2-phasta@kernel.org
Jinjie Ruan [Wed, 28 Aug 2024 08:49:29 +0000 (16:49 +0800)]
drm: zynqmp_dp: Use devm_platform_ioremap_resource_byname()
platform_get_resource_byname() and devm_ioremap_resource() can be
replaced by devm_platform_ioremap_resource_byname(), which can
simplify the code logic a bit, No functional change here.
Sean Anderson [Fri, 7 Feb 2025 16:25:28 +0000 (11:25 -0500)]
drm: zynqmp_dp: Use scope-based mutex helpers
Convert most mutex_(un)lock calls to use (scoped_)guard instead. This
generally reduces line count and prevents bugs like forgetting to unlock
the mutex. I've left traditional calls in a few places where scoped
helpers would be more verbose. This mostly happens where
debugfs_file_put needs to be called regardless. I looked into defining a
CLASS for debugfs_file, but it seems like more effort than it's worth
since debugfs_file_get can fail.
Bart Van Assche [Fri, 7 Feb 2025 16:25:27 +0000 (11:25 -0500)]
drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()
Instead of attempting the same mutex twice, lock and unlock it.
This bug has been detected by the Clang thread-safety analyzer.
Cc: Sean Anderson <sean.anderson@linux.dev> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: 28edaacb821c ("drm: zynqmp_dp: Add debugfs interface for compliance testing") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250207162528.1651426-2-sean.anderson@linux.dev
Sebastian Reichel [Tue, 11 Feb 2025 01:41:01 +0000 (02:41 +0100)]
drm/edp-panel: Add panel used by T14s Gen6 Snapdragon
The Lenovo Thinkpad T14s Gen6 Snapdragon is currently sold with three
different panel versions: OLED, Low Power IPS or IPS with Touchscreen.
My Low Power IPS version had this panel and the kernel complained
about not knowing any details. I don't have any panel documentation,
but as far as I can see the same timings for the already supported
CSO panel also work for this one.
Thomas Zimmermann [Tue, 4 Feb 2025 13:26:39 +0000 (14:26 +0100)]
drm/ast: astdp: Store mode index in connector state
Look up the mode index for the astdp transmitter ship in the encoder's
atomic check and report an error if the display mode is not supported.
The lookup uses the DRM display mode instead of the driver's internal
VBIOS mode. Both are equivalent. The modesetting code later reads
the calculated index from the connector state to avoid recalculating it.
Thomas Zimmermann [Tue, 4 Feb 2025 13:26:38 +0000 (14:26 +0100)]
drm/ast: astdp: Inline mode-index calculation
Programming the astdp transmitter chip requires a magic value for
individual modes. Inline the helper for calculating the value into
its only caller (i.e., the encoder's atomic_mode_set).
With further refactoring, the atomic check will be able to detect
invalid modes before attempting to program them.
Cristian Ciocaltea [Tue, 4 Feb 2025 17:44:38 +0000 (19:44 +0200)]
drm/bridge: dw-hdmi: Sync comment block with actual bus formats order
Commit d3d6b1bf85ae ("drm: bridge: dw_hdmi: fix preference of RGB modes
over YUV420") changed the order of the output bus formats, but missed to
update accordingly the "Possible output formats" comment section above
dw_hdmi_bridge_atomic_get_output_bus_fmts().
Fix the misleading comment block and a context related typo.
Langyan Ye [Sat, 8 Feb 2025 10:53:26 +0000 (18:53 +0800)]
drm/panel: panel-himax-hx83102: support for starry-2082109qfh040022-50e MIPI-DSI panel
The starry-2082109qfh040022-50e is a 10.95" TFT panel. The MIPI controller
on this panel is the same as the other panels here, so add this panel to
this driver.
Langyan Ye [Sat, 8 Feb 2025 10:53:25 +0000 (18:53 +0800)]
drm/panel: panel-himax-hx83102: support for kingdisplay-kd110n11-51ie MIPI-DSI panel
The kingdisplay-kd110n11-51ie is a 10.95" TFT panel. The MIPI controller
on this panel is the same as the other panels here, so add this panel
to this driver.
Langyan Ye [Sat, 8 Feb 2025 10:53:24 +0000 (18:53 +0800)]
dt-bindings: display: panel: Add KD110N11-51IE and 2082109QFH040022-50E
Add a new compatible for the panels KINGDISPLAY KD110N11-51IE and
STARRY 2082109QFH040022-50E. Both panels use the HX83102 IC, so
add the compatible to the hx83102 bindings file.
Zhaoyu Liu [Sun, 26 Jan 2025 09:32:56 +0000 (17:32 +0800)]
drm/ttm: use ttm_resource_unevictable() to replace pin_count and swapped
TTM always uses pin_count and ttm_resource_is_swapped() together to
determine whether a BO is unevictable.
Now use ttm_resource_unevictable() to replace them.
Tomasz Rusinowicz [Tue, 4 Feb 2025 08:46:20 +0000 (09:46 +0100)]
accel/ivpu: Allow to import single buffer into multiple contexts
Use ivpu_gem_prime_import() based on drm_gem_prime_import_dev()
for importing buffers, removing optimization for same device
imports. This optimization reused the same ivpu_bo object in multiple
contexts but a single buffer can be MMU-mapped only to a single context.
Each import now creates a new instance of ivpu_bo object that shares
the same sg_table but have separate MMU mappings.
Ryosuke Yasuoka [Thu, 6 Feb 2025 10:42:59 +0000 (19:42 +0900)]
drm/virtio: Add drm_panic support
Virtio gpu supports the drm_panic module, which displays a message to
the screen when a kernel panic occurs. It is supported where it has
vmapped shmem BO.
Jocelyn Falempe [Tue, 28 Jan 2025 16:52:10 +0000 (17:52 +0100)]
drm/panic: Better binary encoding in QR code
The current encoding, is done by converting 13bits of input into 4
decimal digits, that are then encoded efficiently using the numeric
encoding of the QR code specification.
The Fido v2.2 specification [1] uses a similar approach for its
QR-initiated authentication. The only difference is that it converts
7 bytes (56bits) of input into 17 decimal digits. The benefit is that
the algorithm doesn't require to split input bytes into 13bits chunk,
and the ratio is a bit better.
This improvement was proposed by Jó Ágila Bitsch in [2].
drm_panic is still young, and the QR code feature is not widely used,
so it's still time to switch to a common algorithm, shared with a
widely used standard.
I also changed the name of the url parameter, from zl= to z=, so the
website can keep backward compatibility if needed.
Adrián Larumbe [Thu, 30 Jan 2025 17:28:13 +0000 (17:28 +0000)]
drm/panthor: Fix race condition when gathering fdinfo group samples
Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to
protect access to groups with an xarray lock, which could lead to
use-after-free errors.
Adrián Larumbe [Thu, 30 Jan 2025 17:28:11 +0000 (17:28 +0000)]
drm/panthor: Expose size of driver internal BO's over fdinfo
This will display the sizes of kenrel BO's bound to an open file, which are
otherwise not exposed to UM through a handle.
The sizes recorded are as follows:
- Per group: suspend buffer, protm-suspend buffer, syncobjcs
- Per queue: ringbuffer, profiling slots, firmware interface
- For all heaps in all heap pools across all VM's bound to an open file,
record size of all heap chuks, and for each pool the gpu_context BO too.
This does not record the size of FW regions, as these aren't bound to a
specific open file and remain active through the whole life of the driver.
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250130172851.941597-4-adrian.larumbe@collabora.com
Adrián Larumbe [Thu, 30 Jan 2025 17:28:10 +0000 (17:28 +0000)]
drm/file: Add fdinfo helper for printing regions with prefix
This is motivated by the desire of some drivers (eg. Panthor) to print the
size of internal memory regions with a prefix that reflects the driver
name, as suggested in the previous documentation commit.
That means adding a new argument to print_size and making it available for
DRM users.
Tvrtko Ursulin [Wed, 5 Feb 2025 11:04:10 +0000 (11:04 +0000)]
drm/scheduler: Remove some unused prototypes
As far as I can tell some removed prototypes were introduced by probably
bad conflict resolution in fc58764bbf60 ("Merge tag 'amd-drm-next-6.2-2022-11-18' of https://gitlab.freedesktop.org/agd5f/linux into drm-next").
Remove them.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@redhat.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <pstanner@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250205110410.7941-1-tvrtko.ursulin@igalia.com
Hermes Wu [Tue, 21 Jan 2025 07:01:51 +0000 (15:01 +0800)]
drm/bridge: it6505: fix HDCP V match check is not performed correctly
Fix a typo where V compare incorrectly compares av[] with av[] itself,
which can result in HDCP failure.
The loop of V compare is expected to iterate for 5 times
which compare V array form av[0][] to av[4][].
It should check loop counter reach the last statement "i == 5"
before return true
Cristian Ciocaltea [Tue, 4 Feb 2025 12:40:06 +0000 (14:40 +0200)]
drm/rockchip: vop2: Improve display modes handling on RK3588 HDMI0
The RK3588 specific implementation is currently quite limited in terms
of handling the full range of display modes supported by the connected
screens, e.g. 2560x1440@75Hz, 2048x1152@60Hz, 1024x768@60Hz are just a
few of them.
Additionally, it doesn't cope well with non-integer refresh rates like
59.94, 29.97, 23.98, etc.
Make use of HDMI0 PHY PLL as a more accurate DCLK source to handle
all display modes up to 4K@60Hz.
Cristian Ciocaltea [Tue, 4 Feb 2025 12:40:05 +0000 (14:40 +0200)]
drm/rockchip: vop2: Drop unnecessary if_pixclk_rate computation
The if_pixclk_rate variable is not being used outside of the if-block in
rk3588_calc_cru_cfg(), hence move the superfluous assignment from the
first branch to the inner comment-block.
Damon Ding [Thu, 6 Feb 2025 03:03:29 +0000 (11:03 +0800)]
dt-bindings: display: rockchip: Fix label name of hdptxphy for RK3588 HDMI TX Controller
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Vignesh Raman [Wed, 5 Feb 2025 08:16:46 +0000 (13:46 +0530)]
drm/ci: uprev mesa
Uprev mesa to adapt to the latest changes in mesa ci
which includes new container jobs and stages. Also update
lava-submit script to adapt to the recent changes in mesa
to use LAVA rootfs overlays.
Paz Zcharya [Wed, 29 Jan 2025 14:20:58 +0000 (14:20 +0000)]
drm/vkms: Add support for ABGR8888 pixel format
Add support for pixel format ABGR8888, which is the default format
on Android devices. This will allow us to use VKMS as the default
display driver in Android Emulator (Cuttlefish) and increase VKMS
adoption.
This message reports a mismatch between new_crtc_state->enable and
has_connectors, which should be either both true or both false. However it
does not mention which one is true and which is false, which can be useful
for debugging. Add the value of both avriables to the log message.
Suraj Kandpal [Wed, 22 Jan 2025 05:33:57 +0000 (11:03 +0530)]
drm/display/dp: Define function to setup Extended wake time
Extended wake timeout request helps to give additional
time by reading the DPCD register through which sink requests the
minimal amount of time required to wake the sink up.
Source device shall keep retying the AUX tansaction till the
extended timeout that is being granted for LTTPRs from the
sink device.
Thomas Zimmermann [Fri, 31 Jan 2025 09:21:16 +0000 (10:21 +0100)]
drm/ast: Only look up VBIOS mode on full modesets
Only look up the VBIOS mode during atomic_check if the display mode
changes. For page flips, the previous settings still apply. Avoids the
runtime overhead of looking up the VBIOS mode on each page flip.
Thomas Zimmermann [Fri, 31 Jan 2025 09:21:15 +0000 (10:21 +0100)]
drm/ast: Remove struct ast_vbios_mode_info
The type struct ast_vbios_mode_info used to store information about
the color format and display mode. It has outlived its purpose. Inline
its fields into struct ast_crtc_state and replace all instances.
Thomas Zimmermann [Fri, 31 Jan 2025 09:21:14 +0000 (10:21 +0100)]
drm/ast: astdp: Look up mode index from table
Replace the large switch statement with a look-up table when selecting
the mode index. Makes the code easier to read. The table is sorted by
resolutions; if run-time overhead from traversal becomes significant,
binary search would be a possible optimization.
The mode index requires a refresh-rate index to be added or subtracted,
which still requires a minimal switch. In the original code, some of
the indices did not contain this computation. Those cases would have been
equivalent to adding 0, so they are now all subsumed in the switch's
default branch.
Thomas Zimmermann [Fri, 31 Jan 2025 09:21:13 +0000 (10:21 +0100)]
drm/ast: astdp: Rework display-mode setting
ASTDP requires a mode index, depending on the resolution. Move the
look-up code from ast_dp_set_mode() into a separate helper. Inline
the rest of the function into its only caller. Rename the variable
names and register constants to match the programming manual.
As before, the mode-index lookup still happens during the update's
atomic commit. Right now, there's no way of doing it during the atomic
check. The lookup requires the VBIOS mode, which is not available at
the atomic check's invocation. At least warn now if the mode index
could not be found.
Thomas Zimmermann [Fri, 31 Jan 2025 09:21:11 +0000 (10:21 +0100)]
drm/ast: Validate DRM display modes against VBIOS modes
Test DRM display modes against the list of modes supported by the
VBIOS. The helper will respect the supported-modes flags in struct
ast_device. Hence only DRM display modes supported by the VBIOS
will be reported; without the current duplication of this information.
projects / users / jedix / linux-maple.git / log