On 2018-04-03 03:26 PM, Ilia Mirkin wrote: > On Tue, Apr 3, 2018 at 5:29 AM, Daniel Vetter <daniel at ffwll.ch> wrote: >> On Sun, Apr 01, 2018 at 10:12:10PM +0200, Christian König wrote: >>> Am 01.04.2018 um 20:21 schrieb Takashi Iwai: >>>> On Sun, 01 Apr 2018 19:58:11 +0200, >>>> Christian K6nig wrote: >>>>> Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: >>>>>> On Sun, Apr 1, 2018 at 1:39 PM, Christian König >>>>>> <christian.koenig at amd.com> wrote: >>>>>>> Am 30.03.2018 um 22:45 schrieb Takashi Iwai: >>>>>>>> amdgpu driver lacks of modeset module option other drm drivers provide >>>>>>>> for enforcing or disabling the driver load. Interestingly, the >>>>>>>> amdgpu_mode variable declaration is already found in the header file, >>>>>>>> but the actual implementation seems to have been forgotten. >>>>>>>> >>>>>>>> This patch adds the missing piece. >>>>>>> NAK, modesetting is mandatory for amdgpu and we should probably remove the >>>>>>> option to disable it from other DRM drivers without UMS support as well >>>>>>> (pretty much all of them now). >>>>>>> >>>>>>> If you want to prevent a driver from loading I think the correct way to do >>>>>>> so is to give modprobe.blacklist=amdgpu on the kernel commandline. >>>>>>> >>>>>>> That would remove the possibility to prevent the driver from loading when it >>>>>>> is compiled in, but I don't see much of a problem with that. >>>>>> Having a way to kill the graphics driver is a very useful debugging >>>>>> tool, and also a quick and easy way to get out of an unpleasant >>>>>> situation where graphics are messed up / system hangs / etc. The >>>>>> modprobe blacklist kernel arg only works in certain environments (and >>>>>> only if it's a module). >>>>>> >>>>>> Every other DRM driver has this and this is a well-documented >>>>>> workaround for "graphics are messed up when I install linux", why not >>>>>> allow a uniform experience for the end users who are just trying to >>>>>> get their systems up and running? >>>>> Because it is not well documented and repeated over and over again in >>>>> drivers. >>>>> >>>>> The problem is that people don't realized that the driver isn't loaded >>>>> at all without the modeset=0 module option and demand fixing the >>>>> resulting bad performance without modesetting. >>>> Hm, I don't get it. What this options has to do with performance for >>>> a KMS-only driver...? >>> >>> Well exactly that's the point, nothing. >>> >>> The problem is that the option name is confusing to the end user because the >>> expectation is that "nomodeset" just means that they only can't change the >>> display mode. >>> >>> Some (unfortunately quite a lot) people don't realize that for KMS drivers >>> this means that the driver isn't even loaded and they also don't get any >>> acceleration. >>> >>> We had to explain that numerous times now. I think it would be best to give >>> the option a more meaningful name. >> >> Yeah, agreed with Christian. If we want a generic "pls disable all gfx >> accel" knob then probably best to put that into the drm core. And just >> outright fail loading the drm core if that happens, which will prevent all >> gfx drivers from loading. >> >> That likely means a hole bunch of stuff won't work (usually sound keels >> over too), but that's what you get for this. Only disabling modesetting >> without disabling the entire driver doesn't work (never has, except for >> this UMS+GEM combo only i915 support, and not for long). >> >> And once we have that knob, probably best to phase out all the per-driver >> options. > > Another use-case that the per-driver disables enable is "i915 works > but nouveau is broken due to crazy ACPI / PCIe PM / whatever". It > seems likely this could happen with amdgpu as well. modprobe.blacklist=amdgpu works as well as the modeset parameter for this. > The names are horrid. I think everyone agrees. In fact, when the > driver is disabled by nomodeset or modeset=0, I think they should > print like "driver completely disabled by modeset option" to avoid > some of the user confusion Christian is referring to (which I've run > into on a number of occasions as well). And/or maybe just refuse the > driver load entirely rather than load-but-do-nothing. However being > able to help users debug things seems more important than users being > occasionally confused by options they added to kernel cmdline. FWIW, if a new parameter or other mechanism is added for this, ideally it should allow preventing initialization on a per-GPU basis, instead of only per-driver, for systems with multiple GPUs supported by the same driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer