Am 27.03.2018 um 09:53 schrieb Daniel Vetter:
> [SNIP]
>>> [SNIP]
>>> A slightly better solution is using atomic counter:
>>> driver_range_start() {
>>> atomic_inc(&mydev->notifier_count);
>> ...
>>
>> Yeah, that is exactly what amdgpu is doing now. Sorry if my description
>> didn't made that clear.
>>
>>> I would like to see driver using same code, as it means one place to fix
>>> issues. I had for a long time on my TODO list doing the above conversion
>>> to amd or radeon kernel driver. I am pushing up my todo list hopefully in
>>> next few weeks i can send an rfc so people can have a real sense of how
>>> it can look.
>> Certainly a good idea, but I think we might have that separate to HMM.
>>
>> TTM suffered really from feature overload, e.g. trying to do everything in a
>> single subsystem. And it would be rather nice to have coherent userptr
>> handling for GPUs as separate feature.
> TTM suffered from being a midlayer imo, not from doing too much.
Yeah, completely agree.
midlayers work as long as you concentrate on doing exactly one things in
your midlayer. E.g. in the case of TTM the callback for BO move handling
is well justified.
Only all the stuff around it like address space handling etc... is
really wrong designed and should be separated (which is exactly what DRM
MM did, but TTM still uses this in the wrong way).
> HMM is apparently structured like a toolbox (despite its documentation claiming
> otherwise), so you can pick&choose freely.
That sounds good, but I would still have a better feeling if userptr
handling would be separated. That avoids mangling things together again.
Christian.
> -Daniel
