Hello Bjorn,
> >
> > I have a broken PCI bridge (PCIe downstream port), that is not raising
> interrupts at certain conditions.
> >
> > I'm trying to fool the driver into believing that the device is
> actually sending interrupts by having a quirk that:
> >
> > 1) Polls the device register to monitor the interrupt condition.
> >
> > 2) When a condition is determined that needs an interrupt - calls the
> driver's ISR method.
> >
> > My question - Instead of directly calling the ISR, is there a way my
> quirk can fake an interrupt being generated, through the PCI subsystem?
> That way, my quirk does not have to be a part of the (generic) PCI
> driver.
> >
> > PCI bridge: Integrated Device Technology, Inc. PES12NT3 PCI Express
> > Switch (rev 01) (prog-if 00 [Normal decode])
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0
> > Bus: primary=11, secondary=13, subordinate=13, sec-latency=0 I/O
> > behind bridge: 0000f000-00000fff Memory behind bridge:
> > 80000000-80ffffff 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-
> > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > Capabilities: [40] Express (v1) Downstream Port (Slot-), MSI 00
> > DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <64ns,
> L1 <1us
> > ExtTag+ RBE- FLReset-
> > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > MaxPayload 128 bytes, MaxReadReq 128 bytes
> > DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
> TransPend-
> > LnkCap: Port #1, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency
> L0 <2us, L1 <4us
> > ClockPM- Surprise- LLActRep- BwNot-
> > LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk-
> > DLActive- BWMgmt- ABWMgmt-
> > Capabilities: [70] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-
> ,D3hot+,D3cold+)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > Capabilities: [100 v1] Virtual Channel
> > Caps: LPEVC=0 RefClk=100ns PATEntryBits=2
> > Arb: Fixed- WRR32- WRR64- WRR128-
> > Ctrl: ArbSelect=Fixed
> > Status: InProgress-
> > VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> > Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
> > Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> > Status: NegoPending- InProgress- Kernel driver in use:
> > pcieport
>
> Huh. What interrupt are you expecting from it? I don't see any
> "interrupt enable" bits in your lspci (though I didn't go through
> everything in detail).
>
> Or are you expecting an interrupt from a device below this bridge, and
> that interrupt isn't getting passed through the bridge?
Actually this is the hot-plug interrupt (link change notification from the bridge itself) that I'm trying to fake.
This is an old PCIe switch on an existing shipping hardware. This switch does not support the Link status reporting ("LLActRep-" in lspci). Rather it has proprietary registers to determine link status, but no interrupt associated with change in that link status. I'm trying to make the pciehp believe that this bridge supports link state reporting by using a quirk to:
1) Override the config space access routines (using pci_bus_set_ops()) for this bridge so as to override values of link status / link ctrl / link capabilities with desired values etc.
2) Somehow generate an interrupt whenever the proprietary registers indicate link state changed. Currently I call pcie_isr directly (thus requiring the quirk to be a part of pciehp). But I'm trying to separate out the quirk into a platform specific code, out of pci subsystem.
I know one of the options is to use the pciehp in polling mode, but that changes the mode for all the ports, not just a specific one.
Thanks,
Rajat
PS: The pciehp driver was not loaded and hence you do not see any interrupts enabled in the lspci output.
>
> Bjorn
>
��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
