Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
doing the same on the bridge controller with my workarounds applied: please note some differences: LnkSta: Speed 8GT/s (ok) vs Speed 2.5GT/s (downgraded) SltSta: PresDet+ vs PresDet- LnkSta2: Equalization stuff Virtual channel: NegoPending- vs NegoPending+ both times I executed lspci while the GPU was still suspended. 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 05) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Dell Device 07be Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 256 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <8us ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s (ok), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt+ SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 75.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, OBFF Via WAKE# ARIFwd- AtomicOpsCap: Routing- 32bit+ 64bit+ 128bitCAS+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Via WAKE# ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 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- Capabilities: [140 v1] Root Complex Link Desc: PortNumber=02 ComponentID=01 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: fed19000 Capabilities: [d94 v1] Secondary PCI Express Kernel driver in use: pcieport 00: 86 80 01 19 07 00 10 00 05 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 e0 00 20 20: 00 ec 00 ed 01 c0 f1 d1 00 00 00 00 00 00 00 00 30: 00 00 00 00 88 00 00 00 00 00 00 00 ff 01 10 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 62 17 00 00 00 00 0a 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 28 10 be 07 90: 05 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 10 00 42 01 01 80 00 00 20 00 00 00 03 ad 61 02 b0: 40 00 03 d1 80 25 0c 00 00 00 48 00 00 00 00 00 c0: 00 00 00 00 80 0b 08 00 00 64 00
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
was able to get the lspci prints via ssh. Machine rebooted automatically each time though. relevant dmesg: kernel: nouveau :01:00.0: Refused to change power state, currently in D3 kernel: nouveau :01:00.0: Refused to change power state, currently in D3 kernel: nouveau :01:00.0: Refused to change power state, currently in D3 kernel: nouveau :01:00.0: tmr: stalled at (last one is a 64 bit mmio read to get the on GPU timer value) # lspci -vvxxx -s 0:01.00 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 05) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [88] Subsystem: Dell Device 07be Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [a0] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 256 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #2, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <8us ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (downgraded), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt+ SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 75.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet+ LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, OBFF Via WAKE# ARIFwd- AtomicOpsCap: Routing- 32bit+ 64bit+ 128bitCAS+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Via WAKE# ARIFwd- AtomicOpsCtl: ReqEn- EgressBlck- LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 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- Capabilities: [140 v1] Root Complex Link Desc: PortNumber=02 ComponentID=01 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: fed19000 Capabilities: [d94 v1] Secondary PCI Express Kernel driver in use: pcieport 00: 86 80 01 19 07 00 10 00 05 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 e0 00 20 20: 00 ec 00 ed 01 c0 f1 d1 00 00 00 00 00 00 00 00 30: 00 00 00 00 88 00 00 00 00 00 00 00 ff 01 10 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 62 17 00 00 00 00 0a 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 28 10 be 07 90: 05 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 10 00 42 01
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 4:13 PM Bjorn Helgaas wrote: > > On Tue, May 21, 2019 at 03:28:48PM +0200, Karol Herbst wrote: > > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas > > > > wrote: > > > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > > > Apperantly things go south if we suspend the device with a > > > > > > different PCIE > > > > > > link speed set than it got booted with. Fixes runtime suspend on my > > > > > > gp107. > > > > > > > > > > > > This all looks like some bug inside the pci subsystem and I would > > > > > > prefer a > > > > > > fix there instead of nouveau, but maybe there is no real nice way > > > > > > of doing > > > > > > that outside of drivers? > > > > > > > > > > I agree it would be nice to fix this in the PCI core if that's > > > > > feasible. > > > > > > > > > > It looks like this driver changes the PCIe link speed using some > > > > > device-specific mechanism. When we suspend, we put the device in > > > > > D3cold, so it loses all its state. When we resume, the link probably > > > > > comes up at the boot speed because nothing did that device-specific > > > > > magic to change it, so you probably end up with the link being slow > > > > > but the driver thinking it's configured to be fast, and maybe that > > > > > combination doesn't work. > > > > > > > > > > If it requires something device-specific to change that link speed, I > > > > > don't know how to put that in the PCI core. But maybe I'm missing > > > > > something? > > > > > > > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > > > > > > > Initialization – During hardware initialization, each PCI Express > > > > > Link is set up following a negotiation of Lane widths and frequency > > > > > of operation by the two agents at each end of the Link. No firmware > > > > > or operating system software is involved. > > > > > > > > > > I have been assuming that this means device-specific link speed > > > > > management is out of spec, but it seems pretty common that devices > > > > > don't come up by themselves at the fastest possible link speed. So > > > > > maybe the spec just intends that devices can operate at *some* valid > > > > > speed. > > > > > > > > I would expect that devices kind of have to figure out what they can > > > > operate on and the operating system kind of just checks what the > > > > current state is and doesn't try to "restore" the old state or > > > > something? > > > > > > The devices at each end of the link negotiate the width and speed of > > > the link. This is done directly by the hardware without any help from > > > the OS. > > > > > > The OS can read the current link state (Current Link Speed and > > > Negotiated Link Width, both in the Link Status register). The OS has > > > very little control over that state. It can't directly restore the > > > state because the hardware has to negotiate a width & speed that > > > result in reliable operation. > > > > > > > We don't do anything in the driver after the device was suspended. And > > > > the 0x88000 is a mirror of the PCI config space, but we also got some > > > > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > > > > essentially. I have no idea how much of this is part of the actual pci > > > > standard and how much is driver specific. But the driver also wants to > > > > have some control over the link speed as it's tight to performance > > > > states on GPU. > > > > > > As far as I'm aware, there is no generic PCIe way for the OS to > > > influence the link width or speed. If the GPU driver needs to do > > > that, it would be via some device-specific mechanism. > > > > > > > The big issue here is just, that the GPU boots with 8.0, some on-gpu > > > > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > > > > the communication with the controller is broken. But if we set it to > > > > the boot speed, resuming the GPU just works. So my assumption was, > > > > that _something_ (might it be the controller or the pci subsystem) > > > > tries to force to operate on an invalid link speed and because the > > > > bridge controller is actually powered down as well (as all children > > > > are in D3cold) I could imagine that something in the pci subsystem > > > > actually restores the state which lets the controller fail to > > > > establish communication again? > > > > > > 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s > > > without OS/driver intervention. > > > > > > 2) Some mechanism reduces link speed to 2.5 GT/s. This probably > > > requires driver intervention or at least some ACPI method. > > > > there is no driver intervention and Nouveau doesn't care at all. It's > > all done on the GPU. We just upload a script and some firmware on to > > the GPU. The script runs then on the PMU inside the GPU and this
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 03:28:48PM +0200, Karol Herbst wrote: > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > > Apperantly things go south if we suspend the device with a different > > > > > PCIE > > > > > link speed set than it got booted with. Fixes runtime suspend on my > > > > > gp107. > > > > > > > > > > This all looks like some bug inside the pci subsystem and I would > > > > > prefer a > > > > > fix there instead of nouveau, but maybe there is no real nice way of > > > > > doing > > > > > that outside of drivers? > > > > > > > > I agree it would be nice to fix this in the PCI core if that's > > > > feasible. > > > > > > > > It looks like this driver changes the PCIe link speed using some > > > > device-specific mechanism. When we suspend, we put the device in > > > > D3cold, so it loses all its state. When we resume, the link probably > > > > comes up at the boot speed because nothing did that device-specific > > > > magic to change it, so you probably end up with the link being slow > > > > but the driver thinking it's configured to be fast, and maybe that > > > > combination doesn't work. > > > > > > > > If it requires something device-specific to change that link speed, I > > > > don't know how to put that in the PCI core. But maybe I'm missing > > > > something? > > > > > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > > > > > Initialization – During hardware initialization, each PCI Express > > > > Link is set up following a negotiation of Lane widths and frequency > > > > of operation by the two agents at each end of the Link. No firmware > > > > or operating system software is involved. > > > > > > > > I have been assuming that this means device-specific link speed > > > > management is out of spec, but it seems pretty common that devices > > > > don't come up by themselves at the fastest possible link speed. So > > > > maybe the spec just intends that devices can operate at *some* valid > > > > speed. > > > > > > I would expect that devices kind of have to figure out what they can > > > operate on and the operating system kind of just checks what the > > > current state is and doesn't try to "restore" the old state or > > > something? > > > > The devices at each end of the link negotiate the width and speed of > > the link. This is done directly by the hardware without any help from > > the OS. > > > > The OS can read the current link state (Current Link Speed and > > Negotiated Link Width, both in the Link Status register). The OS has > > very little control over that state. It can't directly restore the > > state because the hardware has to negotiate a width & speed that > > result in reliable operation. > > > > > We don't do anything in the driver after the device was suspended. And > > > the 0x88000 is a mirror of the PCI config space, but we also got some > > > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > > > essentially. I have no idea how much of this is part of the actual pci > > > standard and how much is driver specific. But the driver also wants to > > > have some control over the link speed as it's tight to performance > > > states on GPU. > > > > As far as I'm aware, there is no generic PCIe way for the OS to > > influence the link width or speed. If the GPU driver needs to do > > that, it would be via some device-specific mechanism. > > > > > The big issue here is just, that the GPU boots with 8.0, some on-gpu > > > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > > > the communication with the controller is broken. But if we set it to > > > the boot speed, resuming the GPU just works. So my assumption was, > > > that _something_ (might it be the controller or the pci subsystem) > > > tries to force to operate on an invalid link speed and because the > > > bridge controller is actually powered down as well (as all children > > > are in D3cold) I could imagine that something in the pci subsystem > > > actually restores the state which lets the controller fail to > > > establish communication again? > > > > 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s > > without OS/driver intervention. > > > > 2) Some mechanism reduces link speed to 2.5 GT/s. This probably > > requires driver intervention or at least some ACPI method. > > there is no driver intervention and Nouveau doesn't care at all. It's > all done on the GPU. We just upload a script and some firmware on to > the GPU. The script runs then on the PMU inside the GPU and this > script also causes changing the PCIe link settings. But from a Nouveau > point of view we don't care about the link before or after that script > was invoked. Also there is no ACPI method involved. > > But if there is something we should
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 3:51 PM Ilia Mirkin wrote: > > On Tue, May 21, 2019 at 9:29 AM Karol Herbst wrote: > > > > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > > > > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas > > > > wrote: > > > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > > > Apperantly things go south if we suspend the device with a > > > > > > different PCIE > > > > > > link speed set than it got booted with. Fixes runtime suspend on my > > > > > > gp107. > > > > > > > > > > > > This all looks like some bug inside the pci subsystem and I would > > > > > > prefer a > > > > > > fix there instead of nouveau, but maybe there is no real nice way > > > > > > of doing > > > > > > that outside of drivers? > > > > > > > > > > I agree it would be nice to fix this in the PCI core if that's > > > > > feasible. > > > > > > > > > > It looks like this driver changes the PCIe link speed using some > > > > > device-specific mechanism. When we suspend, we put the device in > > > > > D3cold, so it loses all its state. When we resume, the link probably > > > > > comes up at the boot speed because nothing did that device-specific > > > > > magic to change it, so you probably end up with the link being slow > > > > > but the driver thinking it's configured to be fast, and maybe that > > > > > combination doesn't work. > > > > > > > > > > If it requires something device-specific to change that link speed, I > > > > > don't know how to put that in the PCI core. But maybe I'm missing > > > > > something? > > > > > > > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > > > > > > > Initialization – During hardware initialization, each PCI Express > > > > > Link is set up following a negotiation of Lane widths and frequency > > > > > of operation by the two agents at each end of the Link. No firmware > > > > > or operating system software is involved. > > > > > > > > > > I have been assuming that this means device-specific link speed > > > > > management is out of spec, but it seems pretty common that devices > > > > > don't come up by themselves at the fastest possible link speed. So > > > > > maybe the spec just intends that devices can operate at *some* valid > > > > > speed. > > > > > > > > I would expect that devices kind of have to figure out what they can > > > > operate on and the operating system kind of just checks what the > > > > current state is and doesn't try to "restore" the old state or > > > > something? > > > > > > The devices at each end of the link negotiate the width and speed of > > > the link. This is done directly by the hardware without any help from > > > the OS. > > > > > > The OS can read the current link state (Current Link Speed and > > > Negotiated Link Width, both in the Link Status register). The OS has > > > very little control over that state. It can't directly restore the > > > state because the hardware has to negotiate a width & speed that > > > result in reliable operation. > > > > > > > We don't do anything in the driver after the device was suspended. And > > > > the 0x88000 is a mirror of the PCI config space, but we also got some > > > > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > > > > essentially. I have no idea how much of this is part of the actual pci > > > > standard and how much is driver specific. But the driver also wants to > > > > have some control over the link speed as it's tight to performance > > > > states on GPU. > > > > > > As far as I'm aware, there is no generic PCIe way for the OS to > > > influence the link width or speed. If the GPU driver needs to do > > > that, it would be via some device-specific mechanism. > > > > > > > The big issue here is just, that the GPU boots with 8.0, some on-gpu > > > > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > > > > the communication with the controller is broken. But if we set it to > > > > the boot speed, resuming the GPU just works. So my assumption was, > > > > that _something_ (might it be the controller or the pci subsystem) > > > > tries to force to operate on an invalid link speed and because the > > > > bridge controller is actually powered down as well (as all children > > > > are in D3cold) I could imagine that something in the pci subsystem > > > > actually restores the state which lets the controller fail to > > > > establish communication again? > > > > > > 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s > > > without OS/driver intervention. > > > > > > 2) Some mechanism reduces link speed to 2.5 GT/s. This probably > > > requires driver intervention or at least some ACPI method. > > > > > > > there is no driver intervention and Nouveau doesn't care at all. It's > > all done on the GPU. We just upload a script and some firmware on to > > the GPU. The script runs then on the PMU inside the GPU and
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 9:29 AM Karol Herbst wrote: > > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > > Apperantly things go south if we suspend the device with a different > > > > > PCIE > > > > > link speed set than it got booted with. Fixes runtime suspend on my > > > > > gp107. > > > > > > > > > > This all looks like some bug inside the pci subsystem and I would > > > > > prefer a > > > > > fix there instead of nouveau, but maybe there is no real nice way of > > > > > doing > > > > > that outside of drivers? > > > > > > > > I agree it would be nice to fix this in the PCI core if that's > > > > feasible. > > > > > > > > It looks like this driver changes the PCIe link speed using some > > > > device-specific mechanism. When we suspend, we put the device in > > > > D3cold, so it loses all its state. When we resume, the link probably > > > > comes up at the boot speed because nothing did that device-specific > > > > magic to change it, so you probably end up with the link being slow > > > > but the driver thinking it's configured to be fast, and maybe that > > > > combination doesn't work. > > > > > > > > If it requires something device-specific to change that link speed, I > > > > don't know how to put that in the PCI core. But maybe I'm missing > > > > something? > > > > > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > > > > > Initialization – During hardware initialization, each PCI Express > > > > Link is set up following a negotiation of Lane widths and frequency > > > > of operation by the two agents at each end of the Link. No firmware > > > > or operating system software is involved. > > > > > > > > I have been assuming that this means device-specific link speed > > > > management is out of spec, but it seems pretty common that devices > > > > don't come up by themselves at the fastest possible link speed. So > > > > maybe the spec just intends that devices can operate at *some* valid > > > > speed. > > > > > > I would expect that devices kind of have to figure out what they can > > > operate on and the operating system kind of just checks what the > > > current state is and doesn't try to "restore" the old state or > > > something? > > > > The devices at each end of the link negotiate the width and speed of > > the link. This is done directly by the hardware without any help from > > the OS. > > > > The OS can read the current link state (Current Link Speed and > > Negotiated Link Width, both in the Link Status register). The OS has > > very little control over that state. It can't directly restore the > > state because the hardware has to negotiate a width & speed that > > result in reliable operation. > > > > > We don't do anything in the driver after the device was suspended. And > > > the 0x88000 is a mirror of the PCI config space, but we also got some > > > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > > > essentially. I have no idea how much of this is part of the actual pci > > > standard and how much is driver specific. But the driver also wants to > > > have some control over the link speed as it's tight to performance > > > states on GPU. > > > > As far as I'm aware, there is no generic PCIe way for the OS to > > influence the link width or speed. If the GPU driver needs to do > > that, it would be via some device-specific mechanism. > > > > > The big issue here is just, that the GPU boots with 8.0, some on-gpu > > > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > > > the communication with the controller is broken. But if we set it to > > > the boot speed, resuming the GPU just works. So my assumption was, > > > that _something_ (might it be the controller or the pci subsystem) > > > tries to force to operate on an invalid link speed and because the > > > bridge controller is actually powered down as well (as all children > > > are in D3cold) I could imagine that something in the pci subsystem > > > actually restores the state which lets the controller fail to > > > establish communication again? > > > > 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s > > without OS/driver intervention. > > > > 2) Some mechanism reduces link speed to 2.5 GT/s. This probably > > requires driver intervention or at least some ACPI method. > > > > there is no driver intervention and Nouveau doesn't care at all. It's > all done on the GPU. We just upload a script and some firmware on to > the GPU. The script runs then on the PMU inside the GPU and this > script also causes changing the PCIe link settings. But from a Nouveau > point of view we don't care about the link before or after that script > was invoked. Also there is no ACPI method involved. > > But if there is something we should
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > > Apperantly things go south if we suspend the device with a different > > > > PCIE > > > > link speed set than it got booted with. Fixes runtime suspend on my > > > > gp107. > > > > > > > > This all looks like some bug inside the pci subsystem and I would > > > > prefer a > > > > fix there instead of nouveau, but maybe there is no real nice way of > > > > doing > > > > that outside of drivers? > > > > > > I agree it would be nice to fix this in the PCI core if that's > > > feasible. > > > > > > It looks like this driver changes the PCIe link speed using some > > > device-specific mechanism. When we suspend, we put the device in > > > D3cold, so it loses all its state. When we resume, the link probably > > > comes up at the boot speed because nothing did that device-specific > > > magic to change it, so you probably end up with the link being slow > > > but the driver thinking it's configured to be fast, and maybe that > > > combination doesn't work. > > > > > > If it requires something device-specific to change that link speed, I > > > don't know how to put that in the PCI core. But maybe I'm missing > > > something? > > > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > > > Initialization – During hardware initialization, each PCI Express > > > Link is set up following a negotiation of Lane widths and frequency > > > of operation by the two agents at each end of the Link. No firmware > > > or operating system software is involved. > > > > > > I have been assuming that this means device-specific link speed > > > management is out of spec, but it seems pretty common that devices > > > don't come up by themselves at the fastest possible link speed. So > > > maybe the spec just intends that devices can operate at *some* valid > > > speed. > > > > I would expect that devices kind of have to figure out what they can > > operate on and the operating system kind of just checks what the > > current state is and doesn't try to "restore" the old state or > > something? > > The devices at each end of the link negotiate the width and speed of > the link. This is done directly by the hardware without any help from > the OS. > > The OS can read the current link state (Current Link Speed and > Negotiated Link Width, both in the Link Status register). The OS has > very little control over that state. It can't directly restore the > state because the hardware has to negotiate a width & speed that > result in reliable operation. > > > We don't do anything in the driver after the device was suspended. And > > the 0x88000 is a mirror of the PCI config space, but we also got some > > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > > essentially. I have no idea how much of this is part of the actual pci > > standard and how much is driver specific. But the driver also wants to > > have some control over the link speed as it's tight to performance > > states on GPU. > > As far as I'm aware, there is no generic PCIe way for the OS to > influence the link width or speed. If the GPU driver needs to do > that, it would be via some device-specific mechanism. > > > The big issue here is just, that the GPU boots with 8.0, some on-gpu > > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > > the communication with the controller is broken. But if we set it to > > the boot speed, resuming the GPU just works. So my assumption was, > > that _something_ (might it be the controller or the pci subsystem) > > tries to force to operate on an invalid link speed and because the > > bridge controller is actually powered down as well (as all children > > are in D3cold) I could imagine that something in the pci subsystem > > actually restores the state which lets the controller fail to > > establish communication again? > > 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s > without OS/driver intervention. > > 2) Some mechanism reduces link speed to 2.5 GT/s. This probably > requires driver intervention or at least some ACPI method. > there is no driver intervention and Nouveau doesn't care at all. It's all done on the GPU. We just upload a script and some firmware on to the GPU. The script runs then on the PMU inside the GPU and this script also causes changing the PCIe link settings. But from a Nouveau point of view we don't care about the link before or after that script was invoked. Also there is no ACPI method involved. But if there is something we should notify pci core about, maybe that's something we have to do then? > 3) Suspend puts GPU into D3cold (powered off). > > 4) Resume restores GPU to D0, and the Port and GPU hardware again > negotiate 8.0 GT/s without OS/driver intervention, just
Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini
On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > Apperantly things go south if we suspend the device with a different PCIE > > > link speed set than it got booted with. Fixes runtime suspend on my gp107. > > > > > > This all looks like some bug inside the pci subsystem and I would prefer a > > > fix there instead of nouveau, but maybe there is no real nice way of doing > > > that outside of drivers? > > > > I agree it would be nice to fix this in the PCI core if that's > > feasible. > > > > It looks like this driver changes the PCIe link speed using some > > device-specific mechanism. When we suspend, we put the device in > > D3cold, so it loses all its state. When we resume, the link probably > > comes up at the boot speed because nothing did that device-specific > > magic to change it, so you probably end up with the link being slow > > but the driver thinking it's configured to be fast, and maybe that > > combination doesn't work. > > > > If it requires something device-specific to change that link speed, I > > don't know how to put that in the PCI core. But maybe I'm missing > > something? > > > > Per the PCIe spec (r4.0, sec 1.2): > > > > Initialization – During hardware initialization, each PCI Express > > Link is set up following a negotiation of Lane widths and frequency > > of operation by the two agents at each end of the Link. No firmware > > or operating system software is involved. > > > > I have been assuming that this means device-specific link speed > > management is out of spec, but it seems pretty common that devices > > don't come up by themselves at the fastest possible link speed. So > > maybe the spec just intends that devices can operate at *some* valid > > speed. > > I would expect that devices kind of have to figure out what they can > operate on and the operating system kind of just checks what the > current state is and doesn't try to "restore" the old state or > something? The devices at each end of the link negotiate the width and speed of the link. This is done directly by the hardware without any help from the OS. The OS can read the current link state (Current Link Speed and Negotiated Link Width, both in the Link Status register). The OS has very little control over that state. It can't directly restore the state because the hardware has to negotiate a width & speed that result in reliable operation. > We don't do anything in the driver after the device was suspended. And > the 0x88000 is a mirror of the PCI config space, but we also got some > PCIe stuff at 0x8c000 which is used by newer GPUs for gen3 stuff > essentially. I have no idea how much of this is part of the actual pci > standard and how much is driver specific. But the driver also wants to > have some control over the link speed as it's tight to performance > states on GPU. As far as I'm aware, there is no generic PCIe way for the OS to influence the link width or speed. If the GPU driver needs to do that, it would be via some device-specific mechanism. > The big issue here is just, that the GPU boots with 8.0, some on-gpu > init mechanism decreases it to 2.5. If we suspend, the GPU or at least > the communication with the controller is broken. But if we set it to > the boot speed, resuming the GPU just works. So my assumption was, > that _something_ (might it be the controller or the pci subsystem) > tries to force to operate on an invalid link speed and because the > bridge controller is actually powered down as well (as all children > are in D3cold) I could imagine that something in the pci subsystem > actually restores the state which lets the controller fail to > establish communication again? 1) At boot-time, the Port and the GPU hardware negotiate 8.0 GT/s without OS/driver intervention. 2) Some mechanism reduces link speed to 2.5 GT/s. This probably requires driver intervention or at least some ACPI method. 3) Suspend puts GPU into D3cold (powered off). 4) Resume restores GPU to D0, and the Port and GPU hardware again negotiate 8.0 GT/s without OS/driver intervention, just like at initial boot. 5) Now the driver thinks the GPU is at 2.5 GT/s but it's actually at 8.0 GT/s. Without knowing more about the transition to 2.5 GT/s, I can't guess why the GPU wouldn't work after resume. From a PCIe point of view, the link is supposed to work and the device should be reachable independent of the link speed. But maybe there's some weird dependency between the GPU and the driver here. It sounds like things work if you return to 8.0 GT/s before suspend, things work. That would make sense to me because then the driver's idea of the link state after resume would match the actual state. But I don't see a way to deal with this in the PCI core. The PCI core does save and restore most of the architected config
