[Freedreno] [pull] drm/msm: msm-next for 4.9

[Jordan Crouse]

On Wed, Sep 21, 2016 at 03:23:33AM -0400, Rob Clark wrote:
> On Wed, Sep 21, 2016 at 12:35 AM, Rob Clark <robdclark at gmail.com> wrote:
> > On Tue, Sep 20, 2016 at 10:39 AM, Jordan Crouse <jcrouse at codeaurora.org> wrote:
> >> So this isn't how I planned on announcing it, but hey, I'm back.
> >>
> >>> Rob Clark (5):
> >>>       drm/msm: extend the submit ioctl to pass in flags
> >>
> >> Renaming 'pipe' to 'flags' would break backwards compatibility - I'm not big
> >> fan of 'pipe' either but I would strongly recommend keeping it just to keep
> >> everybody happy. I know that you bump the API version a couple of changes
> >> later and we could use that as a stop gap but workarounds suck.
> >
> > well.. it doesn't break *ABI* compat, and the upstream user (libdrm)
> > carries it's own copy of the header in sync with the name change.  As
> > far as I know this is all we care about.  Any other "hypothetical"
> > userspace should just carry it's own copy of the kernel header, IMHO.
> 
> jfyi, if it wasn't clear, the "flags" field has the "pipe" in the low
> bits (since an ABI break is never ok), and new flags in the high bits:
> 
> /* The pipe-id just uses the lower bits, so can be OR'd with flags in
>  * the upper 16 bits (which could be extended further, if needed, maybe
>  * we extend/overload the pipe-id some day to deal with multiple rings,
>  * but even then I don't think we need the full lower 16 bits).
>  */
> #define MSM_PIPE_ID_MASK     0xffff
> #define MSM_PIPE_ID(x)       ((x) & MSM_PIPE_ID_MASK)
> #define MSM_PIPE_FLAGS(x)    ((x) & ~MSM_PIPE_ID_MASK)
> 
> Because the new flags are allocated from bit 31 downward, and
> previously the only valid pipe value was "3D0" (0x10), this keeps
> compatibility with old userspace on new kernel.  And new userspace on
> old kernel would fail properly with -EINVAL (since pipe!=0x10 was
> never valid before).
> 
> (Maybe we'll reduce PIPE_ID_MASK later if we need more room for
> flags..  I kept it large to start since I'm undecided if we want to
> use pipe-id eventually for multi-context support, vs just tying the
> gpu context to the drm_file)
> 
> 
> BR,
> -R

I saw that ABI was preserved but I was looking for both ABI and API. It seems
we have differing opinions regarding carrying around header file copies but
I guess we'll just have to agree to disagree about that.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project