Mailbox properties are optional in the remoteproc xlnx bindings.
If mailbox properties are not found in device-tree it's not fatal error
in the driver. Driver will print warning messages and continue with
normal operation. However, these warning messages can be interpreted as
error. Check "mboxes" and "mbox-names" properties in the driver and setup
mailbox only if they are available in the device-tree.
This will avoid any unwanted warning/error messages.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20260303235127.2317955-2-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
A copy-paste of a similar issue fixed by Peter Collingbourne in:
https://lore.kernel.org/linux-perf-users/20260304190613.2507582-1-pcc@google.com/
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Justin Stitt <justinstitt@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If the cpuidle governor .select() callback is skipped because there
is only one idle state in the cpuidle driver, the .reflect() callback
should be skipped as well, at least for consistency (if not for
correctness), so do it.
Fixes: e5c9ffc6ae ("cpuidle: Skip governor when only one idle state is available")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://patch.msgid.link/12857700.O9o76ZdvQC@rafael.j.wysocki
The vga_get_uninterruptible() function can return an error if it fails to
set up VGA decoding for the requested device.
If VGA decoding is unavailable, we don't need to be careful to leave the
VGA emulation in a usable state, as vgacon will also be unable to get
access later on, so just skip over the VGA accesses and the vga_put() call
matching the failed vga_get_uninterruptible().
Signed-off-by: Simon Richter <Simon.Richter@hogyros.de>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260306151347.758836-1-Simon.Richter@hogyros.de
During online processing for a DASD device an IO operation is started to
determine the format of the device. CDL format contains specifically
sized blocks at the beginning of the disk.
For a PPRC secondary device no real IO operation is possible therefore
this IO request can not be started and this step is skipped for online
processing of secondary devices. This is generally fine since the
secondary is a copy of the primary device.
In case of an additional partition detection that is run after a swap
operation the format information is needed to properly drive partition
detection IO.
Currently the information is not passed leading to IO errors during
partition detection and a wrongly detected partition table which in turn
might lead to data corruption on the disk with the wrong partition table.
Fix by passing the format information from primary to secondary device.
Fixes: 413862caad ("s390/dasd: add copy pair swap capability")
Cc: stable@vger.kernel.org #6.1
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Acked-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Link: https://patch.msgid.link/20260310142330.4080106-3-sth@linux.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Quiesce and resume is a mechanism to suspend operations on DASD devices.
In the context of a controlled copy pair swap operation, the quiesce
operation is usually issued before the actual swap and a resume
afterwards.
During the swap operation, the underlying device is exchanged. Therefore,
the quiesce flag must be moved to the secondary device to ensure a
consistent quiesce state after the swap.
The secondary device itself cannot be suspended separately because there
is no separate block device representation for it.
Fixes: 413862caad ("s390/dasd: add copy pair swap capability")
Cc: stable@vger.kernel.org #6.1
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Link: https://patch.msgid.link/20260310142330.4080106-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The hashmap__new() function never returns NULL, it returns error
pointers. Fix the error checking to match.
Additionally, set ftrace->profile_hash to NULL on error, and return the
exact error code from hashmap__new().
Fixes: 0f223813ed ("perf ftrace: Add 'profile' command")
Suggested-by: Ian Rogers <irogers@google.com>
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Rework the way that kernel log messages are rate-limited or suppressed
while running the cs_dsp KUnit tests.
Under normal conditions cs_dsp doesn't produce an unreasonable number of
log messages, and state changes are relatively infrequent. But the KUnit
tests run through a very large number of test cases, especially error
cases, and this produces an unusually large amount of log output from
cs_dsp.
The original fix for this in commit 10db9f6899 ("firmware: cs_dsp:
rate-limit log messages in KUnit builds") was effective but not pretty.
It involved different definitions of the log macros for KUnit and
not-KUnit builds, and exported variables for the KUnit tests to disable
log messages. I would have preferred to turn the log macros into real
functions that can contain a KUNIT_STATIC_STUB_REDIRECT(), but the
dev_xxx() macros don't have a version that take va_args, so they can't
be wrapped by a function.
This patch enables the use of a KUNIT_STATIC_STUB_REDIRECT() instead
of exported variables, and avoids the need for different definitions of
the debug macros in KUnit and not-KUnit builds.
- A new function cs_dsp_can_emit_message() returns true if the
messages can be emitted to the kernel log. In a normal not-KUnit build
this function collapses to simply returning true. In KUnit builds it
will rate-limit output, and this uses a single static rate limiter so
it limits the overall rate across all cs_dsp log messages. The KUnit
test can redirect it to change the suppression behavior.
- The cs_dsp debug message macros are changed to only call the dev_xxx()
if cs_dsp_can_emit_message() returns true. These are still macros so
there is no problem wrapping the dev_xxx(). For a normal not-KUnit
build cs_dsp_can_emit_message() always returns true so these macros
simplify down to being identical to calling dev_xxx() directly.
- The KUnit tests that cause a lot of cs_dsp messages now redirect
cs_dsp_can_emit_message() to a local function. This returns false
to suppress cs_dsp messages, unless DEBUG is defined for that test.
I have checked that for a x86_64 production (non-KUnit) build the
disassembled cs_dsp.o is identical to what was generated from the
original code. So the complier is correctly simplifying the
cs_dsp_can_emit_message() and macros down to only the call to dev_xxx().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310130343.1791951-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The pcm_id value is __le32 so convert it before passing to the dev_dbg
function to be printed. Also fixup some other uses of __le32 data and
a couple of places where %u should have been used instead of %d
Picked up by sparse prototype for variadic and printf
function checking. Fixes a large number of sparse warnings, such as:
sound/soc/sof/pcm.c:84:25: warning: incorrect type in argument 4 (different base types)
sound/soc/sof/pcm.c:84:25: expected unsigned int
sound/soc/sof/pcm.c:84:25: got restricted __le32 [usertype] pcm_id
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260310125106.178944-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
In wm_adsp_request_firmware_files() squash the if (system_name && suffix)
and the following if (system_name) blocks together. This removes some
duplicated code.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-11-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bundle the pointers to struct firmware and its filename into a new
struct wm_adsp_fw_files. This simplifies passing these pointers around.
Changes are also needed to the test cases in wm_adsp_fw_find_test.c that
use this API.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-10-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't preserve '/' in firmware filename fields - convert it to '-' like
other punctuation characters.
The code originally normalized the entire string, including the
directory prefix. To prevent breaking the directory it had to preserve
'/' characters in the name, but this meant that the system name and ALSA
prefix must not contain those characters.
It's trivial to skip the directory name prefix and start the
normalization after it, and that means the normalization does not need
to make a special case for '/'.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use a consistent pattern of error checking in
wm_adsp_request_firmware_files().
- The integer return value of wm_adsp_request_firmware_file() reports
unrecoverable errors, for example -ENOMEM.
- A NULL struct firmware pointer is a valid result. This not an error,
not all DSPs require both files, some may not require any files.
Previously wm_adsp_request_firmware_files() was using a mix of checking
the return value and checking the struct firmware pointer to determine
whether a file was found. It wasn't checking for unrecoverable errors.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The 3rd search case in wm_adsp_request_firmware_files() does exactly the
same bin file searches as the case immediately above it. Merge the
conditional from the 3rd case into the second case so the duplicated code
can be removed.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add KUnit testing of the wm_adsp code that searches for firmware files.
Also make the SND_SOC_WM_ADSP Kconfig symbol visible if KUNIT is enabled
so that wm_adsp can be manually included for KUnit testing.
The firmware filename is composed of several fields, some of which are
optional, and there is a search algorithm to fallback from specific to
generic versions of firmware for a device. This KUnit test verifies that
wm_adsp is searching for the correct sequence of filenames.
The are two ways of testing this, and both are used in this KUnit test.
1. Trap the calls to firmware_request_nowarn() and test that the sequence
of filenames request is correct.
This is the most thorough test because it proves that exactly the
expected filenames are requested, in the correct order.
But it doesn't fully cover regression testing. If a change to the search
algorithm changes the expected sequence of requested files, the test
must also be changed to expect that new sequence. If the expectation is
wrong, the tests can pass (because the search order is as expected)
while picking a different file in some cases from what it did before the
change.
2. Test which file is picked from a simulated directory of files.
This is better for regression testing because it is independent of the
search algorithm. It does not need to change if the search algorithm
changes. It is not testing exactly which files the algorithm searches
for, only which file it eventually picks from a given set of available
files.
In other words, the regression test is: does it still pick the same file
from the same directory of files?
But it is impractical for thorough testing. It doesn't prove that
exactly the correct files were searched for, unless it was to test with
every possible combination of file names and directory content that
could ever exist. Clearly this is impossible to implement, since the
number of combations of possible valid filenames in a directory and
number of files in a directory is astronomically large.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make some of the firmware file search functions redirectable for KUnit
testing.
- The call to firmware_request_nowarn() is factored out into a wrapper
function so that it can be redirected.
- wm_adsp_request_firmware_files() and wm_adsp_release_firmware_files()
are made visible and exported if KUNIT is enabled.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310141817.1871794-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
An incorrect device name was logged for PCA9452 because the dev_info()
ternary omitted PCA9452 and fell through to "pca9450bc". Introduce a
type_name and set it per device type so the probed message matches the
actual PMIC. While here, make the PCA9451A case explicit.
No functional changes.
Fixes: 017b76fb8e ("regulator: pca9450: Add PMIC pca9452 support")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260310-pca9450-irq-v1-2-36adf52c2c55@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Kernel warning on i.MX8MP-EVK when doing module test:
irq: type mismatch, failed to map hwirq-3 for gpio@30200000!
Per PCA945[X] specification: The IRQ_B pin is pulled low when any unmasked
interrupt bit status is changed and it is released high once application
processor read INT1 register.
So the interrupt should be configured as IRQF_TRIGGER_LOW, not
IRQF_TRIGGER_FALLING.
Fixes: 0935ff5f1f ("regulator: pca9450: add pca9450 pmic driver")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260310-pca9450-irq-v1-1-36adf52c2c55@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The move of the AHB and APB clocks from a JH7110 specific quirk to the
main clock init dropped the specification of the clock names to request
for the AHB and APB clocks, resulting in the clock framework requesting
a clock with a NULL name three times. On most platforms where the
clocks are physically the same or some are always on this makes no
difference but the reason we had the specific quirk for JH7110 is that
it does actually have separate, controllable clocks. Update the new
code to request the AHB and APB clocks by name to restore the original
behaviour on JH7110.
Fixes: 324ecc7788 ("spi: cadence-qspi: Kill cqspi_jh7110_clk_init")
Reported-by: Ron Economos <re@w6rz.net>
Closes: https://lore.kernel.org/r/a3ca5e9b-7446-497e-8df2-7ef2b42a02e9@w6rz.net
Tested-by: Ron Economos <re@w6rz.net>
Link: https://patch.msgid.link/20260307-spi-cadence-qspi-fix-jh7110-v1-1-c9f37b8c58b1@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260307-spi-cadence-qspi-fix-jh7110-v1-1-c9f37b8c58b1@kernel.org
-----BEGIN PGP SIGNATURE-----
iIkEABYKADEWIQSl+MghEFFAdY3pYJLMOmT6rpmt0gUCaa/u1RMcbWtsQHBlbmd1
dHJvbml4LmRlAAoJEMw6ZPquma3SmsABAJR3wGHrBuQ5QmhLPSmDKsNPMM2so9v9
AW4bGswHf+ReAP99CKH9aNvEIm43/Ap55lTLMhuBEKyYMS1e6SXFN572Dw==
=nBZ9
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-7.0-20260310' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2026-03-10
this is a pull request of 2 patches for net/main.
Haibo Chen's patch fixes the maximum allowed bit rate error, which was
broken in v6.19.
Wenyuan Li contributes a patch for the hi311x driver that adds missing
error checking in the caller of the hi3110_power_enable() function,
hi3110_open().
linux-can-fixes-for-7.0-20260310
* tag 'linux-can-fixes-for-7.0-20260310' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: hi311x: hi3110_open(): add check for hi3110_power_enable() return value
can: dev: keep the max bitrate error at 5%
====================
Link: https://patch.msgid.link/20260310103547.2299403-1-mkl@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit 02c057ddef ("ACPI: video: Convert the driver to a platform one")
switched over the ACPI video bus driver from an ACPI driver to a platform
driver, but that change introduced an unwanted and unexpected side effect.
Namely, on some systems, the ACPI device object of the ACPI video bus
device is an ACPI companion of multiple platform devices and, after
adding video_device_ids[] as an acpi_match_table to the acpi_video_bus
platform driver, all of those devices started to match that driver and
its probe callback is invoked for all of them (it fails, but it leaves
a confusing message in the log). Moreover, the MODULE_DEVICE_TABLE()
of the ACPI video driver module matches all of the devices sharing the
ACPI companion with the ACPI video bus device.
To address this, make the core ACPI device enumeration code create an
auxiliary device for the ACPI video bus device object instead of a
platform device and switch over the ACPI video bus driver (once more)
to an auxiliary driver.
Auxiliary driver generally is a better match for ACPI video bus than
platform driver, among other things because the ACPI video bus device
does not require any resources to be allocated for it during
enumeration. It also allows the ACPI video bus driver to stop abusing
device matching based on ACPI device IDs and it allows a special case
to be dropped from acpi_create_platform_device() because that function
need not worry about the ACPI video bus device any more.
Fixes: 02c057ddef ("ACPI: video: Convert the driver to a platform one")
Reported-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Closes: https://lore.kernel.org/linux-acpi/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/
Tested-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Added AUXILIARY_BUS selection to CONFIG_ACPI to fix build issue ]
[ rjw: Fixed error path in acpi_create_video_bus_device() ]
Link: https://patch.msgid.link/5986516.DvuYhMxLoT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The transmitter and receiver implement separate timestamp counters and
bit counters. The bit counter increments at the end of each bit in a
frame whenever the transmitter or receiver is enabled. The bit counter
can be reset by software. The timestamp counter increments on the bus
interface clock whenever it is enabled. The current value of the
timestamp counter is latched whenever the bit counter increments.
Reading the bit counter register will cause the latched timestamp
value to be saved in the bit counter timestamp register. The timestamp
counter can be reset by software, this also resets the latched timestamp
value and the bit counter timestamp register.
The timestamp counter and bit counter can be used by software to track
the progress of the transmitter and receiver. It can also be used to
calculate the relative frequency of the bit clock against the bus
interface clock.
As there are three regmap handlers defined in this driver, explicitly
call the snd_soc_component_init_regmap() to init regmap handler for the
component.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-4-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The transmitter and receiver implement separate timestamp counters and
bit counters. The bit counter increments at the end of each bit in a
frame whenever the transmitter or receiver is enabled. The bit counter
can be reset by software. The timestamp counter increments on the bus
interface clock whenever it is enabled. The current value of the
timestamp counter is latched whenever the bit counter increments.
Reading the bit counter register will cause the latched timestamp
value to be saved in the bit counter timestamp register. The timestamp
counter can be reset by software, this also resets the latched timestamp
value and the bit counter timestamp register.
The timestamp counter and bit counter can be used by software to track
the progress of the transmitter and receiver. It can also be used to
calculate the relative frequency of the bit clock against the bus
interface clock.
These bitcount and timestamp registers are volatile, and supported when
the module has timestamp features.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-3-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are some registers which are volatile, at pm runtime suspend state,
the regmap cache only is enabled, regmap will return -EBUSY when trying to
access these registers.
static int _regmap_read(struct regmap *map, unsigned int reg,
unsigned int *val)
{
int ret;
void *context = _regmap_map_get_context(map);
if (!map->cache_bypass) {
ret = regcache_read(map, reg, val);
if (ret == 0)
return 0;
}
if (map->cache_only)
return -EBUSY;
if (!regmap_readable(map, reg))
return -EIO;
When exporting these registers by amixer interface to user space, there
will be -EBUSY errors in mixer-test when the cpu dai is in idle. In order
to avoid such error, needs to define FSL own functions to take a pm
runtime reference before calling snd_soc_get_xr_sx(),
snd_soc_get_enum_double(), snd_soc_get_volsw(), and so on.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260310104235.1234569-2-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Similar to i915's commit cebc13de7e
("drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access"), except
that instead of putting the register on the allowlist for UMD to
program, the KMD is doing the programming at context initialization
based on a queue creation flag.
This is a recommended tuning setting for both gen12 and Xe_HP
platforms.
If a render queue is created with
DRM_XE_EXEC_QUEUE_SET_STATE_CACHE_PERF_FIX, COMMON_SLICE_CHICKEN3 will
be programmed at initialization to enable the render color cache to
key with BTP+BTI (binding table pool + binding table entry) instead of
just BTI (binding table entry). This enables the UMD to avoid emitting
render-target-cache-flush + stall-at-pixel-scoreboard every time a
binding table entry pointing to a render target is changed.
v2: Use xe_lrc_write_ring()
v3: Update xe_query.c to report availability
v4: Rename defines to add DISABLE_
v5: update commit message
v6: rebase
Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39982
Bspec: 73993, 73994, 72161, 31870, 68331
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patch.msgid.link/20260306075504.1288676-1-lionel.g.landwerlin@intel.com
For code readability the bindings are expected to follow order shown in
example-schema.yaml - put the additionalProperties/unevaluatedProperties
entry at the end, after listing all required properties and possible
"allOf:if:then:" conditions. Meaning of this style is to close the
schema, after listing what it contains, with final "nothing more is
allowed".
Move the code around adjusting it to coding style. No functional
impact.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260306-dt-bindings-display-panel-clean-v1-4-3086eda1efaf@oss.qualcomm.com
The purpose of common schemas, like panel-common.yaml, is to list
applicable properties. It can list common ABI, e.g. "label" property,
and pure hardware related properties like power supply or GPIOs. In the
second case it means that all panels have these supplies or GPIOs.
This is the only meaning when hardware property is allowed in common
schema, because bindings are precise and we do not define common schemas
for "possible" hardware configurations.
Following this, all panel bindings which reference common schema and use
"unevaluatedProperties: false" do not need to list these common parts.
Simplify such bindings to also reduce copy-paste code and review time
for new contributions.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260306-dt-bindings-display-panel-clean-v1-3-3086eda1efaf@oss.qualcomm.com
This MIPI-DSI LCD panel must be connected to something. According to
scarce web data it supports two channels and it is already used like
this in DTS. Reported by dtbs_check:
rockchip/rk3399-gru-scarlet-inx.dtb: panel@0 (innolux,p097pfg): 'ports' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260306-dt-bindings-display-panel-clean-v1-2-3086eda1efaf@oss.qualcomm.com
This MIPI-DSI LCD panel must be connected to something, thus add missing
port property, already used in DTS. Reported by dtbs_check:
qcom/msm8916-samsung-gt58.dtb: panel@0 (samsung,lsl080al03): 'port' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260306-dt-bindings-display-panel-clean-v1-1-3086eda1efaf@oss.qualcomm.com
Add support for the DSI LCD panel module found in Motorola Atrix 4G or
Droid X2 smartphones. Exact panel vendor and model are unknown hence panel
uses generic compatible based on board where it is used. The panel has a
540x960 resolution with 24 bit RGB per pixel.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260223064630.12720-3-clamor95@gmail.com
Atrix 4G and Droid X2 are based on a board called by Motorola "Mot" and
use the same 540x960 DSI video mode panel. Exact panel vendor and model
are unknown hence generic compatible based on board name "Mot" is used.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260223064630.12720-2-clamor95@gmail.com
Add the compatible for the NT37700F panel found on the Pixel 3a XL.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260310002606.16413-3-mailingradian@gmail.com
The Pixel 3a XL is code-named by Google as "bonito". The
google,bonito-tianma compatible represents a variant of the Pixel 3a XL
board with a Tianma/Novatek NT37700F panel. Document the google,bonito
board compatible and the google,bonito-tianma variant in the bindings.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260310002606.16413-2-mailingradian@gmail.com
The Jadard jd9365da-h3 driver already allows DRM to get the panel
orientation via the device tree rotation property (described in
panel-common.yaml), but it's currently not documented.
Describe it in the driver documentation to fix a dtbs_check error in
Xiaomi Mi Smart Clock x04g, where the panel is landscape-oriented.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260309180353.8220-1-l.scorcia@gmail.com
Add WaveShare 13.3inch 1920x1080 DSI Capacitive Touch Display support.
While the panel is described as DPI panel, it is part of a larger unit
in non-removable metal casing, so the actual internal configuration is
not known. The panel is attached to "waveshare,dsi2dpi" bridge via DT.
It is likely that internally, this panel is an LVDS panel, connected to
ICN6211 DSI-to-DPI bridge and then another unknown DPI-to-LVDS bridge.
Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260117005028.126361-1-marek.vasut+renesas@mailbox.org
All of these GPIO calls are in process context where they can sleep.
Use the appropriate function call to allow use of this driver with GPIO
controllers that might sleep.
Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260303152124.187791-1-jkeeping@inmusicbrands.com
The taiguan-xti05101-01a is a 10.1" TFT panel. The MIPI controller on this
panel is the same as the other panels here, so add this panel to this
driver.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260214085409.3489057-4-yelangyan@huaqin.corp-partner.google.com
Add a new compatible for the panel TAIGUAN XTI05101-01A. This panel uses
JD9365DA-H3 IC, so add the compatible to the jd9365da-h3 binding files.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260214085409.3489057-3-yelangyan@huaqin.corp-partner.google.com
Add the "taiguanck" vendor prefix for Shenzhen Top Group Technology Co., Ltd.
The prefix is derived from the vendor's website domain:
www.taiguanck.com/en/, which uses "taiguanck" as the primary
identifier of the company.
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260214085409.3489057-2-yelangyan@huaqin.corp-partner.google.com
The LXD M9189A panel is based on the EK79007AD3 DSI display controller.
It currently supports only 4 lane operation.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260218-drm-panel-ek79007ad3-v4-3-8ec448bf3ede@pengutronix.de
The LXD M9189A is a 1024x600 MIPI-DSI panel.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260218-drm-panel-ek79007ad3-v4-2-8ec448bf3ede@pengutronix.de
These are 60 Hz panels, but the currently set pixel clocks result in modes
with refresh rates of 63 Hz and ~63.41 Hz.
Adjust the clocks to target 60 Hz.
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260218-mantix-pixel-clock-v1-1-c22c034ba5c1@puri.sm
Add support for the Powertip PH800480T032-ZHC19 7" (800x480) parallel
LCD-TFT panel.
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260217123759.169317-2-florijan.plohl@norik.com
