[PATCH 2/2] drm/amdgpu: Add modeset module option

Tue Apr 3 16:54:32 UTC 2018

On Tue, Apr 03, 2018 at 05:02:35PM +0200, Daniel Vetter wrote:
> On Tue, Apr 03, 2018 at 05:06:03PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 03, 2018 at 03:47:57PM +0200, Michel Dänzer wrote:
> > > On 2018-04-03 03:39 PM, Ilia Mirkin wrote:
> > > > On Tue, Apr 3, 2018 at 9:32 AM, Michel Dänzer <michel at daenzer.net> wrote:
> > > >> 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.
> > > > 
> > > > People who build their own kernels run into trouble too.
> > > 
> > > There have always been various more or less serious issues with building
> > > amdgpu (and radeon) into the kernel. People who do so get to keep all
> > > pieces when it breaks.
> 
> fwiw, same roughly applies for i915. We try to make it work, by allowing
> firmware to be loaded later on and asynchronously. But if you fail to
> provide firmware the driver simply hangs forever. At least in certain
> cases, for others we simply never clock gate/shutdown the chip. Also not
> awesome (and we're closing all corresponding bug reports too).
> 
> We don't yet need firmware for basic display support, so you'll get at
> least a picture to be able to look at dmesg. If you remember to start X
> without accel, that is :-)
> 
> > > > Also does this work uniformly across all systems where it is a module?
> > > 
> > > AFAIK yes.
> > 
> > Sadly modprobe.blacklist doesn't prevent X/whatever from loading the
> > module anyway.
> 
> A generic "please don't bind anything to this device path" kernel property
> would be really nice for this. And hopefully something that could be
> merged into the drivers/base core code.
> 
> Plus a generic and all-encompassing no_modeset^Wno_gfx_I_mean_it knob
> would cover everything I think.
> -Daniel
> 
> > I use modprobe.blacklist myself all the time for i915 development,
> > but I also have all GUI junk disabled as well so that I can load the
> > module myself when I'm actually ready for it (typically after I've
> > enabled netconsole).
> 
> Oh, that's why modprobe.blacklist never works for me. TIL.

The other common reason is snd_hda_intel. That one needs to be blacklisted
at the same time, on modern Intel hw at least. Also one must remember to
write it as "snd_hda_intel" instead of "snd-hda-intel", otherwise it doesn't
do anything.

-- 
Ville Syrjälä
Intel OTC