On 03/13/2012 07:32 AM, 马强 wrote:
> Hi, Gilles.
>
> I could not find "mxc_min_delay = 0xff" in linux source tree
> and xenomai directory. mxc_min_delay comes from ipipe,
> there is also no such statement in latest patch downloaded
> from website.
>
> If mxc_min_delay is 0xff, in my system this means 32us for 8MHz
> ipipe tsc. For a real time system, It seems a little bit longer.
>
> I used mxc_min_delay=16(2us) to do a test during last weekend,
> until now and no stall have happened again. So mxc_min_delay = 0x10
> maybe enough for my test CPU, I can't decide which value should be used.
Linux uses a similar mechanism for its clock_event_device named
min_delta_ns. In latest releases min_delta_ns is set such that it
corresponds to 0xff ticks. But you are right: this value is too large
for xenomai.
>
> The following code copy from the time.c file that patched by xenomai.
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> if (delay > mxc_min_delay) {
> unsigned long tcmp;
>
> if (!timer_is_v2()) {
> tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
> __raw_writel(tcmp, timer_base + MX1_2_TCMP);
> } else {
> tcmp = __raw_readl(timer_base + V2_TCN) + delay;
> __raw_writel(tcmp, timer_base + V2_TCMP);
> }
> } else
> ipipe_trigger_irq(__ipipe_mach_timerint);
> }
>
> My question is whether this function will be interrupted by other high
> priority interrupts.
No, this function is called with hardware irqs off.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
