[RFC] v4l: omap4iss: DT bindings development

[RFC] v4l: omap4iss: DT bindings development

[Michael Allwright]

Hi Everyone,

I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
am unable to capture any data in my test setup. As detailed below, it
seems that everything has been configured correctly however I never
get any interrupts from the ISS unless I do something drastic like
removing one of the wires from the clock differential pair which
results in constant complex IO error interrupts from CSIA until I
restore the physical connection.

My test setup includes a OV6540 sensor camera module (MIPI) from
Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
forming an interconnect between the two. The sensor is connected to
CSI21 on the OMAP4 using a clock lane (on position 1, default
polarity) and a single data lane (on position 2, default polarity),
the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
to 19.2MHz when asked for 24MHz).

The relevant parts of my device tree can be seen here:
https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
Does anything else need to be done here? As far as I can tell I think
all clocks and power has been switched on. I do make two function
calls to the PM API in the ISS probe function, i.e.:

pm_runtime_enable(&pdev->dev);
r = pm_runtime_get_sync(&pdev->dev);

Regarding my debugging, this is what I have checked so far

* Changing the pixel rate of the sensor - this lead me to discover a
possible bug in iss.c or perhaps my ov5640 driver, as the
V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
by copying what Laurent has done in the OMAP3ISP driver which now
works.
* As I only have a 100MHz scope, I had to slow down the camera
significantly (MIPI clock => 10-12MHz range) to verify that I was
getting reasonable output from the sensor (i.e. signals that were
characteristic of CSI2/MIPI). I checked the calculations and made sure
these updated values came across via the V4L2_CID_PIXEL_RATE control
and ended up in the THS_TERM and THS_SETTLE fields of register 0.
* Using the omapconf tool, I have manually and one by one pulled up
the CSI2 pins and verified multiple times all connections to the
sensor module and have even manually tried swapping the DP/DN pairs in
case they were still somehow backwards despite previous testing
* Verified that the interrupt service routine is called by generating
a test interrupt HS_VS from inside the ISS i.e.

./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000

* Verified that the default CMA region is being used, it ends up in
the ping-pong resisters of the ISS.

Additional information:

* Initialisation of pipe line and stream commands:

media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
[UYVY 640x480]'
yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy

* Output from OMAPCONF tool is in the second part of:
https://gist.github.com/allsey87/fdf1feb6eb6a94158638

Anyway, at this point, I'm almost completely out of ideas on how to
move forwards so any suggestions, criticisms or help of any nature
would be appreciated!

All the best,

-- 
Michael Allwright

PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering

University of Paderborn
Office-number 02-47
Zukunftsmeile 1
33102 Paderborn
Germany

Re: [RFC] v4l: omap4iss: DT bindings development

[Tony Lindgren]

* Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
> Hi Everyone,
> 
> I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
> am unable to capture any data in my test setup. As detailed below, it
> seems that everything has been configured correctly however I never
> get any interrupts from the ISS unless I do something drastic like
> removing one of the wires from the clock differential pair which
> results in constant complex IO error interrupts from CSIA until I
> restore the physical connection.
> 
> My test setup includes a OV6540 sensor camera module (MIPI) from
> Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
> forming an interconnect between the two. The sensor is connected to
> CSI21 on the OMAP4 using a clock lane (on position 1, default
> polarity) and a single data lane (on position 2, default polarity),
> the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
> to 19.2MHz when asked for 24MHz).
> 
> The relevant parts of my device tree can be seen here:
> https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
> somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
> Does anything else need to be done here? As far as I can tell I think
> all clocks and power has been switched on. I do make two function
> calls to the PM API in the ISS probe function, i.e.:
> 
> pm_runtime_enable(&pdev->dev);
> r = pm_runtime_get_sync(&pdev->dev);

The ti,hwmod = "iss" hooks up the device with the PM runtime, see
omap_hwmod_44xx_data.c for "iss".
 
> Regarding my debugging, this is what I have checked so far
> 
> * Changing the pixel rate of the sensor - this lead me to discover a
> possible bug in iss.c or perhaps my ov5640 driver, as the
> V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
> by copying what Laurent has done in the OMAP3ISP driver which now
> works.
> * As I only have a 100MHz scope, I had to slow down the camera
> significantly (MIPI clock => 10-12MHz range) to verify that I was
> getting reasonable output from the sensor (i.e. signals that were
> characteristic of CSI2/MIPI). I checked the calculations and made sure
> these updated values came across via the V4L2_CID_PIXEL_RATE control
> and ended up in the THS_TERM and THS_SETTLE fields of register 0.
> * Using the omapconf tool, I have manually and one by one pulled up
> the CSI2 pins and verified multiple times all connections to the
> sensor module and have even manually tried swapping the DP/DN pairs in
> case they were still somehow backwards despite previous testing
> * Verified that the interrupt service routine is called by generating
> a test interrupt HS_VS from inside the ISS i.e.
> 
> ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
> ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
> 
> * Verified that the default CMA region is being used, it ends up in
> the ping-pong resisters of the ISS.
> 
> Additional information:
> 
> * Initialisation of pipe line and stream commands:
> 
> media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
> media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
> [UYVY 640x480]'
> yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
> 
> * Output from OMAPCONF tool is in the second part of:
> https://gist.github.com/allsey87/fdf1feb6eb6a94158638
> 
> Anyway, at this point, I'm almost completely out of ideas on how to
> move forwards so any suggestions, criticisms or help of any nature
> would be appreciated!

Usually it's pinmuxing or some regulator or clock not enabled. Or
incorrect hwmod sysc and syss configuration for iss that prevents
enabling it properly.

Regards,

Tony

Re: [RFC] v4l: omap4iss: DT bindings development

[Laurent Pinchart]

On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
> * Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
> > Hi Everyone,
> > 
> > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
> > am unable to capture any data in my test setup. As detailed below, it
> > seems that everything has been configured correctly however I never
> > get any interrupts from the ISS unless I do something drastic like
> > removing one of the wires from the clock differential pair which
> > results in constant complex IO error interrupts from CSIA until I
> > restore the physical connection.
> > 
> > My test setup includes a OV6540 sensor camera module (MIPI) from
> > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
> > forming an interconnect between the two. The sensor is connected to
> > CSI21 on the OMAP4 using a clock lane (on position 1, default
> > polarity) and a single data lane (on position 2, default polarity),
> > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
> > to 19.2MHz when asked for 24MHz).
> > 
> > The relevant parts of my device tree can be seen here:
> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
> > somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
> > Does anything else need to be done here? As far as I can tell I think
> > all clocks and power has been switched on. I do make two function
> > calls to the PM API in the ISS probe function, i.e.:
> > 
> > pm_runtime_enable(&pdev->dev);
> > r = pm_runtime_get_sync(&pdev->dev);
> 
> The ti,hwmod = "iss" hooks up the device with the PM runtime, see
> omap_hwmod_44xx_data.c for "iss".
> 
> > Regarding my debugging, this is what I have checked so far
> > 
> > * Changing the pixel rate of the sensor - this lead me to discover a
> > possible bug in iss.c or perhaps my ov5640 driver, as the
> > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
> > by copying what Laurent has done in the OMAP3ISP driver which now
> > works.
> > * As I only have a 100MHz scope, I had to slow down the camera
> > significantly (MIPI clock => 10-12MHz range) to verify that I was
> > getting reasonable output from the sensor (i.e. signals that were
> > characteristic of CSI2/MIPI). I checked the calculations and made sure
> > these updated values came across via the V4L2_CID_PIXEL_RATE control
> > and ended up in the THS_TERM and THS_SETTLE fields of register 0.
> > * Using the omapconf tool, I have manually and one by one pulled up
> > the CSI2 pins and verified multiple times all connections to the
> > sensor module and have even manually tried swapping the DP/DN pairs in
> > case they were still somehow backwards despite previous testing
> > * Verified that the interrupt service routine is called by generating
> > a test interrupt HS_VS from inside the ISS i.e.
> > 
> > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
> > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
> > 
> > * Verified that the default CMA region is being used, it ends up in
> > the ping-pong resisters of the ISS.
> > 
> > Additional information:
> > 
> > * Initialisation of pipe line and stream commands:
> > 
> > media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
> > media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
> > [UYVY 640x480]'
> > yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
> > 
> > * Output from OMAPCONF tool is in the second part of:
> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638
> > 
> > Anyway, at this point, I'm almost completely out of ideas on how to
> > move forwards so any suggestions, criticisms or help of any nature
> > would be appreciated!
> 
> Usually it's pinmuxing or some regulator or clock not enabled. Or
> incorrect hwmod sysc and syss configuration for iss that prevents
> enabling it properly.

And have you tried the same setup with platform data ?

-- 
Regards,

Laurent Pinchart

Re: [RFC] v4l: omap4iss: DT bindings development

[Michael Allwright]

Thank you for the replies. Laurent I have started using the platform
data to see if I can determine whether I have a software problem or a
hardware problem. One thing that is confusing me, is how are memory
resources are supposed to be properly mapped to a kernel module in a
DT enabled kernel using the hwmod abstraction layer.

It seems that the omap4iss driver in the mainline is expecting
resources to be declared in the format that was changed around about
this commit: https://www.gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/8304f13d002dfaf618473a551dbbc35cfcdc2742

In the driver in the mainline, these resources are acquired in the
probe function by this loop here from iss.c:1397
for (i = 1; i < OMAP4_ISS_MEM_LAST; i++) { ret =
iss_map_mem_resource(pdev, iss, i); if (ret) goto error_iss; }

However the definitions of these registers have completely disappeared
in the mainline, nor are they in the master branches of linux-media or
linux-omap (see arch/arm/mach-omap2/devices.c / h). Interesting enough
the definitions for the OMAP3 ISP are still there. Furthermore looking
at the omap_hwmod_44xx_data.c in these branches I can see the hwmod
layer is only declaring the first 0xff bytes of address space starting
at 0x52000000, this obviously doesn't include the CSIA/B registers nor
the CAMERARX registers which are all at addresses >0x520000ff.

TLDR: omap4iss seems somewhat broken in the mainline (3.17),
linux-media (master) and linux-omap (master), which repo/branch are
you using for testing? Or what happened to the omap4_iss_resources
array?

All the best,

Michael Allwright

PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering

University of Paderborn
Office-number 02-47
Zukunftsmeile 1
33102 Paderborn
Germany


On 2 June 2015 at 18:22, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
>> * Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
>> > Hi Everyone,
>> >
>> > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
>> > am unable to capture any data in my test setup. As detailed below, it
>> > seems that everything has been configured correctly however I never
>> > get any interrupts from the ISS unless I do something drastic like
>> > removing one of the wires from the clock differential pair which
>> > results in constant complex IO error interrupts from CSIA until I
>> > restore the physical connection.
>> >
>> > My test setup includes a OV6540 sensor camera module (MIPI) from
>> > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
>> > forming an interconnect between the two. The sensor is connected to
>> > CSI21 on the OMAP4 using a clock lane (on position 1, default
>> > polarity) and a single data lane (on position 2, default polarity),
>> > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
>> > to 19.2MHz when asked for 24MHz).
>> >
>> > The relevant parts of my device tree can be seen here:
>> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
>> > somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
>> > Does anything else need to be done here? As far as I can tell I think
>> > all clocks and power has been switched on. I do make two function
>> > calls to the PM API in the ISS probe function, i.e.:
>> >
>> > pm_runtime_enable(&pdev->dev);
>> > r = pm_runtime_get_sync(&pdev->dev);
>>
>> The ti,hwmod = "iss" hooks up the device with the PM runtime, see
>> omap_hwmod_44xx_data.c for "iss".
>>
>> > Regarding my debugging, this is what I have checked so far
>> >
>> > * Changing the pixel rate of the sensor - this lead me to discover a
>> > possible bug in iss.c or perhaps my ov5640 driver, as the
>> > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
>> > by copying what Laurent has done in the OMAP3ISP driver which now
>> > works.
>> > * As I only have a 100MHz scope, I had to slow down the camera
>> > significantly (MIPI clock => 10-12MHz range) to verify that I was
>> > getting reasonable output from the sensor (i.e. signals that were
>> > characteristic of CSI2/MIPI). I checked the calculations and made sure
>> > these updated values came across via the V4L2_CID_PIXEL_RATE control
>> > and ended up in the THS_TERM and THS_SETTLE fields of register 0.
>> > * Using the omapconf tool, I have manually and one by one pulled up
>> > the CSI2 pins and verified multiple times all connections to the
>> > sensor module and have even manually tried swapping the DP/DN pairs in
>> > case they were still somehow backwards despite previous testing
>> > * Verified that the interrupt service routine is called by generating
>> > a test interrupt HS_VS from inside the ISS i.e.
>> >
>> > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
>> > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
>> >
>> > * Verified that the default CMA region is being used, it ends up in
>> > the ping-pong resisters of the ISS.
>> >
>> > Additional information:
>> >
>> > * Initialisation of pipe line and stream commands:
>> >
>> > media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
>> > media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
>> > [UYVY 640x480]'
>> > yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
>> >
>> > * Output from OMAPCONF tool is in the second part of:
>> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638
>> >
>> > Anyway, at this point, I'm almost completely out of ideas on how to
>> > move forwards so any suggestions, criticisms or help of any nature
>> > would be appreciated!
>>
>> Usually it's pinmuxing or some regulator or clock not enabled. Or
>> incorrect hwmod sysc and syss configuration for iss that prevents
>> enabling it properly.
>
> And have you tried the same setup with platform data ?
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: [RFC] v4l: omap4iss: DT bindings development

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 9528 bytes --]

Hi Michael,

On Thursday 04 June 2015 16:56:47 Michael Allwright wrote:
> Thank you for the replies. Laurent I have started using the platform
> data to see if I can determine whether I have a software problem or a
> hardware problem. One thing that is confusing me, is how are memory
> resources are supposed to be properly mapped to a kernel module in a
> DT enabled kernel using the hwmod abstraction layer.
> 
> It seems that the omap4iss driver in the mainline is expecting
> resources to be declared in the format that was changed around about
> this commit:
> https://www.gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/8304f1
> 3d002dfaf618473a551dbbc35cfcdc2742
> 
> In the driver in the mainline, these resources are acquired in the
> probe function by this loop here from iss.c:1397
> for (i = 1; i < OMAP4_ISS_MEM_LAST; i++) { ret =
> iss_map_mem_resource(pdev, iss, i); if (ret) goto error_iss; }
> 
> However the definitions of these registers have completely disappeared
> in the mainline, nor are they in the master branches of linux-media or
> linux-omap (see arch/arm/mach-omap2/devices.c / h). Interesting enough
> the definitions for the OMAP3 ISP are still there. Furthermore looking
> at the omap_hwmod_44xx_data.c in these branches I can see the hwmod
> layer is only declaring the first 0xff bytes of address space starting
> at 0x52000000, this obviously doesn't include the CSIA/B registers nor
> the CAMERARX registers which are all at addresses >0x520000ff.
> 
> TLDR: omap4iss seems somewhat broken in the mainline (3.17),
> linux-media (master) and linux-omap (master), which repo/branch are
> you using for testing? Or what happened to the omap4_iss_resources
> array?

I've mostly been using a TI v3.4 BSP to which I've backported the mainline 
driver. The iss hwmod is indeed broken in mainline.

The two attached patches should help for testing the ISS driver with platform 
data. As we're moving to DT it's probably not worth it pushing them to 
mainline.

I used the following board code when developing a driver for the Aptina AR0330 
used with a Panda board. That was quite a long time ago, I never managed to 
get it fully working and had to move to different projects. The code might 
thus not even compile.

#include <linux/gpio.h>
#include <linux/clk.h>
#include <linux/delay.h>

#include <plat/i2c.h>
#include <plat/omap-pm.h>

#include <asm/mach-types.h>

#include <media/ar0330.h>

#include "devices.h"
#include "../../../drivers/media/video/omap4iss/iss.h"

#include "control.h"
#include "mux.h"

#define PANDA_GPIO_CAM_RESET		83

#define AR0330_I2C_ADDRESS   		0x10

static struct ar0330_platform_data panda_ar0330_data = {
};

static struct i2c_board_info panda_camera_i2c_device = {
	I2C_BOARD_INFO("ar0330", AR0330_I2C_ADDRESS),
	.platform_data = &ar0330_platform_data,
};

static struct iss_subdev_i2c_board_info panda_ar0330_subdevs[] = {
	{
		.board_info = &panda_camera_i2c_device,
		.i2c_adapter_id = 3,
	},
	{ NULL, 0, },
};

static struct iss_v4l2_subdevs_group panda_camera_subdevs[] = {
	{
		.subdevs = panda_ar0330_subdevs,
		.interface = ISS_INTERFACE_CSI2A_PHY1,
		.bus = { .csi2 = {
			.lanecfg	= {
				.clk = {
					.pol = 0,
					.pos = 2,
				},
				.data[0] = {
					.pol = 0,
					.pos = 1,
				},
				.data[1] = {
					.pol = 0,
					.pos = 3,
				},
			},
		} },
	},
	{ },
};

static void panda_omap4iss_set_constraints(struct iss_device *iss, bool 
enable)
{
	if (!iss)
		return;

	/* FIXME: Look for something more precise as a good throughtput limit */
	omap_pm_set_min_bus_tput(iss->dev, OCP_INITIATOR_AGENT,
				 enable ? 800000 : -1);
}

static struct iss_platform_data panda_iss_platform_data = {
	.subdevs = panda_camera_subdevs,
	.set_constraints = panda_omap4iss_set_constraints,
};

static struct omap_device_pad omap4iss_pads[] = {
	{
		.name   = "csi21_dx0.csi21_dx0",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
	{
		.name   = "csi21_dy0.csi21_dy0",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
	{
		.name   = "csi21_dx1.csi21_dx1",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
	{
		.name   = "csi21_dy1.csi21_dy1",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
	{
		.name   = "csi21_dx2.csi21_dx2",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
	{
		.name   = "csi21_dy2.csi21_dy2",
		.enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
	},
};

static struct omap_board_data omap4iss_data = {
	.id	    		= 1,
	.pads	 		= omap4iss_pads,
	.pads_cnt       	= ARRAY_SIZE(omap4iss_pads),
};

static int __init panda_camera_init(void)
{
	struct clk *clk;

	if (!machine_is_omap4_panda())
		return 0;

	clk = clk_get(NULL, "auxclk1_ck");
	if (IS_ERR(clk)) {
		printk(KERN_ERR "Unable to get auxclk1_ck\n");
		return -ENODEV;
	}

	panda_ar0330_data.clock = clk;

	/* Select GPIO 83 */
	omap_mux_init_gpio(PANDA_GPIO_CAM_RESET, OMAP_PIN_OUTPUT);

	/* Init FREF_CLK1_OUT */
	omap_mux_init_signal("fref_clk1_out", OMAP_PIN_OUTPUT);

	if (gpio_request_one(PANDA_GPIO_CAM_RESET, GPIOF_OUT_INIT_HIGH,
			     "CAM_RESET"))
		printk(KERN_WARNING "Cannot request GPIO %d\n",
		       PANDA_GPIO_CAM_RESET);

	panda_ar0330_data.reset = PANDA_GPIO_CAM_RESET;

	return omap4_init_camera(&panda_iss_platform_data, &omap4iss_data);
}
late_initcall(panda_camera_init);


> On 2 June 2015 at 18:22, Laurent Pinchart wrote:
> > On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
> >> * Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
> >> > Hi Everyone,
> >> > 
> >> > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
> >> > am unable to capture any data in my test setup. As detailed below, it
> >> > seems that everything has been configured correctly however I never
> >> > get any interrupts from the ISS unless I do something drastic like
> >> > removing one of the wires from the clock differential pair which
> >> > results in constant complex IO error interrupts from CSIA until I
> >> > restore the physical connection.
> >> > 
> >> > My test setup includes a OV6540 sensor camera module (MIPI) from
> >> > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
> >> > forming an interconnect between the two. The sensor is connected to
> >> > CSI21 on the OMAP4 using a clock lane (on position 1, default
> >> > polarity) and a single data lane (on position 2, default polarity),
> >> > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
> >> > to 19.2MHz when asked for 24MHz).
> >> > 
> >> > The relevant parts of my device tree can be seen here:
> >> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
> >> > somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
> >> > Does anything else need to be done here? As far as I can tell I think
> >> > all clocks and power has been switched on. I do make two function
> >> > calls to the PM API in the ISS probe function, i.e.:
> >> > 
> >> > pm_runtime_enable(&pdev->dev);
> >> > r = pm_runtime_get_sync(&pdev->dev);
> >> 
> >> The ti,hwmod = "iss" hooks up the device with the PM runtime, see
> >> omap_hwmod_44xx_data.c for "iss".
> >> 
> >> > Regarding my debugging, this is what I have checked so far
> >> > 
> >> > * Changing the pixel rate of the sensor - this lead me to discover a
> >> > possible bug in iss.c or perhaps my ov5640 driver, as the
> >> > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
> >> > by copying what Laurent has done in the OMAP3ISP driver which now
> >> > works.
> >> > * As I only have a 100MHz scope, I had to slow down the camera
> >> > significantly (MIPI clock => 10-12MHz range) to verify that I was
> >> > getting reasonable output from the sensor (i.e. signals that were
> >> > characteristic of CSI2/MIPI). I checked the calculations and made sure
> >> > these updated values came across via the V4L2_CID_PIXEL_RATE control
> >> > and ended up in the THS_TERM and THS_SETTLE fields of register 0.
> >> > * Using the omapconf tool, I have manually and one by one pulled up
> >> > the CSI2 pins and verified multiple times all connections to the
> >> > sensor module and have even manually tried swapping the DP/DN pairs in
> >> > case they were still somehow backwards despite previous testing
> >> > * Verified that the interrupt service routine is called by generating
> >> > a test interrupt HS_VS from inside the ISS i.e.
> >> > 
> >> > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
> >> > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
> >> > 
> >> > * Verified that the default CMA region is being used, it ends up in
> >> > the ping-pong resisters of the ISS.
> >> > 
> >> > Additional information:
> >> > 
> >> > * Initialisation of pipe line and stream commands:
> >> > 
> >> > media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
> >> > media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
> >> > [UYVY 640x480]'
> >> > yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
> >> > 
> >> > * Output from OMAPCONF tool is in the second part of:
> >> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638
> >> > 
> >> > Anyway, at this point, I'm almost completely out of ideas on how to
> >> > move forwards so any suggestions, criticisms or help of any nature
> >> > would be appreciated!
> >> 
> >> Usually it's pinmuxing or some regulator or clock not enabled. Or
> >> incorrect hwmod sysc and syss configuration for iss that prevents
> >> enabling it properly.
> > 
> > And have you tried the same setup with platform data ?

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: 0001-ARM-OMAP4-hwmod-Enable-ISS.patch --]
[-- Type: text/x-patch, Size: 1782 bytes --]

>From 05eea18a101240ed9960a99d23b67aba4672b70a Mon Sep 17 00:00:00 2001
From: Sergio Aguirre <saaguirre@ti.com>
Date: Wed, 30 Nov 2011 10:19:42 -0600
Subject: [PATCH 1/2] ARM: OMAP4: hwmod: Enable ISS

Add the CSI2A, CSI2B, CSIPHY1, CSIPHY2, ISP SYS1, ISIF, IPIPEIF, IPIPE,
BTE and RESIZER memory sections to the ISS hwmod entry.

Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 50 ++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 8f0058ef3838..85f2cb55e7d8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3233,6 +3233,56 @@ static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
 		.pa_end		= 0x520000ff,
 		.flags		= ADDR_TYPE_RT
 	},
+	{
+		.pa_start	= 0x52001000,
+		.pa_end		= 0x5200116f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52001170,
+		.pa_end		= 0x5200118f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52001400,
+		.pa_end		= 0x5200156f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52001570,
+		.pa_end		= 0x5200158f,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52002000,
+		.pa_end		= 0x520021FF,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52010000,
+		.pa_end		= 0x5201009F,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52010400,
+		.pa_end		= 0x520107FF,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52010800,
+		.pa_end		= 0x52010FFF,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52011000,
+		.pa_end		= 0x520111FF,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.pa_start	= 0x52011200,
+		.pa_end		= 0x5201127F,
+		.flags		= ADDR_TYPE_RT
+	},
 	{ }
 };
 
-- 
2.3.6


[-- Attachment #3: 0002-ARM-OMAP4-Add-support-for-the-camera-interface-ISS.patch --]
[-- Type: text/x-patch, Size: 2510 bytes --]

>From 3bbfd1931f54fb8075fe0b37530fc0e5965b6e82 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre <saaguirre@ti.com>
Date: Wed, 25 Jan 2012 01:48:33 -0600
Subject: [PATCH 2/2] ARM: OMAP4: Add support for the camera interface (ISS)

Add an omap4_init_camera() to be used by board files to initialize the
OMAP4 ISS.

Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
---
 arch/arm/mach-omap2/devices.c | 40 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/devices.h |  4 ++++
 2 files changed, 44 insertions(+)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b57116e0b394..e64cc04dc2a0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -22,7 +22,12 @@
 #include <linux/netdevice.h>
 #include <linux/if_ether.h>
 #include <linux/pm_runtime.h>
+#ifdef CONFIG_CMA
+#include <linux/dma-contiguous.h>
+#endif
+
 #include <media/omap3isp.h>
+#include <media/omap4iss.h>
 
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -300,6 +305,41 @@ int omap3_init_camera(struct isp_platform_data *pdata)
 
 #endif
 
+int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data *bdata)
+{
+	struct platform_device *pdev;
+	struct omap_hwmod *oh;
+	struct iss_platform_data *omap4iss_pdata;
+	const char *oh_name = "iss";
+	const char *name = "omap4iss";
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("Could not look up %s\n", oh_name);
+		return -ENODEV;
+	}
+
+	omap4iss_pdata = pdata;
+
+	pdev = omap_device_build(name, -1, oh, omap4iss_pdata,
+			sizeof(struct iss_platform_data), NULL, 0, 0);
+
+	if (IS_ERR(pdev)) {
+		WARN(1, "Can't build omap_device for %s:%s.\n",
+						name, oh->name);
+		return PTR_ERR(pdev);
+	}
+
+	oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
+
+#ifdef CONFIG_CMA
+	/* Create private 32MiB contiguous memory area for omap4iss device */
+	dma_declare_contiguous(&pdev->dev, 32*SZ_1M, 0, 0);
+#endif
+
+	return 0;
+}
+
 static inline void omap_init_camera(void)
 {
 #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h
index f61eb6e5d136..31ba87fb9030 100644
--- a/arch/arm/mach-omap2/devices.h
+++ b/arch/arm/mach-omap2/devices.h
@@ -16,4 +16,8 @@ struct isp_platform_data;
 
 int omap3_init_camera(struct isp_platform_data *pdata);
 
+struct iss_platform_data;
+
+int omap4_init_camera(struct iss_platform_data *pdata,
+			     struct omap_board_data *bdata);
 #endif
-- 
2.3.6

Re: [RFC] v4l: omap4iss: DT bindings development

[Michael Allwright]

Thanks for the patch Laurent!

I have found out now what I have missed, I did not declare the DMA
channels in my DT. I'm now able to capture frames at 720p. VGA and
QVGA frames are coming out grainy and discoloured for the moment so
this will require some further investigation. See:

QVGA - https://db.tt/Asyq0xj8
VGA - https://db.tt/BIy8oVDv
720P - https://db.tt/32c9aEOF

I will slowly move forwards now and develop a set of patches that
allow for the ISS to work on a mainline DT enabled kernel. I think it
is also necessary to extend the V4L2 API slightly to create a function
called v4l2_of_parse_sensor_bus which takes a remote endpoint and
returns the underlying control bus (generally i2c) following what is
outlined in Documentation/devicetree/bindings/media/video-interfaces.txt
- This is required for setting up V4L2 asynchronous match between the
sensor and the ISS.

Thanks again for the support everyone!
Michael Allwright

PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering

University of Paderborn
Office-number 02-47
Zukunftsmeile 1
33102 Paderborn
Germany


On 6 June 2015 at 05:01, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Michael,
>
> On Thursday 04 June 2015 16:56:47 Michael Allwright wrote:
>> Thank you for the replies. Laurent I have started using the platform
>> data to see if I can determine whether I have a software problem or a
>> hardware problem. One thing that is confusing me, is how are memory
>> resources are supposed to be properly mapped to a kernel module in a
>> DT enabled kernel using the hwmod abstraction layer.
>>
>> It seems that the omap4iss driver in the mainline is expecting
>> resources to be declared in the format that was changed around about
>> this commit:
>> https://www.gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/8304f1
>> 3d002dfaf618473a551dbbc35cfcdc2742
>>
>> In the driver in the mainline, these resources are acquired in the
>> probe function by this loop here from iss.c:1397
>> for (i = 1; i < OMAP4_ISS_MEM_LAST; i++) { ret =
>> iss_map_mem_resource(pdev, iss, i); if (ret) goto error_iss; }
>>
>> However the definitions of these registers have completely disappeared
>> in the mainline, nor are they in the master branches of linux-media or
>> linux-omap (see arch/arm/mach-omap2/devices.c / h). Interesting enough
>> the definitions for the OMAP3 ISP are still there. Furthermore looking
>> at the omap_hwmod_44xx_data.c in these branches I can see the hwmod
>> layer is only declaring the first 0xff bytes of address space starting
>> at 0x52000000, this obviously doesn't include the CSIA/B registers nor
>> the CAMERARX registers which are all at addresses >0x520000ff.
>>
>> TLDR: omap4iss seems somewhat broken in the mainline (3.17),
>> linux-media (master) and linux-omap (master), which repo/branch are
>> you using for testing? Or what happened to the omap4_iss_resources
>> array?
>
> I've mostly been using a TI v3.4 BSP to which I've backported the mainline
> driver. The iss hwmod is indeed broken in mainline.
>
> The two attached patches should help for testing the ISS driver with platform
> data. As we're moving to DT it's probably not worth it pushing them to
> mainline.
>
> I used the following board code when developing a driver for the Aptina AR0330
> used with a Panda board. That was quite a long time ago, I never managed to
> get it fully working and had to move to different projects. The code might
> thus not even compile.
>
> #include <linux/gpio.h>
> #include <linux/clk.h>
> #include <linux/delay.h>
>
> #include <plat/i2c.h>
> #include <plat/omap-pm.h>
>
> #include <asm/mach-types.h>
>
> #include <media/ar0330.h>
>
> #include "devices.h"
> #include "../../../drivers/media/video/omap4iss/iss.h"
>
> #include "control.h"
> #include "mux.h"
>
> #define PANDA_GPIO_CAM_RESET            83
>
> #define AR0330_I2C_ADDRESS              0x10
>
> static struct ar0330_platform_data panda_ar0330_data = {
> };
>
> static struct i2c_board_info panda_camera_i2c_device = {
>         I2C_BOARD_INFO("ar0330", AR0330_I2C_ADDRESS),
>         .platform_data = &ar0330_platform_data,
> };
>
> static struct iss_subdev_i2c_board_info panda_ar0330_subdevs[] = {
>         {
>                 .board_info = &panda_camera_i2c_device,
>                 .i2c_adapter_id = 3,
>         },
>         { NULL, 0, },
> };
>
> static struct iss_v4l2_subdevs_group panda_camera_subdevs[] = {
>         {
>                 .subdevs = panda_ar0330_subdevs,
>                 .interface = ISS_INTERFACE_CSI2A_PHY1,
>                 .bus = { .csi2 = {
>                         .lanecfg        = {
>                                 .clk = {
>                                         .pol = 0,
>                                         .pos = 2,
>                                 },
>                                 .data[0] = {
>                                         .pol = 0,
>                                         .pos = 1,
>                                 },
>                                 .data[1] = {
>                                         .pol = 0,
>                                         .pos = 3,
>                                 },
>                         },
>                 } },
>         },
>         { },
> };
>
> static void panda_omap4iss_set_constraints(struct iss_device *iss, bool
> enable)
> {
>         if (!iss)
>                 return;
>
>         /* FIXME: Look for something more precise as a good throughtput limit */
>         omap_pm_set_min_bus_tput(iss->dev, OCP_INITIATOR_AGENT,
>                                  enable ? 800000 : -1);
> }
>
> static struct iss_platform_data panda_iss_platform_data = {
>         .subdevs = panda_camera_subdevs,
>         .set_constraints = panda_omap4iss_set_constraints,
> };
>
> static struct omap_device_pad omap4iss_pads[] = {
>         {
>                 .name   = "csi21_dx0.csi21_dx0",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
>         {
>                 .name   = "csi21_dy0.csi21_dy0",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
>         {
>                 .name   = "csi21_dx1.csi21_dx1",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
>         {
>                 .name   = "csi21_dy1.csi21_dy1",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
>         {
>                 .name   = "csi21_dx2.csi21_dx2",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
>         {
>                 .name   = "csi21_dy2.csi21_dy2",
>                 .enable = OMAP_MUX_MODE0 | OMAP_INPUT_EN,
>         },
> };
>
> static struct omap_board_data omap4iss_data = {
>         .id                     = 1,
>         .pads                   = omap4iss_pads,
>         .pads_cnt               = ARRAY_SIZE(omap4iss_pads),
> };
>
> static int __init panda_camera_init(void)
> {
>         struct clk *clk;
>
>         if (!machine_is_omap4_panda())
>                 return 0;
>
>         clk = clk_get(NULL, "auxclk1_ck");
>         if (IS_ERR(clk)) {
>                 printk(KERN_ERR "Unable to get auxclk1_ck\n");
>                 return -ENODEV;
>         }
>
>         panda_ar0330_data.clock = clk;
>
>         /* Select GPIO 83 */
>         omap_mux_init_gpio(PANDA_GPIO_CAM_RESET, OMAP_PIN_OUTPUT);
>
>         /* Init FREF_CLK1_OUT */
>         omap_mux_init_signal("fref_clk1_out", OMAP_PIN_OUTPUT);
>
>         if (gpio_request_one(PANDA_GPIO_CAM_RESET, GPIOF_OUT_INIT_HIGH,
>                              "CAM_RESET"))
>                 printk(KERN_WARNING "Cannot request GPIO %d\n",
>                        PANDA_GPIO_CAM_RESET);
>
>         panda_ar0330_data.reset = PANDA_GPIO_CAM_RESET;
>
>         return omap4_init_camera(&panda_iss_platform_data, &omap4iss_data);
> }
> late_initcall(panda_camera_init);
>
>
>> On 2 June 2015 at 18:22, Laurent Pinchart wrote:
>> > On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
>> >> * Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
>> >> > Hi Everyone,
>> >> >
>> >> > I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
>> >> > am unable to capture any data in my test setup. As detailed below, it
>> >> > seems that everything has been configured correctly however I never
>> >> > get any interrupts from the ISS unless I do something drastic like
>> >> > removing one of the wires from the clock differential pair which
>> >> > results in constant complex IO error interrupts from CSIA until I
>> >> > restore the physical connection.
>> >> >
>> >> > My test setup includes a OV6540 sensor camera module (MIPI) from
>> >> > Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
>> >> > forming an interconnect between the two. The sensor is connected to
>> >> > CSI21 on the OMAP4 using a clock lane (on position 1, default
>> >> > polarity) and a single data lane (on position 2, default polarity),
>> >> > the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
>> >> > to 19.2MHz when asked for 24MHz).
>> >> >
>> >> > The relevant parts of my device tree can be seen here:
>> >> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
>> >> > somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
>> >> > Does anything else need to be done here? As far as I can tell I think
>> >> > all clocks and power has been switched on. I do make two function
>> >> > calls to the PM API in the ISS probe function, i.e.:
>> >> >
>> >> > pm_runtime_enable(&pdev->dev);
>> >> > r = pm_runtime_get_sync(&pdev->dev);
>> >>
>> >> The ti,hwmod = "iss" hooks up the device with the PM runtime, see
>> >> omap_hwmod_44xx_data.c for "iss".
>> >>
>> >> > Regarding my debugging, this is what I have checked so far
>> >> >
>> >> > * Changing the pixel rate of the sensor - this lead me to discover a
>> >> > possible bug in iss.c or perhaps my ov5640 driver, as the
>> >> > V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
>> >> > by copying what Laurent has done in the OMAP3ISP driver which now
>> >> > works.
>> >> > * As I only have a 100MHz scope, I had to slow down the camera
>> >> > significantly (MIPI clock => 10-12MHz range) to verify that I was
>> >> > getting reasonable output from the sensor (i.e. signals that were
>> >> > characteristic of CSI2/MIPI). I checked the calculations and made sure
>> >> > these updated values came across via the V4L2_CID_PIXEL_RATE control
>> >> > and ended up in the THS_TERM and THS_SETTLE fields of register 0.
>> >> > * Using the omapconf tool, I have manually and one by one pulled up
>> >> > the CSI2 pins and verified multiple times all connections to the
>> >> > sensor module and have even manually tried swapping the DP/DN pairs in
>> >> > case they were still somehow backwards despite previous testing
>> >> > * Verified that the interrupt service routine is called by generating
>> >> > a test interrupt HS_VS from inside the ISS i.e.
>> >> >
>> >> > ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
>> >> > ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
>> >> >
>> >> > * Verified that the default CMA region is being used, it ends up in
>> >> > the ping-pong resisters of the ISS.
>> >> >
>> >> > Additional information:
>> >> >
>> >> > * Initialisation of pipe line and stream commands:
>> >> >
>> >> > media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
>> >> > media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
>> >> > [UYVY 640x480]'
>> >> > yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
>> >> >
>> >> > * Output from OMAPCONF tool is in the second part of:
>> >> > https://gist.github.com/allsey87/fdf1feb6eb6a94158638
>> >> >
>> >> > Anyway, at this point, I'm almost completely out of ideas on how to
>> >> > move forwards so any suggestions, criticisms or help of any nature
>> >> > would be appreciated!
>> >>
>> >> Usually it's pinmuxing or some regulator or clock not enabled. Or
>> >> incorrect hwmod sysc and syss configuration for iss that prevents
>> >> enabling it properly.
>> >
>> > And have you tried the same setup with platform data ?
>
> --
> Regards,
>
> Laurent Pinchart

Re: [RFC] v4l: omap4iss: DT bindings development

[Laurent Pinchart]

Hi Michael,

On Sunday 07 June 2015 17:35:48 Michael Allwright wrote:
> Thanks for the patch Laurent!
> 
> I have found out now what I have missed, I did not declare the DMA
> channels in my DT. I'm now able to capture frames at 720p. VGA and
> QVGA frames are coming out grainy and discoloured for the moment so
> this will require some further investigation. See:
> 
> QVGA - https://db.tt/Asyq0xj8
> VGA - https://db.tt/BIy8oVDv
> 720P - https://db.tt/32c9aEOF
> 
> I will slowly move forwards now and develop a set of patches that
> allow for the ISS to work on a mainline DT enabled kernel.

Please feel free to post patches incrementally, you don't have to fix all 
problems in one go. It will actually be easier for me to review the patches if 
they're sent incrementally than in one large series.

> I think it is also necessary to extend the V4L2 API slightly to create a
> function called v4l2_of_parse_sensor_bus which takes a remote endpoint and
> returns the underlying control bus (generally i2c) following what is
> outlined in Documentation/devicetree/bindings/media/video-interfaces.txt
> - This is required for setting up V4L2 asynchronous match between the
> sensor and the ISS.

I'm not convinced about that. Can't you just use V4L2_ASYNC_MATCH_OF instead 
of V4L2_ASYNC_MATCH_I2C ?

> Thanks again for the support everyone!

You're welcome.

-- 
Regards,

Laurent Pinchart