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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



>>>       drm/msm: submit support for in-fences
>>>       drm/msm: move fence allocation out of msm_gpu_submit()
>>>       drm/msm: submit support for out-fences
>>>       drm/msm: bump kernel api version for explicit fencing
>>
>> You misspelled ioctl in the comment. :)
>
> oh, whoops.. well if dave hasn't merged my pull req yet I can fixup
> the typo and resend the pr.  Unfortunately kbuild robot doesn't
> include spellcheck ;-)
>
> BR,
> -R
>
>> Regards,
>> 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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux