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 _______________________________________________ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
