While discussing cgroups we noticed a problem where you could export
a BO to a dma-buf without having it ever being backed or accounted for.
This meant in low memory situations or eventually with cgroups, a
lower privledged process might cause the compositor to try and allocate
a lot of memory on it's behalf and this could fail. At least make
sure the exporter has managed to allocate the RAM at least once
before exporting the object.
This only applies currently to TTM_PL_SYSTEM objects, because
GTT objects get populated on first validate, and VRAM doesn't
use TT.
Reviewed-by: Christian Koenig <christian.koenig@amd.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250904021643.2050497-1-airlied@gmail.com
On systems with multiple GPUs there can be uncertainty which GPU is the
primary one used to drive the display at bootup. In some desktop
environments this can lead to increased power consumption because
secondary GPUs may be used for rendering and never go to a low power
state. In order to disambiguate this add a new sysfs attribute
'boot_display' that uses the output of video_is_primary_device() to
populate whether the PCI device was used for driving the display.
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/issues/23
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250811162606.587759-5-superm1@kernel.org
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
On systems with non VGA GPUs fbcon can't find the primary GPU because
video_is_primary_device() only checks the VGA arbiter.
Add a screen info check to video_is_primary_device() so that callers
can get accurate data on such systems.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250811162606.587759-4-superm1@kernel.org
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
vga_is_firmware_default() checks firmware resources to find the owner
framebuffer resources to find the firmware PCI device. This is an
open coded implementation of screen_info_pci_dev(). Switch to using
screen_info_pci_dev() instead.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250811162606.587759-3-superm1@kernel.org
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
When compiled without CONFIG_VIDEO the architecture specific
implementations of video_is_primary_device() include prototypes and
assume that video-common.c will be linked. Guard against this so that the
fallback inline implementation that returns false will be used when
compiled without CONFIG_VIDEO.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506221312.49Fy1aNA-lkp@intel.com/
Link: https://lore.kernel.org/r/20250811162606.587759-2-superm1@kernel.org
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Remove myself from the intel_vpu driver maintainer list as I'm
moving to another company. Time to let someone else deal with
the NPU bugs while I pretend to know what I'm doing elsewhere!
Thanks to everyone for the great collaboration (and for putting up
with my creative interpretations of what "minor fixes" means).
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://lore.kernel.org/r/20250910085526.230458-1-jacek.lawrynowicz@linux.intel.com
IT6263 supports HDMI vendor specific infoframe. The infoframe header
and payload are configurable via NULL packet registers. The infoframe
is enabled and disabled via PKT_NULL_CTRL register. Add the HDMI vendor
specific infoframe support.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-it6263-vendor-specific-infoframe-v2-1-3f2ebd9135ad@nxp.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Instead of writing the first byte of the infoframe (and hoping that the
rest is default / zeroes), hook Audio InfoFrame support into the
write_infoframe / clear_infoframes callbacks and use
drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the
frame.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Instead of disabling and then reenabling AVI infoframe, use the
recommended way of updating it on the fly: latch current values using
the ADV7511_REG_INFOFRAME_UPDATE register.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-1-05b24459b9a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Gma500 unnecessarily clears the framebuffer's GEM-object pointer
before calling drm_framebuffer_cleanup(). Remove this code to make
gma500 consistent with the rest of the drivers.
The change is cosmetic, as drm_framebuffer_cleanup() does not
touch the object pointer on gma500.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://lore.kernel.org/r/20250904121157.395128-1-tzimmermann@suse.de
The Realtek RTD2171 chipset is a transparent DisplayPort 1.4 to
HDMI 2.0 bridge.
This chipset is usually found in USB-C To HDMI Adapters and Docks,
or laptops to provide HDMI display output.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250908-topic-x1e80100-hdmi-v3-1-c53b0f2bc2fb@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The DRM subsystem has a set of preferred, prefixed logging functions
(drm_info, drm_warn, drm_err) which improve debuggability by including
the driver and function name in the log output.
As part of the ongoing effort to modernize logging calls,
convert a dev_err() call in the bochs hardware initialization
function to its drm_err() equivalent.
This work was suggested by the DRM TODO list.
Signed-off-by: Leander Kieweg <kieweg.leander@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250818113530.187440-1-kieweg.leander@gmail.com
Implement support for DSI command transfer. Transmission of both Short
Packet and Long Packet is implemented, so is command transmission to
request response from peripheral device and transmission of non-read
command with BTA.
The AXI memory access mode is currently not implemented, each transfer
is performed purely using controller register interface. Short Packet
transfer can transfer up to 2 Bytes of data, Long Packet transfer can
transfer up to 16 Bytes of data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://lore.kernel.org/r/20250831190507.327848-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Convert the Renesas R-Car Display Unit LVDS driver from
SET_RUNTIME_PM_OPS() to RUNTIME_PM_OPS(), and pm_ptr(). This reduces
kernel size in case CONFIG_PM is disabled. While DRM_RCAR_LVDS depends
on PM, the code may still serve as an example for new drivers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/2264ff4f21a7e17384822e0efba176cf78ae184d.1756999823.git.geert+renesas@glider.be
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The callback functions for line conversion are almost identical for
semi-planar formats. The generic READ_LINE_YUV_SEMIPLANAR macro
generate all the required boilerplate to process a line from a
semi-planar format.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-7-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-6-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The formats XRGB16161616 and ARGB16161616 were already supported.
Add the support for:
- ABGR16161616
- XBGR16161616
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-3-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The formats XRGB8888 and ARGB8888 were already supported. Add the
support for:
- XBGR8888
- ABGR8888
- RGBA8888
- BGRA8888
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-2-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The callback functions for line conversion are almost identical for
some format. The generic READ_LINE macro generate all the required
boilerplate to process a line.
Two overrides of this macro have been added to avoid duplication of
the same arguments every time.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Link: https://lore.kernel.org/r/20250703-b4-new-color-formats-v7-1-15fd8fd2e15c@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
The 'bridge' pointer started being assigned and used within this 'if' scope
in commit 0beba3f9d3 ("drm/bridge: connector: add support for HDMI codec
framework").
After that, commit 5d04b41889 ("drm/bridge: split HDMI Audio from
DRM_BRIDGE_OP_HDMI") removed the code dereferencing it from the same 'if'
scope, but did not remove the assignment.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20250808-drm-bridge-alloc-getput-for_each_bridge-v2-2-edb6ee81edf1@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Introduce a DRM driver for the Mayqueen Pixpaper e-ink display panel,
which is controlled via SPI. The driver supports a 122x250 resolution
display with XRGB8888 format.
Also, add a MAINTAINERS entry for the Pixpaper driver.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250902-drm-v5-3-d77c678c4ae3@gmail.com
The binding is for the Mayqueen Pixpaper e-ink display panel,
controlled via an SPI interface.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250902-drm-v5-2-d77c678c4ae3@gmail.com
Mayqueen is a Taiwan-based company primarily focused on the development
of arm64 development boards and e-paper displays.
Signed-off-by: Wig Cheng <onlywig@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250902-drm-v5-1-d77c678c4ae3@gmail.com
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250905073712.3791260-1-nichen@iscas.ac.cn
For ternary operators in the form of "a ? true : false", if 'a' itself
returns a boolean result, the ternary operator can be omitted. Remove
redundant ternary operators to clean up the code.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Acked-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
Link: https://lore.kernel.org/r/20250904112738.350652-1-liaoyuanhong@vivo.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Since commit 03fa454bb6 ("drm/panel: lvds: Simplify mode parsing"),
the width and height members of struct panel_lvds are no longer used.
Remove them. No functional change.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Link: https://lore.kernel.org/r/20250829-panel-lvds-remove-width-height-v1-1-acecf0c84dc4@nxp.com
I recently left AMD and would like to continue participating in
the review and maintenance of the XDNA driver using my personal
email address.
Signed-off-by: Min Ma <mamin506@gmail.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/20250831001228.592-1-mamin506@gmail.com
When no other driver selects CONFIG_VIDEOMODE_HELPERS but
CONFIG_DRM_CDNS_DSI is enabled, there is a linker or modpost error:
ERROR: modpost: "drm_display_mode_to_videomode" [drivers/gpu/drm/bridge/cadence/cdns-dsi.ko] undefined!
Select VIDEOMODE_HELPERS to ensure that this helper function is
available to the driver.
Fixes: ce4bc5ca7c ("drm/bridge: cdns-dsi: Use video mode and clean up cdns_dsi_mode2cfg()")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250821-cdns-videohelpers-v1-1-853e021908cf@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Add interface for applications to get information array. The application
provides a buffer pointer along with information type, maximum number of
entries and maximum size of each entry. The buffer may also contain match
conditions based on the information type. After the ioctl completes, the
actual number of entries and entry size are returned. (see [1], used by
driver runtime library)
[1] https://github.com/amd/xdna-driver/blob/main/src/shim/host/platform_host.cpp#L337
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://lore.kernel.org/r/20250903053402.2103196-1-lizhi.hou@amd.com
The AST_DRAM_ constants belong together, so put them in an enum
type. Rename type and variables to 'drm_layout', as there's already
another DRAM type in the ast driver (AST_DDR2, AST_DDR3).
v2:
- avoid compiler warning with switch default (Dan)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-7-tzimmermann@suse.de
The only place in the ast driver that uses the DRAM type is the
P2A DRAM initialization for Gen2 and Gen3 of the chip. Condense
the code in ast_get_dram_info() to exactly this use case and move
it into the Gen's custom source file. Remove the field dram_type
from struct ast_device.
The AST_DRAM_ constants are also used in Gen4 POST helpers, but
independently from the dram_type field. No changes there.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-6-tzimmermann@suse.de
The ast driver used SCU-MPLL and SCU-STRAP to compute the memory
clock. Remove the now unused values.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-5-tzimmermann@suse.de
The memory clock is not necessary for the driver. In default for
AST2600 is event incorrect; should be 800 MHz. Remove it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-4-tzimmermann@suse.de
Most of the information in the DRAM status output is irrelevant; some
is even wrong. Only the DRAM type is used on some older models. Drop
the output entirely.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-2-tzimmermann@suse.de
The declaration of pointer crtc_state includes an assignment to
crtc_state. The double assignment of crtc_state is redundant and
can be removed.
Fixes: 061963cd9e ("drm/sysfb: Blit to CRTC destination format")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250903083106.2703580-1-colin.i.king@gmail.com
Instead of using the "sha1" crypto_shash, simply call the sha1() library
function. This is simpler and faster.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20250821175613.14717-1-ebiggers@kernel.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Currently, when a panel brightness quirk is applied, there is no log
indicating that a quirk was applied. Unwrap the drm device on its own
and use drm_info() to log when a quirk is applied.
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-7-lkml@antheas.dev
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
(Correct a missing -1 in the message math)
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
enabling it universally is reasonable. However, it causes issues in
certain devices. Therefore, introduce it just for the Steam Deck here.
SteamOS kernel does not have a public mirror, but this replaces commit
806dd74bb225 ("amd/drm: override backlight min value from 12 -> 0")
in the latest, as of this writing, SteamOS kernel (6.11.11-valve24).
See unofficial mirror reconstructed from sources below.
Link: https://gitlab.com/evlaV/linux-integration/-/commit/806dd74bb225
Reviewed-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-6-lkml@antheas.dev
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again.
Below are some examples. This was found by iterating over brighness
ranges while printing DP_SOURCE_BACKLIGHT_LEVEL. It was found that
the screen would malfunction on specific values, and some of them
were collected.
Therefore, introduce a quirk where the minor byte of brightness is
OR'd with 0x03 to avoid the range of invalid values.
This quirk was tested by removing the workarounds and iterating
from 0 to 50_000 value ranges with a cadence of 0.2s/it. The
range of the panel is 1000...400_000, so the values were slightly
interpolated during testing. The custom brightness curve added on
6.15 was disabled.
86016: 10101000000000000
86272: 10101000100000000
87808: 10101011100000000
251648: 111101011100000000
251649: 111101011100000001
86144: 10101000010000000
87809: 10101011100000001
251650: 111101011100000010
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3803
Tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-5-lkml@antheas.dev
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Using a single DMI match only allows matching per manufacturer.
Introduce a second optional match to allow matching make/model.
In addition, make DMI optional to allow matching only by EDID.
Tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-4-lkml@antheas.dev
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Currently, the brightness quirk is limited to minimum brightness only.
Refactor it to a structure, so that more quirks can be added in the
future. Reserve 0 value for "no quirk", and use u16 to allow minimum
brightness up to 255.
Tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-3-lkml@antheas.dev
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Currently, having a valid panel_id match is required to use the quirk
system. For certain devices, we know that all SKUs need a certain quirk.
Therefore, allow not specifying ident by only checking for a match
if panel_id is non-zero.
Tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250829145541.512671-2-lkml@antheas.dev
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
