[PATCH 15/15] amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR
Koenig, Christian
Christian.Koenig at amd.com
Wed Aug 7 06:57:24 UTC 2019
Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
>> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix <Felix.Kuehling at amd.com> wrote:
>>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
>>>> On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
>>>>> The option is just used to select HMM mirror support and has a very
>>>>> confusing help text. Just pull in the HMM mirror code by default
>>>>> instead.
>>>>>
>>>>> Signed-off-by: Christoph Hellwig <hch at lst.de>
>>>>> drivers/gpu/drm/Kconfig | 2 ++
>>>>> drivers/gpu/drm/amd/amdgpu/Kconfig | 10 ----------
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ------
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 ------------
>>>>> 4 files changed, 2 insertions(+), 28 deletions(-)
>>>> Felix, was this an effort to avoid the arch restriction on hmm or
>>>> something? Also can't see why this was like this.
>>> This option predates KFD's support of userptrs, which in turn predates
>>> HMM. Radeon has the same kind of option, though it doesn't affect HMM in
>>> that case.
>>>
>>> Alex, Christian, can you think of a good reason to maintain userptr
>>> support as an option in amdgpu? I suspect it was originally meant as a
>>> way to allow kernels with amdgpu without MMU notifiers. Now it would
>>> allow a kernel with amdgpu without HMM or MMU notifiers. I don't know if
>>> this is a useful thing to have.
>> Right. There were people that didn't have MMU notifiers that wanted
>> support for the GPU.
> ?? Is that even a real thing? mmu_notifier does not have much kconfig
> dependency.
Yes, that used to be a very real thing.
Initially a lot of users didn't wanted mmu notifiers to be enabled
because of the performance overhead they costs.
Then we had the problem that HMM mirror wasn't available on a lot of
architectures.
Not sure if we still need it separately, but I think that it shouldn't
be removed without asking around if somebody still needs that.
Christian.
>
> Jason
More information about the dri-devel
mailing list