search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.22k stars 5.03k forks source link

unicam: kernel 5.3.5: the driver fails to setup the capture format ('v4l2-ctl -V' prints "Format Unknown (00000000):") #3301

Open andrey-konovalov opened 5 years ago

andrey-konovalov commented 5 years ago

Describe the bug Can't capture with unicam as the format it reports is unknown (00000000)

To reproduce

Expected behaviour pi@raspberrypi:~ $ v4l2-ctl -V --verbose VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok Format Video Capture: Width/Height : 3280/2464 Pixel Format : 'pBAA' (10-bit Bayer BGBG/GRGR Packed) Field : None Bytes per Line : 4112 Size Image : 10131968 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : pi@raspberrypi:~ $

Actual behaviour pi@rpi-zero-w:~ $ v4l2-ctl -V --verbose VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok Format Unknown (00000000): pi@rpi-zero-w:~ $

System

Logs

From dmesg output: [ 30.796371] uart-pl011 20201000.serial: no DMA platform data [ 31.072524] 8021q: 802.1Q VLAN Support v1.8 [ 32.484599] imx219_vddl: disabling [ 32.484634] imx219_vdig: disabling [ 32.484654] imx219_vana: disabling [ 33.601182] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:1 02396k SSFS [ 34.405613] unicam 20801000.csi: code mismatch - fmt->code 00000000, mbus_fmt .code 00003007 [ 36.322524] Bluetooth: Core ver 2.22 [ 36.322778] NET: Registered protocol family 31

When I rmmod and then 'modprobe bcm2835_unicam debug=4' again: [ 1999.137237] unicam 20801000.csi: ep_node is endpoint [ 1999.137300] unicam 20801000.csi: sensor_node is imx219 [ 1999.137315] unicam 20801000.csi: remote_ep is endpoint [ 1999.137348] unicam 20801000.csi: parsed remote_ep to endpoint. nr_of_link_frequencies 0, bus_type 5 [ 1999.137358] unicam 20801000.csi: bus_type is 5 [ 1999.137366] unicam 20801000.csi: v4l2-endpoint: CSI2 [ 1999.137376] unicam 20801000.csi: Virtual Channel=0 [ 1999.137385] unicam 20801000.csi: flags=0x00000200 [ 1999.137394] unicam 20801000.csi: num_data_lanes=2 [ 1999.137401] unicam 20801000.csi: found sub-device imx219 [ 1999.137471] unicam 20801000.csi: Using sensor imx219 0-0010 for capture [ 1999.137480] unicam 20801000.csi: Get supported formats... [ 1999.137493] unicam 20801000.csi: subdev->enum_mbus_code idx 0 returned -22 - continue [ 1999.137502] unicam 20801000.csi: Done all formats [ 1999.137524] unicam 20801000.csi: subdev_get_format 3280x2464 code:3007 [ 1999.137539] unicam 20801000.csi: subdev_set_format 3280x2464 code:0000 [ 1999.137550] unicam 20801000.csi: __subdev_get_format 3280x2464 code:3007 [ 1999.137560] unicam 20801000.csi: code mismatch - fmt->code 00000000, mbus_fmt.code 00003007

pi@rpi-zero-w:~ $ cat /proc/version Linux version 5.3.5+ (ynk@TM-8481) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03)) #1 Wed Oct 16 14:07:53 MSK 2019

pi@rpi-zero-w:~ $ tail /boot/config.txt dtoverlay=vc4-fkms-v3d max_framebuffers=2

[all]

dtoverlay=vc4-fkms-v3d

start_x=1 gpu_mem=128

dtoverlay=ov5647,i2c_pins_28_29

dtoverlay=imx219,i2c_pins_28_29

6by9 commented 5 years ago

I'm not testing against 5.3. Please check for diffs between 5.3 and 4.19.

6by9 commented 5 years ago

Oh, I vaguely recall hitting an issue with the V4L2 core now checking additional parameters on subdev calls. An equivalent to https://github.com/6by9/linux/commit/4f76e4571ca7c9e51a5adfcb90fe879429f7ebdc on get_fmt calls may be the solution to your problem.

andrey-konovalov commented 5 years ago

@6by9 Thanks a lot for your advice! It was indeed an unset field in the structure when calling enum_mbus_code. Here is the change which made the capture to work with 5.3.7:

--- a/drivers/media/platform/bcm2835/bcm2835-unicam.c
+++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
@@ -1771,6 +1771,7 @@ unicam_async_bound(struct v4l2_async_notifier *notifier,

                memset(&mbus_code, 0, sizeof(mbus_code));
                mbus_code.index = j;
+               mbus_code.which = V4L2_SUBDEV_FORMAT_ACTIVE;
                ret = v4l2_subdev_call(subdev, pad, enum_mbus_code,
                                       NULL, &mbus_code);
                if (ret < 0) {
andrey-konovalov commented 5 years ago

@6by9 IOW this is exactly the patch you referred to which is missing from the rpi/rpi-5.3.y branch.

andrey-konovalov commented 5 years ago

@6by9 BTW, are you aware of any plans to push the unicam and the imx219 drivers upstream? They were both added to RaspberryPi's kernels, but are missing from the mainline. If this is just the man-hours problem, I could help with the imx219 driver.

andrey-konovalov commented 5 years ago

@6by9 Also I am OK with closing this issue as the fix is known. But I can left it open if you plan to merge your fix into rpi-5.3.y someday. Please advise. Thanks!

6by9 commented 5 years ago

@andrey-konovalov Sorry, I was at ELCE discussing Libcamera things. I believe you're also in contact with Kieran, and whilst at ELCE your colleague Peter Griffin volunteered your servivces in upstreaming things!

Unicam and imx219 drivers are wanted to be upstreamed now because Libcamera wants to run against a mainline kernel.

IMX219 is pretty much done as far as I'm concerned. There are two things that would be nice to clean up, and that's frame rate control and interaction with exposure time (currently set a long exposure time and the frame rate drops), and ideally H&V flips as Unicam should now recognise the change in format automatically.

Unicam needs a minor strip back as they rejected the mechanism of negotiating the number of lanes to use, and they don't want the receiver driver looking at the source DT for clocking mode. That bit wasn't working for me on 5.3 anyway, but has knock on effects for the DT overlays as well. Generally the v4l2_fwnode stuff needs checking over.

My plan is to make a clean set of patches on top of the 5.4 branch that is about to be made here. That should be pretty close to ToT for the subsystem trees, so upstreaming should be a relatively small job. If you wanted to take on upstreaming imx219 initially, then you would make me a very happy man. Kieran said you had some changes of your own, so it would be nice to review those before you sent things upstream, but not critical.

I wasn't going to fix up 5.3 as it's not a kernel release that will ever be adopted by Raspbian, so I'm not generally building it or testing for regressions.

Feel free to email me directly to discuss upstreaming stuff - you'll find my email address on all the patches for either of the drivers referenced :-)