On Tue, Nov 22, 2016 at 11:06:00AM +0000, Chris Wilson wrote:
>On Tue, Nov 22, 2016 at 10:53:51AM +0000, Brian Starkey wrote:
>>Hi Gustavo,
>>
>>A little late to the party here, but I was blocked by our internal
>>contributions process...
>>
>>I didn't see these end up in my checkout yet though, so I guess they
>>aren't picked up yet.
>>
>>On Mon, Nov 14, 2016 at 06:59:21PM +0900, Gustavo Padovan wrote:
>>>From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>
>>>Add support for the OUT_FENCE_PTR property to enable setting out fences for
>>>atomic commits.
>>>
>>>Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>---
>>>lib/igt_kms.c | 20 +++++++++++++++++++-
>>>lib/igt_kms.h | 3 +++
>>>2 files changed, 22 insertions(+), 1 deletion(-)
>>>
>>>diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>>index 4748c0a..f25e1eb 100644
>>>--- a/lib/igt_kms.c
>>>+++ b/lib/igt_kms.c
>>>@@ -175,7 +175,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
>>> "DEGAMMA_LUT",
>>> "GAMMA_LUT",
>>> "MODE_ID",
>>>- "ACTIVE"
>>>+ "ACTIVE",
>>>+ "OUT_FENCE_PTR"
>>>};
>>>
>>>const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
>>>@@ -2103,6 +2104,9 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t
*pipe_obj, drmModeAtomicRe
>>> igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
>>> }
>>>
>>>+ if (pipe_obj->out_fence_ptr)
>>>+ igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_OUT_FENCE_PTR,
pipe_obj->out_fence_ptr);
>>>+
>>> /*
>>> * TODO: Add all crtc level properties here
>>> */
>>>@@ -2683,6 +2687,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr,
size_t length)
>>>}
>>>
>>>/**
>>>+ * igt_pipe_set_out_fence_ptr:
>>>+ * @pipe: pipe pointer to which background color to be set
>>>+ * @fence_ptr: out fence pointer
>>
>>I don't think fence_ptr can be int *. It needs to be a pointer to a
>>64-bit type.
>>
>>>+ *
>>>+ * Sets the out fence pointer that will be passed to the kernel in
>>>+ * the atomic ioctl. When the kernel returns the out fence pointer
>>>+ * will contain the fd number of the out fence created by KMS.
>>>+ */
>>>+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr)
>>>+{
>>>+ pipe->out_fence_ptr = (uint64_t) fence_ptr;
>>>+}
>>>+
>>>+/**
>>> * igt_crtc_set_background:
>>> * @pipe: pipe pointer to which background color to be set
>>> * @background: background color value in BGR 16bpc
>>>diff --git a/lib/igt_kms.h b/lib/igt_kms.h
>>>index 344f931..02d7bd1 100644
>>>--- a/lib/igt_kms.h
>>>+++ b/lib/igt_kms.h
>>>@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
>>> IGT_CRTC_GAMMA_LUT,
>>> IGT_CRTC_MODE_ID,
>>> IGT_CRTC_ACTIVE,
>>>+ IGT_CRTC_OUT_FENCE_PTR,
>>> IGT_NUM_CRTC_PROPS
>>>};
>>>
>>>@@ -298,6 +299,7 @@ struct igt_pipe {
>>>
>>> uint64_t mode_blob;
>>> bool mode_changed;
>>>+ uint64_t out_fence_ptr;
>>
>>IMO this should be:
>>
>> int64_t *out_fence_ptr;
>
>In userspace, fences are *fd*, a plain int. It is only the uabi that we
>pass pointers as u64 to the kernel, and indeed that should be limited to
>the uabi wrapper.
>-Chris
Where's the uabi wrapper in this case?
Wherever it is, afaik someone needs to have 64-bit type for the kernel
to stash its fd in - on the kernel side out_fence_ptr is
(s64 __user *), so if there's not a 64-bit variable on the other end
of it then someone's going to have a bad day.