On 12/04/17 01:05 AM, Felix Kuehling wrote: > On 17-04-11 12:01 AM, Michel Dänzer wrote: >> One issue with this per-driver enable_cik option is that if the user >> only enables it in the driver where it's disabled by default, without >> also disabling it in the driver where it's enabled by default, it's back >> to the current situation where both drivers try to use the same GPUs, >> and it's up to chance which one actually gets to. >> >> That's why I was thinking about also having a shared command line option >> respected by both drivers, e.g. amd_cik_driver=amdgpu/radeon . That >> would be the preferred way to choose the driver at runtime. > > The shared option could not be in either amdgpu or radeon. Otherwise > we'd create a cross-dependency between the drivers. It would have to be > in drm, I guess? > >> Note that the per-driver enable_cik option will still be needed to be >> able to override the kernel command line when manually loading the drivers. > > Why? I could make the shared option writable in > /sys/module/drm/parameters/amd_cik_driver so you can change it before > loading the module. I was thinking of a pure kernel command line option which is parsed by both drivers, not a module parameter. One possibility would be making each driver also parse the other driver's module parameter on the kernel command line. I.e. radeon would parse amdgpu.enable_cik=0 on the kernel command line and set its own enable_cik parameter to 1, and vice versa. This would probably require making the default value of the enable_cik options e.g. -1, and only parsing the other driver's option in that case. If you don't want to tackle that, I can give it a go as a follow-up patch. We do need to settle on whether all those Kconfig options are needed though; I think they're overkill. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
