On Mon, Feb 3, 2020 at 11:38 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Mon, Feb 03, 2020 at 04:16:36PM -0500, Alex Deucher wrote: > > AMD has had a micro-controller on the GPU handling pcie link speeds > > and widths dynamically (in addition to GPU clocks and voltages) for > > about 12 years or so at this point to save power when the GPU is idle > > and improve performance when it's required. The micro-controller > > changes the link parameters dynamically based on load independent of > > the driver. The driver can tweak the heuristics, or even disable the > > dynamic changes, but by default it's enabled when the driver loads. > > The ucode for this micro-controller is loaded by the driver so you'll > > see fixed clocks and widths prior to the driver loading. We'd need > > some sort of opt out I suppose for periods when the driver has enabled > > dynamic pcie power management in the micro-controller. > > Note that there are *two* bits in the Link Status Register: > > * Link Autonomous Bandwidth Status > "This bit is Set by hardware to indicate that hardware has > autonomously changed Link speed or width, without the Port > transitioning through DL_Down status, for reasons other than to > attempt to correct unreliable Link operation. This bit must be set if > the Physical Layer reports a speed or width change was initiated by > the Downstream component that was indicated as an autonomous change." > > * Link Bandwidth Management Status > "This bit is Set by hardware to indicate that either of the > following has occurred without the Port transitioning through > DL_Down status. [...] Hardware has changed Link speed or width to > attempt to correct unreliable Link operation, either through an > LTSSM timeout or a higher level process." > > See PCIe Base Spec 4.0 sec 7.8.8, 7.8.7, 4.2.6.3.3.1. > > The two bits generate *separate* interrupts. We only enable the > interrupt for the latter. > > If AMD GPUs generate a Link Bandwidth Management Interrupt upon > autonomously changing bandwidth for power management reasons > (instead of to correct unreliability issues), that would be a > spec violation. > > So the question is, do your GPUs violate the spec in this regard? I don't know off hand. I can ask the firmware team. That said, I haven't seen any reports of problems with our GPUs with this code enabled. Alex
