[Xenomai-help] ARM I-pipe port to OMAP osk board

[Xenomai-help] ARM I-pipe port to OMAP osk board

[Mandar Thite]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Hi all,
Has anyone tried porting ARM ADEOS i-pipe patch to OMAP OSK board?

Although I haven't tried yet , may I ask if it is sufficient to follow
instructions given in howto Adapting the ARM I-pipe patch to a new
board<http://xenomai.org/index.php/I-pipe:ArmPorting>on XENOMAI site,
for getting the patch work correctly on this particular
board?

Please help.

Thanks and regards.

-Mandar

[-- Attachment #2: Type: text/html, Size: 467 bytes --]

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Gilles Chanteperdrix]

Mandar Thite wrote:
> Hi all,
> Has anyone tried porting ARM ADEOS i-pipe patch to OMAP OSK board?
> 
> Although I haven't tried yet , may I ask if it is sufficient to follow
> instructions given in howto Adapting the ARM I-pipe patch to a new
> board<http://xenomai.org/index.php/I-pipe:ArmPorting>on XENOMAI site,
> for getting the patch work correctly on this particular
> board?

Well, yes, we hope to have put as much information on this page as
needed. However, if that is not enough, you can still ask questions on
this list, or even better, on the adeos mailing list, we will answer if
we can help.

-- 
					    Gilles.

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Mandar Thite]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hello everyone,
I am trying to port I-pipe to OMAP5912 SoC. I have query related to follwing
snippet from the page <http://xenomai.org/index.php/I-pipe:ArmPorting>.

/****************

The timer interrupt handler should be modified in two ways:

   - first, if the timer interrupt needs to be acknowledged in some way
   (clearing a

flag in a hardware register, reading a status in a hardware register,
etc...), this acknowledgement must be put in __ipipe_mach_acktimer, because
when the timer is handled by Xenomai, timer interrupts will no longer get
handled by Linux timer interrupt handler.
*****************/

What I understood from this is, that __ipipe_mach_acktimer() should include
routine for letting the timer peripheral know that the interrupt generated
by it has been serviced so the peripheral can deassert the interrupt
request. But my datasheet says that interrupts generated by this peripheral
are edge sensitive. So does this fact make the function
__ipipe_mach_acktimer() dummy?
Thanks.---Mandar

On Wed, Dec 31, 2008 at 11:40 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Mandar Thite wrote:
> > Hi all,
> > Has anyone tried porting ARM ADEOS i-pipe patch to OMAP OSK board?
> >
> > Although I haven't tried yet , may I ask if it is sufficient to follow
> > instructions given in howto Adapting the ARM I-pipe patch to a new
> > board<http://xenomai.org/index.php/I-pipe:ArmPorting>on XENOMAI site,
> > for getting the patch work correctly on this particular
> > board?
>
> Well, yes, we hope to have put as much information on this page as
> needed. However, if that is not enough, you can still ask questions on
> this list, or even better, on the adeos mailing list, we will answer if
> we can help.
>
> --
>                                             Gilles.
>

[-- Attachment #2: Type: text/html, Size: 2575 bytes --]

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Gilles Chanteperdrix]

Mandar Thite wrote:
> Hello everyone,
> I am trying to port I-pipe to OMAP5912 SoC. I have query related to follwing
> snippet from the page <http://xenomai.org/index.php/I-pipe:ArmPorting>.
> 
> /****************
> 
> The timer interrupt handler should be modified in two ways:
> 
>    - first, if the timer interrupt needs to be acknowledged in some way
>    (clearing a
> 
> flag in a hardware register, reading a status in a hardware register,
> etc...), this acknowledgement must be put in __ipipe_mach_acktimer, because
> when the timer is handled by Xenomai, timer interrupts will no longer get
> handled by Linux timer interrupt handler.
> *****************/
> 
> What I understood from this is, that __ipipe_mach_acktimer() should include
> routine for letting the timer peripheral know that the interrupt generated
> by it has been serviced so the peripheral can deassert the interrupt
> request. But my datasheet says that interrupts generated by this peripheral
> are edge sensitive. So does this fact make the function
> __ipipe_mach_acktimer() dummy?
> Thanks.---Mandar

The acknowledgment done by __ipipe_mach_acktimer() is the
acknowledgement at hardware timer level, not at interrupt controller
level. You find this acknowledgement generally in Linux timer interrupt
code. For instance, for the omap 32k timer, implemented in
arch/arm/mach-omap1/timer32k.c, you would write:

void __ipipe_mach_acktimer(void)
{
	omap_32k_timer_ack_irq();
}

-- 
					    Gilles.

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Mandar Thite]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

Hi again,
Platform specific code for "clock_event_device" timer initialization in
"arch/arm/mach-omap1/time.c" is starting the timer in "autoreload mode" as
per "HZ" value. Is this ok for functioning of I-pipe or needs a
modification(i mean should it be started in "one shot mode")?
Thanks. ---Mandar

On Fri, Jan 23, 2009 at 12:44 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Mandar Thite wrote:
> > Hello everyone,
> > I am trying to port I-pipe to OMAP5912 SoC. I have query related to
> follwing
> > snippet from the page <http://xenomai.org/index.php/I-pipe:ArmPorting>.
> >
> > /****************
> >
> > The timer interrupt handler should be modified in two ways:
> >
> >    - first, if the timer interrupt needs to be acknowledged in some way
> >    (clearing a
> >
> > flag in a hardware register, reading a status in a hardware register,
> > etc...), this acknowledgement must be put in __ipipe_mach_acktimer,
> because
> > when the timer is handled by Xenomai, timer interrupts will no longer get
> > handled by Linux timer interrupt handler.
> > *****************/
> >
> > What I understood from this is, that __ipipe_mach_acktimer() should
> include
> > routine for letting the timer peripheral know that the interrupt
> generated
> > by it has been serviced so the peripheral can deassert the interrupt
> > request. But my datasheet says that interrupts generated by this
> peripheral
> > are edge sensitive. So does this fact make the function
> > __ipipe_mach_acktimer() dummy?
> > Thanks.---Mandar
>
> The acknowledgment done by __ipipe_mach_acktimer() is the
> acknowledgement at hardware timer level, not at interrupt controller
> level. You find this acknowledgement generally in Linux timer interrupt
> code. For instance, for the omap 32k timer, implemented in
> arch/arm/mach-omap1/timer32k.c, you would write:
>
> void __ipipe_mach_acktimer(void)
> {
>        omap_32k_timer_ack_irq();
> }
>
> --
>                                             Gilles.
>

[-- Attachment #2: Type: text/html, Size: 2799 bytes --]

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Gilles Chanteperdrix]

Mandar Thite wrote:
> Hi again,
> Platform specific code for "clock_event_device" timer initialization in
> "arch/arm/mach-omap1/time.c" is starting the timer in "autoreload mode" as
> per "HZ" value. Is this ok for functioning of I-pipe or needs a
> modification(i mean should it be started in "one shot mode")?
> Thanks. ---Mandar

Xenomai requires one shot mode.

-- 
					    Gilles.

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Mandar Thite]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Hi Gilles,

I have a problem in following paragraph...

/**********
a function is expected to update the tsc area from time to time (at least
once before the underlying counter reaches the same value again, in order to
avoid losing some wrap arounds). If the free-running counter wraps fast, the
best place to do this is __ipipe_mach_acktimer. If the free-running counter
wraps slowly, doing this from Linux timer interrupt will reduce the timer
interrupt latency.
**********/

How do I decide if, for my platform, "free-running counter" wraps fast or
slow? Or iow, what does it depend upon?

On Fri, Jan 23, 2009 at 3:40 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Mandar Thite wrote:
> > Hi again,
> > Platform specific code for "clock_event_device" timer initialization in
> > "arch/arm/mach-omap1/time.c" is starting the timer in "autoreload mode"
> as
> > per "HZ" value. Is this ok for functioning of I-pipe or needs a
> > modification(i mean should it be started in "one shot mode")?
> > Thanks. ---Mandar
>
> Xenomai requires one shot mode.
>
> --
>                                             Gilles.
>

[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Philippe Gerum]

Mandar Thite wrote:
> Hi Gilles,
> 
> I have a problem in following paragraph...
> 
> /**********
> a function is expected to update the tsc area from time to time (at
> least once before the underlying counter reaches the same value again,
> in order to avoid losing some wrap arounds). If the free-running counter
> wraps fast, the best place to do this is __ipipe_mach_acktimer. If the
> free-running counter wraps slowly, doing this from Linux timer interrupt
> will reduce the timer interrupt latency.
> **********/
> 
> How do I decide if, for my platform, "free-running counter" wraps fast
> or slow? Or iow, what does it depend upon?
>

If you need someone to explain what a free running counter is, or why a
timer-related counter may wrap fast or slow, then I'm afraid there is no way you
could achieve your port before hell freezes. Make everyone a favor, do your
homework first, please.

Besides, the least you could do is attaching your code since you want people to
help with it. A good practice is to send the current state of your work as a
patch with your initial question so that people understand where you are at this
point, then update the list with improved releases of this work from time to
time, as progress is made. This would clear a rather irritating feeling we have
that you are offloading your work to the list.

> On Fri, Jan 23, 2009 at 3:40 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> 
>     Mandar Thite wrote:
>     > Hi again,
>     > Platform specific code for "clock_event_device" timer
>     initialization in
>     > "arch/arm/mach-omap1/time.c" is starting the timer in "autoreload
>     mode" as
>     > per "HZ" value. Is this ok for functioning of I-pipe or needs a
>     > modification(i mean should it be started in "one shot mode")?
>     > Thanks. ---Mandar
> 
>     Xenomai requires one shot mode.
> 
>     --
>                                                Gilles.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] ARM I-pipe port to OMAP osk board

[Mandar Thite]

[-- Attachment #1: Type: text/plain, Size: 2883 bytes --]

Hello,
Let me first express my sincere apologies to Gilles, Philippe and everyone
contributing to this mailing list, for inadvertently making a nuisance of
myself.

Not that I don't have clear theoretical aspects, but I might have mistaken
in putting the question in right manner, for, being a newcomer to this area.
Please forgive me for that. Henceforth, I will certainly make it a point to
think twice before posting to the list.

Thanks.
-Mandar

On Fri, Jan 23, 2009 at 3:16 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> Mandar Thite wrote:
> > Hi Gilles,
> >
> > I have a problem in following paragraph...
> >
> > /**********
> > a function is expected to update the tsc area from time to time (at
> > least once before the underlying counter reaches the same value again,
> > in order to avoid losing some wrap arounds). If the free-running counter
> > wraps fast, the best place to do this is __ipipe_mach_acktimer. If the
> > free-running counter wraps slowly, doing this from Linux timer interrupt
> > will reduce the timer interrupt latency.
> > **********/
> >
> > How do I decide if, for my platform, "free-running counter" wraps fast
> > or slow? Or iow, what does it depend upon?
> >
>
> If you need someone to explain what a free running counter is, or why a
> timer-related counter may wrap fast or slow, then I'm afraid there is no
> way you
> could achieve your port before hell freezes. Make everyone a favor, do your
> homework first, please.
>
> Besides, the least you could do is attaching your code since you want
> people to
> help with it. A good practice is to send the current state of your work as
> a
> patch with your initial question so that people understand where you are at
> this
> point, then update the list with improved releases of this work from time
> to
> time, as progress is made. This would clear a rather irritating feeling we
> have
> that you are offloading your work to the list.
>
> > On Fri, Jan 23, 2009 at 3:40 AM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org
> > <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> >
> >     Mandar Thite wrote:
> >     > Hi again,
> >     > Platform specific code for "clock_event_device" timer
> >     initialization in
> >     > "arch/arm/mach-omap1/time.c" is starting the timer in "autoreload
> >     mode" as
> >     > per "HZ" value. Is this ok for functioning of I-pipe or needs a
> >     > modification(i mean should it be started in "one shot mode")?
> >     > Thanks. ---Mandar
> >
> >     Xenomai requires one shot mode.
> >
> >     --
> >                                                Gilles.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
>
>
> --
> Philippe.
>

[-- Attachment #2: Type: text/html, Size: 4130 bytes --]