linux.git/include/media, branch master

media: rppx1: Add framework to support Dreamchip RPPX1 ISP

2026-07-30T17:51:35+00:00

Add a framework driver for Dreamchip RPPX1 ISP. The driver aims to
provide a framework for other V4L2 based drivers to drive the RPPX1
functionality. The reason for this split is that the RPPX1 IP itself do
not provide any DMA engines to drive data to/from the device, instead it
depends on other IP blocks to implement these features.

While the peripherals around the RPPX1 ISP used in different designs and
by different vendors are different the RPPX1 core itself is the same.
For this reason the framework solution to be able to split the Dreamchip
RPPX1 driver from vendors usage of it have been picked in hope to reduce
duplication of the common parts.

The design is to try and keep the surface of this framework as small as
possible. The intention of this change is to be able to fill all needs
of this.

  * Two functions to create and destroy a RPPX1 instance, rppx1_create()
    and rppx1_destory(). These are intended to be called in the users
    probe and remove code paths.

  * Two functions to start and stop the RPPX1 processing, rppx1_start()
    and rppx1_stop(). These are intended to be called in the users
    stream on and stream off code paths.

  * One function to ask the RPPX1 to process parameters buffer prepared
    by user space, rppx1_params(). The intention is to call this
    function when the parameter buffer is queued to the V4L2 driver and
    the result stored by the driver until the time it needs to be
    written to the RPPX1. It's the users responsibility to write it
    either using MMIO or other means.

  * One function to fill in a statistic buffer based on the current
    status of the RPPX1, rppx1_stats_fill_isr(). The intention is that
    the user call's this in its interrupt handler when it knows the
    RPPX1 is done processing a frame.

  * One function to ack and retrieve the interrupts generated by the
    RPPX1, rppx1_interrupt(). The intention is to call this function
    when the users interrupt handler detects the RPPX1 have raised and
    interrupt. There is no need for the user to understand, or act, on
    the actual RPPX1 interrupt, but it can if it wants too.

The initial support in the framework is limited and do not implement any
ISP processing algorithms other then configuring the RPPX1 to process
any Bayer (8-, 10, or 12-bit) image and produce either a RGB or YUYV
output. It do however probe all function blocks of the RPPX1 and provide
an interface to interact with both parameter and statistic bufferers.
The user of the framework will not change as algorithms for the
different function blocks of the ISP are being added.

Signed-off-by: Niklas Söderlund 
Co-developed-by: Jai Luthra 
Signed-off-by: Jai Luthra 
Co-developed-by: Jacopo Mondi 
Signed-off-by: Jacopo Mondi 
Reviewed-by: Jacopo Mondi 
Signed-off-by: Sakari Ailus

media: v4l2-isp: Add helpers for stats buffer

2026-07-30T17:51:13+00:00

Add two helper functions to v4l2-isp to handle statistics:

- v4l2_isp_stats_init_buffer() to initialize a statistics buffer
- v4l2_isp_stats_init_block() to initialize a statistics block in the
  next available memory location of a buffer

The v4l2_isp_stats_init_buffer() resets the data size counter of the
buffer and initializes its 'version' field.

The v4l2_isp_stats_init_block() helper accepts the type of the stats
block about to be populated, an array of per-block-type information and
the maximum size of the v4l2-isp buffer. If enough space for the new
block is available, the function increments the
v4l2_isp_buffer.data_size counter, initializes the new stats block
header and returns a pointer to the block for the driver to populate it.

Reviewed-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Signed-off-by: Sakari Ailus

media: v4l2-isp: Add per-block validation callback

2026-07-30T17:51:13+00:00

Drivers are expected to provide to the helper function
v4l2_isp_params_validate_buffer() a list of 'struct
v4l2_isp_params_block_type_info' entries, one for each supported ISP block.

The type 'struct v4l2_isp_params_block_type_info' so far only contained the
expected block size for the core framework to validate the declared block
size against the expected one.

For some blocks, drivers might want to implement more precise per-block
validations. Add a function pointer member to 'struct
v4l2_isp_params_block_type_info' to allow drivers to register a callback
and call it from the core framework during validation.

Reviewed-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Signed-off-by: Sakari Ailus

media: v4l2-isp: Rename v4l2_isp_params_buffer_size

2026-07-30T17:51:13+00:00

Rename v4l2_isp_params_buffer_size() to v4l2_isp_buffer_size() to
support statistics.

Reviewed-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Signed-off-by: Sakari Ailus

media: cec/core: add error-inj-tx-timeouts debugfs entry

2026-07-17T08:14:19+00:00

Add a new debugfs entry that makes it possible to do
error injection of failing the next N transmits by a
timeout.

This can be used to test what happens in that case during
the claiming of a free logical address.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: cec/core: handle core events like normal events

2026-07-17T08:14:03+00:00

Currently there is a distinction between core events
(CEC_EVENT_STATE_CHANGE and CEC_EVENT_LOST_MSGS) and other
events. The core events do not require memory allocations,
so are a bit faster, but they are also limited to just a
single event: if a new event comes in, then that replaces
the old one.

It's all overly complicated, and with only one state change
event it is easy to miss state changes.

So just drop that optimization, and allow for up to 3
state change events.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

media: videobuf2: move vb2_querybuf() kernel-doc to header

2026-07-15T15:12:55+00:00

Move the function documentation for vb2_querybuf() from videobuf2-v4l2.c
to videobuf2-v4l2.h to match other functions.

Leaving the comment in the source file prevents the kernel-doc parser
from extracting it - thus become missing from the generated HTML.

Additionally, format the comment block to be the same style as other
functions in the header.

Signed-off-by: Tharit Tangkijwanichakul 
Signed-off-by: Hans Verkuil

media: pci: Use PCI_DEVICE macros and drop zeros from pci_device_id arrays

2026-07-15T15:12:54+00:00

Some pci_device_id arrays already used the PCI_DEVICE macros, others
used named initializers or list initializers. Unify all to use the
PCI_DEVICE macros and (if applicable) a named initializer for
.driver_data. Also drop all zeros that the compiler can care for and
unify indention and spacing.

Signed-off-by: Uwe Kleine-König (The Capable Hub) 
Signed-off-by: Hans Verkuil

media: v4l2-ioctl: fix video_ioctl2 kernel-doc

2026-07-10T08:32:27+00:00

The video_ioctl2() kernel-doc comment says "hancle" and
refers to v4l2_ioctl_ops.unlocked_ioctl.

Fix the typo and refer to v4l2_file_operations.unlocked_ioctl
instead. The unlocked_ioctl member belongs to struct
v4l2_file_operations.

Signed-off-by: Binglin Zhao <1311165354@qq.com>
Signed-off-by: Hans Verkuil

media: camif-core: Drop GPIO handling

2026-07-10T07:53:50+00:00

The driver and platform data refers to the legacy GPIO API,
doesn't really use it, and also calls some GPIO-related functions
passed as platform data.

This platform data is not used anywhere in the kernel.

I'm not outright deleting the driver, just deleting the bogus
GPIO handling. If outoftree developers want to fix up the
driver the GPIOs should be defined in some kind of firmware
node and be obtained using the gpiod_get*() APIs directly
in the driver, but I don't even know what these GPIOs are
since they are hidden in platform data that is not in the
mainline kernel, so what can I do.

Signed-off-by: Linus Walleij 
Reviewed-by: Bartosz Golaszewski 
Signed-off-by: Hans Verkuil