On 10/07/16 23:34, Steve Longerbeam wrote:
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_longerb...@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
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
