6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

ADV7282 Analogue video to CSI chip with interlaced modes

Wed Jul 25, 2018 10:45 am

Branching grimepoch's conversation from viewtopic.php?f=43&t=109137&start=475#p1343297

Synopsis is that he is using ADV7282A-M to receive NTSC. Initially using raspiraw, but being pointed to the main kernel drivers. These are working.
Whilst the ADV7282 has an I2P (Interlaced 2 Progressive) block, it is a simple line doubling type algorithm, so he wants to receive the interlaced video and deinterlace on the Pi.
There is no signalling of which field is which over the CSI2, so the only thing to go on is that apparently one field is a line shorter than the other. The CSI2 peripheral won't give you accurate values in the bytesused field, the suggested option is to manually write a magic sequence into the line that may or may not be written, and then on receiving it back check whether it is there or not.
The Unicam driver also deliberately blocks selection of interlaced modes as there are no standard mechanisms for determining which field is which. That code has to be disabled.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Jul 25, 2018 10:55 am

Copying the last couple of posts:
grimepoch wrote:After much further digging, it is in fact the I2P processor. Once I had something with horizontal lines coming in, you could see the problem. This destroyed text rendering of course.

Using i2cset while it was running, I turned off the I2P which then just filled half frames while displaying with mmal.

Not sure what the proper way to make changes to the settings. Right now working on extracting the frame data to take a look at, so I can look at injecting my own special key on that extra line. (or finding a better way to do it).
6by9 wrote:CSI2 receiver changes required at https://github.com/raspberrypi/linux/bl ... cam.c#L749

If the driver could determine which field is which, then the struct v4l2_buffer should be returned with the field field being set appropriately. As I've said, in this case we can't, so the driver just copies the set field mode into the buffer.

Within yavta, ioctl(dev->fd, VIDIOC_DQBUF, &buf); dequeues the buffer from V4L2 before passing it to MMAL. VIDIOC_QBUF is the partner function that is returning a buffer to V4L2. So that gives you your two points to try checking and inserting magic sequences.

If I've read the code correctly, then dev->buffers[buf->index].mem[0] should be an mmap of the buffer so you don't need to do too much work. dev->plane_fmt[0].bytesperline should be the stride for each line, so you want to be looking at ((uint8_t*)dev->buffers[buf->index].mem[0])[dev->plane_fmt[0].bytesperline * y + x*2] should allow you to find any point in the image.
grimepoch wrote:Whew, okay, I'll look into what you've described, makes sense.

One thing I am trying to find more reference on is using MMAL. In this case MMAL is being used to render to the screen correct? I guess what I need to dig deeper on is how I want to get this data to the GPU for GLSL use. I have some USB webcam code I used that I believe also used MMAL so I will examine how that behaved as well and see what they did. I believe right now it uses glTexImage2D to stuff the image data into a texture.

Do you know of a good reference source that really talks about MMAL?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Jul 25, 2018 1:48 pm

yavta receives UYVY frames from V4L2. It uses MMAL to pass those frames through the ISP, and on to video encode and render the resulting frames.

Docs for MMAL are generally as markup in the headers. We all hate writing documentation, but I suspect I'll have to sit down and write some guides at some point.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Jul 25, 2018 4:05 pm

So I tried for myself, although I'm using a PAL source rather than NTSC.

Kernel diffs:

Code: Select all

diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c b/drivers/media/platform/bcm2835/bcm2835-unicam.c
index 8795692..6f9456b 100644
--- a/drivers/media/platform/bcm2835/bcm2835-unicam.c
+++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
@@ -86,6 +86,10 @@ static int debug;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Debug level 0-3");
 
+static int allow_interlaced;
+module_param(allow_interlaced, int, 0644);
+MODULE_PARM_DESC(debug, "Non-zero permits interlaced sources in s_fmt");
+
 #define unicam_dbg(level, dev, fmt, arg...)    \
                v4l2_dbg(level, debug, &(dev)->v4l2_dev, fmt, ##arg)
 #define unicam_info(dev, fmt, arg...)  \
@@ -749,7 +753,8 @@ static int unicam_try_fmt_vid_cap(struct file *file, void *priv,
         * No support for receiving interlaced video, so never
         * request it from the sensor subdev.
         */
-       mbus_fmt->field = V4L2_FIELD_NONE;
+       if (!allow_interlaced)
+               mbus_fmt->field = V4L2_FIELD_NONE;
 
        ret = v4l2_subdev_call(dev->sensor, pad, set_fmt, dev->sensor_config,
                               &sd_fmt);
Set allow_interlaced to non-zero either by hard coding it or /sys/modules/bcm2835_unicam/parameters/allow_interlaced and it'll let you select an interlaced mode.

There's already a yavta command-line option -I to fill the frames with 0x55 before queuing them with V4L2.
There's also an option "--field interlaced" that will request interlaced video.

So combine those into the command-line:

Code: Select all

./yavta --capture=1000 -n10 -f UYVY -m -T /dev/video0 --field interlaced -I -Fout.uyvy --skip 10
will select interlaced mode, drop the first 10 frames, and then save the rest to out.uyvy.
Review that file in an image editor (I like Vooya), and I find that we get the same number of lines in both fields.

As an alternative, apply the diff:

Code: Select all

@@ -2450,6 +2497,14 @@ static int video_do_capture(struct device *dev, unsigned int nframes,
                                        buf.timestamp.tv_sec, buf.timestamp.tv_usec,
                                        ts.tv_sec, ts.tv_nsec/1000, fps,
                                        ts_type, ts_source);*/
+                               for (int j=286; j<290; j+=1)
+                               {
+                                       struct buffer *buffer = &dev->buffers[buf.index];
+                                       uint8_t *image = (uint8_t*)buffer->mem[0] + (dev->plane_fmt[0].bytesperline*j) + 32;
+
+                                       printf("Buf idx %u (%u): Line %u, starts %08X%08X\n",
+                                               buf.index, buffer->idx, j, *(uint32_t*)&image[0], *(uint32_t*)&image[4]);
+                               }
 
                                last = buf.timestamp;
 
to print out the values from lines 280 to 289 (adjust appropriately for NTSC) at 16 pixels into the image, and I get

Code: Select all

Buf idx 4 (4): Line 286, starts AF87AE79AF86AE79
Buf idx 4 (4): Line 287, starts 6885687B6685677B
Buf idx 4 (4): Line 288, starts 5555555555555555
Buf idx 4 (4): Line 289, starts 5555555555555555
Buf idx 5 (5): Line 286, starts B486B377B686B477
Buf idx 5 (5): Line 287, starts 4184427942844279
Buf idx 5 (5): Line 288, starts 5555555555555555
Buf idx 5 (5): Line 289, starts 5555555555555555
Buf idx 6 (6): Line 286, starts AB86AB78AC86AB78
Buf idx 6 (6): Line 287, starts 7284717A7185717A
Buf idx 6 (6): Line 288, starts 5555555555555555
Buf idx 6 (6): Line 289, starts 5555555555555555
Buf idx 7 (7): Line 286, starts B587B478B587B478
Buf idx 7 (7): Line 287, starts 4385447A4385437A
Buf idx 7 (7): Line 288, starts 5555555555555555
Buf idx 7 (7): Line 289, starts 5555555555555555
Buf idx 8 (8): Line 286, starts AD86AC79AC86AC79
Buf idx 8 (8): Line 287, starts 6A856A7A6A846A7A
Buf idx 8 (8): Line 288, starts 5555555555555555
Buf idx 8 (8): Line 289, starts 5555555555555555
Buf idx 9 (9): Line 286, starts B386B378B287B377
Buf idx 9 (9): Line 287, starts 4384437943854479
Buf idx 9 (9): Line 288, starts 5555555555555555
Buf idx 9 (9): Line 289, starts 5555555555555555
ie it always writes line 287, but never into 288. As my line numbering is 0-based that's 288 lines per field, or 576 per frame, so that all adds up correctly.
(If you have the -Fout.uyvy option to save the data, that does take time and may result in frame drops).

The handling of NTSC may be different, but I'm skeptical.

You may be able to use the blanking in the first line. Looking at the first line of the images I get

Code: Select all

Buf idx 0 (0): Line 0, starts 1A801A801A801A801A801A801A801A801A801A801A801A801A801A801A801A80
Buf idx 1 (1): Line 0, starts E080FE80B680B580B680B780B580B880B580B880E080B7801680FE8019800180
Buf idx 2 (2): Line 0, starts 1A801A801A801A801A801A801A801A801A801A801A801A801A801A801A801A80
Buf idx 3 (3): Line 0, starts E080FE80B680B580B680B780B580B880B580B880E080B8801480FE8019800180
Buf idx 4 (4): Line 0, starts 1A801A801A801A801A801A801A801A801A801A801A801A801A801A801A801A80
Buf idx 5 (5): Line 0, starts E180FE80B680B680B680B780B580B880B580B880DF80B8801B80FE8019800180
Buf idx 6 (6): Line 0, starts 1A801A801A801A801A7F1A801A801A801A801A801A801A801A801A801A801A80
Buf idx 7 (7): Line 0, starts E080FE80B680B680B680B780B680B880B680B880E080B8801A80FE801A800180
Buf idx 8 (8): Line 0, starts 1A801A801A801A801A801A801A801B801A801A801A801A801A801A801A801A80
I'm printing the data as 32 bit words as it is easier, but that looks like one field has a very high luma value (0xB6 or greater), whilst the other has a very low luma (~ 0x1A). The chroma values of 0x80 would be right for monochrome images.
That may be the teletext data or similar that my source is producing (it's a Panasonic DMR-EX75 playing back an old Freeview recording), but you may get lucky as well with NTSC. Or it may be that the ADV chip is deliberately encoding that. I just don't know, and it isn't documented that I've seen.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Jul 25, 2018 6:50 pm

Thanks for the absolutely detailed response! I'll get back on this in a few days, I am tracking down some hardware specific issues with the ADV7182A with regards to a YCrCb input first, and the documentation for the ADC and clamping isn't the best either.

I'll be making this work for NTSC and PAL, just started on NTSC since all my equipment was already set up for that.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Fri Jul 27, 2018 6:11 pm

I've been continuing to talk to the people at Analog Devices about this issue. While NTSC does output an additional line, with PAL it does not. So that means this method of looking for an extra line is not going to do anything for me since I need to use PAL and NTSC.

It seems like their suggestion so far is to look at the EAV packet which does indicate which field you are. Do we have access to that, or the last one we received? (They mentioned SAV as well, but I hadn't looked at what that contained yet)

They also mentioned looking at the vertical blanking periods, not sure what is getting sent during that time.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Jul 28, 2018 7:29 am

(A redirect to Cloudflare just lost my first version of this)

SAV and EAV (Start and End of Active VIdeo) sound more like BT656 parallel video than CSI2. CSI2 has frame start and end short packets, which do include a frame count. They then also have line start and end short packets that include a line count. Generally we ignore both counters as sensors typically leave them at 0 always (permitted by the spec). CSI2 also doesn't tend to send the blanking lines, therefore all lines received are active lines.

As it happens I have been looking at a similar thing under https://github.com/6by9/raspiraw/issues/14. For the adv748x family of chips (HDMI and analogue video to CSI) they have documentation saying that they modify those counters in a predictable way for interlaced fields. There may be a debug feature in the CSI2 receiver that allows us to detect a unique combination of short frame, but I haven't tried it as yet.
I've got an Analogue Devices apps engineer coming in to discuss some stuff on Tues 7th Aug, so I'll ping him an email and see if he has any extra info on the ADV728x CSI and interlaced video.

The frame timestamps are when the frame start packet is received from the device. If there is a variation in the blanking intervals then you can have a look at the deltas. IIRC just streaming with v4l2-ctl (with the kernel patch to allow interlaced video) prints out the timestamps and deltas between buffers. I don't know if the printout includes sufficient resolution, and there may be a small amount of interrupt latency to account for.
I'm off for the next week, so haven't got hardware to play with until I'm back in the office to try it for myself.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Sat Jul 28, 2018 10:02 pm

My understanding is that the ADV7282 is sending either BT656-4 or BT656-3 (selectable by register selection) over CSI-2. Now whether the CSI-2 receiver is doing anything with that info, that is definitely a different story.

This is from the user guide:

Code: Select all

The decoder in the ADV7280A-M, ADV7281A-M, and ADV7282A-M output is an ITU-R BT.656 data stream. The ITU-R BT.656 data stream is connected into a MIPI Tx module. Data from the MIPI Tx module is fed into a D-PHY physical layer and output serially from the device.
While you wait to hear from the application engineer, I will continue to dig. It's interesting how many of these chips share the same IP.

robainche
Posts: 1
Joined: Wed Aug 01, 2018 2:25 pm

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Aug 01, 2018 3:45 pm

@6by9 do I understand it correctly that you are trying to get the adv748x up and running to allow both cvbs and HDMI input to the CSI-2?
Could you indicate a possible timeframe and feasibility for this?

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Wed Aug 01, 2018 10:46 pm

I've compiled in the changes and can not turn on interleaved, and I've looked at the data getting similar results to you. I did come across your conversation with danriches about the ADV7282 as well.

I've been trying to study the bcm2835-unicam.c c code and the adv7180.c code (with the 7282 updates that you pointed me to). I know that in other processors, like the iMX line they are able to decode interlaced from the just the MIPI stream. Although trying to abstract out how they are doing it is not easy because I think it is buried in the drivers and most of the conversations I have found are only relative to settings in the drivers, not the actual code.

I'm also found a post about the ADV7281-M that stated this:

Code: Select all

The ADV7281-M outputs MIPI CSI-2 with Frame Start/ Frame End packets and Line Start/End packets. This takes the place of the EAV/SAV codes that were used in the BT656 specification.


Is that consistent with what you were seeing?

If you have a look over at this page:

https://ez.analog.com/docs/DOC-10649-ad ... port-files

You'll see that an engineer captured the output of the interlaced frames (test pattern) and posted that information, it's in the file "ADV728x MIPI free run interlaced.zip" that you can download. If you dig down in, you can find either NTSC or PAL ITU656_4 (or 3) CSV file captures.

Just posting that particular info because I thought it was interesting.

Now, pertaining to the MIPI standard, it looks like their intension of "Line Synchronization Packets" were to be used for de-interlaceing. Having a look at their wording and they say:

Code: Select all

Line number increments by the same arbitrary step value greater than one for every LS packet within the same Virtual Channel and the same Data Type. The line number is periodically reset to a non-zero arbitrary start value for the first LS packet after a FS packet. The arbitrary start value may be different between successive frames. The intended usage is for interlaced video data streams.
Of course, line synchronization packets are optional, so we may not have them from the ADV7282. (Not seeing anything that jumps out in the capture)

We also have frame synchronization packets as well, not sure if we can figure out what we need off that value.

Nevertheless, I dug a little deeper into the capture, and this is what I notice on captured frames:

Code: Select all

Sample Number	 Time	 MIPI-CSI-2 Packet	 Data ID	 VCI	 Data Type	 Word Count	 Short Packet Data	 ECC	 Payload	 CheckSum	 Direction
65	 1.278520 ms	 Frame Start Code (HS)	0	0	0	 	1	 1A (GOOD)	 	 	 CSI-102
66	 1.279596 ms	 Line Start Code (HS)	2	0	2	 	3	 0D (GOOD)	 	 	 CSI-102
											
1101	 17.993238 ms	 Frame Start Code (HS)	0	0	0	 	2	 1C (GOOD)	 	 	 CSI-102
1102	 17.994310 ms	 Line Start Code (HS)	2	0	2	 	2	 17 (GOOD)	 	 	 CSI-102
											
2133	 34.644396 ms	 Frame Start Code (HS)	0	0	0	 	1	 1A (GOOD)	 	 	 CSI-102
2134	 34.645472 ms	 Line Start Code (HS)	2	0	2	 	3	 0D (GOOD)	 	 	 CSI-102
											
3169	 51.359114 ms	 Frame Start Code (HS)	0	0	0	 	2	 1C (GOOD)	 	 	 CSI-102
3170	 51.360186 ms	 Line Start Code (HS)	2	0	2	 	2	 17 (GOOD)	 	 	 CSI-102
Alternating frames, get a different short packet (1 versus 2) and the first Line Start Code is also different (3 versus 2). If we can extract either of these, maybe we can use that information?

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 02, 2018 12:48 am

We definitely want to use the Line Start Code, looking deeper, this is EXACTLY the interlaced information. I have verified in the captures that for one frame they are all ODD, and the other all EVEN.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 02, 2018 5:33 am

Digging deeper into the reference material, I looked at the driver code you started with for the unicam source, trying to see what other information we could get out of the registers.

Unfortunately, there is zero documentation out there to look any of these registers up, and searches for anything unicam typical comes up with your release notes and/or reviews people were doing to your releases. :)

Specifically, what first caught my eye was this struct:

Code: Select all

struct int_desc {
	u8 fsi;
	u8 fei;
	u32 lci;
	u8 die;
	u32 dataline;
};
Which led to these three functions being defined in their code:

Code: Select all

/* ISTA register ... only FS, FE and LCI are allowed */
int mm_csi0_get_int_stat(struct int_desc *desc, int ack);

int mm_csi0_get_data_stat(struct int_desc *desc, int ack);

/* Configure interrupts */
int mm_csi0_config_int(struct int_desc *desc, enum buffer_type type);
It would seem to me that we get an interrupt triggered on the change of any of those values coming in. Specifically, what if we had another buffer pool that was synchronized to the buffer pool we are writing frames into. Then, we could

a) during the "fsi" interrupt callback, we set the current buffer to a specific value, let's say '0' to indicate even frame.
b) we setup a callback for "lci" that is programmed to line 3, in that callback, we set the value to '1'
c) during "fei" we know the frame by looking at that value.

I imagine the other option is just to make the buffer one line larger and just only let the video stream use the part it will use, and then we use that extra line for this sort of data.

Clearly I am working way outside my knowledge base here, so I am not sure how to push that information down the pipeline as it is needed. I'm still looking to see if we can recall the last line number during fei, as I am sure there HAS to be a register with that information. Maybe it just isn't published. (and not seeing anything in vc4-regs-unicam.h that is jumping out at me). Do you have any resources to ask if such a register just exists?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 02, 2018 7:06 am

OK, it sounds like you've found the relevant data for the ADV728x-M, and it's nearly the same as the ADV748x in that it manipulates the frame and line start values. These are the only devices I've come across that does so.

Those functions are from the Broadcom soc_camera driver, not mine. soc_camera is deprecated which is why we haven't used it.
The registers are only enabling an interrupt on frame start (fsi), frame end (fei) , line count every N lines (lci is the N), on embedded data (die) (ie not matching the programmed data type) every dataline lines. They'll enable the interrupt and give you a status back saying that that interrupt occurred. They don't give you the word count field from the packet.

The option that may work is through the UNICAM_CMP1 register. This was intended for debugging in that it can generate an interrupt when it receives a particular short packet code, and it does then store the word count value.
CMP0 is already used as there were some circumstances where the peripheral missed frame ends, so it is set up as a second trigger for frame ends.

It'll be a pretty hacky thing as this is not a standard behaviour on the CSI bus, but there is no API available to query the ADV driver over what special criteria should be detected/reported or how that should be interpreted.

As I said earlier, I'm on holiday this week, but will have a play when I get back in the office next week.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Thu Aug 02, 2018 8:15 am

Hah! I knew you were on vacation, I was just digging deeper while you were out, and putting interesting information I found here. While you've just answered questions about what I had found, just for completeness sake, I found where you helped someone write out the registers by mapping /dev/mem, so I was curious what the interrupt enables were set to, and this is what I got:

Code: Select all

ICTL  0x00800003
ISTA  0x00000000
FSIE           1
FEIE           1
IBOB           0
 FCM           0
 TFC           0
 LIP           0
LCIE         128
(I just decoded the first ICTL line to what you see below ISTA, in decimal) So from what you are saying is the LCI is just a line received count interrupt, not specifically to the line count packet. Okay, thanks for that clarification.

I'll continue to poke around, but I'll clearly await your return from vacation on actually implementing the possible use of CMP1. Even if I could detect interlaced, I am not sure how to pass that data up the chain anyways :)

And I see where you are setting up UNICAM_CMP0 as you were talking about to avoid missing frame ends in the driver code:

Code: Select all

	/* Packet compare setup - required to avoid missing frame ends */
	val = 0;
	set_field(&val, 1, UNICAM_PCE);
	set_field(&val, 1, UNICAM_GI);
	set_field(&val, 1, UNICAM_CPH);
	set_field(&val, 0, UNICAM_PCVC_MASK);
	set_field(&val, 1, UNICAM_PCDT_MASK);
	reg_write(cfg, UNICAM_CMP0, val);
And just to keep this info in one place, the details on the bit fields within the register:

Code: Select all

/* UNICAM_CMP[0,1] register */
#define UNICAM_PCE		BIT(31)
#define UNICAM_GI		BIT(9)
#define UNICAM_CPH		BIT(8)
#define UNICAM_PCVC_MASK	GENMASK(7, 6)
#define UNICAM_PCDT_MASK	GENMASK(5, 0)

And in case you didn't feel like looking up the packet Data IDs

Code: Select all

Frame Start: 0
  Frame End: 1
 Line Start: 2
   Line End: 3

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 06, 2018 12:25 pm

It looks like we're in luck.

Reading the SoC datasheet, if CPH (Capture Packet Header) is set in UNICAM_CMPx, then it stores the header in UNICAM_CAPx. We're already triggering the packet capture interrupt, so it's valid to check it in the isr (the value is latched until you write 0x80000000 to CAPx).
In CAPx:
- bits 0-5 are the data type
- bits 6-7 are the virtual channel
- bits 8-23 are the word count/short packet data field
- bits 24-29 are the ECC (not sure how this works as it is 8 bits on the line)
- bit 31 indicates it is valid
We're already using CMP0 as a backup trigger for Frame End, so we can check (and reset) CAP0 in the existing ISR.

I'm putting together a basic patch and will post a link when done. Whether I'll get all the combinations correct on the first pass I have no idea, but the "field" member of v4l2_buffer that is dequeued should have the correct V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM designation if the device has been set to V4L2_FIELD_ALTERNATE, as documented in https://linuxtv.org/downloads/v4l-dvb-a ... order.html

The same should work on ADV748x, but it may require a little tweaking. (I have no hardware for that, so can't try it out).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 06, 2018 2:17 pm

https://github.com/6by9/linux/tree/rpi- ... interlaced includes both the module parameter to allow interlaced modes, and the driver change to try and give the correct signalling. I get the signalling through, but Murphy's law says it'll be inverted and I don't think I've got any test kit to confirm easily (it's also making an assumption about how ADV are using the line numbering).

Code: Select all

./yavta --capture=1000 -f UYVY -m -T /dev/video0 --field alternate
is the line I've been running. To get progressive then set "--field none".
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Mon Aug 06, 2018 9:12 pm

Excellent! Is there a way to easily update my kernel code to this version, or do I just pull it all and remake like I did last time? I’m not as versed with ongoing kernel updating during development!

Once I get going I have tools that can tell of field is backwards.

I've downloaded the 2 files you changed, and am recompiling with those in place, stay tuned... (An I laughed that you put your Murphys law comment in the code) haha.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 8:02 am

grimepoch wrote:
Mon Aug 06, 2018 9:12 pm
Excellent! Is there a way to easily update my kernel code to this version, or do I just pull it all and remake like I did last time? I’m not as versed with ongoing kernel updating during development!

Once I get going I have tools that can tell of field is backwards.

I've downloaded the 2 files you changed, and am recompiling with those in place, stay tuned... (An I laughed that you put your Murphys law comment in the code) haha.
It sounds like you've got the right steps for recompiling, although there were 2 commits pushed (3 files) - one for adv7180 to say it produced V4L2_FIELD_ALTERNATE which has recently been added to the mainline kernel, and then my commit to do something useful with that mode. I'm not sure which instructions you've followed for checking out the code, but with a bit of git magic you can add additional remote repositories and switch between branches or pull code in from them.

Code: Select all

git remote add 6by9 https://github.com/6by9/linux.git
git fetch 6by9
git checkout -t -b rpi-4.14.y-unicam-interlaced 6by9/rpi-4.14.y-unicam-interlaced
and then build.

The commits are currently only in one of my personal branches, hence the comments on Murphy's law. If you can confirm that we have the fields correctly signalled then I'll delete it before requesting that it gets merged to the main Pi kernel.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 8:09 am

I did find that 3rd file as well, as I followed your commit history backwards. That said, I need to start using git as you've described, will make my life a lot easier.

After compiling and installing, when I run yavta with the same line as you (minus the -T) I get a segfault. Using gdb, it seems to be failing here:

Code: Select all

0x0001359c in video_do_capture (fill=BUFFER_FILL_NONE, do_queue_late=0, do_requeue_last=1000,
    pattern=0x0, delay=0, skip=0, nframes=2130701736, dev=0x7effef80) at yavta.c:2467
2467							if (((struct buffer*)mmal->user_data)->idx != buf.index) {
And the output of Yavta:

Code: Select all

./yavta --capture=1000 -f UYVY -m  /dev/video0 --field alternate
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (driver 'unicam') is a video capture (without mplanes) device.
stride is 0
stride is now 1280
Video format set: UYVY (59565955) 720x480 (stride 1440) field none buffer size 691200
Video format: UYVY (59565955) 720x480 (stride 1440) field none buffer size 691200
Current frame rate: 1001/30000
vc.ril.isp:in:0(UYVY)(0xe12ba0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 736, height: 480, (0,0,720,480) pixel aspect ratio: 0/0, frame rate: 0/0 buffers num: 8(opt 1, min 1), size: 706560(opt 706560, min: 706560), align: 0stride is 1472
stride is now 1472
Video format set: UYVY (59565955) 720x480 (stride 1472) field none buffer size 706560
Video format: UYVY (59565955) 720x480 (stride 1472) field none buffer size 706560
Created pool of length 8, size 0
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 529920 for encode/render
4 buffers requested.
length: 706560 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x737c9000.
Importing DMABUF 6 into VCSM...
...done. vcsm_handle 262144
Exported buffer 0 to dmabuf 6, vcsm handle 262144
Linking V4L2 buffer index 0 ptr 0xe19a68 to MMAL header 0xe16c78. mmal->data 0xC00000FF
length: 706560 offset: 708608 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x7371c000.
Importing DMABUF 7 into VCSM...
...done. vcsm_handle 266240
Exported buffer 1 to dmabuf 7, vcsm handle 266240
Linking V4L2 buffer index 1 ptr 0xe19ad8 to MMAL header 0xe16e50. mmal->data 0xC0000100
length: 706560 offset: 1417216 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7366f000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 270336
Exported buffer 2 to dmabuf 8, vcsm handle 270336
Linking V4L2 buffer index 2 ptr 0xe19b48 to MMAL header 0xe17028. mmal->data 0xC0000101
length: 706560 offset: 2125824 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x735c2000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 274432
Exported buffer 3 to dmabuf 9, vcsm handle 274432
Linking V4L2 buffer index 3 ptr 0xe19bb8 to MMAL header 0xe17200. mmal->data 0xC000010F
Segmentation fault
Not sure what could cause this. I tried both PAL and NTSC.

I'm just going to pull your whole version, compile it, and test, JUST to make sure my kernel doesn't have any other differences. This way WE KNOW my baseline is the same.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 9:11 am

git can live up to its name, and it doesn't help that there are almost always at least 3 ways to do almost everything. I have https://xkcd.com/1597/ printed out for whenever anyone asks me git questions!

No real idea why you're getting a seg fault - I haven't been, although I do have a couple of local mods (just committing them). Nothing in that area though.
You're right that -T isn't needed in your case.
Your log implies it is still setting field to none instead of alternate. That'll either be that you don't have the required adv7180 patch built, or that the unicam driver module parameter isn't set. It should still work, but just output progressive data using the I2P.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 9:38 am

Understood. I saw it compiling the proper files, but who knows. I'd feel better starting from your EXACT release to reduce the amount of possible inconsistencies. If it still fails at that point, I will dig deeper with what you've pointed out. I'm sure it will be some time later today this will be done downloading AND compiling! Haha.

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 12:34 pm

Hmmm, no difference. Looking at DMESG I see the following line:

Code: Select all

[  391.661783] cma: cma_alloc: alloc failed, req-size: 173 pages, ret: -12
[  391.661816] unicam 3f801000.csi1: dma_alloc_coherent of size 708608 failed
Update: Doing this allows it to run now:

Code: Select all

sudo chmod 777  /sys/module/bcm2835_unicam/parameters/allow_interlaced
echo 1 > /sys/module/bcm2835_unicam/parameters/allow_interlaced

grimepoch
Posts: 95
Joined: Thu May 12, 2016 1:57 am

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 12:48 pm

Strange, my observations are that if /sys/module/bcm2835_unicam/parameters/allow_interlaced is set to 0, or I run --field none, it always segfaults. If I run with allow_interlaced set to 1, and --field to interlaced, it runs, but I get 1/2 the image in the center of the screen, as shown here:
IMG_0345.JPG
IMG_0345.JPG (186.65 KiB) Viewed 716 times
And I have verified, it's an entire even or odd frame it appears. Just pushed into the center.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 2:11 pm

Edit /boot/cmdline.txt and add

Code: Select all

cma=64M
to the line (it must remain as one line).
This driver uses the Contiguous Memory Allocator (CMA) for memory, not gpu_mem, and the default is something pretty small. Sorry if I hadn't passed that information to you before.
I haven't added full error handling to yavta, so an allocation may well trigger nasties.

Each buffer delivered when field is interlaced should be one field, with the struct v4l2_buffer "field" value being V4L2_FIELD_TOP or V4L2_FIELD_BOTTOM. Each field is 720x288 or 720x240, but the display side has no knowledge that it is interlaced, so it displays that with a pixel aspect ratio of 1:1, centred in the middle of the screen. Use "vcgencmd dispmanx_list" to show the current resources on the screen (expect to see an ARGB8888 frame - it's the Linux frame buffer)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5814
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: ADV7282 Analogue video to CSI chip with interlaced modes

Tue Aug 07, 2018 2:19 pm

Just looking at the yavta code, failing to allocate one or more of the buffers will cause issues.
The MMAL pool will have N buffers, whilst V4L2 has M which is less than N. There is an expectation of N=M, so when MMAL pulls out buffer M+1 it tries to use uninitialised elements of the structure.
I can fix it up, but the better solution is to increase the CMA region. Progressive images will be twice the size of the interlaced equivalents, therefore are more likely to get an allocation failure.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”