[PATCH 1/2] drm/ttm: remove unused placement flags

[Emil Velikov]

On 9 September 2016 at 15:30, Christian König <deathsimple at vodafone.de> wrote:
> Am 09.09.2016 um 15:54 schrieb Emil Velikov:
>>
>> On 9 September 2016 at 12:24, Christian König <deathsimple at vodafone.de>
>> wrote:
>>>
>>> Hi Hawking,
>>>
>>>> Removing the flag will make ttm_mem_type_from_place skip counting the
>>>> corresponding placement and thus have impact on mem region create and bo
>>>> movement.
>>>
>>> And that is exactly the reason why I want to remove the unused flags.
>>>
>>>> There is no guarantee that amdgpu would never introduce new memory
>>>> domain
>>>> in future.
>>>
>>> Irrelevant, if any driver wants to use additional domains it should add
>>> them
>>> when they are used.
>>>
>>> BTW: Why would we want to add another TTM domain? I really don't see any
>>> need for that.
>>>
>>>> Then how about keep these flags?
>>>
>>> Actually we used to have automated scanners which complain about unused
>>> code. I'm wondering why they don't detected that earlier.
>>>
>>> Anyway any code which isn't used in a while should be removed.
>>>
>> Fwiw I second Christian here. If they are unused in open-source
>> drivers there's no reason to keep them.
>> If/as that changes the (newly introduced) user can add back the relevant
>> code.
>
>
> Crap to late :( I was about to send a V2 of the patch to keep the PRIV
> flags.
>
Oops, sorry :-)

>> If closed-source driver(s) use them, then they can keep it as part of
>> their blob. Upstream kernel does not cater for closed-source drivers,
>> period.
>> I realise that's not the answer some are hoping for, so if you want to
>> question it take it up with Linus and co.
>
>
> It's not an issue between closed vs. open, but rather additional work of
> rebasing the open code when we start to use additional domains.
>
This should serve as a greater initiative to develop and upstream
things in a gradual manner, no ?
We all get carried away sometimes creating a massive branch which just
cannot go in at once.

> But on the other hand I still haven't seen a good reason for using those. As
> far as I know we have covered all resource in the current and next hardware
> generation with the existing flags.
>
This in itself is a pretty good point as well, considering you know
the hardware fairly well and you've worked in the kernel for quite a
while now.

Regards,
Emil