[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVywrFUN0ho-D6bmf9u4ePxBCvtc5zVK=6DEjkML6ohdw@mail.gmail.com>
Date: Sun, 28 Jun 2015 11:24:19 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Dave Airlie <airlied@...hat.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>
Subject: atomic64 on 32-bit vs 64-bit (was: Re: Add virtio gpu driver.)
On Fri, Jun 26, 2015 at 10:52 PM, Linux Kernel Mailing List
<linux-kernel@...r.kernel.org> wrote:
> Gitweb: http://git.kernel.org/linus/;a=commit;h=dc5698e80cf724770283e10414054662bdf6ccfa
> Commit: dc5698e80cf724770283e10414054662bdf6ccfa
> Parent: 16e3247da7f71f8c31f4330f739f6192a00c8b51
> Refname: refs/heads/master
> Author: Dave Airlie <airlied@...il.com>
> AuthorDate: Mon Sep 9 10:02:56 2013 +1000
> Committer: Gerd Hoffmann <kraxel@...hat.com>
> CommitDate: Wed Jun 3 14:17:38 2015 +0200
>
> Add virtio gpu driver.
>
> This patch adds a kms driver for the virtio gpu. The xorg modesetting
> driver can handle the device just fine, the framebuffer for fbcon is
> there too.
>
> Qemu patches for the host side are under review currently.
>
> The pci version of the device comes in two variants: with and without
> vga compatibility. The former has a extra memory bar for the vga
> framebuffer, the later is a pure virtio device. The only concern for
> this driver is that in the virtio-vga case we have to kick out the
> firmware framebuffer.
>
> Initial revision has only 2d support, 3d (virgl) support requires
> some more work on the qemu side and will be added later.
>
> Signed-off-by: Dave Airlie <airlied@...hat.com>
> Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
> Acked-by: Michael S. Tsirkin <mst@...hat.com>
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
> +static int
> +virtio_gpu_debugfs_irq_info(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = (struct drm_info_node *) m->private;
> + struct virtio_gpu_device *vgdev = node->minor->dev->dev_private;
> +
> + seq_printf(m, "fence %ld %lld\n",
> + atomic64_read(&vgdev->fence_drv.last_seq),
> + vgdev->fence_drv.sync_seq);
On m68k (32-bit):
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function
‘virtio_gpu_debugfs_irq_info’:
drivers/gpu/drm/virtio/virtgpu_debugfs.c:39: warning: format ‘%ld’
expects type ‘long int’, but argument 3 has type ‘long long int’
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
> +static bool virtio_signaled(struct fence *f)
> +{
> + struct virtio_gpu_fence *fence = to_virtio_fence(f);
> +
> + if (atomic64_read(&fence->drv->last_seq) >= fence->seq)
> + return true;
drivers/gpu/drm/virtio/virtgpu_fence.c: In function ‘virtio_timeline_value_str’:
drivers/gpu/drm/virtio/virtgpu_fence.c:64: warning: format ‘%lu’
expects type ‘long unsigned int’, but argument 4 has type ‘long long
int’
interestingly, this was reported almost one year ago:
https://lists.01.org/pipermail/kbuild-all/2014-September/006409.html
Instead of sprinkling casts, is there any good reason why atomic64_read()
and atomic64_t aren't "long long" everywhere, cfr. u64?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists