Re: [PATCH 06/11] media: adv7180: add bt.656-4 OF property

[Steve Longerbeam <steve_longerbeam@mentor.com>]

On 07/10/2016 07:30 AM, Hans Verkuil wrote:
> On 07/10/2016 04:17 PM, Ian Arkver wrote:
>> On 10/07/16 13:55, Hans Verkuil wrote:
>>> On 07/10/2016 02:10 PM, Lars-Peter Clausen wrote:
>>>> On 07/09/2016 11:36 PM, Steve Longerbeam wrote:
>>>>> On 07/09/2016 02:10 PM, Steve Longerbeam wrote:
>>>>>> On 07/09/2016 11:59 AM, Steve Longerbeam wrote:
>>>>>>> On 07/07/2016 07:52 AM, Lars-Peter Clausen wrote:
>>>>>>>> On 07/07/2016 12:59 AM, Steve Longerbeam wrote:
>>>>>>>>> Add a device tree boolean property "bt656-4" to allow setting
>>>>>>>>> the ITU-R BT.656-4 compatible bit.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>>>>>>>> +    /* 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