similar to: [patch] drm/virtio: checking for NULL instead of IS_ERR

Factors out code, no functional change. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_fb.c | 58 +---------------------------- drivers/gpu/drm/virtio/virtgpu_plane.c | 68 ++++++++++++++++++++++++++++++++++ 3 files changed, 71 insertions(+), 56 deletions(-) diff --git

Factors out code, no functional change. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_fb.c | 58 +---------------------------- drivers/gpu/drm/virtio/virtgpu_plane.c | 68 ++++++++++++++++++++++++++++++++++ 3 files changed, 71 insertions(+), 56 deletions(-) diff --git

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order mode_config bit so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code on bigendian machines. Also add DRIVER_PREFER_HOST_BYTE_ORDER driver feature flag so drm_mode_addfb() asks for the correct format code. Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little endian, so using a different mapping on bigendian machines is wrong. It's there because of broken drm_mode_addfb()

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 14 --- drivers/gpu/drm/virtio/virtgpu_display.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +- drivers/gpu/drm/virtio/virtgpu_fb.c | 191 ------------------------------- drivers/gpu/drm/virtio/virtgpu_kms.c | 8 -- 5 files changed, 8 insertions(+), 215 deletions(-)

On Mon, Apr 03, 2017 at 09:08:44AM +0200, Gerd Hoffmann wrote: > Factors out code, no functional change. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Ugh on the big endian define, I guess we'll never managed to figure this aspect of drm pixel formats out correctly - they're supposed to encode endinaness. But the copy-paste looks correct :-) Acked-by: Daniel

On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: > From: Dave Airlie <airlied at gmail.com> > > 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

On Tue, Mar 24, 2015 at 05:07:18PM +0100, Gerd Hoffmann wrote: > From: Dave Airlie <airlied at gmail.com> > > 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

From: Dave Airlie <airlied at gmail.com> 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

From: Dave Airlie <airlied at gmail.com> 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

From: Dave Airlie <airlied at gmail.com> 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

From: Dave Airlie <airlied at gmail.com> 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

From: Dave Airlie <airlied at gmail.com> 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

From: Dave Airlie <airlied at gmail.com> 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

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 v2 of this to follow because I couldn't figure out how to properly handle one of the error cases ... see the comment embedded in one of the patches. Matthew Wilcox

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 uses normal ram as backing storage for the framebuffer, so we should assign the address to new screen_buffer (added by commit 17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base. Reported-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- 1 file changed, 1 insertion(+), 1

virtio uses normal ram as backing storage for the framebuffer, so we should assign the address to new screen_buffer (added by commit 17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base. Reported-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- 1 file changed, 1 insertion(+), 1

Make these structures const as they are only passed to the function drm_fb_helper_prepare and the corresponding argument is of type const. Done using Coccinelle @match disable optional_qualifier@ identifier s; @@ static struct drm_fb_helper_funcs s = {...}; @ref@ position p; identifier match.s; @@ s at p @good1@ identifier match.s; expression e1,e2; position ref.p; @@