diff options
author | Álvaro Fernández Rojas <noltari@gmail.com> | 2020-05-28 19:08:55 +0200 |
---|---|---|
committer | Álvaro Fernández Rojas <noltari@gmail.com> | 2020-05-28 19:12:43 +0200 |
commit | 77e97abf129c5028385dd72587eabab68db0d954 (patch) | |
tree | fc52a8c2ba346da77281f00538a1eb6de49deb5d /target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch | |
parent | 5d3a0c6b26144eb5d62515b99613b5ad8dbdc717 (diff) | |
download | upstream-77e97abf129c5028385dd72587eabab68db0d954.tar.gz upstream-77e97abf129c5028385dd72587eabab68db0d954.tar.bz2 upstream-77e97abf129c5028385dd72587eabab68db0d954.zip |
bcm27xx: update to latest patches from RPi foundation
Also removes random module and switches to new bcm2711 thermal driver.
Boot tested on RPi 4B v1.1 4G.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Diffstat (limited to 'target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch')
-rw-r--r-- | target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch | 125 |
1 files changed, 125 insertions, 0 deletions
diff --git a/target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch b/target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch new file mode 100644 index 0000000000..7c3c470849 --- /dev/null +++ b/target/linux/bcm27xx/patches-5.4/950-0547-drm-vc4-plane-Move-planes-creation-to-its-own-functi.patch @@ -0,0 +1,125 @@ +From ac2c812856c3a496354b9f19d0a43458e108844d Mon Sep 17 00:00:00 2001 +From: Maxime Ripard <maxime@cerno.tech> +Date: Thu, 6 Feb 2020 14:32:57 +0100 +Subject: [PATCH] drm/vc4: plane: Move planes creation to its own + function + +The planes so far were created as part of the CRTC binding code with +each planes created associated only to one CRTC. However, the hardware +in the vc4 doesn't really have such constraint and can be used with any +CRTC. + +In order to rework this, let's first move the overlay and cursor planes +creation to a function of its own. + +Signed-off-by: Maxime Ripard <maxime@cerno.tech> +--- + drivers/gpu/drm/vc4/vc4_crtc.c | 33 ++++------------------------ + drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ + drivers/gpu/drm/vc4/vc4_plane.c | 38 +++++++++++++++++++++++++++++++++ + 3 files changed, 44 insertions(+), 29 deletions(-) + +--- a/drivers/gpu/drm/vc4/vc4_crtc.c ++++ b/drivers/gpu/drm/vc4/vc4_crtc.c +@@ -1142,7 +1142,7 @@ static int vc4_crtc_bind(struct device * + struct drm_device *drm = dev_get_drvdata(master); + struct vc4_crtc *vc4_crtc; + struct drm_crtc *crtc; +- struct drm_plane *primary_plane, *cursor_plane, *destroy_plane, *temp; ++ struct drm_plane *primary_plane, *destroy_plane, *temp; + const struct of_device_id *match; + int ret, i; + +@@ -1190,34 +1190,9 @@ static int vc4_crtc_bind(struct device * + */ + drm_crtc_enable_color_mgmt(crtc, 0, true, crtc->gamma_size); + +- /* Set up some arbitrary number of planes. We're not limited +- * by a set number of physical registers, just the space in +- * the HVS (16k) and how small an plane can be (28 bytes). +- * However, each plane we set up takes up some memory, and +- * increases the cost of looping over planes, which atomic +- * modesetting does quite a bit. As a result, we pick a +- * modest number of planes to expose, that should hopefully +- * still cover any sane usecase. +- */ +- for (i = 0; i < 8; i++) { +- struct drm_plane *plane = +- vc4_plane_init(drm, DRM_PLANE_TYPE_OVERLAY); +- +- if (IS_ERR(plane)) +- continue; +- +- plane->possible_crtcs = drm_crtc_mask(crtc); +- } +- +- /* Set up the legacy cursor after overlay initialization, +- * since we overlay planes on the CRTC in the order they were +- * initialized. +- */ +- cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR); +- if (!IS_ERR(cursor_plane)) { +- cursor_plane->possible_crtcs = drm_crtc_mask(crtc); +- crtc->cursor = cursor_plane; +- } ++ ret = vc4_plane_create_additional_planes(drm, crtc); ++ if (ret) ++ goto err_destroy_planes; + + vc4_crtc_get_cob_allocation(vc4_crtc); + +--- a/drivers/gpu/drm/vc4/vc4_drv.h ++++ b/drivers/gpu/drm/vc4/vc4_drv.h +@@ -855,6 +855,8 @@ int vc4_kms_load(struct drm_device *dev) + /* vc4_plane.c */ + struct drm_plane *vc4_plane_init(struct drm_device *dev, + enum drm_plane_type type); ++int vc4_plane_create_additional_planes(struct drm_device *dev, ++ struct drm_crtc *crtc); + u32 vc4_plane_write_dlist(struct drm_plane *plane, u32 __iomem *dlist); + u32 vc4_plane_dlist_size(const struct drm_plane_state *state); + void vc4_plane_async_set_fb(struct drm_plane *plane, +--- a/drivers/gpu/drm/vc4/vc4_plane.c ++++ b/drivers/gpu/drm/vc4/vc4_plane.c +@@ -1437,3 +1437,41 @@ struct drm_plane *vc4_plane_init(struct + + return plane; + } ++ ++int vc4_plane_create_additional_planes(struct drm_device *drm, ++ struct drm_crtc *crtc) ++{ ++ struct drm_plane *cursor_plane; ++ unsigned int i; ++ ++ /* Set up some arbitrary number of planes. We're not limited ++ * by a set number of physical registers, just the space in ++ * the HVS (16k) and how small an plane can be (28 bytes). ++ * However, each plane we set up takes up some memory, and ++ * increases the cost of looping over planes, which atomic ++ * modesetting does quite a bit. As a result, we pick a ++ * modest number of planes to expose, that should hopefully ++ * still cover any sane usecase. ++ */ ++ for (i = 0; i < 8; i++) { ++ struct drm_plane *plane = ++ vc4_plane_init(drm, DRM_PLANE_TYPE_OVERLAY); ++ ++ if (IS_ERR(plane)) ++ continue; ++ ++ plane->possible_crtcs = drm_crtc_mask(crtc); ++ } ++ ++ /* Set up the legacy cursor after overlay initialization, ++ * since we overlay planes on the CRTC in the order they were ++ * initialized. ++ */ ++ cursor_plane = vc4_plane_init(drm, DRM_PLANE_TYPE_CURSOR); ++ if (!IS_ERR(cursor_plane)) { ++ cursor_plane->possible_crtcs = drm_crtc_mask(crtc); ++ crtc->cursor = cursor_plane; ++ } ++ ++ return 0; ++} |