| Message ID | 20190827215539.1286-1-mmichilot@gateworks.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: i2c: adv7180: fix adv7280 BT.656-4 compatibility | expand |
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 <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 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 <matthew.michilot@gmail.com> > Reviewed-by: Tim Harvey <tharvey@gateworks.com> > --- > 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 <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 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 <matthew.michilot@gmail.com> > > Reviewed-by: Tim Harvey <tharvey@gateworks.com> > > --- > > 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, > > >
On Thu, Aug 29, 2019 at 7:29 AM Niklas Söderlund <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 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 <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 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 <matthew.michilot@gmail.com> > > > Reviewed-by: Tim Harvey <tharvey@gateworks.com> > > > --- > > > 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 > <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 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 <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 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 <matthew.michilot@gmail.com> > > > > Reviewed-by: Tim Harvey <tharvey@gateworks.com> > > > > --- > > > > 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, On Wed, Sep 25, 2019 at 9:22 PM Tim Harvey <tharvey@gateworks.com> 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 <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öderlund > > <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 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 <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 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
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 > <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öderlund > > > <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 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 <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 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.
On Fri, Sep 27, 2019 at 1:43 PM Niklas Söderlund <niklas.soderlund@ragnatech.se> 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 > > <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öderlund > > > > <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 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 > <niklas.soderlund@ragnatech.se> 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 >>> <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öderlund >>>>> <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 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
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,