Messages in this thread | | | Date | Mon, 3 May 2021 17:42:20 -0500 | From | Bjorn Helgaas <> | Subject | Re: [PATCH v4 2/2] PCI: Enable NO_BUS_RESET quirk for Nvidia GPUs |
| |
On Fri, Apr 30, 2021 at 05:11:23PM -0500, Shanker R Donthineni wrote: > Thanks Bjorn for reviewing patch. > > On 4/30/21 12:01 PM, Bjorn Helgaas wrote: > > External email: Use caution opening links or attachments > > > > > > On Wed, Apr 28, 2021 at 07:49:07PM -0500, Shanker Donthineni wrote: > >> On select platforms, some Nvidia GPU devices do not work with SBR. > >> Triggering SBR would leave the device inoperable for the current > >> system boot. It requires a system hard-reboot to get the GPU device > >> back to normal operating condition post-SBR. For the affected > >> devices, enable NO_BUS_RESET quirk to fix the issue. > > Since 1/2 adds _RST support, should I infer that _RST works on these > > Nvidia GPUs even though SBR does not? If so, how does _RST do the > > reset? > Yes, _RST method works but not SBR. The _RST method in DSDT-AML uses > platform-specific initialization steps outside of the GPU BARs for resetting > the GPU device.
Obviously _RST only works for built-in devices, since there's no AML for plug-in devices, right? So if there's a plug-in card with this GPU, neither SBR nor _RST will work?
> > Do you have a root cause for why SBR doesn't work? > It is a hardware implementation specific issue. GPU end-point device > is inoperative after receiving SBR from the RP/SwitchPort. This quirk is > to prevent SBR.
That's not a root cause; it's basically still "it doesn't work." But OK.
I'm wondering if we should log something to dmesg in quirk_no_bus_reset(), quirk_no_pm_reset(), quirk_no_flr(), etc., just so we have a hint about the fact that resets won't work quite as expected on these devices.
Bjorn
| |