AM5728: ADV7611 issue in capturing video with TMDSEVM572x board

Hi

is there any help? ...

Ali

Hi Ali

> [ 39.980912] vin3a: vip_init_port: g_mbus_fmt subdev mbus_code: 100A fourcc:RGB3 size: -1056617069x-718341108

The size appears to be un-initialized or set to undefined enums. What is the expected format and sizes here in your usecase.

Thanks,

Gowtham

Ali,

When VIP handshakes with the subdevice (adv7611) it enumerates its supported MBUS code (as seen in the traces above) to find all suitable format it VIP can actually handle.

VIP can only handle the following MBUS code:

MEDIA_BUS_FMT_UYVY8_2X8 (0x2006),

MEDIA_BUS_FMT_RGB888_1X24 (0x100a),

MEDIA_BUS_FMT_ARGB8888_1X32 (0x100d),

MEDIA_BUS_FMT_SBGGR8_1X8 (0x3001),

MEDIA_BUS_FMT_SGBRG8_1X8 (0x3013),

MEDIA_BUS_FMT_SGRBG8_1X8 (0x3002),

MEDIA_BUS_FMT_SRGGB8_1X8 (0x3014),

MEDIA_BUS_FMT_SBGGR16_1X16 (0x31d)

Now MEDIA_BUS_FMT_UYVY8_2X8 is the only mbus code VIP can use to generate all supported variant of YUV 422 and NV12.

It looks like the ADV7611 driver only supports MEDIA_BUS_FMT_YUYV8_2X8 (0x2008) which VIP does not support as input.

With you above configuration if you were to run:

v4l2-ctl --list-formats -d /dev/video1

It would show that none of the YUV format are available.

This is why the g-streamer pipeline fails.

Now with regard with the highlighted trace above with the resolution being wrong.

It looks like the adv7611 driver does not initialize to a default resolution at probe time.

The width and height seem to be only properly set after a set_format ioctl.

At this point however when VIP open the video device, it try to get the current format from the sensor so it knows if it needs to be changed later on.

I think you can safely ignore this log.

The correct resolution and format will be set when a S_FMT ioctl is sent.

Hope this helps.

Benoit

Hi Gowtham

than you for reply.

I'm using the default source code of SDK 06.00.00.07.

I expect it to initialize ADV7611 appropriate to dts file. in dts, I set the bus-width=<8> and without Hsync,Vsync, so I expect it to be initialize in mode BT656 8bit.

BR,

Ali

Hi Benoit

thanks very much for your reply.

wen i run command v4l2-ctl --list-formats -d /dev/video1 , the result is :

root@am57xx-evm:~# v4l2-ctl --list-formats -d /dev/video1
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'RGB3' (24-bit RGB 8-8-8)

why does not the driver set the ADV7611 in BT656 8Bit mode? I set the bus-width=<8> in dts and also removed Hsync and Vsync from dts file.

I think the driver reads the input parameters from dts file and set the ADV7611 as needed. is not it?

what should I do? should I change the ADV7604 (or ADV7611) driver source code?

BR,

Ali

Hi again Bengoit

I have designed an other board with ADV7611 that has 24 bit RGB connection with EVM connector P9.

I set the dts for adv7611 as :

port@1 {

reg = <1>;

endpoint {

phandle = <0x21d>

remote-endpoint = <0x21c>;

hsync-active = <0x0>;
vsync-active = <0x0>;
field-even-active = <0>;

channels = <0>;

pixel-mux;

bus-width= <24>;

};

};

that is, I want the ADV7611 to be set in 24 bit mode and with Hsync & Vsync (active high).

after reboot and installing the adv7604.ko, the dmesg log is :

root@am57xx-evm:~# insmod /lib/modules/4.19.38-g4dae378bbe/kernel/drivers/media/i2c/adv7604.ko
[ 80.010569] adv7611 4-004c: adv7611 found @ 0x98 (OMAP I2C adapter)
[ 80.017057] vin3a: Port A: Using subdev adv7611 4-004c for capture
[ 80.025145] vin3a-0: device registered as video1

root@am57xx-evm:~# dmesg | grep vip
[ 7.335996] vin3: vip_set_slice_path:
[ 7.336006] vin3: vip_set_slice_path: DATA_PATH_SELECT(0000010C): 80008000
[ 7.337199] vin4: vip_set_slice_path:
[ 7.337206] vin4: vip_set_slice_path: DATA_PATH_SELECT(00000110): 80008000
[ 7.337250] vip 48990000.vip: loading firmware vpdma-1b8.bin
[ 7.370039] vip 48990000.vip: VPDMA firmware loaded
[ 80.017050] vin3a: vip_async_bound
[ 80.032208] vin3a: vip_create_streams: bus_type = V4L2_MBUS_PARALLEL
[ 80.032216] vin3a: vip_async_complete
[ 80.032567] vin3a-0: vip_open
[ 80.032599] vin3a: vip_init_port: g_mbus_fmt subdev mbus_code: 100A fourcc:RGB3 size: -1056617069x-727753716

I checked the signals of ADV7611 by oscilloscope and saw that Hsync & Vsync are correct (active high pulses with correct frequency appropriate to input resolution). but the data signals is not correct. only the 8 Bit data is generated.

now, it can not capture video again :

root@am57xx-evm:~# gst-launch-1.0 -e v4l2src device=/dev/video1 num-buffers=-1 io-mode=4 ! 'video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, framerate=(fraction)30/1' ! vpe num-input-buffers=1 ! ducatih264enc inter-interval=1 bitrate=5000 ! h264parse ! ducatih264dec ! vpe ! 'video/x-raw,format=(string)NV12, width=1280,height=720' ! waylandsink sync=false
Setting pipeline to PAUSED ...

** (gst-launch-1.0:1375): WARNING **: 03:16:[ 98.552816] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
25.520: Could not bind to zwp_linux_dmabuf_v1
Pipeline is live and does not need PREROLL ...
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../../../../gstreamer-1.14.4/libs/gst/base/gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

any help will be appreciated.

Best Regards,

Ali

Hi

is there any response?

BR,

Ali

Ali,

As I was describing previously VIP can only recognize MEDIA_BUS_FMT_UYVY8_2X8 (0x2006) as source of YUV video.

Since the adv7611 driver/sensor generate  MEDIA_BUS_FMT_YUYV8_2X8 (0x2008) then it won't match for YUV format.

It is able to match on MEDIA_BUS_FMT_RGB888_1X24 (0x100a) so that means you can capture RGB 24 bits.

The bus width parameters in DTS indicates how many data lines is being used to carry the video data from the sensor.

I would assume that without reworking the whole board to camera connectivity you probably still using only 8 data pins to carry the signals.

So bus-width should stay at 8. RGB 24 bits here is indicative of the pixel video format size and probably not the bus width. In other words with an 8bit data bus you would need 3 pixel clock to carry a single 24 bits pixel.

Now given that the only matched bus format is MEDIA_BUS_FMT_RGB888_1X24 then in this case VIP can only generate RGB3 as the output format.

In your test you are also still using the same g-streamer pipeline which tries to configure VIP to capture YUY2 which won't be possible in this case.

Your capture format would have to match 'RGB3' fourcc.

if you want to do a quick test, you could modify the adv7611 driver and replace the  MEDIA_BUS_FMT_YUYV8_2X8 with  MEDIA_BUS_FMT_UYVY8_2X8.

This would allow VIP to handshake with the adv7611 driver and give access to the YUV format, like YUY2.

Keep in mind that with modification the resulting colors would be wrong and probably green-ish looking but you should be able to capture something.

I would also keep g-streamer out of the loop and use a simple capture application until you get something working.

I normally use yavta for this purpose.

You can run "yavta --enum-formats .dev.video1" to see the list of format and resolution available.

Something like this would capture a quick test file with 20 frames:

yavta -c20 -fYUYV -Fcapture_test.yuv -s1280x720 /dev/video1

Ali,

Also I had missed in your previous message that you had reworked the hw connection to use 24 bits/pins.

When probing for the data pin signals where were you probing those data pins signals?

If the adv7611 is configured properly for MEDIA_BUS_FMT_RGB888_1X24 then i would assume it would generate data on all 24 pins.

If it is only generating data on 8 pins then maybe that specific issue is on the adv7611 side.

Now that being said on the device side (VIP) the pin muxing for the vin3a pins is done in u-boot, but it probably doesn't hurt to double check the pin muxing.

Hi Benoit

thanks very much for reply.

I had to discard and leave my work for a month because of Corona Virus.

I will test your recommendations soon and report the results.

thanks and regards,

Ali