similar to: [PATCH] drm/cirrus: flip default to 32bpp

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also

The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. Typically either 32bpp or 16bpp are used. Using 32bpp would limit the resolution to 800x600 due to hardware constrains. So lets go with 16bpp. Also

cirrus can handle 1024x768 (and slightly higher) with 24bpp depth. cirrus can handle up to 800x600 with 32bpp. The problem with 24bpp is that it is a rather unusual depth these days, cirrus is pretty much the only relevant device still using that, and it is a endless source of issues. Wayland doesn't support it at all. Bugs in Xorg keep showing up. So using 32bpp by default is the better

Because it is. Huge congrats to everyone who made this kind of refactoring happen! Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org --- MAINTAINERS | 2 +- drivers/gpu/drm/Kconfig | 2 --

Because it is. Huge congrats to everyone who made this kind of refactoring happen! Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org --- MAINTAINERS | 2 +- drivers/gpu/drm/Kconfig | 2 --

On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > > > Am 15.04.20 um 09:40 schrieb Daniel Vetter: > > Because it is. Huge congrats to everyone who made this kind of > > refactoring happen! > > Every other week, I felt an urge to send out this patch. Thank you so > much, Daniel! There are more candidates for tiny/. They are

On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > > > Am 15.04.20 um 09:40 schrieb Daniel Vetter: > > Because it is. Huge congrats to everyone who made this kind of > > refactoring happen! > > Every other week, I felt an urge to send out this patch. Thank you so > much, Daniel! There are more candidates for tiny/. They are

Signed-off-by: Rob Hoes <rob.hoes@citrix.com> --- docs/man/xl.cfg.pod.5 | 18 +++++++------- tools/libxl/libxl_create.c | 57 ++++++++++++++++++++++++++++++++++---------- 2 files changed, 55 insertions(+), 20 deletions(-) diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 769767b..c18604d 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -1009,14

On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > > Hi, > > > >> If not for TTM, what would be the alternative? One VMA manager per > >> memory region per device? > > > > Depends pretty much on the device. > > > > The cirrus is a display device with

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 15.04.19 um 17:54 schrieb Daniel Vetter: > > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 09.04.19 um 09:12 schrieb kraxel at redhat.com: > >>> Hi, > >>> > >>>> If not

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

The ttm_backend_func structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/ast/ast_ttm.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-

The ttm_backend_func structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/ast/ast_ttm.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-

On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Time to kill some bad sample code people are copying from ;) > > This is a complete rewrite of the cirrus driver. The cirrus_mode_set() > function is pretty much the only function which is carried over largely > unmodified. Everything else is upside down. > > It is a single monster patch.

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code