Re: [PATCH] drm/i915: Revert "drm/i915: Reject the pin ioctl on gen6+"

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Sep 19, 2014 at 03:25:55PM +0100, Damien Lespiau wrote:
> Hi Daniel,
> 
> On Mon, Jul 07, 2014 at 11:04:55PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote:
> > > This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
> > > 
> > > The OA buffer can contain global data (in particular, not linked to a
> > > context or a single batch execution) about GPU events (eg. hw context
> > > switches, rc6 transitions, frequency changes, ...) and needs to be
> > > mapped to GGTT. The pin ioctl provided a way to do that.
> > > 
> > > Admittedly, this change broke what seems to be a valid use case of
> > > pinning a buffer in GGTT, even when PPGTT is used (which is the reason
> > > invoked in the commit message).
> > 
> > Global OA buffers should be handled by the kernel and exposed through
> > perf, imo. I think I'll go lalala on this a bit longer ...
> 
> Do you think that we can unblock this now that we have somewhat of path
> forward with Rob Bragg's work? I'm still uneasy with a precedent where
> we break working applications and it takes a long time for us to revert
> the offending change?

I still consider pinning stuff behind the kernels back too evil. So if
people want that I'd like to see the use-case and why we can't do this
differently.

And I've never approved of the pin ioctl but really loudly complained
about each occasion I've spotted, so I think the internal users just have
to keep the pieces for a bit longer.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch