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
