Hi Kieran, On Thu, Apr 16, 2020 at 12:31:32PM +0100, Kieran Bingham wrote: > On 16/04/2020 12:31, Jacopo Mondi wrote: > > Hi Kieran, > > > > On Thu, Apr 16, 2020 at 11:50:07AM +0100, Kieran Bingham wrote: > >> Hi Jacopo, > >> > >> On 16/04/2020 11:40, Jacopo Mondi wrote: > >>> From: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > >>> > >>> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx> > >>> > >>> --- > >>> v2: > >>> [Jacopo] > >>> - Write register 0x63 and 0x64 directly as going through the function > >>> breaks RDACM21 operations > >>> --- > >>> drivers/media/i2c/max9286.c | 12 ++++++++++++ > >>> 1 file changed, 12 insertions(+) > >>> > >>> diff --git a/drivers/media/i2c/max9286.c b/drivers/media/i2c/max9286.c > >>> index 3ef74ba10074..e0c637d4a7de 100644 > >>> --- a/drivers/media/i2c/max9286.c > >>> +++ b/drivers/media/i2c/max9286.c > >>> @@ -966,6 +966,18 @@ static int max9286_setup(struct max9286_priv *priv) > >>> max9286_write(priv, 0x0c, MAX9286_HVEN | MAX9286_INVVS | > >>> MAX9286_HVSRC_D14); > >>> > >>> + /* > >>> + * The overlap window seems to provide additional validation by tracking > >>> + * the delay between vsync and frame sync, generating an error if the > >>> + * delay is bigger than the programmed window, though it's not yet clear > >>> + * what value should be set. > >>> + * > >>> + * As it's an optional value and can be disabled, we do so by setting > >>> + * a 0 overlap value. > >> > >> Are you happy to add the following as part of the removal of the function? > >> > >> * > >> * The overlap window is a 13 bit value, and register 0x64 is > >> * shared with ENFSINLAST in BIT(5) which is also set zero. > >> * > > > > Not sure, as I noticed failres for RDACM21 when not writing the > > supposidely reserved bits. > > > > As we blindly write the full registers I would leave details out until > > we figure out what's happening. > > But that's precisely why I think we should document it :-) Otherwise - > some other person could hit this issue in a different way... In that case yes, I was concerned about the "reserved bits", but please go ahead and add that comment. > > > > >> > >>> + */ > >>> + max9286_write(priv, 0x63, 0); > >>> + max9286_write(priv, 0x64, 0); > >>> + > >>> /* > >>> * Wait for 2ms to allow the link to resynchronize after the > >>> * configuration change. > >>> > >> >
