HPET mmap() problem

HPET mmap() problem

[Jussi Laako]

Hi,

In the JACK audio connection kit we have support for mmap() of /dev/hpet
as our time source (as one of the possibilities). However, there's a
nasty issue with the current driver as it reserves one of the three
comparator-timers per each open() and denies further opens when the
timers are exhausted. And in case it's already used as a system clock
source, two of the timers are already reserved...

However, we are only interested on the main counter value, and would
like to have unlimited access from number of processes to this value
through mmap() of the device.

Any ideas/recommendations/suggestions on which way to change the driver
to support this? Or even better, if someone is already working on this?


Best regards,

	- Jussi

Re: HPET mmap() problem

[Clemens Ladisch]

Jussi Laako wrote:
> In the JACK audio connection kit we have support for mmap() of /dev/hpet
> as our time source (as one of the possibilities). However, there's a
> nasty issue with the current driver as it reserves one of the three
> comparator-timers per each open() and denies further opens when the
> timers are exhausted. And in case it's already used as a system clock
> source, two of the timers are already reserved...
> 
> However, we are only interested on the main counter value, and would
> like to have unlimited access from number of processes to this value
> through mmap() of the device.
> 
> Any ideas/recommendations/suggestions on which way to change the driver
> to support this?

Don't allocate a hpet_dev in hpet_open but when hpet_ioctl is called for
the first time.

> Or even better, if someone is already working on this?

I'm planning to work on this.


HTH
Clemens