[PATCH 01/14] drm/amdgpu: fix wrong release of vmid owner

Christian König deathsimple at vodafone.de
Tue May 10 08:21:53 UTC 2016


Am 10.05.2016 um 07:05 schrieb Dave Airlie:
> On 9 May 2016 at 18:17, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Wed, May 04, 2016 at 02:26:42PM -0400, Alex Deucher wrote:
>>> From: Chunming Zhou <David1.Zhou at amd.com>
>>>
>>> The release of the vmid owner was not handled
>>> correctly.  We need to take the lock and walk
>>> the lru list.
>>>
>>> Signed-off-by: Chunming Zhou <David1.Zhou at amd.com>
>>> Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>>> Reviewed-by: Monk Liu <monk.liu at amd.com>
>>> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>> I know that it's super hard to get former proprietary driver teams to
>> stick their heads out on a public mailing lists. But imo being steward for
>> them is totally the worst case option you can pick long term. It means you
>> keep all the frustration of them not being fully in control (because
>> sometimes other people from outside the company jump in), never learning
>> how to driver the process themselves. And from the community pov it just
>> looks like code-drop over the wall. In my experience (I've been trying to
>> pull this off in public for almost 4 years now) trying to make exceptions
>> to get folks started just doesn't help anyone.
>>
>> Imo contributors need to fence for their patches themselves (with you
>> helping behind the scenes ofc) from the start.
> I'd prefer this as well, I'd also prefer at least people who do develop upstream
> like Christian be set free to do so again, having patches spring on
> the lists fully
> formed isn't really great.

Yeah, completely agree.

I actually tried to work on the public list again. Especially since I'm 
working on TTM improvements that would make things much easier.

The problem is that then internal people started to complain that some 
patches only got reviewed and merged upstream, but not internally.

>
> It would be also nice if there was more external discussion around
> design decisions etc,
> get the internal patch debate onto the mailing list.

Yeah, again completely agree. Alex and I already spend a lot of effort 
trying to explain the difference between releasing code to the public 
and making code open source.

>
> Because at this rate I've no idea about most of the design internals
> of the VM stuff,
> and I really think you guys can do a lot better.
>
> Maybe start setup another mailing list like intel-gfx for this, so
> it's a bit more private
> than dri-devel, but what is happening at the moment is worse than what
> used to happen.

Yeah, that sounds like a good idea to me.

Regards,
Christian.

>
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



More information about the dri-devel mailing list