The cursor must be set again after creating the primary surface.
Also drop the error message.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm
The shadow bo is used as qxl surface, so allocate it as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
dumb buffers are used as qxl surfaces, so allocate them as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
qxl surfaces (used for framebuffers and gem objects) can live in both
VRAM and PRIV ttm domains. Update placement setup to include both.
Put PRIV first in the list so it is preferred, so VRAM will have more
room for objects which must be allocated there.
Signed-off-by: Gerd Hoffmann
Without that ttm offsets are not unique, they can refer to objects
in both VRAM and PRIV memory (aka main and surfaces slot).
One of those "why things didn't blow up without this" moments.
Probably offset conflicts are rare enough by pure luck.
Signed-off-by: Gerd Hoffmann
---
slot_id_bits and slot_gen_bits can be read directly from qxlrom instead.
va_slot_mask is never used anywhere.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_kms.c | 10 ++
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a
Drop pointless indirection, remove the mem_slots array and index
variables, drop dynamic allocation. Store memslots in qxl_device
instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 15 +
drivers/gpu/drm/qxl/qxl_kms.c | 72
On Mon, Dec 10, 2018 at 11:03:57AM +0100, Daniel Vetter wrote:
> Doesn't do anything with atomic.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualization@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
&g
ains. Update placement setup to include both. Put
> > > > PRIV first in the list so it is preferred, so VRAM will have more room
> > > > for objects which must be allocated there.
> > > >
> > > > Signed-off-by: Gerd Hoffmann
> > >
>
> > qdev->monitors_config->max_allowed is effectively set by a module
> > parameter. So using the module parameter variable qxl_num_crtc
> > directly is better IMO. The kernel doesn't need to dereference pointers
> > each time it needs the value, and when reading the code you don't have
> > to tr
e, and when reading the code you don't have to trace where
and why qdev->monitors_config->max_allowed is set.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qx
On Thu, Dec 06, 2018 at 07:53:10AM -0500, Frediano Ziglio wrote:
> >
> > On Thu, Dec 06, 2018 at 05:59:25AM -0500, Frediano Ziglio wrote:
> > > >
> > > > Just use qxl_num_crtc directly everywhere instead of using
> > > > qdev->monitors_config->max_allowed. Drops pointless indirection
> > > > and
On Thu, Dec 06, 2018 at 05:59:25AM -0500, Frediano Ziglio wrote:
> >
> > Just use qxl_num_crtc directly everywhere instead of using
> > qdev->monitors_config->max_allowed. Drops pointless indirection
> > and also is less confusing.
> >
>
> To me is MORE confusing, why comparing number of someth
M will have more room
> > for objects which must be allocated there.
> >
> > Signed-off-by: Gerd Hoffmann
>
> I remember these kind of changes in the past made migration
> fails. I proposed similar patches years ago and they were rejected
> for these reasons.
Point
qxl surfaces (used for framebuffers and gem objects) can live in both
VRAM and PRIV ttm domains. Update placement setup to include both. Put
PRIV first in the list so it is preferred, so VRAM will have more room
for objects which must be allocated there.
Signed-off-by: Gerd Hoffmann
The shadow bo is used as qxl surface, so allocate it as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
dumb buffers are used as qxl surfaces, so allocate them as
QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in
PRIV ttm domain then, so this reduces VRAM memory pressure.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Just use qxl_num_crtc directly everywhere instead of using
qdev->monitors_config->max_allowed. Drops pointless indirection
and also is less confusing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 21 +
1 file changed, 9 insertions(+), 12 del
Just call drm_fence_put directly instead.
Also set vgfb->fence to NULL after dropping the reference.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
drivers/gpu/drm/virtio/virtgpu_fence.c | 8
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/gpu/
If we got an error response code from the host, print it to the log.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
Sending the flush command only makes sense if we actually have
a framebuffer attached to the scanout (handle != 0).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 5 ++---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm
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-of
Skip the pointless and slightly confusing indirection via
qdev->monitors_config->max_allowed. Just use qxl_num_crtc instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff -
the workflow in
qxl_primary_atomic_update().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_cmd.c | 8 +++-
drivers/gpu/drm/qxl/qxl_display.c | 29 -
2 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/driv
ry surface), make it big enough that dumb bo's for all crtcs fit in
side-by-side. Adjust the pageflip blits to place the heads next to each
other in the shadow.
With this patch in place multihead qxl works with wayland.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 5
The cursor must be set again after creating the primary surface.
Also drop the error message.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_cmd.c | 7 +++
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index
Track which bo is used as primary surface. With that in place we don't
need the primary_created flag any more, we can just check the primary bo
pointer instead.
Also verify we don't already have a primary surface in
qxl_io_create_primary().
Signed-off-by: Gerd Hoffmann
---
drivers/g
On Tue, Oct 30, 2018 at 10:38:04AM +0100, Daniel Vetter wrote:
> On Tue, Oct 30, 2018 at 07:32:06AM +0100, Gerd Hoffmann wrote:
> > linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Like with bochs, I thin
On Thu, Nov 15, 2018 at 12:10:36PM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create':
> drivers/gpu/drm/cirrus/cirrus_fbdev.c:172:20: warning:
> variable 'bo' set but not used [-Wunused-but-set-variab
On Sat, Nov 10, 2018 at 03:44:46AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/qxl/qxl_object.c: In function 'qxl_bo_kunmap_atomic_page':
> drivers/gpu/drm/qxl/qxl_object.c:189:21: warning:
> variable 'map' set but not used [-Wunused-but-set-varia
On Wed, Nov 07, 2018 at 08:31:22PM +, Colin King wrote:
> From: Colin Ian King
>
> The allocation for vfpriv is being leaked on an error return path,
> fix this by kfree'ing it before returning.
>
> Detected by CoverityScan, CID#1475380 ("Resource Leak")
Patches added to qemu queue, should
On Mon, Nov 12, 2018 at 05:51:53PM +0100, Robert Foss wrote:
>
> This series implements fence support for drm/virtio and
> has been tested using qemu, kmscube and the below branches.
>
> Rob Herring solved a reference counting issue and
> suggested a context check for the execbuf ioctl, his
> cha
On Fri, Nov 09, 2018 at 06:13:52PM +0100, Robert Foss wrote:
> Hey Gerd,
>
> On 2018-11-09 11:13, Gerd Hoffmann wrote:
> > On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote:
> > > On Mon, 5 Nov 2018 at 11:42, Robert Foss
> > > wrote:
> > > &g
On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote:
> On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote:
> >
> > When the execbuf call receives an in-fence it will get the dma_fence
> > related to that fence fd and wait on it before submitting the draw call.
> >
> > On the out-fence side we
qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt
instead, to avoid wasting resources (swiotlb bounce buffers for
example).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/dr
> > On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
> > >
> > > From: Gustavo Padovan
> > >
> > > Refactor fence creation to remove the potential allocation failure from
> > > the cmd_submit and atomic_commit paths. Now the fence should be allocated
> > > first and just after we should proceed
On Tue, Oct 30, 2018 at 11:31:04AM +, Emil Velikov wrote:
> HI Gerd,
>
> On Tue, 30 Oct 2018 at 06:11, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > The execbuffer IOCTL is now read-write to allow the userspace to read the
> > > out-fence.
&g
On Mon, Oct 29, 2018 at 12:46:34PM -0700, Michael Forney wrote:
> Hi,
>
> I was looking at adding virtio-gpu support to tinyemu
> (https://bellard.org/tinyemu/). I got it to work on x86, but just for
> fun I tried it under riscv and ran into an issue with buffer
> allocations (though, this should
.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
---
include/uapi/linux/virtio_gpu.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index f43c3c6171..8e88eba1fa 100644
--- a/include/uapi/linux
linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++
drivers/gpu/drm/virtio/virtgpu_display.c | 12 ++
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c
On Fri, Oct 26, 2018 at 04:20:30PM -0300, Shayenne da Luz Moura wrote:
> This series cleans the following checkpatch.pl issues:
>
> ERROR: trailing whitespace
> WARNING: Missing a blank line after declarations
> CHECK: Please don't use multiple blank lines
> WARNING: Prefer 'unsigned int' to bare
Hi,
> The execbuffer IOCTL is now read-write to allow the userspace to read the
> out-fence.
> #define DRM_IOCTL_VIRTGPU_EXECBUFFER \
> - DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
> + DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
> struct drm_virtgpu_exec
On Tue, Oct 23, 2018 at 12:50:36PM +0300, Jani Nikula wrote:
> On Tue, 23 Oct 2018, Souptick Joarder wrote:
> > On Fri, Oct 19, 2018 at 9:30 PM Sabyasachi Gupta
> > wrote:
> >>
> >> Replaced kmem_cache_alloc + memset with kmem_cache_zalloc
> >
> > Put a new line gap in between these two lines and
On Wed, Sep 26, 2018 at 09:00:27AM -0700, Matthew Wilcox wrote:
> I noticed you were using IDRs where you could be using the more efficient
> IDAs, then while fixing that I noticed the lack of error handling,
> and I decided to follow that up with an efficiency improvement.
>
> There's probably a
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/boc
On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote:
> On Mon, 29 Oct 2018, Gerd Hoffmann wrote:
> > Recent qemu (latest master branch, upcoming 3.1 release) got support
> > for EDID data. This patch adds guest driver support.
> >
> > EDID support in qemu is n
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/boc
object state.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 3 +++
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c| 3 ++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers
We pass the obj anyway, so obj->hw_res_handle can be used instead
in virtio_gpu_object_attach() and virtio_gpu_cmd_create_resource().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virtio/virtgpu_fb.c| 4 ++--
drivers/gpu/drm/vir
Drop pointless resid variable in virtio_gpu_mode_dumb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
think
some error paths too.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 3 ---
drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
drivers/gpu/drm/virtio/virtgpu_gem.c| 1 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 23
Drop pointless res_id variable in virtio_gpu_resource_create_ioctl(),
just use the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff
Drop pointless resid variable in virtio_gpufb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio
> > > This to me feels more like a bind/unbind operation rather than a
> > > populate/unpopulate operation,
> > >
> > > bind is " Bind the backend pages into the aperture in the location"
> > >
> > > whereas populate is
> > >
> > > allocate pages for a ttm.
> >
> > I ran into that trap too ;)
> >
>
.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Dave Airlie
---
include/uapi/linux/virtio_gpu.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index f43c3c6171..68198691a6 100644
--- a/include/uapi/linux/virtio_gpu.h
On Thu, Oct 18, 2018 at 11:41:52AM +1000, Dave Airlie wrote:
> On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote:
> >
> > Remove the virtio_gpu_object_{attach,detach} calls from move_notify()
> > callback. Add them to the ttm_tt_{populate,unpopulate} callbacks, which
> &
On Thu, Oct 18, 2018 at 11:25:22AM +1000, Dave Airlie wrote:
> On Mon, 1 Oct 2018 at 20:33, Gerd Hoffmann wrote:
> >
> > Track whenever the virtio_gpu_object is already created (i.e. host knows
> > about it) in a new variable. Add checks to virtio_gpu_object_attach()
> &g
Hi,
> > Recent qemu (latest master branch, upcoming 3.1 release) got support
> > for EDID data. This patch adds guest driver support.
> >
> > EDID support in qemu is not (yet) enabled by default, so please use
> > 'qemu -device VGA,edid=on' for testing.
>
> The EDID never changes after boot?
Hi,
> >>> +/* VIRTIO_GPU_RESP_OK_EDID */
> >>> +struct virtio_gpu_resp_edid {
> >>> + struct virtio_gpu_ctrl_hdr hdr;
> >>> + __le32 scanout;
> >>> + __le32 size;
> >>> + __u8 edid[1024];
> >>
> >> Wouldn’t it be enough to stick to EDID 2.0 (256 bytes)?
> >>
> >> If not, maybe add comment to e
.
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/virtio_gpu.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index f43c3c6171..1cef1ff339 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/boc
On Wed, Sep 26, 2018 at 09:04:55AM -0700, Matthew Wilcox wrote:
> On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote:
> > @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct
> > virtio_gpu_device *vgdev,
> >
> > if (handle < 0)
> > return handle;
> > + han
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/boc
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/boc
Hi,
> Having the support for vmapping dmabuf's is required to share
> dmabufs to drivers that want CPU access. This is the case of
> a vivid to virtio-gpu pipeline, where the virtio-gpu driver
> exports dmabufs to the video4linux vivid driver.
>
> The first patch adds virtio_gpu_object_kunmap()
Hi,
> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
> uint32_t resource_id, uint64_t offset,
> ...
> struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
> struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
> struct
Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and
virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just
the virtio resource handle.
This is needed to lookup the scatter list of the object, for dma sync.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio
> >> Once display manger is kicked off for example (sudo systemctl start
> >> lightdm.service) and
> >> resource id 3 gets created from user space down, it still gives a blank
> >> black screen.
> >
> > Hmm. I'd suspect there is simply a code path missing. Can you send the
> > patch you have?
tly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 17 +
drivers/gpu/drm/bochs/bochs_km
ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++
drivers/gpu/
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h
Hi,
> buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object
> obj->pages-sgl
> before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel
> console path.
That should be the right place.
> Once display manger is kicked off for example (sudo systemctl start
>
.
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/virtio_gpu.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
index f43c3c6171..7267c3d2d6 100644
--- a/include/uapi/linux/virtio_gpu.h
+++ b/include/uapi/linux
linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++
drivers/gpu/drm/virtio/virtgpu_display.c | 6
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c
Hi,
> I attempted to fix it in the ttm layer and here is the discussion
> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/
>
> The ttm maintainer Christian is suggesting to map and set ttm->pages as
> decrypted
> right after ttm->pages are allocated.
>
> Just checkin
On Mon, Sep 10, 2018 at 03:21:56PM +0200, Peter Wu wrote:
> Lots of code can be removed by relying on fb-helper:
> - "struct drm_framebuffer" moves to fb_helper.fb.
> - "struct drm_gem_object" moves to fb_helper.obj[0].
> - "struct qxl_device" can be inferred as drm_fb_helper is embedded.
> - qxl_u
> > this to set the VIRTIO_F_IOMMU_PLATFORM flag. But for example
> > QEMU has the use of iommu_platform attribute disabled for virtio-gpu
> > device. So would also like to move towards not having to specify
> > the VIRTIO_F_IOMMU_PLATFORM flag.
>
> Specifying VIRTIO_F_IOMMU_PLATFORM is the right
On Fri, Sep 07, 2018 at 02:03:57AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/virtio/virtgpu_display.c: In function
> 'virtio_gpu_framebuffer_init':
> drivers/gpu/drm/virtio/virtgpu_display.c:78:28: warning:
> variable 'bo' set but not used [-Wu
Hi,
> > You can probably get rid of this one if you're refactoring even more. The
> > generic fb_probe implementation (already merged) plus gem-shmem support
> > for it (still in flight) from Noralf should be able to pull that off. That
> > gives you the fb_mmap implementation, but with 100% gen
ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++
drivers/gpu/
userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 ++---
drivers/gpu/drm/bochs/bochs_kms.c | 34 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a
ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 4 +++
drivers/gpu/
userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 3 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 ++---
drivers/gpu/drm/bochs/bochs_kms.c | 33 -
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
4 files changed, 37
On Thu, Aug 30, 2018 at 08:14:02AM +0200, Thomas Zimmermann wrote:
> Hi Gerd
>
> Am 09.08.2018 um 17:27 schrieb Gerd Hoffmann:
> >> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> >> b/drivers/gpu/drm/bochs/bochs_mm.c
> >> index 39cd08416773..c9c7097030ca 100
Use the dma mapping api and properly add iommu mappings for
objects, unless virtio is in iommu quirk mode.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_vq.c | 46 +---
2 files changed, 38 insertions
The new function balances virtio_gpu_object_attach().
Also make virtio_gpu_cmd_resource_inval_backing() static and switch
call sites to the new virtio_gpu_object_attach() function.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio
Track whenever an virtual output (crtc) is enabled or disabled.
On atomic updates check for both framebuffer being present and crtc
being enabled to figure whenever the output is active or not.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm
On Fri, Jul 27, 2018 at 02:54:40PM +0300, Anton Vasilyev wrote:
> If qxl_device_init fails on creating resources and does not report it,
> then qxl module will catch null pointer exception on remove, or on
> probe's error path.
>
> The patch adds error path with resources release into qxl_device_i
On Fri, Jul 20, 2018 at 01:27:43PM +0200, Thomas Zimmermann wrote:
> In the Cirrus driver, the regular clean-up code also performs the clean-up
> of a failed initialization. If the fbdev's framebuffer was not initialized,
> the clean-up will fail within drm_framebuffer_unregister_private. Booting
>
> diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
> index f5c1e7872e92..89606c819d82 100644
> --- a/drivers/gpu/drm/qxl/qxl_gem.c
> +++ b/drivers/gpu/drm/qxl/qxl_gem.c
> @@ -40,7 +40,7 @@ void qxl_gem_object_free(struct drm_gem_object *gobj)
> qxl_surface_evict(qdev
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 60d54e10a34d..57f8fe6d020b 100644
> --- a/drivers/gpu/dr
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index 39cd08416773..c9c7097030ca 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -430,7 +430,7 @@ static void bochs_bo_unref(struct bochs_bo **bo)
> re
32bpp would limit the
resolution to 800x600 due to hardware constrains. So lets go with 16bpp.
Also use the default depth for the framebuffer console and
mode_info->preferred_depth.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 4 ++--
drivers/gpu/drm/cirrus/cirrus
32bpp would limit the
resolution to 800x600 due to hardware constrains. So lets go with 16bpp.
Also use the default depth for the framebuffer console.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 4 ++--
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 3 +--
2 files chang
On Mon, Jul 09, 2018 at 09:39:24AM +0200, Daniel Vetter wrote:
> On Fri, Jul 06, 2018 at 02:35:07PM -0400, Adam Jackson wrote:
> > On Fri, 2018-07-06 at 11:12 +0200, Gerd Hoffmann wrote:
> > > cirrus can handle 1024x768 (and slightly higher) with 24bpp depth.
> > > cirr
doesn't support it at all. Bugs
in Xorg keep showing up.
So using 32bpp by default is the better choice IMO, even if it comes
with the drawback that the resolution is 800x600 only. But hey, better
a working 800x600 display than a broken 1024x768 display ...
Signed-off-by: Gerd Hof
On Mon, Jul 02, 2018 at 11:57:28PM +0530, Souptick Joarder wrote:
> The fault handler code is commented since v4.2.
> If there is no plan to enable the fault handler
> code in future, we can remove this dead code.
Indeed, but please without tyops in the $subject line.
cheers,
Gerd
On Fri, Jun 01, 2018 at 04:05:32PM -0400, Jeremy Cline wrote:
> "qxl_bo_unref" may sleep, but calling "qxl_release_map" causes
> "preempt_disable()" to be called and "preempt_enable()" isn't called
> until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out
> from in between the two to
801 - 900 of 1170 matches
Mail list logo
