27 Nov
2005
27 Nov
'05
3:03 p.m.
On 11/27/05, Pete Leigh <pete.leigh(a)gmail.com> wrote:
No, not at all. In fact, I think that both are necessary to gain the
most control over the hardware. With a PIC system set up things with a
sound card on IRQ9 or IRQ10. Then set the -rt priority to a value of
80. With an APIC system I believe all you have to do is set the -rt
priority and not worry so much about the hardware setting.
- Mark
On 27/11/05, Mark Knecht <markknecht(a)gmail.com>
wrote:
OK, this 'priority' is the Linux kernel's priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
In the older PIC when an ISR was entered all lower hardware 'priority'
IRQ are blocked until the ISR tells the PIC it is ready to release.
That is the numerical list I gave earlier. In that list is something
at IRQ14 starts and doesn't release then all interrupts of lower
hardware priority (15,3,4,5,6,7) will not happen.
The setting of Linux kernel 'priority' doesn't care whether you are
using a PIC or an APIC. Clemen's app works for both I'm sure.
Sorry for the confusion!
On 11/27/05, Pete Leigh
<pete.leigh(a)gmail.com> wrote:
> Didn't Clemens Ladisch write a (now
outdated) patch to re-assign
> APIC priorities in software, and a program to change PIC interrupt
> priorities?
For APIC - yes
For PIC - no
Oh, perhaps I misread at
http://users.informaik.uni-halle.de/~ladischc/pic_priorities.html
where he says:
(quote on)
To configure the PIC, use the following little program:
set8259priorities.c (source code only).
[...]
The above example configuration with interrupt 5 at the
top can be set with "set8259priorities 5 8". For interrupt 11
at the top, run "set8259priorities 2 11".
(quote off)
Or perhaps I didn't understand what he was saying. It seems
to be saying that the PIC controller can be programmed to
some extent from software, at least in principle (perhaps it
needs some hardware support?) > Is the
latter an intrinsically inferior solution?
I didn't follow. Sorry.
I meant to ask: is using the irq handling thread priority control
from the rt kernel patches necessarily a worse way to go about
things than hardware re-prioritisation?
Cheers,
- Pete.