[Adeos-main] Porting to Intel IXP425

[Adeos-main] Porting to Intel IXP425

[Richard Cochran]

I am porting to the IXP425 using adeos-ipipe-2.6.19-arm-1.6-04.patch.

Apart from the code itself, I guess that there is nothing written
about what the bits in mach-xxx must do. If I am wrong, please point
me in the right direction.

Looking at __ipipe_mach_irq_mux_p and __ipipe_mach_demux_irq:

The 'mux_p' seems to identify one of the IRQs, and this IRQ is special
in some way. The 'mux' here stands for 'multiplex', I guess. But what
exactly is the meaning of this macro?

The purpose of 'demux_irq' appears to be to check the interrupt
controller for all pending interrupts, and feed them back to the ipipe
via '__ipipe_handle_irq'. Is that right?

Thanks,
Richard


************************************************************************
***
Richard Cochran (Mr), Software Development
OMICRON electronics GmbH, Oberes Ried 1, A-6833 Klaus / Austria
Tel.: +43 5523 507 425, Fax.: +43 5523 507 7425
http://www.omicron.at/         mailto:richard.cochran@domain.hid
************************************************************************
***

Re: [Adeos-main] Porting to Intel IXP425

[Sebastian Smolorz]

Richard Cochran wrote:
> Looking at __ipipe_mach_irq_mux_p and __ipipe_mach_demux_irq:
>
> The 'mux_p' seems to identify one of the IRQs, and this IRQ is special
> in some way. The 'mux' here stands for 'multiplex', I guess. But what
> exactly is the meaning of this macro?

It has to determine whether a given IRQ is cascaded and therefore must be 
specially serviced WRT acknowledging. The required acknowledging of 
IRQ-subchannels is done in __ipipe_mach_demux_irq together with the call of 
__ipipe_handle_irq() after having determined the correct IRQ number where 
necessary.

-- 
Sebastian

Re: [Adeos-main] Porting to Intel IXP425

[Gilles Chanteperdrix]

Sebastian Smolorz wrote:
> Richard Cochran wrote:
> 
>>Looking at __ipipe_mach_irq_mux_p and __ipipe_mach_demux_irq:
>>
>>The 'mux_p' seems to identify one of the IRQs, and this IRQ is special
>>in some way. The 'mux' here stands for 'multiplex', I guess. But what
>>exactly is the meaning of this macro?
> 
> 
> It has to determine whether a given IRQ is cascaded and therefore must be 
> specially serviced WRT acknowledging. The required acknowledging of 
> IRQ-subchannels is done in __ipipe_mach_demux_irq together with the call of 
> __ipipe_handle_irq() after having determined the correct IRQ number where 
> necessary.
> 

Right. And I think the IXP425 has no cascaded IRQ, so you can define
__ipipe_mach_irq_mux_p to 0, and do not have to implement
__ipipe_mach_demux_irq.

-- 
                                                 Gilles Chanteperdrix

RE: [Adeos-main] Porting to Intel IXP425

[Richard Cochran]

> Right. And I think the IXP425 has no cascaded IRQ, so you can define
> __ipipe_mach_irq_mux_p to 0, and do not have to implement
> __ipipe_mach_demux_irq.

That was easy.

(The IXP425 has no cascaded interrupts.)

Now, about the rest, by reading the other arm ports, I learned the
following:

__ipipe_mach_get_dec()

Returns the periodic timer interval in HW ticks.

__ipipe_mach_set_dec()

Sets the periodic timer interval.

__ipipe_mach_get_tsc()

Returns the free flowing time stamp register as a 64 bit integer.

__ipipe_mach_acktimer()

Called by the timer ISR, clears the timer interrupt.

__ipipe_mach_release_timer()

Restores the timer interval to the value expected by Linux.


Did I get it right?

Thanks,
Richard

Re: [Adeos-main] Porting to Intel IXP425

[Gilles Chanteperdrix]

Richard Cochran wrote:
>>Right. And I think the IXP425 has no cascaded IRQ, so you can define
>>__ipipe_mach_irq_mux_p to 0, and do not have to implement
>>__ipipe_mach_demux_irq.
> 
> 
> That was easy.
> 
> (The IXP425 has no cascaded interrupts.)
> 
> Now, about the rest, by reading the other arm ports, I learned the
> following:
> 
> __ipipe_mach_get_dec()
> 
> Returns the periodic timer interval in HW ticks.
> 
> __ipipe_mach_set_dec()
> 
> Sets the periodic timer interval.

The timer is aperiodic (most of the time) when running Xenomai, so
__ipipe_mach_set_dec is called for each timer tick and programs the
timer hardware for the next tick.

> 
> __ipipe_mach_get_tsc()
> 
> Returns the free flowing time stamp register as a 64 bit integer.
> 
> __ipipe_mach_acktimer()
> 
> Called by the timer ISR, clears the timer interrupt.
> 
> __ipipe_mach_release_timer()
> 
> Restores the timer interval to the value expected by Linux.

__ipipe_mach_release_timer is called when Xenomai stops handling the
timer and let Linux handle it.


-- 
                                                 Gilles Chanteperdrix

RE: [Adeos-main] Porting to Intel IXP425

[Richard Cochran]

> The timer is aperiodic (most of the time) when running Xenomai, so
> __ipipe_mach_set_dec is called for each timer tick and programs the
> timer hardware for the next tick.

Okay, so does that mean that I should implement a "one-shot" timer, or
are we talking about resetting the periodic timer once in a while?

(BTW, in one-shot mode, the IXP425 timer does not do what the Developers
Manual, part 252480-006, says that it does!)

> __ipipe_mach_release_timer is called when Xenomai stops handling the
> timer and let Linux handle it.

But why does Xenomai do this? When unloading the module?


Richard

Re: [Adeos-main] Porting to Intel IXP425

[Gilles Chanteperdrix]

Richard Cochran wrote:
>>The timer is aperiodic (most of the time) when running Xenomai, so
>>__ipipe_mach_set_dec is called for each timer tick and programs the
>>timer hardware for the next tick.
> 
> 
> Okay, so does that mean that I should implement a "one-shot" timer, or
> are we talking about resetting the periodic timer once in a while?
> 
> (BTW, in one-shot mode, the IXP425 timer does not do what the Developers
> Manual, part 252480-006, says that it does!)

Yes, the one shot mode is Xenomai default mode. The implementation of a
periodic timer over the one-shot timer is already done by the generic
ARM part of the Adeos patch.

> 
> 
>>__ipipe_mach_release_timer is called when Xenomai stops handling the
>>timer and let Linux handle it.
> 
> 
> But why does Xenomai do this? When unloading the module?

Yes, exactly.

-- 
                                                 Gilles Chanteperdrix

Re: [Adeos-main] Porting to Intel IXP425

[Philippe Gerum]

On Fri, 2007-03-30 at 16:05 +0200, Gilles Chanteperdrix wrote:
> Richard Cochran wrote:
> >>Right. And I think the IXP425 has no cascaded IRQ, so you can define
> >>__ipipe_mach_irq_mux_p to 0, and do not have to implement
> >>__ipipe_mach_demux_irq.
> > 
> > 
> > That was easy.
> > 
> > (The IXP425 has no cascaded interrupts.)
> > 
> > Now, about the rest, by reading the other arm ports, I learned the
> > following:
> > 
> > __ipipe_mach_get_dec()
> > 
> > Returns the periodic timer interval in HW ticks.
> > 
> > __ipipe_mach_set_dec()
> > 
> > Sets the periodic timer interval.
> 
> The timer is aperiodic (most of the time) when running Xenomai,

Moreover, Xenomai 2.4 (i.e. our current development trunk/) will always
drive the timer chip in oneshot mode. Periodic mode is emulated over
aperiodic ticks there.

>  so
> __ipipe_mach_set_dec is called for each timer tick and programs the
> timer hardware for the next tick.
> 
> > 
> > __ipipe_mach_get_tsc()
> > 
> > Returns the free flowing time stamp register as a 64 bit integer.
> > 
> > __ipipe_mach_acktimer()
> > 
> > Called by the timer ISR, clears the timer interrupt.
> > 
> > __ipipe_mach_release_timer()
> > 
> > Restores the timer interval to the value expected by Linux.
> 
> __ipipe_mach_release_timer is called when Xenomai stops handling the
> timer and let Linux handle it.
> 
> 
-- 
Philippe.

RE: [Adeos-main] Porting to Intel IXP425

[Richard Cochran]

Just to be clear, does __ipipe_mach_get_dec() return the _dialed_
number of ticks, or the _remaining_ number of ticks?

Thanks again,
Richard

Re: [Adeos-main] Porting to Intel IXP425

[Gilles Chanteperdrix]

Richard Cochran wrote:
> Just to be clear, does __ipipe_mach_get_dec() return the _dialed_
> number of ticks, or the _remaining_ number of ticks?

__ipipe_mach_get_dec() is supposed to return the number of remaining ticks.

-- 
                                                 Gilles Chanteperdrix

[Adeos-main] Re: Porting to Intel IXP425

[Schlägl Manfred jun.]

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

Am Freitag, den 30.03.2007, 16:41 +0200 schrieb Gilles Chanteperdrix:
> Richard Cochran wrote:
> >>The timer is aperiodic (most of the time) when running Xenomai, so
> >>__ipipe_mach_set_dec is called for each timer tick and programs the
> >>timer hardware for the next tick.
> > 
> > 
> > Okay, so does that mean that I should implement a "one-shot" timer, or
> > are we talking about resetting the periodic timer once in a while?
> > 
> > (BTW, in one-shot mode, the IXP425 timer does not do what the Developers
> > Manual, part 252480-006, says that it does!)
> 
> Yes, the one shot mode is Xenomai default mode. The implementation of a
> periodic timer over the one-shot timer is already done by the generic
> ARM part of the Adeos patch.

It's better to use a periodic implementation in background, because then
you are able to messure the lost ticks between a timer-interrupt and
programming next timer-event.

Example with 16bit timer:
 * Periode: 27000 Ticks 
 * Timer counts down to zero (Interrupt) & wrap around to 2^16-1 
 * Reprogramm Timer with new Periode (lost-ticks = 2^16 - timerval)

These lost-ticks should be added to the global time-stamp (returned by
get_tsc) and should mentioned at the linux-gettimeoffset-function also.


Lost-ticks could sum up to a bothering time-error.

- Manfred Schlaegl


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Adeos-main] Re: Porting to Intel IXP425

[Gilles Chanteperdrix]

Schlägl "Manfred jun." wrote:
 > Am Freitag, den 30.03.2007, 16:41 +0200 schrieb Gilles Chanteperdrix:
 > > Richard Cochran wrote:
 > > >>The timer is aperiodic (most of the time) when running Xenomai, so
 > > >>__ipipe_mach_set_dec is called for each timer tick and programs the
 > > >>timer hardware for the next tick.
 > > > 
 > > > 
 > > > Okay, so does that mean that I should implement a "one-shot" timer, or
 > > > are we talking about resetting the periodic timer once in a while?
 > > > 
 > > > (BTW, in one-shot mode, the IXP425 timer does not do what the Developers
 > > > Manual, part 252480-006, says that it does!)
 > > 
 > > Yes, the one shot mode is Xenomai default mode. The implementation of a
 > > periodic timer over the one-shot timer is already done by the generic
 > > ARM part of the Adeos patch.
 > 
 > It's better to use a periodic implementation in background, because then
 > you are able to messure the lost ticks between a timer-interrupt and
 > programming next timer-event.
 > 
 > Example with 16bit timer:
 >  * Periode: 27000 Ticks 
 >  * Timer counts down to zero (Interrupt) & wrap around to 2^16-1 
 >  * Reprogramm Timer with new Periode (lost-ticks = 2^16 - timerval)
 > 
 > These lost-ticks should be added to the global time-stamp (returned by
 > get_tsc) and should mentioned at the linux-gettimeoffset-function also.
 > 
 > 
 > Lost-ticks could sum up to a bothering time-error.

This is needed for machines where the hardware timer is based on a
decrementer. But for machines with a free-running counter and a match
register, reading the value of the free-running counter is
simpler. IXP425 is in the  "free-running counter and match register
category". So, its implementation should look like the one of the PXA.

-- 


					    Gilles Chanteperdrix.