Hello all,
I am implementing a driver for a set of hardware countdown timers and I have
a few questions as to how this device's interface should be approached.
Background on the device:
Actually, there are several implementations of this hardware that I must
support, but here are the basics that they all have in common.
The device contains several countdown timers. A count is loaded into the
device,
the timer is enabled, the timer counts down to 0 at which point it fires an
interrupt, reloads the counter to the original value, and so on....
To be clear, this device differs from the rtc device in the following ways:
1. RTC tracks date/time of day. The countdown timer device is not aware of
date/time.
2. There are multiple countdown timers.
3. Each countdown timer may/may not have programmable clock rates and the
rates available vary from device to device. Some have software selectable
rates and others have rates selectable by jumpers.
4. Countdown timers don't have update or alarm interrupt modes.
5. One may still want to use /dev/rtc alongside the countdown timers.
Questions:
1. Is there already a standard kernel interface to this type of timer?
2. Is there any reason to interface/integrate this type of device with the
high-res timer stuff currently under development for the 2.5 kernel?
Assuming there is not a standard and this device should be handled separate
from the high-res timer/posix timer stuff I am proposing this interface:
Goals:
1. Hide the complexity of each device (counter sizes, clock rates, etc...)
so the user has a simple and consistent interface regardless of the
particular hardware implementation.
2. Programmable to nanosecond resolution (limited by the resolution of the
individual devices of course).
3. Ability to set a timeout value of reasonable magnitude. I.e. programming
a device using a 32-bit int value corresponding to number of nanoseconds
is not a sufficiently large timeout value.
The driver registers /dev/timer0, /dev/timer1, etc... for each timer device.
Obviously a major number would need to be assigned to the /dev/timer device.
The following ioctls would exist:
#define TIMER_LOAD_COUNT _IOW('t', 1, struct timespec)
#define TIMER_GET_COUNT _IOR('t', 2, struct timespec)
#define TIMER_START _IO('t', 3)
#define TIMER_STOP _IO('t', 4)
A read blocks until an interrupt occurs unless interrupts are already
pending. The read returns number of interrupts since the last read so
pileups can be
detected. Select would also be implemented.
An alternative approach would be this:
Writing a value in the form of struct timespec loads and starts the counter.
Writing a struct timespec with a value of 0 stops the timer.
A read returns struct timespec with the current timer value.
Interrupts are received using the select function. The driver would respond
to
the select with POLLPRI when the count had expired.
Comments?
> Questions:
> 1. Is there already a standard kernel interface to this type of timer?
The Posix high-res timer stuff, I think. Have you tried expressing
what you want user programs to do in terms of Posix high-res timers yet?
> 2. Is there any reason to interface/integrate this type of device with the
> high-res timer stuff currently under development for the 2.5 kernel?
Yes; perhaps you could create a service provider interface
for the posix high-res timer stuff, then use that SPI
to plug your hardware in?
I may be way off base here, but it does seem like it's due dilligence
to verify that you're not reinventing an interface here.
- Dan
> > Questions:
> > 1. Is there already a standard kernel interface to this
> type of timer?
>
> The Posix high-res timer stuff, I think. Have you tried expressing
> what you want user programs to do in terms of Posix high-res
> timers yet?
>
> > 2. Is there any reason to interface/integrate this type of
> device with the
> > high-res timer stuff currently under development for the
> 2.5 kernel?
>
> Yes; perhaps you could create a service provider interface
> for the posix high-res timer stuff, then use that SPI
> to plug your hardware in?
>
> I may be way off base here, but it does seem like it's due dilligence
> to verify that you're not reinventing an interface here.
Yes, the first intent of this request is to see if there is a suitable
interface already available.
I will follow up about the service provider interface on the high-res timer
list.
Thanks.
Dan Kegel wrote:
>
> > Questions:
> > 1. Is there already a standard kernel interface to this type of timer?
>
> The Posix high-res timer stuff, I think. Have you tried expressing
> what you want user programs to do in terms of Posix high-res timers yet?
>
> > 2. Is there any reason to interface/integrate this type of device with the
> > high-res timer stuff currently under development for the 2.5 kernel?
>
> Yes; perhaps you could create a service provider interface
> for the posix high-res timer stuff, then use that SPI
> to plug your hardware in?
>
> I may be way off base here, but it does seem like it's due dilligence
> to verify that you're not reinventing an interface here.
> - Dan
>
Let me help out here if I may. First, not to rain on your
parade but, when I did high-res timers on another system,
far away and long ago, we dropped support for the hardware
timers. I.e. I would submit that the POSIX timers interface
to a common system timer does all you need and more. You
MAY want to consider using your hardware as the system clock
underlying jiffies and all the system timers, but that is
another issue.
You also may want to define a new CLOCK for the POSIX
timers. Most of this capability is in place in the current
patch. I did notice, however, that I took a short cut on
the clock_nanosleep code and assumed that it was a standard
clock. This is easy to change... The new CLOCK(s) would
then talk to your hardware. The problem you will encounter,
and which the high-res-patch solves, is making the timers
available to all comers, i.e. there is no reservation system
or busy counter, etc. Just a nice set timer and give me a
signal when it is done.
You can code a blocking interface using the sigwait and
friends calls which will also cut down of the timer delivery
overhead by eliminating the signal.
So what more could you ask for?
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
> >
> > > Questions:
> > > 1. Is there already a standard kernel interface to this
> type of timer?
> >
> > The Posix high-res timer stuff, I think. Have you tried expressing
> > what you want user programs to do in terms of Posix
> high-res timers yet?
> >
> > > 2. Is there any reason to interface/integrate this type
> of device with the
> > > high-res timer stuff currently under development for
> the 2.5 kernel?
> >
> > Yes; perhaps you could create a service provider interface
> > for the posix high-res timer stuff, then use that SPI
> > to plug your hardware in?
> >
> > I may be way off base here, but it does seem like it's due
> dilligence
> > to verify that you're not reinventing an interface here.
> > - Dan
> >
> Let me help out here if I may. First, not to rain on your
> parade but, when I did high-res timers on another system,
> far away and long ago, we dropped support for the hardware
> timers. I.e. I would submit that the POSIX timers interface
> to a common system timer does all you need and more.
I suspect that is most often the case. My task, working for an OEM,
is to provide access to the available hardware. The customer's decide
if the hardware is appropriate to their needs, and still many customers
are demanding access to these devices. I am going to try to do a study
on whether additional hardware timers are of any benefit given the
resources available on current standard hardware and the availability of
the high-res patch, but the additional hardware is probably still going
to be available because it is needed on others OS's.
> You MAY want to consider using your hardware as the system clock
> underlying jiffies and all the system timers, but that is
> another issue.
>
> You also may want to define a new CLOCK for the POSIX
> timers. Most of this capability is in place in the current
> patch. I did notice, however, that I took a short cut on
> the clock_nanosleep code and assumed that it was a standard
> clock. This is easy to change... The new CLOCK(s) would
> then talk to your hardware. The problem you will encounter,
> and which the high-res-patch solves, is making the timers
> available to all comers, i.e. there is no reservation system
> or busy counter, etc. Just a nice set timer and give me a
> signal when it is done.
>
Hmmm, that sounds promising.
> You can code a blocking interface using the sigwait and
> friends calls which will also cut down of the timer delivery
> overhead by eliminating the signal.
Very good.
> So what more could you ask for?
I've already sent Santa my list.
Thanks for the advice.