[LAU] Thinkpad R60 for Audio Update - Firewire Conflicts with Audio

[Pieter Palmers]

Robin Gareus wrote:
> 
> mea wrote:
>> Hi,
>> Sorry to bump into the thread like this, but I have 3+ year old R40 and
>> I never managed to make it work with my firewire sound card under linux,
>> I think mainly because of> cat /proc/interrupts
>>  0:    6674809          XT-PIC  timer
>>   1:         24          XT-PIC  i8042
>>   2:          0          XT-PIC  cascade
>>   6:          3          XT-PIC  floppy
>>   8:          1          XT-PIC  rtc
>>   9:         48          XT-PIC  acpi
>>  11:    1744806          XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2,
>> uhci_hcd:usb3, ehci_hcd:usb4, yenta, ohci1394, Intel 82801DB-ICH4, eth0,
>> radeon at pci:0000:01:00.0
>>  12:         35          XT-PIC  i8042
>>  14:      27840          XT-PIC  ide0
>>  15:         20          XT-PIC  ide1
>> NMI:          0
>> ERR:          0
>>
>> As you can see, 11 is loaded. My question: In BIOS I see letters(A,B,
>> etc) all assigned to 11. Is it safe to try to change them?
> 
> yes, in the worst case you just need to reboot and re-set them..
> 
> (hihi; if you dual boot: windows might find some new devices after
> flipping those around; prepare to jockey (not mount) the driver CD/DVD)
> 
> ABCD usually correspond do the PCI irq wires . aehm striplines or
> signals. ;) - some bios allow to choose "[voltage]level" or "edge" IRQ
> detection. - not sure if and how that affects rt-linux. i use edge
> detection.
If I recall this correctly, level detection is better because it allows 
for shared interrupts. The interrupt line is pulled high by any device 
that wants to generate an interrupt. As long as the interrupt line is 
high, the CPU should execute an interrupt handler. This means that if 
device A and device B both are connected to the same interrupt line, and 
both generate an interrupt simultanously they both pull the interrupt 
line up. The CPU detects this and starts the interrupt service routine 
that handles either A or B. The device that was handled (e.g. A) stops 
pulling the line up, which normally exits the interrupt state. But since 
in this case there is another device with an unhandled interrupt (i.e. 
B), the doesn't go up and the CPU does another round of interrupt handling.

But it has been a long time since I've been into this...

Pieter

> 
> assiging each letter to a different IRQ number and checking the output
> of /proc/interrupts seems like a good idea.  try IRQ 3,5,9,11 for example.
> 
> you might still be unlucky: the firewire device might share the "wire"
> with some other [inconvenient] device(s).
> 
> robin
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
>