Casper.Dik at Sun.COM wrote:
>> Actually, I could really use the ability to use a timer based service
>> that had a smaller window than 10 msec. For example, many audio devices
>> have crummy interrupt capabilities... its a lot nicer (smoother audio)
>> if I have a reliable way to get a periodic running at smaller
>> intervals. (5 to 10 msec, but with precision -- the current stuff is
>> simply too coarse.)
>>
>> This would simplify a lot of audio device drivers. And make them more
>> robust as well. :-)
>>
>
>
> Do they work better if you set "hz" to 1000? (hires_tick)?
>
> I remember that some devices failed to work when you set hz to 1000
> such as the audio in the Ultra 45 (since fixed) but this was because of
> bad code.
>
> If your driver wants to sleep a short amount of time AND that time is
> less then 10ms, that code is hardly ever tested.
>
> (We should vet all the uses of drv_usectohz() and more sure that the
> argument is at least 10000 or that we have an actual reason that we might
> want to sleep less)
>
Yes. There are times when drivers need to sleep for a while to account
for chip requirements. Anytime I am faced with a chip based requirement
of over 500 usec or so, I will try to use delay() if it works in the
context I'm in, to avoid burning CPU cycles on a spin loop. This
typically happens during device initialization, such as post firmware
initialization delays or during 802.3 autonegotiation.
In those cases, we probably *could* just bump the timer up to 1000 usec,
but wouldn't it be easier to just verify with tick = 1000?
-- Garrett
> Casper
>
>
