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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.