On 10/9/19 8:40 AM, Tim Harvey wrote:
On Tue, Oct 8, 2019 at 4:48 PM Fabio Estevam <feste...@gmail.com> wrote:
Hi Tim,
On Tue, Oct 8, 2019 at 6:01 PM Tim Harvey <thar...@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/media-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?
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.
