RTnet on PowerPC?

[Paolo Mantegazza]

Philippe Gerum wrote:
> 
> Wolfgang Grandegger writes:
>  > On 11/15/2002 01:05 PM Jan Kiszka wrote:
>  > > Hans-Peter Bock schrieb:
>  > >> Hello Jan,
>  > >>
>  > >>
>  > >>>Could you track down the problem a
>  > >>>bit more (e.g. are packets sent, is any packet received by the driver or
>  > >>>the stack)?
>  > >>
>  > >>
>  > >> I have put a rt_printk into the function speedo_interrupt() to see, if it
>  > >> is called, but I didn't get any outputs of this rt_printk in the kernel
>  > >> logfile.
>  > >>
>  > >> There is also a warning when I compile the eepro100-rt- or the
>  > >> 3c59x-module:
>  > >>
>  > >> [tb10bhp at tb10bhp driver]$ ppc_60x-gcc -D__KERNEL__
>  > >> -I/home/tb10hpb/elinos/RTAI-Clone/linux/drivers/rtai/include
>  > >> -I/home/tb10hpb/elinos/RTAI-Clone/linux/include -Wall -Wstrict-prototypes
>  > >> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
>  > >> -I/home/tb10hpb/elinos/RTAI-Clone/linux/arch/ppc -fsigned-char
>  > >> -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring
>  > >> -DMODULE -fomit-frame-pointer  -DKBUILD_BASENAME=rtnet  -DEXPORT_SYMTAB
>  > >> -I../include -I. -I../lib -c eepro100-rt.c -Wall
>  > >> eepro100-rt.c: In function `speedo_open':
>  > >> eepro100-rt.c:991: warning: passing arg 2 of `rt_request_global_irq_ext'
>  > >> from incompatible pointer type
>  > >>
>  > >
>  > > This could indicate the core problem. rt_request_global_irq_ext() is an
>  > > undocumented extension of rt_request_global_irq(). IRQ handlers assigned
>  > > this way are called with an extra argument, generally some kind of
>  > > context pointer. RTnet uses this feature for its network drivers. It
>  > > seems to be only available on x86 platforms, at least according to the
>  > > original PPC tree of RTAI-24.1.10.
>  > >
>  > > So, to all that PPC gurus out there: Does a simular mechanism already
>  > > exists for the PPC or could it be added to RTAI?
>  >
>  > No, it's _not_ implemented in RTAI 24.1.10 for the PowerPC. There was an
>  > improper implementation for some time in 2.4.9 but then I realized, that
>  > it's usually used for the timer interrupt (irq=0), which on the PowerPC
>  > platform is handled differently e.g. it's not an (external) interrupt
>  > but a decrementer trap.
>  >
>  > It thought it's one of Paolo's special-purpose extensions mainly for the
>  > buslokchk example. Could someone explain what rt_request_global_irq_ext
>  > and rt_set_global_irq_ext are good for. Thanks.
>  >
> 
> Hi Wolfgang,
> 
> As far as I understand the x86 implementation, an extended handler
> also gets its return value tested so that a non-zero return causes the
> interrupt path to end (iret) immediately. This is roughly the same
> behaviour as catching an interrupt when the soft masking is in effect
> with a regular (RT but non-extended) handler: the IRQ is delivered to
> the handler, but the current interrupt log is not played on return
> since the soft masking prevents it.
> 
> OTOH, if the extended handler returns zero, any pending IRQ is also
> delivered (linux_sti()) on behalf of dispatch_global_irq() if the soft
> mask allows it.
> 
> rt_set_global_irq_ext() allows to switch the handler mode of a given
> IRQ to either "regular" or "extended" and stores the cookie which will
> be passed to the extended handler.
> 
> I guess that rt_request_global_irq_ext() is somewhat designed to hook
> high-frequency interrupts on handlers which want the interrupt frame
> to be unwound as fast as possible (prevent piling up?). Since the
> timer interrupt is usually propagated to Linux on a much lower
> frequency than it is received by the RT side, this could be a fair
> reason to use this trick in this context. But this is just a
> guess...
> 

Philippe's guess is totally correct, as it is on many others RTAI
things. Otherwise his arti.c interface for RTAI on ADEOS would have not
worked :-), while it does also SMP now.

To get it in the details notice that standard real time RTAI intr
handler dispatcher reanables the hard interrupt at most has soon has it
has finished its real time work and see if there is something to do for
Linux. Naturally handlers can do so even before if they want, but that
is up to the application. At that point, if real time interrupts are
coming in too fast, they can pile up the registers environments. It is
in the order of the tens of bytes but if the piling goes on for too much
the system crashes. By allowing the immediate interrupt then interrupts
are enabled by iret so nothing piles on the stack. It has been a trick
that has allowed to take interrupt handler only controllers to the
extreme, while keeping Linux barely alive. It could be useful and as
such has been left. The possibility of having an argoment allows some
dynamic interaction with the handler by using appropriate pointers.

Paolo.