Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420999 > unrolled thread

Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2016-06-13 17:30 +0200
    Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls Arnd Bergmann <arnd@arndb.de> - 2016-06-13 21:30 +0200
    Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls Afzal Mohammed <afzal.mohd.ma@gmail.com> - 2016-06-14 18:10 +0200
      Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-06-14 18:20 +0200

#1420999 — Re: [PATCH 01/48] clk: at91: replace usleep() by udelay() calls

On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :
> On Saturday, June 11, 2016 12:03:04 AM CEST Alexandre Belloni wrote:
> > From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> > 
> > Fix the main and slow clock .prepare() implementations which used to call
> > usleep() when the scheduler wasn't ready yet.
> > 
> 
> Does this have to be called that early? It seems wasteful to always
> call udelay() here, when these are functions that are normally
> allowed to sleep.
> 

So I've tested it and something like that would work:

	if (system_state < SYSTEM_RUNNING)
		udelay(osc->startup_usec);
	else
		usleep_range(osc->startup_usec, osc->startup_usec + 1);

But I'm afraid it would be the first driver to actually do something
like that (however, it is already the only driver trying to sleep). 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [next] | [standalone]

#1421241

On Monday, June 13, 2016 5:24:09 PM CEST Alexandre Belloni wrote:
> On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :
> > On Saturday, June 11, 2016 12:03:04 AM CEST Alexandre Belloni wrote:
> > > From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> > > 
> > > Fix the main and slow clock .prepare() implementations which used to call
> > > usleep() when the scheduler wasn't ready yet.
> > > 
> > 
> > Does this have to be called that early? It seems wasteful to always
> > call udelay() here, when these are functions that are normally
> > allowed to sleep.
> > 
> 
> So I've tested it and something like that would work:
> 
>         if (system_state < SYSTEM_RUNNING)
>                 udelay(osc->startup_usec);
>         else
>                 usleep_range(osc->startup_usec, osc->startup_usec + 1);

I think that's reasonable in this case.

> But I'm afraid it would be the first driver to actually do something
> like that (however, it is already the only driver trying to sleep). 

We have a lot of drivers that call potentially sleeping function from
the .prepare callback, e.g. when they go to an i2c controller.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1422052

Hi,

On Mon, Jun 13, 2016 at 05:24:09PM +0200, Alexandre Belloni wrote:
> On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :

> > Does this have to be called that early? It seems wasteful to always
> > call udelay() here, when these are functions that are normally
> > allowed to sleep.

> So I've tested it and something like that would work:
> 
> 	if (system_state < SYSTEM_RUNNING)
> 		udelay(osc->startup_usec);
> 	else
> 		usleep_range(osc->startup_usec, osc->startup_usec + 1);
> 
> But I'm afraid it would be the first driver to actually do something
> like that (however, it is already the only driver trying to sleep). 

tglx has suggested to modify clock core to handle a somewhat similar
kind of scenario (probably should work here too) and avoid driver
changes,

http://lkml.kernel.org/r/alpine.DEB.2.11.1606061448010.28031@nanos

Regards
afzal

[toc] | [prev] | [next] | [standalone]

#1422059

On Tue, 14 Jun 2016 21:35:17 +0530
Afzal Mohammed <afzal.mohd.ma@gmail.com> wrote:

> Hi,
> 
> On Mon, Jun 13, 2016 at 05:24:09PM +0200, Alexandre Belloni wrote:
> > On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :  
> 
> > > Does this have to be called that early? It seems wasteful to always
> > > call udelay() here, when these are functions that are normally
> > > allowed to sleep.  
> 
> > So I've tested it and something like that would work:
> > 
> > 	if (system_state < SYSTEM_RUNNING)
> > 		udelay(osc->startup_usec);
> > 	else
> > 		usleep_range(osc->startup_usec, osc->startup_usec + 1);
> > 
> > But I'm afraid it would be the first driver to actually do something
> > like that (however, it is already the only driver trying to sleep).   
> 
> tglx has suggested to modify clock core to handle a somewhat similar
> kind of scenario (probably should work here too) and avoid driver
> changes,
> 
> http://lkml.kernel.org/r/alpine.DEB.2.11.1606061448010.28031@nanos

Oh, interesting. Definitely a better solution than this custom check.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web