From: Matthew Michilot <[email protected]>
Captured video would be out of sync when using the adv7280 with
the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
be configured properly to ensure BT.656-4 compatibility.
An error in the adv7280 reference manual suggested that EAV/SAV mode
was enabled by default, however upon inspecting register 0x31, it was
determined to be disabled by default.
Signed-off-by: Matthew Michilot <[email protected]>
Reviewed-by: Tim Harvey <[email protected]>
---
drivers/media/i2c/adv7180.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 99697baad2ea..27da424dce76 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -94,6 +94,7 @@
#define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
#define ADV7180_REG_CTRL_2 0x001d
#define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
#define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
#define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
#define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
@@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
} else {
- if (state->chip_info->flags & ADV7180_FLAG_V2)
+ if (state->chip_info->flags & ADV7180_FLAG_V2) {
+ /* ITU-R BT.656-4 compatible */
adv7180_write(state,
ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
- 0x17);
+ ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
+ /* Manually set NEWAVMODE */
+ adv7180_write(state,
+ ADV7180_REG_VSYNC_FIELD_CTL_1,
+ ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
+ /* Manually set V bit end position in NTSC mode */
+ adv7180_write(state,
+ ADV7180_REG_NTSC_V_BIT_END,
+ ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+ }
else
adv7180_write(state,
ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
--
2.17.1
Adding Niklas.
Niklas, can you take a look at this?
Regards,
Hans
On 8/27/19 11:55 PM, Matthew Michilot wrote:
> From: Matthew Michilot <[email protected]>
>
> Captured video would be out of sync when using the adv7280 with
> the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> be configured properly to ensure BT.656-4 compatibility.
>
> An error in the adv7280 reference manual suggested that EAV/SAV mode
> was enabled by default, however upon inspecting register 0x31, it was
> determined to be disabled by default.
>
> Signed-off-by: Matthew Michilot <[email protected]>
> Reviewed-by: Tim Harvey <[email protected]>
> ---
> drivers/media/i2c/adv7180.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 99697baad2ea..27da424dce76 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -94,6 +94,7 @@
> #define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
> #define ADV7180_REG_CTRL_2 0x001d
> #define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
> +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
> #define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
> #define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
> #define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
> @@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
> adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
> adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
> } else {
> - if (state->chip_info->flags & ADV7180_FLAG_V2)
> + if (state->chip_info->flags & ADV7180_FLAG_V2) {
> + /* ITU-R BT.656-4 compatible */
> adv7180_write(state,
> ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> - 0x17);
> + ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
> + /* Manually set NEWAVMODE */
> + adv7180_write(state,
> + ADV7180_REG_VSYNC_FIELD_CTL_1,
> + ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
> + /* Manually set V bit end position in NTSC mode */
> + adv7180_write(state,
> + ADV7180_REG_NTSC_V_BIT_END,
> + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> + }
> else
> adv7180_write(state,
> ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
>
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 boards
are in a box somewhere. I hope to have my lab up and running next week,
so if this is not urgent I will look at it then.
>
> Regards,
>
> Hans
>
> On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > From: Matthew Michilot <[email protected]>
> >
> > Captured video would be out of sync when using the adv7280 with
> > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > be configured properly to ensure BT.656-4 compatibility.
> >
> > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > was enabled by default, however upon inspecting register 0x31, it was
> > determined to be disabled by default.
> >
> > Signed-off-by: Matthew Michilot <[email protected]>
> > Reviewed-by: Tim Harvey <[email protected]>
> > ---
> > drivers/media/i2c/adv7180.c | 15 +++++++++++++--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> > index 99697baad2ea..27da424dce76 100644
> > --- a/drivers/media/i2c/adv7180.c
> > +++ b/drivers/media/i2c/adv7180.c
> > @@ -94,6 +94,7 @@
> > #define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
> > #define ADV7180_REG_CTRL_2 0x001d
> > #define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
> > +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
> > #define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
> > #define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
> > #define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
> > @@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
> > adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
> > adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
> > } else {
> > - if (state->chip_info->flags & ADV7180_FLAG_V2)
> > + if (state->chip_info->flags & ADV7180_FLAG_V2) {
> > + /* ITU-R BT.656-4 compatible */
> > adv7180_write(state,
> > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > - 0x17);
> > + ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
> > + /* Manually set NEWAVMODE */
> > + adv7180_write(state,
> > + ADV7180_REG_VSYNC_FIELD_CTL_1,
> > + ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
> > + /* Manually set V bit end position in NTSC mode */
> > + adv7180_write(state,
> > + ADV7180_REG_NTSC_V_BIT_END,
> > + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> > + }
> > else
> > adv7180_write(state,
> > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> >
>
--
Regards,
Niklas S?derlund
On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund
<[email protected]> 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 boards
> are in a box somewhere. I hope to have my lab up and running next week,
> 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.
Regards,
Tim
> >
> > Regards,
> >
> > Hans
> >
> > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > From: Matthew Michilot <[email protected]>
> > >
> > > Captured video would be out of sync when using the adv7280 with
> > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > be configured properly to ensure BT.656-4 compatibility.
> > >
> > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > was enabled by default, however upon inspecting register 0x31, it was
> > > determined to be disabled by default.
> > >
> > > Signed-off-by: Matthew Michilot <[email protected]>
> > > Reviewed-by: Tim Harvey <[email protected]>
> > > ---
> > > drivers/media/i2c/adv7180.c | 15 +++++++++++++--
> > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> > > index 99697baad2ea..27da424dce76 100644
> > > --- a/drivers/media/i2c/adv7180.c
> > > +++ b/drivers/media/i2c/adv7180.c
> > > @@ -94,6 +94,7 @@
> > > #define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
> > > #define ADV7180_REG_CTRL_2 0x001d
> > > #define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
> > > +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
> > > #define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
> > > #define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
> > > #define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
> > > @@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
> > > adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
> > > adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
> > > } else {
> > > - if (state->chip_info->flags & ADV7180_FLAG_V2)
> > > + if (state->chip_info->flags & ADV7180_FLAG_V2) {
> > > + /* ITU-R BT.656-4 compatible */
> > > adv7180_write(state,
> > > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > > - 0x17);
> > > + ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
> > > + /* Manually set NEWAVMODE */
> > > + adv7180_write(state,
> > > + ADV7180_REG_VSYNC_FIELD_CTL_1,
> > > + ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
> > > + /* Manually set V bit end position in NTSC mode */
> > > + adv7180_write(state,
> > > + ADV7180_REG_NTSC_V_BIT_END,
> > > + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> > > + }
> > > else
> > > adv7180_write(state,
> > > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > >
> >
>
> --
> Regards,
> Niklas Söderlund
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?derlund
> <[email protected]> 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 boards
> > are in a box somewhere. I hope to have my lab up and running next week,
> > 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.
>
> Regards,
>
> Tim
>
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > > From: Matthew Michilot <[email protected]>
> > > >
> > > > Captured video would be out of sync when using the adv7280 with
> > > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > > be configured properly to ensure BT.656-4 compatibility.
> > > >
> > > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > > 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/ADV7280_7281_7282_7283_UG-637.pdf
> > > >
> > > > Signed-off-by: Matthew Michilot <[email protected]>
> > > > Reviewed-by: Tim Harvey <[email protected]>
> > > > ---
> > > > drivers/media/i2c/adv7180.c | 15 +++++++++++++--
> > > > 1 file changed, 13 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> > > > index 99697baad2ea..27da424dce76 100644
> > > > --- a/drivers/media/i2c/adv7180.c
> > > > +++ b/drivers/media/i2c/adv7180.c
> > > > @@ -94,6 +94,7 @@
> > > > #define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
> > > > #define ADV7180_REG_CTRL_2 0x001d
> > > > #define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
> > > > +#define ADV7180_VSYNC_FIELD_CTL_1_NEWAV 0x12
> > > > #define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
> > > > #define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
> > > > #define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
> > > > @@ -935,10 +936,20 @@ static int adv7182_init(struct adv7180_state *state)
> > > > adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
> > > > adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
> > > > } else {
> > > > - if (state->chip_info->flags & ADV7180_FLAG_V2)
> > > > + if (state->chip_info->flags & ADV7180_FLAG_V2) {
> > > > + /* ITU-R BT.656-4 compatible */
> > > > adv7180_write(state,
> > > > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > > > - 0x17);
> > > > + ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS);
> > > > + /* Manually set NEWAVMODE */
> > > > + adv7180_write(state,
> > > > + ADV7180_REG_VSYNC_FIELD_CTL_1,
> > > > + ADV7180_VSYNC_FIELD_CTL_1_NEWAV);
> > > > + /* Manually set V bit end position in NTSC mode */
> > > > + adv7180_write(state,
> > > > + ADV7180_REG_NTSC_V_BIT_END,
> > > > + ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
> > > > + }
> > > > else
> > > > adv7180_write(state,
> > > > ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
> > > >
> > >
> >
> > --
> > Regards,
> > Niklas S?derlund
--
Regards,
Niklas S?derlund
Hi Tim,
On Wed, Sep 25, 2019 at 9:22 PM Tim Harvey <[email protected]> wrote:
> 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.
In order to be backported to older kernels, please add a Fixes tag.
Thanks
On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
<[email protected]> 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öderlund
> > <[email protected]> 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 boards
> > > are in a box somewhere. I hope to have my lab up and running next week,
> > > 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 <[email protected]>
> > > > >
> > > > > Captured video would be out of sync when using the adv7280 with
> > > > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > > > be configured properly to ensure BT.656-4 compatibility.
> > > > >
> > > > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > > > 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/ADV7280_7281_7282_7283_UG-637.pdf
>
Table 99 in that document shows NEVAVMODE disabled on power-up
(0x31=0x02) yet Page 77 shows it enabled at power-up. Looking at an
actual device we find it is indeed disabled on powerup (0x31=0x02) 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/ADV7180.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
--
CONFIDENTIALITY NOTICE: This email constitutes an electronic
communication within the meaning of the Electronic Communications Privacy
Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named
recipient(s) intended by the sender of this message. This email, and any
attachments, may contain confidential and/or proprietary information. If
you are not a named recipient, any copying, using, disclosing or
distributing to others the information in this email and attachments is
STRICTLY PROHIBITED. If you have received this email in error, please
notify the sender immediately and permanently delete the email, any
attachments, and all copies thereof from any drives or storage media and
destroy any printouts or hard copies of the email and attachments.
EXPORT COMPLIANCE NOTICE: This email and any attachments may contain
technical data subject to U.S export restrictions under the International
Traffic in Arms Regulations (ITAR) or the Export Administration Regulations
(EAR). Export or transfer of this technical data and/or related information
to any foreign person(s) or entity(ies), either within the U.S. or outside
of the U.S., may require advance export authorization by the appropriate
U.S. Government agency prior to export or transfer. In addition, technical
data may not be exported or transferred to certain countries or specified
designated nationals identified by U.S. embargo controls without prior
export authorization. By accepting this email and any attachments, all
recipients confirm that they understand and will comply with all applicable
ITAR, EAR and embargo compliance requirements.
Hi Tim,
On 2019-09-27 12:26:40 -0700, Tim Harvey wrote:
> On Fri, Sep 27, 2019 at 12:04 PM Niklas S?derlund
> <[email protected]> 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?derlund
> > > <[email protected]> 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 boards
> > > > are in a box somewhere. I hope to have my lab up and running next week,
> > > > 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.
I understand your problem, the driver configures adv7180 and adv7280
differently.
>
> So if the point of the driver is to configure the variants in the same
> way, this patch needs to be applied.
I'm not sure that is the point of the driver. As the driver today
configures different compatible strings differently. Some as ITU-R
BT.656-3 and some as ITU-R BT.656-4, I can only assume there is a reason
for that.
>
> 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.
I understand that this is needed to make it a drop-in replacement for
the adv7180 in your use-case. But I'm not sure it is a good idea for
other users of the driver. What if someone is already using a adv7282 on
a board and depends on it providing ITU-R BT.656-3 and the old settings?
If this patch is picked up there use-cases may break.
I'm not sure what the best way forward is I'm afraid. Looking at
video-interfaces.txt we have a device tree property bus-type which is
used to describe the bus is a BT.656 bus but not which revision of it.
I'm not really found of driver specific bus descriptions, but maybe this
is a case where one might consider adding one? Hans what do you think?
>
> > >
> > > Regards,
> > >
> > > Tim
> > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hans
> > > > >
> > > > > On 8/27/19 11:55 PM, Matthew Michilot wrote:
> > > > > > From: Matthew Michilot <[email protected]>
> > > > > >
> > > > > > Captured video would be out of sync when using the adv7280 with
> > > > > > the BT.656-4 protocol. Certain registers (0x04, 0x31, 0xE6) had to
> > > > > > be configured properly to ensure BT.656-4 compatibility.
> > > > > >
> > > > > > An error in the adv7280 reference manual suggested that EAV/SAV mode
> > > > > > 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/ADV7280_7281_7282_7283_UG-637.pdf
> >
>
> Table 99 in that document shows NEVAVMODE disabled on power-up
> (0x31=0x02) yet Page 77 shows it enabled at power-up. Looking at an
> actual device we find it is indeed disabled on powerup (0x31=0x02) 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/ADV7180.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
>
> --
>
>
> CONFIDENTIALITY NOTICE: This email constitutes an electronic
> communication within the meaning of the Electronic Communications Privacy
> Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named
> recipient(s) intended by the sender of this message. This email, and any
> attachments, may contain confidential and/or proprietary information. If
> you are not a named recipient, any copying, using, disclosing or
> distributing to others the information in this email and attachments is
> STRICTLY PROHIBITED. If you have received this email in error, please
> notify the sender immediately and permanently delete the email, any
> attachments, and all copies thereof from any drives or storage media and
> destroy any printouts or hard copies of the email and attachments.
>
> ?
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain
> technical data subject to U.S export restrictions under the International
> Traffic in Arms Regulations (ITAR) or the Export Administration Regulations
> (EAR). Export or transfer of this technical data and/or related information
> to any foreign person(s) or entity(ies), either within the U.S. or outside
> of the U.S., may require advance export authorization by the appropriate
> U.S. Government agency prior to export or transfer. In addition, technical
> data may not be exported or transferred to certain countries or specified
> designated nationals identified by U.S. embargo controls without prior
> export authorization. By accepting this email and any attachments, all
> recipients confirm that they understand and will comply with all applicable
> ITAR, EAR and embargo compliance requirements.
--
Regards,
Niklas S?derlund
On Fri, Sep 27, 2019 at 1:43 PM Niklas Söderlund
<[email protected]> wrote:
>
> Hi Tim,
>
> On 2019-09-27 12:26:40 -0700, Tim Harvey wrote:
> > On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
> > <[email protected]> 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öderlund
> > > > <[email protected]> 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 boards
> > > > > are in a box somewhere. I hope to have my lab up and running next week,
> > > > > 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.
>
> I understand your problem, the driver configures adv7180 and adv7280
> differently.
>
> >
> > So if the point of the driver is to configure the variants in the same
> > way, this patch needs to be applied.
>
> I'm not sure that is the point of the driver. As the driver today
> configures different compatible strings differently. Some as ITU-R
> BT.656-3 and some as ITU-R BT.656-4, I can only assume there is a reason
> for that.
>
> >
> > 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.
>
> I understand that this is needed to make it a drop-in replacement for
> the adv7180 in your use-case. But I'm not sure it is a good idea for
> other users of the driver. What if someone is already using a adv7282 on
> a board and depends on it providing ITU-R BT.656-3 and the old settings?
> If this patch is picked up there use-cases may break.
>
> I'm not sure what the best way forward is I'm afraid. Looking at
> video-interfaces.txt we have a device tree property bus-type which is
> used to describe the bus is a BT.656 bus but not which revision of it.
>
> I'm not really found of driver specific bus descriptions, but maybe this
> is a case where one might consider adding one? Hans what do you think?
>
Niklas / Hans,
Thanks for the feedback. I thought that the goal of any 'compatible'
device should be to be configured identically. If that's not the case
then we need more discussion for sure.
There are 3 registers being changed by this patch which do the
following for the adv7182/adv7280/adv7181/adv7282:
- change output from BT656-3 to BT656-4 (as the driver does this for adv7180)
- enable NEWAVMODE meaning EAV/SAV codes are configurable (new code
but adv7180 enables this by power-on default and adv7280 does not)
- configure V bit end count (to be what adv7180 uses; this isn't used
if NEWAVMODE is disabled)
So its not only the question of how to decide to configure BT656-3 vs
BT656-4 but how to deal with differences in the EAV/SAV codes. I'm not
an expert so I don't know what configuration is BT656 compliant and of
course without knowing who is using these devices we can't tell what
would break even if we fix something that may be misconfigured already
(or even completely unused).
I'm cc'ing Steve Longerbeam as well as at one point he was suggesting
adding a 'newavmode' property to the adv7180 bindings and likely
recalls the discussions there.
Tim
On 10/2/19 2:31 PM, Tim Harvey wrote:
> On Fri, Sep 27, 2019 at 1:43 PM Niklas Söderlund
> <[email protected]> wrote:
>> Hi Tim,
>>
>> On 2019-09-27 12:26:40 -0700, Tim Harvey wrote:
>>> On Fri, Sep 27, 2019 at 12:04 PM Niklas Söderlund
>>> <[email protected]> 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öderlund
>>>>> <[email protected]> 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 boards
>>>>>> are in a box somewhere. I hope to have my lab up and running next week,
>>>>>> 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.
>> I understand your problem, the driver configures adv7180 and adv7280
>> differently.
>>
>>> So if the point of the driver is to configure the variants in the same
>>> way, this patch needs to be applied.
>> I'm not sure that is the point of the driver. As the driver today
>> configures different compatible strings differently. Some as ITU-R
>> BT.656-3 and some as ITU-R BT.656-4, I can only assume there is a reason
>> for that.
>>
>>> 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.
>> I understand that this is needed to make it a drop-in replacement for
>> the adv7180 in your use-case. But I'm not sure it is a good idea for
>> other users of the driver. What if someone is already using a adv7282 on
>> a board and depends on it providing ITU-R BT.656-3 and the old settings?
>> If this patch is picked up there use-cases may break.
>>
>> I'm not sure what the best way forward is I'm afraid. Looking at
>> video-interfaces.txt we have a device tree property bus-type which is
>> used to describe the bus is a BT.656 bus but not which revision of it.
>>
>> I'm not really found of driver specific bus descriptions, but maybe this
>> is a case where one might consider adding one? Hans what do you think?
>>
> Niklas / Hans,
>
> Thanks for the feedback. I thought that the goal of any 'compatible'
> device should be to be configured identically. If that's not the case
> then we need more discussion for sure.
>
> There are 3 registers being changed by this patch which do the
> following for the adv7182/adv7280/adv7181/adv7282:
> - change output from BT656-3 to BT656-4 (as the driver does this for adv7180)
> - enable NEWAVMODE meaning EAV/SAV codes are configurable (new code
> but adv7180 enables this by power-on default and adv7280 does not)
> - configure V bit end count (to be what adv7180 uses; this isn't used
> if NEWAVMODE is disabled)
>
> So its not only the question of how to decide to configure BT656-3 vs
> BT656-4 but how to deal with differences in the EAV/SAV codes. I'm not
> an expert so I don't know what configuration is BT656 compliant and of
> course without knowing who is using these devices we can't tell what
> would break even if we fix something that may be misconfigured already
> (or even completely unused).
>
> I'm cc'ing Steve Longerbeam as well as at one point he was suggesting
> adding a 'newavmode' property to the adv7180 bindings and likely
> recalls the discussions there.
I've never understood why the adv7180 driver configures a non-standard
V-bit end position (ADV7180_NTSC_V_BIT_END_MANUAL_NVEND), maybe because
the driver was introduced along with a new bridge driver that assumes
that V-bit position. The parallel CSI interface in imx6 driver is also
configuring its crop window to work with this non-standard V-bit position.
The most straight-forward approach to decouple these adv7180
dependencies would be to remove the non-standard V-bit setting in the
adv7180 driver, and it should output standard bt.656-3 or bt.656-4
SAV/EAV codes for all compatible chips. Then expand on the bus-type DT
bindings to distinguish between bt.656-3 and bt.656-4. And finally all
bridge drivers that use adv7180 would have to be fixed to work only with
standard bt.656-3/4 codes. But I realize that last part isn't so easy,
and it's even possible some bridge drivers may not be able to cope with
the standard V-bit positions.
Steve