* PCIE
@ 2007-05-23 12:15 Manu Abraham
2007-05-23 15:59 ` PCIE Greg KH
0 siblings, 1 reply; 38+ messages in thread
From: Manu Abraham @ 2007-05-23 12:15 UTC (permalink / raw)
To: linux-pci; +Cc: Greg KH, linux-kernel
Hi,
Do the PCI Express chipsets also use the same PCI API ? The device
specifications are thus for the device that i am looking at:
PCI Express interface
* Compliant to PCI Express Base Specification 1.0a
* The PCI Express circuit supports isochronous data traffic intended
for uninterrupted transfer of streaming data like video streaming
o x1 PCI Express endpoint (2.5 Gbit/s)
o Data and clock recovery from serial stream
o Low jitter and BER
* Type 0 configuration space header
o 64-bit addressing
o Single BAR; programmable address range of 17 bits, 18 bits,
19 bits or 20 bits dependent on application requirements
* PCI Express capabilities
o 128 bytes write packet size and 64 bytes read packet size
o MSI support
o Software directed power management of four device power
states (D0 to D3)
o Active state power management of link states
o Vendor specific capability for VC1 support; after reset VC1
isochronous capability is disabled
I have been trying the said card with a normal PCI style driver, but
while booting the kernel (2.6.21.1) i do get a message like this (an
Intel DP965LT motherboard with BIOS version:
MQ96510J.86A.1612.2006.1227.1513)
Also accessing the interrupt registers causes a hard freeze, for which
only the RESET button seems to be of any help.
Uncompressing Linux .. Ok, booting the kernel.
BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
vendor)
PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0
Any ideas as to what could be wrong ?
Thanks,
Manu
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: PCIE 2007-05-23 12:15 PCIE Manu Abraham @ 2007-05-23 15:59 ` Greg KH 2007-05-23 20:59 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Greg KH @ 2007-05-23 15:59 UTC (permalink / raw) To: Manu Abraham; +Cc: linux-pci, linux-kernel On Wed, May 23, 2007 at 04:15:01PM +0400, Manu Abraham wrote: > Hi, > > Do the PCI Express chipsets also use the same PCI API ? At the Linux kernel driver level, yes, they do. > The device > specifications are thus for the device that i am looking at: > > PCI Express interface > > * Compliant to PCI Express Base Specification 1.0a > * The PCI Express circuit supports isochronous data traffic intended > for uninterrupted transfer of streaming data like video streaming > o x1 PCI Express endpoint (2.5 Gbit/s) > o Data and clock recovery from serial stream > o Low jitter and BER > * Type 0 configuration space header > o 64-bit addressing > o Single BAR; programmable address range of 17 bits, 18 bits, > 19 bits or 20 bits dependent on application requirements > * PCI Express capabilities > o 128 bytes write packet size and 64 bytes read packet size > o MSI support > o Software directed power management of four device power > states (D0 to D3) > o Active state power management of link states > o Vendor specific capability for VC1 support; after reset VC1 > isochronous capability is disabled > > I have been trying the said card with a normal PCI style driver, but > while booting the kernel (2.6.21.1) i do get a message like this (an > Intel DP965LT motherboard with BIOS version: > MQ96510J.86A.1612.2006.1227.1513) > Also accessing the interrupt registers causes a hard freeze, for which > only the RESET button seems to be of any help. > > Uncompressing Linux .. Ok, booting the kernel. > BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw > vendor) > PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0 > > Any ideas as to what could be wrong ? What type of PCI device is this? What driver is controlling it? What is the output of 'lspci -v' at boot time? thanks, greg k-h ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 15:59 ` PCIE Greg KH @ 2007-05-23 20:59 ` Manu Abraham 2007-05-23 21:10 ` PCIE Roland Dreier 0 siblings, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-23 20:59 UTC (permalink / raw) To: Greg KH; +Cc: linux-pci, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2438 bytes --] Greg KH wrote: > On Wed, May 23, 2007 at 04:15:01PM +0400, Manu Abraham wrote: >> Hi, >> >> Do the PCI Express chipsets also use the same PCI API ? > > At the Linux kernel driver level, yes, they do. > >> The device >> specifications are thus for the device that i am looking at: >> >> PCI Express interface >> >> * Compliant to PCI Express Base Specification 1.0a >> * The PCI Express circuit supports isochronous data traffic intended >> for uninterrupted transfer of streaming data like video streaming >> o x1 PCI Express endpoint (2.5 Gbit/s) >> o Data and clock recovery from serial stream >> o Low jitter and BER >> * Type 0 configuration space header >> o 64-bit addressing >> o Single BAR; programmable address range of 17 bits, 18 bits, >> 19 bits or 20 bits dependent on application requirements >> * PCI Express capabilities >> o 128 bytes write packet size and 64 bytes read packet size >> o MSI support >> o Software directed power management of four device power >> states (D0 to D3) >> o Active state power management of link states >> o Vendor specific capability for VC1 support; after reset VC1 >> isochronous capability is disabled >> >> I have been trying the said card with a normal PCI style driver, but >> while booting the kernel (2.6.21.1) i do get a message like this (an >> Intel DP965LT motherboard with BIOS version: >> MQ96510J.86A.1612.2006.1227.1513) >> Also accessing the interrupt registers causes a hard freeze, for which >> only the RESET button seems to be of any help. >> >> Uncompressing Linux .. Ok, booting the kernel. >> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw >> vendor) >> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0 >> >> Any ideas as to what could be wrong ? > > What type of PCI device is this? What driver is controlling it? What > is the output of 'lspci -v' at boot time? Err .. how do i get lspci -v at boot time ? You mean without any driver loaded , i presume. The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface. 06:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 (rev 01) Subsystem: Twinhan Technology Co. Ltd Unknown device 0027 Currently working on a driver for the same. I am attaching lspci -v as well as lspci -vvn outputs. Thanks, Manu [-- Attachment #2: lspci-v.txt --] [-- Type: text/plain, Size: 11912 bytes --] root@manu-04:~# lspci -v 00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: 30000000-31ffffff Prefetchable memory behind bridge: 0000000020000000-000000002fffffff Capabilities: [88] Subsystem: Intel Corporation Unknown device 0000 Capabilities: [80] Power Management version 3 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [a0] Express Root Port (Slot+) IRQ 0 00:03.0 Communication controller: Intel Corporation 82P965/G965 HECI Controller (rev 02) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 32426100 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 0001 Flags: bus master, fast devsel, latency 0, IRQ 216 Memory at 32400000 (32-bit, non-prefetchable) [size=128K] Memory at 32424000 (32-bit, non-prefetchable) [size=4K] I/O ports at 20e0 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 20c0 [size=32] 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 20a0 [size=32] 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at 32425c00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) Subsystem: Intel Corporation Unknown device 2111 Flags: bus master, fast devsel, latency 0, IRQ 9 Memory at 32420000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: 32500000-325fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [90] Subsystem: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00001000-00001fff Memory behind bridge: 32300000-323fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [90] Subsystem: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 Capabilities: [a0] Power Management version 2 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Memory behind bridge: 32600000-326fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [90] Subsystem: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 Capabilities: [a0] Power Management version 2 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Memory behind bridge: 32700000-327fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [90] Subsystem: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 Capabilities: [a0] Power Management version 2 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: 32200000-322fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Capabilities: [90] Subsystem: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 Capabilities: [a0] Power Management version 2 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 2080 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 2060 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 2040 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at 32425800 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=32 Memory behind bridge: 32100000-321fffff Prefetchable memory behind bridge: 0000000032000000-00000000320fffff Capabilities: [50] Subsystem: Intel Corporation Unknown device 514d 00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 217 I/O ports at 2108 [size=8] I/O ports at 2114 [size=4] I/O ports at 2100 [size=8] I/O ports at 2110 [size=4] I/O ports at 2020 [size=32] Memory at 32425000 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+ Capabilities: [70] Power Management version 3 Capabilities: [a8] #12 [0010] 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) Subsystem: Intel Corporation Unknown device 514d Flags: medium devsel, IRQ 10 Memory at 32426000 (32-bit, non-prefetchable) [size=256] I/O ports at 2000 [size=32] 01:00.0 VGA compatible controller: nVidia Corporation GeForce 7300 LE (rev a1) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 8229 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 31000000 (32-bit, non-prefetchable) [size=16M] Memory at 20000000 (64-bit, prefetchable) [size=256M] Memory at 30000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [78] Express Endpoint IRQ 0 03:00.0 IDE interface: Marvell Technology Group Ltd. Unknown device 6101 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Marvell Technology Group Ltd. Unknown device 6101 Flags: bus master, fast devsel, latency 0, IRQ 10 I/O ports at 1018 [size=8] I/O ports at 1024 [size=4] I/O ports at 1010 [size=8] I/O ports at 1020 [size=4] I/O ports at 1000 [size=16] Memory at 32300000 (32-bit, non-prefetchable) [size=512] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [e0] Express Legacy Endpoint IRQ 0 06:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 (rev 01) Subsystem: Twinhan Technology Co. Ltd Unknown device 0027 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 32200000 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [50] Express Endpoint IRQ 0 Capabilities: [74] Power Management version 2 Capabilities: [80] Vendor Specific Information 07:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Subsystem: Twinhan Technology Co. Ltd VisionPlus DVB card Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at 32001000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Subsystem: Twinhan Technology Co. Ltd VisionPlus DVB Card Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at 32000000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 07:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) Subsystem: Intel Corporation Unknown device 514d Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at 32104000 (32-bit, non-prefetchable) [size=2K] Memory at 32100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 root@manu-04:~# [-- Attachment #3: lspci-vvn.txt --] [-- Type: text/plain, Size: 56834 bytes --] root@manu-04:~# lspci -vvvn 00:00.0 0600: 8086:29a0 (rev 02) Subsystem: 8086:514d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00:01.0 0604: 8086:29a1 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 30000000-31ffffff Prefetchable memory behind bridge: 0000000020000000-000000002fffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B- Capabilities: [88] Subsystem: 8086:0000 Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4139 Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 75.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:03.0 0780: 8086:29a4 (rev 02) Subsystem: 8086:514d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32426100 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00:19.0 0200: 8086:104b (rev 02) Subsystem: 8086:0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 216 Region 0: Memory at 32400000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at 32424000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 20e0 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Address: 00000000fee0100c Data: 4171 00:1a.0 0c03: 8086:2834 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at 20c0 [size=32] 00:1a.1 0c03: 8086:2835 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin B routed to IRQ 10 Region 4: I/O ports at 20a0 [size=32] 00:1a.7 0c03: 8086:283a (rev 02) (prog-if 20 [EHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin C routed to IRQ 11 Region 0: Memory at 32425c00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port 00:1b.0 0403: 8086:284b (rev 02) Subsystem: 8086:2111 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 9 Region 0: Memory at 32420000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 00:1c.0 0604: 8086:283f (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 32500000-325fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 1, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4141 Capabilities: [90] Subsystem: 8086:283f Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.1 0604: 8086:2841 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00001000-00001fff Memory behind bridge: 32300000-323fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 2, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4149 Capabilities: [90] Subsystem: 8086:2841 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.2 0604: 8086:2843 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 32600000-326fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 3, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4151 Capabilities: [90] Subsystem: 8086:2843 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.3 0604: 8086:2845 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 32700000-327fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 4, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4159 Capabilities: [90] Subsystem: 8086:2845 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.4 0604: 8086:2847 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 32200000-322fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 5 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 5, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4161 Capabilities: [90] Subsystem: 8086:2847 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1d.0 0c03: 8086:2830 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at 2080 [size=32] 00:1d.1 0c03: 8086:2831 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin B routed to IRQ 11 Region 4: I/O ports at 2060 [size=32] 00:1d.2 0c03: 8086:2832 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin C routed to IRQ 11 Region 4: I/O ports at 2040 [size=32] 00:1d.7 0c03: 8086:2836 (rev 02) (prog-if 20 [EHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32425800 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port 00:1e.0 0604: 8086:244e (rev f2) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=32 I/O behind bridge: 0000f000-00000fff Memory behind bridge: 32100000-321fffff Prefetchable memory behind bridge: 0000000032000000-00000000320fffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [50] Subsystem: 8086:514d 00:1f.0 0601: 8086:2810 (rev 02) Subsystem: 8086:514d 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: 0 Capabilities: [e0] Vendor Specific Information 00:1f.2 0106: 8086:2824 (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 217 Region 0: I/O ports at 2108 [size=8] Region 1: I/O ports at 2114 [size=4] Region 2: I/O ports at 2100 [size=8] Region 3: I/O ports at 2110 [size=4] Region 4: I/O ports at 2020 [size=32] Region 5: Memory at 32425000 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+ Address: fee0100c Data: 4169 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] #12 [0010] 00:1f.3 0c05: 8086:283e (rev 02) Subsystem: 8086:514d 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- Interrupt: pin B routed to IRQ 10 Region 0: Memory at 32426000 (32-bit, non-prefetchable) [size=256] Region 4: I/O ports at 2000 [size=32] 01:00.0 0300: 10de:01d1 (rev a1) (prog-if 00 [VGA]) Subsystem: 1043:8229 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 31000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 20000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at 30000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [78] Express Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <256ns, L1 <4us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 03:00.0 0101: 11ab:6101 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: 11ab:6101 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 1018 [size=8] Region 1: I/O ports at 1024 [size=4] Region 2: I/O ports at 1010 [size=8] Region 3: I/O ports at 1020 [size=4] Region 4: I/O ports at 1000 [size=16] Region 5: Memory at 32300000 (32-bit, non-prefetchable) [size=512] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [e0] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0 Link: Latency L0s <256ns, L1 unlimited Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 06:00.0 0480: 1131:7162 (rev 01) Subsystem: 1822:0027 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32200000 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [50] Express Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <256ns, L1 <1us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <4us, L1 <64us Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [74] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information 07:00.0 0400: 109e:036e (rev 11) Subsystem: 1822:0001 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 (4000ns min, 10000ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 32001000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 07:00.1 0480: 109e:0878 (rev 11) Subsystem: 1822:0001 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 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 32000000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 07:03.0 0c00: 104c:8023 (prog-if 10 [OHCI]) Subsystem: 8086:514d 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 (500ns min, 1000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32104000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at 32100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME+ root@manu-04:~# clear root@manu-04:~# lspci -vvn 00:00.0 0600: 8086:29a0 (rev 02) Subsystem: 8086:514d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00:01.0 0604: 8086:29a1 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: 30000000-31ffffff Prefetchable memory behind bridge: 0000000020000000-000000002fffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B- Capabilities: [88] Subsystem: 8086:0000 Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4139 Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 75.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:03.0 0780: 8086:29a4 (rev 02) Subsystem: 8086:514d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32426100 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00:19.0 0200: 8086:104b (rev 02) Subsystem: 8086:0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 216 Region 0: Memory at 32400000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at 32424000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 20e0 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Address: 00000000fee0100c Data: 4171 00:1a.0 0c03: 8086:2834 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at 20c0 [size=32] 00:1a.1 0c03: 8086:2835 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin B routed to IRQ 10 Region 4: I/O ports at 20a0 [size=32] 00:1a.7 0c03: 8086:283a (rev 02) (prog-if 20 [EHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin C routed to IRQ 11 Region 0: Memory at 32425c00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port 00:1b.0 0403: 8086:284b (rev 02) Subsystem: 8086:2111 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 9 Region 0: Memory at 32420000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 00:1c.0 0604: 8086:283f (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: 32500000-325fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 1, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4141 Capabilities: [90] Subsystem: 8086:283f Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.1 0604: 8086:2841 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00001000-00001fff Memory behind bridge: 32300000-323fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 2, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4149 Capabilities: [90] Subsystem: 8086:2841 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.2 0604: 8086:2843 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Memory behind bridge: 32600000-326fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 3, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4151 Capabilities: [90] Subsystem: 8086:2843 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.3 0604: 8086:2845 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Memory behind bridge: 32700000-327fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x0 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 4, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4159 Capabilities: [90] Subsystem: 8086:2845 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1c.4 0604: 8086:2847 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: 32200000-322fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 5 Link: Latency L0s <1us, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 5, PowerLimit 10.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4161 Capabilities: [90] Subsystem: 8086:2847 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1d.0 0c03: 8086:2830 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at 2080 [size=32] 00:1d.1 0c03: 8086:2831 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin B routed to IRQ 11 Region 4: I/O ports at 2060 [size=32] 00:1d.2 0c03: 8086:2832 (rev 02) (prog-if 00 [UHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin C routed to IRQ 11 Region 4: I/O ports at 2040 [size=32] 00:1d.7 0c03: 8086:2836 (rev 02) (prog-if 20 [EHCI]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32425800 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port 00:1e.0 0604: 8086:244e (rev f2) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=32 Memory behind bridge: 32100000-321fffff Prefetchable memory behind bridge: 0000000032000000-00000000320fffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [50] Subsystem: 8086:514d 00:1f.0 0601: 8086:2810 (rev 02) Subsystem: 8086:514d 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: 0 Capabilities: [e0] Vendor Specific Information 00:1f.2 0106: 8086:2824 (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: 8086:514d 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: 0 Interrupt: pin A routed to IRQ 217 Region 0: I/O ports at 2108 [size=8] Region 1: I/O ports at 2114 [size=4] Region 2: I/O ports at 2100 [size=8] Region 3: I/O ports at 2110 [size=4] Region 4: I/O ports at 2020 [size=32] Region 5: Memory at 32425000 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+ Address: fee0100c Data: 4169 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] #12 [0010] 00:1f.3 0c05: 8086:283e (rev 02) Subsystem: 8086:514d 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- Interrupt: pin B routed to IRQ 10 Region 0: Memory at 32426000 (32-bit, non-prefetchable) [size=256] Region 4: I/O ports at 2000 [size=32] 01:00.0 0300: 10de:01d1 (rev a1) (prog-if 00 [VGA]) Subsystem: 1043:8229 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 31000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 20000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at 30000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [78] Express Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <256ns, L1 <4us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 03:00.0 0101: 11ab:6101 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: 11ab:6101 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 1018 [size=8] Region 1: I/O ports at 1024 [size=4] Region 2: I/O ports at 1010 [size=8] Region 3: I/O ports at 1020 [size=4] Region 4: I/O ports at 1000 [size=16] Region 5: Memory at 32300000 (32-bit, non-prefetchable) [size=512] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [e0] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr+ NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0 Link: Latency L0s <256ns, L1 unlimited Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 06:00.0 0480: 1131:7162 (rev 01) Subsystem: 1822:0027 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32200000 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [50] Express Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <256ns, L1 <1us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <4us, L1 <64us Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [74] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information 07:00.0 0400: 109e:036e (rev 11) Subsystem: 1822:0001 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 (4000ns min, 10000ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 32001000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 07:00.1 0480: 109e:0878 (rev 11) Subsystem: 1822:0001 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 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at 32000000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 07:03.0 0c00: 104c:8023 (prog-if 10 [OHCI]) Subsystem: 8086:514d 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 (500ns min, 1000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at 32104000 (32-bit, non-prefetchable) [size=2K] Region 1: Memory at 32100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME+ root@manu-04:~# ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 20:59 ` PCIE Manu Abraham @ 2007-05-23 21:10 ` Roland Dreier 2007-05-23 22:11 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Roland Dreier @ 2007-05-23 21:10 UTC (permalink / raw) To: Manu Abraham; +Cc: Greg KH, linux-pci, linux-kernel >> Uncompressing Linux .. Ok, booting the kernel. >> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor) >> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0 This message is about device 01:00.0 as it says (your nvidia video card based on later lspci output). > The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface. > > 06:00.0 Multimedia controller: Philips Semiconductors Unknown device > 7162 (rev 01) > Subsystem: Twinhan Technology Co. Ltd Unknown device 0027 This is device 06:00.0, so it's not related to that earlier message at all. You didn't say what problem you're having with your driver for this device... but all standard PCI stuff should work fine for PCIe devices -- the normal PCI driver stuff is all you should need for everything but exotic cases. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 21:10 ` PCIE Roland Dreier @ 2007-05-23 22:11 ` Manu Abraham 2007-05-23 22:23 ` PCIE Roland Dreier 0 siblings, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-23 22:11 UTC (permalink / raw) To: Roland Dreier; +Cc: Greg KH, linux-pci, linux-kernel Roland Dreier wrote: >>> Uncompressing Linux .. Ok, booting the kernel. >>> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw vendor) >>> PCI: Failed to allocate mem resource #6:20000@30000000 for 0000:01:00.0 > > This message is about device 01:00.0 as it says (your nvidia video > card based on later lspci output). > > > The device is a new DTV bridge from NXP (SAA7162E) with a PCIe interface. > > > > 06:00.0 Multimedia controller: Philips Semiconductors Unknown device > > 7162 (rev 01) > > Subsystem: Twinhan Technology Co. Ltd Unknown device 0027 > > This is device 06:00.0, so it's not related to that earlier message at > all. You didn't say what problem you're having with your driver for > this device... If i uncomment the saa716x_read or write, what i get is a solid freeze on module load. If i leave it commented out, the module loads fine. static irqreturn_t saa716x_pcie_irq(int irq, void *dev_id) { struct saa716x *saa716x; u32 stat, mask; if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) { printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__); return IRQ_NONE; } // stat = saa716x_read(0x500); dprintk(verbose, SAA716x_DEBUG, 0, "=== Interrupts[%04x] [", stat); dprintk(verbose, SAA716x_DEBUG, 0, "] ==\n"); return IRQ_HANDLED; } int saa716x_pcie_init(struct saa716x *saa716x) { struct pci_dev *pdev = saa716x->pdev; int err = 0; u8 latency, revision; printk(KERN_INFO "%s: found a %s device\n", __func__, saa716x->hwconfig->model_name); pci_set_drvdata(pdev, saa716x); if ((err = pci_enable_device(pdev)) != 0) { printk(KERN_ERR "%s ERROR: pci enable failed (%i)\n", __func__, err); goto fail0; } if (request_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0), DRIVER_NAME) == NULL) { printk(KERN_ERR "%s ERROR: mem region request failed\n", __func__); err = -ENOMEM; goto fail1; } saa716x->mmio = ioremap(pci_resource_start(pdev, 0), 0x1000); // FIXME: check this size if ((err = request_irq(pdev->irq, saa716x_pcie_irq, IRQF_SHARED | IRQF_DISABLED, DRIVER_NAME, (void *) saa716x)) != 0) { printk(KERN_ERR "%s ERROR: irq request failed (%i)\n", err, __func__); goto fail2; } pci_set_master(pdev); pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency); pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision); dprintk(verbose, SAA716x_ERROR, 0, " SAA7160/1/2 Rev %d [%04x:%04x], ", revision, saa716x->pdev->subsystem_vendor, saa716x->pdev->subsystem_device); dprintk(verbose, SAA716x_ERROR, 0, "irq: %d, latency: %d\n memory: 0x%04x, mmio: 0x%p\n", saa716x->pdev->irq, latency, pci_resource_start(pdev, 0), saa716x->mmio); saa716x->verbose = verbose; // init_waitqueue_head(&saa716x->i2c_queue); /* Disable all interrupts here */ // saa716x_write(0, 0x500); return 0; fail2: iounmap(saa716x->mmio); release_mem_region(pci_resource_start(saa716x->pdev, 0), pci_resource_len(saa716x->pdev, 0)); fail1: pci_disable_device(pdev); fail0: pci_set_drvdata(pdev, NULL); return err; } EXPORT_SYMBOL_GPL(saa716x_pcie_init); > but all standard PCI stuff should work fine for PCIe > devices -- the normal PCI driver stuff is all you should need for > everything but exotic cases. That part is then fine. Does MSI require any special tinkering ? Thanks, Manu ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 22:11 ` PCIE Manu Abraham @ 2007-05-23 22:23 ` Roland Dreier 2007-05-23 23:03 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Roland Dreier @ 2007-05-23 22:23 UTC (permalink / raw) To: Manu Abraham; +Cc: Greg KH, linux-pci, linux-kernel > If i uncomment the saa716x_read or write, what i get is a solid freeze > on module load. If i leave it commented out, the module loads fine. That sounds like a typical bug during driver development... you're probably wedging the hardware by doing the wrong access. I didn't see the source for saa716x_read or write in the code you posted, so it's hard to say if there's a problem with them. Is your interrupt handler getting called? Is the device generating interrupts? > That part is then fine. Does MSI require any special tinkering ? Just pci_enable_msi() as usual. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 22:23 ` PCIE Roland Dreier @ 2007-05-23 23:03 ` Manu Abraham 2007-05-23 23:51 ` PCIE Roland Dreier 0 siblings, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-23 23:03 UTC (permalink / raw) To: Roland Dreier; +Cc: Greg KH, linux-pci, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2734 bytes --] Roland Dreier wrote: > > If i uncomment the saa716x_read or write, what i get is a solid freeze > > on module load. If i leave it commented out, the module loads fine. > > That sounds like a typical bug during driver development... you're > probably wedging the hardware by doing the wrong access. > > I didn't see the source for saa716x_read or write in the code you > posted, so it's hard to say if there's a problem with them. > Attaching saa716x_read/write in saa716x_priv.h > Is your interrupt handler getting called? Is the device generating > interrupts? It looks so, from the logs. The only problem is i can't disable the interrupts, if i write "0" to 0x500, the interrupt/enable register, it gives me a solid freeze. If i read from the handler, commenting out the disable interrupts in init, that read also gives me a solid freeze. This lead me to think that there could be some problem with the MMIO block access. May 23 03:25:48 manu-04 kernel: [ 383.602737] saa716x_pci_init: found a Twinhan VP-6090 device May 23 03:25:48 manu-04 kernel: [ 383.602764] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 16 (level, low) -> IRQ 16 May 23 03:25:48 manu-04 kernel: [ 383.603020] SAA7160/1/2 Rev 1 [1822:0027], irq: 16, latency: 0 May 23 03:25:48 manu-04 kernel: [ 383.603024] memory: 0x32200000, mmio: 0xe046e000 May 23 03:25:48 manu-04 kernel: [ 383.610761] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.624056] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.637348] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.650650] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.663951] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.677253] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.690554] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.703858] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.717156] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.730459] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.743760] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.757064] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.770364] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.783665] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.796966] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.810269] === Interrupts[0010] [] == May 23 03:25:48 manu-04 kernel: [ 383.823569] === Interrupts[0010] [] == > > > That part is then fine. Does MSI require any special tinkering ? > > Just pci_enable_msi() as usual. Thanks Regards, Manu [-- Attachment #2: saa716x_priv.h --] [-- Type: text/plain, Size: 2652 bytes --] #ifndef __SAA716x_PRIV_H #define __SAA716x_PRIV_H #include <linux/interrupt.h> #include <linux/pci.h> #include <linux/sched.h> #include <linux/mutex.h> #include "dvbdev.h" #include "dvb_demux.h" #include "dmxdev.h" #include "dvb_frontend.h" #include "dvb_net.h" #define SAA716x_ERROR 0 #define SAA716x_NOTICE 1 #define SAA716x_INFO 2 #define SAA716x_DEBUG 3 #define dprintk(x, y, z, format, arg...) do { \ if (z) { \ if ((x > SAA716x_ERROR) && (x > y)) \ printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\ else if ((x > SAA716x_NOTICE) && (x > y)) \ printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\ else if ((x > SAA716x_INFO) && (x > y)) \ printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\ else if ((x > SAA716x_DEBUG) && (x > y)) \ printk(KERN_ERR "%s (%d): " format "\n", __func__, saa716x->num, ##arg);\ } else { \ if (x > y) \ printk(format, ##arg); \ } \ } while (0); #define MAKE_ENTRY(subven, subdev, configptr) { \ .vendor = 0x1131, \ .device = 0x7162, \ .subvendor = (subven), \ .subdevice = (subdev), \ .driver_data = (unsigned long) (configptr) \ } #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr)) #define saa716x_read(addr) readl((saa716x->mmio)+(addr)) struct saa716x; typedef int (*saa716x_load_config_t)(struct saa716x *saa716x); struct saa716x_hwconfig { char *model_name; char *dev_type; saa716x_load_config_t load_config; }; struct saa716x_dma { struct tasklet_struct dma_tasklet; }; struct saa716x_dvb { struct dvb_adapter adapter; struct dvb_frontend *fe; struct dvb_demux demux; struct dmxdev dmxdev; struct dmx_frontend fe_hw; struct dmx_frontend fe_mem; struct dvb_net dvbnet; }; struct saa716x_i2c { struct device *dev; struct i2c_adapter adapter; wait_queue_head_t i2c_queue; }; struct saa716x { /* dev priv */ unsigned int verbose; unsigned int num; struct saa716x_hwconfig *hwconfig; /* PCI */ struct pci_dev *pdev; void __iomem *mmio; unsigned int irq; /* I2C */ struct saa716x_i2c i2c_adapter_a; struct saa716x_i2c i2c_adapter_b; /* DMA */ struct saa716x_dma dma_device_a; struct saa716x_dma dma_device_b; /* DVB */ struct saa716x_dvb dvb_device_a; struct saa716x_dvb dvb_device_b; }; extern void saa716x_i2c_disable(struct saa716x *saa716x); extern void saa716x_i2c_enable(struct saa716x *saa716x); extern int saa716x_pcie_init(struct saa716x *saa716x); extern void saa716x_pcie_exit(struct saa716x *saa716x); #endif //__SAA716x_PRIV_H ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 23:03 ` PCIE Manu Abraham @ 2007-05-23 23:51 ` Roland Dreier 2007-05-24 0:07 ` PCIE Manu Abraham 2007-05-24 22:32 ` PCIE Manu Abraham 0 siblings, 2 replies; 38+ messages in thread From: Roland Dreier @ 2007-05-23 23:51 UTC (permalink / raw) To: Manu Abraham; +Cc: Greg KH, linux-pci, linux-kernel > It looks so, from the logs. The only problem is i can't disable the > interrupts, if i write "0" to 0x500, the interrupt/enable register, it > gives me a solid freeze. If i read from the handler, commenting out the > disable interrupts in init, that read also gives me a solid freeze. This > lead me to think that there could be some problem with the MMIO block > access. OK, this looks reasonable: > #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr)) although a) your driver has no hope of working on a system with more than one device of this type; and b) there's really no point in obfuscating a simple use of writel() this way. Why does the device come up in a state where it generates a stream of interrupts as soon as you enable the PCI device? That's somewhat unusual behavior, although certainly not unheard of. This really has the feel of a typical driver bug to me, not anything related to general PCIe access. I've definitely wedged my system many times while trying to poke a device the right way. Also, where are you getting the offset of 0x500 from? Is it possible that the offset is really being given to you in bits (so you should use 0x500 / 8) or 32-bit words (so you should use an offset of 0x500 * 4)? Are the datasheet / programming docs available for this device? I actually have: 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 in one of my systems so I'd be somewhat interested in getting a driver working too. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 23:51 ` PCIE Roland Dreier @ 2007-05-24 0:07 ` Manu Abraham 2007-05-24 22:32 ` PCIE Manu Abraham 1 sibling, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-24 0:07 UTC (permalink / raw) To: Roland Dreier; +Cc: Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > > It looks so, from the logs. The only problem is i can't disable the > > interrupts, if i write "0" to 0x500, the interrupt/enable register, it > > gives me a solid freeze. If i read from the handler, commenting out the > > disable interrupts in init, that read also gives me a solid freeze. This > > lead me to think that there could be some problem with the MMIO block > > access. > > OK, this looks reasonable: > > > #define saa716x_write(dat, addr) writel((dat), (saa716x->mmio)+(addr)) > > although > > a) your driver has no hope of working on a system with more than one > device of this type; and to make it working with more than one device shouldn't be hard once it is going on. > b) there's really no point in obfuscating a simple use of writel() > this way. > > Why does the device come up in a state where it generates a stream of > interrupts as soon as you enable the PCI device? That's somewhat > unusual behavior, although certainly not unheard of. Will ask the vendor, what's going on. > This really has the feel of a typical driver bug to me, not anything > related to general PCIe access. I've definitely wedged my system many > times while trying to poke a device the right way. Yeah, you seem to sound right. > Also, where are you getting the offset of 0x500 from? The register offset is according to the device specs. Of course i already found some wrong offsets etc, maybe this one's wrong too, probably. > Is it possible > that the offset is really being given to you in bits (so you should > use 0x500 / 8) or 32-bit words (so you should use an offset of 0x500 * It says, the base address is currently 500h > 4)? Are the datasheet / programming docs available for this device? Working with this device, under NDA with the vendor. > I actually have: > > 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 > > in one of my systems so I'd be somewhat interested in getting a driver > working too. Cool, won't be that long, just the bridge part remains, most other parts are done or do exist. Thanks, Manu ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-23 23:51 ` PCIE Roland Dreier 2007-05-24 0:07 ` PCIE Manu Abraham @ 2007-05-24 22:32 ` Manu Abraham 2007-05-25 3:25 ` PCIE Roland Dreier 1 sibling, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-24 22:32 UTC (permalink / raw) To: Roland Dreier; +Cc: Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > Why does the device come up in a state where it generates a stream of > interrupts as soon as you enable the PCI device? That's somewhat > unusual behavior, although certainly not unheard of. > In fact the device wasn't generating a stream of interrupts when loaded (i guess). It was just that the shared handler was showing all the interrupts that occurred, since i was not looking at the interrupt mask/status. But accessing any registers caused me a flood of interrupts, which froze the system. excessive printing to the console caused a lockup. I am now wondering whether the usage of MSI would help in this case and that i should be using enable_msi before request_irq ? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-24 22:32 ` PCIE Manu Abraham @ 2007-05-25 3:25 ` Roland Dreier 2007-05-26 15:03 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Roland Dreier @ 2007-05-25 3:25 UTC (permalink / raw) To: Manu Abraham; +Cc: Greg KH, linux-pci, linux-kernel > I am now wondering whether the usage of MSI would help in this case and > that i should be using enable_msi before request_irq ? MSI interrupts are never shared. So if pci_enable_msi() succeeds, you can be sure that the interrupts you get with that IRQ number are coming from your device. But using MSI does not work on all systems, so your driver needs to work with standard (possibly shared) INTx interrupts too. And you should probably provide at least a module flag to disable the use of MSI, to avoid problems on buggy systems. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-25 3:25 ` PCIE Roland Dreier @ 2007-05-26 15:03 ` Manu Abraham 2007-05-26 18:28 ` PCIE Grant Grundler 2007-05-26 22:49 ` PCIE David Miller 0 siblings, 2 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-26 15:03 UTC (permalink / raw) To: Roland Dreier; +Cc: Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > > I am now wondering whether the usage of MSI would help in this case and > > that i should be using enable_msi before request_irq ? > > MSI interrupts are never shared. So if pci_enable_msi() succeeds, you > can be sure that the interrupts you get with that IRQ number are > coming from your device. > i presume then i shouldn't be using IRQF_SHARED, if using MSI. Another question would be if the device supports multiple messages, MSIX should be used ? In such a context, if i request for say more than the messages that i need, say i request 16 messages, but use only 1 or 2, that does bear any consequences ? > But using MSI does not work on all systems, so your driver needs to > work with standard (possibly shared) INTx interrupts too. And you > should probably provide at least a module flag to disable the use of > MSI, to avoid problems on buggy systems. I should probably look for CONFIG_PCI_MSI and check whether the system supports MSI pci_enable_msi() ? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 15:03 ` PCIE Manu Abraham @ 2007-05-26 18:28 ` Grant Grundler 2007-05-26 19:27 ` PCIE Manu Abraham 2007-05-26 22:49 ` PCIE David Miller 1 sibling, 1 reply; 38+ messages in thread From: Grant Grundler @ 2007-05-26 18:28 UTC (permalink / raw) To: Manu Abraham; +Cc: Roland Dreier, Greg KH, linux-pci, linux-kernel On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote: > Roland Dreier wrote: > > > I am now wondering whether the usage of MSI would help in this case and > > > that i should be using enable_msi before request_irq ? > > > > MSI interrupts are never shared. So if pci_enable_msi() succeeds, you > > can be sure that the interrupts you get with that IRQ number are > > coming from your device. > > > > i presume then i shouldn't be using IRQF_SHARED, if using MSI. I'm not sure...but my guess is not. Who ever "just knows", could you please submit a patch to Documentation/MSI-HOWTO.txt ? > Another question would be if the device supports multiple messages, MSIX > should be used ? Yes. Assuming the device supports multiple MSI-X messages. > In such a context, if i request for say more than the messages that i > need, say i request 16 messages, but use only 1 or 2, that does bear any > consequences ? Yes. One is allocating IRQ vectors from a finite number of vectors. But this normally isn't a problem until one gets to larger machines that have more than 4-8 PCI-e or PCI-X slots. Typically, one will limit the number of vectors to the number of CPUs in the system or to how many different events the device can signal. > > But using MSI does not work on all systems, so your driver needs to > > work with standard (possibly shared) INTx interrupts too. And you > > should probably provide at least a module flag to disable the use of > > MSI, to avoid problems on buggy systems. > > I should probably look for CONFIG_PCI_MSI and check whether the system > supports MSI pci_enable_msi() ? pci_enable_msi() will fail if the system doesn't support MSI or something else goes wrong with the call (e.g. already setup). hth, grant ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 18:28 ` PCIE Grant Grundler @ 2007-05-26 19:27 ` Manu Abraham 2007-05-28 1:15 ` PCIE Roland Dreier 0 siblings, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-26 19:27 UTC (permalink / raw) To: Grant Grundler; +Cc: Roland Dreier, Greg KH, linux-pci, linux-kernel [-- Attachment #1: Type: text/plain, Size: 9044 bytes --] Grant Grundler wrote: > On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote: >> Roland Dreier wrote: >>> > I am now wondering whether the usage of MSI would help in this case and >>> > that i should be using enable_msi before request_irq ? >>> >>> MSI interrupts are never shared. So if pci_enable_msi() succeeds, you >>> can be sure that the interrupts you get with that IRQ number are >>> coming from your device. >>> >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > I'm not sure...but my guess is not. Who ever "just knows", could you > please submit a patch to Documentation/MSI-HOWTO.txt ? did a bit of search in the sources, e1000 does avoid using IRQF_SHARED. tg3 uses IRQF_SAMPLE_RANDOM, don't understand why SAMPLE_RANDOM though. >> Another question would be if the device supports multiple messages, MSIX >> should be used ? > > Yes. Assuming the device supports multiple MSI-X messages. > What i read from the specs: 6.2 Message Signals Interrupts The MSI logic is responsible for generating the MSI messages.MSI is an optional feature in PCI Express that enables a device to request a service by writing a system-specified message to a system-specified address (PCI Express DWORD memory write transaction). The write transaction address specifies the MSI message destination and the write transaction data specifies the message including a message “ID”. During device configuration, system software reads the capability list of the logic core to find out whether it supports MSI, and if yes how many different MSI messages it is requesting. Using the multiple message feature allows an PCI Express device to give different MSI messages a unique message ID (e.g. an MSI message initiated by interrupt source #1 gets a different message ID than an MSI message initiated by interrupt source#2). The max. number of requested MSI messages is 32 and must be aligned to a power of two (1,2,4,8,16, or 32). The core will be configured for 32 requested messages, but optionally the default setting of 32 requested messages can be modified by the BOOT logic immediately after power-on-reset (i.e. before device configuration). After reading the capability list, system software initializes the following parameters: - Multiple Message Enable field Defines the number of allowed messages, which is either all or a subsetof the number of requested messages. For example, a PCI Express device can request 4messages and be allocated either four, two, or one message. The number of messages requested and allocated are aligned to a power of two (a PCI Express device that requires three messages must request four) - MSI message destination address Defines the (physical) message destination address of MSI messages. - MSI message data Defines the message data of MSI messages. The main features of the MSI logic are: • MSI capability - 32 different messages - programmable ID in MSI message data field - programmable TC in MSI message address field • Support for MSI delay timer • Support for the following interrupt sources: - DMA channel tag_ack (“buffer_done”) interrupts (12x) - DMA channel overflow interrupts (12x) - A/V interrupts (8x) - I2C interrupts (2x) - unmapped_tc interrupt (1x) - external interrupts from GPIO (16x) - all interrupts edge sensitive with programmable edge polarity - round-robin arbitration between multiple, simultaneous interrupt requests • Support for interrupt masking (i.e. enable/disable) • Support for INT-A emulation • DTL-MMIO target interface for SW access - 4Kbyte address aperture (12bit address / 32bit aligned) - 32bit read and write data >> In such a context, if i request for say more than the messages that i >> need, say i request 16 messages, but use only 1 or 2, that does bear any >> consequences ? > > Yes. One is allocating IRQ vectors from a finite number of vectors. > But this normally isn't a problem until one gets to larger machines that > have more than 4-8 PCI-e or PCI-X slots. Ok. Alongwith this, i am a bit confused with the mailbox approach of sending messages, every register type has it's own set of interrupt registers (for example I2C, say I2C has it's own set of 32 STATUS bitfields for it's interrupt, the same goes for the others) Another aspect is the DTL-MMIO interface, which isn't defined any place. Using the base addresses as an offset to the normal MMIO obtained using pci_resource_*/ioremap() doesn't seem to work at all. Seems like it needs some kind of a translation (guessing here, still no clue yet) The device supports 50 MSI interrupt sources Somewhere else it mentions thus: 6.4Global Register (GREG) The logic provides a set of global registers there are accessible via a device transaction level protocol memory mapped input output interface. Primarily, the global registers are used to control and/or observe logic inside the SAA7160 that is not directly accessible via the device status network. The main features of the GREG logic are: • 16 general purpose global registers • dedicated interfaces to/from the following SAA7160 blocks: - core unit - device transaction level 2 memory transaction level protocol adapter unit - audio/video input unit - Reset unit - I²C to device transaction level unit - pulse synchronization unit • device transaction level protocol memory mapped input output target interface for SW access - 4Kbyte address aperture (12bit address / 32bit aligned) - 32bit read and write data Furthermore, the GREG logic also implements 16 general-purpose global registers that can be used whenever temporary storage of one or more registers is needed. An example here could be a mailbox type of application where an external I²C master writes to GREGvia I2CtoDTL, and system software reads from GREG. It should be noted that the GREG logic does not offer any hardware support for semaphoring, so in case of a mailbox type of application data coherency needs to be ensured in some other way, for example using GPIO. In the SAA7160, the GREG logic has dedicated interfaces to/from the following blocks: • Audio/Video input unit The glue logic inside the Audio/Video input block requires some control to configure them into the desired operating mode. This glue logic inside the A/V input block is controlled via registers in the GREG block. • I²CtoDTL unit The 7bit I²C slave address of the I²CtoDTL block can be defined via register in the GREG logic. The default I²C slave address after reset is 0b1110000. • Reset unit All reset control circuitry is grouped together in the Reset block. Each reset domain can be individually activated and/or released via registers in the GREG logic. • DTL2MTL adapter unit The overflow mode in the DTL2MTL adapter can be enabled/disabled for each DMA channel individually via a register in the GREG logic. • PULSE_SYNC unit The tag_ack filter for MSI in the PULSE_SYNC module can be enabled / disabled via a register in the GREG logic. • Core unit At PCI Express reset, the PCI Express configuration registers inside the core unit will be loaded with “default” values. Most of them are hard-coded. Some others are application dependent and are provided as configuration inputs at the core interface such that their reset values can be defined via registers in the GREG logic. > > Typically, one will limit the number of vectors to the number of CPUs > in the system or to how many different events the device can signal. > >>> But using MSI does not work on all systems, so your driver needs to >>> work with standard (possibly shared) INTx interrupts too. And you >>> should probably provide at least a module flag to disable the use of >>> MSI, to avoid problems on buggy systems. >> I should probably look for CONFIG_PCI_MSI and check whether the system >> supports MSI pci_enable_msi() ? > > pci_enable_msi() will fail if the system doesn't support MSI or something > else goes wrong with the call (e.g. already setup). Ok, so that will be a good choice for testing whether the machine would support MSI or not. Did retouch the code, it looks like as attached, on module load/unload the logs do look like this: [ 239.262464] saa716x_hybrid_probe: Searching for SAA7160/1/2 PCIe Hybrid devices [ 239.262471] saa716x_pcie_init: found a Twinhan VP-6090 device [ 239.262506] PCI: Found IRQ 11 for device 0000:06:00.0 [ 239.262945] PCI: Sharing IRQ 11 with 0000:00:03.0 [ 239.263070] PCI: Sharing IRQ 11 with 0000:00:1a.0 [ 239.263249] PCI: Sharing IRQ 11 with 0000:01:00.0 [ 239.263402] PCI: Setting latency timer of device 0000:06:00.0 to 64 [ 239.263636] SAA7162 Rev 1 [1822:0027], irq: 215, latency: 0 [ 239.263641] IOMEM: 0x32200000-0x32300000 length:0x100000 [ 239.263644] MMIO: 0xe0b80000 [ 239.317087] saa716x_pcie_init (0): Subsys:0xffffffff [ 307.602818] saa716x_pcie_exit (0): Unloading .. [ 307.602824] saa716x_pcie_exit (0): Disabling PCIe Bus Mastering .. [ 307.602853] saa716x_pcie_exit (0): SAA716x mem: 0xe0b80000 A bit confused on how Memory mapped I/O works here Thanks, Manu [-- Attachment #2: saa716x_pci.c --] [-- Type: text/plain, Size: 5453 bytes --] #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/kernel.h> #include <linux/pci.h> #include <asm/io.h> #include <linux/ioport.h> #include <asm/pgtable.h> #include <asm/page.h> #include <linux/types.h> #include <linux/interrupt.h> #include <linux/kmod.h> #include <linux/vmalloc.h> #include <linux/init.h> #include "saa716x_priv.h" #include "saa716x_regs.h" #include "saa716x_budget.h" #define DRIVER_NAME "SAA716x_CORE" unsigned int verbose = 5; module_param(verbose, int, 0644); MODULE_PARM_DESC(verbose, "verbosity level"); static irqreturn_t saa716x_pcie_irq(int irq, void *dev_id) { struct saa716x *saa716x; u32 i2c_stat1, i2c_stat2, mask; if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) { printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__); return IRQ_NONE; } // i2c_stat1 = saa716x_read(0xbfe0); // i2c_stat2 = saa716x_read(0xcfe0); dprintk(verbose, SAA716x_DEBUG, 0, "=== Interrupts[Core A: %04x - Core B: %04x] [", i2c_stat1, i2c_stat2); dprintk(verbose, SAA716x_DEBUG, 0, "] ==\n"); return IRQ_HANDLED; } static irqreturn_t saa716x_pcie_irq_msi(int irq, void *dev_id) { struct saa716x *saa716x; if (unlikely((saa716x = (struct saa716x *) dev_id) == NULL)) { printk(KERN_ERR "%s: Aeie NULL ptr\n", __func__); return IRQ_NONE; } return IRQ_HANDLED; } static int saa716x_request_irq(struct saa716x *saa716x) { u32 flags; int err; flags = IRQF_SHARED; #ifdef CONFIG_PCI_MSI saa716x->have_msi = TRUE; if ((err = pci_enable_msi(saa716x->pdev))) { printk("%s ERROR(%d): unable to allocate MSI Interrupt\n", __func__, err); saa716x->have_msi = FALSE; } if (saa716x->have_msi) { flags &= ~IRQF_SHARED; err = request_irq(saa716x->pdev->irq, &saa716x_pcie_irq_msi, flags, DRIVER_NAME, saa716x); if (err) printk("%s ERROR(%d): Unable to allocate Interrupt\n", __func__, err); } else #endif if ((err = request_irq(saa716x->pdev->irq, &saa716x_pcie_irq, flags, DRIVER_NAME, saa716x)) != 0) printk("%s ERROR(%d): Unable to allocate Interrupt\n", __func__, err); return err; } static void saa716x_free_irq(struct saa716x *saa716x) { free_irq(saa716x->pdev->irq, saa716x); #ifdef CONFIG_PCI_MSI if (saa716x->have_msi) pci_disable_msi(saa716x->pdev); #endif } int saa716x_pcie_init(struct saa716x *saa716x) { struct pci_dev *pdev = saa716x->pdev; int err = 0; u8 latency, revision; u32 i2c_stat, int_stat, flags, subsys; unsigned long mmio_start, mmio_len; printk(KERN_INFO "%s: found a %s device\n", __func__, saa716x->hwconfig->model_name); pci_set_drvdata(pdev, saa716x); if ((err = pci_enable_device(pdev)) != 0) { printk(KERN_ERR "%s ERROR: pci enable failed (%i)\n", __func__, err); goto fail0; } if (!(pci_resource_flags(pdev, BAR_0) & IORESOURCE_MEM)) { printk(KERN_ERR "Cannot find proper PCIe device " "base addrress, aborting.\n"); err = -ENODEV; goto fail1; } if ((err = pci_request_region(pdev, BAR_0, DRIVER_NAME)) < 0) { printk(KERN_ERR "%s ERROR: mem region request failed\n", __func__); err = -ENOMEM; goto fail1; } pci_set_master(pdev); mmio_start = pci_resource_start(pdev, BAR_0); mmio_len = pci_resource_len(pdev, BAR_0); err = -EIO; if (!(saa716x->mmio = ioremap(mmio_start, mmio_len))) goto fail2; saa716x->mmio_start = mmio_start; saa716x->mmio_end = mmio_start + mmio_len; err = saa716x_request_irq(saa716x); if (err) goto fail2; pci_read_config_byte(pdev, PCI_LATENCY_TIMER, &latency); pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision); dprintk(verbose, SAA716x_ERROR, 0, " SAA7162 Rev %d [%04x:%04x], ", revision, saa716x->pdev->subsystem_vendor, saa716x->pdev->subsystem_device); dprintk(verbose, SAA716x_ERROR, 0, "irq: %d, latency: %d\n IOMEM: 0x%lx-0x%lx length:0x%lx\n", saa716x->pdev->irq, latency, saa716x->mmio_start, saa716x->mmio_end, mmio_len); dprintk(verbose, SAA716x_ERROR, 0, " MMIO: 0x%p\n", saa716x->mmio); saa716x->verbose = verbose; // init_waitqueue_head(&saa716x->i2c_queue); /* Disable all interrupts here */ // saa716x_write(0, 0x500); // i2c_stat = saa716x_read(0xb008); // int_stat = saa716x_read(0x500); // dprintk(verbose, SAA716x_ERROR, 1, "I2C Status=[0x%04x]", i2c_stat); // dprintk(verbose, SAA716x_ERROR, 1, "INT Status=[0x%04x]", int_stat); subsys = saa716x_read(0x00012000); dprintk(verbose, SAA716x_ERROR, 1, "Subsys:0x%04x", subsys); return 0; fail2: iounmap(saa716x->mmio); release_mem_region(pci_resource_start(saa716x->pdev, 0), pci_resource_len(saa716x->pdev, 0)); fail1: pci_disable_device(pdev); fail0: pci_set_drvdata(pdev, NULL); return err; } EXPORT_SYMBOL_GPL(saa716x_pcie_init); void saa716x_pcie_exit(struct saa716x *saa716x) { struct pci_dev *pdev = saa716x->pdev; u8 command; dprintk(verbose, SAA716x_ERROR, 1, "Unloading .. "); dprintk(verbose, SAA716x_ERROR, 1, "Disabling PCIe Bus Mastering .."); pci_read_config_byte(pdev, PCI_COMMAND, &command); command &= ~PCI_COMMAND_MASTER; pci_write_config_byte(pdev, PCI_COMMAND, command); saa716x_free_irq(saa716x); dprintk(verbose, SAA716x_NOTICE, 1, "SAA716x mem: 0x%p", saa716x->mmio); iounmap(saa716x->mmio); release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0)); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); } EXPORT_SYMBOL_GPL(saa716x_pcie_exit); MODULE_DESCRIPTION("SAA716x PCIe bridge driver"); MODULE_AUTHOR("Manu Abraham"); MODULE_LICENSE("GPL"); ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 19:27 ` PCIE Manu Abraham @ 2007-05-28 1:15 ` Roland Dreier 2007-05-28 1:25 ` PCIE Manu Abraham 2007-05-28 2:04 ` PCIE Manu Abraham 0 siblings, 2 replies; 38+ messages in thread From: Roland Dreier @ 2007-05-28 1:15 UTC (permalink / raw) To: Manu Abraham; +Cc: Grant Grundler, Greg KH, linux-pci, linux-kernel > >> Another question would be if the device supports multiple messages, MSIX > >> should be used ? > > > > Yes. Assuming the device supports multiple MSI-X messages. At least on my device (PCI ID 1131:7162) there is no MSI-X capability, so that's not an option for you. The current Linux implementation does not support more than one MSI interrupt, so you just get one interrupt with pci_enable_msi(). I think it's probably simplest for you to forget about MSI until you have the basic driver working. > Ok. Alongwith this, i am a bit confused with the mailbox approach of > sending messages, every register type has it's own set of interrupt > registers (for example I2C, say I2C has it's own set of 32 STATUS > bitfields for it's interrupt, the same goes for the others) > > Another aspect is the DTL-MMIO interface, which isn't defined any place. > Using the base addresses as an offset to the normal MMIO obtained using > pci_resource_*/ioremap() doesn't seem to work at all. > [etc....] All this is device-specific stuff ... not sure how much anyone can help you if you can't share the docs. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 1:15 ` PCIE Roland Dreier @ 2007-05-28 1:25 ` Manu Abraham 2007-05-28 2:04 ` PCIE Manu Abraham 1 sibling, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-28 1:25 UTC (permalink / raw) To: Roland Dreier; +Cc: Grant Grundler, Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > > >> Another question would be if the device supports multiple messages, MSIX > > >> should be used ? > > > > > > Yes. Assuming the device supports multiple MSI-X messages. > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > so that's not an option for you. The current Linux implementation > does not support more than one MSI interrupt, so you just get one > interrupt with pci_enable_msi(). > > I think it's probably simplest for you to forget about MSI until you > have the basic driver working. Damn. The NXP guys don't want me to go ahead with the generic registers. What they said : > And if you really use the SAA7162 in the PC application, > pls ignore the 0x520 ..... > That's not a good decision to use that. Might need to ask them why it would not be a good decision then. :-( ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 1:15 ` PCIE Roland Dreier 2007-05-28 1:25 ` PCIE Manu Abraham @ 2007-05-28 2:04 ` Manu Abraham 2007-05-28 2:24 ` PCIE Roland Dreier 1 sibling, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-28 2:04 UTC (permalink / raw) To: Roland Dreier; +Cc: Grant Grundler, Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > > >> Another question would be if the device supports multiple messages, MSIX > > >> should be used ? > > > > > > Yes. Assuming the device supports multiple MSI-X messages. > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > so that's not an option for you. The current Linux implementation > does not support more than one MSI interrupt, so you just get one > interrupt with pci_enable_msi(). This would mean MSI or MSI-X ? A bit confused now. • MSI capability - 32 different messages - programmable ID in MSI message data field - programmable TC in MSI message address field ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 2:04 ` PCIE Manu Abraham @ 2007-05-28 2:24 ` Roland Dreier 2007-05-28 2:47 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Roland Dreier @ 2007-05-28 2:24 UTC (permalink / raw) To: Manu Abraham; +Cc: Grant Grundler, Greg KH, linux-pci, linux-kernel > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > > so that's not an option for you. The current Linux implementation > > does not support more than one MSI interrupt, so you just get one > > interrupt with pci_enable_msi(). > > This would mean MSI or MSI-X ? A bit confused now. As I said, the device I have in my system: 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 Subsystem: Animation Technologies Inc. Unknown device 0820 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 90200000 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable- Capabilities: [50] Express Endpoint IRQ 0 Capabilities: [74] Power Management version 2 Capabilities: [80] Vendor Specific Information ...has only an MSI capability (the "[40] Message Signalled Interrupts" line). So MSI-X is not possible, since the device cannot do it. And that means you can at most do pci_enable_msi(). The current Linux MSI support only handles a single interrupt, just like you get normally (no matter how many MSI interrupts a device can handle). To get multiple interrupts from a single device under Linux, you must use MSI-X and pci_enable_msix -- but for this to work, your device must support MSI-X of course. A device that supports both MSI and MSI-X would look like: 0b:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] (rev 20) Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fc600000 (64-bit, non-prefetchable) [size=1M] Memory at d8800000 (64-bit, prefetchable) [size=8M] Capabilities: [40] Power Management version 2 Capabilities: [48] Vital Product Data Capabilities: [90] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable- Capabilities: [84] MSI-X: Enable- Mask- TabSize=32 Capabilities: [60] Express Endpoint IRQ 0 with both "Message Signalled Interrupts" and "MSI-X" capabilities. However, as I said before I think you shouldn't worry about MSI right now. Since there are many systems where MSI doesn't work, you'll need to get the driver working with legacy (INTx) interrupts anyway. And you seem to be in a bit over your head just doing that without adding the complexity of MSI on top, hence my recommendation to just focus on the basic driver. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 2:24 ` PCIE Roland Dreier @ 2007-05-28 2:47 ` Manu Abraham 0 siblings, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-28 2:47 UTC (permalink / raw) To: Roland Dreier; +Cc: Grant Grundler, Greg KH, linux-pci, linux-kernel Roland Dreier wrote: > > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability, > > > so that's not an option for you. The current Linux implementation > > > does not support more than one MSI interrupt, so you just get one > > > interrupt with pci_enable_msi(). > > > > This would mean MSI or MSI-X ? A bit confused now. > > As I said, the device I have in my system: > > 02:00.0 Multimedia controller: Philips Semiconductors Unknown device 7162 > Subsystem: Animation Technologies Inc. Unknown device 0820 > Flags: bus master, fast devsel, latency 0, IRQ 11 > Memory at 90200000 (64-bit, non-prefetchable) [size=1M] > Capabilities: [40] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable- > Capabilities: [50] Express Endpoint IRQ 0 > Capabilities: [74] Power Management version 2 > Capabilities: [80] Vendor Specific Information > > ...has only an MSI capability (the "[40] Message Signalled Interrupts" > line). So MSI-X is not possible, since the device cannot do it. And > that means you can at most do pci_enable_msi(). The current Linux MSI > support only handles a single interrupt, just like you get normally > (no matter how many MSI interrupts a device can handle). To get > multiple interrupts from a single device under Linux, you must use > MSI-X and pci_enable_msix -- but for this to work, your device must > support MSI-X of course. > > A device that supports both MSI and MSI-X would look like: > > 0b:00.0 InfiniBand: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] (rev 20) > Subsystem: Mellanox Technologies MT25204 [InfiniHost III Lx HCA] > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at fc600000 (64-bit, non-prefetchable) [size=1M] > Memory at d8800000 (64-bit, prefetchable) [size=8M] > Capabilities: [40] Power Management version 2 > Capabilities: [48] Vital Product Data > Capabilities: [90] Message Signalled Interrupts: Mask- 64bit+ Queue=0/5 Enable- > Capabilities: [84] MSI-X: Enable- Mask- TabSize=32 > Capabilities: [60] Express Endpoint IRQ 0 > > with both "Message Signalled Interrupts" and "MSI-X" capabilities. > Thanks for the explanation. > However, as I said before I think you shouldn't worry about MSI right > now. Since there are many systems where MSI doesn't work, you'll need > to get the driver working with legacy (INTx) interrupts anyway. And > you seem to be in a bit over your head just doing that without adding > the complexity of MSI on top, hence my recommendation to just focus on > the basic driver. True, compatibility would be important. Thanks, Manu ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 15:03 ` PCIE Manu Abraham 2007-05-26 18:28 ` PCIE Grant Grundler @ 2007-05-26 22:49 ` David Miller 2007-05-26 22:57 ` PCIE Manu Abraham ` (3 more replies) 1 sibling, 4 replies; 38+ messages in thread From: David Miller @ 2007-05-26 22:49 UTC (permalink / raw) To: abraham.manu; +Cc: rdreier, greg, linux-pci, linux-kernel From: Manu Abraham <abraham.manu@gmail.com> Date: Sat, 26 May 2007 19:03:12 +0400 > i presume then i shouldn't be using IRQF_SHARED, if using MSI. That's actually a really good question. It is likely architecture dependant whether the PCI controller wires unique MSI interrupts to shared cpu interrupt lines. I can imagine many systems where the cpu simply doesn't have enough interrupt pins to uniquely identify every possible MSI interrupt source. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 22:49 ` PCIE David Miller @ 2007-05-26 22:57 ` Manu Abraham 2007-05-26 23:55 ` PCIE Grant Grundler ` (2 subsequent siblings) 3 siblings, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-26 22:57 UTC (permalink / raw) To: David Miller; +Cc: rdreier, greg, linux-pci, linux-kernel David Miller wrote: > From: Manu Abraham <abraham.manu@gmail.com> > Date: Sat, 26 May 2007 19:03:12 +0400 > >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. > > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. > Ok, that explains it a bit, but i am pulling out a bit of hair on the other aspects i wrote in this thread, of course i am a bit new to PCIe and hence all my questions/doubts. Hope someone can clear them. Thanks, Manu ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 22:49 ` PCIE David Miller 2007-05-26 22:57 ` PCIE Manu Abraham @ 2007-05-26 23:55 ` Grant Grundler 2007-05-27 0:00 ` PCIE David Miller 2007-05-27 2:34 ` PCIE H. Peter Anvin 2007-05-28 1:03 ` PCIE Roland Dreier 3 siblings, 1 reply; 38+ messages in thread From: Grant Grundler @ 2007-05-26 23:55 UTC (permalink / raw) To: David Miller; +Cc: abraham.manu, rdreier, greg, linux-pci, linux-kernel On Sat, May 26, 2007 at 03:49:10PM -0700, David Miller wrote: > From: Manu Abraham <abraham.manu@gmail.com> > Date: Sat, 26 May 2007 19:03:12 +0400 > > > i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. MSI (and MSI-X) vectors are required to be exclusive. I submitted that change to pci.txt last year: http://lkml.org/lkml/2006/12/25/2 and ISTR I've posted that bit of the PCI spec a few years ago. But it probably was to linux-pci mailing list only. > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. The cpus haven't been using interrupt pins for a long time now. Anything with a Local-xAPIC is already using transactions to signal interrupts even if the OS isn't aware of it. hth, grant ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 23:55 ` PCIE Grant Grundler @ 2007-05-27 0:00 ` David Miller 2007-05-27 0:16 ` PCIE Grant Grundler 2007-05-28 1:10 ` PCIE Roland Dreier 0 siblings, 2 replies; 38+ messages in thread From: David Miller @ 2007-05-27 0:00 UTC (permalink / raw) To: grundler; +Cc: abraham.manu, rdreier, greg, linux-pci, linux-kernel From: Grant Grundler <grundler@parisc-linux.org> Date: Sat, 26 May 2007 17:55:15 -0600 > MSI (and MSI-X) vectors are required to be exclusive. > I submitted that change to pci.txt last year: > http://lkml.org/lkml/2006/12/25/2 > > and ISTR I've posted that bit of the PCI spec a few years ago. > But it probably was to linux-pci mailing list only. This requirement only extends to the PCI host controller, how that interfaces to the cpu and it's limitations is an entirely other matter. > > I can imagine many systems where the cpu simply doesn't have enough > > interrupt pins to uniquely identify every possible MSI interrupt > > source. > > The cpus haven't been using interrupt pins for a long time now. > Anything with a Local-xAPIC is already using transactions to > signal interrupts even if the OS isn't aware of it. I'm not talking about x86, x86_64, et al. I'm talking about embedded ARM chips and the like, and yes they very possibly will be using PCI-E controllers at some point. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 0:00 ` PCIE David Miller @ 2007-05-27 0:16 ` Grant Grundler 2007-05-27 0:30 ` PCIE David Miller 2007-05-28 1:10 ` PCIE Roland Dreier 1 sibling, 1 reply; 38+ messages in thread From: Grant Grundler @ 2007-05-27 0:16 UTC (permalink / raw) To: David Miller Cc: grundler, abraham.manu, rdreier, greg, linux-pci, linux-kernel On Sat, May 26, 2007 at 05:00:39PM -0700, David Miller wrote: > From: Grant Grundler <grundler@parisc-linux.org> > Date: Sat, 26 May 2007 17:55:15 -0600 > > > MSI (and MSI-X) vectors are required to be exclusive. > > I submitted that change to pci.txt last year: > > http://lkml.org/lkml/2006/12/25/2 > > > > and ISTR I've posted that bit of the PCI spec a few years ago. > > But it probably was to linux-pci mailing list only. > > This requirement only extends to the PCI host controller, > how that interfaces to the cpu and it's limitations is > an entirely other matter. Are they really? The device is generating the transaction on the bus. The PCI host controller (in general) will be routing that transaction to wherever the "dest addr" of the MSI lives. It doesn't have to be in the CPU but it will certainly be a proxy for that CPU if it's not. We won't care if the proxy only have one IRQ line going to the CPU as long as the de-muxing of the "data" portion results in a unique identifier that can be mapped to exactly one interrupt handler. > > The cpus haven't been using interrupt pins for a long time now. > > Anything with a Local-xAPIC is already using transactions to > > signal interrupts even if the OS isn't aware of it. > > I'm not talking about x86, x86_64, et al. > > I'm talking about embedded ARM chips and the like, and yes they > very possibly will be using PCI-E controllers at some point. It doesn't matter if it's embedded or not. Trying to share what is the equivalent to an "edge triggered" interrupt is futile. MSI "vectors" need to be exclusive. thanks, grant ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 0:16 ` PCIE Grant Grundler @ 2007-05-27 0:30 ` David Miller 2007-05-27 1:01 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: David Miller @ 2007-05-27 0:30 UTC (permalink / raw) To: grundler; +Cc: abraham.manu, rdreier, greg, linux-pci, linux-kernel From: Grant Grundler <grundler@parisc-linux.org> Date: Sat, 26 May 2007 18:16:31 -0600 > Are they really? The device is generating the transaction on the bus. > The PCI host controller (in general) will be routing that transaction > to wherever the "dest addr" of the MSI lives. It doesn't have to be > in the CPU but it will certainly be a proxy for that CPU if it's not. > We won't care if the proxy only have one IRQ line going to the CPU > as long as the de-muxing of the "data" portion results in a unique > identifier that can be mapped to exactly one interrupt handler. True, on sparc64 PCI-E controllers, for example, the MSI vector is received by the PCI-E host controller, and the host controller turns this into a cpu format interrupt packet for the system bus. I guess on IRQ pin starved systems, the PCI-E host controller or something similar would get interrogated by the cpu for the MSI vector number. I don't want to be the person who has to code up support for that, as it's not easy to shim mid-level vectoring into the generic IRQ layer currently. I'd love to be able to do that on sparc64 instead of what arch/sparc64/kernel/pci_sun4v.c's pci_sun4v_msi_prehandler() is doing. There is a lot of information and vectoring capabilities present that I'm simply not taking advantage of yet :-) ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 0:30 ` PCIE David Miller @ 2007-05-27 1:01 ` Manu Abraham 2007-05-27 1:49 ` PCIE Grant Grundler 0 siblings, 1 reply; 38+ messages in thread From: Manu Abraham @ 2007-05-27 1:01 UTC (permalink / raw) To: David Miller; +Cc: grundler, rdreier, greg, linux-pci, linux-kernel David Miller wrote: > From: Grant Grundler <grundler@parisc-linux.org> > Date: Sat, 26 May 2007 18:16:31 -0600 > >> Are they really? The device is generating the transaction on the bus. >> The PCI host controller (in general) will be routing that transaction >> to wherever the "dest addr" of the MSI lives. It doesn't have to be >> in the CPU but it will certainly be a proxy for that CPU if it's not. >> We won't care if the proxy only have one IRQ line going to the CPU >> as long as the de-muxing of the "data" portion results in a unique >> identifier that can be mapped to exactly one interrupt handler. > > True, on sparc64 PCI-E controllers, for example, the MSI vector is > received by the PCI-E host controller, and the host controller turns > this into a cpu format interrupt packet for the system bus. Err .. why would a PCIe controller be CPU specific ? Looking at Figure 1-6 of the spec, i think it should be CPU independent ? Excuse me for my ignorance, just that my head has begun to reel after reading through PCIe 1.0 and the device specs, still being inconclusive how to proceed. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 1:01 ` PCIE Manu Abraham @ 2007-05-27 1:49 ` Grant Grundler 2007-05-27 20:28 ` PCIE Manu Abraham 0 siblings, 1 reply; 38+ messages in thread From: Grant Grundler @ 2007-05-27 1:49 UTC (permalink / raw) To: Manu Abraham; +Cc: linux-pci, linux-kernel On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote: > David Miller wrote: > > True, on sparc64 PCI-E controllers, for example, the MSI vector is > > received by the PCI-E host controller, and the host controller turns > > this into a cpu format interrupt packet for the system bus. > > Err .. why would a PCIe controller be CPU specific ? Looking at Figure > 1-6 of the spec, i think it should be CPU independent ? To be pedantic, the PCIe controller isn't really CPU specific. It's host bus specific. ie the PCI-e controller is a bridge between whatever chipset defines the "cache coherency domain" and the PCI-e devices. > Excuse me for my ignorance, just that my head has begun to reel after > reading through PCIe 1.0 and the device specs, still being inconclusive > how to proceed. no problem...I suspect you need to figure out why DTL-MMIO isn't working. I have never touched DTL and can't be of much help with that. hth, grant ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 1:49 ` PCIE Grant Grundler @ 2007-05-27 20:28 ` Manu Abraham 0 siblings, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-27 20:28 UTC (permalink / raw) To: Grant Grundler; +Cc: linux-pci, linux-kernel Grant Grundler wrote: > On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote: >> David Miller wrote: >>> True, on sparc64 PCI-E controllers, for example, the MSI vector is >>> received by the PCI-E host controller, and the host controller turns >>> this into a cpu format interrupt packet for the system bus. >> Err .. why would a PCIe controller be CPU specific ? Looking at Figure >> 1-6 of the spec, i think it should be CPU independent ? > > To be pedantic, the PCIe controller isn't really CPU specific. > It's host bus specific. ie the PCI-e controller is a bridge between > whatever chipset defines the "cache coherency domain" and the PCI-e devices. > >> Excuse me for my ignorance, just that my head has begun to reel after >> reading through PCIe 1.0 and the device specs, still being inconclusive >> how to proceed. > > no problem...I suspect you need to figure out why DTL-MMIO isn't working. > I have never touched DTL and can't be of much help with that. > Have been reading a bit about DTL and so on. Haven't reached anything much solid yet. Will have something soon i presume. Thanks for the comments. Regards, Manu ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 0:00 ` PCIE David Miller 2007-05-27 0:16 ` PCIE Grant Grundler @ 2007-05-28 1:10 ` Roland Dreier 1 sibling, 0 replies; 38+ messages in thread From: Roland Dreier @ 2007-05-28 1:10 UTC (permalink / raw) To: David Miller; +Cc: grundler, abraham.manu, greg, linux-pci, linux-kernel > I'm talking about embedded ARM chips and the like, and yes they > very possibly will be using PCI-E controllers at some point. As an example the AMCC PowerPC 440SPe, which is an embedded SoC with an onboard PCIe controller that supports three ports, has 24 MSI interrupts that external PCIe devices can raise. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 22:49 ` PCIE David Miller 2007-05-26 22:57 ` PCIE Manu Abraham 2007-05-26 23:55 ` PCIE Grant Grundler @ 2007-05-27 2:34 ` H. Peter Anvin 2007-05-27 7:40 ` PCIE David Miller 2007-05-28 1:05 ` PCIE Roland Dreier 2007-05-28 1:03 ` PCIE Roland Dreier 3 siblings, 2 replies; 38+ messages in thread From: H. Peter Anvin @ 2007-05-27 2:34 UTC (permalink / raw) To: David Miller; +Cc: abraham.manu, rdreier, greg, linux-pci, linux-kernel David Miller wrote: > >> i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. > > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. There are systems which only get a single bit indication that an MSI has happened. Presumably we need something like IRQF_MSI which can be set as appropriate depending on the architecture? -hpa ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 2:34 ` PCIE H. Peter Anvin @ 2007-05-27 7:40 ` David Miller 2007-05-27 20:31 ` PCIE Manu Abraham 2007-05-28 1:05 ` PCIE Roland Dreier 1 sibling, 1 reply; 38+ messages in thread From: David Miller @ 2007-05-27 7:40 UTC (permalink / raw) To: hpa; +Cc: abraham.manu, rdreier, greg, linux-pci, linux-kernel From: "H. Peter Anvin" <hpa@zytor.com> Date: Sat, 26 May 2007 19:34:26 -0700 > There are systems which only get a single bit indication that an MSI has > happened. > > Presumably we need something like IRQF_MSI which can be set as > appropriate depending on the architecture? Although I don't want to make the IRQ handling subsystems any more complicated than they already are, one idea I floated around is that we could seperate CPU irq numbers (the things we pass around today) and MSI vector numbers. But I immediately understand how that is unnecessary to some extent, any platform which needs to deal with that kind of distinction can use virtual IRQ numbers like sparc64 and powerpc do. Sparc64 PCI-E controllers, for example, allow you to group several MSIs into a 'group', and the interrupt source is for the group rather than the individual MSIs. When the MSI group interrupt arrives, you get a descriptor in a per-MSI-group ring buffer that describes the MSI that arrived. This descriptor in fact passes on a ton of interesting information, see arch/sparc64/kernel/pci_sun4v.c:pci_sun4v_msiq_entry. It gives you the type, the system TSC value at the time of interrupt arrival (so you could do incredibly cool profiling with this), the PCI bus/device/fn that generated the MSI vector, the MSI address that was signalled, the MSI data field, and full information for PCI-E MSG packets including bus/dev/fn of target, the message routing code, and the message code. But we use none of these facilities currently because it's either impossible or too cumbersome to be useful at the moment. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 7:40 ` PCIE David Miller @ 2007-05-27 20:31 ` Manu Abraham 0 siblings, 0 replies; 38+ messages in thread From: Manu Abraham @ 2007-05-27 20:31 UTC (permalink / raw) To: David Miller; +Cc: hpa, rdreier, greg, linux-pci, linux-kernel David Miller wrote: > From: "H. Peter Anvin" <hpa@zytor.com> > Date: Sat, 26 May 2007 19:34:26 -0700 > >> There are systems which only get a single bit indication that an MSI has >> happened. >> >> Presumably we need something like IRQF_MSI which can be set as >> appropriate depending on the architecture? > > Although I don't want to make the IRQ handling subsystems any more > complicated than they already are, one idea I floated around is that > we could seperate CPU irq numbers (the things we pass around today) > and MSI vector numbers. > > But I immediately understand how that is unnecessary to some extent, > any platform which needs to deal with that kind of distinction can use > virtual IRQ numbers like sparc64 and powerpc do. > > Sparc64 PCI-E controllers, for example, allow you to group several > MSIs into a 'group', and the interrupt source is for the group rather > than the individual MSIs. When the MSI group interrupt arrives, you > get a descriptor in a per-MSI-group ring buffer that describes the MSI > that arrived. > > This descriptor in fact passes on a ton of interesting information, > see arch/sparc64/kernel/pci_sun4v.c:pci_sun4v_msiq_entry. > > It gives you the type, the system TSC value at the time of interrupt > arrival (so you could do incredibly cool profiling with this), > the PCI bus/device/fn that generated the MSI vector, the MSI address > that was signalled, the MSI data field, and full information for PCI-E > MSG packets including bus/dev/fn of target, the message routing code, > and the message code. > > But we use none of these facilities currently because it's either > impossible or too cumbersome to be useful at the moment. > I think it is better to use IRQF_MSI as HPA suggested, since IRQF_SHARED is a bit confusing thing altogether since MSI doesn't share interrupts. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-27 2:34 ` PCIE H. Peter Anvin 2007-05-27 7:40 ` PCIE David Miller @ 2007-05-28 1:05 ` Roland Dreier 1 sibling, 0 replies; 38+ messages in thread From: Roland Dreier @ 2007-05-28 1:05 UTC (permalink / raw) To: H. Peter Anvin; +Cc: David Miller, abraham.manu, greg, linux-pci, linux-kernel > Presumably we need something like IRQF_MSI which can be set as > appropriate depending on the architecture? Unfortunately I don't think it's that simple -- drivers would have to do something like if (IRQF_MSI == IRQF_SHARED) { // lose MSI optimizations, do an MMIO read, etc. } else... As I said I think that if we're running on a system where MSI interrupts might be shared, we should just have pci_enable_msi() fail so drivers fall back to their usual interrupt handler. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-26 22:49 ` PCIE David Miller ` (2 preceding siblings ...) 2007-05-27 2:34 ` PCIE H. Peter Anvin @ 2007-05-28 1:03 ` Roland Dreier 2007-05-28 2:54 ` PCIE David Miller ` (2 more replies) 3 siblings, 3 replies; 38+ messages in thread From: Roland Dreier @ 2007-05-28 1:03 UTC (permalink / raw) To: David Miller; +Cc: abraham.manu, greg, linux-pci, linux-kernel > > i presume then i shouldn't be using IRQF_SHARED, if using MSI. > > That's actually a really good question. > > It is likely architecture dependant whether the PCI controller wires > unique MSI interrupts to shared cpu interrupt lines. Yes, but current Linux drivers assume that MSI interrupts are non-shared. Certainly in my drivers I make that assumption, and from a quick look neither tg3 nor e1000 sets IRQF_SHARED if they enable MSI. I think that if we run on a system where MSI interrupts may be shared, then we should just have pci_enable_msi() fail. If drivers have to allow for shared MSI interrupts, then they lose most of the advantage of MSI -- if I get an MSI but I don't know it came from my device, I probably have to do an MMIO read to find out if it's mine or not and also to preserve DMA ordering, which kills the main advantage of MSI. And since MSIs are basically edge triggered, sharing vectors is going to lead to all sorts of hassles. > I can imagine many systems where the cpu simply doesn't have enough > interrupt pins to uniquely identify every possible MSI interrupt > source. I have a hard time imagining a PCI host bus controller that converts MSI interrupts back to wire interrupts that go to pins on the CPU. For one thing it would be hard to maintain the guarantee that MSI interrupts can't pass DMAs. And it would be an absolutely silly architecture too. - R. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 1:03 ` PCIE Roland Dreier @ 2007-05-28 2:54 ` David Miller 2007-05-28 4:18 ` PCIE Grant Grundler 2007-05-28 5:22 ` PCIE H. Peter Anvin 2 siblings, 0 replies; 38+ messages in thread From: David Miller @ 2007-05-28 2:54 UTC (permalink / raw) To: rdreier; +Cc: abraham.manu, greg, linux-pci, linux-kernel From: Roland Dreier <rdreier@cisco.com> Date: Sun, 27 May 2007 18:03:29 -0700 > I have a hard time imagining a PCI host bus controller that converts > MSI interrupts back to wire interrupts that go to pins on the CPU. > For one thing it would be hard to maintain the guarantee that > MSI interrupts can't pass DMAs. And it would be an absolutely silly > architecture too. We are definitely going to see systems like this, and the DMA issue will be taken care of by the PCI host controller, it will either pull out all queued up DMA writes by the device in question itself (somehow) or require the driver for the PCI host controller do a dummy read out to the device before servicing an interrupt handler to guanentee this semantic. We already have pre-PCI-E controllers on sparc64 where I have to do a dummy config space read to pull out all the pending DMA requests before servicing an interrupt, so this kind of scheme would be nothing new. People are going to use PCI-E on very inexpensive and primitive cpu platforms. The thing to do for such platforms is the use virtual IRQ numbers and interrogate the PCI-E controller for the MSI number when the CPU level interrupt arrives and translate that into the appropriate virtual IRQ. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 1:03 ` PCIE Roland Dreier 2007-05-28 2:54 ` PCIE David Miller @ 2007-05-28 4:18 ` Grant Grundler 2007-05-28 5:23 ` PCIE H. Peter Anvin 2007-05-28 5:22 ` PCIE H. Peter Anvin 2 siblings, 1 reply; 38+ messages in thread From: Grant Grundler @ 2007-05-28 4:18 UTC (permalink / raw) To: Roland Dreier; +Cc: David Miller, abraham.manu, greg, linux-pci, linux-kernel On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote: ... > > I can imagine many systems where the cpu simply doesn't have enough > > interrupt pins to uniquely identify every possible MSI interrupt > > source. > > I have a hard time imagining a PCI host bus controller that converts > MSI interrupts back to wire interrupts that go to pins on the CPU. > For one thing it would be hard to maintain the guarantee that > MSI interrupts can't pass DMAs. Whatever converts the MSI back to CPU IRQ pins would have to participate in the "cache coherency domain". This would avoid issues around DMA ordering. It _could_ be on the same silicon as the PCI Host bus controller as long as the above is true. > And it would be an absolutely silly architecture too. While I agree it's silly, it might be cheaper if any patents are involved, it reduces complexity, power consumption or anything else that costs time/money. thanks, grant ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 4:18 ` PCIE Grant Grundler @ 2007-05-28 5:23 ` H. Peter Anvin 0 siblings, 0 replies; 38+ messages in thread From: H. Peter Anvin @ 2007-05-28 5:23 UTC (permalink / raw) To: Grant Grundler Cc: Roland Dreier, David Miller, abraham.manu, greg, linux-pci, linux-kernel Grant Grundler wrote: > On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote: > ... >> > I can imagine many systems where the cpu simply doesn't have enough >> > interrupt pins to uniquely identify every possible MSI interrupt >> > source. >> >> I have a hard time imagining a PCI host bus controller that converts >> MSI interrupts back to wire interrupts that go to pins on the CPU. >> For one thing it would be hard to maintain the guarantee that >> MSI interrupts can't pass DMAs. > > Whatever converts the MSI back to CPU IRQ pins would have to participate > in the "cache coherency domain". This would avoid issues around DMA ordering. > It _could_ be on the same silicon as the PCI Host bus controller as long > as the above is true. > Also, don't forget that a lot of platforms provide *no* hardware cache coherency. -hpa ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: PCIE 2007-05-28 1:03 ` PCIE Roland Dreier 2007-05-28 2:54 ` PCIE David Miller 2007-05-28 4:18 ` PCIE Grant Grundler @ 2007-05-28 5:22 ` H. Peter Anvin 2 siblings, 0 replies; 38+ messages in thread From: H. Peter Anvin @ 2007-05-28 5:22 UTC (permalink / raw) To: Roland Dreier; +Cc: David Miller, abraham.manu, greg, linux-pci, linux-kernel Roland Dreier wrote: > > I have a hard time imagining a PCI host bus controller that converts > MSI interrupts back to wire interrupts that go to pins on the CPU. > For one thing it would be hard to maintain the guarantee that > MSI interrupts can't pass DMAs. And it would be an absolutely silly > architecture too. > Well, on pretty much all CPUs interrupts sooner or later are combined to an interrupt signal (not necessarily an external pin) on the CPU indicating that an interrupt has happened. On many CPUs demultiplex is then done in software. As I said, I have seen at least one architecture where MSIs are treated as nothing other than another PCI interrupt -- you get five status bits from the PCI unit -- INTA, INTB, INTC, INTD, MSI. Needless to say, I didn't bother enabling MSI on that platform. Even if it had worked correctly, which I kind of doubt, it would probably have been a net loss. -hpa ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2007-05-28 5:25 UTC | newest] Thread overview: 38+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-05-23 12:15 PCIE Manu Abraham 2007-05-23 15:59 ` PCIE Greg KH 2007-05-23 20:59 ` PCIE Manu Abraham 2007-05-23 21:10 ` PCIE Roland Dreier 2007-05-23 22:11 ` PCIE Manu Abraham 2007-05-23 22:23 ` PCIE Roland Dreier 2007-05-23 23:03 ` PCIE Manu Abraham 2007-05-23 23:51 ` PCIE Roland Dreier 2007-05-24 0:07 ` PCIE Manu Abraham 2007-05-24 22:32 ` PCIE Manu Abraham 2007-05-25 3:25 ` PCIE Roland Dreier 2007-05-26 15:03 ` PCIE Manu Abraham 2007-05-26 18:28 ` PCIE Grant Grundler 2007-05-26 19:27 ` PCIE Manu Abraham 2007-05-28 1:15 ` PCIE Roland Dreier 2007-05-28 1:25 ` PCIE Manu Abraham 2007-05-28 2:04 ` PCIE Manu Abraham 2007-05-28 2:24 ` PCIE Roland Dreier 2007-05-28 2:47 ` PCIE Manu Abraham 2007-05-26 22:49 ` PCIE David Miller 2007-05-26 22:57 ` PCIE Manu Abraham 2007-05-26 23:55 ` PCIE Grant Grundler 2007-05-27 0:00 ` PCIE David Miller 2007-05-27 0:16 ` PCIE Grant Grundler 2007-05-27 0:30 ` PCIE David Miller 2007-05-27 1:01 ` PCIE Manu Abraham 2007-05-27 1:49 ` PCIE Grant Grundler 2007-05-27 20:28 ` PCIE Manu Abraham 2007-05-28 1:10 ` PCIE Roland Dreier 2007-05-27 2:34 ` PCIE H. Peter Anvin 2007-05-27 7:40 ` PCIE David Miller 2007-05-27 20:31 ` PCIE Manu Abraham 2007-05-28 1:05 ` PCIE Roland Dreier 2007-05-28 1:03 ` PCIE Roland Dreier 2007-05-28 2:54 ` PCIE David Miller 2007-05-28 4:18 ` PCIE Grant Grundler 2007-05-28 5:23 ` PCIE H. Peter Anvin 2007-05-28 5:22 ` PCIE H. Peter Anvin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox