Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 04/24/2012 11:31 AM, Michael Trimarchi wrote:
> Hi
> 
> On 04/24/2012 10:53 AM, Gilles Chanteperdrix wrote:
>> On 04/24/2012 10:32 AM, Michael Trimarchi wrote:
>>> On 04/24/2012 10:13 AM, Gilles Chanteperdrix wrote:
>>>> On 04/24/2012 10:09 AM, Michael Trimarchi wrote:
>>>>> This patch includes:
>>>>> 
>>>>> * Fix invalid virtual address base of MX1_2_TCM * Fix the
>>>>> minimum delay below which the hardware timer can not be
>>>>> reprogrammed. The value is the same of that one that is used
>>>>> to calculate the min_delta_ns
>>>>> 
>>>>> arch/arm/plat-mxc/time.c 414: clockevent_mxc.min_delta_ns =
>>>>> clockevent_delta2ns(0xff, &clockevent_mxc);
>>>> 
>>>> I do not think we can use this value, it is way to high for
>>>> xenomai needs. In latest releases we use 2us instead of 1us,
>>>> and according to what a user posted recently, this should be
>>>> enough, could you test with 2us? And 2us is already what we
>>>> have in the 3.2 repository.
>>>> 
>>> As I understood the min delays is in tick and not depend on the
>>> clock rate.
>>> 
>>> This is from atmel at91_ipipe_time
>>> 
>>> min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns *
>>> clkevt.mult) >> clkevt.shift;
>>> 
>>> this is exaclty the reverse calculation of
>>> clockevent_mxc.min_delta_ns
>>> 
>>> I have already the result in the previous calculation: 0xff is
>>> the minimun in ticks
>> 
>> 0xff is too large, it corresponds to 30us on some platforms, could
>> you please try with 2us? The delay is given as a count of ticks or
>> as a duration in ns depending on the architecture, it does not
>> really matter.
>> 
> 
> Ok, with 0x85 is working (2 uS). I don't find in the documentation
> the min_delta_ns for this architecture. I will rebase the patch on
> core-3.2

This is not really a specified constant, finding this minimum value is
more of a hit and miss. Anyway, on core 3.2, the timers have been
substantially reworked, and we are able to reuse the clockevent callback
which has a safety mechanism in addition to the minimum value to avoid
loosing ticks (in short, the timer is re-read after programming it, and
if the delay has already passed, the callback returns a negative value,
which the timer subsystem uses to trigger the irq).

Core-3.2 is not yet supported on ARM for xenomai 2.6. I will do the
changes and keep you informed.

-- 
					    Gilles.