wifi: iwlwifi: acpi: check the size of the ACPI PPAG tables
We need to make sure we don't have a buffer overflow while reading the
PPAG tables from ACPI into the firmware runtime object.
Add an ACPI specific define for the number of chains in order to
decouple the ACPI layout from the other objects.
wifi: iwlwifi: regulatory: support a new command for PPAG
Per Platform Antenna Gain is getting support for UNII-9.
Add a new version of PER_PLATFORM_ANT_GAIN_CMD.
This requires to increase the number of subbands in the firmware runtime
object.
Pass the number of subbands to iwl_bios_print_ppag to avoid printing
invalid values.
Introduce BIOS_PPAG_MAX_SUB_BANDS_NUM to avoid impacting
BIOS_SAR_MAX_SUB_BANDS_NUM which was used until now for PPAG as well.
SAR will get support for the new subband in future patches.
While at it, print the PPAG table as it was read from BIOS.
Miri Korenblit [Thu, 19 Mar 2026 09:09:23 +0000 (11:09 +0200)]
wifi: iwlwifi: mld: add support for sta command version 3
In this version, the link_id becomes a link_mask to support multiple
links that are used to communicate with the station in question.
This is needed for NAN, in which we can communicate on multiple channels
with the same station.
Also add a new STA type - NAN peer.
wifi: iwlwifi: bring iwl_fill_ppag_table to the iwlmvm
iwl_fill_ppag_table fills a command that is sent to the firmware. This
command has several versions and handling those different versions is
the responsibility of the op_mode.
wifi: iwlwifi: uefi: open code the PPAG table store operation
The structure in firmware runtime will need to grow because we're adding
a subband for UNII-9.
This means that we will soon no longer be able to just memcpy the data
from the UEFI table. The layout of the array will change.
Tediously copy the data byte-byte to make sure things get to the right
place even when we'll increase the number of subbands.
Make it easier for the uefi_cnv_var_ppag structure to grow by
simpiflying the layout it becomes an array of s8.
The layout of the structure becomes less obvious from the structure's
declaration, but then the code is more flexible.
Don't use UEFI_SAR_MAX_SUB_BANDS_NUM for the number of bands for PPAG.
Of course, SAR related structures will grow in future patches, but
decouple SAR and PPAG to make the work easier.
Ilan Peer [Thu, 19 Mar 2026 09:09:20 +0000 (11:09 +0200)]
wifi: iwlwifi: mld: Introduce scan command version 18
The FW scan logic was extended to support new channels in the
7 GHz band, as such, the scan command was modified to support
scanning more PSC channels.
Introduce scan command version 18 handling, which is different
from scan command version 17 only in the number of supported
channel configurations.
As a preparation for a new scan command version, refactor
the scan command building such that it would allow introducing
new scan command structures in a simpler way.
wifi: iwlwifi: mld: remove unused scan expire time constants
Remove the unused IWL_MLD_SCAN_EXPIRE_TIME_SEC constant from
constants.h and its corresponding IWL_MLD_SCAN_EXPIRE_TIME
macro definition from mlo.c. These definitions are no longer
referenced.
wifi: iwlwifi: uefi: decouple UEFI and firmware APIs
The APIs in uefi.h are not firmware API files nor are they pure software
objects. They really reflect a specific layout we expect to see in the
UEFI tables.
Since the UEFI objects are encoded into the BIOS, we can't use the same
values for the declaration of the UEFI objects and for the pure software
object like iwl_sar_profile in the firmware runtime object.
wifi: iwlwifi: ensure we don't read SAR values past the limit
When we fill the SAR values, we read values from the BIOS store in the
firmware runtime object and write them into the command that we send to
the firmware.
We assumed that the size of the firmware command is not longer than the
BIOS tables. This has been true until now, but this is not really safe.
We will soon have an firmware API change that will increase the size of
the table in the command and we want to make sure that we don't have a
buffer overrun when we read the firmware runtime object.
Add this safety measure.
wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2
There is a new version of this command to indicate which AP type in
UNII-9 is supported per country.
This adds support for a new UEFI table that will include that data to be
filled in the new AP type table.
Rename the uats_table field in firmware_runtime structure since it
includes now the UATS and the new UNEB table coming from UEFI.
For the same reason, rename iwl_mld_init_uats.
Marco Crivellari [Tue, 10 Feb 2026 14:33:32 +0000 (15:33 +0100)]
wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Marco Crivellari [Thu, 20 Nov 2025 10:08:49 +0000 (11:08 +0100)]
wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Marco Crivellari [Thu, 20 Nov 2025 10:08:48 +0000 (11:08 +0100)]
wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
Laurent Pinchart [Wed, 18 Mar 2026 23:59:07 +0000 (01:59 +0200)]
media: renesas: vsp1: Initialize format on all pads
The state initialization function vsp1_entity_init_state() incorrectly
leaves the last entity pad out when initializing formats due to an off
by one error. Fix it.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:06 +0000 (01:59 +0200)]
media: renesas: vsp1: Implement control events
The V4L2 API requires drivers that expose controls to implement control
notification events. This is enforced by v4l2-compliance. Add event
handling to the VSP1 entities that create controls to fix the compliance
failures.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:05 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix format setting
The histogram .set_fmt() handler suffers from two problems:
- When operating on the source pad, it returns correct information to
userspace, but does not store the format in the subdev state.
Subsequent calls to .get_fmt(), handled by the
vsp1_subdev_get_pad_format() helper, will not return the correct
information.
- When operating on the sink pad, it uses the
vsp1_subdev_set_pad_format(), which propagates the sink format to the
source, incorrectly overwriting the fixed source format.
The first issue could be fixed by implementing the set format operation
with vsp1_subdev_get_pad_format() on the source pad, if it wasn't that
.set_fmt() is also used to initialize the subdev state in
vsp1_entity_init_state(). The histogram would need a custom
.init_state() handler.
As the second issue would anyway overwrite the format, and therefore
requires a custom .set_fmt() implementation, fix both issues without
using the helpers.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:04 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix size enumeration
The histogram supports size enumeration on the sink pad only, as the
source pad outputs a metadata format. The correct error code when
enumeration is not supported is -ENOTTY, not -EINVAL. Fix it.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:03 +0000 (01:59 +0200)]
media: renesas: vsp1: histo: Fix code enumeration
The histogram media bus code enumeration does not check the index when
operating on the source pad, resulting in an infinite loop if userspace
keeps enumerating code without any loop boundary. Fix it by returning an
error for indices larger than 0 as the pad supports a single format.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:02 +0000 (01:59 +0200)]
media: renesas: vsp1: hsit: Fix size enumeration
The HSIT entity performs format conversion, which leads to incorrect
results with the vsp1_subdev_enum_frame_size() helper. Implement a
custom .enum_frame_size() handler that correctly validates the media bus
code. Size validation is identical to the helper.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:01 +0000 (01:59 +0200)]
media: renesas: vsp1: brx: Fix format propagation
The format width and height is never propagated to the BRX source pad,
leaving its initial configuration invalid. Propagate the whole format
from the first sink pad to the source pad instead of only propagating
the media bus code. This fixes compliance with the subdev format
propagation rules.
Laurent Pinchart [Wed, 18 Mar 2026 23:59:00 +0000 (01:59 +0200)]
media: renesas: vsp1: rwpf: Fix media bus code and frame size enumeration
The RWPF can't freely convert between all input and output formats. They
support RGB <-> YUV conversion, but HSV formats can't be converted. Fix
the media bus code and frame size enumeration to take this into account
on the source pad.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:59 +0000 (01:58 +0200)]
media: renesas: vsp1: rpf: Fix crop width and height clamping
The vsp1 driver doesn't enforce a minimum value on the RPF crop rectangle
width and height. Empty rectangles are accepted, leading to incorrect
hardware behaviour. Fix it by adding minimum width and height
constraints to the value clamping.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:58 +0000 (01:58 +0200)]
media: renesas: vsp1: rpf: Fix crop left and top clamping
The RPF doesn't enforces the alignment constraint on the sink pad
format, which could have an odd size, possibly down to 1x1. In that
case, the upper bounds for the left and top coordinates clamping would
become negative, cast to a very large positive value. Incorrect crop
rectangle coordinates would then be incorrectly accepted.
A second issue can occur when the requested left and top coordinates are
negative. They are cast to a large unsigned value, clamped to the
maximum. While the calculation will produce valid values for the
hardware, this is not compliant with the V4L2 specification that
requires values to be adjusted to the closest valid value.
Fix both issues by switching to signed clamping, with an explicit
minimum to adjust negative values, and adjusting the clamp bounds to
avoid negative upper bounds.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:57 +0000 (01:58 +0200)]
media: renesas: vsp1: Fix code checks in frame size enumeration
The media bus code passed to the .enum_frame_size() operation for the
sink pad is required to be supported by the device, but not to match the
current format. All entities that use the vsp1_subdev_enum_frame_size()
helper, as well as the SRU and UDS entities that implement the operation
manually, perform the check incorrectly.
Fix the issue by implementing the correct code check in the
vsp1_subdev_enum_frame_size(). For the SRU and UDS, to avoid duplicating
code, use the vsp1_subdev_enum_frame_size() as a base and override the
enumerated size on the source pad with entity-specific constraints.
While at it, include the missing <linux/mutex.h> as the code locks
mutexes.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:56 +0000 (01:58 +0200)]
media: renesas: vsp1: Store size limits in vsp1_entity
Most entities use the vsp1_subdev_enum_frame_size() and
vsp1_subdev_set_pad_format() helper functions to implement the
corresponding subdev operations. Both helpers are given the minimum and
maximum sizes supported by the entity as arguments, requiring each
entity to implement a wrapper.
Replace the function arguments with storing the size limits in the
vsp1_entity structure. This allows dropping most of the
.enum_frame_size() and .set_fmt() wrappers in entities.
Laurent Pinchart [Wed, 18 Mar 2026 23:58:55 +0000 (01:58 +0200)]
media: renesas: vsp1: Store supported media bus codes in vsp1_entity
Most entities use the vsp1_subdev_enum_mbus_code() and
vsp1_subdev_set_pad_format() helper functions to implement the
corresponding subdev operations. Both helpers are given the list of
supported media bus codes as arguments, requiring each entity to
implement a wrapper.
Replace the function arguments with storing the supported media bus
codes in the vsp1_entity structure. This allows dropping most of the
.enum_mbus_code() wrappers from entities.
Oliver Collyer [Fri, 26 Dec 2025 06:57:18 +0000 (06:57 +0000)]
media: uvcvideo: Add support for P010 pixel format
Add support for the P010 (10-bit Y/UV 4:2:0) pixel format to the
uvcvideo driver. This format is exposed by USB capture devices such as
the Magewell USB Capture HDMI 4K Pro when capturing HDR10 content.
P010 stores 10-bit Y and interleaved UV samples in 16-bit little-endian
words, with data in the upper 10 bits and zeros in the lower 6 bits.
This requires 2 bytes per sample, so bytesperline is wWidth * 2.
V4L2_PIX_FMT_P010 was added to the V4L2 core in commit 5374d8fb75f3
("media: Add P010 video format").
Based on the community DKMS patch from awawa-dev/P010_for_V4L2.
Yogev Modlin [Sun, 26 Oct 2025 16:43:03 +0000 (18:43 +0200)]
media: uvcvideo: Add D436 and D555 cameras metadata support
Add support for Intel RealSense D436 and D555 depth cameras metadata.
These cameras use the D4XX metadata format for transmitting depth and
sensor information.
The D555 camera uses UVC protocol version 1.5, while the D436 uses
an undefined protocol version. Both cameras require the D4XX metadata
format flag to properly handle their metadata streams.
Yogev Modlin [Sun, 26 Oct 2025 16:43:02 +0000 (18:43 +0200)]
media: uvcvideo: Change comment to 'Intel RealSense'
RealSense branding is now independent of Intel. Update all driver
comments referencing "Intel" to "Intel RealSense" to reflect
current ownership. No code logic changes.
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:56 +0000 (15:01 +0000)]
media: uvcvideo: Allow userspace to increase the meta buffersize
Now we have the metadata size hardcoded to 10 KiB, this is a value that
works fine for bulk cameras or frames with no extra metadata. But not
for all usecases.
We have seen some cameras that produce more metadata per frame. Eg:
Frame 1 captured (Bytes: 11154)
Frame 2 captured (Bytes: 11616)
Frame 3 captured (Bytes: 11374)
Frame 4 captured (Bytes: 11132)
Frame 5 captured (Bytes: 11594)
Frame 6 captured (Bytes: 11352)
Frame 7 captured (Bytes: 11110)
Frame 8 captured (Bytes: 11572)
Frame 9 captured (Bytes: 11308)
When this happens, the driver (correctly) marks the metadata as ERROR.
This patch let userspace set bigger buffersize via S_FMT.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-3-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:55 +0000 (15:01 +0000)]
media: uvcvideo: uvc_queue_to_stream(): Support meta queues
The stream data structure has two queues: the metadata and the data
queues, but uvc_queue_to_stream() only supports the data queue. If we
pass the metadata queue the function will return an invalid pointer.
This patch add a parameter to the function to explicitly tell the
function which queue are we using.
Ricardo Ribalda [Mon, 9 Mar 2026 15:01:54 +0000 (15:01 +0000)]
media: uvcvideo: Enable VB2_DMABUF for metadata stream
The UVC driver has two video streams, one for the frames and another one
for the metadata. Both streams share most of the codebase, but only the
data stream declares support for DMABUF transfer mode.
I have tried the DMABUF transfer mode with CONFIG_DMABUF_HEAPS_SYSTEM
and the frames looked correct.
This patch announces the support for DMABUF for the metadata stream.
This is useful for apps/HALs that only want to support DMABUF.
Cc: stable@vger.kernel.org Fixes: 088ead2552458 ("media: uvcvideo: Add a metadata device node") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260309-uvc-metadata-dmabuf-v1-1-fc8b87bd29c5@chromium.org Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Jann Horn [Tue, 24 Mar 2026 21:35:12 +0000 (22:35 +0100)]
slab,rcu: disable KVFREE_RCU_BATCHED for strict grace period
Disable CONFIG_KVFREE_RCU_BATCHED in CONFIG_RCU_STRICT_GRACE_PERIOD builds
so that kernel fuzzers have an easier time finding use-after-free involving
kfree_rcu().
The intent behind CONFIG_RCU_STRICT_GRACE_PERIOD is that RCU should invoke
callbacks and free objects as soon as possible (at a large performance
cost) so that kernel fuzzers and such have an easier time detecting
use-after-free bugs in objects with RCU lifetime.
CONFIG_KVFREE_RCU_BATCHED is a performance optimization that queues
RCU-freed objects in ways that CONFIG_RCU_STRICT_GRACE_PERIOD can't
expedite; for example, the following testcase doesn't trigger a KASAN splat
when CONFIG_KVFREE_RCU_BATCHED is enabled:
```
struct foo_struct {
struct rcu_head rcu;
int a;
};
struct foo_struct *foo = kmalloc(sizeof(*foo),
GFP_KERNEL | __GFP_NOFAIL | __GFP_ZERO);
Jun Nie [Thu, 12 Mar 2026 08:28:12 +0000 (16:28 +0800)]
drm/msm/dpu: support plane splitting in quad-pipe case
The content of every half of screen is sent out via one interface in
dual-DSI case. The content for every interface is blended by a LM
pair in quad-pipe case, thus a LM pair should not blend any content
that cross the half of screen in this case. Clip plane into pipes per
left and right half screen ROI if topology is quad pipe case.
The clipped rectangle on every half of screen is futher handled by two
pipes if its width exceeds a limit for a single pipe.
For non-virtual-plane case, there is always one stage config to serve
a LM or LM pair. So the clipping does not occur when interating stages
in this case. The plane is mapped to 2 pipes only when width or clock
rate exceeds hardware constrain within stage check.
Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/711324/ Link: https://lore.kernel.org/r/20260312-msm-next-quad-pipe-split-v19-3-4ffa2b06c996@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tvrtko Ursulin [Tue, 24 Mar 2026 11:10:19 +0000 (11:10 +0000)]
drm/syncobj: Fix xa_alloc allocation flags
The xarray conversion blindly and wrongly replaced idr_alloc with xa_alloc
and kept the GFP_NOWAIT. It should have been GFP_KERNEL to account for
idr_preload it removed. Fix it.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: fec2c3c01f1c ("drm/syncobj: Convert syncobj idr to xarray") Reported-by: Himanshu Girotra <himanshu.girotra@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himanshu Girotra <himanshu.girotra@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260324111019.22467-1-tvrtko.ursulin@igalia.com
Jun Nie [Thu, 12 Mar 2026 08:28:11 +0000 (16:28 +0800)]
drm/msm/dpu: Defer SSPP allocation until CRTC check
Currently, mapping plane to SSPP occurs during the plane check phase for
non-virtual plane case. The SSPP allocation and plane mapping occurs during
CRTC check phase for virtual plane case. Defer these SSPP operations until
CRTC check stage to unify the 2 cases, and ease later revisement for
quad-pipe change.
Jun Nie [Thu, 12 Mar 2026 08:28:10 +0000 (16:28 +0800)]
drm/msm/dpu: Extract plane splitting into a dedicated function
dpu_plane_atomic_check_nosspp() currently handles both plane
validation and plane splitting. For better simplicity and to
facilitate future refactoring, move the splitting logic into
its own dedicated function.
Miguel Ojeda [Wed, 25 Mar 2026 01:55:48 +0000 (02:55 +0100)]
dma-mapping: add missing `inline` for `dma_free_attrs`
Under an UML build for an upcoming series [1], I got `-Wstatic-in-inline`
for `dma_free_attrs`:
BINDGEN rust/bindings/bindings_generated.rs - due to target missing
In file included from rust/helpers/helpers.c:59:
rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs' is used in an inline function with external linkage [-Wstatic-in-inline]
17 | dma_free_attrs(dev, size, cpu_addr, dma_handle, attrs);
| ^
rust/helpers/dma.c:12:1: note: use 'static' to give inline function 'rust_helper_dma_free_attrs' internal linkage
12 | __rust_helper void rust_helper_dma_free_attrs(struct device *dev, size_t size,
| ^
| static
The issue is that `dma_free_attrs` was not marked `inline` when it was
introduced alongside the rest of the stubs.
Thus mark it.
Fixes: ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA") Closes: https://lore.kernel.org/rust-for-linux/20260322194616.89847-1-ojeda@kernel.org/ [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260325015548.70912-1-ojeda@kernel.org
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:46 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF index from the struct dpu_hw_vbif
Since we don't support and don't use VBIF_NRT, VBIF_RT is the only
possible VBIF type. To simplify the driver, drop vbif_idx from the VBIF
instance structure. As the last users of VBIF_RT and enum dpu_vbif are
gone, drop them too.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:45 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF index from the VBIF params
Since we don't support and don't use VBIF_NRT, VBIF_RT is the only
possible VBIF type. To simplify the driver, drop vbif_idx from the VBIF
parameter structures.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:44 +0000 (20:36 +0200)]
drm/msm/dpu: drop vbif_idx from WB configuration
All MDP / DPU implementations except for MSM8996 use VBIF_RT (or the
only VBIF) for WB2. Writeback on MSM8996 is not supported (nor planned
to be supported). In order to simplify the driver, drop the field form
the struct dpu_wb_cfg.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:42 +0000 (20:36 +0200)]
drm/msm/dpu: replace VBIF-related array with bare pointers
As we no longer have multiple VBIF instances, it doesn't make sense to
keep VBIF data as arrays. Drop the extra wrapping and keep only a single
instance of each of the structures.
Dmitry Baryshkov [Fri, 27 Feb 2026 18:36:40 +0000 (20:36 +0200)]
drm/msm/dpu: drop VBIF_NRT handling
The second VBIF instance, VBIF_NRT, is only used for the separate inline
rotator block. It is unsupported by the DPU driver and will require a
separate driver (or separate instance of the DPU device).
The only possible user of VBIF_NRT is writeback on MSM8996, however
writeback on that platform is currently unsupported and it's not worth
keeping extra complexity for the sake of that single legacy platform.
None of the hardware catalogs entries actually declare VBIF_NRT, so it
is left in its default state.
Stop pretending that DPU driver cares about VBIF_NRT and drop it.
Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/707773/ Link: https://lore.kernel.org/r/20260227-drop-vbif-nrt-v1-1-2b97d0438182@oss.qualcomm.com
Pengyu Luo [Sat, 7 Mar 2026 11:12:49 +0000 (19:12 +0800)]
drm/msm/dsi: fix hdisplay calculation for CMD mode panel
Commit ac47870fd795 ("drm/msm/dsi: fix hdisplay calculation when
programming dsi registers") incorrecly broke hdisplay calculation for
CMD mode by specifying incorrect number of bytes per transfer, fix it.
Pengyu Luo [Sat, 7 Mar 2026 11:12:48 +0000 (19:12 +0800)]
drm/msm/dsi: fix bits_per_pclk
mipi_dsi_pixel_format_to_bpp return dst bpp not src bpp, dst bpp may
not be the uncompressed data size. use src bpc * 3 to get src bpp,
this aligns with pclk rate calculation.
drm/msm/dpu: fix vblank IRQ registration before atomic_mode_set
dpu_encoder_toggle_vblank_for_crtc() can call control_vblank_irq()
at any time in response to a userspace vblank request, independently
of the atomic commit sequence. If this happens before the encoder's
first atomic_mode_set(), irq[INTR_IDX_RDPTR] is still zero.
Passing irq_idx=0 to dpu_core_irq_register_callback() is treated as
invalid, and DPU_IRQ_REG(0) and DPU_IRQ_BIT(0) produce misleading
values of 134217727 and 31 respectively due to unsigned wraparound
in the (irq_idx - 1) macros, resulting in the confusing error:
Since irq[INTR_IDX_RDPTR] will be properly populated by
atomic_mode_set() and registered by irq_enable() as part of the
normal modeset sequence, silently skip the vblank IRQ registration
when the index has not yet been initialized. This matches the
existing pattern of the master encoder check above it.
drm/msm/hdmi: Avoid double error print on msm_hdmi_get_phy() failure
msm_hdmi_get_phy() already prints error messages on each error path
using dev_err_probe(), so final DRM_DEV_ERROR() would duplicate it and
possibly flood the dmesg on probe deferrals.
drm/msm/hdmi: Fix wrong CTRL1 register used in writing info frames
Commit 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi
framework") changed the unconditional register writes in few places to
updates: read, apply mask, write. The new code reads
REG_HDMI_INFOFRAME_CTRL1 register, applies fields/mask for
HDMI_INFOFRAME_CTRL0 register and finally writes to
HDMI_INFOFRAME_CTRL0. This difference between CTRL1 and CTRL0 looks
unintended and may result in wrong data being written to HDMI bridge
registers.
Cc: <stable@vger.kernel.org> Fixes: 384d2b03d0a1 ("drm/msm/hdmi: make use of the drm_connector_hdmi framework") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/711156/ Link: https://lore.kernel.org/r/20260311191620.245394-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Konrad Dybcio [Tue, 10 Mar 2026 13:20:25 +0000 (14:20 +0100)]
drm/msm/mdss: Add a TODO for better managing the MDSS clock power state
There's a small window where the MDP clock could be set to a high rate
(say, from the bootloader) without a corresponding RPM(H)PD vote to
back it up. This is normally not an issue, but could be, if rmmod fails
to shut down the display driver cleanly, and the module is inserted
again, or when the providers' .sync_state has timed out.
Mark a TODO to fix it one day. Linking the relevant discussion below.
Yuanjie Yang [Mon, 9 Mar 2026 06:37:20 +0000 (14:37 +0800)]
drm/msm/dpu: fix mismatch between power and frequency
During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops
the MMCX rail to MIN_SVS while the core clock frequency remains at its
original (highest) rate. When runtime resume re-enables the clock, this
may result in a mismatch between the rail voltage and the clock rate.
For example, in the DPU bind path, the sequence could be:
cpu0: dev_sync_state -> rpmhpd_sync_state
cpu1: dpu_kms_hw_init
timeline 0 ------------------------------------------------> t
After rpmhpd_sync_state, the voltage performance is no longer guaranteed
to stay at the highest level. During dpu_kms_hw_init, calling
dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to
fall to MIN_SVS while the core clock is still at its maximum frequency.
When the power is re-enabled, only the clock is enabled, leading to a
situation where the MMCX rail is at MIN_SVS but the core clock is at its
highest rate. In this state, the rail cannot sustain the clock rate,
which may cause instability or system crash.
Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend
to ensure the correct vote is restored when DPU resumes.
Fixes: b0530eb11913 ("drm/msm/dpu: Use OPP API to set clk/perf state") Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/710077/ Link: https://lore.kernel.org/r/20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
dt-bindings: display/msm: qcom,eliza-mdss: Add Eliza SoC
Add MDSS/MDP display subsystem for Qualcomm Eliza SoC, being overall a
minor revision change against SM8750, but coming with few different
components, like different DSI PHY, missing DP1 and added HDMI.
The binding does not include HDMI description yet.
dt-bindings: display/msm: dsi-phy-7nm: Add Eliza SoC
Add DSI PHY 4nm v5.2.4 for the Qualcomm Eliza SoC, fully compatible with
SM8650. Note that this DSI PHY, unlike the Eliza MDSS DSI, is not
compatible with SM8750.
dt-bindings: display/msm: dp-controller: Add Eliza SoC
Add DisplayPort controller for Qualcomm Eliza SoC fully compatible with
SM8650. The device looks very similar to SM8750 (same DP TX block
v1.5.1) but with a differences in DP PHY: Eliza and SM8650 use DP PHY
4nm v7.0, SM8750 uses 3nm v8.0.
Konrad Dybcio [Mon, 2 Mar 2026 13:41:26 +0000 (14:41 +0100)]
drm/msm/mdp5: Remove MSM8974v1
To the best of my knowledge, the v1 version of this SoC had been
superseded before any device was released on the market. Everywhere
else in the kernel, there are assumptions about the SoC being revision
2 or the later MSM8974PRO.
Remove the config for that flavor of MDP. To bring the naming in line
with the rest of the kernel, remove the v2 suffix from the remaining
config.
Dmitry Baryshkov [Sat, 28 Feb 2026 17:20:37 +0000 (19:20 +0200)]
drm/msm: add missing MODULE_DEVICE_ID definitions
The drm/msm module bundles several drivers, each of them having a
separate OF match table, however only MDSS (subsystem), KMS devices and
GPU have corresponding MODULE_DEVICE_ID tables.
Add MODULE_DEVICE_ID to the display-related driver and to all other
drivers in this module, simplifying userspace job.
Dmitry Baryshkov [Thu, 26 Feb 2026 13:49:02 +0000 (15:49 +0200)]
drm/msm/dpu: enable virtual planes by default
Turn on the switch and use virtual planes by default, enhancing
utilisation of the display pipelines. It is still possible to use legacy
implementation by using `msm.dpu_use_virtual_planes=false` kernel boot
parameter.
Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Val Packett <val@packett.cool> # x1e80100-dell-latitude-7455,
Patchwork: https://patchwork.freedesktop.org/patch/707437/ Link: https://lore.kernel.org/r/20260226-dpu-enable-virt-planes-v2-1-87971236fe86@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Luca Coelho [Tue, 24 Mar 2026 08:04:27 +0000 (10:04 +0200)]
drm/i915: move LPT clock gating init into intel_pch
Move the LPT PCH clock gating programming into
intel_pch_init_clock_gating() and switch the corresponding
Haswell/Broadwell callers to the display-specific code.
clk: airoha: Add econet EN751221 clock/reset support to en7523-scu
EcoNet EN751221 clock/reset driver is significantly similar to the
EN7523 / EN7581, however the EN751221 does not have a neat batch of clock
divider registers so there are fewer known clocks, and the frequency of
each clock is derived differently. This clock driver will probably work
correctly on EN751627, EN7528, and EN7580.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add clock and reset bindings for EN751221 as well as a "chip-scu" which is
an additional regmap that is used by the clock driver as well as others.
This split of the SCU across two register areas is the same as the Airoha
AN758x family.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Zqiang [Wed, 25 Mar 2026 03:11:00 +0000 (11:11 +0800)]
sched_ext: Choose the right sch->ops.name to output in the print_scx_info()
The print_scx_info() always output scx_root structure's->ops.name,
but for built with CONFIG_EXT_SUB_SCHED=y kernels, the tasks may be
attach an sub scx_sched structure. this commit therefore use the
scx_task_sched_rcu() to correctly get scx_sched structure to output
ops.name, and drop state check.
Input: mk712 - use guard notation when acquiring spinlock
Using guard notation makes the code more compact and error handling
more robust by ensuring that locks are released in all code paths
when control leaves critical section.
Do not define or use iqs5xx_ihex_rec structure: the original code was
using just a couple of fields in it and instead used it to calculate
offset to record data. The data field was actually reserving space for
checksum.
Instead iterate through fields and advance pointer explicitly.
projects / thirdparty / kernel / stable.git / log
