similar to: [PATCH v3 5/5] drm/cirrus: rewrite and modernize driver.

On Wed, Apr 3, 2019 at 9:23 AM 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.

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. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

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. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

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. But given that it does some pretty fundamental changes to the drivers workflow and also reduces the code size by

cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm" instead of "git rm" on them so they are still in present the tree. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 250 --------------------- drivers/gpu/drm/cirrus/cirrus_ttm.c |

cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm" instead of "git rm" on them so they are still in present the tree. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 250 --------------------- drivers/gpu/drm/cirrus/cirrus_ttm.c |

Move final cleanups from cirrus_pci_remove() to the new callback. Add drm_atomic_helper_shutdown() call to cirrus_pci_remove(). Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus.c | 43 ++++++++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 6 deletions(-) diff

Move final cleanups from cirrus_pci_remove() to the new callback. Add drm_atomic_helper_shutdown() call to cirrus_pci_remove(). Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. v4: add changelog. v3: use drm_dev*. v2: stop touching hardware after pci_remove(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus.c | 43

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

Move final cleanups from cirrus_pci_remove() to the new callback. Add drm_atomic_helper_shutdown() call to cirrus_pci_remove(). Set pointers to NULL after iounmap() and check them before using them to make sure we don't touch released hardware. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus.c | 23 +++++++++++++++++++++-- 1 file changed, 21

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

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_drv.h | 1 - drivers/gpu/drm/cirrus/cirrus_mode.c | 9 ++------- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h b/drivers/gpu/drm/cirrus/cirrus_drv.h index 915709739257..828b150cdb20 100644 --- a/drivers/gpu/drm/cirrus/cirrus_drv.h +++

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c b/drivers/gpu/drm/cirrus/cirrus_mode.c index 7f9bc32af685..32ce2c1040b4 100644 --- a/drivers/gpu/drm/cirrus/cirrus_mode.c +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c @@ -615,6 +615,7 @@ void

This patch replaces ast's framebuffer console with DRM's generic implememtation. All respective code is being removed from the driver. The console is set up with a shadow buffer. The actual buffer object is not permanently pinned in video ram, but just another buffer object that the driver moves in and out of vram as necessary. The driver's function ast_crtc_do_set_base() used to

Commit "f4bd542bca drm/fb-helper: Scale back depth to supported maximum" uncovered a bug in the cirrus driver. It must create its own primary plane, using the correct format list, depending on the bpp module parameter, so it is consistent with mode_config->preferred_depth. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/cirrus/cirrus_mode.c | 67

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Acked-by: Eric Anholt <eric at anholt.net> Acked-by: Sam Ravnborg <sam at ravnborg.org> 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: Daniel Vetter <daniel.vetter at

Am 03.04.20 um 15:58 schrieb Daniel Vetter: > Upcasting using a container_of macro is more typesafe, faster and > easier for the compiler to optimize. > > 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: Daniel Vetter <daniel.vetter at ffwll.ch> > Cc:

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. 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: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: "Noralf Tr?nnes" <noralf at tronnes.org> Cc: Sam Ravnborg <sam

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. 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: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: "Noralf Tr?nnes" <noralf at tronnes.org> Cc: Sam Ravnborg <sam