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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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_longerbeam@xxxxxxxxxx>
+    /* 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux