On Tue, 03 Apr 2018 11:18:34 +0200, Michel D4nzer wrote: > > On 2018-04-03 11:02 AM, Takashi Iwai wrote: > > On Tue, 03 Apr 2018 10:57:56 +0200, > > Christian K6nig wrote: > >> > >> Am 03.04.2018 um 10:36 schrieb Michel Dänzer: > >>> On 2018-04-01 07:45 PM, Ilia Mirkin wrote: > >>>> 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). > >>> Building amdgpu into the kernel isn't feasible for a generic kernel such > >>> as a distro one, because it would require including all microcode into > >>> the kernel as well (12M right now, and growing). > >>> > >>> If a user decides to build amdgpu into their custom kernel and runs into > >>> trouble due to that, that's "doctor, it hurts if I do this" territory. > >> > >> Correct, but I agree that even in this situation it would be very > >> helpful to prevent the gfx drivers from loading and fallback to > >> efifb/vesafd (or whatever the platform provides). > >> > >> It's just that the "nomodeset" and "amdgpu.modeset=0" options are > >> really not well named for this task. > > > > Agreed with the naming mess. But OTOH, it's already a thing that is > > too popular to kill. You can add a more suitable option name, but you > > cannot drop these existing ones easily. It's already in a gray zone > > of the golden "don't break user-space" rule. > > That's quite a stretch argument, given that amdgpu has never supported > the modeset parameter. Oh I don't mean about my own patch but the foreseen action Christian mentioned. > Also, module parameters aren't UAPI. Right, but we care not only about UAPI. If the kernel breaks something, it's a regression. It's what Linus suggested many times. The same argument has been applied to proc or sysfs files in the past, and we had to correct back again. Don't get me wrong: I'm not always objecting to the removal of any module existing options. But if it break a major usage pattern, it's a problem. And the removal of nomodeset option would be a kind of such things, IMO, that's why I mentioned as "a gray zone" in the above. thanks, Takashi
