[PATCH 0/4] V4L2 fwnode framework and driver fixes

[PATCH 0/4] V4L2 fwnode framework and driver fixes

[Sakari Ailus]

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

[PATCH 1/4] v4l2-fwnode: Defaults may not override endpoint configuration in firmware

[Sakari Ailus]

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

[PATCH 2/4] v4l2-fwnode: The first default data lane is 0 on C-PHY

[Sakari Ailus]

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

[PATCH 3/4] pxa-camera: Match with device node, not the port node

[Sakari Ailus]

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

[PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Sakari Ailus]

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

[PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Sakari Ailus]

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

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Benoit Parrot]

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
> 

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Sakari Ailus]

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

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Benoit Parrot]

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

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Sakari Ailus]

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

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Benoit Parrot]

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

Re: [PATCH v1.1 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[Sakari Ailus]

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

Re: [PATCH 4/4] ti-vpe: Parse local endpoint for properties, not the remote one

[kbuild test robot]

[-- 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", &regval);
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 --]

Re: [PATCH 3/4] pxa-camera: Match with device node, not the port node

[Robert Jarzmik]

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

Re: [PATCH 3/4] pxa-camera: Match with device node, not the port node

[Sakari Ailus]

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