This patch introduces an additional parameter to xntimer_start for
specifying if the passed timeout value is relative (like now always) or
absolute. The idea is to simplify the setup of absolute timeouts which
have to be converted into relative ones so far.
All direct callers of xntimer_start are
Here comes another step to move xntimers closer to the hrtimer API of
the latest kernels. A hrtimer handler controls via its return value if
the timer should be restarted or not. This patch introduce a return
value to xntimer handlers as well: XNTIMER_DONE for leaving the timer
alone and
A simple patch, just like suggested by Gilles, to avoid looping over
periodic xntimer handlers in case of overruns.
It saves the current TSC on loop entry and uses this value later when
forwarding the timer. Is is the overhead of re-reading the TSC on all
archs negligible and should we rather go
Jan Kiszka wrote:
Hi,
instead of replying directly to Wolfgang's announcement of their great
CAN stack I take the chance to start a generic thread on the future of
RTDM drivers *within* Xenomai.
If you look at the real-time Linux scene now and in the past, you may
find it fairly scattered.
On Wed, 2006-08-02 at 20:06 +0200, Gilles Chanteperdrix wrote:
Bart Jonkers wrote:
On Wed, 2006-08-02 at 15:09 +0200, Gilles Chanteperdrix wrote:
Detlef Vollmann wrote:
I also added an interrupt handler on a button which is connected to
GPIO
pin. The interrupt handler
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi,
instead of replying directly to Wolfgang's announcement of their great
CAN stack I take the chance to start a generic thread on the future of
RTDM drivers *within* Xenomai.
If you look at the real-time Linux scene now and in the past, you
On Wed, 2006-08-02 at 20:06 +0200, Gilles Chanteperdrix wrote:
Bart Jonkers wrote:
On Wed, 2006-08-02 at 15:09 +0200, Gilles Chanteperdrix wrote:
Detlef Vollmann wrote:
I also added an interrupt handler on a button which is connected to
GPIO
pin. The interrupt handler
Bart Jonkers wrote:
Here is a new version of the ipipe-sa1100-pxa patch that unmaks
interrupts at the end of the demux handlers, and that attempt to fix the
gettimeoffset issue. I have run 20 minutes (time for OSCR to wrap) latency
with a test program verifying that time returned by
On Thu, 2006-08-03 at 15:18 +0200, Gilles Chanteperdrix wrote:
Bart Jonkers wrote:
Here is a new version of the ipipe-sa1100-pxa patch that unmaks
interrupts at the end of the demux handlers, and that attempt to fix the
gettimeoffset issue. I have run 20 minutes (time for OSCR to
On Wed, 2006-08-02 at 12:19 +0200, Jan Kiszka wrote:
Hi,
instead of replying directly to Wolfgang's announcement of their great
CAN stack I take the chance to start a generic thread on the future of
RTDM drivers *within* Xenomai.
If you look at the real-time Linux scene now and in the
Hi Wolfgang,
First of all, thx for the CAN stack. Great job.
On Thu, 2006-08-03 at 09:58 +0200, Wolfgang Grandegger wrote:
Jan Kiszka wrote:
snip
Now I would suggest to look at RTCAN (or what it will be called in the
end) and to discuss on this first concrete example how we can
Jan Kiszka wrote:
A simple patch, just like suggested by Gilles, to avoid looping over
periodic xntimer handlers in case of overruns.
It saves the current TSC on loop entry and uses this value later when
forwarding the timer. Is is the overhead of re-reading the TSC on all
archs
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
A simple patch, just like suggested by Gilles, to avoid looping over
periodic xntimer handlers in case of overruns.
It saves the current TSC on loop entry and uses this value later when
forwarding the timer. Is is the overhead of
13 matches
Mail list logo
