[PATCH 39/49] drm/ttm: make ttm_bo_man_init/takedown take type + args

[Christian König]

Am 04.08.20 um 03:42 schrieb Dave Airlie:
> On Fri, 31 Jul 2020 at 23:32, Christian König <christian.koenig at amd.com> wrote:
>> Am 31.07.20 um 06:05 schrieb Dave Airlie:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> This makes it easier to move these to a driver allocated system
>> No, sorry that looks like going into the wrong direction to me.
>>
>> I already wanted to suggest to get rid of the size argument instead.
> I'm not sure how it should look then, I don't want the driver poking
> around inside the range manager code, the range manager should be a
> generic object that driver inits and leaves alone,
>
> I definitely don't want the driver to be poking caching and size
> values into the man objects for it, since it isn't a driver object.
>
> Do you have some other view on how the generic range manager should work?

That was not what I was talking about. Take a look at what those fields 
are used for :)


As far as I see the only usage of the size is in 
ttm_resource_manager_debug(). But this size is actually totally opaque 
to TTM, it could be pages, bytes, fried chicken wings or whatever. In 
other words it would be much better to print it in the debug callback of 
each resource manager.


The available_caching is completely superfluous as well. The original 
idea what that a driver could specify multiple placements as flags in 
one entry, but no driver ever used that as far as I know and it became 
completely deprecated in 2014 when I moved the lpfn and fpfn into each 
place.


The default_caching is used in ttm_bo_select_caching(), but this is 
complete utterly nonsense. It just results in multiple possible cache 
behaviors being selected, which are then fortunately ignored by 
ttm_tt_set_placement_caching :)


To be honest I think just removing those parameters and the associated 
caching flags all together is the next logical step.

Regards,
Christian.

>
> Dave.