Am 31.07.20 um 11:29 schrieb daniel@ffwll.ch:
On Fri, Jul 31, 2020 at 11:17:26AM +0200, Christian König wrote:
Am 31.07.20 um 06:04 schrieb Dave Airlie:
I started pulling on a thread, and it led me down a hole.
We might want to make that hole even bigger :)
How about we rename the ttm_mem_reg into ttm_resource and ttm_mem_type_manager into ttm_resource_manager.
+1 on names I can understand, I alwas get confused about what exactly ttm means with mem_reg and mem_type_manager.
Well mem_type_manager was obvious, but to be honest I never figured out what _reg meant either :)
Christian.
-Daniel
Neither amdgpu's OA/GWS resources nor the IDs in VMGFX are really memory.
In the long term I also want to move the whole address handling into each backend.
Going to send comments on the individual patches as well.
This series refactors the ttm ttm_mem_type_manager object into a driver owned, allocated, subclassaed object.
It starts with two minor fixes for some bad assumptions in two drivers.
Enables a new init path, ports all the drivers to the new init path, and cleans up the old init path. Enables a new takedown path, ports all the drivers to the new takedown path, and cleans up the old takedown path Wraps all access to the memory managers in the bo_device in a wrapper across all drivers. Make debug callback optional Enables driver to provide their own mem manager objects Subclasses the objects in all drivers and makes them into driver owned object Drops the bo_device arrays of pointers, and some unneeded links and struct members Cleans up one api.
I think I'd probably want to merge all this via drm-misc, so if I can collect acks/r-b from driver maintainers that would be good.
This is also based on Chrisitan's work to remove init_mem_type, so it won't apply until he's finished getting all of that into drm-misc.
Preparing to push that to drm-misc-next just now.
Regards, Christian.
https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fcgit.freedes... is the tree I've built this on top off, so it's probably going to get rebased but the code should stay mostly the same.
I've done some boot testing on nouveau, and I hope to test it on vmwgfx and amdgpu soon.
Dave.
dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.free...