[PATCH] drm/amdgpu: fix drm leases being broken on radv

Daniel Vetter daniel at ffwll.ch
Wed Apr 17 12:35:54 UTC 2019


On Wed, Apr 17, 2019 at 12:06:32PM +0000, Koenig, Christian wrote:
> Am 17.04.19 um 14:00 schrieb Daniel Vetter:
> > On Wed, Apr 17, 2019 at 11:18:35AM +0000, Koenig, Christian wrote:
> >> Am 17.04.19 um 13:06 schrieb Daniel Vetter:
> >>> On Wed, Apr 17, 2019 at 12:29 PM Koenig, Christian
> >>> <Christian.Koenig at amd.com> wrote:
> >>> [SNIP]
> >> Well, what you guys did here is a serious no-go.
> > Not really understanding your reasons for an unconditional nak on all this
> > still.
> 
> Well, let me summarize: You worked around a problem with libva by 
> breaking another driver and now proposing a rather ugly and only halve 
> backed workaround for that driver.
> 
> This is a serious no-go. I've already send out a i915 specific change to 
> remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW and revert 
> the offending patch.

Oh I'm totally fine with the revert if that's what we go with. But that
still leaves the issue that it would make sense to drop DRM_AUTH from
DRIVER_RENDER capable drivers (not just for libva, but in general). And
there's fundamentally 2 options to do that:

- This one here (or anything implementing the same idea), to keep radv
  working.

- We drop DRM_AUTH from all drivers with DRIVER_RENDER except amdgpu. How
  exactly that's doen doesn't matter, but it leaves amdgpu out in the
  cold. It also doesn't matter whether we get there with revert + lots of
  patches, or a special hack for amdgpu, in the end amdgpu would be
  different. Also note that your patch isn't enough, since it doesn't fix
  the core ioctls.

I think from an overall platform pov, the first is the better option.
After all we try really hard to avoid driver special cases for these kinds
of things.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list