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