[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