10 Apr
2007
10 Apr
'07
10:40 a.m.
CC: Linux-Audio-Developers
CC: linux1394-devel
Spencer Russell wrote:
Hey List,
So my initial concerns that the HDA Intel audio card shares the IRQ
with ohci1394 seem to have manifested themselves. Using the kernel
option pci=noacpi initially put most of my devices on IRQ11, but then
I was able to move them around using the BIOS. Unfortunately, whenever
I change the IRQs around, HDA Intel, ohci1394, and uhci_hcd:usb2 all
seem to move together, which to me indicates that there's some
lower-level hardware connection between the three of them.
This means that I get loads of xruns if I try to run jackd with a
firewire hard drive plugged in, which is a pain because I bought this
enclosure specifically so that I would have access to the hard drive
that has all my session files on it.
The current interrupt handler for ohci1394 is rather heavyweight. This
could cause these problems. However, ohci1394 is open source, so we can
solve that if we want to :).
You should try the new juju stack, and see if you experience the same
issues there.
I'm also wondering why/whether threaded IRQ's can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
Greets,
Pieter
10 Apr
10 Apr
12:18 p.m.
New subject: [LAU] Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
On Tue, 2007-04-10 at 14:34 +0200, Pieter Palmers wrote:
I'm also wondering why/whether threaded IRQ's
can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
yes, thats correct. the priority of the IRQ itself is based in h/w, and
is not affected by the scheduling class or priority of the kernel task
that runs the *_handle_irq(). the point of ingo's changes are that
*_handle_irq() runs in a dedicated task/thread per IRQ at a (relatively)
fixed priority.
3:41 p.m.
New subject: [LAU] Thinkpad R60 for Audio Update - Firewire Conflicts with Audio
Paul Davis wrote:
On Tue, 2007-04-10 at 14:34 +0200, Pieter Palmers
wrote:
I think we're not on the same track here...
This is how I understand things:
The IRQ priorities are indeed hardware fixed, in the sense that if two
IRQ's occur simultaneously, that the order of handling them is hardware
based. [=what you say]
The IRQ handler 'vectors' are called by the hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Example:
What I see on my laptop is:
$ cat /proc/interrupts:
...
9: 2210709 XT-PIC-XT ipw2200, Intel 82801DB-ICH4,
Intel 82801DB-ICH4 Modem, eth0
...
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9 FF 50
What I would like to see is:
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9-ipw2200 TS -
IRQ-9-snd FF 50
IRQ-9-eth0 TS -
That would restrict the critical path whenever IRQ-9 is called to the
kernel's dispatch function for the interrupt.
Greets,
Pieter
I'm also wondering why/whether threaded
IRQ's can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
yes, thats correct. the priority of the IRQ itself is based in h/w, and
is not affected by the scheduling class or priority of the kernel task
that runs the *_handle_irq(). the point of ingo's changes are that
*_handle_irq() runs in a dedicated task/thread per IRQ at a (relatively)
fixed priority.
6360
days inactive
6360
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Paul Davis -
Pieter Palmers