On 17-04-27 05:22 AM, Michel Dänzer wrote: > On 27/04/17 05:15 AM, Felix Kuehling wrote: >> Hi Michel, >> >> You said in an earlier email that it doesn't have to be convenient. With >> that in mind, I went back to a minimalistic solution that doesn't need >> any additional Kconfig options and only uses two module parameters (one >> in radeon, one in amdgpu). >> >> I'm attaching my WIP patches for reference (currently based on >> amd-kfd-staging). For an official review I'd rebase them on >> amd-staging-4.9, remove the #if-0-ed hack that didn't work out, and add >> the same for SI. >> >> Can everyone can agree that this is good enough? > Yes, something like this could be a good first step in the right > direction. Some comments: > > The radeon options should be available regardless of > CONFIG_DRM_AMDGPU_CIK/SI, or they won't be useful for amdgpu-pro / other > out-of-tree amdgpu builds. Hmm, when an amdgpu-pro build is installed on a system with an older kernel, radeon won't have the module option at all. Unless the pro-build blacklists radeon, or replaces radeon with its own version, it will always have to be compiled without CIK support. Therefore, I think my patch, meant for upstream, should not consider this case. > > The default at this point should possibly still be for CIK GPUs to be > driven by radeon, even if CONFIG_DRM_AMDGPU_CIK is enabled; Alex and Christian seem to think otherwise. Regards, Felix > more > definitely so for SI. Then we can flip the default and remove > CONFIG_DRM_AMDGPU_CIK/SI at some point in the future, and (much) later > maybe remove the CIK/SI code from radeon. > >
