* Re: [RFC PATCH 1/6] media: mc: Implement shared media graph
From: Paul Elder @ 2026-06-24 4:47 UTC (permalink / raw)
To: laurent.pinchart
Cc: michael.riesch, xuhf, stefan.klug, kieran.bingham, dan.scally,
jacopo.mondi, linux-media, linux-arm-kernel, linux-rockchip,
linux-kernel, hverkuil+cisco, nicolas.dufresne, ribalda,
sakari.ailus
In-Reply-To: <20260619052637.1110672-2-paul.elder@ideasonboard.com>
Hi me,
You have a typo...
Quoting Paul Elder (2026-06-19 14:26:28)
> Currently, a media graph contains a main device whose driver is
> responsible for creating the media device. We have however recently run
> into devices that have multiple devices that can quality as a main
> device. Examples are the RK3588 which has a VICAP and two ISP
> instances, and another example is the i.MX8MP which has an ISI and two
> ISP instances. As there is currently no way to reconcile who the main
> device is in the media device, these setups simple cannot be used
> simultaneously.
>
> This patch extends the media controller API with a "shared media graph"
> framework. This allows drivers to share a media device, thus enabling
> the setups mentioned above. Instead of owning and creating a media
> device, drivers can join-or-create a shared media device via the shared
> media graph API. The matching is done automatically based on the
> detected endpoints in the device tree.
>
> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> ---
> drivers/media/mc/Makefile | 2 +-
> drivers/media/mc/mc-shared-graph.c | 335 +++++++++++++++++++++++++++++
> include/media/mc-shared-graph.h | 92 ++++++++
> 3 files changed, 428 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/mc/mc-shared-graph.c
> create mode 100644 include/media/mc-shared-graph.h
>
> diff --git a/drivers/media/mc/Makefile b/drivers/media/mc/Makefile
> index 2b7af42ba59c..1d502fdc52ad 100644
> --- a/drivers/media/mc/Makefile
> +++ b/drivers/media/mc/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> mc-objs := mc-device.o mc-devnode.o mc-entity.o \
> - mc-request.o
> + mc-request.o mc-shared-graph.o
>
> ifneq ($(CONFIG_USB),)
> mc-objs += mc-dev-allocator.o
> diff --git a/drivers/media/mc/mc-shared-graph.c b/drivers/media/mc/mc-shared-graph.c
> new file mode 100644
> index 000000000000..c4067e5b861d
> --- /dev/null
> +++ b/drivers/media/mc/mc-shared-graph.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.c - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/fwnode.h>
> +#include <linux/kref.h>
> +#include <linux/property.h>
> +
> +#include <media/media-device.h>
> +
> +#include <media/mc-shared-graph.h>
> +
> +static LIST_HEAD(media_device_shared_list);
> +static DEFINE_MUTEX(media_device_shared_lock);
> +
> +struct media_device_shared_member {
> + struct device *dev;
> + struct fwnode_handle *fwnode;
> + struct list_head list;
> +};
> +
> +struct media_device_shared_link {
> + struct media_entity *source;
> + u16 source_pad;
> + struct media_entity *sink;
> + u16 sink_pad;
> + u32 flags;
> + struct list_head list;
> +};
> +
> +// TODO figure out locking for when multiple drivers touch the media graph;
> +// maybe macros for shared versions?
> +struct media_device_shared {
> + struct media_device mdev;
> + struct list_head members;
> + struct list_head links;
> +
> + struct list_head list;
> + struct kref refcount;
> +
> + struct device *removed_device;
> +};
> +
> +static inline struct media_device_shared *
> +to_media_device_shared(struct media_device *mdev)
> +{
> + return container_of(mdev, struct media_device_shared, mdev);
> +}
> +
> +static void media_device_shared_release(struct kref *kref)
> +{
> + struct media_device_shared *mds =
> + container_of(kref, struct media_device_shared, refcount);
> +
> + dev_dbg(mds->removed_device, "%s: releasing Media Device\n", __func__);
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + media_device_unregister(&mds->mdev);
> + media_device_cleanup(&mds->mdev);
> +
> + list_del(&mds->list);
> + mutex_unlock(&media_device_shared_lock);
> +
> + kfree(mds);
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static bool __media_device_shared_find_match(struct media_device_shared *mds,
> + struct fwnode_handle *fwnode)
> +{
> + struct media_device_shared_member *member;
> + struct fwnode_handle *ep;
> + struct fwnode_handle *remote_ep;
> + bool match = false;
> +
> + // TODO: parse the device tree endpoints graph instead of finding just the
> + // first-level neighbours
> + fwnode_graph_for_each_endpoint(fwnode, ep) {
> + list_for_each_entry(member, &mds->members, list) {
> + remote_ep = fwnode_graph_get_remote_port_parent(ep);
> + match = (member->fwnode == remote_ep);
> + fwnode_handle_put(remote_ep);
> +
> + if (!match)
> + continue;
> +
> + goto match_complete;
> + }
> + }
> +
> +match_complete:
> + fwnode_handle_put(ep);
> + return match;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_get(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + bool ret;
> +
> + dev_dbg(dev, "%s: searching for media device for %pfwf", __func__, fwnode);
> +
> + list_for_each_entry(mds, &media_device_shared_list, list) {
> + ret = __media_device_shared_find_match(mds, fwnode);
> + if (ret)
> + break;
> + }
> +
> + if (!ret)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + return NULL;
> +
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> + kref_get(&mds->refcount);
> +
> + dev_dbg(dev, "%s: %pfwf joined media device of %pfwf",
> + __func__, fwnode,
> + list_first_entry(&mds->members, struct media_device_shared_member, list)->fwnode);
> +
> + return &mds->mdev;
> +}
> +
> +/* Callers should hold media_device_shared_lock when calling this function */
> +static struct media_device *__media_device_shared_create(struct device *dev)
> +{
> + struct media_device_shared *mds;
> + struct media_device_shared_member *member;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + int ret;
> +
> + mds = kzalloc_obj(*mds);
> + if (!mds)
> + return NULL;
> +
> + member = kzalloc_obj(*member);
> + if (!member)
> + goto err_free_mds;
> +
> + media_device_init(&mds->mdev);
> +
> + ret = media_device_register(&mds->mdev);
> + if (ret)
> + goto err_free_member;
> +
> + INIT_LIST_HEAD(&mds->members);
> + member->dev = dev;
> + member->fwnode = fwnode;
> + list_add_tail(&member->list, &mds->members);
> +
> + INIT_LIST_HEAD(&mds->links);
> +
> + kref_init(&mds->refcount);
> + list_add_tail(&mds->list, &media_device_shared_list);
> +
> + // TODO figure out how to reconcile this with multiple members
> + mds->mdev.dev = dev;
> +
> + devv_dbg(dev, "%s: Allocated media device with %pfwf at %p\n",
here:
s/devv/dev/
Paul
> + __func__, fwnode, &mds->mdev);
> + return &mds->mdev;
> +
> +err_free_member:
> + kfree(member);
> +err_free_mds:
> + kfree(mds);
> + return NULL;
> +}
> +
> +// TODO figure out how to resolve the identifiers (model, driver name, etc);
> +// atm it's racy and whoever gets it last wins
> +struct media_device *media_device_shared_join(struct device *dev)
> +{
> + struct media_device *mdev;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + mdev = __media_device_shared_get(dev);
> + if (!!mdev) {
> + dev_dbg(dev, "%s: found media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> + }
> +
> + mdev = __media_device_shared_create(dev);
> + if (!mdev) {
> + dev_warn(dev, "%s: failed to create media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dev_dbg(dev, "%s: created media device for %pfwf", __func__, dev_fwnode(dev));
> + mutex_unlock(&media_device_shared_lock);
> + return mdev;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join);
> +
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_member *member;
> + struct media_device_shared_member *member_tmp;
> + bool removed = false;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(member, member_tmp, &mds->members, list) {
> + if (member->dev == dev) {
> + list_del(&member->list);
> + kfree(member);
> + removed = true;
> + }
> + }
> +
> + if (!removed)
> + dev_err(dev, "%s: %pfwf trying to leave from graph in which not a member",
> + __func__, dev_fwnode(dev));
> +
> + mds->removed_device = dev;
> + mutex_unlock(&media_device_shared_lock);
> + kref_put(&mds->refcount, media_device_shared_release);
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_leave);
> +
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + /*
> + * TODO Figure out flags. Should we use greatest common denominator? Or
> + * prioritize sink? Or whoever wins the race? For now we just take the flags
> + * from the sink.
> + *
> + * TODO Figure out how to actually do the matching. For now we just match
> + * whoever comes in first. This works with the simple example we're running
> + * with now (rkcif + one rkisp2) but with setups with multiple copies of
> + * hardware this will cause problems, like with rkcif + two rkisp2 and
> + * imx8-isi + two rkisp1.
> + */
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->sink) {
> + ret = media_create_pad_link(source, source_pad,
> + link->sink, link->sink_pad,
> + link->flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_source;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_source;
> + }
> +
> + link->source = source;
> + link->source_pad = source_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_source:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_source);
> +
> +// TODO deduplicate from above
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags)
> +{
> + struct media_device_shared *mds = to_media_device_shared(mdev);
> + struct media_device_shared_link *link;
> + struct media_device_shared_link *link_tmp;
> + int ret = 0;
> +
> + mutex_lock(&media_device_shared_lock);
> +
> + list_for_each_entry_safe(link, link_tmp, &mds->links, list) {
> + if (link->source) {
> + ret = media_create_pad_link(link->source, link->source_pad,
> + sink, sink_pad,
> + flags);
> + list_del(&link->list);
> + kfree(link);
> + goto exit_join_link_sink;
> + }
> + }
> +
> + link = kzalloc_obj(*link);
> + if (!link) {
> + ret = -ENOMEM;
> + goto exit_join_link_sink;
> + }
> +
> + link->sink = sink;
> + link->sink_pad = sink_pad;
> + link->flags = flags;
> + list_add_tail(&link->list, &mds->links);
> +
> +exit_join_link_sink:
> + mutex_unlock(&media_device_shared_lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(media_device_shared_join_link_sink);
> diff --git a/include/media/mc-shared-graph.h b/include/media/mc-shared-graph.h
> new file mode 100644
> index 000000000000..487325163f84
> --- /dev/null
> +++ b/include/media/mc-shared-graph.h
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * mc-shared-graph.h - Media Controller Shared Graph API
> + *
> + * Copyright (c) 2026 Paul Elder <paul.elder@ideasonboard.com>
> + */
> +
> +/*
> + * This file adds the Media Controller Shared Graph API. This allows drivers
> + * to create shared media graphs or join existing media graphs from other
> + * drivers, so that they can all be in the same media graph. This allows us to
> + * have more complex media graphs chaining more complex hardware together,
> + * instead of simple async subdevs.
> + */
> +
> +#include <linux/types.h>
> +
> +#ifndef _MEDIA_SHARED_GRAPH_H
> +#define _MEDIA_SHARED_GRAPH_H
> +
> +struct device;
> +struct media_device;
> +struct media_entity;
> +
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> +/**
> + * media_device_shared_join() - Join or create a new shared media device
> + *
> + * @dev: struct &device pointer
> + *
> + * This is the entrance function for a device to join or create a new shared
> + * media device. It searches for an existing shared media device based on the
> + * neighbours in the device's device tree ports node. If found, then this
> + * functions returns the existing shared media device and joins it. If one is
> + * not found then one is created and initialized and returned.
> + */
> +struct media_device *media_device_shared_join(struct device *dev);
> +
> +/**
> + * media_device_shared_leave() - Leave the shared media device.
> + *
> + * @mdev: struct &media_device pointer
> + * @dev: struct &device pointer
> + *
> + * This function makes the device leave the shared media device. When all
> + * members have left the media device it will be freed.
> + */
> +void media_device_shared_leave(struct media_device *mdev, struct device *dev);
> +
> +/**
> + * media_device_shared_join_link_source() - Register a link source in the shared media device
> + *
> + * @mdev: The struct &media_device pointer that is part of a shared media device
> + * @dev: struct &device pointer
> + * @source: The link source
> + * @source_pad: The pad
> + * @flags: The flags
> + *
> + * This function registers with the shared media device the source part of a
> + * link. When the shared media device receives the matching sink part of a link
> + * via media_device_shared_join_link_sink() then the link will be fully created.
> + */
> +int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags);
> +
> +/**
> + * media_device_shared_join_link_sink() - Register a link sink in the shared media device
> + *
> + * Same as media_device_shared_join_link_source() but for sink instead of
> + * source.
> + */
> +int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags);
> +#else
> +static inline struct media_device *media_device_shared_join(struct device *dev)
> +{ return NULL; }
> +static inline void media_device_shared_leave(struct media_device *mdev,
> + struct device *dev) { }
> +static inline int media_device_shared_join_link_source(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *source,
> + u16 source_pad, u32 flags) { }
> +static inline int media_device_shared_join_link_sink(struct media_device *mdev,
> + struct device *dev,
> + struct media_entity *sink,
> + u16 sink_pad, u32 flags) { }
> +#endif /* CONFIG_MEDIA_CONTROLLER */
> +#endif /* _MEDIA_DEV_SHARED_GRAPH_H */
> --
> 2.47.2
>
^ permalink raw reply
* [PATCH v5 3/3] media: i2c: imx471: Add Sony IMX471 image sensor driver
From: Kate Hsuan @ 2026-06-24 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans de Goede, Hans Verkuil, Sakari Ailus,
Serin Yeh, Tarang Raval, Damjan Georgievski
Cc: linux-media, linux-kernel, Kate Hsuan
In-Reply-To: <20260624033508.27391-1-hpa@redhat.com>
Add a new driver for Sony imx471 camera sensor. It is based on
Jimmy Su <jimmy.su@intel.com> implementation and the driver can be found
in the following URL.
https://github.com/intel/ipu6-drivers/commits/master/drivers/media/i2c/imx471.c
This sensor can be found on Lenovo X1 Carbon G14, X9-14 and X9-15 laptops
and it is a part of IPU7 solution. The driver was tested on Lenovo X1
Carbon G14, X9-14 and X9-15 laptops.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
---
MAINTAINERS | 6 +
drivers/media/i2c/Kconfig | 10 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx471.c | 971 +++++++++++++++++++++++++++++++++++++
4 files changed, 988 insertions(+)
create mode 100644 drivers/media/i2c/imx471.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4560681b51..586958b1816d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25219,6 +25219,12 @@ T: git git://linuxtv.org/media.git
F: Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
F: drivers/media/i2c/imx415.c
+SONY IMX471 SENSOR DRIVER
+M: Kate Hsuan <hpa@redhat.com>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/imx471.c
+
SONY MEMORYSTICK SUBSYSTEM
M: Maxim Levitsky <maximlevitsky@gmail.com>
M: Alex Dubov <oakad@yahoo.com>
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 5d173e0ecf42..b7199f9f5a0c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -287,6 +287,16 @@ config VIDEO_IMX415
To compile this driver as a module, choose M here: the
module will be called imx415.
+config VIDEO_IMX471
+ tristate "Sony IMX471 sensor support"
+ select V4L2_CCI_I2C
+ help
+ This is a Video4Linux2 sensor driver for the Sony
+ IMX471 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx471.
+
config VIDEO_MAX9271_LIB
tristate
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index e45359efe0e4..acbd321fc12e 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_IMX335) += imx335.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
obj-$(CONFIG_VIDEO_IMX412) += imx412.o
obj-$(CONFIG_VIDEO_IMX415) += imx415.o
+obj-$(CONFIG_VIDEO_IMX471) += imx471.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ISL7998X) += isl7998x.o
obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
diff --git a/drivers/media/i2c/imx471.c b/drivers/media/i2c/imx471.c
new file mode 100644
index 000000000000..1e1bff69ea3d
--- /dev/null
+++ b/drivers/media/i2c/imx471.c
@@ -0,0 +1,971 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * imx471.c - imx471 sensor driver
+ *
+ * Copyright (C) 2025 Intel Corporation
+ * Copyright (C) 2026 Kate Hsuan <hpa@redhat.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/unaligned.h>
+#include <media/v4l2-cci.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-event.h>
+#include <media/v4l2-fwnode.h>
+
+#define IMX471_REG_MODE_SELECT CCI_REG8(0x0100)
+#define IMX471_MODE_STANDBY 0x00
+#define IMX471_MODE_STREAMING 0x01
+
+/* Chip ID */
+#define IMX471_REG_CHIP_ID CCI_REG16(0x0016)
+#define IMX471_CHIP_ID 0x0471
+
+/* V_TIMING internal */
+#define IMX471_REG_FLL CCI_REG16(0x0340)
+#define IMX471_FLL_MAX 0xffff
+
+/* Exposure control */
+#define IMX471_REG_EXPOSURE CCI_REG16(0x0202)
+#define IMX471_EXPOSURE_MIN 1
+#define IMX471_EXPOSURE_STEP 1
+#define IMX471_EXPOSURE_DEFAULT 1270
+
+/* Default exposure margin */
+#define IMX471_EXPOSURE_MARGIN 18
+
+/* Analog gain control */
+#define IMX471_REG_ANALOG_GAIN CCI_REG16(0x0204)
+#define IMX471_ANA_GAIN_MIN 0
+#define IMX471_ANA_GAIN_MAX 800
+#define IMX471_ANA_GAIN_STEP 1
+#define IMX471_ANA_GAIN_DEFAULT 0
+
+/* Digital gain control */
+#define IMX471_REG_DPGA_USE_GLOBAL_GAIN CCI_REG16(0x3ff9)
+#define IMX471_REG_DIG_GAIN_GLOBAL CCI_REG16(0x020e)
+#define IMX471_DGTL_GAIN_MIN 256
+#define IMX471_DGTL_GAIN_MAX 4095
+#define IMX471_DGTL_GAIN_STEP 1
+#define IMX471_DGTL_GAIN_DEFAULT 256
+
+/* HFLIP and VFLIP control */
+#define IMX471_REG_ORIENTATION CCI_REG8(0x0101)
+#define IMX471_HFLIP_BIT BIT(0)
+#define IMX471_VFLIP_BIT BIT(1)
+
+/* Test Pattern Control */
+#define IMX471_REG_TEST_PATTERN CCI_REG8(0x0600)
+#define IMX471_TEST_PATTERN_DISABLED 0
+#define IMX471_TEST_PATTERN_SOLID_COLOR 1
+#define IMX471_TEST_PATTERN_COLOR_BARS 2
+#define IMX471_TEST_PATTERN_GRAY_COLOR_BARS 3
+#define IMX471_TEST_PATTERN_PN9 4
+
+/* default link frequency and external clock */
+#define IMX471_LINK_FREQ_DEFAULT 200000000LL
+#define IMX471_EXT_CLK 19200000
+#define IMX471_LINK_FREQ_INDEX 0
+
+/* PLL */
+#define IMX471_REG_VTPXCK_DIV CCI_REG8(0x0301)
+#define IMX471_REG_VTSYCK_DIV CCI_REG8(0x0303)
+#define IMX471_REG_PREPLLCK_VT_DIV CCI_REG8(0x0305)
+#define IMX471_REG_PLL_VT_MPY CCI_REG16(0x0306)
+#define IMX471_REG_OPPXCK_DIV CCI_REG8(0x0309)
+#define IMX471_REG_OPSYCK_DIV CCI_REG8(0x030b)
+#define IMX471_REG_PLL_MULT_DRIV CCI_REG8(0x0310)
+#define IMX471_PLL_SINGLE 0
+#define IMX471_PLL_DUAL 1
+
+/* IMX471 native and active pixel array size */
+#define IMX471_NATIVE_WIDTH 4672
+#define IMX471_NATIVE_HEIGHT 3512
+#define IMX471_PIXEL_ARRAY_LEFT 8
+#define IMX471_PIXEL_ARRAY_TOP 8
+#define IMX471_PIXEL_ARRAY_WIDTH 4656
+#define IMX471_PIXEL_ARRAY_HEIGHT 3496
+
+#define IMX471_REG_EXCK_FREQ CCI_REG16(0x0136)
+#define IMX471_EXCK_FREQ(n) ((n) * 256) /* n in MHz */
+
+#define IMX471_REG_CSI_DATA_FORMAT CCI_REG16(0x0112)
+#define IMX471_CSI_DATA_FORMAT_RAW10 0x0a0a
+
+#define IMX471_REG_CSI_LANE_MODE CCI_REG8(0x0114)
+#define IMX471_CSI_2_LANE_MODE 1
+#define IMX471_CSI_4_LANE_MODE 3
+
+#define IMX471_REG_X_ADD_STA CCI_REG16(0x0344)
+#define IMX471_REG_Y_ADD_STA CCI_REG16(0x0346)
+#define IMX471_REG_X_ADD_END CCI_REG16(0x0348)
+#define IMX471_REG_Y_ADD_END CCI_REG16(0x034a)
+#define IMX471_REG_X_OUTPUT_SIZE CCI_REG16(0x034c)
+#define IMX471_REG_Y_OUTPUT_SIZE CCI_REG16(0x034e)
+#define IMX471_REG_X_EVEN_INC CCI_REG8(0x0381)
+#define IMX471_REG_X_ODD_INC CCI_REG8(0x0383)
+#define IMX471_REG_Y_EVEN_INC CCI_REG8(0x0385)
+#define IMX471_REG_Y_ODD_INC CCI_REG8(0x0387)
+
+#define IMX471_REG_DIG_CROP_X_OFFSET CCI_REG16(0x0408)
+#define IMX471_REG_DIG_CROP_Y_OFFSET CCI_REG16(0x040a)
+#define IMX471_REG_DIG_CROP_WIDTH CCI_REG16(0x040c)
+#define IMX471_REG_DIG_CROP_HEIGHT CCI_REG16(0x040e)
+
+/* Binning mode */
+#define IMX471_REG_BINNING_MODE CCI_REG8(0x0900)
+#define IMX471_BINNING_NONE 0
+#define IMX471_BINNING_ENABLE 1
+#define IMX471_REG_BINNING_TYPE CCI_REG8(0x0901)
+#define IMX471_REG_BINNING_WEIGHTING CCI_REG8(0x0902)
+
+#define to_imx471(_sd) container_of_const(_sd, struct imx471, sd)
+
+static const char * const imx471_supply_name[] = {
+ "avdd",
+};
+
+struct imx471_mode {
+ u32 width;
+ u32 height;
+
+ /* V-timing */
+ u32 fll_def;
+ u32 fll_min;
+
+ /* H-timing */
+ u32 llp;
+
+ u32 link_freq_index;
+
+ const struct cci_reg_sequence *default_mode_regs;
+ unsigned int default_mode_regs_length;
+};
+
+struct imx471 {
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct v4l2_ctrl *vblank;
+ struct v4l2_ctrl *hblank;
+ struct v4l2_ctrl *vflip;
+ struct v4l2_ctrl *hflip;
+ struct v4l2_ctrl *exposure;
+
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(imx471_supply_name)];
+ struct clk *img_clk;
+
+ struct device *dev;
+ struct regmap *regmap;
+};
+
+static const struct cci_reg_sequence imx471_global_regs[] = {
+ { IMX471_REG_EXCK_FREQ, IMX471_EXCK_FREQ(19.2) },
+ { CCI_REG8(0x3c7e), 0x08 },
+ { CCI_REG8(0x3c7f), 0x05 },
+ { CCI_REG8(0x3e35), 0x00 },
+ { CCI_REG8(0x3e36), 0x00 },
+ { CCI_REG8(0x3e37), 0x00 },
+ { CCI_REG8(0x3f7f), 0x01 },
+ { CCI_REG8(0x4431), 0x04 },
+ { CCI_REG8(0x531c), 0x01 },
+ { CCI_REG8(0x531d), 0x02 },
+ { CCI_REG8(0x531e), 0x04 },
+ { CCI_REG8(0x5928), 0x00 },
+ { CCI_REG8(0x5929), 0x2f },
+ { CCI_REG8(0x592a), 0x00 },
+ { CCI_REG8(0x592b), 0x85 },
+ { CCI_REG8(0x592c), 0x00 },
+ { CCI_REG8(0x592d), 0x32 },
+ { CCI_REG8(0x592e), 0x00 },
+ { CCI_REG8(0x592f), 0x88 },
+ { CCI_REG8(0x5930), 0x00 },
+ { CCI_REG8(0x5931), 0x3d },
+ { CCI_REG8(0x5932), 0x00 },
+ { CCI_REG8(0x5933), 0x93 },
+ { CCI_REG8(0x5938), 0x00 },
+ { CCI_REG8(0x5939), 0x24 },
+ { CCI_REG8(0x593a), 0x00 },
+ { CCI_REG8(0x593b), 0x7a },
+ { CCI_REG8(0x593c), 0x00 },
+ { CCI_REG8(0x593d), 0x24 },
+ { CCI_REG8(0x593e), 0x00 },
+ { CCI_REG8(0x593f), 0x7a },
+ { CCI_REG8(0x5940), 0x00 },
+ { CCI_REG8(0x5941), 0x2f },
+ { CCI_REG8(0x5942), 0x00 },
+ { CCI_REG8(0x5943), 0x85 },
+ { CCI_REG8(0x5f0e), 0x6e },
+ { CCI_REG8(0x5f11), 0xc6 },
+ { CCI_REG8(0x5f17), 0x5e },
+ { CCI_REG8(0x7990), 0x01 },
+ { CCI_REG8(0x7993), 0x5d },
+ { CCI_REG8(0x7994), 0x5d },
+ { CCI_REG8(0x7995), 0xa1 },
+ { CCI_REG8(0x799a), 0x01 },
+ { CCI_REG8(0x799d), 0x00 },
+ { CCI_REG8(0x8169), 0x01 },
+ { CCI_REG8(0x8359), 0x01 },
+ { CCI_REG8(0x9302), 0x1e },
+ { CCI_REG8(0x9306), 0x1f },
+ { CCI_REG8(0x930a), 0x26 },
+ { CCI_REG8(0x930e), 0x23 },
+ { CCI_REG8(0x9312), 0x23 },
+ { CCI_REG8(0x9316), 0x2c },
+ { CCI_REG8(0x9317), 0x19 },
+ { CCI_REG8(0xb046), 0x01 },
+ { CCI_REG8(0xb048), 0x01 },
+};
+
+static const struct cci_reg_sequence mode_1928x1088_regs[] = {
+ { IMX471_REG_CSI_DATA_FORMAT, IMX471_CSI_DATA_FORMAT_RAW10 },
+ { IMX471_REG_CSI_LANE_MODE, IMX471_CSI_4_LANE_MODE },
+ { IMX471_REG_X_ADD_STA, 8 },
+ { IMX471_REG_Y_ADD_STA, 408 },
+ { IMX471_REG_X_ADD_END, 4647 },
+ { IMX471_REG_Y_ADD_END, 3051 },
+ { IMX471_REG_X_EVEN_INC, 1 },
+ { IMX471_REG_X_ODD_INC, 1 },
+ { IMX471_REG_Y_EVEN_INC, 1 },
+ { IMX471_REG_Y_ODD_INC, 1 },
+ { IMX471_REG_BINNING_MODE, IMX471_BINNING_ENABLE },
+ { IMX471_REG_BINNING_TYPE, 0x22 },
+ { IMX471_REG_BINNING_WEIGHTING, 0x08 },
+ { IMX471_REG_DIG_CROP_X_OFFSET, 208 },
+ { IMX471_REG_DIG_CROP_Y_OFFSET, 108 },
+ { IMX471_REG_DIG_CROP_WIDTH, 1928 },
+ { IMX471_REG_DIG_CROP_HEIGHT, 1088 },
+ { IMX471_REG_X_OUTPUT_SIZE, 1928 },
+ { IMX471_REG_Y_OUTPUT_SIZE, 1088 },
+ { IMX471_REG_VTPXCK_DIV, 0x06 },
+ { IMX471_REG_VTSYCK_DIV, 0x02 },
+ { IMX471_REG_PREPLLCK_VT_DIV, 0x02 },
+ { IMX471_REG_PLL_VT_MPY, 0x0079 },
+ { IMX471_REG_OPSYCK_DIV, 0x01 },
+ { CCI_REG8(0x030d), 0x02 },
+ { CCI_REG8(0x030e), 0x00 },
+ { CCI_REG8(0x030f), 0x53 },
+ { IMX471_REG_PLL_MULT_DRIV, IMX471_PLL_DUAL },
+ { CCI_REG8(0x3f4c), 0x81 },
+ { CCI_REG8(0x3f4d), 0x81 },
+ { CCI_REG8(0x3f78), 0x01 },
+ { CCI_REG8(0x3f79), 0x31 },
+ { CCI_REG8(0x3ffe), 0x00 },
+ { CCI_REG8(0x3fff), 0x8a },
+ { CCI_REG8(0x5f0a), 0xb6 },
+};
+
+static const char * const imx471_test_pattern_menu[] = {
+ "Disabled",
+ "Solid Colour",
+ "Eight Vertical Colour Bars",
+ "Colour Bars With Fade to Grey",
+ "Pseudorandom Sequence (PN9)",
+};
+
+static const s64 link_freq_menu_items[] = {
+ IMX471_LINK_FREQ_DEFAULT,
+};
+
+/*
+ * The Bayer formats for the flipping.
+ * - no flip
+ * - h flip
+ * - v flip
+ * - h and v flips
+ */
+static const u32 imx471_hv_flips_bayer_order[] = {
+ MEDIA_BUS_FMT_SRGGB10_1X10,
+ MEDIA_BUS_FMT_SGRBG10_1X10,
+ MEDIA_BUS_FMT_SGBRG10_1X10,
+ MEDIA_BUS_FMT_SBGGR10_1X10,
+};
+
+static const struct imx471_mode imx471_modes[] = {
+ {
+ .width = 1928,
+ .height = 1088,
+ .fll_def = 1308,
+ .fll_min = 1308,
+ .llp = 2328,
+ .link_freq_index = IMX471_LINK_FREQ_INDEX,
+ .default_mode_regs = mode_1928x1088_regs,
+ .default_mode_regs_length = ARRAY_SIZE(mode_1928x1088_regs),
+ },
+};
+
+static int imx471_get_regulators(struct device *dev, struct imx471 *sensor)
+{
+ for (unsigned int i = 0; i < ARRAY_SIZE(imx471_supply_name); i++)
+ sensor->supplies[i].supply = imx471_supply_name[i];
+
+ return devm_regulator_bulk_get(dev, ARRAY_SIZE(imx471_supply_name),
+ sensor->supplies);
+}
+
+static int imx471_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct imx471 *sensor = container_of_const(ctrl->handler,
+ struct imx471,
+ ctrl_handler);
+ struct v4l2_subdev_state *state =
+ v4l2_subdev_get_locked_active_state(&sensor->sd);
+ const struct v4l2_mbus_framefmt *format =
+ v4l2_subdev_state_get_format(state, 0);
+ int ret;
+
+ if (ctrl->id == V4L2_CID_VBLANK) {
+ s64 exposure_max = format->height + ctrl->val -
+ IMX471_EXPOSURE_MARGIN;
+ ret = __v4l2_ctrl_modify_range(sensor->exposure,
+ sensor->exposure->minimum,
+ exposure_max,
+ sensor->exposure->step,
+ exposure_max);
+ if (ret)
+ return ret;
+ }
+
+ if (!pm_runtime_get_if_in_use(sensor->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_ANALOGUE_GAIN:
+ ret = cci_write(sensor->regmap, IMX471_REG_ANALOG_GAIN,
+ ctrl->val, NULL);
+ break;
+ case V4L2_CID_DIGITAL_GAIN:
+ ret = cci_write(sensor->regmap, IMX471_REG_DIG_GAIN_GLOBAL,
+ ctrl->val, NULL);
+ break;
+ case V4L2_CID_EXPOSURE:
+ ret = cci_write(sensor->regmap, IMX471_REG_EXPOSURE,
+ ctrl->val, &ret);
+ break;
+ case V4L2_CID_VBLANK:
+ /* Update FLL that meets expected vertical blanking */
+ ret = cci_write(sensor->regmap, IMX471_REG_FLL,
+ format->height + ctrl->val, &ret);
+ break;
+ case V4L2_CID_TEST_PATTERN:
+ ret = cci_write(sensor->regmap, IMX471_REG_TEST_PATTERN,
+ ctrl->val, NULL);
+ break;
+ case V4L2_CID_HFLIP:
+ case V4L2_CID_VFLIP:
+ ret = cci_write(sensor->regmap, IMX471_REG_ORIENTATION,
+ sensor->hflip->val | sensor->vflip->val << 1,
+ NULL);
+ break;
+ default:
+ ret = -EINVAL;
+ dev_err(sensor->dev, "ctrl(id:0x%x,val:0x%x) is not handled\n",
+ ctrl->id, ctrl->val);
+ break;
+ }
+
+ pm_runtime_put(sensor->dev);
+
+ return ret;
+}
+
+static const struct v4l2_ctrl_ops imx471_ctrl_ops = {
+ .s_ctrl = imx471_set_ctrl,
+};
+
+static u32 imx471_get_format_code(struct imx471 *sensor)
+{
+ unsigned int i;
+
+ i = (sensor->vflip->val ? 2 : 0) | (sensor->hflip->val ? 1 : 0);
+
+ return imx471_hv_flips_bayer_order[i];
+}
+
+static int imx471_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ struct imx471 *sensor = to_imx471(sd);
+
+ if (code->index >= (ARRAY_SIZE(imx471_hv_flips_bayer_order) / 4))
+ return -EINVAL;
+
+ code->code = imx471_get_format_code(sensor);
+
+ return 0;
+}
+
+static int imx471_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse->index >= ARRAY_SIZE(imx471_modes))
+ return -EINVAL;
+
+ fse->min_width = imx471_modes[fse->index].width;
+ fse->max_width = fse->min_width;
+ fse->min_height = imx471_modes[fse->index].height;
+ fse->max_height = fse->min_height;
+
+ return 0;
+}
+
+static void imx471_update_pad_format(struct imx471 *sensor,
+ const struct imx471_mode *mode,
+ struct v4l2_subdev_format *fmt)
+{
+ fmt->format.code = imx471_get_format_code(sensor);
+ fmt->format.width = mode->width;
+ fmt->format.height = mode->height;
+ fmt->format.field = V4L2_FIELD_NONE;
+}
+
+static int imx471_set_pad_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_format *fmt)
+{
+ struct imx471 *sensor = to_imx471(sd);
+ const struct imx471_mode *mode;
+ int h_blank, ret;
+
+ mode = v4l2_find_nearest_size(imx471_modes, ARRAY_SIZE(imx471_modes),
+ width, height, fmt->format.width,
+ fmt->format.height);
+
+ imx471_update_pad_format(sensor, mode, fmt);
+
+ *v4l2_subdev_state_get_format(sd_state, fmt->pad) = fmt->format;
+
+ if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
+ return 0;
+
+ if (media_entity_is_streaming(&sensor->sd.entity))
+ return -EBUSY;
+
+ ret = __v4l2_ctrl_modify_range(sensor->vblank,
+ mode->fll_min - mode->height,
+ IMX471_FLL_MAX - mode->height,
+ 1,
+ mode->fll_def - mode->height);
+ if (ret)
+ return ret;
+
+ h_blank = mode->llp - mode->width;
+ /*
+ * Currently hblank is not changeable.
+ * So FPS control is done only by vblank.
+ */
+ return __v4l2_ctrl_modify_range(sensor->hblank, h_blank,
+ h_blank, 1, h_blank);
+}
+
+static int imx471_get_selection(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state,
+ struct v4l2_subdev_selection *sel)
+{
+ switch (sel->target) {
+ case V4L2_SEL_TGT_CROP:
+ sel->r = *v4l2_subdev_state_get_crop(sd_state, sel->pad);
+ break;
+
+ case V4L2_SEL_TGT_NATIVE_SIZE:
+ sel->r.top = 0;
+ sel->r.left = 0;
+ sel->r.width = IMX471_NATIVE_WIDTH;
+ sel->r.height = IMX471_NATIVE_HEIGHT;
+ return 0;
+
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ sel->r.top = IMX471_PIXEL_ARRAY_TOP;
+ sel->r.left = IMX471_PIXEL_ARRAY_LEFT;
+ sel->r.width = IMX471_PIXEL_ARRAY_WIDTH;
+ sel->r.height = IMX471_PIXEL_ARRAY_HEIGHT;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int imx471_init_state(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *sd_state)
+{
+ struct v4l2_subdev_format fmt = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ .format = {
+ .code = MEDIA_BUS_FMT_SRGGB10_1X10,
+ .width = imx471_modes[0].width,
+ .height = imx471_modes[0].height,
+ },
+ };
+
+ return imx471_set_pad_format(sd, sd_state, &fmt);
+}
+
+static int imx471_identify_module(struct imx471 *sensor)
+{
+ int ret;
+ u64 val;
+
+ ret = cci_read(sensor->regmap, IMX471_REG_CHIP_ID, &val, NULL);
+ if (ret)
+ return dev_err_probe(sensor->dev, ret,
+ "failed to read chip id\n");
+
+ if (val != IMX471_CHIP_ID)
+ return dev_err_probe(sensor->dev, -EIO,
+ "chip id mismatch: %x!=%llx\n",
+ IMX471_CHIP_ID, val);
+
+ return 0;
+}
+
+static int imx471_power_off(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct imx471 *sensor = to_imx471(sd);
+
+ clk_disable_unprepare(sensor->img_clk);
+ gpiod_set_value_cansleep(sensor->reset_gpio, 1);
+
+ regulator_bulk_disable(ARRAY_SIZE(imx471_supply_name),
+ sensor->supplies);
+
+ return 0;
+}
+
+static int imx471_power_on(struct device *dev)
+{
+ struct v4l2_subdev *sd = dev_get_drvdata(dev);
+ struct imx471 *sensor = to_imx471(sd);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(imx471_supply_name),
+ sensor->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable regulators: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(sensor->img_clk);
+ if (ret < 0) {
+ regulator_bulk_disable(ARRAY_SIZE(imx471_supply_name),
+ sensor->supplies);
+ dev_err(dev, "failed to enable imaging clock: %d\n", ret);
+ return ret;
+ }
+
+ gpiod_set_value_cansleep(sensor->reset_gpio, 0);
+
+ usleep_range(10000, 15000);
+
+ return 0;
+}
+
+static int imx471_enable_stream(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ u32 pad, u64 streams_mask)
+{
+ struct imx471 *sensor = to_imx471(sd);
+ const struct imx471_mode *mode;
+ struct v4l2_mbus_framefmt *fmt;
+ int ret;
+
+ ret = pm_runtime_resume_and_get(sensor->dev);
+ if (ret)
+ return ret;
+
+ ret = imx471_identify_module(sensor);
+ if (ret)
+ goto error_powerdown;
+
+ ret = cci_multi_reg_write(sensor->regmap, imx471_global_regs,
+ ARRAY_SIZE(imx471_global_regs), NULL);
+ if (ret) {
+ dev_err(sensor->dev, "failed to set global settings: %d\n",
+ ret);
+ goto error_powerdown;
+ }
+
+ fmt = v4l2_subdev_state_get_format(state, 0);
+ mode = v4l2_find_nearest_size(imx471_modes, ARRAY_SIZE(imx471_modes),
+ width, height, fmt->width, fmt->height);
+
+ ret = cci_multi_reg_write(sensor->regmap, mode->default_mode_regs,
+ mode->default_mode_regs_length, NULL);
+ if (ret) {
+ dev_err(sensor->dev, "failed to set mode: %d\n", ret);
+ goto error_powerdown;
+ }
+
+ ret = cci_write(sensor->regmap, IMX471_REG_DPGA_USE_GLOBAL_GAIN, 1,
+ NULL);
+ if (ret)
+ goto error_powerdown;
+
+ ret = __v4l2_ctrl_handler_setup(&sensor->ctrl_handler);
+ if (ret)
+ goto error_powerdown;
+
+ ret = cci_write(sensor->regmap, IMX471_REG_MODE_SELECT,
+ IMX471_MODE_STREAMING, NULL);
+ if (ret)
+ goto error_powerdown;
+
+ __v4l2_ctrl_grab(sensor->vflip, true);
+ __v4l2_ctrl_grab(sensor->hflip, true);
+
+ return ret;
+
+error_powerdown:
+ pm_runtime_put(sensor->dev);
+
+ return ret;
+}
+
+static int imx471_disable_stream(struct v4l2_subdev *sd,
+ struct v4l2_subdev_state *state,
+ u32 pad, u64 streams_mask)
+{
+ struct imx471 *sensor = to_imx471(sd);
+ int ret;
+
+ ret = cci_write(sensor->regmap, IMX471_REG_MODE_SELECT,
+ IMX471_MODE_STANDBY, NULL);
+ pm_runtime_put(sensor->dev);
+
+ if (ret)
+ dev_err(sensor->dev,
+ "failed to disable stream with return value: %d\n",
+ ret);
+
+ __v4l2_ctrl_grab(sensor->vflip, false);
+ __v4l2_ctrl_grab(sensor->hflip, false);
+
+ return 0;
+}
+
+static const struct v4l2_subdev_video_ops imx471_video_ops = {
+ .s_stream = v4l2_subdev_s_stream_helper,
+};
+
+static const struct v4l2_subdev_pad_ops imx471_pad_ops = {
+ .enum_mbus_code = imx471_enum_mbus_code,
+ .get_fmt = v4l2_subdev_get_fmt,
+ .set_fmt = imx471_set_pad_format,
+ .get_selection = imx471_get_selection,
+ .enum_frame_size = imx471_enum_frame_size,
+ .enable_streams = imx471_enable_stream,
+ .disable_streams = imx471_disable_stream,
+};
+
+static const struct v4l2_subdev_ops imx471_subdev_ops = {
+ .video = &imx471_video_ops,
+ .pad = &imx471_pad_ops,
+};
+
+static const struct v4l2_subdev_internal_ops imx471_internal_ops = {
+ .init_state = imx471_init_state,
+};
+
+static int imx471_init_controls(struct imx471 *sensor)
+{
+ const struct imx471_mode *mode = &imx471_modes[0];
+ struct v4l2_fwnode_device_properties props;
+ struct v4l2_ctrl_handler *ctrl_hdlr;
+ struct v4l2_ctrl *link_freq;
+ s64 exposure_max, hblank;
+ u64 pixel_rate;
+ int ret;
+
+ ret = v4l2_fwnode_device_parse(sensor->dev, &props);
+ if (ret) {
+ dev_err(sensor->dev, "failed to parse fwnode: %d\n", ret);
+ return ret;
+ }
+
+ ctrl_hdlr = &sensor->ctrl_handler;
+ v4l2_ctrl_handler_init(ctrl_hdlr, 12);
+
+ v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, &imx471_ctrl_ops, &props);
+
+ link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
+ &imx471_ctrl_ops,
+ V4L2_CID_LINK_FREQ,
+ ARRAY_SIZE(link_freq_menu_items) - 1,
+ 0,
+ link_freq_menu_items);
+
+ /* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
+ pixel_rate = div_u64(IMX471_LINK_FREQ_DEFAULT * 2 * 4, 10);
+
+ v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_PIXEL_RATE, pixel_rate,
+ pixel_rate, 1, pixel_rate);
+
+ sensor->vblank = v4l2_ctrl_new_std(ctrl_hdlr,
+ &imx471_ctrl_ops,
+ V4L2_CID_VBLANK,
+ mode->fll_min - mode->height,
+ IMX471_FLL_MAX - mode->height,
+ 1,
+ mode->fll_def - mode->height);
+
+ hblank = mode->llp - mode->width;
+ sensor->hblank = v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_HBLANK, hblank, hblank,
+ 1, hblank);
+
+ /* fll >= exposure time + adjust parameter (default value is 18) */
+ exposure_max = mode->fll_def - IMX471_EXPOSURE_MARGIN;
+ sensor->exposure = v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_EXPOSURE,
+ IMX471_EXPOSURE_MIN, exposure_max,
+ IMX471_EXPOSURE_STEP,
+ IMX471_EXPOSURE_DEFAULT);
+
+ v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops, V4L2_CID_ANALOGUE_GAIN,
+ IMX471_ANA_GAIN_MIN, IMX471_ANA_GAIN_MAX,
+ IMX471_ANA_GAIN_STEP, IMX471_ANA_GAIN_DEFAULT);
+
+ v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops, V4L2_CID_DIGITAL_GAIN,
+ IMX471_DGTL_GAIN_MIN, IMX471_DGTL_GAIN_MAX,
+ IMX471_DGTL_GAIN_STEP, IMX471_DGTL_GAIN_DEFAULT);
+
+ v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(imx471_test_pattern_menu) - 1,
+ 0, 0, imx471_test_pattern_menu);
+
+ sensor->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+
+ sensor->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &imx471_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+
+ if (ctrl_hdlr->error) {
+ dev_err(sensor->dev, "%s control init failed: %d\n",
+ __func__, ctrl_hdlr->error);
+ goto error;
+ }
+
+ link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+ sensor->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+ sensor->hflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
+ sensor->vflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT;
+
+ sensor->sd.ctrl_handler = ctrl_hdlr;
+
+ return 0;
+
+error:
+ v4l2_ctrl_handler_free(ctrl_hdlr);
+
+ return ctrl_hdlr->error;
+}
+
+static int imx471_check_hwcfg(struct imx471 *sensor)
+{
+ struct v4l2_fwnode_endpoint bus_cfg = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY,
+ };
+ struct fwnode_handle *ep, *fwnode = dev_fwnode(sensor->dev);
+ unsigned long link_freq_bitmap;
+ struct clk *clk;
+ int ret;
+
+ clk = devm_v4l2_sensor_clk_get(sensor->dev, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(sensor->dev, PTR_ERR(clk),
+ "can't get clock frequency\n");
+
+ if (clk_get_rate(clk) != IMX471_EXT_CLK)
+ return dev_err_probe(sensor->dev, -EINVAL,
+ "external clock %lu is not supported\n",
+ clk_get_rate(clk));
+
+ ep = fwnode_graph_get_endpoint_by_id(fwnode, 0, 0, 0);
+ ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+ fwnode_handle_put(ep);
+ if (ret)
+ return dev_err_probe(sensor->dev, ret,
+ "parsing endpoint failed\n");
+
+ if (bus_cfg.bus.mipi_csi2.num_data_lanes != 4) {
+ ret = dev_err_probe(sensor->dev, -EINVAL,
+ "number of CSI2 data lanes %u is not supported\n",
+ bus_cfg.bus.mipi_csi2.num_data_lanes);
+ goto done_endpoint_free;
+ }
+
+ ret = v4l2_link_freq_to_bitmap(sensor->dev, bus_cfg.link_frequencies,
+ bus_cfg.nr_of_link_frequencies,
+ link_freq_menu_items,
+ ARRAY_SIZE(link_freq_menu_items),
+ &link_freq_bitmap);
+
+done_endpoint_free:
+ v4l2_fwnode_endpoint_free(&bus_cfg);
+
+ return ret;
+}
+
+static int imx471_probe(struct i2c_client *client)
+{
+ struct imx471 *sensor;
+ int ret;
+
+ sensor = devm_kzalloc(&client->dev, sizeof(*sensor), GFP_KERNEL);
+ if (!sensor)
+ return dev_err_probe(&client->dev, -ENOMEM,
+ "failed to allocate memory\n");
+
+ sensor->dev = &client->dev;
+
+ ret = imx471_check_hwcfg(sensor);
+ if (ret)
+ return dev_err_probe(sensor->dev, ret,
+ "failed to check hwcfg: %d\n", ret);
+
+ ret = imx471_get_regulators(sensor->dev, sensor);
+ if (ret)
+ return dev_err_probe(sensor->dev, ret,
+ "failed to get regulators\n");
+
+ sensor->reset_gpio = devm_gpiod_get_optional(sensor->dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(sensor->reset_gpio))
+ return dev_err_probe(sensor->dev, PTR_ERR(sensor->reset_gpio),
+ "failed to get reset gpio\n");
+
+ sensor->img_clk = devm_v4l2_sensor_clk_get(sensor->dev, NULL);
+ if (IS_ERR(sensor->img_clk))
+ return dev_err_probe(sensor->dev, PTR_ERR(sensor->img_clk),
+ "failed to get imaging clock\n");
+
+ v4l2_i2c_subdev_init(&sensor->sd, client, &imx471_subdev_ops);
+
+ sensor->regmap = devm_cci_regmap_init_i2c(client, 16);
+ if (IS_ERR(sensor->regmap))
+ return dev_err_probe(sensor->dev, PTR_ERR(sensor->regmap),
+ "failed to initialize CCI\n");
+
+ ret = imx471_power_on(sensor->dev);
+ if (ret)
+ return dev_err_probe(sensor->dev, ret,
+ "failed to power on\n");
+
+ ret = imx471_identify_module(sensor);
+ if (ret) {
+ dev_err_probe(sensor->dev, ret, "failed to find sensor: %d\n",
+ ret);
+ goto error_power_off;
+ }
+
+ ret = imx471_init_controls(sensor);
+ if (ret) {
+ dev_err_probe(sensor->dev, ret, "failed to init controls: %d\n",
+ ret);
+ goto error_power_off;
+ }
+
+ sensor->sd.internal_ops = &imx471_internal_ops;
+ sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
+ sensor->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+
+ ret = media_entity_pads_init(&sensor->sd.entity, 1, &sensor->pad);
+ if (ret) {
+ dev_err_probe(sensor->dev, ret,
+ "failed to init entity pads: %d\n", ret);
+ goto error_v4l2_ctrl_handler_free;
+ }
+
+ sensor->sd.state_lock = sensor->ctrl_handler.lock;
+ ret = v4l2_subdev_init_finalize(&sensor->sd);
+ if (ret < 0) {
+ dev_err_probe(sensor->dev, ret, "failed to init subdev: %d\n",
+ ret);
+ goto error_media_entity_pm;
+ }
+
+ pm_runtime_set_active(sensor->dev);
+ pm_runtime_enable(sensor->dev);
+
+ ret = v4l2_async_register_subdev_sensor(&sensor->sd);
+ if (ret < 0)
+ goto error_v4l2_subdev_cleanup;
+
+ pm_runtime_idle(sensor->dev);
+
+ return 0;
+
+error_v4l2_subdev_cleanup:
+ pm_runtime_disable(sensor->dev);
+ pm_runtime_set_suspended(sensor->dev);
+ v4l2_subdev_cleanup(&sensor->sd);
+
+error_media_entity_pm:
+ media_entity_cleanup(&sensor->sd.entity);
+
+error_v4l2_ctrl_handler_free:
+ v4l2_ctrl_handler_free(sensor->sd.ctrl_handler);
+
+error_power_off:
+ imx471_power_off(sensor->dev);
+
+ return ret;
+}
+
+static void imx471_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+
+ v4l2_async_unregister_subdev(sd);
+ v4l2_subdev_cleanup(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+
+ pm_runtime_disable(&client->dev);
+
+ if (!pm_runtime_status_suspended(&client->dev)) {
+ imx471_power_off(&client->dev);
+ pm_runtime_set_suspended(&client->dev);
+ }
+}
+
+static DEFINE_RUNTIME_DEV_PM_OPS(imx471_pm_ops, imx471_power_off,
+ imx471_power_on, NULL);
+
+static const struct acpi_device_id imx471_acpi_ids[] __maybe_unused = {
+ { "SONY471A" },
+ { "TBE20A0" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, imx471_acpi_ids);
+
+static struct i2c_driver imx471_i2c_driver = {
+ .driver = {
+ .name = "imx471",
+ .acpi_match_table = ACPI_PTR(imx471_acpi_ids),
+ .pm = pm_sleep_ptr(&imx471_pm_ops),
+ },
+ .probe = imx471_probe,
+ .remove = imx471_remove,
+};
+module_i2c_driver(imx471_i2c_driver);
+
+MODULE_AUTHOR("Jimmy Su <jimmy.su@intel.com>");
+MODULE_AUTHOR("Serin Yeh <serin.yeh@intel.com>");
+MODULE_AUTHOR("Kate Hsuan <hpa@redhat.com>");
+MODULE_DESCRIPTION("Sony imx471 sensor driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v5 2/3] media: ipu-bridge: Add Sony IMX471 for Lenovo X1 Carbon G14
From: Kate Hsuan @ 2026-06-24 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans de Goede, Hans Verkuil, Sakari Ailus,
Serin Yeh, Tarang Raval, Damjan Georgievski
Cc: linux-media, linux-kernel, Kate Hsuan
In-Reply-To: <20260624033508.27391-1-hpa@redhat.com>
The HID for Sony IMX471 is TBE20A0 on Lenovo X1 Carbon G14.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
---
drivers/media/pci/intel/ipu-bridge.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 2474452b3015..8ddfab357922 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -97,6 +97,8 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = {
IPU_SENSOR_CONFIG("OVTI8856", 3, 180000000, 360000000, 720000000),
/* Sony IMX471 */
IPU_SENSOR_CONFIG("SONY471A", 1, 200000000),
+ /* Sony IMX471 (found on Lenovo X1 Carbon G14) */
+ IPU_SENSOR_CONFIG("TBE20A0", 1, 200000000),
/* Toshiba T4KA3 */
IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000),
};
--
2.54.0
^ permalink raw reply related
* [PATCH v5 1/3] media: ipu-bridge: Add DMI information of Lenovo X9 to the image upside-down list
From: Kate Hsuan @ 2026-06-24 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans de Goede, Hans Verkuil, Sakari Ailus,
Serin Yeh, Tarang Raval, Damjan Georgievski
Cc: linux-media, linux-kernel, Kate Hsuan
In-Reply-To: <20260624033508.27391-1-hpa@redhat.com>
The Lenovo X9 has an upside-down-mounted Sony IMX471 sensor so the image
was displayed upside-down. Add the DMI information of Lenovo X9 to
resolve the issue.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
---
drivers/media/pci/intel/ipu-bridge.c | 39 ++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
index 88581a4c081d..2474452b3015 100644
--- a/drivers/media/pci/intel/ipu-bridge.c
+++ b/drivers/media/pci/intel/ipu-bridge.c
@@ -134,6 +134,45 @@ static const struct dmi_system_id upside_down_sensor_dmi_ids[] = {
},
.driver_data = "OVTI02C1",
},
+ /*
+ * The first four characters of DMI_BOARD_NAME identify the Lenovo
+ * machine type/model. For example, a DMI_BOARD_NAME starting with
+ * "21Q6" indicates a ThinkPad X9-15.
+ *
+ * Reference: https://psref.lenovo.com/
+ */
+ {
+ /* Lenovo X9-14 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_BOARD_NAME, "21QA"),
+ },
+ .driver_data = "SONY471A",
+ },
+ {
+ /* Lenovo X9-14 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_BOARD_NAME, "21QB"),
+ },
+ .driver_data = "SONY471A",
+ },
+ {
+ /* Lenovo X9-15 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_BOARD_NAME, "21Q6"),
+ },
+ .driver_data = "SONY471A",
+ },
+ {
+ /* Lenovo X9-15 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_BOARD_NAME, "21Q7"),
+ },
+ .driver_data = "SONY471A",
+ },
{} /* Terminating entry */
};
--
2.54.0
^ permalink raw reply related
* [PATCH v5 0/3] Add Sony IMX471 camera sensor driver
From: Kate Hsuan @ 2026-06-24 3:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans de Goede, Hans Verkuil, Sakari Ailus,
Serin Yeh, Tarang Raval, Damjan Georgievski
Cc: linux-media, linux-kernel, Kate Hsuan
This patchset adds the Sony IMX471 camera sensor driver to the Linux
kernel and resolves the IPU7 camera can't work issueon Lenovo X9
laptops [1].
The patchset contains two patches:
1. Add DMI information of Lenovo X9 to the image upside-down list
2. Add Sony IMX471 image sensor driver
The IMX471 driver can be found in the Intel ipu6-drivers repository [2].
To comply with the sensor driver implementation, the clean-up work
includes:
1. Use CCI register helpers.
2. Enable and disable streams using enable_streams and disable_streams
functions in struct v4l2_subdev_pad_ops. Invoke
v4l2_subdev_s_stream_helper() to manage the streaming state.
3. Get rotation information from fwnode properties using
v4l2_fwnode_device_parse().
4. Finalizes the initialization of the subdev, including allocation of
the active state using v4l2_subdev_init_finalize().
5. Add the IMX471 driver to the Makefile and Kconfig file.
6. The mutex lock is managed by the V4l2 core.
7. Replace the supported link frequency with v4l2_link_freq_to_bitmap().
8. Drop unused codes.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2454119
[2] https://github.com/intel/ipu6-drivers/commits/master/drivers/media/i2c/imx471.c
Changes in v5:
1. Add a description for the DMI_BOARD_NAME in the ipu-bridge driver.
2. Check the numbers of MIPI lanes. The driver only support 4 lanes mode.
3. Fix many rumetime PM issues.
4. Drop pixel_rate control variable.
5. Drop unnecessary comments.
6. Name the registers.
7. Fix a leak in imx471_init_controls().
Changes in v4:
1. Add TBE20A0 (found on Lenovo X1 Carbon G14) to the supported sensors list.
2. Revert the sensor upside-down list to v1.
3. Decrease the max analog gain to 800 to mitigate the image flickering problem.
4. Return the error value when __v4l2_ctrl_modify_range() fails.
5. Fix indentation issue in Kconfig.
6. Fix the cci error value issue.
7. Drop unnecessary comments.
8. Drop unused link_freq control variable.
Changes in v3:
1. Naming the register addresses and set up the value with the correct value length.
2. Implement the .get_selection().
3. Drop "identified" field from struct imx471.
4. Drop "streaming" field from struct imx471 and use the __v4l2_ctrl_grab() instead.
5. Moreover, The naming for the register can be found in a seperated patch. If we
agree with the patch, I will squash it into one patch.
Changes in v2:
1. Change the Bayer format setting according to the vertical and horizontal flip settings.
2. Replace the self-owned mutex with the v4l2 subdev state.
3. Rework the flip control.
4. Manage the regulators using devm_regulator_bulk_get|disable|enbale API
5. Invoke devm_v4l2_sensor_clk_get to get clock-frequency
Kate Hsuan (3):
media: ipu-bridge: Add DMI information of Lenovo X9 to the image
upside-down list
media: ipu-bridge: Add Sony IMX471 for Lenovo X1 Carbon G14
media: i2c: imx471: Add Sony IMX471 image sensor driver
MAINTAINERS | 6 +
drivers/media/i2c/Kconfig | 10 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx471.c | 971 +++++++++++++++++++++++++++
drivers/media/pci/intel/ipu-bridge.c | 41 ++
5 files changed, 1029 insertions(+)
create mode 100644 drivers/media/i2c/imx471.c
--
2.54.0
^ permalink raw reply
* RE: [PATCH 4/4] media: qcom: camss: use fwnode_graph_for_each_endpoint_scoped() to simpifly code
From: G.N. Zhou @ 2026-06-24 3:17 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-4-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 4/4] media: qcom: camss: use
> fwnode_graph_for_each_endpoint_scoped() to simpifly code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use fwnode_graph_for_each_endpoint_scoped() to simpifly code.
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
>
> No functional changes.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/platform/qcom/camss/camss.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss.c
> b/drivers/media/platform/qcom/camss/camss.c
> index 2123f6388e3d7..23f3cc30a15a5 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -4793,30 +4793,23 @@ static int camss_parse_endpoint_node(struct
> device *dev, static int camss_parse_ports(struct camss *camss) {
> struct device *dev = camss->dev;
> - struct fwnode_handle *fwnode = dev_fwnode(dev), *ep;
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> int ret;
>
> - fwnode_graph_for_each_endpoint(fwnode, ep) {
> + fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
> struct camss_async_subdev *csd;
>
> csd = v4l2_async_nf_add_fwnode_remote(&camss->notifier,
> ep,
> typeof(*csd));
> - if (IS_ERR(csd)) {
> - ret = PTR_ERR(csd);
> - goto err_cleanup;
> - }
> + if (IS_ERR(csd))
> + return PTR_ERR(csd);
>
> ret = camss_parse_endpoint_node(dev, ep, csd);
> if (ret < 0)
> - goto err_cleanup;
> + return ret;
> }
>
> return 0;
> -
> -err_cleanup:
> - fwnode_handle_put(ep);
> -
> - return ret;
> }
>
> /*
>
> --
> 2.43.0
^ permalink raw reply
* RE: [PATCH 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: G.N. Zhou @ 2026-06-24 3:15 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-2-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 2/4] media: mc: use
> fwnode_graph_for_each_endpoint_scoped() to simpilfy code
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
s/simpifly/simplify/ both in message title and body.
With this addressed:
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> code.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-
> mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@
> EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags) {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint)
> {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct
> v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
>
> --
> 2.43.0
^ permalink raw reply
* RE: [PATCH 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: G.N. Zhou @ 2026-06-24 2:54 UTC (permalink / raw)
To: Frank Li (OSS), Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Mauro Carvalho Chehab, Dafna Hirschfeld,
Laurent Pinchart, Heiko Stuebner, Bryan O'Donoghue,
Vladimir Zapolskiy, Loic Poulain
Cc: driver-core@lists.linux.dev, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, Frank Li
In-Reply-To: <20260622-fw_scoped-v1-1-a37d0aac0a68@nxp.com>
Hi Frank,
> -----Original Message-----
> From: Frank Li (OSS) <frank.li@oss.nxp.com>
> Sent: Monday, June 22, 2026 10:30 PM
> To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; Daniel Scally
> <djrscally@gmail.com>; Heikki Krogerus <heikki.krogerus@linux.intel.com>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Rafael J. Wysocki <rafael@kernel.org>; Danilo
> Krummrich <dakr@kernel.org>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Dafna Hirschfeld <dafna@fastmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Heiko Stuebner
> <heiko@sntech.de>; Bryan O'Donoghue <bryan.odonoghue@linaro.org>;
> Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>; Loic Poulain
> <loic.poulain@oss.qualcomm.com>
> Cc: driver-core@lists.linux.dev; linux-acpi@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; imx@lists.linux.dev; G.N. Zhou
> <guoniu.zhou@nxp.com>; Frank Li <frank.li@nxp.com>
> Subject: [PATCH 1/4] device property: Introduce
> fwnode_graph_for_each_endpoint_scoped()
>
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new version
> of the loop macro instantiates a new local struct fwnode_handle * that uses the
> __free(fwnode_handle) auto cleanup handling so that if a reference to a node is
> held on early exit from the loop the reference will be released. If the loop runs
> to completion, the child pointer will be NULL and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to safely
> disable the auto cleanup.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h index
> 14c304db46648..ade194c462d42 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int
> fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child;
> \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child)
> \
> + for (struct fwnode_handle *child __free(fwnode_handle) =
> \
> + fwnode_graph_get_next_endpoint(fwnode, NULL);
> \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
>
> --
> 2.43.0
^ permalink raw reply
* Re: Support for Mygica A681B (ATSC/QAM USB tuner)
From: Michael Goffioul @ 2026-06-24 2:30 UTC (permalink / raw)
To: Forest Crossman; +Cc: linux-media
In-Reply-To: <CAO3ALPxbYGG5fxO1Dd989bjg=a4xRLBSDwtDL41Bd9ym7pt6KQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4560 bytes --]
On Tue, Oct 14, 2025 at 1:42 PM Forest Crossman <cyrozap@gmail.com> wrote:
> On Tue, Oct 14, 2025 at 9:13 AM Michael Goffioul
> <michael.goffioul@gmail.com> wrote:
> >
> > On Fri, Oct 10, 2025 at 11:22 AM Forest Crossman <cyrozap@gmail.com>
> wrote:
> >>
> >> On Sun, Jun 22, 2025 at 8:46 PM Michael Goffioul
> >> <michael.goffioul@gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I have a Mygica A681B USB tuner and I'm wondering whether there's any
> >> > hope to have it supported by the Linux kernel. I've attached the lsusb
> >> > output for the device at the end of this email.
> >> >
> >> > So far, I've downloaded the Linux driver from Geniatech web site. This
> >> > is made for Ubuntu 20 and kernel 5.4. From what I can tell from the
> >> > driver sources, the device 1f4d:692f seems to use a mxl692 frontend
> >> > driver, but it uses a binary-only mxl692_fe.o module, without
> >> > providing the source code for it. Kernel 6 includes its own mxl692
> >> > driver, however it appears to use a different interface/API (and
> >> > apparently also a firmware blob that does not look to be easy to
> >> > find...).
> >> >
> >> > Any help or hint would be greatly appreciated.
> >> >
> >> > Michael.
> >>
> >> Hi, Michael,
> >>
> >> I've recently submitted some patches [1] to enable support for the
> >> A681B and its more-compact USB-C sibling, the PT682C. The patches are
> >> not yet ready for mainline (hence why I marked them "RFC"), but
> >> they're good enough to get the hardware working and streaming TV from
> >> over the air. If you're willing to patch your kernel, the patches
> >> should get you up and running while you wait for support in mainline
> >> or your distro's kernel.
> >>
> >> Also, while the cover letter for the patch series contains a link to a
> >> script I wrote to download and extract the firmware image from the
> >> Windows driver, I recently learned that the firmware can simply be
> >> downloaded directly from here [2].
> >>
> >> I hope this helps!
> >>
> >> Forest
> >>
> >> [1]:
> https://lore.kernel.org/linux-media/20251001051534.925714-1-cyrozap@gmail.com/T/
> >> [2]:
> https://github.com/LibreELEC/dvb-firmware/blob/90261ae2934329f6ca84dd6c72d10d0777bf4b0e/firmware/dvb-demod-mxl692.fw
> >
> >
> > Hi Forest,
> >
> > Thanks for the info. I will give it a try when I get a chance.
> >
> > Do you know whether this would support Clear QAM too? While I had some
> > success with ATSC with some reverse engineering, I was not able to get
> > the device to work with QAM (with the device directly connected to a
> > VeCOAX modulator).
> >
> > Thanks,
> > Michael.
> >
>
> Michael,
>
> No, I don't think QAM works yet. The message for the commit that added
> the mxl692 driver to the kernel mentions that "Only ATSC is currently
> advertised via DVB properties. QAM still has issues." And the patch
> series cover letter[1] mentions "The ATSC portion works fully, the QAM
> portion needs some TLC and is therefore not listed in the DVB
> capabilities." Since no commits have been added since then to get QAM
> demod working, I think it probably still doesn't work. Not that I've
> tried, though--my first objective was to just get the driver for the
> A681B and PT682C working, then maybe later if I could get a Clear QAM
> source up and running (I have some SDRs that can do this, but I
> haven't used them in years) I'd try getting QAM demod working.
>
> All the best,
> Forest
>
> [1]:
> https://lore.kernel.org/all/20210126015416.5622-1-brad@nextdimension.cc/
Forrest,
I finally found the time to try your driver and I was able to use the
MyGica A681B device on my desktop with ATSC. Additionally, using the
attached patch, I was also able to use Clear QAM (both 64-QAM and 256-QAM,
using a DekTec modulator as source). So, thanks for the driver.
That being said, it didn't work well when using the device connected to an
Android device (which is my target platform). Although the streaming
worked, there were regular streaming errors (video pixelation and buffering
events) making the device unsuitable for normal usage. A Hauppauge WindTV
dual-HD device, used in the exact same test conditions (just swapped with
the MyGica one), worked flawlessly. I didn't observe the same issues
either, when using the MyGica device on my normal desktop. I'm not sure
whether it might be due to the limited resources of the Android box, but if
you have any suggestions, please let me know.
Michael.
[-- Attachment #1.2: Type: text/html, Size: 6199 bytes --]
[-- Attachment #2: mygica-qam.diff --]
[-- Type: text/x-patch, Size: 1441 bytes --]
--- ../backup/drivers/media/dvb-frontends/mxl692.c 2026-06-23 11:31:22.147765006 -0400
+++ drivers/media/dvb-frontends/mxl692.c 2026-06-23 22:14:06.349742396 -0400
@@ -1021,12 +1021,21 @@
goto err;
qam_params.annex_type = qam_annex;
- qam_params.qam_type = MXL_EAGLE_QAM_DEMOD_AUTO;
qam_params.iq_flip = MXL_EAGLE_DEMOD_IQ_AUTO;
- if (p->modulation == QAM_64)
- qam_params.symbol_rate_hz = 5057000;
- else
- qam_params.symbol_rate_hz = 5361000;
+ switch (p->modulation) {
+ case QAM_64:
+ qam_params.qam_type = MXL_EAGLE_QAM_DEMOD_QAM64;
+ qam_params.symbol_rate_hz = 5057000;
+ break;
+ case QAM_256:
+ qam_params.qam_type = MXL_EAGLE_QAM_DEMOD_QAM256;
+ qam_params.symbol_rate_hz = 5361000;
+ break;
+ default:
+ qam_params.qam_type = MXL_EAGLE_QAM_DEMOD_AUTO;
+ qam_params.symbol_rate_hz = 5361000;
+ break;
+ }
qam_params.symbol_rate_256qam_hz = 5361000;
@@ -1284,13 +1293,13 @@
}
static const struct dvb_frontend_ops mxl692_ops = {
- .delsys = { SYS_ATSC },
+ .delsys = { SYS_ATSC, SYS_DVBC_ANNEX_B },
.info = {
- .name = "MaxLinear MxL692 VSB tuner-demodulator",
+ .name = "MaxLinear MxL692 VSB/QAM tuner-demodulator",
.frequency_min_hz = 54000000,
.frequency_max_hz = 858000000,
.frequency_stepsize_hz = 62500,
- .caps = FE_CAN_8VSB
+ .caps = FE_CAN_8VSB | FE_CAN_QAM_AUTO | FE_CAN_QAM_64 | FE_CAN_QAM_256
},
.init = mxl692_init,
^ permalink raw reply
* [PATCH] media: imx-jpeg: finish the job on device_run() error paths
From: Fan Wu @ 2026-06-24 0:32 UTC (permalink / raw)
To: mirela.rabulea, mchehab
Cc: shawnguo, s.hauer, kernel, festevam, imx, linux-media,
linux-arm-kernel, linux-kernel, stable, Fan Wu
mxc_jpeg_device_run() returns early through a shared "end" label on several
error paths (no free slot, mxc_jpeg_alloc_slot_data() failure, or missing
buffers or queue data), and none of them calls v4l2_m2m_job_finish().
Since the delayed work is queued only after the hardware is started, those
paths neither finish the job directly nor queue timeout work that could
finish it later. The job is left with TRANS_RUNNING set, so the
wait_event() in v4l2_m2m_cancel_job() (reached from v4l2_m2m_ctx_release()
at close) waits indefinitely and the close hangs.
mxc_jpeg_alloc_slot_data() uses dma_alloc_coherent(), so the failure path
is reachable under memory pressure.
Return the src/dst buffers with VB2_BUF_STATE_ERROR and call
v4l2_m2m_job_finish() on those paths: paths that have buffers use a
"buf_finish" label; the no-buffer path uses "job_finish" directly. This
mirrors the existing jpeg_parse_error path.
This bug was found by static analysis.
Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
.../media/platform/nxp/imx-jpeg/mxc-jpeg.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
index 9e4a813489c0..6b224a19f40e 100644
--- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
@@ -1525,15 +1525,15 @@ static void mxc_jpeg_device_run(void *priv)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
if (!src_buf || !dst_buf) {
dev_err(dev, "Null src or dst buf\n");
- goto end;
+ goto job_finish;
}
q_data_cap = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
if (!q_data_cap)
- goto end;
+ goto buf_finish;
q_data_out = mxc_jpeg_get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
if (!q_data_out)
- goto end;
+ goto buf_finish;
src_buf->sequence = q_data_out->sequence++;
dst_buf->sequence = q_data_cap->sequence++;
@@ -1571,11 +1571,11 @@ static void mxc_jpeg_device_run(void *priv)
ctx->slot = mxc_get_free_slot(&jpeg->slot_data);
if (ctx->slot < 0) {
dev_err(dev, "No more free slots\n");
- goto end;
+ goto buf_finish;
}
if (!mxc_jpeg_alloc_slot_data(jpeg)) {
dev_err(dev, "Cannot allocate slot data\n");
- goto end;
+ goto buf_finish;
}
mxc_jpeg_enable_slot(reg, ctx->slot);
@@ -1597,8 +1597,17 @@ static void mxc_jpeg_device_run(void *priv)
mxc_jpeg_dec_mode_go(dev, reg);
}
schedule_delayed_work(&ctx->task_timer, msecs_to_jiffies(hw_timeout));
-end:
+
spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ return;
+buf_finish:
+ v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_ERROR);
+ v4l2_m2m_buf_done(dst_buf, VB2_BUF_STATE_ERROR);
+job_finish:
+ spin_unlock_irqrestore(&ctx->mxc_jpeg->hw_lock, flags);
+ v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
}
static int mxc_jpeg_decoder_cmd(struct file *file, void *priv,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] dma-buf: Split sgl into page-aligned 2G chunks
From: David Laight @ 2026-06-23 22:53 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: David Hu, Sumit Semwal, Christian König, Jason Gunthorpe,
Nicolin Chen, Leon Romanovsky, Kevin Tian, Ankit Agrawal,
Alex Williamson, linux-media, dri-devel, linaro-mm-sig,
linux-kernel, iommu, jmoroni, kpberry, chriscli, sashiko-bot,
stable
In-Reply-To: <ajryxMaT5evDUxaq@google.com>
On Tue, 23 Jun 2026 20:55:32 +0000
Pranjal Shrivastava <praan@google.com> wrote:
> On Tue, Jun 23, 2026 at 09:44:46AM +0100, David Laight wrote:
>
> Hi David,
>
> > On Tue, 23 Jun 2026 01:54:59 +0000
> > David Hu <xuehaohu@google.com> wrote:
> >
> > > Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`.
> > > This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the
> > > first entry, resulting in non-page-aligned DMA addresses for all
> > > subsequent entries.
> >
> > There is a separate issue of whether this code is even needed at all.
> > Where can transfers over 2G (never mind 4G) actually come from.
> >
> > The read, write and similar system calls limit transfers to INT_MAX
> > (even on 64bit) and a lot of driver code will need fixing it longer
> > lengths are allowed though.
> > io_uring better enforce the same limits.
> > So the transfers can come directly from userspace.
> >
> > Not only that but you also need a single physically contiguous buffer.
> > Good luck allocating that!
> >
> > Now maybe there are some peer-to-peer places where the large buffer
> > is device memory, but they will be unusual and probably need
> > special treatment anyway.
> >
>
> I agree that traditional VFS read/write face the MAX_RW_COUNT limit
> (~2GB), and io_uring has its limits, but I'm a little confused by the
> push to enforce these limits here in the SGL code?
>
> File I/O seems to be only one side of the picture. In my view, this fix
> is necessary and certainly has a use-case:
>
> For example, the RDMA subsystem has the capability to import dmabufs [1],
> which gives rise to use cases for dmabuf beyond standard file ops
> (via VFS/io_uring).
>
> In these scenarios, GPU HBM can be exported as dmabufs. With recent GPUs,
> HBM capacity can be in the order of hundreds of GBs [2]. RDMA can employ
> infrastructure like the vfio-dmabuf-exporter [3] or similar dmabuf
> exporters to frequently move huge blocks of data via P2PDMA.
Ok, that explains where big buffers can come from.
I just wasn't sure.
> If we restrict incoming dmabuf transfers to fit within VFS-centric
> limits (2GB), we impose unnecessary overhead on the RDMA stack, forcing
> it to manage a significantly higher number of memory registrations. By
> cleanly splitting these massive contiguous device buffers into
> page-aligned SGL entries, we directly improve the efficiency of P2P
> transfers and memory registration.
But a divide by '4G - PAGE_SIZE' is also non-trivial and (I think affects
a lot of io) when the quotient is always 1.
Splitting into 2G chunks is a lot cheaper.
> Since this change doesn't seem to have a negative impact on standard file
> I/O or break existing VFS constraints, I'm curious why we shouldn't
> support splitting these >4GB P2P transfers? Am I missing something?
I was only wondering whether it was needed...
It does bring up the question of why the >4GB transfers even need splitting.
But that is another question.
If you want to split large transfers into 4G-PAGE_SIZE blocks
it is probably worth having a quick test that returns 1 for 'small' buffers.
David
>
> Thanks,
> Praan
>
> [1] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/infiniband/core/umem_dmabuf.c#L174
> [2] https://nvdam.widen.net/s/fdvdqvfvj2/hopper-h200-nvl-product-brief (Table 2-2)
> [3] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/vfio/pci/vfio_pci_dmabuf.c#L297
>
^ permalink raw reply
* [PATCH v3 3/3] staging: media: atomisp: drop redundant out-of-memory messages
From: Rodrigo Gobbi @ 2026-06-23 22:09 UTC (permalink / raw)
To: andy, hansg, mchehab, sakari.ailus, gregkh, feng
Cc: ~lkcamp/patches, linux-kernel-mentees, linux-kernel, linux-media,
linux-staging
In-Reply-To: <20260623221028.40238-1-rodrigo.gobbi.7@gmail.com>
On allocation failure the memory management core already emits a
detailed warning, so the driver's own IA_CSS_ERROR("out of memory")
lines add nothing but noise.
Remove them; the error handling itself is left unchanged.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
---
drivers/staging/media/atomisp/pci/sh_css_param_dvs.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_param_dvs.c b/drivers/staging/media/atomisp/pci/sh_css_param_dvs.c
index ad2a9b84e232..c0102056d421 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_param_dvs.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_param_dvs.c
@@ -25,7 +25,6 @@ alloc_dvs_6axis_table(const struct ia_css_resolution *frame_res,
dvs_config = kvmalloc_obj(struct ia_css_dvs_6axis_config);
if (!dvs_config) {
- IA_CSS_ERROR("out of memory");
err = -ENOMEM;
} else {
/*Initialize new struct with latest config settings*/
@@ -52,7 +51,6 @@ alloc_dvs_6axis_table(const struct ia_css_resolution *frame_res,
dvs_config->xcoords_y = kvmalloc(array3_size(width_y, height_y, sizeof(uint32_t)),
GFP_KERNEL);
if (!dvs_config->xcoords_y) {
- IA_CSS_ERROR("out of memory");
err = -ENOMEM;
goto exit;
}
@@ -60,7 +58,6 @@ alloc_dvs_6axis_table(const struct ia_css_resolution *frame_res,
dvs_config->ycoords_y = kvmalloc(array3_size(width_y, height_y, sizeof(uint32_t)),
GFP_KERNEL);
if (!dvs_config->ycoords_y) {
- IA_CSS_ERROR("out of memory");
err = -ENOMEM;
goto exit;
}
@@ -72,7 +69,6 @@ alloc_dvs_6axis_table(const struct ia_css_resolution *frame_res,
sizeof(uint32_t)),
GFP_KERNEL);
if (!dvs_config->xcoords_uv) {
- IA_CSS_ERROR("out of memory");
err = -ENOMEM;
goto exit;
}
@@ -81,7 +77,6 @@ alloc_dvs_6axis_table(const struct ia_css_resolution *frame_res,
sizeof(uint32_t)),
GFP_KERNEL);
if (!dvs_config->ycoords_uv) {
- IA_CSS_ERROR("out of memory");
err = -ENOMEM;
}
exit:
--
2.48.1
^ permalink raw reply related
* [PATCH v3 2/3] staging: media: atomisp: use kvmalloc_objs() for overflow-safe allocation
From: Rodrigo Gobbi @ 2026-06-23 22:09 UTC (permalink / raw)
To: andy, hansg, mchehab, sakari.ailus, gregkh, feng
Cc: ~lkcamp/patches, linux-kernel-mentees, linux-kernel, linux-media,
linux-staging
In-Reply-To: <20260623221028.40238-1-rodrigo.gobbi.7@gmail.com>
From: Feng Ning <feng@innora.ai>
Replace open-coded width * height * sizeof() multiplications with
kvmalloc_objs() and array_size() to prevent integer overflow in buffer
allocations.
The atomisp driver computes DVS and statistics buffer sizes using
unchecked arithmetic. When dimensions are large, the product can
silently wrap, causing kvmalloc() to allocate an undersized buffer.
kvmalloc_objs() uses size_mul() internally, which saturates to SIZE_MAX
on overflow, so kvmalloc() returns NULL instead of succeeding with too
few bytes. array_size() provides the same overflow protection for the
two-factor dimension products.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Feng Ning <feng@innora.ai>
[rodrigo: rebased; convert only the sites left open-coded after
commit d178c7ca8fef]
Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
---
.../staging/media/atomisp/pci/sh_css_params.c | 101 +++++++-----------
1 file changed, 36 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c b/drivers/staging/media/atomisp/pci/sh_css_params.c
index 8420a22fd8f0..adc329be8b0b 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_params.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_params.c
@@ -6,6 +6,7 @@
#include <linux/overflow.h>
#include <linux/math.h>
+#include <linux/slab.h>
#include "gdc_device.h" /* gdc_lut_store(), ... */
#include "isp.h" /* ISP_VEC_ELEMBITS */
@@ -4151,7 +4152,7 @@ struct ia_css_3a_statistics *
ia_css_3a_statistics_allocate(const struct ia_css_3a_grid_info *grid)
{
struct ia_css_3a_statistics *me;
- int grid_size;
+ size_t grid_size;
IA_CSS_ENTER("grid=%p", grid);
@@ -4162,8 +4163,8 @@ ia_css_3a_statistics_allocate(const struct ia_css_3a_grid_info *grid)
goto err;
me->grid = *grid;
- grid_size = grid->width * grid->height;
- me->data = kvmalloc(grid_size * sizeof(*me->data), GFP_KERNEL);
+ grid_size = array_size(grid->width, grid->height);
+ me->data = kvmalloc_objs(*me->data, grid_size);
if (!me->data)
goto err;
/* No weighted histogram, no structure, treat the histogram data as a byte dump in a byte array */
@@ -4236,6 +4237,7 @@ struct ia_css_dvs_coefficients *
ia_css_dvs_coefficients_allocate(const struct ia_css_dvs_grid_info *grid)
{
struct ia_css_dvs_coefficients *me;
+ size_t cnt;
assert(grid);
@@ -4245,15 +4247,13 @@ ia_css_dvs_coefficients_allocate(const struct ia_css_dvs_grid_info *grid)
me->grid = *grid;
- me->hor_coefs = kvmalloc(grid->num_hor_coefs *
- IA_CSS_DVS_NUM_COEF_TYPES *
- sizeof(*me->hor_coefs), GFP_KERNEL);
+ cnt = array_size(grid->num_hor_coefs, IA_CSS_DVS_NUM_COEF_TYPES);
+ me->hor_coefs = kvmalloc_objs(*me->hor_coefs, cnt);
if (!me->hor_coefs)
goto err;
- me->ver_coefs = kvmalloc(grid->num_ver_coefs *
- IA_CSS_DVS_NUM_COEF_TYPES *
- sizeof(*me->ver_coefs), GFP_KERNEL);
+ cnt = array_size(grid->num_ver_coefs, IA_CSS_DVS_NUM_COEF_TYPES);
+ me->ver_coefs = kvmalloc_objs(*me->ver_coefs, cnt);
if (!me->ver_coefs)
goto err;
@@ -4277,6 +4277,7 @@ struct ia_css_dvs2_statistics *
ia_css_dvs2_statistics_allocate(const struct ia_css_dvs_grid_info *grid)
{
struct ia_css_dvs2_statistics *me;
+ size_t cnt;
assert(grid);
@@ -4286,59 +4287,37 @@ ia_css_dvs2_statistics_allocate(const struct ia_css_dvs_grid_info *grid)
me->grid = *grid;
- me->hor_prod.odd_real = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->hor_prod.odd_real),
- GFP_KERNEL);
+ cnt = array_size(grid->aligned_width, grid->aligned_height);
+
+ me->hor_prod.odd_real = kvmalloc_objs(*me->hor_prod.odd_real, cnt);
if (!me->hor_prod.odd_real)
goto err;
- me->hor_prod.odd_imag = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->hor_prod.odd_imag),
- GFP_KERNEL);
+ me->hor_prod.odd_imag = kvmalloc_objs(*me->hor_prod.odd_imag, cnt);
if (!me->hor_prod.odd_imag)
goto err;
- me->hor_prod.even_real = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->hor_prod.even_real),
- GFP_KERNEL);
+ me->hor_prod.even_real = kvmalloc_objs(*me->hor_prod.even_real, cnt);
if (!me->hor_prod.even_real)
goto err;
- me->hor_prod.even_imag = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->hor_prod.even_imag),
- GFP_KERNEL);
+ me->hor_prod.even_imag = kvmalloc_objs(*me->hor_prod.even_imag, cnt);
if (!me->hor_prod.even_imag)
goto err;
- me->ver_prod.odd_real = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->ver_prod.odd_real),
- GFP_KERNEL);
+ me->ver_prod.odd_real = kvmalloc_objs(*me->ver_prod.odd_real, cnt);
if (!me->ver_prod.odd_real)
goto err;
- me->ver_prod.odd_imag = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->ver_prod.odd_imag),
- GFP_KERNEL);
+ me->ver_prod.odd_imag = kvmalloc_objs(*me->ver_prod.odd_imag, cnt);
if (!me->ver_prod.odd_imag)
goto err;
- me->ver_prod.even_real = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->ver_prod.even_real),
- GFP_KERNEL);
+ me->ver_prod.even_real = kvmalloc_objs(*me->ver_prod.even_real, cnt);
if (!me->ver_prod.even_real)
goto err;
- me->ver_prod.even_imag = kvmalloc(grid->aligned_width *
- grid->aligned_height *
- sizeof(*me->ver_prod.even_imag),
- GFP_KERNEL);
+ me->ver_prod.even_imag = kvmalloc_objs(*me->ver_prod.even_imag, cnt);
if (!me->ver_prod.even_imag)
goto err;
@@ -4377,51 +4356,43 @@ ia_css_dvs2_coefficients_allocate(const struct ia_css_dvs_grid_info *grid)
me->grid = *grid;
- me->hor_coefs.odd_real = kvmalloc(grid->num_hor_coefs *
- sizeof(*me->hor_coefs.odd_real),
- GFP_KERNEL);
+ me->hor_coefs.odd_real = kvmalloc_objs(*me->hor_coefs.odd_real,
+ grid->num_hor_coefs);
if (!me->hor_coefs.odd_real)
goto err;
- me->hor_coefs.odd_imag = kvmalloc(grid->num_hor_coefs *
- sizeof(*me->hor_coefs.odd_imag),
- GFP_KERNEL);
+ me->hor_coefs.odd_imag = kvmalloc_objs(*me->hor_coefs.odd_imag,
+ grid->num_hor_coefs);
if (!me->hor_coefs.odd_imag)
goto err;
- me->hor_coefs.even_real = kvmalloc(grid->num_hor_coefs *
- sizeof(*me->hor_coefs.even_real),
- GFP_KERNEL);
+ me->hor_coefs.even_real = kvmalloc_objs(*me->hor_coefs.even_real,
+ grid->num_hor_coefs);
if (!me->hor_coefs.even_real)
goto err;
- me->hor_coefs.even_imag = kvmalloc(grid->num_hor_coefs *
- sizeof(*me->hor_coefs.even_imag),
- GFP_KERNEL);
+ me->hor_coefs.even_imag = kvmalloc_objs(*me->hor_coefs.even_imag,
+ grid->num_hor_coefs);
if (!me->hor_coefs.even_imag)
goto err;
- me->ver_coefs.odd_real = kvmalloc(grid->num_ver_coefs *
- sizeof(*me->ver_coefs.odd_real),
- GFP_KERNEL);
+ me->ver_coefs.odd_real = kvmalloc_objs(*me->ver_coefs.odd_real,
+ grid->num_ver_coefs);
if (!me->ver_coefs.odd_real)
goto err;
- me->ver_coefs.odd_imag = kvmalloc(grid->num_ver_coefs *
- sizeof(*me->ver_coefs.odd_imag),
- GFP_KERNEL);
+ me->ver_coefs.odd_imag = kvmalloc_objs(*me->ver_coefs.odd_imag,
+ grid->num_ver_coefs);
if (!me->ver_coefs.odd_imag)
goto err;
- me->ver_coefs.even_real = kvmalloc(grid->num_ver_coefs *
- sizeof(*me->ver_coefs.even_real),
- GFP_KERNEL);
+ me->ver_coefs.even_real = kvmalloc_objs(*me->ver_coefs.even_real,
+ grid->num_ver_coefs);
if (!me->ver_coefs.even_real)
goto err;
- me->ver_coefs.even_imag = kvmalloc(grid->num_ver_coefs *
- sizeof(*me->ver_coefs.even_imag),
- GFP_KERNEL);
+ me->ver_coefs.even_imag = kvmalloc_objs(*me->ver_coefs.even_imag,
+ grid->num_ver_coefs);
if (!me->ver_coefs.even_imag)
goto err;
--
2.48.1
^ permalink raw reply related
* [PATCH v3 1/3] staging: media: atomisp: use kvmalloc_objs() in make_histogram()
From: Rodrigo Gobbi @ 2026-06-23 22:09 UTC (permalink / raw)
To: andy, hansg, mchehab, sakari.ailus, gregkh, feng
Cc: ~lkcamp/patches, linux-kernel-mentees, linux-kernel, linux-media,
linux-staging
In-Reply-To: <20260623221028.40238-1-rodrigo.gobbi.7@gmail.com>
Replace kvmalloc() with multiply with kvmalloc_objs(), which handles
the size multiplication internally with overflow checking, silenting
checkpatch warn.
Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
---
drivers/staging/media/atomisp/pci/sh_css_metrics.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/sh_css_metrics.c b/drivers/staging/media/atomisp/pci/sh_css_metrics.c
index edf473dd86ca..90d92ab8d52b 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_metrics.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_metrics.c
@@ -4,6 +4,8 @@
* Copyright (c) 2015, Intel Corporation.
*/
+#include <linux/slab.h>
+
#include "assert_support.h"
#include "sh_css_metrics.h"
@@ -59,16 +61,13 @@ make_histogram(struct sh_css_pc_histogram *histogram, unsigned int length)
return;
if (histogram->run)
return;
- histogram->run = kvmalloc(length * sizeof(*histogram->run),
- GFP_KERNEL);
+ histogram->run = kvmalloc_objs(*histogram->run, length);
if (!histogram->run)
return;
- histogram->stall = kvmalloc(length * sizeof(*histogram->stall),
- GFP_KERNEL);
+ histogram->stall = kvmalloc_objs(*histogram->stall, length);
if (!histogram->stall)
return;
- histogram->msink = kvmalloc(length * sizeof(*histogram->msink),
- GFP_KERNEL);
+ histogram->msink = kvmalloc_objs(*histogram->msink, length);
if (!histogram->msink)
return;
--
2.48.1
^ permalink raw reply related
* [PATCH v3 0/3] staging: media: atomisp: use kvmalloc_objs() and drop redundant OOM messages
From: Rodrigo Gobbi @ 2026-06-23 22:09 UTC (permalink / raw)
To: andy, hansg, mchehab, sakari.ailus, gregkh, feng
Cc: ~lkcamp/patches, linux-kernel-mentees, linux-kernel, linux-media,
linux-staging
Several allocations in the atomisp driver still size their buffers with
open-coded multiplication, e.g. width * height * sizeof(*p). When the
dimensions are large the product can silently wrap, causing kvmalloc()
to allocate an undersized buffer.
Convert the remaining sites to kvmalloc_objs() with array_size(), which
saturate to SIZE_MAX on overflow so kvmalloc() returns NULL instead of
allocating too few bytes.
This continues the work started in commit [2], and picks up the stalled
sites from [1], unifying with [3].
While here, drop the redundant IA_CSS_ERROR("out of memory") messages on
the touched allocation paths: the memory management core already emits a
far more detailed warning on allocation failure as raised at [1].
[1] https://lore.kernel.org/all/20260413112904.98864-1-feng@innora.ai/
[2] https://github.com/torvalds/linux/commit/d178c7ca8fefc28115d35b94c3b1f4d653e34182
[3] https://lore.kernel.org/all/20260609215110.118860-1-rodrigo.gobbi.7@gmail.com/
---
Changelog:
v3: keep original author chain/tags at v2 and v3; minor cnt usage at v2 for readability;
v2: https://lore.kernel.org/all/20260622224402.34001-1-rodrigo.gobbi.7@gmail.com/
v1: https://lore.kernel.org/all/20260609215110.118860-1-rodrigo.gobbi.7@gmail.com/
---
Feng Ning (1):
staging: media: atomisp: use kvmalloc_objs() for overflow-safe
allocation
Rodrigo Gobbi (2):
staging: media: atomisp: use kvmalloc_objs() in make_histogram()
staging: media: atomisp: drop redundant out-of-memory messages
.../media/atomisp/pci/sh_css_metrics.c | 11 +-
.../media/atomisp/pci/sh_css_param_dvs.c | 5 -
.../staging/media/atomisp/pci/sh_css_params.c | 101 +++++++-----------
3 files changed, 41 insertions(+), 76 deletions(-)
--
2.48.1
^ permalink raw reply
* Re: [PATCH] dma-buf: Split sgl by largest page-aligned chunk
From: David Hu @ 2026-06-23 21:03 UTC (permalink / raw)
To: David Laight
Cc: Sumit Semwal, Christian König, Jason Gunthorpe, Nicolin Chen,
Leon Romanovsky, Kevin Tian, Ankit Agrawal, Alex Williamson,
linux-media, dri-devel, linaro-mm-sig, linux-kernel, iommu,
jmoroni, praan, kpberry, sashiko-bot, stable
In-Reply-To: <20260623092501.17bef195@pumpkin>
On Tue, Jun 23, 2026 at 4:25 AM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Mon, 22 Jun 2026 17:26:10 -0400
> David Hu <xuehaohu@google.com> wrote:
>
> > On Mon, Jun 22, 2026 at 4:13 AM David Laight
> > <david.laight.linux@gmail.com> wrote:
> > >
> >
> > Hi David,
> >
> > Thank you for your review. You raised many good points regarding
> > optimizations here. I'll switch to using 2G as the max entry size
> > (`SZ_2G` from `linux/sizes.h`), and remove divisions and
> > multiplications. I'll also replace the `for()` loop with `while
> > (length)`, and drop `min_t()` in favor of `min()` by casting `SZ_2G`
> > to `size_t`.
>
> You shouldn't need a cast at all.
Hi David,
You are right. It looks like `min(length, CONSTANT)` works well here
without triggering any type mismatch warnings, regardless of whether
`CONSTANT` is `SZ_1G` (`int`), `SZ_2G` (`unsigned int`), `SZ_4G`
(`unsigned long long`), or larger. I'll drop the cast and send out a
v3 shortly.
Thanks,
David
^ permalink raw reply
* Re: [PATCH v2] dma-buf: Split sgl into page-aligned 2G chunks
From: Pranjal Shrivastava @ 2026-06-23 20:55 UTC (permalink / raw)
To: David Laight
Cc: David Hu, Sumit Semwal, Christian König, Jason Gunthorpe,
Nicolin Chen, Leon Romanovsky, Kevin Tian, Ankit Agrawal,
Alex Williamson, linux-media, dri-devel, linaro-mm-sig,
linux-kernel, iommu, jmoroni, kpberry, chriscli, sashiko-bot,
stable
In-Reply-To: <20260623094446.4a8fc2ed@pumpkin>
On Tue, Jun 23, 2026 at 09:44:46AM +0100, David Laight wrote:
Hi David,
> On Tue, 23 Jun 2026 01:54:59 +0000
> David Hu <xuehaohu@google.com> wrote:
>
> > Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`.
> > This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the
> > first entry, resulting in non-page-aligned DMA addresses for all
> > subsequent entries.
>
> There is a separate issue of whether this code is even needed at all.
> Where can transfers over 2G (never mind 4G) actually come from.
>
> The read, write and similar system calls limit transfers to INT_MAX
> (even on 64bit) and a lot of driver code will need fixing it longer
> lengths are allowed though.
> io_uring better enforce the same limits.
> So the transfers can come directly from userspace.
>
> Not only that but you also need a single physically contiguous buffer.
> Good luck allocating that!
>
> Now maybe there are some peer-to-peer places where the large buffer
> is device memory, but they will be unusual and probably need
> special treatment anyway.
>
I agree that traditional VFS read/write face the MAX_RW_COUNT limit
(~2GB), and io_uring has its limits, but I'm a little confused by the
push to enforce these limits here in the SGL code?
File I/O seems to be only one side of the picture. In my view, this fix
is necessary and certainly has a use-case:
For example, the RDMA subsystem has the capability to import dmabufs [1],
which gives rise to use cases for dmabuf beyond standard file ops
(via VFS/io_uring).
In these scenarios, GPU HBM can be exported as dmabufs. With recent GPUs,
HBM capacity can be in the order of hundreds of GBs [2]. RDMA can employ
infrastructure like the vfio-dmabuf-exporter [3] or similar dmabuf
exporters to frequently move huge blocks of data via P2PDMA.
If we restrict incoming dmabuf transfers to fit within VFS-centric
limits (2GB), we impose unnecessary overhead on the RDMA stack, forcing
it to manage a significantly higher number of memory registrations. By
cleanly splitting these massive contiguous device buffers into
page-aligned SGL entries, we directly improve the efficiency of P2P
transfers and memory registration.
Since this change doesn't seem to have a negative impact on standard file
I/O or break existing VFS constraints, I'm curious why we shouldn't
support splitting these >4GB P2P transfers? Am I missing something?
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/infiniband/core/umem_dmabuf.c#L174
[2] https://nvdam.widen.net/s/fdvdqvfvj2/hopper-h200-nvl-product-brief (Table 2-2)
[3] https://elixir.bootlin.com/linux/v7.1.1/source/drivers/vfio/pci/vfio_pci_dmabuf.c#L297
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:44AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v3 1/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
From: Matt Evans @ 2026-06-23 17:47 UTC (permalink / raw)
To: Robin Murphy, Tian, Kevin, Pranjal Shrivastava
Cc: Alex Williamson, Leon Romanovsky, Jason Gunthorpe, Alex Mastro,
Christian König, Bjorn Helgaas, Logan Gunthorpe,
Mahmoud Adam, David Matlack, Björn Töpel, Sumit Semwal,
Ankit Agrawal, Alistair Popple, Kasireddy, Vivek,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <88a9ebaa-8637-4290-b299-acae0e3065f8@ozlabs.org>
Hi Robin, me,
On 23/06/2026 16:59, Matt Evans wrote:
> Heya Robin,
>
> On 23/06/2026 16:48, Robin Murphy wrote:
>> On 12/06/2026 3:31 pm, Matt Evans wrote:
>>> Hi Kevin, Pranjal, (+Robin, hi!)
>>
>> Oh hey there! :)
>>
>>> On 12/06/2026 04:39, Tian, Kevin wrote:
>>>>> From: Pranjal Shrivastava <praan@google.com>
>>>>> Sent: Friday, June 12, 2026 2:38 AM
>>>>>
>>>>> On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote:
>>>>>> --- a/drivers/pci/Kconfig
>>>>>> +++ b/drivers/pci/Kconfig
>>>>>> @@ -206,11 +206,7 @@ config PCIE_TPH
>>>>>> config PCI_P2PDMA
>>>>>> bool "PCI peer-to-peer transfer support"
>>>>>> depends on ZONE_DEVICE
>>>>>> - #
>>>>>> - # The need for the scatterlist DMA bus address flag means PCI
>>>>> P2PDMA
>>>>>> - # requires 64bit
>>>>>> - #
>>>>>> - depends on 64BIT
>>>>>> + select PCI_P2PDMA_CORE
>>>>>> select GENERIC_ALLOCATOR
>>>>>> select NEED_SG_DMA_FLAGS
>>>>>> help
>>>>>
>>>>> Nit: Did we drop depends on 64BIT intentionally here? I guess the full
>>>>> PCI_P2PDMA stack still selects NEED_SG_DMA_FLAGS? IIRC,
>>>>> NEED_SG_DMA_FLAGS doesn't select 64BIT?
>>>>
>>>> seems that comment is stale. According to the commit msg:
>>>>
>>>> " it would make vfio-pci only available if CONFIG_ZONE_DEVICE is
>>>> present (e.g. 64-bit systems), "
>>>>
>>>> so it sounds a redundant dependency hence is removed.
>>>
>>> This was intentional. In practice there is still a dependency on 64BIT
>>> for PCI_P2PDMA, but it is because of ZONE_DEVICE (and mem hotplug). The
>>> key need is PCI_P2PDMA_CORE is available on !64BIT for VFIO, but I
>>> didn't see a requirement from PCI_P2PDMA itself (as opposed to its
>>> dependencies). If I've missed one, I can put it back...
>>>
>>> But NEED_SG_DMA_FLAGS doesn't smell quite right; I see from comments in
>>>
>>> af2880ec44021 ("scatterlist: add dedicated config for DMA flags")
>>>
>>> that it assumes 64BIT, but it seems to be missing a "depends on 64BIT".
>>>
>>> Robin -- should that depend on 64BIT?
>>
>> Indeed, looking at the history it seems like that was overlooked, but it
>> worked out at the time since the only selector of NEED_SG_DMA_FLAGS was
>> PCI_P2PDMA as you say. If we're now generalising then moving the
>> explicit 64BIT dependency to NEED_SG_DMA_FLAGS itself sounds like the
>> right thing to do.
>
> Cheers for confirming. I'll send a patch separate to this series (since
> the deps work out OK for PCI_P2PDMA for the reasons mentioned).
I think we were wrong, NEED_SG_DMA_FLAGS doesn't _need_ 64BIT.
Other than P2PDMA, the other consumer of NEED_SG_DMA_FLAGS is IOMMU_DMA,
and turns out if one builds an i386 kernel with INTEL_IOMMU (or some
other configs, like Xen) then NEED_SG_DMA_FLAGS is enabled on 32-bit
builds too.
The scatterlist.h comments af2880ec44021 touched are just saying that
_since_ P2PDMA depends on 64BIT, there _is_ circumstantial padding so
let's use it for flags. It doesn't require 64BIT.
For example struct scatterlist isn't pushed over some special (e.g.
power-of-two) size when NEED_SG_DMA_FLAGS is enabled on 32-bit; I can't
find a reason it should be prevented on 32-bit builds (and found cases
above in which it is already enabled in them).
So I won't change the NEED_SG_DMA_FLAGS dependencies after all. Sorry
for the noise -- as ever if I've missed something do please explain.
(I'll continue with removing the P2PDMA dependency on 64BIT because it
seems P2PDMA's dependencies rely on 64BIT, though P2PDMA itself doesn't.)
Thanks,
Matt
^ permalink raw reply
* Re: [PATCH v7 01/15] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-06-23 16:31 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, linux-arm-msm, devicetree, dri-devel, freedreno,
linux-media, netdev, linux-wireless, ath12k, linux-remoteproc,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260522115936.201208-2-sumit.garg@kernel.org>
On Fri, May 22, 2026 at 05:29:22PM +0530, Sumit Garg wrote:
> From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> All the existing variants Kodiak boards are using Gunyah hypervisor
> which means that, so far, Linux-based OS could only boot in EL1 on those
> devices. However, it is possible for us to boot Linux at EL2 on these
> devices [1].
>
> When running under Gunyah, the remote processor firmware IOMMU
> streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
> managed by the consumer of this DeviceTree. Therefore, describe the
> firmware streams for each remote processor.
>
> Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
> devices to create -el2.dtb for each of them alongside "normal" dtb.
>
> Note that modem and media subsystems haven't been supported yet due
> to missing dependencies. For GPU to work, zap shader is disabled and
> in EL2 mode the kernel owns hardware watchdog which is enabled here.
>
> [1]
> https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> [SG: watchdog and modem fixup]
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
As discussed internally, I will be taking this patch separately and you
can drop this from series.
--
-Mukesh Ojha
^ permalink raw reply
* [PATCH] v4l2-sysfs-path: Add missing help text
From: saivishnu725 @ 2026-06-23 16:24 UTC (permalink / raw)
To: linux-media; +Cc: saivishnu725
Add a program description to the help output.
The description matches the existing README documentation
to keep the documentation consistent.
Signed-off-by: Sai Vishnu M <saivishnu725@gmail.com>
---
utils/v4l2-sysfs-path/v4l2-sysfs-path.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/utils/v4l2-sysfs-path/v4l2-sysfs-path.c b/utils/v4l2-sysfs-path/v4l2-sysfs-path.c
index d1ad7edb..70da5353 100644
--- a/utils/v4l2-sysfs-path/v4l2-sysfs-path.c
+++ b/utils/v4l2-sysfs-path/v4l2-sysfs-path.c
@@ -30,6 +30,8 @@
const char *argp_program_version = "v4l2-sysfs-path version " V4L_UTILS_VERSION;
const char *argp_program_bug_address = "Mauro Carvalho Chehab <mchehab@kernel.org>";
+static const char doc[] = "Tool to show relationships between V4L2 video devices \
+and other related devices belonging to the same physical device by parsing the sysfs tree.";
static const struct argp_option options[] = {
{"device", 'd', 0, 0, "use alternative device show mode", 0},
@@ -53,6 +55,7 @@ static error_t parse_opt(int k, char *arg, struct argp_state *state)
static struct argp argp = {
.options = options,
.parser = parse_opt,
+ .doc = doc
};
static void print_all_associated_devices(void *md, const char *vid,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 1/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
From: Matt Evans @ 2026-06-23 15:59 UTC (permalink / raw)
To: Robin Murphy, Tian, Kevin, Pranjal Shrivastava
Cc: Alex Williamson, Leon Romanovsky, Jason Gunthorpe, Alex Mastro,
Christian König, Bjorn Helgaas, Logan Gunthorpe,
Mahmoud Adam, David Matlack, Björn Töpel, Sumit Semwal,
Ankit Agrawal, Alistair Popple, Kasireddy, Vivek,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <81a9d212-996e-42e1-aabf-b120a13e94c3@arm.com>
Heya Robin,
On 23/06/2026 16:48, Robin Murphy wrote:
> On 12/06/2026 3:31 pm, Matt Evans wrote:
>> Hi Kevin, Pranjal, (+Robin, hi!)
>
> Oh hey there! :)
>
>> On 12/06/2026 04:39, Tian, Kevin wrote:
>>>> From: Pranjal Shrivastava <praan@google.com>
>>>> Sent: Friday, June 12, 2026 2:38 AM
>>>>
>>>> On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote:
>>>>> --- a/drivers/pci/Kconfig
>>>>> +++ b/drivers/pci/Kconfig
>>>>> @@ -206,11 +206,7 @@ config PCIE_TPH
>>>>> config PCI_P2PDMA
>>>>> bool "PCI peer-to-peer transfer support"
>>>>> depends on ZONE_DEVICE
>>>>> - #
>>>>> - # The need for the scatterlist DMA bus address flag means PCI
>>>> P2PDMA
>>>>> - # requires 64bit
>>>>> - #
>>>>> - depends on 64BIT
>>>>> + select PCI_P2PDMA_CORE
>>>>> select GENERIC_ALLOCATOR
>>>>> select NEED_SG_DMA_FLAGS
>>>>> help
>>>>
>>>> Nit: Did we drop depends on 64BIT intentionally here? I guess the full
>>>> PCI_P2PDMA stack still selects NEED_SG_DMA_FLAGS? IIRC,
>>>> NEED_SG_DMA_FLAGS doesn't select 64BIT?
>>>
>>> seems that comment is stale. According to the commit msg:
>>>
>>> " it would make vfio-pci only available if CONFIG_ZONE_DEVICE is
>>> present (e.g. 64-bit systems), "
>>>
>>> so it sounds a redundant dependency hence is removed.
>>
>> This was intentional. In practice there is still a dependency on 64BIT
>> for PCI_P2PDMA, but it is because of ZONE_DEVICE (and mem hotplug). The
>> key need is PCI_P2PDMA_CORE is available on !64BIT for VFIO, but I
>> didn't see a requirement from PCI_P2PDMA itself (as opposed to its
>> dependencies). If I've missed one, I can put it back...
>>
>> But NEED_SG_DMA_FLAGS doesn't smell quite right; I see from comments in
>>
>> af2880ec44021 ("scatterlist: add dedicated config for DMA flags")
>>
>> that it assumes 64BIT, but it seems to be missing a "depends on 64BIT".
>>
>> Robin -- should that depend on 64BIT?
>
> Indeed, looking at the history it seems like that was overlooked, but it
> worked out at the time since the only selector of NEED_SG_DMA_FLAGS was
> PCI_P2PDMA as you say. If we're now generalising then moving the
> explicit 64BIT dependency to NEED_SG_DMA_FLAGS itself sounds like the
> right thing to do.
Cheers for confirming. I'll send a patch separate to this series (since
the deps work out OK for PCI_P2PDMA for the reasons mentioned).
Ta,
Matt
^ permalink raw reply
* Re: [PATCH v3 1/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE
From: Robin Murphy @ 2026-06-23 15:48 UTC (permalink / raw)
To: Matt Evans, Tian, Kevin, Pranjal Shrivastava
Cc: Alex Williamson, Leon Romanovsky, Jason Gunthorpe, Alex Mastro,
Christian König, Bjorn Helgaas, Logan Gunthorpe,
Mahmoud Adam, David Matlack, Björn Töpel, Sumit Semwal,
Ankit Agrawal, Alistair Popple, Kasireddy, Vivek,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <0dfadf98-a904-4e6a-b078-5caf27bc7922@ozlabs.org>
On 12/06/2026 3:31 pm, Matt Evans wrote:
> Hi Kevin, Pranjal, (+Robin, hi!)
Oh hey there! :)
> On 12/06/2026 04:39, Tian, Kevin wrote:
>>> From: Pranjal Shrivastava <praan@google.com>
>>> Sent: Friday, June 12, 2026 2:38 AM
>>>
>>> On Wed, Jun 10, 2026 at 04:43:15PM +0100, Matt Evans wrote:
>>>> --- a/drivers/pci/Kconfig
>>>> +++ b/drivers/pci/Kconfig
>>>> @@ -206,11 +206,7 @@ config PCIE_TPH
>>>> config PCI_P2PDMA
>>>> bool "PCI peer-to-peer transfer support"
>>>> depends on ZONE_DEVICE
>>>> - #
>>>> - # The need for the scatterlist DMA bus address flag means PCI
>>> P2PDMA
>>>> - # requires 64bit
>>>> - #
>>>> - depends on 64BIT
>>>> + select PCI_P2PDMA_CORE
>>>> select GENERIC_ALLOCATOR
>>>> select NEED_SG_DMA_FLAGS
>>>> help
>>>
>>> Nit: Did we drop depends on 64BIT intentionally here? I guess the full
>>> PCI_P2PDMA stack still selects NEED_SG_DMA_FLAGS? IIRC,
>>> NEED_SG_DMA_FLAGS doesn't select 64BIT?
>>
>> seems that comment is stale. According to the commit msg:
>>
>> " it would make vfio-pci only available if CONFIG_ZONE_DEVICE is
>> present (e.g. 64-bit systems), "
>>
>> so it sounds a redundant dependency hence is removed.
>
> This was intentional. In practice there is still a dependency on 64BIT
> for PCI_P2PDMA, but it is because of ZONE_DEVICE (and mem hotplug). The
> key need is PCI_P2PDMA_CORE is available on !64BIT for VFIO, but I
> didn't see a requirement from PCI_P2PDMA itself (as opposed to its
> dependencies). If I've missed one, I can put it back...
>
> But NEED_SG_DMA_FLAGS doesn't smell quite right; I see from comments in
>
> af2880ec44021 ("scatterlist: add dedicated config for DMA flags")
>
> that it assumes 64BIT, but it seems to be missing a "depends on 64BIT".
>
> Robin -- should that depend on 64BIT?
Indeed, looking at the history it seems like that was overlooked, but it
worked out at the time since the only selector of NEED_SG_DMA_FLAGS was
PCI_P2PDMA as you say. If we're now generalising then moving the
explicit 64BIT dependency to NEED_SG_DMA_FLAGS itself sounds like the
right thing to do.
Cheers,
Robin.
^ permalink raw reply
* Re: [PATCH] drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name()
From: André Draszik @ 2026-06-23 14:33 UTC (permalink / raw)
To: phasta, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Sumit Semwal, Christian König,
Tvrtko Ursulin, Boris Brezillon, Danilo Krummrich
Cc: dri-devel, linux-kernel, linux-media, linaro-mm-sig,
Peter Griffin, Tudor Ambarus, Juan Yescas, kernel-team
In-Reply-To: <f59d6080cf31f424ebcf0e6086b4a93623813a6e.camel@mailbox.org>
Hi Philipp,
On Tue, 2026-06-23 at 13:58 +0200, Philipp Stanner wrote:
> On Tue, 2026-06-23 at 12:37 +0100, André Draszik wrote:
> > On Thu, 2026-06-18 at 17:56 +0200, Philipp Stanner wrote:
> > >
> > > I continue to believe because of bugs like this and the ones I have
> > > quoted in the threads above the robustness of the kernel could be
> > > greatly improved if we could get dma_fence fully synchronized with its
> > > lock.
> >
> > On top of that, sashiko highlighted (via my other patch) that the existing
> > code is missing some memory barriers:
> >
> > https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix-v1-1-801f29c9853d@linaro.org?part=1
> >
> > I believe Lock synchronization would resolve that (as would adding explicit
> > memory barriers).
>
> That is being discussed in the thread I linked, where Gary lists which
> barriers you would need for (presumably correct) lockless magic.
Having read Gary's suggestion, that aligns with what I had in mind.
> However, if my issue were to be solved with barriers, the
> test_and_set_bit() in dma_fence_signal_timestamp_locked() would have to
> be replaced with the more weakly ordered test_bit() and set_bit(),
> maybe creating other pitfalls.
For the avoidance of doubts, I'm not saying that all the issues you raised
can be solved by barriers instead of appropriate locks (I don't know enough
about the code and issues in general here).
I do think however that appropriate locks will fix the ordering issue
highlighted by sashiko (i.e. +1 for your argument). Barriers would fix this
specific issue, too, but that is not a statement about any wider issues.
> The ordering issue in the get_*_name() functions plays into that.
> Setting the bit would then be done after setting the ops-pointer to
> NULL. So one would have to try to move the NULL set, too.
>
> Long story short, this is painful and subtle.
>
> But I think what we are realizing over and over again is that dma_fence
> has many subtleties to its API contract, and the implementation's
> sparring use of spinlocks leads to workarounds where people take locks
> manually or have to do an RCU dance.
>
> Note that Christian is strongly opposed to guarding everything with
> locks, in part for supposedly occuring deadlocks in the fence callbacks
> when the driver needs to take its own locks.
ww_mutex could help against deadlocks, but might affect performance, in case
these are all critical code paths (IDK),
> The community discussion regarding that problem is currently in some
> sort of dead end, where none of us seems to know what the correct path
> forward is.
Please ignore if the following doesn't make sense, I'm just a bystander :-)
How about at least adding the required barriers and related changes, and
taking it from there? This would solve some immediate and easy to hit
issues on Arm64? If they turn out to be insufficient, code can still
be changed.
> > >
> [...]
> My understanding of the current situation is that as an issuer of
> dma_fence's you, in general, should wait for a grace period until you
> perform operations like driver unload, or, more generally, have fence-
> related resources and such being accessed through callbacks go away.
If I understand correctly, simply waiting for a grace period in the
driver's unbind should be the way to go.
> Danilo ... Maybe he's got the time to share some details with you that are
> relevant to your work.
Will wait a little :-)
BTW, thanks Philipp for all these details, much appreciated.
Cheers,
A.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox