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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

The current set of capabilities has served developers fairly well in
providing quick debug instructions to mildly-experienced users (i.e.
enough to be able to edit kernel cmdline). I definitely wouldn't want
to lose that.

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.

  -ilia


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux