On 09/02/09 11:35, Garrett D'Amore wrote: > 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. The expiration is also rounded up to 10 ms boundaries. So, it would be a random thing between 10 and 20 ms.
Since audio drivers require this, you can file a CR against ddi_periodic_add() and assign a high enough priority to it to get someone to fix that. Steve Sistare has shared some thoughts on how to fix the implementation with the original implementor. Maybe, with a priority CR, the original implementor may be willing to reimplement this based on your requirements. We can all add our thoughts to the CR and get someone to fix this. From a power management perspective as well, this interface does not work well. The tickless clock team will be thrilled to have someone work on this to fix it the way it should be fixed. Madhavan
