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

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@email-addr-hidden: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@email-addr-hidden
>> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
>>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Received on Fri Apr 20 20:15:14 2007