Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-06 Thread Felix Rueegg 

Hi Dmitry,

On 03/04/2014 06:07 PM, Dmitry Torokhov wrote:

Hi Felix,

On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:

When an effect with zero replay length, zero replay delay
and zero envelope attack length is uploaded, it is played and then scheduled to 
play
again one timer tick later. This triggers a warning (URB submitted while
active) in combination with the xpad driver.

Skipping the rescheduling of this effect fixes the issue.

Won't the same issue happen if we happen to schedule a different effect
that would start at "now" time? We should not be "dropping" the new
effect, at least not in core.
I can confirm this. It also happens sometimes with an effect that has a 
length and a replay count greater than one at the time, when the effect 
ends and restarts again.

It looks to me xpad.c needs [more] love.

I agree and will try to come up with a fix for the xpad driver.


Signed-off-by: Felix Rueegg 
---
  drivers/input/ff-memless.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 74c0d8c..2e06948 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
if (!test_bit(FF_EFFECT_STARTED, >flags))
continue;
  
-		if (test_bit(FF_EFFECT_PLAYING, >flags))

+   if (test_bit(FF_EFFECT_PLAYING, >flags)) {
next_at = calculate_next_time(state);
-   else
+   if (next_at == now)
+   continue;
+   } else {
next_at = state->play_at;
+   }
  
  		if (time_before_eq(now, next_at) &&

(++events == 1 || time_before(next_at, earliest)))
--
1.9.0


Thanks.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-06 Thread Felix Rueegg 

Hi Dmitry,

On 03/04/2014 06:07 PM, Dmitry Torokhov wrote:

Hi Felix,

On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:

When an effect with zero replay length, zero replay delay
and zero envelope attack length is uploaded, it is played and then scheduled to 
play
again one timer tick later. This triggers a warning (URB submitted while
active) in combination with the xpad driver.

Skipping the rescheduling of this effect fixes the issue.

Won't the same issue happen if we happen to schedule a different effect
that would start at now time? We should not be dropping the new
effect, at least not in core.
I can confirm this. It also happens sometimes with an effect that has a 
length and a replay count greater than one at the time, when the effect 
ends and restarts again.

It looks to me xpad.c needs [more] love.

I agree and will try to come up with a fix for the xpad driver.


Signed-off-by: Felix Rueegg felix.rue...@gmail.com
---
  drivers/input/ff-memless.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 74c0d8c..2e06948 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
if (!test_bit(FF_EFFECT_STARTED, state-flags))
continue;
  
-		if (test_bit(FF_EFFECT_PLAYING, state-flags))

+   if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
next_at = calculate_next_time(state);
-   else
+   if (next_at == now)
+   continue;
+   } else {
next_at = state-play_at;
+   }
  
  		if (time_before_eq(now, next_at) 

(++events == 1 || time_before(next_at, earliest)))
--
1.9.0


Thanks.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-04 Thread Dmitry Torokhov 
Hi Felix,

On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:
> When an effect with zero replay length, zero replay delay
> and zero envelope attack length is uploaded, it is played and then scheduled 
> to play
> again one timer tick later. This triggers a warning (URB submitted while
> active) in combination with the xpad driver.
> 
> Skipping the rescheduling of this effect fixes the issue.

Won't the same issue happen if we happen to schedule a different effect
that would start at "now" time? We should not be "dropping" the new
effect, at least not in core.

It looks to me xpad.c needs [more] love.

> 
> Signed-off-by: Felix Rueegg 
> ---
>  drivers/input/ff-memless.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> index 74c0d8c..2e06948 100644
> --- a/drivers/input/ff-memless.c
> +++ b/drivers/input/ff-memless.c
> @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
>   if (!test_bit(FF_EFFECT_STARTED, >flags))
>   continue;
>  
> - if (test_bit(FF_EFFECT_PLAYING, >flags))
> + if (test_bit(FF_EFFECT_PLAYING, >flags)) {
>   next_at = calculate_next_time(state);
> - else
> + if (next_at == now)
> + continue;
> + } else {
>   next_at = state->play_at;
> + }
>  
>   if (time_before_eq(now, next_at) &&
>   (++events == 1 || time_before(next_at, earliest)))
> -- 
> 1.9.0
> 

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-04 Thread Dmitry Torokhov 
Hi Felix,

On Sun, Mar 02, 2014 at 12:35:43PM +0100, Felix Rueegg wrote:
 When an effect with zero replay length, zero replay delay
 and zero envelope attack length is uploaded, it is played and then scheduled 
 to play
 again one timer tick later. This triggers a warning (URB submitted while
 active) in combination with the xpad driver.
 
 Skipping the rescheduling of this effect fixes the issue.

Won't the same issue happen if we happen to schedule a different effect
that would start at now time? We should not be dropping the new
effect, at least not in core.

It looks to me xpad.c needs [more] love.

 
 Signed-off-by: Felix Rueegg felix.rue...@gmail.com
 ---
  drivers/input/ff-memless.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
 index 74c0d8c..2e06948 100644
 --- a/drivers/input/ff-memless.c
 +++ b/drivers/input/ff-memless.c
 @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
   if (!test_bit(FF_EFFECT_STARTED, state-flags))
   continue;
  
 - if (test_bit(FF_EFFECT_PLAYING, state-flags))
 + if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
   next_at = calculate_next_time(state);
 - else
 + if (next_at == now)
 + continue;
 + } else {
   next_at = state-play_at;
 + }
  
   if (time_before_eq(now, next_at) 
   (++events == 1 || time_before(next_at, earliest)))
 -- 
 1.9.0
 

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Elias Vanderstuyft 
-- Forwarded message --
From: Michal Malý 
Date: Sun, Mar 2, 2014 at 2:29 PM
Subject: Re: [PATCH] input: ff-memless: don't schedule already playing
effect to play again
To: Elias Vanderstuyft 


On Sunday 02 of March 2014 14:17:58 you wrote:
> On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg
 wrote:
> > When an effect with zero replay length, zero replay delay
> > and zero envelope attack length is uploaded, it is played and then
> > scheduled to play again one timer tick later. This triggers a
warning
> > (URB submitted while active) in combination with the xpad driver.
> >
> > Skipping the rescheduling of this effect fixes the issue.
> >
> > Signed-off-by: Felix Rueegg 
> > ---
> >
> >  drivers/input/ff-memless.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> > index 74c0d8c..2e06948 100644
> > --- a/drivers/input/ff-memless.c
> > +++ b/drivers/input/ff-memless.c
> > @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct
ml_device *ml)
> >
> > if (!test_bit(FF_EFFECT_STARTED, >flags))
> >
> > continue;
> >
> > -   if (test_bit(FF_EFFECT_PLAYING, >flags))
> > +   if (test_bit(FF_EFFECT_PLAYING, >flags)) {
> >
> > next_at = calculate_next_time(state);
> >
> > -   else
> > +   if (next_at == now)
> > +   continue;
> > +   } else {
> >
> > next_at = state->play_at;
> >
> > +   }
> >
> > if (time_before_eq(now, next_at) &&
> >
> > (++events == 1 || time_before(next_at, earliest)))
> >
> > --
> > 1.9.0
> >
> > --
>
> @Michal: Is ff-memless-next also affected by this problem?
>
> Elias

I hope it's not, see mlnx_get_envelope_update_time(), this part in
particular:

/* Prevent the effect from being started twice */
if (mlnxeff->begin_at == now && mlnx_is_playing(mlnxeff))
return now - 1;

return mlnxeff->begin_at;

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Michal Malý 
On Sunday 02 of March 2014 14:17:58 you wrote:
> On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg 
 wrote:
> > When an effect with zero replay length, zero replay delay
> > and zero envelope attack length is uploaded, it is played and then
> > scheduled to play again one timer tick later. This triggers a 
warning
> > (URB submitted while active) in combination with the xpad driver.
> > 
> > Skipping the rescheduling of this effect fixes the issue.
> > 
> > Signed-off-by: Felix Rueegg 
> > ---
> > 
> >  drivers/input/ff-memless.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> > index 74c0d8c..2e06948 100644
> > --- a/drivers/input/ff-memless.c
> > +++ b/drivers/input/ff-memless.c
> > @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct 
ml_device *ml)
> > 
> > if (!test_bit(FF_EFFECT_STARTED, >flags))
> > 
> > continue;
> > 
> > -   if (test_bit(FF_EFFECT_PLAYING, >flags))
> > +   if (test_bit(FF_EFFECT_PLAYING, >flags)) {
> > 
> > next_at = calculate_next_time(state);
> > 
> > -   else
> > +   if (next_at == now)
> > +   continue;
> > +   } else {
> > 
> > next_at = state->play_at;
> > 
> > +   }
> > 
> > if (time_before_eq(now, next_at) &&
> > 
> > (++events == 1 || time_before(next_at, earliest)))
> > 
> > --
> > 1.9.0
> > 
> > --
> 
> @Michal: Is ff-memless-next also affected by this problem?
> 
> Elias

I hope it's not, see mlnx_get_envelope_update_time(), this part in 
particular:

/* Prevent the effect from being started twice */
if (mlnxeff->begin_at == now && mlnx_is_playing(mlnxeff))
return now - 1;

return mlnxeff->begin_at;

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Elias Vanderstuyft 
On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg  wrote:
> When an effect with zero replay length, zero replay delay
> and zero envelope attack length is uploaded, it is played and then scheduled 
> to play
> again one timer tick later. This triggers a warning (URB submitted while
> active) in combination with the xpad driver.
>
> Skipping the rescheduling of this effect fixes the issue.
>
> Signed-off-by: Felix Rueegg 
> ---
>  drivers/input/ff-memless.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
> index 74c0d8c..2e06948 100644
> --- a/drivers/input/ff-memless.c
> +++ b/drivers/input/ff-memless.c
> @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
> if (!test_bit(FF_EFFECT_STARTED, >flags))
> continue;
>
> -   if (test_bit(FF_EFFECT_PLAYING, >flags))
> +   if (test_bit(FF_EFFECT_PLAYING, >flags)) {
> next_at = calculate_next_time(state);
> -   else
> +   if (next_at == now)
> +   continue;
> +   } else {
> next_at = state->play_at;
> +   }
>
> if (time_before_eq(now, next_at) &&
> (++events == 1 || time_before(next_at, earliest)))
> --
> 1.9.0
>
> --

@Michal: Is ff-memless-next also affected by this problem?

Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Felix Rueegg 
When an effect with zero replay length, zero replay delay
and zero envelope attack length is uploaded, it is played and then scheduled to 
play
again one timer tick later. This triggers a warning (URB submitted while
active) in combination with the xpad driver.

Skipping the rescheduling of this effect fixes the issue.

Signed-off-by: Felix Rueegg 
---
 drivers/input/ff-memless.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 74c0d8c..2e06948 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
if (!test_bit(FF_EFFECT_STARTED, >flags))
continue;
 
-   if (test_bit(FF_EFFECT_PLAYING, >flags))
+   if (test_bit(FF_EFFECT_PLAYING, >flags)) {
next_at = calculate_next_time(state);
-   else
+   if (next_at == now)
+   continue;
+   } else {
next_at = state->play_at;
+   }
 
if (time_before_eq(now, next_at) &&
(++events == 1 || time_before(next_at, earliest)))
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Felix Rueegg 
When an effect with zero replay length, zero replay delay
and zero envelope attack length is uploaded, it is played and then scheduled to 
play
again one timer tick later. This triggers a warning (URB submitted while
active) in combination with the xpad driver.

Skipping the rescheduling of this effect fixes the issue.

Signed-off-by: Felix Rueegg felix.rue...@gmail.com
---
 drivers/input/ff-memless.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index 74c0d8c..2e06948 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
if (!test_bit(FF_EFFECT_STARTED, state-flags))
continue;
 
-   if (test_bit(FF_EFFECT_PLAYING, state-flags))
+   if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
next_at = calculate_next_time(state);
-   else
+   if (next_at == now)
+   continue;
+   } else {
next_at = state-play_at;
+   }
 
if (time_before_eq(now, next_at) 
(++events == 1 || time_before(next_at, earliest)))
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Elias Vanderstuyft 
On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg felix.rue...@gmail.com wrote:
 When an effect with zero replay length, zero replay delay
 and zero envelope attack length is uploaded, it is played and then scheduled 
 to play
 again one timer tick later. This triggers a warning (URB submitted while
 active) in combination with the xpad driver.

 Skipping the rescheduling of this effect fixes the issue.

 Signed-off-by: Felix Rueegg felix.rue...@gmail.com
 ---
  drivers/input/ff-memless.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
 index 74c0d8c..2e06948 100644
 --- a/drivers/input/ff-memless.c
 +++ b/drivers/input/ff-memless.c
 @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct ml_device *ml)
 if (!test_bit(FF_EFFECT_STARTED, state-flags))
 continue;

 -   if (test_bit(FF_EFFECT_PLAYING, state-flags))
 +   if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
 next_at = calculate_next_time(state);
 -   else
 +   if (next_at == now)
 +   continue;
 +   } else {
 next_at = state-play_at;
 +   }

 if (time_before_eq(now, next_at) 
 (++events == 1 || time_before(next_at, earliest)))
 --
 1.9.0

 --

@Michal: Is ff-memless-next also affected by this problem?

Elias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Michal Malý 
On Sunday 02 of March 2014 14:17:58 you wrote:
 On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg 
felix.rue...@gmail.com wrote:
  When an effect with zero replay length, zero replay delay
  and zero envelope attack length is uploaded, it is played and then
  scheduled to play again one timer tick later. This triggers a 
warning
  (URB submitted while active) in combination with the xpad driver.
  
  Skipping the rescheduling of this effect fixes the issue.
  
  Signed-off-by: Felix Rueegg felix.rue...@gmail.com
  ---
  
   drivers/input/ff-memless.c | 7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)
  
  diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
  index 74c0d8c..2e06948 100644
  --- a/drivers/input/ff-memless.c
  +++ b/drivers/input/ff-memless.c
  @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct 
ml_device *ml)
  
  if (!test_bit(FF_EFFECT_STARTED, state-flags))
  
  continue;
  
  -   if (test_bit(FF_EFFECT_PLAYING, state-flags))
  +   if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
  
  next_at = calculate_next_time(state);
  
  -   else
  +   if (next_at == now)
  +   continue;
  +   } else {
  
  next_at = state-play_at;
  
  +   }
  
  if (time_before_eq(now, next_at) 
  
  (++events == 1 || time_before(next_at, earliest)))
  
  --
  1.9.0
  
  --
 
 @Michal: Is ff-memless-next also affected by this problem?
 
 Elias

I hope it's not, see mlnx_get_envelope_update_time(), this part in 
particular:

/* Prevent the effect from being started twice */
if (mlnxeff-begin_at == now  mlnx_is_playing(mlnxeff))
return now - 1;

return mlnxeff-begin_at;

Michal
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: [PATCH] input: ff-memless: don't schedule already playing effect to play again

2014-03-02 Thread Elias Vanderstuyft 
-- Forwarded message --
From: Michal Malý madcatxs...@prifuk.cz
Date: Sun, Mar 2, 2014 at 2:29 PM
Subject: Re: [PATCH] input: ff-memless: don't schedule already playing
effect to play again
To: Elias Vanderstuyft elias@gmail.com


On Sunday 02 of March 2014 14:17:58 you wrote:
 On Sun, Mar 2, 2014 at 12:35 PM, Felix Rueegg
felix.rue...@gmail.com wrote:
  When an effect with zero replay length, zero replay delay
  and zero envelope attack length is uploaded, it is played and then
  scheduled to play again one timer tick later. This triggers a
warning
  (URB submitted while active) in combination with the xpad driver.
 
  Skipping the rescheduling of this effect fixes the issue.
 
  Signed-off-by: Felix Rueegg felix.rue...@gmail.com
  ---
 
   drivers/input/ff-memless.c | 7 +--
   1 file changed, 5 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
  index 74c0d8c..2e06948 100644
  --- a/drivers/input/ff-memless.c
  +++ b/drivers/input/ff-memless.c
  @@ -139,10 +139,13 @@ static void ml_schedule_timer(struct
ml_device *ml)
 
  if (!test_bit(FF_EFFECT_STARTED, state-flags))
 
  continue;
 
  -   if (test_bit(FF_EFFECT_PLAYING, state-flags))
  +   if (test_bit(FF_EFFECT_PLAYING, state-flags)) {
 
  next_at = calculate_next_time(state);
 
  -   else
  +   if (next_at == now)
  +   continue;
  +   } else {
 
  next_at = state-play_at;
 
  +   }
 
  if (time_before_eq(now, next_at) 
 
  (++events == 1 || time_before(next_at, earliest)))
 
  --
  1.9.0
 
  --

 @Michal: Is ff-memless-next also affected by this problem?

 Elias

I hope it's not, see mlnx_get_envelope_update_time(), this part in
particular:

/* Prevent the effect from being started twice */
if (mlnxeff-begin_at == now  mlnx_is_playing(mlnxeff))
return now - 1;

return mlnxeff-begin_at;

Michal
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/