Hi Krzysztof, On Fri, 2018-06-01 at 12:02 +0200, Krzysztof Hałasa wrote: > Steve Longerbeam <slongerbeam@xxxxxxxxx> writes: > > > I tend to agree, I've found conflicting info out there regarding > > PAL vs. NTSC field order. And I've never liked having to guess > > at input analog standard based on input # lines. I will go ahead > > and remove the field order override code. > > I've merged your current fix-csi-interlaced.2 branch (2018-06-01 > 00:06:45 UTC 22ad9f30454b6e46979edf6f8122243591910a3e) along with > "media: adv7180: fix field type" commit and NTSC camera: > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:alternate]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]" > media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x480 field:interlaced/-bt/-tb]" > > correctly sets: > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x480 field:alternate] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x480 field:alternate] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x480 field:alternate] > "ipu2_csi1":0 [fmt:UYVY2X8/720x480 field:alternate] > "ipu2_csi1":2 [fmt:AYUV32/720x480 field:interlaced/-bt/-tb] > > but all 3 cases seem to produce top-first interlaced frames. > The CCIR_CODE_* register dump shows no differences: > 2a38014: 010D07DF 00040596 00FF0000 > > ...it's because the code in drivers/gpu/ipu-v3/ipu-csi.c still sets the > registers depending on the height of the image. Exactly. > Hovewer, I'm using 480 > lines here, so it should be B-T instead. My understanding is that the CCIR codes for height == 480 (NTSC) currently capture the second field (top) first, assuming that for NTSC the EAV/SAV codes are bottom-field-first. So the CSI captures SEQ_TB for both PAL and NTSC: The three-bit values in CCIR_CODE_2/3 are in H,V,F order, and the NTSC case has F=1 for the field that is captured first, where F=1 is the field that is marked as second field on the wire, so top. Which means that the captured frame has two fields captured across frame boundaries, which might be problematic if the source data was originally progressive. > My guess is the CSI is skipping > the first incomplete line (half-line - the first visible line has full > length) and BT becomes TB. That wouldn't make BT TB though, if we'd still capture the bottom field (minus its first half line) first? > It seems writing to the CCIR_CODE_[12] registers does the trick, though > (the captured frames aren't correct and have the lines swapped in pairs > because t/b field pointers aren't correctly set). What are you writing exactly? 0x01040596 to CCIR_CODE_1 and 0x000d07df to CCIR_CODE_2? That is what I would expect to capture SEQ_BT for NTSC data, and the IPU could interweave this into INTERLACED_BT, correctly if we fix ipu_cpmem_interlaced_scan to allow negative offsets. regards Philipp
