On Wed, Sep 21, 2016 at 03:23:33AM -0400, Rob Clark wrote:
> On Wed, Sep 21, 2016 at 12:35 AM, Rob Clark <robdcl...@gmail.com> wrote:
> > On Tue, Sep 20, 2016 at 10:39 AM, Jordan Crouse <jcro...@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)
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.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Freedreno mailing list