Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture

[Philipp Zabel <p.zabel@pengutronix.de>]

On Sat, 2018-06-02 at 11:44 -0700, Steve Longerbeam wrote:
> 
> On 06/01/2018 06:44 AM, Philipp Zabel wrote:
> > On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote:
> > <snip>
> > > +
> > > +.. code-block:: none
> > > +
> > > +   # Setup links
> > > +   media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]"
> > > +   media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
> > > +   media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> > > +   # Configure pads
> > > +   media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]"
> > > +   media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]"
> > > +   media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]"
> > 
> > Could the example suggest using interlaced-bt to be explicit here?
> > Actually, I don't think we should allow interlaced on the CSI src pads
> > at all in this case. Technically it always writes either seq-tb or seq-
> > bt into the smfc, never interlaced (unless the input is already
> > interlaced).
> > 
> 
> Hmm, if the sink is 'alternate', and the requested source is
> 'interlaced*', perhaps we should allow the source to be
> 'interlaced*' and not override it. For example, if requested
> is 'interlaced-tb', let it be that. IOW assume user knows something
> we don't about the original field order, or is experimenting
> with finding the correct field order.

If the source material is really interlaced and not alternate, shouldn't
the sink pad be set to interlaced?

regards
Philipp