All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Nicholas Mc Guire <hofrat@opentech.at>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] media: smiapp: core: add range to usleep_range
Date: Sat, 4 May 2019 11:46:35 +0200	[thread overview]
Message-ID: <20190504094635.GA27029@osadl.at> (raw)
In-Reply-To: <20190430134944.6sutxdztj6crgo6w@valkosipuli.retiisi.org.uk>

On Tue, Apr 30, 2019 at 04:49:44PM +0300, Sakari Ailus wrote:
> Hi Nicholas,
> 
> On Sun, Apr 07, 2019 at 04:16:02AM +0200, Nicholas Mc Guire wrote:
> > Allow the hrtimer subsystem to coalesce delay timers of lower accuracy
> > by providing a suitable range
> > 
> > Signed-off-by: Nicholas Mc Guire <hofrat@opentech.at>
> > ---
> > 
> > Problem located by an experimental coccinelle script
> > 
> > hrtimers in atomic context have limited accuracy due to possible
> > context-switching and interruption so the accuracy is limited 
> > anyway. Giving the hrtimer subsystem a reasonable range for merging
> > hrtimers helps to reduce the load on the hrtimer subsystem. As this
> > delays do not seem to mandate high accuracy the range of a factor
> > two seems acceptable.
> > 
> > Patch was compile tested with: x86_64_defconfig + MEDIA_SUPPORT=m,
> > MEDIA_CAMERA_SUPPORT=y, MEDIA_CONTROLLER=y, VIDEO_V4L2_SUBDEV_API=y,
> > VIDEO_SMIAPP=m                                                                                               
> > (with a number of sparse warnings on sizeof() usage)
> > 
> > Patch is against 5.1-rc3 (localversion-next is next-20190405)
> 
> The delays are exact for the reason that they are user-visible delays in
> image capturing related use cases. Sometimes milliseconds matter, or at
> least adding more does not help.
>

Actually it can be better iwith respect to jitter to let the hrtimer 
subsystem use an existing timer event than to have a close by second event 
and the accuracy is determined by the non-atomic context anyway - 
so while the proposed delay extension might be excessive in your case
I would still suggest to try to get away from a range of 0 - even if
you only end up with (1000,1050) that would be an advantage for the
timer subsystem.

thx!
hofrat
 
> > 
> >  drivers/media/i2c/smiapp/smiapp-core.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
> > index 58a45c3..c0c29ec 100644
> > --- a/drivers/media/i2c/smiapp/smiapp-core.c
> > +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> > @@ -1222,19 +1222,19 @@ static int smiapp_power_on(struct device *dev)
> >  		dev_err(&client->dev, "failed to enable vana regulator\n");
> >  		return rval;
> >  	}
> > -	usleep_range(1000, 1000);
> > +	usleep_range(1000, 2000);
> >  
> >  	rval = clk_prepare_enable(sensor->ext_clk);
> >  	if (rval < 0) {
> >  		dev_dbg(&client->dev, "failed to enable xclk\n");
> >  		goto out_xclk_fail;
> >  	}
> > -	usleep_range(1000, 1000);
> > +	usleep_range(1000, 2000);
> >  
> >  	gpiod_set_value(sensor->xshutdown, 1);
> >  
> >  	sleep = SMIAPP_RESET_DELAY(sensor->hwcfg->ext_clk);
> > -	usleep_range(sleep, sleep);
> > +	usleep_range(sleep, sleep*2);
> >  
> >  	mutex_lock(&sensor->mutex);
> >  
> > @@ -1381,7 +1381,7 @@ static int smiapp_power_off(struct device *dev)
> >  
> >  	gpiod_set_value(sensor->xshutdown, 0);
> >  	clk_disable_unprepare(sensor->ext_clk);
> > -	usleep_range(5000, 5000);
> > +	usleep_range(5000, 10000);
> >  	regulator_disable(sensor->vana);
> >  	sensor->streaming = false;
> >  
> 
> -- 
> Sakari Ailus

  reply	other threads:[~2019-05-04  9:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-07  2:16 [PATCH 1/3] media: smiapp: core: add range to usleep_range Nicholas Mc Guire
2019-04-07  2:16 ` [PATCH 2/3] media: smiapp: regs: " Nicholas Mc Guire
2019-04-07  2:16 ` [PATCH 3/3] media: smiapp: quirk: " Nicholas Mc Guire
2019-04-30 13:49 ` [PATCH 1/3] media: smiapp: core: " Sakari Ailus
2019-05-04  9:46   ` Nicholas Mc Guire [this message]
2019-05-07 21:04     ` Sakari Ailus

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=20190504094635.GA27029@osadl.at \
    --to=der.herr@hofr.at \
    --cc=hofrat@opentech.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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.