RE: ADV7180 Capture with i.MX53

Matthew Starr
2019-10-18T22:33:56Z

> -----Original Message-----
> From: Steve Longerbeam <slongerbeam@gmail.com>
>
> On 10/9/19 8:40 AM, Tim Harvey wrote:
> > On Tue, Oct 8, 2019 at 4:48 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> >> Hi Tim,
> >>
> >> On Tue, Oct 8, 2019 at 6:01 PM Tim Harvey <tharvey@gateworks.com>
> wrote:
> >>
> >>> Ok that's strange indeed. I did recently test 5.3 on a Gateworks
> >>> IMX6 board with ADV7180 and the one patch to drop the first few
> >>> frames and its stable. What does your testing show on an IMX6 and do
> >>> you know
> >> I will give it a try on a imx6q-sabreauto board for comparison.
> >>
> >>> when it may have broken for IMX53?
> >> i.MX53 capture is relatively new and this is my first time trying to
> >> get it to work with mainline.
> >>
> >> I assume I should do something similar to your
> >> https://raw.githubusercontent.com/Gateworks/media-ctl-
> setup/master/me
> >> dia-ctl-setup script, more especifically the mode 3 setup where you
> >> have:
> >>
> > I struggled with coming up with a way to easily document all the
> > variations with our boards as we have several different boards that
> > have an adv7180 using different CSI ports and then you also have to
> > deal with the differences between IMX6SDL and IMX6Q. The script was
> > the best solution I could come up with but if you read through it its
> > pretty complicated.
> >
> >> case "$SENS" in
> >> adv7180)
> >> fmt "'$SENSOR':0 [fmt:UYVY2X8/$res field:alternate]"
> >> fmt "'ipu${IPU}_csi${CSI}_mux':$((p+1)) [fmt:UYVY2X8/$res]"
> >> # rec709 config at CSI pad 0
> >> fmt "'ipu${IPU}_csi${CSI}':0 [fmt:$fmt field:$field colorspace:rec709
> >> ycbcr:709]"
> >> # CSI src pad output is frame height
> >> h=$((h*2))
> >> res=${w}x${h}
> >> fmt "'ipu${IPU}_csi${CSI}':1 [fmt:AYUV32/$res]"
> >> fmt "'ipu${IPU}_vdic':2 [fmt:AYUV32/$res field:none]"
> >> fmt "'ipu${IPU}_ic_prp':2 [fmt:AYUV32/$res field:none]"
> >> fmt "'$EP':1 [fmt:AYUV32/$res]"
> >> ;;
> >>
> >> Why do you multiple h by 2?
> > The input the the CSI is a field of 240 lines but the vdic will
> > combine these and have 480 lines. I don't recall exactly why but for
> > this to propagate properly you need to set the 480 lines on the csi
> > output.
>
> The reason is because there are is no register status bits that will tell you
> whether a captured field was field 0 or field 1. For this reason the driver can't
> support alternate capture mode (which captures individual fields and reports
> to userspace in the returned v4l2_buffer's whether the field is a top field or
> bottom field). So the CSI captures two consecutive fields and reports field
> type seq-bt or seq-tb, and doubles height, at its output.
>
>
> >>> I do have a discussion going on here about NEWAVMODE and BT.656-3
> vs
> >>> BT.656-4. I wonder if its something to do with that as that issue
> >>> causes rolling video on IMX6 with ADV7280:
> >>> https://patchwork.kernel.org/patch/11117579/
> >> Tested this patch, but it did not help.
>
> About a year ago Matthew Starr reported similar horizontal rolling issue with
> i.mx53 + adv7180. I didn't have an explanation for the problem, since IPU
> register-level is the same between i.mx53 and i.mx6, and
> adv7180 capture is working fine on i.mx6 SabreAuto. And like now, the
> skipping of initial corrupt frames solved vertical sync but not the horizontal
> rolling. I never heard back whether he was able to track down the issue.
>
> Matthew, were you ever able to solve this?

Steve,

I never had a chance to dig deeper on this issue. The last time it was worked on the video could never get a proper sync between frames, so the images were always split between frames.

If there are some new updates over the last year I would be willing to test them out.

- Matt Starr

>
> > That patch won't affect adv7180 but I wonder if the issues you are
> > having have to do with something like this. The adv7180_init function
> > will set BT.656-4 mode and adjust V bit end position for NTSC... I
> > don't know if that's consistent with the IMX53 CSI needs?
>
> Well, like mentioned above, the IPU CSI is register-level compatible between
> i.mx53 and i.mx6, at least according to the reference manuals, so the non-
> standard V-bit position set by adv7180, and adjusted for by the CSI, should
> work for i.mx53 just like it does for i.mx6. But it's possible there are some
> undocumented differences in the CSI between these SoC's.
>
> Steve
>
> > There are
> > lots of little tweaks that can be made to the EAV/SAV codes and its
> > not clear to me how to deal with compat issues like i have run into
> > with the adv7280 config not being compatible with the IMX6 CSI needs.