[alsa-devel] [patch] snd-pcsp fixes

[Takashi Iwai]

At Fri, 30 Oct 2009 15:22:39 +0300,
Stas Sergeev wrote:
> 
> Hi.
> 
> Takashi Iwai wrote:
> > I applied the patch now as is, as I suppose you tested it well :)
> Well, no! :) I only tested it on 2
> machines yet. Please give it more
> testing if you can.

OK, will check later.  But I think it should be irrelevant with
machine since it's the core part of hrtimer.

> > I don't remember exactly the changes for pcsp driver right now,
> > but the change of the initial delay was due to the change of start
> > logic.  At least, at the time HRTIMER_CB_IRQSAFE was removed, starting
> > with zero didn't work at all on my machine.  Maybe something got fixed
> > in the core side.
> OK, it would be nice if you can check
> whether or not the problem is there on
> that particular machine...

Maybe I have no more that machine.  Anyway, more testing would be
needed.

> > But, I still don't understand why it has to be zero.  The first
> > bit-flip is done inside the trigger-start, so the next wakeup should
> > be after the calculated ns.  Isn't it?
> That was the logic you invented, but
> initially, and with my patch, there
> is no bitflip on start trigger. Or,
> at least, not supposed to be - there
> was only a timer mode setup, or if not -
> that was a bug. :)

OK, then we should revert the zero-delay logic again.
The zero-delay start means to do the bitflip again immediately.
This is wrong, of course.

> Also, you added some caching variables:
> 
> +       unsigned int fmt_size;
> +       unsigned int is_signed;
> 
> What was the intention? Is this a speed-up?
> If not - reverting that too?

It's for speeding up.  We should minimize any calculations in the
hrtimer callback.


thanks,

Takashi