On Sat, Dec 21, 2019 at 01:24:16PM -0800, Matthew Garrett wrote: > On Sat, Dec 21, 2019 at 8:44 AM Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> wrote: > > Point taken. I like Arvind's suggestion but we need to take care not > > to disable the device producing the GOP. Beyond that, it should be > > possible to disable all devices that are behind PCI bridges. It does > > mean we need to decode the secondary/subordinate bus values from the > > config space and take them into account when iterating over the PCI > > handle list. Why do we need to look at the bus numbers? Shouldn't it be just looping and disabling everything that's a regular device in the first pass (possibly excluding devices that are producing GOP/UGA), and then going over it again to disable the bus-master settings on bridges? Also, why do we restrict the bus-master disable to only PCI/PCI bridges? Shouldn't we also disable bus-mastering on all the other PCI-xxx bridges? > > The device producing the GOP is the device that I'm most afraid of, to > be honest.I'd naively expect that anything presenting a linear > framebuffer will probably leave it up at disconnect time, and we're > definitely not using DMA to access that framebuffer. At least on my system, disconnecting the GOP device does leave the display up, and the framebuffer remains active (ie writing to it updates the display). It wouldn't be surprising if this doesn't work for all GPUs though.
