From: Steve Longerbeam <slongerbeam@gmail.com>
To: Tim Harvey <tharvey@gateworks.com>, Fabio Estevam <festevam@gmail.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
linux-media <linux-media@vger.kernel.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
Matthew Starr <mstarr@hedonline.com>
Subject: Re: ADV7180 Capture with i.MX53
Date: Wed, 9 Oct 2019 10:22:20 -0700 [thread overview]
Message-ID: <e2c7a89c-5475-6685-2f9b-3f54e822a526@gmail.com> (raw)
In-Reply-To: <CAJ+vNU3FUvB_a1TxxjvtKbC9xg6-VbD+3PE6-5uEwgOwXn6WvQ@mail.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/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.
next prev parent reply other threads:[~2019-10-09 17:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 0:15 ADV7180 Capture with i.MX53 Fabio Estevam
2019-10-08 0:37 ` Steve Longerbeam
2019-10-08 0:46 ` Fabio Estevam
2019-10-08 0:51 ` Steve Longerbeam
2019-10-08 1:07 ` Fabio Estevam
2019-10-08 1:40 ` Fabio Estevam
2019-10-08 11:21 ` Fabio Estevam
2019-10-08 16:55 ` Tim Harvey
2019-10-08 17:14 ` Steve Longerbeam
2019-10-08 17:20 ` Ian Arkver
2019-10-08 17:30 ` Steve Longerbeam
2019-10-08 17:33 ` Ian Arkver
2019-10-08 20:34 ` Fabio Estevam
2019-10-08 21:01 ` Tim Harvey
2019-10-08 23:48 ` Fabio Estevam
2019-10-09 15:40 ` Tim Harvey
2019-10-09 17:22 ` Steve Longerbeam [this message]
2019-10-18 22:33 ` Matthew Starr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2c7a89c-5475-6685-2f9b-3f54e822a526@gmail.com \
--to=slongerbeam@gmail.com \
--cc=festevam@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=mstarr@hedonline.com \
--cc=nicolas@ndufresne.ca \
--cc=p.zabel@pengutronix.de \
--cc=tharvey@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox