On Thu, Feb 24, 2000 at 05:44:53AM +0300, Maxim S. Shatskih wrote:
quoted
It's not seen because the driver is stuck in bus reset. The most
probable reason is that DMA is not working. I can't think of a reason
right now (since it does work on another PPC).
I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
config space is set?
To quote Albert's patch:
+ pci_read_config_word (dev, PCI_COMMAND, &w);
+ pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
He sets the PCI master flag (which should be the only thing disabling /
enabling DMA in general). In the standard sources pci_set_master() is
used, which does the same.
Setting PCI_COMMAND_IO on the other hand is unneccessary since the
PCILynx only uses memory mapped I/O (if I understand PCI config
correctly). I don't know if this flag is harmful if there are no I/O
ports.
--
Andreas E. Bombe [off-list ref]
http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
[sorry for the late answer, was out for a few days...]
Andreas Bombe wrote:
Setting PCI_COMMAND_IO on the other hand is unneccessary since the
PCILynx only uses memory mapped I/O (if I understand PCI config
correctly). I don't know if this flag is harmful if there are no I/O
ports.
I don't think that writing a read-only bit will cause any problem.
You told me earlier that the PCILynx was stuck in bus reset, because DMA seems
not to work. Does DMA signal success/completition by interrupt? Then this
might be a problem with the CardBus Bridge and/or interrupts. "lspci -vv" tells
me for the PCILynx
01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
Layer Controller (rev 04) (prog-if 00 [Generic])
Subsystem: Texas Instruments: Unknown device 8000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 1 min, 2 max, 32 set, cache line size 20
Interrupt: pin A routed to IRQ 0
Region 0: Memory at 90030000 (32-bit, non-prefetchable)
Region 1: Memory at 90000000 (32-bit, non-prefetchable)
Region 2: Memory at 90010000 (32-bit, non-prefetchable)
Expansion ROM at 90020000
I think IRQ 0 is a little bit suspicious, right? At least /proc/interrupts does
not count ANY irq's on this line. The same information for the Cardbus bridge
is-
00:13.0 CardBus bridge: Texas Instruments: Unknown device ac1e
Subsystem: Texas Instruments: Unknown device ac1e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 set, cache line size 08
Interrupt: pin A routed to IRQ 22
Region 0: Memory at 80880000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=01, subordinate=04, sec-latency=64
Memory window 0: 90000000-90031000
I/O window 0: 00000000-00000003
I/O window 1: 00000000-00000003
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0007
Any cardbus/pci gurus out there?
Thanks, Albrecht.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/