* [PATCH 0/4] V4L2 fwnode framework and driver fixes
@ 2019-03-05 13:55 Sakari Ailus
2019-03-05 13:55 ` [PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware Sakari Ailus
` (3 more replies)
0 siblings, 4 replies; 15+ messages in thread
From: Sakari Ailus @ 2019-03-05 13:55 UTC (permalink / raw)
To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot
Hi folks,
Here are a few fixes for the parsing fwnodes in the V4L2 framework as well
as drivers using it.
Sakari Ailus (4):
v4l2-fwnode: Defaults may not override endpoint configuration in
firmware
v4l2-fwnode: The first default data lane is 0 on C-PHY
pxa-camera: Match with device node, not the port node
ti-vpe: Parse local endpoint for properties, not the remote one
drivers/media/platform/pxa_camera.c | 2 +-
drivers/media/platform/ti-vpe/cal.c | 11 ++---------
drivers/media/v4l2-core/v4l2-fwnode.c | 12 ++++++++++--
3 files changed, 13 insertions(+), 12 deletions(-)
--
2.11.0
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware 2019-03-05 13:55 [PATCH 0/4] V4L2 fwnode framework and driver fixes Sakari Ailus @ 2019-03-05 13:55 ` Sakari Ailus 2019-03-05 13:56 ` [PATCH 2/4] v4l2-fwnode: The first default data lane is 0 on C-PHY Sakari Ailus ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 13:55 UTC (permalink / raw) To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot The lack of defaults provided by the caller to v4l2_fwnode_endpoint_parse() signals the use of the default lane mapping. The default lane mapping must not be used however if the firmmare contains the lane mapping. Disable the default lane mapping in that case, and improve the debug messages telling of the use of the defaults. This was missed previously since the default mapping will only unsed in this case if the bus type is set, and no driver did both while still needing the lane mapping configuration. Fixes: b4357d21d674 ("media: v4l: fwnode: Support default CSI-2 lane mapping for drivers") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- drivers/media/v4l2-core/v4l2-fwnode.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c index 9bfedd7596a1..93d0547779df 100644 --- a/drivers/media/v4l2-core/v4l2-fwnode.c +++ b/drivers/media/v4l2-core/v4l2-fwnode.c @@ -163,7 +163,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, } if (use_default_lane_mapping) - pr_debug("using default lane mapping\n"); + pr_debug("no lane mapping given, using defaults\n"); } rval = fwnode_property_read_u32_array(fwnode, "data-lanes", NULL, 0); @@ -175,6 +175,10 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, num_data_lanes); have_data_lanes = true; + if (use_default_lane_mapping) { + pr_debug("data-lanes property exists; disabling default mapping\n"); + use_default_lane_mapping = false; + } } for (i = 0; i < num_data_lanes; i++) { -- 2.11.0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 2/4] v4l2-fwnode: The first default data lane is 0 on C-PHY 2019-03-05 13:55 [PATCH 0/4] V4L2 fwnode framework and driver fixes Sakari Ailus 2019-03-05 13:55 ` [PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware Sakari Ailus @ 2019-03-05 13:56 ` Sakari Ailus 2019-03-05 13:56 ` [PATCH 3/4] pxa-camera: Match with device node, not the port node Sakari Ailus 2019-03-05 13:56 ` [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one Sakari Ailus 3 siblings, 0 replies; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 13:56 UTC (permalink / raw) To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot C-PHY has no clock lanes. Therefore the first data lane is 0 by default. Fixes: edc6d56c2e7e ("media: v4l: fwnode: Support parsing of CSI-2 C-PHY endpoints") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- drivers/media/v4l2-core/v4l2-fwnode.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c index 93d0547779df..6b990c78c73a 100644 --- a/drivers/media/v4l2-core/v4l2-fwnode.c +++ b/drivers/media/v4l2-core/v4l2-fwnode.c @@ -229,6 +229,10 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, if (bus_type == V4L2_MBUS_CSI2_DPHY || bus_type == V4L2_MBUS_CSI2_CPHY || lanes_used || have_clk_lane || (flags & ~V4L2_MBUS_CSI2_CONTINUOUS_CLOCK)) { + /* Only D-PHY has a clock lane. */ + unsigned int dfl_data_lane_index = + bus_type == V4L2_MBUS_CSI2_DPHY; + bus->flags = flags; if (bus_type == V4L2_MBUS_UNKNOWN) vep->bus_type = V4L2_MBUS_CSI2_DPHY; @@ -237,7 +241,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, if (use_default_lane_mapping) { bus->clock_lane = 0; for (i = 0; i < num_data_lanes; i++) - bus->data_lanes[i] = 1 + i; + bus->data_lanes[i] = dfl_data_lane_index + i; } else { bus->clock_lane = clock_lane; for (i = 0; i < num_data_lanes; i++) -- 2.11.0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 3/4] pxa-camera: Match with device node, not the port node 2019-03-05 13:55 [PATCH 0/4] V4L2 fwnode framework and driver fixes Sakari Ailus 2019-03-05 13:55 ` [PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware Sakari Ailus 2019-03-05 13:56 ` [PATCH 2/4] v4l2-fwnode: The first default data lane is 0 on C-PHY Sakari Ailus @ 2019-03-05 13:56 ` Sakari Ailus 2019-08-21 7:26 ` Robert Jarzmik 2019-03-05 13:56 ` [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one Sakari Ailus 3 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 13:56 UTC (permalink / raw) To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot V4L2 fwnode matching right now still works based on device nodes, not port nodes. Fix this. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- drivers/media/platform/pxa_camera.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c index 3cf3c6390cc8..f729519f34e1 100644 --- a/drivers/media/platform/pxa_camera.c +++ b/drivers/media/platform/pxa_camera.c @@ -2350,7 +2350,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev, pcdev->platform_flags |= PXA_CAMERA_PCLK_EN; asd->match_type = V4L2_ASYNC_MATCH_FWNODE; - remote = of_graph_get_remote_port(np); + remote = of_graph_get_remote_port_parent(np); if (remote) asd->match.fwnode = of_fwnode_handle(remote); else -- 2.11.0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 3/4] pxa-camera: Match with device node, not the port node 2019-03-05 13:56 ` [PATCH 3/4] pxa-camera: Match with device node, not the port node Sakari Ailus @ 2019-08-21 7:26 ` Robert Jarzmik 2019-08-21 8:24 ` Sakari Ailus 0 siblings, 1 reply; 15+ messages in thread From: Robert Jarzmik @ 2019-08-21 7:26 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media, akinobu.mita, hverkuil, bparrot Sakari Ailus <sakari.ailus@linux.intel.com> writes: > V4L2 fwnode matching right now still works based on device nodes, not port > nodes. Fix this. Mmmh why does it need a fix, and what's wrong on device node matching ? This commit message is a bit too brief for me to understand why a fix is needed. Moreover, does it have an impact on Documentation/devicetree/bindings/media/pxa-camera.txt ? Cheers. -- Robert ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/4] pxa-camera: Match with device node, not the port node 2019-08-21 7:26 ` Robert Jarzmik @ 2019-08-21 8:24 ` Sakari Ailus 0 siblings, 0 replies; 15+ messages in thread From: Sakari Ailus @ 2019-08-21 8:24 UTC (permalink / raw) To: Robert Jarzmik; +Cc: linux-media, akinobu.mita, hverkuil, bparrot Hi Robert, On Wed, Aug 21, 2019 at 09:26:59AM +0200, Robert Jarzmik wrote: > Sakari Ailus <sakari.ailus@linux.intel.com> writes: > > > V4L2 fwnode matching right now still works based on device nodes, not port > > nodes. Fix this. > Mmmh why does it need a fix, and what's wrong on device node matching ? This > commit message is a bit too brief for me to understand why a fix is needed. The V4L2 async framework matches the async sub-devices based on their device nodes on fwnode matching which is used on DT-based systems. If a port node is provided instead, there won't be a match. > > Moreover, does it have an impact on > Documentation/devicetree/bindings/media/pxa-camera.txt ? The bindings are fine. -- Regards, Sakari Ailus sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 13:55 [PATCH 0/4] V4L2 fwnode framework and driver fixes Sakari Ailus ` (2 preceding siblings ...) 2019-03-05 13:56 ` [PATCH 3/4] pxa-camera: Match with device node, not the port node Sakari Ailus @ 2019-03-05 13:56 ` Sakari Ailus 2019-03-05 14:02 ` [PATCH v1.1 " Sakari Ailus 2019-03-07 21:25 ` [PATCH " kbuild test robot 3 siblings, 2 replies; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 13:56 UTC (permalink / raw) To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot ti-vpe driver parsed the remote endpoints for properties but ignored the local ones. Fix this by parsing the local endpoint properties instead. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- drivers/media/platform/ti-vpe/cal.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c index fc3c212b96e1..576f5d0d5789 100644 --- a/drivers/media/platform/ti-vpe/cal.c +++ b/drivers/media/platform/ti-vpe/cal.c @@ -1643,8 +1643,7 @@ of_get_next_endpoint(const struct device_node *parent, static int of_cal_create_instance(struct cal_ctx *ctx, int inst) { struct platform_device *pdev = ctx->dev->pdev; - struct device_node *ep_node, *port, *remote_ep, - *sensor_node, *parent; + struct device_node *ep_node, *port, *sensor_node, *parent; struct v4l2_fwnode_endpoint *endpoint; struct v4l2_async_subdev *asd; u32 regval = 0; @@ -1657,7 +1656,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) ep_node = NULL; port = NULL; - remote_ep = NULL; sensor_node = NULL; ret = -EINVAL; @@ -1703,12 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) asd->match_type = V4L2_ASYNC_MATCH_FWNODE; asd->match.fwnode = of_fwnode_handle(sensor_node); - remote_ep = of_graph_get_remote_endpoint(ep_node); - if (!remote_ep) { - ctx_dbg(3, ctx, "can't get remote-endpoint\n"); - goto cleanup_exit; - } - v4l2_fwnode_endpoint_parse(of_fwnode_handle(remote_ep), endpoint); + v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep_node), endpoint); if (endpoint->bus_type != V4L2_MBUS_CSI2_DPHY) { ctx_err(ctx, "Port:%d sub-device %pOFn is not a CSI2 device\n", -- 2.11.0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 13:56 ` [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one Sakari Ailus @ 2019-03-05 14:02 ` Sakari Ailus 2019-03-05 14:34 ` Benoit Parrot 2019-03-07 21:25 ` [PATCH " kbuild test robot 1 sibling, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 14:02 UTC (permalink / raw) To: linux-media; +Cc: akinobu.mita, robert.jarzmik, hverkuil, bparrot ti-vpe driver parsed the remote endpoints for properties but ignored the local ones. Fix this by parsing the local endpoint properties instead. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- since v1: - Remove of_node_put(remote_ep) as well, the only remaining reference to it. drivers/media/platform/ti-vpe/cal.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c index fc3c212b96e1..8d075683e448 100644 --- a/drivers/media/platform/ti-vpe/cal.c +++ b/drivers/media/platform/ti-vpe/cal.c @@ -1643,8 +1643,7 @@ of_get_next_endpoint(const struct device_node *parent, static int of_cal_create_instance(struct cal_ctx *ctx, int inst) { struct platform_device *pdev = ctx->dev->pdev; - struct device_node *ep_node, *port, *remote_ep, - *sensor_node, *parent; + struct device_node *ep_node, *port, *sensor_node, *parent; struct v4l2_fwnode_endpoint *endpoint; struct v4l2_async_subdev *asd; u32 regval = 0; @@ -1657,7 +1656,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) ep_node = NULL; port = NULL; - remote_ep = NULL; sensor_node = NULL; ret = -EINVAL; @@ -1703,12 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) asd->match_type = V4L2_ASYNC_MATCH_FWNODE; asd->match.fwnode = of_fwnode_handle(sensor_node); - remote_ep = of_graph_get_remote_endpoint(ep_node); - if (!remote_ep) { - ctx_dbg(3, ctx, "can't get remote-endpoint\n"); - goto cleanup_exit; - } - v4l2_fwnode_endpoint_parse(of_fwnode_handle(remote_ep), endpoint); + v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep_node), endpoint); if (endpoint->bus_type != V4L2_MBUS_CSI2_DPHY) { ctx_err(ctx, "Port:%d sub-device %pOFn is not a CSI2 device\n", @@ -1759,7 +1752,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) sensor_node = NULL; cleanup_exit: - of_node_put(remote_ep); of_node_put(sensor_node); of_node_put(ep_node); of_node_put(port); -- 2.11.0 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 14:02 ` [PATCH v1.1 " Sakari Ailus @ 2019-03-05 14:34 ` Benoit Parrot 2019-03-05 16:32 ` Sakari Ailus 0 siblings, 1 reply; 15+ messages in thread From: Benoit Parrot @ 2019-03-05 14:34 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil Sakari, Thank you for the patch. Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > ti-vpe driver parsed the remote endpoints for properties but ignored the > local ones. Fix this by parsing the local endpoint properties instead. I am not sure I understand the logic here. For CSI2 sensor as far as I understand the lane mapping (clock and data) is driven from the sensor side. The bridge driver (in this case CAL) needs to setup the receiver side based on what the sensor (aka remote endpoint) can provide. I failed to see how this fixes things here. Are you suggesting that sensor relevant properties be set (and effectively duplicated) on the bridge/receiver side? Some sensor can and do handle multiple data lanes configuration so the sensor driver also needs to use those properties at probe time, duplicating the lane data is just asking for a mismatch to happen, no? Benoit > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > since v1: > > - Remove of_node_put(remote_ep) as well, the only remaining reference to it. > > drivers/media/platform/ti-vpe/cal.c | 12 ++---------- > 1 file changed, 2 insertions(+), 10 deletions(-) > > diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c > index fc3c212b96e1..8d075683e448 100644 > --- a/drivers/media/platform/ti-vpe/cal.c > +++ b/drivers/media/platform/ti-vpe/cal.c > @@ -1643,8 +1643,7 @@ of_get_next_endpoint(const struct device_node *parent, > static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > { > struct platform_device *pdev = ctx->dev->pdev; > - struct device_node *ep_node, *port, *remote_ep, > - *sensor_node, *parent; > + struct device_node *ep_node, *port, *sensor_node, *parent; > struct v4l2_fwnode_endpoint *endpoint; > struct v4l2_async_subdev *asd; > u32 regval = 0; > @@ -1657,7 +1656,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > > ep_node = NULL; > port = NULL; > - remote_ep = NULL; > sensor_node = NULL; > ret = -EINVAL; > > @@ -1703,12 +1701,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > asd->match_type = V4L2_ASYNC_MATCH_FWNODE; > asd->match.fwnode = of_fwnode_handle(sensor_node); > > - remote_ep = of_graph_get_remote_endpoint(ep_node); > - if (!remote_ep) { > - ctx_dbg(3, ctx, "can't get remote-endpoint\n"); > - goto cleanup_exit; > - } > - v4l2_fwnode_endpoint_parse(of_fwnode_handle(remote_ep), endpoint); > + v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep_node), endpoint); > > if (endpoint->bus_type != V4L2_MBUS_CSI2_DPHY) { > ctx_err(ctx, "Port:%d sub-device %pOFn is not a CSI2 device\n", > @@ -1759,7 +1752,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > sensor_node = NULL; > > cleanup_exit: > - of_node_put(remote_ep); > of_node_put(sensor_node); > of_node_put(ep_node); > of_node_put(port); > -- > 2.11.0 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 14:34 ` Benoit Parrot @ 2019-03-05 16:32 ` Sakari Ailus 2019-03-05 17:38 ` Benoit Parrot 0 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 16:32 UTC (permalink / raw) To: Benoit Parrot; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil Hi Benoit, On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > Sakari, > > Thank you for the patch. > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > local ones. Fix this by parsing the local endpoint properties instead. > > I am not sure I understand the logic here. For CSI2 sensor as far as I > understand the lane mapping (clock and data) is driven from the sensor > side. The bridge driver (in this case CAL) needs to setup the receiver side > based on what the sensor (aka remote endpoint) can provide. > > I failed to see how this fixes things here. > > Are you suggesting that sensor relevant properties be set (and effectively > duplicated) on the bridge/receiver side? Yes. The endpoint configuration in general is local to the device and should not be accessed from other device drivers. The lane mapping, for instance, is specific to a given device --- and may differ even between for two connected endpoints. It's used to reorder the PHY lanes (if the device supports that). Same goes for the clock lane. See e.g. arch/arm/boot/dts/omap3-n9.dts . > > Some sensor can and do handle multiple data lanes configuration so the > sensor driver also needs to use those properties at probe time, duplicating > the lane data is just asking for a mismatch to happen, no? It's a different configuration on the sensor side. We currently have no checks in place to verify that the two would match. I haven't heard of this would have really been a problem though. The frame descriptors should be used for runtime configuration. Niklas and more recently Jacopo have been working on that. -- Kind regards, Sakari Ailus sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 16:32 ` Sakari Ailus @ 2019-03-05 17:38 ` Benoit Parrot 2019-03-05 20:48 ` Sakari Ailus 0 siblings, 1 reply; 15+ messages in thread From: Benoit Parrot @ 2019-03-05 17:38 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 18:32:40 +0200]: > Hi Benoit, > > On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > > Sakari, > > > > Thank you for the patch. > > > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > > local ones. Fix this by parsing the local endpoint properties instead. > > > > I am not sure I understand the logic here. For CSI2 sensor as far as I > > understand the lane mapping (clock and data) is driven from the sensor > > side. The bridge driver (in this case CAL) needs to setup the receiver side > > based on what the sensor (aka remote endpoint) can provide. > > > > I failed to see how this fixes things here. > > > > Are you suggesting that sensor relevant properties be set (and effectively > > duplicated) on the bridge/receiver side? > > Yes. The endpoint configuration in general is local to the device and > should not be accessed from other device drivers. > > The lane mapping, for instance, is specific to a given device --- and may > differ even between for two connected endpoints. It's used to reorder the > PHY lanes (if the device supports that). Same goes for the clock lane. I did not see omap3isp having lane reorder capability, but I guess it would be possible for instance, that a sensor uses clock lane 0 and data lane 1 & 2 but the way it is wired on the board makes it that the receiver would see sensor lane 0 on device lane 2 and so on... Not sure why you would wire it up that way but who knows... > > See e.g. arch/arm/boot/dts/omap3-n9.dts . > > > > > Some sensor can and do handle multiple data lanes configuration so the > > sensor driver also needs to use those properties at probe time, duplicating > > the lane data is just asking for a mismatch to happen, no? > > It's a different configuration on the sensor side. We currently have no > checks in place to verify that the two would match. I haven't heard of this > would have really been a problem though. I had just never thought about this cases, to me a single source of information is better than 2. But anyhow I guess I'll have to update all of my relevant dts files in the near future. Benoit > > The frame descriptors should be used for runtime configuration. Niklas and > more recently Jacopo have been working on that. > > -- > Kind regards, > > Sakari Ailus > sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 17:38 ` Benoit Parrot @ 2019-03-05 20:48 ` Sakari Ailus 2019-03-07 15:34 ` Benoit Parrot 0 siblings, 1 reply; 15+ messages in thread From: Sakari Ailus @ 2019-03-05 20:48 UTC (permalink / raw) To: Benoit Parrot; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil On Tue, Mar 05, 2019 at 11:38:42AM -0600, Benoit Parrot wrote: > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 18:32:40 +0200]: > > Hi Benoit, > > > > On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > > > Sakari, > > > > > > Thank you for the patch. > > > > > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > > > local ones. Fix this by parsing the local endpoint properties instead. > > > > > > I am not sure I understand the logic here. For CSI2 sensor as far as I > > > understand the lane mapping (clock and data) is driven from the sensor > > > side. The bridge driver (in this case CAL) needs to setup the receiver side > > > based on what the sensor (aka remote endpoint) can provide. > > > > > > I failed to see how this fixes things here. > > > > > > Are you suggesting that sensor relevant properties be set (and effectively > > > duplicated) on the bridge/receiver side? > > > > Yes. The endpoint configuration in general is local to the device and > > should not be accessed from other device drivers. > > > > The lane mapping, for instance, is specific to a given device --- and may > > differ even between for two connected endpoints. It's used to reorder the > > PHY lanes (if the device supports that). Same goes for the clock lane. > > I did not see omap3isp having lane reorder capability, but I guess it would > be possible for instance, that a sensor uses clock lane 0 and data lane 1 > & 2 but the way it is wired on the board makes it that the receiver would see > sensor lane 0 on device lane 2 and so on... Not sure why you would wire it > up that way but who knows... I presume the feature is there to ease PCB design. > > > > > See e.g. arch/arm/boot/dts/omap3-n9.dts . ^ There it is. > > > > > > > > Some sensor can and do handle multiple data lanes configuration so the > > > sensor driver also needs to use those properties at probe time, duplicating > > > the lane data is just asking for a mismatch to happen, no? > > > > It's a different configuration on the sensor side. We currently have no > > checks in place to verify that the two would match. I haven't heard of this > > would have really been a problem though. > > I had just never thought about this cases, to me a single source of > information is better than 2. But anyhow I guess I'll have to update all of > my relevant dts files in the near future. Do you have in-kernel dts files using this? I presume the driver should then figure out whether the local endpoint has a configuration and if it doesn't, then look it up from the remote one. Otherwise old dts binaries will break. :-( -- Regards, Sakari Ailus sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 20:48 ` Sakari Ailus @ 2019-03-07 15:34 ` Benoit Parrot 2019-03-07 15:55 ` Sakari Ailus 0 siblings, 1 reply; 15+ messages in thread From: Benoit Parrot @ 2019-03-07 15:34 UTC (permalink / raw) To: Sakari Ailus; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 22:48:44 +0200]: > On Tue, Mar 05, 2019 at 11:38:42AM -0600, Benoit Parrot wrote: > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 18:32:40 +0200]: > > > Hi Benoit, > > > > > > On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > > > > Sakari, > > > > > > > > Thank you for the patch. > > > > > > > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > > > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > > > > local ones. Fix this by parsing the local endpoint properties instead. > > > > > > > > I am not sure I understand the logic here. For CSI2 sensor as far as I > > > > understand the lane mapping (clock and data) is driven from the sensor > > > > side. The bridge driver (in this case CAL) needs to setup the receiver side > > > > based on what the sensor (aka remote endpoint) can provide. > > > > > > > > I failed to see how this fixes things here. > > > > > > > > Are you suggesting that sensor relevant properties be set (and effectively > > > > duplicated) on the bridge/receiver side? > > > > > > Yes. The endpoint configuration in general is local to the device and > > > should not be accessed from other device drivers. > > > > > > The lane mapping, for instance, is specific to a given device --- and may > > > differ even between for two connected endpoints. It's used to reorder the > > > PHY lanes (if the device supports that). Same goes for the clock lane. > > > > I did not see omap3isp having lane reorder capability, but I guess it would > > be possible for instance, that a sensor uses clock lane 0 and data lane 1 > > & 2 but the way it is wired on the board makes it that the receiver would see > > sensor lane 0 on device lane 2 and so on... Not sure why you would wire it > > up that way but who knows... > > I presume the feature is there to ease PCB design. > > > > > > > > > See e.g. arch/arm/boot/dts/omap3-n9.dts . > > ^ > > There it is. Yes I saw that the sensor describes its clock-lanes as 0 and data-lanes as 1 & 2. And that the OMAP3ISP receiver describes its clock-lanes as 2 and data-lanes as 1 & 3. But when I looked at the driver code itself it just uses those lane config without doing anything else, so to me that just point to the way it's wired up on the board, nothing more. (although I have not looked into any schematics so I am just guessing here) > > > > > > > > > > > > Some sensor can and do handle multiple data lanes configuration so the > > > > sensor driver also needs to use those properties at probe time, duplicating > > > > the lane data is just asking for a mismatch to happen, no? > > > > > > It's a different configuration on the sensor side. We currently have no > > > checks in place to verify that the two would match. I haven't heard of this > > > would have really been a problem though. > > > > I had just never thought about this cases, to me a single source of > > information is better than 2. But anyhow I guess I'll have to update all of > > my relevant dts files in the near future. > > Do you have in-kernel dts files using this? I presume the driver should > then figure out whether the local endpoint has a configuration and if it > doesn't, then look it up from the remote one. Otherwise old dts binaries > will break. :-( No I do not currently have any dts in mainline using this feature as of yet. It is used in several DT file in our own kernel tree so I'll have to update those for sure. But between our major releases we do not guarantee DTBs backward compatibility, so depending on when I merge this we may not need to add backward compat code. I guess you are free to augment the patch to add backward support since this patch is changing the current DT parsing behavior for this driver. I do have a backlog of patches for this driver I need to up-stream. If you prefer you can drop this patch from the series then I can include a version of it with my set. Up to you. Benoit > > -- > Regards, > > Sakari Ailus > sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-07 15:34 ` Benoit Parrot @ 2019-03-07 15:55 ` Sakari Ailus 0 siblings, 0 replies; 15+ messages in thread From: Sakari Ailus @ 2019-03-07 15:55 UTC (permalink / raw) To: Benoit Parrot; +Cc: linux-media, akinobu.mita, robert.jarzmik, hverkuil On Thu, Mar 07, 2019 at 09:34:12AM -0600, Benoit Parrot wrote: > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 22:48:44 +0200]: > > On Tue, Mar 05, 2019 at 11:38:42AM -0600, Benoit Parrot wrote: > > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 18:32:40 +0200]: > > > > Hi Benoit, > > > > > > > > On Tue, Mar 05, 2019 at 08:34:09AM -0600, Benoit Parrot wrote: > > > > > Sakari, > > > > > > > > > > Thank you for the patch. > > > > > > > > > > Sakari Ailus <sakari.ailus@linux.intel.com> wrote on Tue [2019-Mar-05 16:02:24 +0200]: > > > > > > ti-vpe driver parsed the remote endpoints for properties but ignored the > > > > > > local ones. Fix this by parsing the local endpoint properties instead. > > > > > > > > > > I am not sure I understand the logic here. For CSI2 sensor as far as I > > > > > understand the lane mapping (clock and data) is driven from the sensor > > > > > side. The bridge driver (in this case CAL) needs to setup the receiver side > > > > > based on what the sensor (aka remote endpoint) can provide. > > > > > > > > > > I failed to see how this fixes things here. > > > > > > > > > > Are you suggesting that sensor relevant properties be set (and effectively > > > > > duplicated) on the bridge/receiver side? > > > > > > > > Yes. The endpoint configuration in general is local to the device and > > > > should not be accessed from other device drivers. > > > > > > > > The lane mapping, for instance, is specific to a given device --- and may > > > > differ even between for two connected endpoints. It's used to reorder the > > > > PHY lanes (if the device supports that). Same goes for the clock lane. > > > > > > I did not see omap3isp having lane reorder capability, but I guess it would > > > be possible for instance, that a sensor uses clock lane 0 and data lane 1 > > > & 2 but the way it is wired on the board makes it that the receiver would see > > > sensor lane 0 on device lane 2 and so on... Not sure why you would wire it > > > up that way but who knows... > > > > I presume the feature is there to ease PCB design. > > > > > > > > > > > > > See e.g. arch/arm/boot/dts/omap3-n9.dts . > > > > ^ > > > > There it is. > > Yes I saw that the sensor describes its clock-lanes as 0 and data-lanes as > 1 & 2. And that the OMAP3ISP receiver describes its clock-lanes as 2 and > data-lanes as 1 & 3. > > But when I looked at the driver code itself it just uses those lane config > without doing anything else, so to me that just point to the way it's wired up > on the board, nothing more. (although I have not looked into any schematics > so I am just guessing here) It is wired on the board... and that's the point here indeed. The register configured based on this is ISPCSI2_PHY_CFG (driver name, I don't know what the datasheet uses). > > > > > > > > > > > > > > > > > Some sensor can and do handle multiple data lanes configuration so the > > > > > sensor driver also needs to use those properties at probe time, duplicating > > > > > the lane data is just asking for a mismatch to happen, no? > > > > > > > > It's a different configuration on the sensor side. We currently have no > > > > checks in place to verify that the two would match. I haven't heard of this > > > > would have really been a problem though. > > > > > > I had just never thought about this cases, to me a single source of > > > information is better than 2. But anyhow I guess I'll have to update all of > > > my relevant dts files in the near future. > > > > Do you have in-kernel dts files using this? I presume the driver should > > then figure out whether the local endpoint has a configuration and if it > > doesn't, then look it up from the remote one. Otherwise old dts binaries > > will break. :-( > > No I do not currently have any dts in mainline using this feature as of > yet. It is used in several DT file in our own kernel tree so I'll have to > update those for sure. But between our major releases we do not guarantee > DTBs backward compatibility, so depending on when I merge this we may not > need to add backward compat code. > > I guess you are free to augment the patch to add backward support since this > patch is changing the current DT parsing behavior for this driver. > > I do have a backlog of patches for this driver I need to up-stream. > If you prefer you can drop this patch from the series then I can include a > version of it with my set. Up to you. I have an upcoming patch that changes the code again. :-) So I'll keep it in my set. Btw. I checked Documentation/devicetree/bindings/media/ti-cal.txt and it seems a bit incomplete. There is no endpoint configuration on CAL side (which is understandable now), but there's also the "slave-mode" property which looks just inapplicable for this type or hardware. Also "reg = <0>" can be omitted on ar0330 side. Is this btw. an Aptina image sensor or some lesser known TI chip with somewhat similar properties? :-) The binding file should describe relevant properties for the device as well as the valid values for them. (Excluding graph etc. documentation which already exists elsewhere.) Would you like to address these? :-) Thanks. -- Kind regards, Sakari Ailus sakari.ailus@linux.intel.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one 2019-03-05 13:56 ` [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one Sakari Ailus 2019-03-05 14:02 ` [PATCH v1.1 " Sakari Ailus @ 2019-03-07 21:25 ` kbuild test robot 1 sibling, 0 replies; 15+ messages in thread From: kbuild test robot @ 2019-03-07 21:25 UTC (permalink / raw) To: Sakari Ailus Cc: kbuild-all, linux-media, akinobu.mita, robert.jarzmik, hverkuil, bparrot [-- Attachment #1: Type: text/plain, Size: 10941 bytes --] Hi Sakari, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v5.0 next-20190306] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/V4L2-fwnode-framework-and-driver-fixes/20190308-042715 base: git://linuxtv.org/media_tree.git master config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.2.0 make.cross ARCH=sparc64 All errors (new ones prefixed by >>): drivers/media//platform/ti-vpe/cal.c: In function 'of_cal_create_instance': >> drivers/media//platform/ti-vpe/cal.c:1755:14: error: 'remote_ep' undeclared (first use in this function) of_node_put(remote_ep); ^~~~~~~~~ drivers/media//platform/ti-vpe/cal.c:1755:14: note: each undeclared identifier is reported only once for each function it appears in vim +/remote_ep +1755 drivers/media//platform/ti-vpe/cal.c 343e89a79 Benoit Parrot 2016-01-06 1642 343e89a79 Benoit Parrot 2016-01-06 1643 static int of_cal_create_instance(struct cal_ctx *ctx, int inst) 343e89a79 Benoit Parrot 2016-01-06 1644 { 343e89a79 Benoit Parrot 2016-01-06 1645 struct platform_device *pdev = ctx->dev->pdev; e8013a352 Sakari Ailus 2019-03-05 1646 struct device_node *ep_node, *port, *sensor_node, *parent; 859969b38 Sakari Ailus 2016-08-26 1647 struct v4l2_fwnode_endpoint *endpoint; 343e89a79 Benoit Parrot 2016-01-06 1648 struct v4l2_async_subdev *asd; 343e89a79 Benoit Parrot 2016-01-06 1649 u32 regval = 0; 343e89a79 Benoit Parrot 2016-01-06 1650 int ret, index, found_port = 0, lane; 343e89a79 Benoit Parrot 2016-01-06 1651 343e89a79 Benoit Parrot 2016-01-06 1652 parent = pdev->dev.of_node; 343e89a79 Benoit Parrot 2016-01-06 1653 343e89a79 Benoit Parrot 2016-01-06 1654 asd = &ctx->asd; 343e89a79 Benoit Parrot 2016-01-06 1655 endpoint = &ctx->endpoint; 343e89a79 Benoit Parrot 2016-01-06 1656 343e89a79 Benoit Parrot 2016-01-06 1657 ep_node = NULL; 343e89a79 Benoit Parrot 2016-01-06 1658 port = NULL; 343e89a79 Benoit Parrot 2016-01-06 1659 sensor_node = NULL; 343e89a79 Benoit Parrot 2016-01-06 1660 ret = -EINVAL; 343e89a79 Benoit Parrot 2016-01-06 1661 343e89a79 Benoit Parrot 2016-01-06 1662 ctx_dbg(3, ctx, "Scanning Port node for csi2 port: %d\n", inst); 343e89a79 Benoit Parrot 2016-01-06 1663 for (index = 0; index < CAL_NUM_CSI2_PORTS; index++) { 343e89a79 Benoit Parrot 2016-01-06 1664 port = of_get_next_port(parent, port); 343e89a79 Benoit Parrot 2016-01-06 1665 if (!port) { 343e89a79 Benoit Parrot 2016-01-06 1666 ctx_dbg(1, ctx, "No port node found for csi2 port:%d\n", 343e89a79 Benoit Parrot 2016-01-06 1667 index); 343e89a79 Benoit Parrot 2016-01-06 1668 goto cleanup_exit; 343e89a79 Benoit Parrot 2016-01-06 1669 } 343e89a79 Benoit Parrot 2016-01-06 1670 343e89a79 Benoit Parrot 2016-01-06 1671 /* Match the slice number with <REG> */ 343e89a79 Benoit Parrot 2016-01-06 1672 of_property_read_u32(port, "reg", ®val); 343e89a79 Benoit Parrot 2016-01-06 1673 ctx_dbg(3, ctx, "port:%d inst:%d <reg>:%d\n", 343e89a79 Benoit Parrot 2016-01-06 1674 index, inst, regval); 343e89a79 Benoit Parrot 2016-01-06 1675 if ((regval == inst) && (index == inst)) { 343e89a79 Benoit Parrot 2016-01-06 1676 found_port = 1; 343e89a79 Benoit Parrot 2016-01-06 1677 break; 343e89a79 Benoit Parrot 2016-01-06 1678 } 343e89a79 Benoit Parrot 2016-01-06 1679 } 343e89a79 Benoit Parrot 2016-01-06 1680 343e89a79 Benoit Parrot 2016-01-06 1681 if (!found_port) { 343e89a79 Benoit Parrot 2016-01-06 1682 ctx_dbg(1, ctx, "No port node matches csi2 port:%d\n", 343e89a79 Benoit Parrot 2016-01-06 1683 inst); 343e89a79 Benoit Parrot 2016-01-06 1684 goto cleanup_exit; 343e89a79 Benoit Parrot 2016-01-06 1685 } 343e89a79 Benoit Parrot 2016-01-06 1686 343e89a79 Benoit Parrot 2016-01-06 1687 ctx_dbg(3, ctx, "Scanning sub-device for csi2 port: %d\n", 343e89a79 Benoit Parrot 2016-01-06 1688 inst); 343e89a79 Benoit Parrot 2016-01-06 1689 343e89a79 Benoit Parrot 2016-01-06 1690 ep_node = of_get_next_endpoint(port, ep_node); 343e89a79 Benoit Parrot 2016-01-06 1691 if (!ep_node) { 343e89a79 Benoit Parrot 2016-01-06 1692 ctx_dbg(3, ctx, "can't get next endpoint\n"); 343e89a79 Benoit Parrot 2016-01-06 1693 goto cleanup_exit; 343e89a79 Benoit Parrot 2016-01-06 1694 } 343e89a79 Benoit Parrot 2016-01-06 1695 343e89a79 Benoit Parrot 2016-01-06 1696 sensor_node = of_graph_get_remote_port_parent(ep_node); 343e89a79 Benoit Parrot 2016-01-06 1697 if (!sensor_node) { 343e89a79 Benoit Parrot 2016-01-06 1698 ctx_dbg(3, ctx, "can't get remote parent\n"); 343e89a79 Benoit Parrot 2016-01-06 1699 goto cleanup_exit; 343e89a79 Benoit Parrot 2016-01-06 1700 } 859969b38 Sakari Ailus 2016-08-26 1701 asd->match_type = V4L2_ASYNC_MATCH_FWNODE; 4e48afecd Mauro Carvalho Chehab 2017-09-27 1702 asd->match.fwnode = of_fwnode_handle(sensor_node); 343e89a79 Benoit Parrot 2016-01-06 1703 e8013a352 Sakari Ailus 2019-03-05 1704 v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep_node), endpoint); 343e89a79 Benoit Parrot 2016-01-06 1705 2d95e7ed0 Sakari Ailus 2018-07-03 1706 if (endpoint->bus_type != V4L2_MBUS_CSI2_DPHY) { f764e6d68 Rob Herring 2018-08-27 1707 ctx_err(ctx, "Port:%d sub-device %pOFn is not a CSI2 device\n", f764e6d68 Rob Herring 2018-08-27 1708 inst, sensor_node); 343e89a79 Benoit Parrot 2016-01-06 1709 goto cleanup_exit; 343e89a79 Benoit Parrot 2016-01-06 1710 } 343e89a79 Benoit Parrot 2016-01-06 1711 343e89a79 Benoit Parrot 2016-01-06 1712 /* Store Virtual Channel number */ 343e89a79 Benoit Parrot 2016-01-06 1713 ctx->virtual_channel = endpoint->base.id; 343e89a79 Benoit Parrot 2016-01-06 1714 343e89a79 Benoit Parrot 2016-01-06 1715 ctx_dbg(3, ctx, "Port:%d v4l2-endpoint: CSI2\n", inst); 343e89a79 Benoit Parrot 2016-01-06 1716 ctx_dbg(3, ctx, "Virtual Channel=%d\n", ctx->virtual_channel); 343e89a79 Benoit Parrot 2016-01-06 1717 ctx_dbg(3, ctx, "flags=0x%08x\n", endpoint->bus.mipi_csi2.flags); 343e89a79 Benoit Parrot 2016-01-06 1718 ctx_dbg(3, ctx, "clock_lane=%d\n", endpoint->bus.mipi_csi2.clock_lane); 343e89a79 Benoit Parrot 2016-01-06 1719 ctx_dbg(3, ctx, "num_data_lanes=%d\n", 343e89a79 Benoit Parrot 2016-01-06 1720 endpoint->bus.mipi_csi2.num_data_lanes); 343e89a79 Benoit Parrot 2016-01-06 1721 ctx_dbg(3, ctx, "data_lanes= <\n"); 343e89a79 Benoit Parrot 2016-01-06 1722 for (lane = 0; lane < endpoint->bus.mipi_csi2.num_data_lanes; lane++) 343e89a79 Benoit Parrot 2016-01-06 1723 ctx_dbg(3, ctx, "\t%d\n", 343e89a79 Benoit Parrot 2016-01-06 1724 endpoint->bus.mipi_csi2.data_lanes[lane]); 343e89a79 Benoit Parrot 2016-01-06 1725 ctx_dbg(3, ctx, "\t>\n"); 343e89a79 Benoit Parrot 2016-01-06 1726 f764e6d68 Rob Herring 2018-08-27 1727 ctx_dbg(1, ctx, "Port: %d found sub-device %pOFn\n", f764e6d68 Rob Herring 2018-08-27 1728 inst, sensor_node); 343e89a79 Benoit Parrot 2016-01-06 1729 d079f94c9 Steve Longerbeam 2018-09-29 1730 v4l2_async_notifier_init(&ctx->notifier); d079f94c9 Steve Longerbeam 2018-09-29 1731 d079f94c9 Steve Longerbeam 2018-09-29 1732 ret = v4l2_async_notifier_add_subdev(&ctx->notifier, asd); d079f94c9 Steve Longerbeam 2018-09-29 1733 if (ret) { d079f94c9 Steve Longerbeam 2018-09-29 1734 ctx_err(ctx, "Error adding asd\n"); d079f94c9 Steve Longerbeam 2018-09-29 1735 goto cleanup_exit; d079f94c9 Steve Longerbeam 2018-09-29 1736 } d079f94c9 Steve Longerbeam 2018-09-29 1737 b6ee3f0dc Laurent Pinchart 2017-08-30 1738 ctx->notifier.ops = &cal_async_ops; 343e89a79 Benoit Parrot 2016-01-06 1739 ret = v4l2_async_notifier_register(&ctx->v4l2_dev, 343e89a79 Benoit Parrot 2016-01-06 1740 &ctx->notifier); 343e89a79 Benoit Parrot 2016-01-06 1741 if (ret) { 343e89a79 Benoit Parrot 2016-01-06 1742 ctx_err(ctx, "Error registering async notifier\n"); d079f94c9 Steve Longerbeam 2018-09-29 1743 v4l2_async_notifier_cleanup(&ctx->notifier); 343e89a79 Benoit Parrot 2016-01-06 1744 ret = -EINVAL; 343e89a79 Benoit Parrot 2016-01-06 1745 } 343e89a79 Benoit Parrot 2016-01-06 1746 d079f94c9 Steve Longerbeam 2018-09-29 1747 /* d079f94c9 Steve Longerbeam 2018-09-29 1748 * On success we need to keep reference on sensor_node, or d079f94c9 Steve Longerbeam 2018-09-29 1749 * if notifier_cleanup was called above, sensor_node was d079f94c9 Steve Longerbeam 2018-09-29 1750 * already put. d079f94c9 Steve Longerbeam 2018-09-29 1751 */ d079f94c9 Steve Longerbeam 2018-09-29 1752 sensor_node = NULL; d079f94c9 Steve Longerbeam 2018-09-29 1753 343e89a79 Benoit Parrot 2016-01-06 1754 cleanup_exit: 343e89a79 Benoit Parrot 2016-01-06 @1755 of_node_put(remote_ep); 343e89a79 Benoit Parrot 2016-01-06 1756 of_node_put(sensor_node); 343e89a79 Benoit Parrot 2016-01-06 1757 of_node_put(ep_node); 343e89a79 Benoit Parrot 2016-01-06 1758 of_node_put(port); 343e89a79 Benoit Parrot 2016-01-06 1759 343e89a79 Benoit Parrot 2016-01-06 1760 return ret; 343e89a79 Benoit Parrot 2016-01-06 1761 } 343e89a79 Benoit Parrot 2016-01-06 1762 :::::: The code at line 1755 was first introduced by commit :::::: 343e89a792a571b28b9c02850db7af2ef25ffb20 [media] media: ti-vpe: Add CAL v4l2 camera capture driver :::::: TO: Benoit Parrot <bparrot@ti.com> :::::: CC: Mauro Carvalho Chehab <mchehab@osg.samsung.com> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 56338 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-08-21 8:24 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-05 13:55 [PATCH 0/4] V4L2 fwnode framework and driver fixes Sakari Ailus 2019-03-05 13:55 ` [PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware Sakari Ailus 2019-03-05 13:56 ` [PATCH 2/4] v4l2-fwnode: The first default data lane is 0 on C-PHY Sakari Ailus 2019-03-05 13:56 ` [PATCH 3/4] pxa-camera: Match with device node, not the port node Sakari Ailus 2019-08-21 7:26 ` Robert Jarzmik 2019-08-21 8:24 ` Sakari Ailus 2019-03-05 13:56 ` [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one Sakari Ailus 2019-03-05 14:02 ` [PATCH v1.1 " Sakari Ailus 2019-03-05 14:34 ` Benoit Parrot 2019-03-05 16:32 ` Sakari Ailus 2019-03-05 17:38 ` Benoit Parrot 2019-03-05 20:48 ` Sakari Ailus 2019-03-07 15:34 ` Benoit Parrot 2019-03-07 15:55 ` Sakari Ailus 2019-03-07 21:25 ` [PATCH " kbuild test robot
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.