Linux Media Controller development
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Bingbu Cao <bingbu.cao@intel.com>,
	Tianshu Qiu <tian.shu.qiu@intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] media: ov2740: Ensure proper reset sequence on probe()
Date: Mon, 13 May 2024 12:07:16 +0200	[thread overview]
Message-ID: <ZkHmVNloIZBY58d8@linux.intel.com> (raw)
In-Reply-To: <f74981e4-ad5c-415d-9f1a-d03a8194db25@redhat.com>

Hi Hans

On Thu, May 09, 2024 at 03:42:25PM +0200, Hans de Goede wrote:
> Hi Stanislaw,
> 
> On 5/9/24 1:42 PM, Stanislaw Gruszka wrote:
> > On Mon, May 06, 2024 at 03:24:38PM +0200, Hans de Goede wrote:
> >> Before this commit on probe() the driver would do:
> >>
> >> reset=1                // from probe() calling gpiod_get(GPIOD_OUT_HIGH)
> >> reset=0                // from resume()
> >> msleep(20)             // from resume()
> >>
> >> So if reset was 0 before getting the GPIO the reset line would only be
> >> driven high for a very short time and sometimes there would be errors
> >> reading the id register afterwards.
> >>
> >> Add a msleep(20) after getting the reset line to ensure the sensor is
> >> properly reset:
> >>
> >> reset=1                // from probe() calling gpiod_get(GPIOD_OUT_HIGH)
> >> msleep(20)             // from probe()
> >> reset=0                // from resume()
> >> msleep(20)             // from resume()
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > Tested-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> > 
> > This fixes this issue:
> > 
> > [    7.742633] ov2740 i2c-INT3474:01: chip id mismatch: 2740 != 0
> > [    7.742638] ov2740 i2c-INT3474:01: error -ENXIO: failed to find sensor
> > 
> > for me as well.
> 
> Thank you for testing.
> 
> However there is still the issue of the sensor not always starting to
> stream reliably being discussed here:
> 
> https://github.com/intel/ipu6-drivers/issues/187
> 
> I have been thinking about this and I think that something like this
> should fix this, can you give this a try (with the patch to disable
> runtime-pm reverted) :
> 
> diff --git a/drivers/media/i2c/ov2740.c b/drivers/media/i2c/ov2740.c
> index c48dbcde9877..58818bcfe086 100644
> --- a/drivers/media/i2c/ov2740.c
> +++ b/drivers/media/i2c/ov2740.c
> @@ -1294,7 +1294,14 @@ static int ov2740_suspend(struct device *dev)
>  	struct ov2740 *ov2740 = to_ov2740(sd);
>  
>  	gpiod_set_value_cansleep(ov2740->reset_gpio, 1);
> +	/*
> +	 * Ensure reset is asserted for at least 20 ms before disabling the clk.
> +	 * This also assures reset is properly asserted for 20 ms when a runtime
> +	 * suspend is immediately followed by a runtime resume.
> +	 */
> +	msleep(20);
>  	clk_disable_unprepare(ov2740->clk);
> +
>  	return 0;
>  }
>  
> @@ -1308,6 +1315,9 @@ static int ov2740_resume(struct device *dev)
>  	if (ret)
>  		return ret;
>  
> +	/* Give clk time to stabilize */
> +	msleep(20);
> +
>  	gpiod_set_value_cansleep(ov2740->reset_gpio, 0);
>  	msleep(20);
>  
> 
> Hopefully this will fix the start / stop stream issues when runtime
> pm is enabled.

With the both patches I have quite good reproducible "chip id mismatch"
problem. I test patch 1 and patch 2 separately and both of them together.
Unfortunately non combination fixes the issues: mismatch and steam
start and some other problems with ov2740 on my lenovo x1 laptop

Looks previously I get good result with original patch just by sheer luck.
Those are random problems and reuire more testing before confirmation
of fix.

So sadly I have to scratch result that original patch fixes chip mishmash id
issue :-(

Problems need to be properly debugged and require deeper investigation.

Regards
Stanislaw
   

      reply	other threads:[~2024-05-13 10:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-06 13:24 [PATCH] media: ov2740: Ensure proper reset sequence on probe() Hans de Goede
2024-05-09 11:42 ` Stanislaw Gruszka
2024-05-09 13:42   ` Hans de Goede
2024-05-13 10:07     ` Stanislaw Gruszka [this message]

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=ZkHmVNloIZBY58d8@linux.intel.com \
    --to=stanislaw.gruszka@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tian.shu.qiu@intel.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