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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo