| Message ID | 20250531163148.83497-12-hansg@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | media: mt9m114: Changes to make it work with atomisp devices | expand |
Hi Hans, Laurent, On Tue, Jun 03, 2025 at 03:27:16PM +0200, Hans de Goede wrote: > Hi Laurent, > > Thank you for your reviews. I agree with most of your > comments and I'll address them when I can make some time. > > On 3-Jun-25 1:03 PM, Laurent Pinchart wrote: > > Hi Hans, > > > > Thank you for the patch. > > > > On Sat, May 31, 2025 at 06:31:46PM +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 c4d3122d698e..72914c47ec9a 100644 > >> --- a/drivers/media/i2c/mt9m114.c > >> +++ b/drivers/media/i2c/mt9m114.c > >> @@ -2399,11 +2399,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. > >> + */ > >> ep = fwnode_graph_get_next_endpoint(fwnode, NULL); > >> - if (!ep) { > >> - dev_err(&sensor->client->dev, "No endpoint found\n"); > >> - return -EINVAL; > >> - } > >> + if (!ep) > >> + return dev_err_probe(&sensor->client->dev, -EPROBE_DEFER, > >> + "waiting for fwnode graph endpoint\n"); > > > > That's a bit annoying, as in non-ACPI systems we'll then get probe > > deferral, making the issue more difficult to debug. > > With "then" I assume you mean when the fwnode graph endpoint is missing > on DT systems ? > > > Is there a way, on IPU-based systems, to delay probing the sensor until > > the bridge has been initialized ? > > Waiting for the fwnode graph endpoint to show up is the way to wait for > bridge init we (Sakari and me) have agreed upon, this is done on all > drivers used on x86/ACPI platforms. In the long run it'd be nice to move the code from the IPU bridge to the ACPI framework. That way we could remove this check as we could guarantee the endpoints would be where they're needed in time. But I don't expect this to happen any time soon: reworking the fwnode infrastructure to accommodate more flexible node/property insertion should probably be done first. Still, IPU bridge doesn't conflict with DisCo for Imaging doing largely similar things under the hood as the two are effectively mutually exclusive (and should remain so).
diff --git a/drivers/media/i2c/mt9m114.c b/drivers/media/i2c/mt9m114.c index c4d3122d698e..72914c47ec9a 100644 --- a/drivers/media/i2c/mt9m114.c +++ b/drivers/media/i2c/mt9m114.c @@ -2399,11 +2399,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. + */ ep = fwnode_graph_get_next_endpoint(fwnode, NULL); - if (!ep) { - dev_err(&sensor->client->dev, "No endpoint found\n"); - return -EINVAL; - } + if (!ep) + return dev_err_probe(&sensor->client->dev, -EPROBE_DEFER, + "waiting for fwnode graph endpoint\n"); sensor->bus_cfg.bus_type = V4L2_MBUS_UNKNOWN; ret = v4l2_fwnode_endpoint_alloc_parse(ep, &sensor->bus_cfg);
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(-)