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@xxxxxxxxx> wrote: > > On Tue, Sep 20, 2016 at 10:39 AM, Jordan Crouse <jcrouse@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
