Hi everybody,
the recent patches are enclosed here. Mmm I haven't ported it to the
recent adeos-ipipe && xeno though but I guess it's not a big
obstacle for possible design-related comments etc.
just to note some main issues...
o the ipipe_virtualize_irq() interface now includes an additional
Philippe Gerum wrote:
[...]
Just one question: what's the reason why the periodic mode
is disabled by default ?
Because AFAICT, most people would rather use the aperiodic timing mode
in usual configurations for a much better accuracy. Since the periodic
mode uses the available hw PIT and pro
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Stefan Kisdaroczi wrote:
>>
>>> Hi,
>>>
>>> cant the timer be started by default ?
>>>
>>> The current state (2.0.1) seems to lead to the following scenario:
>>> 1) Every app calls rt_timer_start()
>>> 2) If you call rt_timer_stop you can hurt other r
Jan Kiszka wrote:
Stefan Kisdaroczi wrote:
Hi,
cant the timer be started by default ?
The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
call it
3) As some apps dont stop the
Stefan Kisdaroczi wrote:
> Hi,
>
> cant the timer be started by default ?
>
> The current state (2.0.1) seems to lead to the following scenario:
> 1) Every app calls rt_timer_start()
> 2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>call it
> 3) As some apps dont stop the ti
Hi,
cant the timer be started by default ?
The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
call it
3) As some apps dont stop the timer, check in 1) if its already running
I
Jan Kiszka wrote:
Hi,
this patches fixes the hint a user sees when trying to start some
RT-application without the related core service being available. Might
be frustrating for a newbie if the suggested command fails...
Applied, thanks.
Jan
---
Hannes Mayer wrote:
Jan Kiszka wrote:
[...]
Yea, maybe that periodic timer mode is not compiled in and
rt_timer_start fails in your original example. I think it's off by
default now.
Yeah, got it! Sorry for not supplying error code earlier!
In Xeno source:
int xnpod_start_timer (u_long nsti
Jan Kiszka wrote:
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
16:12:43.000
Hi everybody,
the recent patches are enclosed here. Mmm I haven't ported it to the
recent adeos-ipipe && xeno though but I guess it's not a big
obstacle for possible design-related comments etc.
just to note some main issues...
o the ipipe_virtualize_irq() interface now includes an additional
Jan Kiszka wrote:
>
>
> --- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig 2005-11-24
> 23:10:21.0 +0100
> +++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
> 16:12:43.0 +0100
> @@
Philippe Gerum wrote:
[...]
Just one question: what's the reason why the periodic mode
is disabled by default ?
Because AFAICT, most people would rather use the aperiodic timing mode
in usual configurations for a much better accuracy. Since the periodic
mode uses the available hw PIT and pro
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Stefan Kisdaroczi wrote:
>>
>>> Hi,
>>>
>>> cant the timer be started by default ?
>>>
>>> The current state (2.0.1) seems to lead to the following scenario:
>>> 1) Every app calls rt_timer_start()
>>> 2) If you call rt_timer_stop you can hurt other r
Jan Kiszka wrote:
Stefan Kisdaroczi wrote:
Hi,
cant the timer be started by default ?
The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
call it
3) As some apps dont stop the
Stefan Kisdaroczi wrote:
> Hi,
>
> cant the timer be started by default ?
>
> The current state (2.0.1) seems to lead to the following scenario:
> 1) Every app calls rt_timer_start()
> 2) If you call rt_timer_stop you can hurt other rt-apps, so dont
>call it
> 3) As some apps dont stop the ti
Hi,
cant the timer be started by default ?
The current state (2.0.1) seems to lead to the following scenario:
1) Every app calls rt_timer_start()
2) If you call rt_timer_stop you can hurt other rt-apps, so dont
call it
3) As some apps dont stop the timer, check in 1) if its already running
I
Jan Kiszka wrote:
Hi,
this patches fixes the hint a user sees when trying to start some
RT-application without the related core service being available. Might
be frustrating for a newbie if the suggested command fails...
Applied, thanks.
Jan
---
Hannes Mayer wrote:
Jan Kiszka wrote:
[...]
Yea, maybe that periodic timer mode is not compiled in and
rt_timer_start fails in your original example. I think it's off by
default now.
Yeah, got it! Sorry for not supplying error code earlier!
In Xeno source:
int xnpod_start_timer (u_long nsti
Jan Kiszka wrote:
Jan Kiszka wrote:
--- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24
23:10:21.0 +0100
+++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
16:12:43.000
Jan Kiszka wrote:
>
>
> --- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig 2005-11-24
> 23:10:21.0 +0100
> +++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28
> 16:12:43.0 +0100
> @@
Jan Kiszka wrote:
[...]
Yea, maybe that periodic timer mode is not compiled in and
rt_timer_start fails in your original example. I think it's off by
default now.
Yeah, got it! Sorry for not supplying error code earlier!
In Xeno source:
int xnpod_start_timer (u_long nstick, xnisr_t tickhandler
21 matches
Mail list logo