Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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. ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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 [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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. ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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. ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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. ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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 ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] [PATCH 3/3] Fix imx time reprogramming issue
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. ___ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
