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
prev parent 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