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

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

[Michael Trimarchi]

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);

Signed-off-by: Michael Trimarchi <michael@domain.hid>
Signed-off-by: Bruno Morelli <b.morelli@domain.hid>
---
 arch/arm/plat-mxc/time.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c
index aae2717..30916f8 100644
--- a/arch/arm/plat-mxc/time.c
+++ b/arch/arm/plat-mxc/time.c
@@ -400,11 +400,11 @@ mxc_timer_init(struct clk *timer_clk,
 	__ipipe_mach_timerint = irq;
 	__ipipe_mach_ticks_per_jiffy = (clk_get_rate(timer_clk) + HZ/2) / HZ;
 	tsc_info.freq = clk_get_rate(timer_clk);
-	mxc_min_delay = ((__ipipe_cpu_freq + 500000) / 1000000) ?: 1;
+	mxc_min_delay = 0xff;
 
 	if (timer_is_v1()) {
 		tsc_info.u.counter_paddr = phys + MX1_2_TCN;
-		tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN);
+		tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN);
 	} else {
 		tsc_info.u.counter_paddr = phys + V2_TCN;
 		tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN);
-- 
1.7.5.4

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |

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

[Gilles Chanteperdrix]

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.

-- 
                                                                Gilles.

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

[Michael Trimarchi]

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

Michael

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

[Gilles Chanteperdrix]

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.

> 
> Michael
> 


-- 
                                                                Gilles.

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

[Michael Trimarchi]

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

Michael

>>
>> Michael
>>
> 
> 


-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |

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

[Gilles Chanteperdrix]

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.

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

[Gilles Chanteperdrix]

On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote:
> 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.
> 
Ok, I have just pushed the changes to the 2.6 branch repository to
support I-pipe core on ARM.

So, the repository for xenomai is:
git://git.xenomai.org/xenoami-2.6.git branch master
and the repository for the core-3.2 ipipe series is:
git://git.denx.de/ipipe.git branch core-3.2

-- 
                                                                Gilles.

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

[Michael Trimarchi]

Hi Gilles

On 04/24/2012 10:34 PM, Gilles Chanteperdrix wrote:
> On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote:
>> 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.
>>
> Ok, I have just pushed the changes to the 2.6 branch repository to
> support I-pipe core on ARM.
> 
> So, the repository for xenomai is:
> git://git.xenomai.org/xenoami-2.6.git branch master
> and the repository for the core-3.2 ipipe series is:
> git://git.denx.de/ipipe.git branch core-3.2
> 

Thanks
I will rebase the the embedded board on top of the ipipe core-3.2 so I can
test again the ipipe layer.

Michael

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

[Gilles Chanteperdrix]

On 04/25/2012 10:12 AM, Michael Trimarchi wrote:
> Hi Gilles
> 
> On 04/24/2012 10:34 PM, Gilles Chanteperdrix wrote:
>> On 04/24/2012 11:41 AM, Gilles Chanteperdrix wrote:
>>> 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.
>>>
>> Ok, I have just pushed the changes to the 2.6 branch repository to
>> support I-pipe core on ARM.
>>
>> So, the repository for xenomai is:
>> git://git.xenomai.org/xenoami-2.6.git branch master
>> and the repository for the core-3.2 ipipe series is:
>> git://git.denx.de/ipipe.git branch core-3.2
>>
> 
> Thanks
> I will rebase the the embedded board on top of the ipipe core-3.2 so I can
> test again the ipipe layer.

Ok. In fact, please use the ipipe-core from this branch:
git://git.xenomai.org/ipipe-gch.git branch for-ipipe-3.2-arm, it is
generally more up to date for arm (in this case, it contains some fixes
for imx).

> 
> Michael
> 


-- 
                                                                Gilles.