On 25/07/16 23:04, Steve Longerbeam wrote:
On 07/25/2016 12:36 PM, Ian Arkver wrote:
On 25/07/16 18:55, Steve Longerbeam wrote:
On 07/25/2016 05:04 AM, Ian Arkver wrote:
On 23/07/16 18:00, Steve Longerbeam wrote:
<snip>
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
See below re this value.
Hi Ian, I double-checked the ADV7180 datasheet, this value is
correct. Bit 4, when cleared, _enables_ NEWAVMODE.
Hah, ok. I'm not familiar enough with the history of this chip and
didn't
know what "OLDAVMODE" was. So, to enable NEWAVMODE you clear
the NEWAVMODE bit. That makes perfect sense.
Anyway, I still don't see what NEWAVMODE gets you.
Hi Ian,
With video standard auto-detect disabled in the chip (VID_SEL > 2),
captured NTSC
images by the i.mx6q SabreAuto are corrupted, best I can describe it
as "extremely
fuzzy". Only when newavmode is enabled do the images look good again,
in manual
mode. With auto-detect enabled, images look good with or without
newavmode.
The strange this is, the auto-detected standard is identical to the
standard set
explicitly in manual mode (NTSC-M). I did a complete i2c dump of the
registers
for both auto-detect and manual mode, and found no other differences
besides
the auto-detect/manual setting.
Trying to track this down further would probably require a logic
analyzer on the
bt.656 bus, which I don't have access to.
I will not be debugging this further so NEWAVMODE it will have to remain.
Steve
OK, interesting. And weird indeed.
I may be interfacing an ADV7280 to the i.MX6 in the August timeframe,
depending on
project needs etc. I'll see if I hit this with that chip. My test app
does use autodetect.
Incidentally, looking at the BT656-5 spec and comparing to the tvp5150,
I see that
the spec calls for 244 and 243 lines per field for NTSC, and the tvp5150
provides
that number of lines. However this write...
adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
where NVEND is 0x4f, configures the adv7180 to send only 242 lines in
each field.
Not sure if this is significant.
Regards,
IanJ.
As
far as I can see it just locks down the timings and removes the
flexibility
the chip otherwise offers to move the BT656 SAV and EAV codes around
relative to the incoming video.
In what circumstances would you need to set the newavmode property
and change this default behaviour? We're not coupling the adv7180
back-to-back with an ADV video encoder here, which is what
NEWAVMODE is for and is presumably why AD recommend it for their
eval boards. We're trying to get a BT656 compliant stream, which is
what the default mode purports to generate.
Regards,
IanJ
--
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
