Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-12 Thread Mark Brown
On Wed, Jan 11, 2017 at 06:59:52PM +, Nicholas Mc Guire wrote: > On Wed, Jan 11, 2017 at 06:06:58PM +, Mark Brown wrote: > > Yes, but as fairly recently discussed somewhere on the lists (and IIRC > > actually fixed) approximately no users expect or want that behaviour - > True its an odd

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-12 Thread Mark Brown
On Wed, Jan 11, 2017 at 06:59:52PM +, Nicholas Mc Guire wrote: > On Wed, Jan 11, 2017 at 06:06:58PM +, Mark Brown wrote: > > Yes, but as fairly recently discussed somewhere on the lists (and IIRC > > actually fixed) approximately no users expect or want that behaviour - > True its an odd

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 06:06:58PM +, Mark Brown wrote: > On Wed, Jan 11, 2017 at 03:06:45PM +, Nicholas Mc Guire wrote: > > On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > > > > If you're doing conversions like this I'd expect us to be picking the > > > lower number rather

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 06:06:58PM +, Mark Brown wrote: > On Wed, Jan 11, 2017 at 03:06:45PM +, Nicholas Mc Guire wrote: > > On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > > > > If you're doing conversions like this I'd expect us to be picking the > > > lower number rather

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Mark Brown
On Wed, Jan 11, 2017 at 03:06:45PM +, Nicholas Mc Guire wrote: > On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > > If you're doing conversions like this I'd expect us to be picking the > > lower number rather than the higher number - people are saying "wait for > > at least X

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Mark Brown
On Wed, Jan 11, 2017 at 03:06:45PM +, Nicholas Mc Guire wrote: > On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > > If you're doing conversions like this I'd expect us to be picking the > > lower number rather than the higher number - people are saying "wait for > > at least X

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > On Wed, Jan 11, 2017 at 12:49:36PM +0100, Nicholas Mc Guire wrote: > > > if (!rt5651->hp_mute) > > - usleep_range(8, 85000); > > + msleep(85); > > If you're doing conversions like

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 02:59:26PM +, Mark Brown wrote: > On Wed, Jan 11, 2017 at 12:49:36PM +0100, Nicholas Mc Guire wrote: > > > if (!rt5651->hp_mute) > > - usleep_range(8, 85000); > > + msleep(85); > > If you're doing conversions like

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Mark Brown
On Wed, Jan 11, 2017 at 12:49:36PM +0100, Nicholas Mc Guire wrote: > if (!rt5651->hp_mute) > - usleep_range(8, 85000); > + msleep(85); If you're doing conversions like this I'd expect us to be picking the lower number rather than the

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Mark Brown
On Wed, Jan 11, 2017 at 12:49:36PM +0100, Nicholas Mc Guire wrote: > if (!rt5651->hp_mute) > - usleep_range(8, 85000); > + msleep(85); If you're doing conversions like this I'd expect us to be picking the lower number rather than the

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 03:55:49AM -0800, Joe Perches wrote: > On Wed, 2017-01-11 at 12:49 +0100, Nicholas Mc Guire wrote: > > ulseep_range() uses hrtimers and provides no advantage over msleep() > > for larger delays. Fix up the 75/85ms delays here to use msleep() and > > reduce the load on the

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
On Wed, Jan 11, 2017 at 03:55:49AM -0800, Joe Perches wrote: > On Wed, 2017-01-11 at 12:49 +0100, Nicholas Mc Guire wrote: > > ulseep_range() uses hrtimers and provides no advantage over msleep() > > for larger delays. Fix up the 75/85ms delays here to use msleep() and > > reduce the load on the

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Joe Perches
On Wed, 2017-01-11 at 12:49 +0100, Nicholas Mc Guire wrote: > ulseep_range() uses hrtimers and provides no advantage over msleep() > for larger delays. Fix up the 75/85ms delays here to use msleep() and > reduce the load on the hrtimer subsystem. If this is useful, why not convert all the large

Re: [PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Joe Perches
On Wed, 2017-01-11 at 12:49 +0100, Nicholas Mc Guire wrote: > ulseep_range() uses hrtimers and provides no advantage over msleep() > for larger delays. Fix up the 75/85ms delays here to use msleep() and > reduce the load on the hrtimer subsystem. If this is useful, why not convert all the large

[PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
ulseep_range() uses hrtimers and provides no advantage over msleep() for larger delays. Fix up the 75/85ms delays here to use msleep() and reduce the load on the hrtimer subsystem. Signed-off-by: Nicholas Mc Guire --- As these are non-atomic regions and a delay of 75/85 ms

[PATCH] ASoC: rt5651: use msleep for large delays

2017-01-11 Thread Nicholas Mc Guire
ulseep_range() uses hrtimers and provides no advantage over msleep() for larger delays. Fix up the 75/85ms delays here to use msleep() and reduce the load on the hrtimer subsystem. Signed-off-by: Nicholas Mc Guire --- As these are non-atomic regions and a delay of 75/85 ms implies that there is