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

[Ilia Mirkin]

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. Also does
this work uniformly across all systems where it is a module? The
appeal of the kernel param is that it's fool-proof.

> 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.

Oh yeah, that'd be nice. (Optionally though, so that it's still easy
to use for the fairly common single gpu case.)