From: Steve Longerbeam <slongerbeam@gmail.com>
To: Ian Arkver <ian.arkver.dev@gmail.com>,
Steve Longerbeam <steve_longerbeam@mentor.com>,
lars@metafoo.de
Cc: mchehab@kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE
Date: Mon, 25 Jul 2016 18:57:53 -0700 [thread overview]
Message-ID: <18f9e081-018d-26c2-e35e-262627826ed3@gmail.com> (raw)
In-Reply-To: <153fdfbc-a929-6584-3f06-26413498c1fa@gmail.com>
On 07/25/2016 03:24 PM, Ian Arkver wrote:
> 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.
Right. I thought for sure that was the reason for the image problems, but
I tried commenting out that write (default value for ADV7180_REG_NTSC_V_BIT_END)
with NEWAVMODE disabled, and still the images were corrupted in manual mode.
Steve
next prev parent reply other threads:[~2016-07-26 1:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-23 17:00 [PATCH v3 0/9] adv7180 subdev fixes, v3 Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 1/9] media: adv7180: Fix broken interrupt register access Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 2/9] media: adv7180: define more registers Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 3/9] media: adv7180: add support for NEWAVMODE Steve Longerbeam
2016-07-25 12:13 ` Ian Arkver
[not found] ` <b2f5e6ab-86f0-7caf-40bd-8b3259dce5cd@gmail.com>
2016-07-25 17:55 ` Steve Longerbeam
2016-07-25 19:36 ` Ian Arkver
2016-07-25 22:04 ` Steve Longerbeam
2016-07-25 22:24 ` Ian Arkver
2016-07-26 1:57 ` Steve Longerbeam [this message]
2016-07-23 17:00 ` [PATCH v3 4/9] media: adv7180: add power pin control Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 5/9] media: adv7180: implement g_parm Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 6/9] media: adv7180: change mbus format to UYVY Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 7/9] v4l: Add signal lock status to source change events Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 8/9] media: adv7180: enable lock/unlock interrupts Steve Longerbeam
2016-07-23 17:00 ` [PATCH v3 9/9] media: adv7180: fix field type Steve Longerbeam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18f9e081-018d-26c2-e35e-262627826ed3@gmail.com \
--to=slongerbeam@gmail.com \
--cc=ian.arkver.dev@gmail.com \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=steve_longerbeam@mentor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox