From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans de Goede <hansg@kernel.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
Mathis Foerst <mathis.foerst@mt.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3 14/15] media: mt9m114: Return -EPROBE_DEFER if no endpoint is found
Date: Sat, 27 Dec 2025 16:54:58 +0200 [thread overview]
Message-ID: <20251227145458.GL4094@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ee136d75-16a3-4b30-a6e0-981f33494713@kernel.org>
On Wed, Dec 24, 2025 at 01:12:28PM +0100, Hans de Goede wrote:
> On 2-Jul-25 02:53, Laurent Pinchart wrote:
> > On Sun, Jun 29, 2025 at 10:56:24PM +0200, Hans de Goede wrote:
> >> With IPU# bridges, endpoints may only be created when the IPU bridge is
> >> initialized. This may happen after the sensor driver's first probe().
> >>
> >> Signed-off-by: Hans de Goede <hansg@kernel.org>
> >> ---
> >> drivers/media/i2c/mt9m114.c | 11 +++++++----
> >> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c
> >> index ec5e9ce24d1c..5e759a23e6cc 100644
> >> --- a/drivers/media/i2c/mt9m114.c
> >> +++ b/drivers/media/i2c/mt9m114.c
> >> @@ -2448,11 +2448,14 @@ static int mt9m114_parse_dt(struct mt9m114 *sensor)
> >> struct fwnode_handle *ep;
> >> int ret;
> >>
> >> + /*
> >> + * Sometimes the fwnode graph is initialized by the bridge driver,
> >> + * wait for this.
> >> + */
> >
> > I'm still not thrilled by this, but there's no real alternative for the
> > time being. Still, as Sakari mentioned, the IPU bridge code should at
> > some point be moved to the ACPI framework, so let's record here that the
> > sensor driver should then be updated:
> >
> > /*
> > * On ACPI systems the fwnode graph can be initialized by a bridge
> > * driver, which may not have probed yet. Wait for this.
> > *
> > * TODO: Return an error once bridge driver code will have moved
> > * to the ACPI core.
> > */
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > I wouldn't like to see this being replicated in lots of sensor drivers
> > though.
>
> I understand. With the new __devm_v4l2_sensor_clk_get() helper we could
> do something like this:
>
> From f7b13937af5f706bce3eed87c67a8f484f049c6a Mon Sep 17 00:00:00 2001
> From: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Date: Wed, 24 Dec 2025 13:04:09 +0100
> Subject: [PATCH] media: v4l2-common: sensor_clk_get(): Wait for endpoint
> fwnode to show up
>
> On ACPI systems the fwnode graph can be initialized by a bridge driver,
> which may not have probed yet.
>
> Currently all sensor drivers which are used on ACPI platforms need to wait
> for this themselves.
>
> Add a check for the endpoint fwnode being present to
> the devm_v4l2_sensor_clk_get() helper, this allows sensor drivers to drop
> the check for this themselves as long as they call the helper before doing
> any endpoint fwnode parsing.
>
> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> ---
> drivers/media/v4l2-core/v4l2-common.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 554c591e1113..b68b5567a508 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -743,11 +743,27 @@ struct clk *__devm_v4l2_sensor_clk_get(struct device *dev, const char *id,
> {
> bool of_node = is_of_node(dev_fwnode(dev));
> const char *clk_id __free(kfree) = NULL;
> + struct fwnode_handle *ep;
> struct clk_hw *clk_hw;
> struct clk *clk;
> u32 rate = clk_rate;
> int ret = 0;
>
> + /*
> + * On ACPI systems the fwnode graph can be initialized by a bridge
> + * driver, which may not have probed yet. The bridge driver also sets
> + * the clock-frequency property which is used below. Wait for this.
> + *
> + * TODO: Return an error once bridge driver code will have moved
> + * to the ACPI core.
> + */
> + ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
> + if (!ep)
> + return dev_err_probe(dev, -EPROBE_DEFER,
> + "waiting for fwnode graph endpoint\n");
> +
> + fwnode_handle_put(ep);
> +
> clk = devm_clk_get_optional(dev, id);
> if (IS_ERR(clk))
> return clk;
> and then in e.g. the mt9m114.c code move the devm_v4l2_sensor_clk_get()
> call to above mt9m114_parse_dt() and then the handling for this can be
> dropped from the mt9m114.c code (and the same for other sensor drivers
> with a similar check).
>
> The downside of this is that it makes having an endpoint fwnode available
> mandatory for all sensor drivers which use the devm_v4l2_sensor_clk_get()
> helper, but AFAICT having an endpoint fwnode is mandatory for all sensor
> drivers anyways, so this should not be an issue ?
Yes I think that would work, and would avoid copying the hack in
multiple drivers. Sakari, is this OK with you ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2025-12-27 14:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-29 20:56 [PATCH v3 00/15] media: mt9m114: Changes to make it work with atomisp devices Hans de Goede
2025-06-29 20:56 ` [PATCH v3 01/15] media: aptina-pll: Debug log p1 min and max values Hans de Goede
2025-06-29 20:56 ` [PATCH v3 02/15] media: mt9m114: Add support for clock-frequency property Hans de Goede
2025-06-29 20:56 ` [PATCH v3 03/15] media: mt9m114: Use aptina-PLL helper to get PLL values Hans de Goede
2025-06-29 20:56 ` [PATCH v3 04/15] media: mt9m114: Lower minimum vblank value Hans de Goede
2025-06-29 20:56 ` [PATCH v3 05/15] media: mt9m114: Fix default hblank and vblank values Hans de Goede
2025-06-29 20:56 ` [PATCH v3 06/15] media: mt9m114: Tweak default hblank and vblank for more accurate fps Hans de Goede
2025-06-29 20:56 ` [PATCH v3 07/15] media: mt9m114: Avoid a reset low spike during probe() Hans de Goede
2025-06-29 20:56 ` [PATCH v3 08/15] media: mt9m114: Put sensor in reset on power down Hans de Goede
2025-06-29 20:56 ` [PATCH v3 09/15] media: mt9m114: Add and use mt9m114_ifp_get_border() helper function Hans de Goede
2025-07-02 0:17 ` Laurent Pinchart
2025-06-29 20:56 ` [PATCH v3 10/15] media: mt9m114: Adjust IFP selections and src format when src pixelfmt changes to/from RAW10 Hans de Goede
2025-07-02 0:32 ` Laurent Pinchart
2025-12-23 13:33 ` Hans de Goede
2025-06-29 20:56 ` [PATCH v3 11/15] media: mt9m114: Update src pad sel and format when sink pad format changes Hans de Goede
2025-07-02 0:36 ` Laurent Pinchart
2025-06-29 20:56 ` [PATCH v3 12/15] media: mt9m114: Don't allow changing the IFP crop/compose selections when bypassing the scaler Hans de Goede
2025-07-02 0:42 ` Laurent Pinchart
2025-06-29 20:56 ` [PATCH v3 13/15] media: mt9m114: Drop start-, stop-streaming sequence from initialize Hans de Goede
2025-07-02 1:08 ` Laurent Pinchart
2025-12-23 13:37 ` Hans de Goede
2025-12-23 16:50 ` Laurent Pinchart
2025-12-23 16:57 ` Hans de Goede
2025-06-29 20:56 ` [PATCH v3 14/15] media: mt9m114: Return -EPROBE_DEFER if no endpoint is found Hans de Goede
2025-07-02 0:53 ` Laurent Pinchart
2025-12-24 12:12 ` Hans de Goede
2025-12-27 14:54 ` Laurent Pinchart [this message]
2025-06-29 20:56 ` [PATCH v3 15/15] media: mt9m114: Add ACPI enumeration support Hans de Goede
[not found] ` <6861b00f.050a0220.379e4a.5185@mx.google.com>
2025-06-30 7:34 ` [v3,00/15] media: mt9m114: Changes to make it work with atomisp devices Hans de Goede
2025-06-30 22:28 ` [PATCH v3 00/15] " Laurent Pinchart
2025-07-01 13:21 ` Hans de Goede
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=20251227145458.GL4094@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=hansg@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mathis.foerst@mt.com \
--cc=sakari.ailus@linux.intel.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.