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
