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

[mea]

Thanks for the quick answers,
I will give it a another try next week or so, when I have a bit more 
time, last time I tried to set it up it took a week and no success, but 
maybe this time ;)
@Pieter Palmers>>   the chipset is Texas Insts., not Ricoh.
Thanks again
Best
Martin


Pieter Palmers wrote:
> 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
>>
> 
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
>