What causes "resource temporarily unavailable" in v4l2

Question

I have compiled adv7180 driver available here.

I am unloading the ov5642 cameradriver(which in my case is built-in) and loading the adv7180_tvin module and after I am loading mxcv4l2_capture module which creates video0 in /dev/. (dmesg command says: "mxc camera on IPU2_CSI1 registered as video0")

But when I try to access video0 with v4l2-ctl I got a message "resource temporarily unavailable" or when I am using gstreamer I got message "Can not open /dev/video0" (but the device is really created).

Is that a problem in device tree settings or it can be caused by something else? Which tools should I use to find out what causes this issue?

My device tree settings look like below:

&i2c3{
adv7180: adv7180@20{
compatible = "adv,adv7180";
reg = <0x20>;
clocks = <&clks IMX6QDL_CLK_CKO2>;
clock-names = "csi_mclk";
pwn-gpios = <&gpio3 10 GPIO_ACTIVE_LOW>;
ipu_id = <1>;
csi_id = <1>;
mclk = <24000000>;
mclk_source = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_parallel>;

cvbs = <1>;

};
};

I need to add that before adv7180 I was using above settings for ov5642 camera (excluding cvbs setting) and everything worked properly.

EDIT:

Ok I got one clue.

When I load modules in dmesg message "mxc_v4l2_master_attach: ipu(0:1)/csi(1:1)/mipi(0:0) doesn't match" shows. But it only happens when ipu_id=<1> in v4l2_cap device tree settings and in adv7180 settings. When i change ipu_id to ipu_id=<0> in v4l2 settings and adv7180 dmesg now shows "parallel attach to IPU1 CSI1 and I can access the /dev/video0 succesfully with v4l2-ctl tool.

But In my case there is only one possibility to use IPU2_CSI1.

Why can't I set IPU2 to adv7180 when I was using it successfully to ov5642 ?

vinod maverick · Accepted Answer · 2017-03-31T15:07:10.643

1

As per my knowledge i.MX6 having two IPUs. I think by default IPU1 parallel interface is not enabled in the board file. So you need to check the IOMUXC_GPR1 register setting (bit 19 and 20) for IPU/CSI1 and pass the csi_id in your camera driver.

As you are using the parallel interface so check your pin muxing setting as well in your device tree. (which is not required for serial interface.)

Edit: There are two ways which you can follow to update the register setting from the kernel space (boardfile or camera driver) itself:

1. From the board file:

struct regmap *gpr
gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
regmap_update_bits(gpr, IOMUXC_GPR1, 1 << 20, 1 << 20);

2. From the boardfile or camera driver

void __iomem *va_ipu2_address;
u32 reg_val;
va_ipu2_address = ioremap(0x20e0004,0xe0004);
reg_val = readl(va_ipu2_address);
/* Enable parallel interface to IPU2 CSI1.  */
writel(reg_val | 1 << 20, va_ipu2_address);

edited Mar 31 '17 at 15:07

answered Mar 29 '17 at 01:37

vinod maverick

670
4
14

Without schametic I can not say weather it is correct or not. But if the same pin mixing is working for you with ov5642 then it should be fine. You can set the IOMUX_GPR1 register from the board file. The board file location should be arch/arm/mach-imx/* depend upon the processor. If you have not customised your kernel then I think it should be mach-imx6q.c file. Apart from this you can use ipu_id inside your driver. – vinod maverick Mar 29 '17 at 14:07
Thanks. I didn't customize kernel so I changed line 370 in "mach-imx6q.c" file to set bit 20 to "1". Then I built linux image again and rebooted. But the problem still exists. Is there any thing else I should do instead of making a new imege ? How can I check if the value in register really changed ? – S.Seba Mar 30 '17 at 13:25
Yes. Either you can read the register the value through real from kernel space or you can use the devreg tool (which i always prefer) to access the register values from the user space. So verify your IPU2 register from the user space. If your driver is working fine with IPU1 then I don't find any other reason (apart from the enablement of IPU2). – vinod maverick Mar 30 '17 at 14:00
check the CCM_CCGR3 register as well which enable the clock of IPU2. – vinod maverick Mar 30 '17 at 14:28
Ok. I used devmem2 to check valued of register 0x20E0004 (devmem2 0x20E0004) it seems like this value doesn't change no matter if I pass 1<<19 or 1<<20 in line 370 of mach-imx6.c file. I will try to add ipu_id to my driver somehow. Thank You very much for help ! – S.Seba Mar 31 '17 at 07:56

S.Seba · Answer 2 · 2017-03-29T12:10:43.280

Thanks for Your answer. My pinmuxing looks like this:

 &iomuxc{
 hummingboard2{
  pinctrl_hummingboard2_parallel: hummingboard2_parallel{
 fsl,pins = <
 MX6QDL_PAD_EIM_A24__IPU2_CSI1_DATA19 0x0b0b1
 MX6QDL_PAD_EIM_A23__IPU2_CSI1_DATA18 0x0b0b1
 MX6QDL_PAD_EIM_A22__IPU2_CSI1_DATA17 0x0b0b1
 MX6QDL_PAD_EIM_A21__IPU2_CSI1_DATA16 0x0b0b1
 MX6QDL_PAD_EIM_A20__IPU2_CSI1_DATA15 0x0b0b1
 MX6QDL_PAD_EIM_A19__IPU2_CSI1_DATA14 0x0b0b1
 MX6QDL_PAD_EIM_A18__IPU2_CSI1_DATA13 0x0b0b1
 MX6QDL_PAD_EIM_A17__IPU2_CSI1_DATA12 0x0b0b1
 MX6QDL_PAD_EIM_DA11__IPU2_CSI1_HSYNC 0x0b0b1
 MX6QDL_PAD_EIM_DA12__IPU2_CSI1_VSYNC 0x0b0b1
 MX6QDL_PAD_EIM_A16__IPU2_CSI1_PIXCLK 0x0b0b1

 MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1    
 >;
 };
 };
 };

and it's been working succesively with ov5642 camera. No I see that the adv7180 driver does not take an ipu_id as an argument from device tree so I think it is using the default ipu which is (I think) IPU1.

I've been playing arround how to change settings in IOMUXC_GPR1. Bit 20 needs to be set ("enable parallel interface to IPU2 CSI1). But have got no more ideas how to do it in device tree.

score 0 · Answer 3 · answered Mar 31 '17 at 12:02

Ok. I found it !

I couldn't set bit 20 in IOMUXC_GPR1 register using mach-imx6q.c file so I did it this way:

in console:

sudo devmem2 0x20e0004

and read the existing value (which was in my case 0x48643005). Then I set bit 20 to one ("1") so I got 0x48743005 and I put this value into the register:

sudo devmem2 0x20e0004 w 0x48743005

next I loaded adv7180_tvin and mxc_v4l2_capture modules and captured frames using gsreamer:

gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! imxipuvideotransform ! autovideosink deinterlace=true

Everything works great ! Thanks for help !

That is good news. But I think it will be better if you can achieve the same thing from the kernel space itself. I have updated the answer for the same so you can try it. — vinod maverick, Mar 31 '17 at 15:10

What causes "resource temporarily unavailable" in v4l2

3 Answers3