lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 25 Jul 2016 15:04:02 -0700
From:	Steve Longerbeam <steve_longerbeam@...tor.com>
To:	Ian Arkver <ian.arkver.dev@...il.com>,
	Steve Longerbeam <slongerbeam@...il.com>, <lars@...afoo.de>
CC:	<mchehab@...nel.org>, <linux-media@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE



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



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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ