drm/virtio: implement context init: add virtio_gpu_fence_event

Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event
to the DRM file descriptor when a fence on a specific ring is
signaled

drm/virtio: implement context init: add virtio_gpu_fence_event

Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event
to the DRM file descriptor when a fence on a specific ring is
signaled.

One difference is the event is not exposed via the UAPI -- this is
because host responses are on a shared memory buffer of type
BLOB_MEM_GUEST [this is the common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Nicholas Verne <nverne@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-12-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: implement context init: stop using drv->context when creating fence

The plumbing is all here to do this. Since we always use the
default fence context when allocating a fence, this make

drm/virtio: implement context init: stop using drv->context when creating fence

The plumbing is all here to do this. Since we always use the
default fence context when allocating a fence, this makes no
functional difference.

We can't process just the largest fence id anymore, since it's
it's associated with different timelines. It's fine for fence_id
260 to signal before 259. As such, process each fence_id
individually.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-9-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc

These were defined in the previous commit. We'll need these
parameters when allocating a dma_fence. Th

drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc

These were defined in the previous commit. We'll need these
parameters when allocating a dma_fence. The use case for this
is multiple synchronizations timelines.

The maximum number of timelines per 3D instance will be 32. Usually,
only 2 are needed -- one for CPU commands, and another for GPU
commands.

As such, we'll need to specify these parameters when allocating a
dma_fence.

vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-8-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: consider dma-fence context when signaling

This an incremental refactor towards multiple dma-fence contexts
in virtio-gpu. Since all fences are still allocated using
&virtio_gpu_fence_dr

drm/virtio: consider dma-fence context when signaling

This an incremental refactor towards multiple dma-fence contexts
in virtio-gpu. Since all fences are still allocated using
&virtio_gpu_fence_driver.context, nothing should break and every
processed fence will be signaled.

The overall idea is every 3D context can allocate a number of
dma-fence contexts. Each dma-fence context refers to it's own
timeline.

For example, consider the following case where virgl submits
commands to the GPU (fence ids 1, 3) and does a metadata query with
the CPU (fence id 5). In a different process, gfxstream submits
commands to the GPU (fence ids 2, 4).

fence_id (&dma_fence.seqno) | 1 2 3 4 5
----------------------------------|-----------
fence_ctx 0 (virgl gpu) | 1 3
fence_ctx 1 (virgl metadata query)| 5
fence_ctx 2 (gfxstream gpu) | 2 4

With multiple fence contexts, we can wait for the metadata query
to finish without waiting for the virgl gpu to finish. virgl gpu
does not have to wait for gfxstream gpu. The fence id still is the
monotonically increasing sequence number, but it's only revelant to
the specific dma-fence context.

To fully enable this feature, we'll need to:
- have each 3d context allocate a number of fence contexts. Not
too hard with explicit context initialization on the horizon.
- have guest userspace specify fence context when performing
ioctls.
- tag each fence emitted to the host with the fence context
information. virtio_gpu_ctrl_hdr has padding + flags available,
so that should be easy.

This change goes in the direction specified above, by:
- looking up the virtgpu_fence given a fence_id
- signalling all prior fences in a given context
- signalling current fence

v2: fix grammar in comment
v3: add r-b tags

Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-3-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: rework virtio_fence_signaled

virtio_gpu_fence_event_process sets the last_fence_id and
subsequently calls dma_fence_signal_locked(..).

dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SI

drm/virtio: rework virtio_fence_signaled

virtio_gpu_fence_event_process sets the last_fence_id and
subsequently calls dma_fence_signal_locked(..).

dma_fence_signal_locked(..) sets DMA_FENCE_FLAG_SIGNALED_BIT,
which is actually checked before &dma_fence_ops.(*signaled) is
called.

The check for last_fence_id is therefore a bit redundant, and
it will not be sufficient to check the last_fence_id for multiple
synchronization timelines. Remove it.

v3: add r-b tags

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-2-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: virtio_{blah} --> virtio_gpu_{blah}

virtio_gpu typically uses the prefix virtio_gpu, but there are
a few places where the virtio prefix is used. Modify this for
consistency.

v3: add r-

drm/virtio: virtio_{blah} --> virtio_gpu_{blah}

virtio_gpu typically uses the prefix virtio_gpu, but there are
a few places where the virtio prefix is used. Modify this for
consistency.

v3: add r-b tags

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201201021623.619-1-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: rename sync_seq and last_seq

To be clearer about our intentions to associate sequence numbers
and fence IDs, let's rename these variables.

Signed-off-by: Gurchetan Singh <gurchetansingh

drm/virtio: rename sync_seq and last_seq

To be clearer about our intentions to associate sequence numbers
and fence IDs, let's rename these variables.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-5-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: use fence_id when processing fences

Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.

Let's use the fence_id name to clea

drm/virtio: use fence_id when processing fences

Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.

Let's use the fence_id name to clearly signal this.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-4-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: move to_virtio_fence inside virtgpu_fence

That's the only file that uses it.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/ms

drm/virtio: move to_virtio_fence inside virtgpu_fence

That's the only file that uses it.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-5-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: static-ify virtio_fence_signaled

Not used anywhere else.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.1

drm/virtio: static-ify virtio_fence_signaled

Not used anywhere else.

Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20191219005733.18960-1-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: add fence sanity check

Make sure we don't leak half-initialized fences outside the driver.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Li

drm/virtio: add fence sanity check

Make sure we don't leak half-initialized fences outside the driver.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-19-kraxel@redhat.com

show more ...

drm/virtgpu: drop use of drmP.h

Drop use of the deprecated drmP.h header file.
Fix fallout by adding missing include files.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Gerd Hoffmann <k

drm/virtgpu: drop use of drmP.h

Drop use of the deprecated drmP.h header file.
Fix fallout by adding missing include files.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190630061922.7254-28-sam@ravnborg.org

show more ...

drm/virtio: Remove redundant return type

virtio_gpu_fence_emit() always returns 0, since it
has no error paths.

Consequently no calls for virtio_gpu_fence_emit()
use the return value, and it can be

drm/virtio: Remove redundant return type

virtio_gpu_fence_emit() always returns 0, since it
has no error paths.

Consequently no calls for virtio_gpu_fence_emit()
use the return value, and it can be removed.

Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190506091034.30289-1-robert.foss@collabora.com
Suggested-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: allocate fences with GFP_KERNEL

It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
with a spinlock held. Th

drm/virtio: allocate fences with GFP_KERNEL

It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
with a spinlock held. That was no longer true after commit
9fdd90c0f (add virtio_gpu_alloc_fence()).

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190429221021.159784-1-olvaffe@gmail.com
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
Cc: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: trace drm_fence_emit

For most drivers, drm_fence_init is followed by drm_fence_emit
immediately. But for our driver, they are done separately. We also
don't know the fence seqno until

drm/virtio: trace drm_fence_emit

For most drivers, drm_fence_init is followed by drm_fence_emit
immediately. But for our driver, they are done separately. We also
don't know the fence seqno until drm_fence_emit.

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-2-olvaffe@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: set seqno for dma-fence

This is motivated by having meaningful ftrace events, but it also
fixes use cases where dma_fence_is_later is called, such as in
sync_file_merge.

In other driver

drm/virtio: set seqno for dma-fence

This is motivated by having meaningful ftrace events, but it also
fixes use cases where dma_fence_is_later is called, such as in
sync_file_merge.

In other drivers, fence creation and cmdbuf submission normally
happen atomically,

mutex_lock();
fence = dma_fence_create(..., ++timeline->seqno);
submit_cmdbuf();
mutex_unlock();

and have no such issue. But in our driver, because most ioctls
queue commands into ctrlq, we do not want to grab a lock. Instead,
we set seqno to 0 when a fence is created, and update it when the
command is finally queued and the seqno is known.

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190429220825.156644-1-olvaffe@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: rework resource creation workflow.

This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create()

drm/virtio: rework resource creation workflow.

This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function. That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initializes the object and calls
our driver callbacks.

Specifically the object is already created when the
virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
so the extra virtio_gpu_object_attach() calls done after
virtio_gpu_object_create() are not needed any more.

The fence support for the create ioctl becomes a bit more tricky though.
The code moved into virtio_gpu_object_create() too. We first submit the
(fenced) virtio_gpu_cmd_create_resource() command, then initialize the
ttm object, and finally attach just created object to the fence for the
command in case it didn't finish yet.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20190318113332.10900-6-kraxel@redhat.com

show more ...

drm/virtio: drop virtio_gpu_fence_cleanup()

Just call drm_fence_put directly instead.
Also set vgfb->fence to NULL after dropping the reference.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rev

drm/virtio: drop virtio_gpu_fence_cleanup()

Just call drm_fence_put directly instead.
Also set vgfb->fence to NULL after dropping the reference.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181219122708.4586-4-kraxel@redhat.com

show more ...

drm/virtio: fence: pass plain pointer

Since commit "9fdd90c0f4 drm/virtio: add virtio_gpu_alloc_fence()"
fences are not allocated any more by virtio_gpu_fence_emit(). So there
is no need to pass do

drm/virtio: fence: pass plain pointer

Since commit "9fdd90c0f4 drm/virtio: add virtio_gpu_alloc_fence()"
fences are not allocated any more by virtio_gpu_fence_emit(). So there
is no need to pass down a reference to the fence pointer, a plain
pointer is enough now.

Convert virtio_gpu_fence_emit() and callers.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181128151021.29565-2-kraxel@redhat.com

show more ...

drm/virtio: add virtio_gpu_alloc_fence()

Refactor fence creation, add fences to relevant GPU
operations and add cursor helper functions.

This removes the potential for allocation failures from the

drm/virtio: add virtio_gpu_alloc_fence()

Refactor fence creation, add fences to relevant GPU
operations and add cursor helper functions.

This removes the potential for allocation failures from the
cmd_submit and atomic_commit paths.
Now a fence will be allocated first and only after that
will we proceed with the rest of the execution.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-2-robert.foss@collabora.com
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: Remove unecessary dma_fence_ops

dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by

drm/virtio: Remove unecessary dma_fence_ops

dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180503142603.28513-15-daniel.vetter@ffwll.ch

show more ...

dma-buf: Rename struct fence to dma_fence

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make r

dma-buf: Rename struct fence to dma_fence

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.
v4: Try again for msm, sorry Daniel

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
(
...
)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk

show more ...

drm/virtio: add real fence context and seqno

virtio fences were created with no fence context, which would make then
clash with an allocated fence context.

Signed-off-by: Gustavo Padovan <gustavo.p

drm/virtio: add real fence context and seqno

virtio fences were created with no fence context, which would make then
clash with an allocated fence context.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Message-id: 1472660813-28219-2-git-send-email-gustavo@padovan.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer

Add helper function to handle the submission of fenced control requests.
Make sure we initialize the fence while holding the virtqueue lock,

virtio-gpu: add & use virtio_gpu_queue_fenced_ctrl_buffer

Add helper function to handle the submission of fenced control requests.
Make sure we initialize the fence while holding the virtqueue lock, so
requests can't be reordered.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

show more ...

drm/virtio: use %llu format string form atomic64_t

The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes t

drm/virtio: use %llu format string form atomic64_t

The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:

drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=]
snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
^
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info':
drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=]
seq_printf(m, "fence %ld %lld\n",
^

In order to avoid the warnings, this changes the format strings to %llu
and adds a cast to u64, which makes it work the same way everywhere.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

show more ...