Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190827215539.1286-1-mmichilot@gateworks.com>
 <cb3e9be4-9ce6-354f-bb7c-a4710edc1c1b@xs4all.nl> <20190829142931.GZ28351@bigcity.dyn.berto.se>
 <CAJ+vNU11HTcP8L5J2Xg+Rmhvb8JDYemhJxt-GaGG5Myk3n38Tw@mail.gmail.com> <20190927190454.GA7409@bigcity.dyn.berto.se>
In-Reply-To: <20190927190454.GA7409@bigcity.dyn.berto.se>
From:   Tim Harvey <tharvey@gateworks.com>
Date:   Fri, 27 Sep 2019 12:26:40 -0700
Message-ID: <CAJ+vNU2shAbnLO9TY4dtPupLxE4UFvNi9FXoFF4MfPbtbAZo=g@mail.gmail.com>
Subject: Re: [PATCH] media: i2c: adv7180: fix adv7280 BT.656-4 compatibility
To:     =?UTF-8?Q?Niklas_S=C3=B6derlund?= <niklas.soderlund@ragnatech.se>
Cc:     Hans Verkuil <hverkuil@xs4all.nl>,
        Matthew Michilot <matthew.michilot@gmail.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        linux-media <linux-media@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 27, 2019 at 12:04 PM Niklas S=C3=B6derlund
<niklas.soderlund@ragnatech.se> wrote:
>
> Hi Tim,
>
> Sorry for taking to so long to look at this.
>
> On 2019-09-23 15:04:47 -0700, Tim Harvey wrote:
> > On Thu, Aug 29, 2019 at 7:29 AM Niklas S=C3=B6derlund
> > <niklas.soderlund@ragnatech.se> wrote:
> > >
> > > Hi,
> > >
> > > On 2019-08-29 13:43:49 +0200, Hans Verkuil wrote:
> > > > Adding Niklas.
> > > >
> > > > Niklas, can you take a look at this?
> > >
> > > I'm happy to have a look at this. I'm currently moving so all my boar=
ds
> > > are in a box somewhere. I hope to have my lab up and running next wee=
k,
> > > so if this is not urgent I will look at it then.
> > >
> >
> > Niklas,
> >
> > Have you looked at this yet? Without this patch the ADV7280A does not
> > output proper BT.656. We tested this on a Gateworks Ventana GW5404-G
> > which uses the ADV7280A connected to the IMX6 CSI parallel bus. I'm
> > hoping to see this get merged and perhaps backported to older kernels.
>
> I only have access to an adv7180 so I was unable to test this patch.
> After reviewing the documentation I think the patch is OK if what you
> want is to unconditionally switch the driver from outputting BT.656-3 to
> outputting BT.656-4.
>
> As this change would effect a large number of compat strings (adv7280,
> adv7280-m, adv7281, adv7281-m, adv7281-ma, adv7282, adv7282-m) and the
> goal is to back port it I'm a bit reluctant to adding my tag to this
> patch as I'm not sure if this will break other setups.
>
> From the documentation about the BT.656-4 register (address 0x04 bit 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.
>
> Do you know what effects such a change would bring? Looking at the
> driver BT.656-4 seems to be set unconditionally for some adv7180 chips.
>

Niklas,

Quite simply, we have a board that has an ADV7180 attached to the
parallel CSI of an IMX6 that worked fine with mainline drivers then
when we revised this board to attach an ADV7280A in the same way
capture failed to sync. Investigation showed that the NEWAVMODE
differed between the two.

So if the point of the driver is to configure the variants in the same
way, this patch needs to be applied.

I would maintain that the adv7180 comes up with NEWAVMODE enabled and
in order to be compatible we must configure the adv7282 the same.

The same argument can be made for setting the V bit end position in
NTSC mode - its done for the adv7180 so for compatible output it
should be done for the adv7282.

> >
> > Regards,
> >
> > Tim
> >
> > > >
> > > > Regards,
> > > >
> > > >       Hans
> > > >
> > > > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > > > From: Matthew Michilot <matthew.michilot@gmail.com>
> > > > >
> > > > > Captured video would be out of sync when using the adv7280 with
> > > > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had t=
o
> > > > > be configured properly to ensure BT.656-4 compatibility.
> > > > >
> > > > > An error in the adv7280 reference manual suggested that EAV/SAV m=
ode
> > > > > was enabled by default, however upon inspecting register 0x31, it=
 was
> > > > > determined to be disabled by default.
>
> The manual I have [1] states that NEWAVMODE is switched off by default.
> I'm only asking as I would like to know if there is an error in that
> datasheet or not.
>
> 1. https://www.analog.com/media/en/technical-documentation/user-guides/AD=
V7280_7281_7282_7283_UG-637.pdf
>

Table 99 in that document shows NEVAVMODE disabled on power-up
(0x31=3D0x02) yet Page 77 shows it enabled at power-up. Looking at an
actual device we find it is indeed disabled on powerup (0x31=3D0x02) so
Table 99 is correct, and Page 77 is not.

If you look at the ADV7180 datasheet
(https://www.analog.com/media/en/technical-documentation/data-sheets/ADV718=
0.pdf)
Table 105 shows NEWAVMODE enabled by default which is also reflected
in the register details on Page 91 and is what you find on an actual
device.

Regards,

Tim

--=20


CONFIDENTIALITY NOTICE: This email constitutes an electronic=20
communication within the meaning of the Electronic Communications Privacy=
=20
Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named=20
recipient(s) intended by the sender of this message. This email, and any=20
attachments, may contain confidential and/or proprietary information. If=20
you are not a named recipient, any copying, using, disclosing or=20
distributing to others the information in this email and attachments is=20
STRICTLY PROHIBITED. If you have received this email in error, please=20
notify the sender immediately and permanently delete the email, any=20
attachments, and all copies thereof from any drives or storage media and=20
destroy any printouts or hard copies of the email and attachments.

=C2=A0


EXPORT COMPLIANCE NOTICE: This email and any attachments may contain=20
technical data subject to U.S export restrictions under the International=
=20
Traffic in Arms Regulations (ITAR) or the Export Administration Regulations=
=20
(EAR). Export or transfer of this technical data and/or related information=
=20
to any foreign person(s) or entity(ies), either within the U.S. or outside=
=20
of the U.S., may require advance export authorization by the appropriate=20
U.S. Government agency prior to export or transfer. In addition, technical=
=20
data may not be exported or transferred to certain countries or specified=
=20
designated nationals identified by U.S. embargo controls without prior=20
export authorization. By accepting this email and any attachments, all=20
recipients confirm that they understand and will comply with all applicable=
=20
ITAR, EAR and embargo compliance requirements.