* 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 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-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 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 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-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-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-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 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-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 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
* 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
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