> -----Original Message----- > From: Steve Longerbeam <slongerbeam@xxxxxxxxx> > > On 10/9/19 8:40 AM, Tim Harvey wrote: > > On Tue, Oct 8, 2019 at 4:48 PM Fabio Estevam <festevam@xxxxxxxxx> > wrote: > >> Hi Tim, > >> > >> On Tue, Oct 8, 2019 at 6:01 PM Tim Harvey <tharvey@xxxxxxxxxxxxx> > 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.
