From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Fernando Rimoli <fernandorimoli11@gmail.com>
Cc: Daniel Scally <dan.scally@ideasonboard.com>,
linux-media@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Arsalan Naeem <naeemarsalan@gmail.com>,
Jakob Berg Jespersen <dev@berg.pm>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 5/6] media: ipu-bridge: Match sensor configs per IPU and add config flags
Date: Wed, 2 Sep 2026 09:42:22 +0300 [thread overview]
Message-ID: <apfFTqPGCUB1m--R@kekkonen.localdomain> (raw)
In-Reply-To: <20260831181858.325109-6-fernandorimoli11@gmail.com>
Hi Fernando,
On Mon, Aug 31, 2026 at 08:18:57PM +0200, Fernando Rimoli wrote:
> Some sensors need different treatment depending on which IPU they are
> connected to, so the sensor's ACPI HID alone is not always enough to
> describe what the bridge has to set up.
>
> Add an optional IPU PCI product ID and a set of flags to struct
> ipu_sensor_config, along with an IPU_SENSOR_CONFIG_MATCH_FL() macro to
> define such an entry. A config naming a PCI product ID only applies to
> that IPU and takes precedence over a generic config for the same sensor,
> so that a sensor covered by both is connected once, through the more
> specific entry. Existing entries are unchanged and keep matching any IPU.
>
> No flags are defined yet and no entry uses the new macro, so there is no
> functional change.
There's quite a bit of irrelevant information here.
>
> Signed-off-by: Fernando Rimoli <fernandorimoli11@gmail.com>
> ---
> drivers/media/pci/intel/ipu-bridge.c | 31 ++++++++++++++++++++++++++++
> include/media/ipu-bridge.h | 29 +++++++++++++++++++++-----
> 2 files changed, 55 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c
> index cd3c36d44..38ad3e54e 100644
> --- a/drivers/media/pci/intel/ipu-bridge.c
> +++ b/drivers/media/pci/intel/ipu-bridge.c
> @@ -8,6 +8,7 @@
> #include <linux/dmi.h>
> #include <linux/i2c.h>
> #include <linux/mei_cl_bus.h>
> +#include <linux/pci.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/property.h>
> @@ -853,6 +854,32 @@ static int ipu_bridge_connect_sensor(const struct ipu_sensor_config *cfg,
> return ret;
> }
>
> +/*
> + * Whether a sensor config applies to the IPU the bridge sits on. A config
> + * naming a PCI product ID only applies to that IPU, and takes precedence over
> + * a generic config for the same sensor, which is skipped so that the sensor is
> + * not connected twice.
> + */
> +static bool ipu_bridge_config_matches(const struct ipu_sensor_config *cfg,
> + struct ipu_bridge *bridge)
> +{
> + unsigned int i;
> +
> + if (cfg->pci_id)
> + return cfg->pci_id == bridge->pci_id;
> +
> + for (i = 0; i < ARRAY_SIZE(ipu_supported_sensors); i++) {
Is there really a need to go through the entire array for each entry? Can't
you simply arrange the entries with a pci_id before the generic one?
> + const struct ipu_sensor_config *sp =
> + &ipu_supported_sensors[i];
> +
> + if (sp->pci_id && sp->pci_id == bridge->pci_id &&
> + !strcmp(sp->hid, cfg->hid))
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int ipu_bridge_connect_sensors(struct ipu_bridge *bridge)
> {
> unsigned int i;
> @@ -862,6 +889,9 @@ static int ipu_bridge_connect_sensors(struct ipu_bridge *bridge)
> const struct ipu_sensor_config *cfg =
> &ipu_supported_sensors[i];
>
> + if (!ipu_bridge_config_matches(cfg, bridge))
> + continue;
> +
> ret = ipu_bridge_connect_sensor(cfg, bridge);
> if (ret)
> goto err_unregister_sensors;
> @@ -948,6 +978,7 @@ int ipu_bridge_init(struct device *dev,
> sizeof(bridge->ipu_node_name));
> bridge->ipu_hid_node.name = bridge->ipu_node_name;
> bridge->dev = dev;
> + bridge->pci_id = dev_is_pci(dev) ? to_pci_dev(dev)->device : 0;
> bridge->parse_sensor_fwnode = parse_sensor_fwnode;
>
> ret = software_node_register(&bridge->ipu_hid_node);
> diff --git a/include/media/ipu-bridge.h b/include/media/ipu-bridge.h
> index 61e10cef1..d12e51336 100644
> --- a/include/media/ipu-bridge.h
> +++ b/include/media/ipu-bridge.h
> @@ -17,13 +17,27 @@
> #define IPU_SENSOR_ROTATION_NORMAL 0
> #define IPU_SENSOR_ROTATION_INVERTED 1
>
> -#define IPU_SENSOR_CONFIG(_HID, _NR, ...) \
> - (const struct ipu_sensor_config) { \
> - .hid = _HID, \
> - .nr_link_freqs = _NR, \
> - .link_freqs = { __VA_ARGS__ } \
> +/* Flags for struct ipu_sensor_config */
> +#define IPU_BR_FL_NONE 0
> +
> +/*
> + * Sensor config specific to a single IPU, identified by its PCI product ID,
> + * with flags describing what the sensor needs on that IPU. Where both a
> + * specific and a generic (IPU_SENSOR_CONFIG) entry exist for the same HID,
> + * the specific one takes precedence.
> + */
> +#define IPU_SENSOR_CONFIG_MATCH_FL(_HID, _ID, _FLAGS, _NR, ...) \
> + (const struct ipu_sensor_config) { \
> + .hid = _HID, \
> + .pci_id = _ID, \
> + .flags = IPU_BR_FL_##_FLAGS, \
Please don't assume a flag; setting multiple flags also doesn't work this
way.
> + .nr_link_freqs = _NR, \
> + .link_freqs = { __VA_ARGS__ } \
> }
>
> +#define IPU_SENSOR_CONFIG(_HID, _NR, ...) \
> + IPU_SENSOR_CONFIG_MATCH_FL(_HID, 0, NONE, _NR, __VA_ARGS__)
> +
> #define NODE_SENSOR(_HID, _PROPS) \
> (const struct software_node) { \
> .name = _HID, \
> @@ -132,6 +146,9 @@ struct ipu_node_names {
>
> struct ipu_sensor_config {
> const char *hid;
> + /* IPU PCI product ID this config is specific to, 0 for any */
> + const u16 pci_id;
In later patches we already get two extra entries per sensor that only
differ on pci_id. How about making this a pointer to an array? Zero
termination should be fine here.
> + const u32 flags;
> const u8 nr_link_freqs;
> const u64 link_freqs[MAX_NUM_LINK_FREQS];
> };
> @@ -177,6 +194,8 @@ typedef int (*ipu_parse_sensor_fwnode_t)(struct acpi_device *adev,
>
> struct ipu_bridge {
> struct device *dev;
> + /* PCI product ID of the IPU, 0 if it is not a PCI device */
All IPUs are PCI devices. ipu_bridge_init() should fail if a device isn't.
I think I might just omit the check.
> + u16 pci_id;
> ipu_parse_sensor_fwnode_t parse_sensor_fwnode;
> char ipu_node_name[ACPI_ID_LEN];
> struct software_node ipu_hid_node;
--
Regards,
Sakari Ailus
next prev parent reply other threads:[~2026-09-02 6:42 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 21:36 [PATCH] media: ov5693: add OVTI5693 ACPI HID for IPU6 Surface devices Fernando Rimoli
2026-07-09 13:17 ` Dan Scally
2026-07-14 9:32 ` Sakari Ailus
2026-07-17 13:20 ` [PATCH v2 0/3] media: Enable the OV5693 front camera on " Fernando Rimoli
2026-07-17 13:20 ` [PATCH v2 1/3] media: i2c: ov5693: Add OVTI5693 ACPI HID Fernando Rimoli
2026-07-17 13:20 ` [PATCH v2 2/3] media: ipu-bridge: Add OVTI5693 to the list of supported sensors Fernando Rimoli
2026-07-17 13:20 ` [PATCH v2 3/3] media: i2c: ov5693: Gate the MIPI clock lane for IPU6 Fernando Rimoli
2026-07-19 16:25 ` Jakob Berg Jespersen
2026-07-19 22:42 ` Sakari Ailus
2026-07-20 16:38 ` [PATCH v3 0/4] media: Enable the OV5693 front camera on IPU6 Surface devices Fernando Rimoli
2026-07-20 16:38 ` [PATCH v3 1/4] media: i2c: ov5693: Add OVTI5693 ACPI HID Fernando Rimoli
2026-07-20 16:38 ` [PATCH v3 2/4] media: ipu-bridge: Add OVTI5693 to the list of supported sensors Fernando Rimoli
2026-07-20 21:09 ` Dan Scally
2026-07-20 16:38 ` [PATCH v3 3/4] media: i2c: ov5693: Gate the MIPI clock lane for non-continuous clock Fernando Rimoli
2026-07-20 21:49 ` Dan Scally
2026-07-30 7:46 ` Sakari Ailus
2026-08-31 18:16 ` Fernando Rimoli
2026-07-20 16:38 ` [PATCH v3 4/4] media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6 Fernando Rimoli
2026-07-20 21:56 ` Dan Scally
2026-07-20 23:50 ` Fernando Rimoli
2026-07-30 7:32 ` Sakari Ailus
2026-08-31 18:17 ` Fernando Rimoli
2026-08-31 18:18 ` Fernando Rimoli
2026-08-31 18:18 ` [PATCH v4 0/6] media: Enable the OV5693 front camera on IPU6 Surface devices Fernando Rimoli
2026-08-31 18:18 ` [PATCH v4 1/6] media: i2c: ov5693: Add OVTI5693 ACPI HID Fernando Rimoli
2026-08-31 18:18 ` [PATCH v4 2/6] media: ipu-bridge: Add OVTI5693 to the list of supported sensors Fernando Rimoli
2026-08-31 18:18 ` [PATCH v4 3/6] media: i2c: ov5693: Gate the MIPI clock lane for non-continuous clock Fernando Rimoli
2026-09-01 9:32 ` Jakob Berg Jespersen
2026-09-01 9:56 ` Fernando Rimoli
2026-09-01 16:34 ` Fernando Rimoli
2026-09-01 18:32 ` Jakob Berg Jespersen
2026-09-01 18:46 ` Fil Dunsky
2026-09-02 7:27 ` Sakari Ailus
2026-08-31 18:18 ` [PATCH v4 4/6] media: ipu-bridge: Assign endpoint property indices dynamically Fernando Rimoli
2026-09-02 6:33 ` Sakari Ailus
2026-08-31 18:18 ` [PATCH v4 5/6] media: ipu-bridge: Match sensor configs per IPU and add config flags Fernando Rimoli
2026-09-01 9:57 ` Fernando Rimoli
2026-09-02 6:42 ` Sakari Ailus [this message]
2026-08-31 18:18 ` [PATCH v4 6/6] media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6 Fernando Rimoli
2026-09-02 4:42 ` Kengo Oki
2026-09-02 14:23 ` [PATCH v5 0/7] media: Enable the OV5693 front camera on IPU6 Surface devices Fernando Rimoli
2026-09-02 14:23 ` [PATCH v5 1/7] media: i2c: ov5693: Add OVTI5693 ACPI HID Fernando Rimoli
2026-09-02 14:23 ` [PATCH v5 2/7] media: ipu-bridge: Add OVTI5693 to the list of supported sensors Fernando Rimoli
2026-09-02 14:23 ` [PATCH v5 3/7] dt-bindings: media: ov5693: Add clock-noncontinuous Fernando Rimoli
2026-09-02 17:27 ` Conor Dooley
2026-09-02 14:23 ` [PATCH v5 4/7] media: i2c: ov5693: Gate the MIPI clock lane for non-continuous clock Fernando Rimoli
2026-09-02 19:11 ` Fil Dunsky
2026-09-02 14:23 ` [PATCH v5 5/7] media: ipu-bridge: Assign endpoint property indices dynamically Fernando Rimoli
2026-09-02 14:23 ` [PATCH v5 6/7] media: ipu-bridge: Match sensor configs per IPU and add config flags Fernando Rimoli
2026-09-02 14:23 ` [PATCH v5 7/7] media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6 Fernando Rimoli
2026-09-05 21:13 ` D. Manresa
2026-09-06 7:39 ` [PATCH v5 0/7] media: Enable the OV5693 front camera on IPU6 Surface devices D. Manresa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apfFTqPGCUB1m--R@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=dan.scally@ideasonboard.com \
--cc=dev@berg.pm \
--cc=fernandorimoli11@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=naeemarsalan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.