[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