[PATCH] drm: Harmonize CIK ASIC support in radeon and amdgpu (v2)

Michel Dänzer michel at daenzer.net
Wed Apr 12 02:23:44 UTC 2017


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


More information about the amd-gfx mailing list