At Fri, 30 Oct 2009 17:23:09 +0300, Stas Sergeev wrote:
Takashi Iwai wrote:
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.
What do you mean? As I said above, there seems to be no first bitflip on a start trigger, neither initially, nor with my current patch. There was only the timer _mode_ setup, the GATE input of the timer was not supposed to be touched. The logic you invented, OTOH, does the first bitflip there, and then advances the timer, which is also correct, but is more complicated. Do you think there was a bug that actually did the first bitflip anyway?
The problem was that the first call with zero delay didn't happen and hrtimer stopped totally on my tests. So, it had to be implemented in my way.
I'm not sure whether this was fixed. Keep testing on your other machines as I have really no time for checking this at all for the time being. Still over 8,000 mails left in my inbox.
thanks,
Takashi