[Adeos-main] ipipe_request_tickdev issue

[Adeos-main] ipipe_request_tickdev issue

[Gilles Chanteperdrix]

Hi,

I found this out a long time ago on AT91 and worked around it but am
starting to see the same issue on hardware which hardware timer does not
wrap as fast: when xenomai calls ipipe_request_tickdev, the clockevent
structure max_delta_ns member is set to ULONG_MAX, but on most ARM
platforms, the reason for max_delta_ns is not only the timer hardware
limit, it is also necessary to call eg. update_sched_clock at least once
every max_delta_ns in order to avoid the hardware counter wrapping
without the system noticing it.

What do you think is the best way to avoid this issue? I would propose
simply removing the line which does:
	evtdev->max_delta_ns = ULONG_MAX;
in ipipe_request_tickdev, but maybe someone else sees a better solution.

-- 
                                                                Gilles.

Re: [Adeos-main] ipipe_request_tickdev issue

[Philippe Gerum]

On 02/11/2012 07:34 PM, Gilles Chanteperdrix wrote:
>
> Hi,
>
> I found this out a long time ago on AT91 and worked around it but am
> starting to see the same issue on hardware which hardware timer does not
> wrap as fast: when xenomai calls ipipe_request_tickdev, the clockevent
> structure max_delta_ns member is set to ULONG_MAX, but on most ARM
> platforms, the reason for max_delta_ns is not only the timer hardware
> limit, it is also necessary to call eg. update_sched_clock at least once
> every max_delta_ns in order to avoid the hardware counter wrapping
> without the system noticing it.
>
> What do you think is the best way to avoid this issue? I would propose
> simply removing the line which does:
> 	evtdev->max_delta_ns = ULONG_MAX;

Assuming we never go through clockevents_program_event() to program the 
next real-time shot, I don't see any issue killing this line in the 
current pipeline implementation. This said, it is unlikely that we would 
want to program delays larger than what the kernel defined as the 
maximum for the clock chip anyway.

> in ipipe_request_tickdev, but maybe someone else sees a better solution.
>


-- 
Philippe.