Re: [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE

From: Ian Arkver
Date: Mon Jul 25 2016 - 18:25:03 EST

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:
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.


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,

where NVEND is 0x4f, configures the adv7180 to send only 242 lines in each field.
Not sure if this is significant.


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.