On 9 September 2016 at 15:30, Christian König deathsimple@vodafone.de wrote:
Am 09.09.2016 um 15:54 schrieb Emil Velikov:
On 9 September 2016 at 12:24, Christian König deathsimple@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