linux 2.4.x, PPC and openPIC interrupt priorities

linux 2.4.x, PPC and openPIC interrupt priorities

[Ron Bianco]

Hi,

Can anyone please tell me what, if any, distribution of 2.4.x linux is 'best' as a
starting point for porting to our custom 8240 board?  I realize 2.4.x, especially for
PPC, is being updated daily.   Any advice will be greatly appreciated.
I'm also somewhat aware of RTlinux and others, but don't have time to search, read
and compare the plethora of tech doc on kernel versions, changes, and PPC gotchas
right now.

The 8240 is basically an enhanced 603 with an open PIC compatible EPIC and PCI etc.
on chip.

Can anyone also tell me if the 2.4.x-testx kernel now, indirectly at least, handles
'external' interrupt priorities according to the way the open pic registers are
programmed.
i.e. it allows a lower priority interrupt handler to be interrupted by a higher
priority int?

Instead of the old 2.2.x and 2.3.x way of disabling external ints via the MSR  EE bit
until ANY int handler returns.

The EPIC will only assert the int signal to the CPU if a higher priority int comes
along, so the linux interrupt
dispatching code should, ideally, NOT globally disable ints via MSR[EE] when calling
a handler, for PPC anyway.

We are currently testing with HHL 2.3.16-sandpoint8240 and are finding too much
interrupt 'jitter' to be able to service our special PCI device properly while SCSI
disk accesses using the sym53c8xx driver, are going on.

Max.  latency has been found to be >300usec, which is too long for our special device
which interrupts every 167usec.

We have only 3 external ( PCI ) interrupts on our board.

Ethernet - i82559 lowest priority
SCSI     - 52c895 next
special  - highest priority

As far as I can tell so far, neither the eepro100 and sym53c8xx drivers disable ints
themselves.

Desperately yours, Ron

Ron Bianco
Computer Systems Technologist
Level Control Systems
email: ronb@junction.net
phone: 250-549-2558 Ext 8
web:  www.lcsaudio.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: linux 2.4.x, PPC and openPIC interrupt priorities

[Cort Dougan]

} Can anyone please tell me what, if any, distribution of 2.4.x linux is 'best' as a
} starting point for porting to our custom 8240 board?  I realize 2.4.x, especially for
} PPC, is being updated daily.   Any advice will be greatly appreciated.
} I'm also somewhat aware of RTlinux and others, but don't have time to search, read
} and compare the plethora of tech doc on kernel versions, changes, and PPC gotchas
} right now.

I don't have any info no which distrubtion would be best (from which
vendor, that is) but any should do.  I'd suggest starting with the 2.4.X
sources from www.fsmlabs.com/linuxppcbk.html for any work you do.  You may
also want to subscribe to the mailing list there.

} The 8240 is basically an enhanced 603 with an open PIC compatible EPIC and PCI etc.
} on chip.

Should be easy with 2.4.X.

} Can anyone also tell me if the 2.4.x-testx kernel now, indirectly at least, handles
} 'external' interrupt priorities according to the way the open pic registers are
} programmed.
} i.e. it allows a lower priority interrupt handler to be interrupted by a higher
} priority int?

We don't explicitly program them and rely on all-enabled or all-disabled
with the MSR.  Dealing with priorities is a mess for us since we support
over a dozen interrupt controllers, all of which have different methods of
assigning priorities.

} Instead of the old 2.2.x and 2.3.x way of disabling external ints via the MSR  EE bit
} until ANY int handler returns.
}
} The EPIC will only assert the int signal to the CPU if a higher priority int comes
} along, so the linux interrupt
} dispatching code should, ideally, NOT globally disable ints via MSR[EE] when calling
} a handler, for PPC anyway.
}
} We are currently testing with HHL 2.3.16-sandpoint8240 and are finding too much
} interrupt 'jitter' to be able to service our special PCI device properly while SCSI
} disk accesses using the sym53c8xx driver, are going on.
}
} Max.  latency has been found to be >300usec, which is too long for our special device
} which interrupts every 167usec.

You'll never get that with normal linux.  We've found 810ms (that is not a
mistype - 810 _ms_) delays with certain operations.

However, with the 82xx chips you can get sub 10 us (even better with some
configurations) worst-case interrupt latency with RTLinux.  For periodic
tasks we see about 10us worst-case jitter for those chips.  A standard G4
pmac will push the worst case latency/jitter to 16us/20us because of the
IDE controller being slow.

Take a look at www.rtlinux.org and download it from
www.rtlinux.com/pub/rtlinux/v3/  That's the "open" version of RTLinux
which is GPL.  Your application code does not invoke the GPL so it can be
closed or open but if you modify the RTLinux code itself you need to talk
to us.  The details of the license are there.

} We have only 3 external ( PCI ) interrupts on our board.
}
} Ethernet - i82559 lowest priority
} SCSI     - 52c895 next
} special  - highest priority
}
} As far as I can tell so far, neither the eepro100 and sym53c8xx drivers disable ints
} themselves.

Send me details on your needs and I can give you some recommendations.
RTLinux will give you much better than the 167us worst-case latency you need.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: linux 2.4.x, PPC and openPIC interrupt priorities

[Ron Bianco]

Thanks a lot Cort, that's a big help.

We're wondering if rtlinux-3.0-pre10 patches can also be applied to your latest
bitkeeper 2.4.1-preX  linux.
It is mentioned that the patches are to be applied to linux-2.4.0-test1.

It sure is unfortunate, to my mind, that regular linux handles interrupts that
'enable all/disable all', way.
But I understand the predicament of dealing with tons of different PICs.   Must drive
driver writers nuts. :-)
Might actually make writing linux drivers for some hardware, impossible.

If we think we need mods to RTLinux for our purposes, I'll let you know.

regards, Ron


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: linux 2.4.x, PPC and openPIC interrupt priorities

[Cort Dougan]

} Thanks a lot Cort, that's a big help.
}
} We're wondering if rtlinux-3.0-pre10 patches can also be applied to your latest
} bitkeeper 2.4.1-preX  linux.
} It is mentioned that the patches are to be applied to linux-2.4.0-test1.

You may want to just grab the tar file for the kernel source there.  It's
pre-patched for all architectures.  In fact, the most recent PPC trees need
no patches.  The RTLinux code itself that is there (3.0-pre10) doesn't work
with 2.4.1-preX but we do have a copy that does work.  That'll be in our final
3.0 release (hopefully later this week if our testing goes well).

} It sure is unfortunate, to my mind, that regular linux handles interrupts that
} 'enable all/disable all', way.
} But I understand the predicament of dealing with tons of different PICs.   Must drive
} driver writers nuts. :-)
} Might actually make writing linux drivers for some hardware, impossible.

You can disable/enable interrupts individually but you can't adjust
priorities.  Linux doesn't depend on priorities, either.  Perhaps I wasn't
clear about that.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/