On 10/07/16 23:34, Steve Longerbeam wrote:

On 07/10/2016 07:30 AM, Hans Verkuil wrote:

quoted

On 07/10/2016 04:17 PM, Ian Arkver wrote:

quoted

On 10/07/16 13:55, Hans Verkuil wrote:

quoted

On 07/10/2016 02:10 PM, Lars-Peter Clausen wrote:

quoted

On 07/09/2016 11:36 PM, Steve Longerbeam wrote:

quoted

On 07/09/2016 02:10 PM, Steve Longerbeam wrote:

quoted

On 07/09/2016 11:59 AM, Steve Longerbeam wrote:

quoted

On 07/07/2016 07:52 AM, Lars-Peter Clausen wrote:

quoted

On 07/07/2016 12:59 AM, Steve Longerbeam wrote:

quoted

Add a device tree boolean property "bt656-4" to allow setting
the ITU-R BT.656-4 compatible bit.

Signed-off-by: Steve Longerbeam <redacted>

+    /* select ITU-R BT.656-4 compatible? */

Please don't use the '-4': BT.656 is sufficient. The -4 is just the 
version
number of the standard (and 5 is the latest anyway).

  From the ADV7180 DS [1]:

BT.656-4, ITU-R BT.656-4 Enable, Address 0x04[7]

Between Revision 3 and Revision 4 of the ITU-R BT.656 standards, the 
ITU
has changed the toggling position for the V bit within the SAV EAV 
codes
for NTSC. The ITU-R BT.656-4 standard bit allows the user to select an
output mode that is compliant with either the previous or new standard.
For further information, visit the International Telecommunication 
Union
website.

Note that the standard change only affects NTSC and has no bearing 
on PAL.

When ITU-R BT.656-4 is 0 (default), the ITU-R BT.656-3 specification is
used. The V bit goes low at EAV of Line 10 and Line 273.

When ITU-R BT.656-4 is 1, the ITU-R BT.656-4 specification is used. The
V bit goes low at EAV of Line 20 and Line 283.

[1]www.analog.com/media/en/technical-documentation/data-sheets/*ADV7180*.pdf 

Rev 4 came in in 1998. I would say that that is the default. We have 
had any
problems with this and I would need some proof that this is really 
needed.

Hi Hans, yeah I agree with you that new capture drivers should not
expect BT.656-3 compatible buss' any longer. The problem with i.MX6
however, is that the IPU CSI CCIR_CODE registers, which inform the IPU
about the AV code positions, are very poorly documented. In order for
i.MX6 to support BT.656-4 it would require very time-consuming reverse
engineering to find the right values to plug into those registers to 
conform
to the BT.656-4 AV code positions.

Steve

Hi Steve,

Once you dsicover that the 3-bit fields in each CCIR_CODE register 
correspond to the H, V and F flags in the SAV/EAV code (in that order, 
MSbit->LSbit),  those registers make more sense. Pity that's not 
mentioned in the Ref Manual.

However, I don't think that's relevant here, since the spec revision 
didn't change the codes, but just moved the lines the V bit is sent on. 
I believe the spec change switched the NTSC timing from VSYNC to VBLANK, 
but the net effect was 10 fewer "active" video lines per field. Looking 
at a sample of one other video decoder (tvp5150), the default seems to 
be to change V on lines 20 and 283, as per the newer revision of the 
spec., though again bets may have been hedged with a programmable override.

In any case, I'm wondering if your extra ten lines per field are more 
related to this snippet from calc_default_crop in imx-camif.c, which 
seems like it would break other decoder front ends and adv7180 in 
bt656-4 mode...

     /*
      * FIXME: For NTSC standards, top must be set to an
      * offset of 13 lines to match fixed CCIR programming
      * in the IPU.
      */
     if (std != V4L2_STD_UNKNOWN && (std & V4L2_STD_525_60))
         rect->top = 13;

I believe tvp5150 at least sends 243 active lines per field for an NTSC 
source and the top 3 lines are generally dropped.

Regards,
Ian