Madhavan Venkataraman wrote:
> On 09/02/09 11:08, Garrett D'Amore wrote:
>> Madhavan Venkataraman wrote:
>>> On 09/01/09 17:31, Garrett D'Amore wrote:
>>>> Joerg Schilling wrote:
>>>>> Jerry Gilliam <jerry.gilliam at sun.com> wrote:
>>>>>
>>>>>
>>>>>> 2. Project Summary
>>>>>> 2.1. Project Description:
>>>>>> The tickless project aims at implementing the services
>>>>>> provided by the
>>>>>> clock cyclic in an event driven fashion. The first
>>>>>> sub-project is the
>>>>>> decoupling of the lbolt and lbolt64 variables from
>>>>>> clock(). These two
>>>>>> variables are incremented at each firing of the clock
>>>>>> cyclic and provide
>>>>>> a time reference to the system. They are being replaced
>>>>>> by two routines
>>>>>> that are backed by gethrtime(), the existing
>>>>>> ddi_get_lbolt() and
>>>>>> the new ddi_get_lbolt64(), introduced as a migration path
>>>>>> for existing
>>>>>> non-DDI compliant consumers.
>>>>>>
>>>>>
>>>>> If this results in being able to sleep with less than 10 ms
>>>>> granularity without
>>>>> setting a high-res tick, you get many + from me!
>>>>>
>>>>
>>>> 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. :-)
>>>>
>>>> - Garrett
>>>>
>>> The callout subsystem has been redesigned to support small and high
>>> resolution
>>> timers. The condition variable module has also been enhanced to make
>>> use of the
>>> high resolution timers. (see functions that end with _hires in
>>> condvar.c). However,
>>> this is not exported via DDI. If some consolidation private driver
>>> wants to cheat
>>> and use these interfaces (ugh), it can. But if you feel there is a
>>> real need, someone
>>> should work to export the hires CV interfaces to DDI. What I am
>>> saying is that
>>> the functionality is there. It just needs to be exported.
>>
>> Can I use fine grained timers with ddi_periodic()? Or is it still
>> only tick granularity?
> Unfortunately not. It only supports 10 millisecond granularity
> even if hires_tick is set. The interface itself accepts hrtime_t.
> But internally, the interval is rounded up to the nearest
> 10 ms boundary. That whole interface needs to be revisited and
> its implementation revamped. A whole timer subsystem has been
> implemented there with many issues. But that is a separate topic.
So what I need, at least for audio drivers, is a periodic style
interface that allows me to specify smaller time windows.
One more question: does the periodic reliably execute on 10 msec
boundaries, or is it just some random boundary between 10 and 20 msec?
For audio purposes, I can probably live with 10 msec *if* it is reliably
called at 100 Hz (+/- a reasonable margin of error -- say 1 msec). If
it is less frequent than that, or somewhat randomly timed, then it isn't
precise enough for audio purposes.
- Garrett
>
> Madhavan
