All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02  9:09 ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: linux-arm-kernel

This is the base for finally getting RealView and Versatile
Express supported in the PL111 DRM driver.

We have then moved all the way up from the first ARM
Integrator versions to the last Versatile Express reference
designs using PL111.

After this, forked hardware such as Nomadik and SPEAr
remains to be moved over.

Some infrastructure for adjusting depth (ARGB5551) etc
on the Integrator and some bridge fixups are still needed
but this is the core of the support for these platforms
and the rest can be done on top before switching over.

Also the Versatile Express CLCD on the motherboard has
a dedicated video memory, and cannot use CMA (ha! complex!)
and I will need to figure out a way to work around that.
The CLCDs synthesized on the core tiles for CA9 work
fine with this though.

Linus Walleij (4):
  drm/pl111: Make the default BPP a per-variant variable
  drm/pl111: Use max memory bandwidth for resolution
  drm/pl111: Handle the RealView variant separately
  drm/pl111: Support the Versatile Express

 drivers/gpu/drm/pl111/Makefile          |   1 +
 drivers/gpu/drm/pl111/pl111_display.c   |  36 +++++++++++
 drivers/gpu/drm/pl111/pl111_drm.h       |   6 +-
 drivers/gpu/drm/pl111/pl111_drv.c       |  10 ++-
 drivers/gpu/drm/pl111/pl111_versatile.c |  80 +++++++++++++++++++++++-
 drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
 7 files changed, 258 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h

-- 
2.14.3

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02  9:09 ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula, Sean Paul, Eric Anholt, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel

This is the base for finally getting RealView and Versatile
Express supported in the PL111 DRM driver.

We have then moved all the way up from the first ARM
Integrator versions to the last Versatile Express reference
designs using PL111.

After this, forked hardware such as Nomadik and SPEAr
remains to be moved over.

Some infrastructure for adjusting depth (ARGB5551) etc
on the Integrator and some bridge fixups are still needed
but this is the core of the support for these platforms
and the rest can be done on top before switching over.

Also the Versatile Express CLCD on the motherboard has
a dedicated video memory, and cannot use CMA (ha! complex!)
and I will need to figure out a way to work around that.
The CLCDs synthesized on the core tiles for CA9 work
fine with this though.

Linus Walleij (4):
  drm/pl111: Make the default BPP a per-variant variable
  drm/pl111: Use max memory bandwidth for resolution
  drm/pl111: Handle the RealView variant separately
  drm/pl111: Support the Versatile Express

 drivers/gpu/drm/pl111/Makefile          |   1 +
 drivers/gpu/drm/pl111/pl111_display.c   |  36 +++++++++++
 drivers/gpu/drm/pl111/pl111_drm.h       |   6 +-
 drivers/gpu/drm/pl111/pl111_drv.c       |  10 ++-
 drivers/gpu/drm/pl111/pl111_versatile.c |  80 +++++++++++++++++++++++-
 drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
 7 files changed, 258 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h

-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 1/4] drm/pl111: Make the default BPP a per-variant variable
  2018-03-02  9:09 ` Linus Walleij
@ 2018-03-02  9:09   ` Linus Walleij
  -1 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: linux-arm-kernel

The PL110, Integrator and Versatile boards strongly prefer to
use 16 BPP even if other modes are supported, both to keep down
memory consumption and also to easier find a good match to
supported resolutions with consideration taken to the memory
bandwidth of the platforms.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/pl111_drm.h       | 2 ++
 drivers/gpu/drm/pl111/pl111_drv.c       | 4 +++-
 drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 6d0e450e51b1..360fbdd2203c 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -43,6 +43,7 @@ struct drm_minor;
  * @broken_vblank: the vblank IRQ is broken on this variant
  * @formats: array of supported pixel formats on this variant
  * @nformats: the length of the array of supported pixel formats
+ * @fb_bpp: desired bits per pixel on the default framebuffer
  */
 struct pl111_variant_data {
 	const char *name;
@@ -52,6 +53,7 @@ struct pl111_variant_data {
 	bool broken_vblank;
 	const u32 *formats;
 	unsigned int nformats;
+	unsigned int fb_bpp;
 };
 
 struct pl111_drm_dev_private {
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 1231905150d0..73d252351438 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -192,7 +192,7 @@ static int pl111_modeset_init(struct drm_device *dev)
 
 	drm_mode_config_reset(dev);
 
-	drm_fb_cma_fbdev_init(dev, 32, 0);
+	drm_fb_cma_fbdev_init(dev, priv->variant->fb_bpp, 0);
 
 	drm_kms_helper_poll_init(dev);
 
@@ -341,6 +341,7 @@ static const struct pl111_variant_data pl110_variant = {
 	.is_pl110 = true,
 	.formats = pl110_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_pixel_formats),
+	.fb_bpp = 16,
 };
 
 /* RealView, Versatile Express etc use this modern variant */
@@ -365,6 +366,7 @@ static const struct pl111_variant_data pl111_variant = {
 	.name = "PL111",
 	.formats = pl111_pixel_formats,
 	.nformats = ARRAY_SIZE(pl111_pixel_formats),
+	.fb_bpp = 32,
 };
 
 static const struct amba_id pl111_id_table[] = {
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index 11024ad64181..9825f6d52788 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -241,6 +241,7 @@ static const struct pl111_variant_data pl110_integrator = {
 	.broken_vblank = true,
 	.formats = pl110_integrator_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_integrator_pixel_formats),
+	.fb_bpp = 16,
 };
 
 /*
@@ -253,6 +254,7 @@ static const struct pl111_variant_data pl110_versatile = {
 	.external_bgr = true,
 	.formats = pl110_versatile_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_versatile_pixel_formats),
+	.fb_bpp = 16,
 };
 
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
-- 
2.14.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 1/4] drm/pl111: Make the default BPP a per-variant variable
@ 2018-03-02  9:09   ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula, Sean Paul, Eric Anholt, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel

The PL110, Integrator and Versatile boards strongly prefer to
use 16 BPP even if other modes are supported, both to keep down
memory consumption and also to easier find a good match to
supported resolutions with consideration taken to the memory
bandwidth of the platforms.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/pl111_drm.h       | 2 ++
 drivers/gpu/drm/pl111/pl111_drv.c       | 4 +++-
 drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 6d0e450e51b1..360fbdd2203c 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -43,6 +43,7 @@ struct drm_minor;
  * @broken_vblank: the vblank IRQ is broken on this variant
  * @formats: array of supported pixel formats on this variant
  * @nformats: the length of the array of supported pixel formats
+ * @fb_bpp: desired bits per pixel on the default framebuffer
  */
 struct pl111_variant_data {
 	const char *name;
@@ -52,6 +53,7 @@ struct pl111_variant_data {
 	bool broken_vblank;
 	const u32 *formats;
 	unsigned int nformats;
+	unsigned int fb_bpp;
 };
 
 struct pl111_drm_dev_private {
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 1231905150d0..73d252351438 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -192,7 +192,7 @@ static int pl111_modeset_init(struct drm_device *dev)
 
 	drm_mode_config_reset(dev);
 
-	drm_fb_cma_fbdev_init(dev, 32, 0);
+	drm_fb_cma_fbdev_init(dev, priv->variant->fb_bpp, 0);
 
 	drm_kms_helper_poll_init(dev);
 
@@ -341,6 +341,7 @@ static const struct pl111_variant_data pl110_variant = {
 	.is_pl110 = true,
 	.formats = pl110_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_pixel_formats),
+	.fb_bpp = 16,
 };
 
 /* RealView, Versatile Express etc use this modern variant */
@@ -365,6 +366,7 @@ static const struct pl111_variant_data pl111_variant = {
 	.name = "PL111",
 	.formats = pl111_pixel_formats,
 	.nformats = ARRAY_SIZE(pl111_pixel_formats),
+	.fb_bpp = 32,
 };
 
 static const struct amba_id pl111_id_table[] = {
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index 11024ad64181..9825f6d52788 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -241,6 +241,7 @@ static const struct pl111_variant_data pl110_integrator = {
 	.broken_vblank = true,
 	.formats = pl110_integrator_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_integrator_pixel_formats),
+	.fb_bpp = 16,
 };
 
 /*
@@ -253,6 +254,7 @@ static const struct pl111_variant_data pl110_versatile = {
 	.external_bgr = true,
 	.formats = pl110_versatile_pixel_formats,
 	.nformats = ARRAY_SIZE(pl110_versatile_pixel_formats),
+	.fb_bpp = 16,
 };
 
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution
  2018-03-02  9:09 ` Linus Walleij
@ 2018-03-02  9:09   ` Linus Walleij
  -1 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: linux-arm-kernel

We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.

This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.

Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
  so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
  simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
  trying to be heuristic about this setting for now.
---
 drivers/gpu/drm/pl111/pl111_display.c | 36 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm.h     |  1 +
 drivers/gpu/drm/pl111/pl111_drv.c     |  6 ++++++
 3 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index d75923896609..577e61950e16 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
 	return status;
 }
 
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+		 const struct drm_display_mode *mode)
+{
+	struct drm_device *drm = crtc->dev;
+	struct pl111_drm_dev_private *priv = drm->dev_private;
+	u32 cpp = priv->variant->fb_bpp / 8;
+	u64 bw;
+
+	/*
+	 * We use the pixelclock to also account for interlaced modes, the
+	 * resulting bandwidth is in bytes per second.
+	 */
+	bw = mode->clock * 1000; /* In Hz */
+	bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+	bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+	/*
+	 * If no bandwidth constraints, anything goes, else
+	 * check if we are too fast.
+	 */
+	if (priv->memory_bw && (bw > priv->memory_bw)) {
+		DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+			 mode->hdisplay, mode->vdisplay,
+			 mode->clock * 1000, cpp, bw);
+
+		return MODE_BAD;
+	}
+	DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+		 mode->hdisplay, mode->vdisplay,
+		 mode->clock * 1000, cpp, bw);
+
+	return MODE_OK;
+}
+
 static int pl111_display_check(struct drm_simple_display_pipe *pipe,
 			       struct drm_plane_state *pstate,
 			       struct drm_crtc_state *cstate)
@@ -344,6 +379,7 @@ static int pl111_display_prepare_fb(struct drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+	.mode_valid = pl111_mode_valid,
 	.check = pl111_display_check,
 	.enable = pl111_display_enable,
 	.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 360fbdd2203c..70b092670c04 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
 	struct drm_simple_display_pipe pipe;
 
 	void *regs;
+	u32 memory_bw;
 	u32 ienb;
 	u32 ctrl;
 	/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 73d252351438..b469aa317d9d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -262,6 +262,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
 	drm->dev_private = priv;
 	priv->variant = variant;
 
+	if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+				 &priv->memory_bw)) {
+		dev_info(dev, "no max memory bandwidth specified, assume unlimited\n");
+		priv->memory_bw = 0;
+	}
+
 	/* The two variants swap this register */
 	if (variant->is_pl110) {
 		priv->ienb = CLCD_PL110_IENB;
-- 
2.14.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution
@ 2018-03-02  9:09   ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula, Sean Paul, Eric Anholt, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel

We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.

This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.

Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Account for the case where there is no bandwidth limitation
  so priv->memory_bw is zero. Then just accept any modes.
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
  simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
  trying to be heuristic about this setting for now.
---
 drivers/gpu/drm/pl111/pl111_display.c | 36 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm.h     |  1 +
 drivers/gpu/drm/pl111/pl111_drv.c     |  6 ++++++
 3 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index d75923896609..577e61950e16 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
 	return status;
 }
 
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+		 const struct drm_display_mode *mode)
+{
+	struct drm_device *drm = crtc->dev;
+	struct pl111_drm_dev_private *priv = drm->dev_private;
+	u32 cpp = priv->variant->fb_bpp / 8;
+	u64 bw;
+
+	/*
+	 * We use the pixelclock to also account for interlaced modes, the
+	 * resulting bandwidth is in bytes per second.
+	 */
+	bw = mode->clock * 1000; /* In Hz */
+	bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+	bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+	/*
+	 * If no bandwidth constraints, anything goes, else
+	 * check if we are too fast.
+	 */
+	if (priv->memory_bw && (bw > priv->memory_bw)) {
+		DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+			 mode->hdisplay, mode->vdisplay,
+			 mode->clock * 1000, cpp, bw);
+
+		return MODE_BAD;
+	}
+	DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+		 mode->hdisplay, mode->vdisplay,
+		 mode->clock * 1000, cpp, bw);
+
+	return MODE_OK;
+}
+
 static int pl111_display_check(struct drm_simple_display_pipe *pipe,
 			       struct drm_plane_state *pstate,
 			       struct drm_crtc_state *cstate)
@@ -344,6 +379,7 @@ static int pl111_display_prepare_fb(struct drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+	.mode_valid = pl111_mode_valid,
 	.check = pl111_display_check,
 	.enable = pl111_display_enable,
 	.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 360fbdd2203c..70b092670c04 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -65,6 +65,7 @@ struct pl111_drm_dev_private {
 	struct drm_simple_display_pipe pipe;
 
 	void *regs;
+	u32 memory_bw;
 	u32 ienb;
 	u32 ctrl;
 	/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 73d252351438..b469aa317d9d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -262,6 +262,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
 	drm->dev_private = priv;
 	priv->variant = variant;
 
+	if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+				 &priv->memory_bw)) {
+		dev_info(dev, "no max memory bandwidth specified, assume unlimited\n");
+		priv->memory_bw = 0;
+	}
+
 	/* The two variants swap this register */
 	if (variant->is_pl110) {
 		priv->ienb = CLCD_PL110_IENB;
-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 3/4] drm/pl111: Handle the RealView variant separately
  2018-03-02  9:09 ` Linus Walleij
@ 2018-03-02  9:09   ` Linus Walleij
  -1 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: linux-arm-kernel

We want to cut down the default bpp to 16 on the RealView so
we can have a 1024x768 framebuffer console by default. The
memory bandwidth limitations makes this not work with the
PL111 default of 32bpp.

This builds on top of the earlier patches making the
framebuffer default bpp a per-variant variable.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/pl111_versatile.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index 9825f6d52788..f15391d994b6 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -230,6 +230,23 @@ static const u32 pl110_versatile_pixel_formats[] = {
 	DRM_FORMAT_XRGB1555,
 };
 
+static const u32 pl111_realview_pixel_formats[] = {
+	DRM_FORMAT_ABGR8888,
+	DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_BGR565,
+	DRM_FORMAT_RGB565,
+	DRM_FORMAT_ABGR1555,
+	DRM_FORMAT_XBGR1555,
+	DRM_FORMAT_ARGB1555,
+	DRM_FORMAT_XRGB1555,
+	DRM_FORMAT_ABGR4444,
+	DRM_FORMAT_XBGR4444,
+	DRM_FORMAT_ARGB4444,
+	DRM_FORMAT_XRGB4444,
+};
+
 /*
  * The Integrator variant is a PL110 with a bunch of broken, or not
  * yet implemented features
@@ -257,6 +274,18 @@ static const struct pl111_variant_data pl110_versatile = {
 	.fb_bpp = 16,
 };
 
+/*
+ * RealView PL111 variant, the only real difference from the vanilla
+ * PL111 is that we select 16bpp framebuffer by default to be able
+ * to get 1024x768 without saturating the memory bus.
+ */
+static const struct pl111_variant_data pl111_realview = {
+	.name = "PL111 RealView",
+	.formats = pl111_realview_pixel_formats,
+	.nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+	.fb_bpp = 16,
+};
+
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 {
 	const struct of_device_id *clcd_id;
@@ -306,6 +335,7 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 	case REALVIEW_CLCD_PBA8:
 	case REALVIEW_CLCD_PBX:
 		versatile_syscon_map = map;
+		priv->variant = &pl111_realview;
 		priv->variant_display_enable = pl111_realview_clcd_enable;
 		priv->variant_display_disable = pl111_realview_clcd_disable;
 		dev_info(dev, "set up callbacks for RealView PL111\n");
-- 
2.14.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 3/4] drm/pl111: Handle the RealView variant separately
@ 2018-03-02  9:09   ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula, Sean Paul, Eric Anholt, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel

We want to cut down the default bpp to 16 on the RealView so
we can have a 1024x768 framebuffer console by default. The
memory bandwidth limitations makes this not work with the
PL111 default of 32bpp.

This builds on top of the earlier patches making the
framebuffer default bpp a per-variant variable.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/pl111_versatile.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index 9825f6d52788..f15391d994b6 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -230,6 +230,23 @@ static const u32 pl110_versatile_pixel_formats[] = {
 	DRM_FORMAT_XRGB1555,
 };
 
+static const u32 pl111_realview_pixel_formats[] = {
+	DRM_FORMAT_ABGR8888,
+	DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_BGR565,
+	DRM_FORMAT_RGB565,
+	DRM_FORMAT_ABGR1555,
+	DRM_FORMAT_XBGR1555,
+	DRM_FORMAT_ARGB1555,
+	DRM_FORMAT_XRGB1555,
+	DRM_FORMAT_ABGR4444,
+	DRM_FORMAT_XBGR4444,
+	DRM_FORMAT_ARGB4444,
+	DRM_FORMAT_XRGB4444,
+};
+
 /*
  * The Integrator variant is a PL110 with a bunch of broken, or not
  * yet implemented features
@@ -257,6 +274,18 @@ static const struct pl111_variant_data pl110_versatile = {
 	.fb_bpp = 16,
 };
 
+/*
+ * RealView PL111 variant, the only real difference from the vanilla
+ * PL111 is that we select 16bpp framebuffer by default to be able
+ * to get 1024x768 without saturating the memory bus.
+ */
+static const struct pl111_variant_data pl111_realview = {
+	.name = "PL111 RealView",
+	.formats = pl111_realview_pixel_formats,
+	.nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+	.fb_bpp = 16,
+};
+
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 {
 	const struct of_device_id *clcd_id;
@@ -306,6 +335,7 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 	case REALVIEW_CLCD_PBA8:
 	case REALVIEW_CLCD_PBX:
 		versatile_syscon_map = map;
+		priv->variant = &pl111_realview;
 		priv->variant_display_enable = pl111_realview_clcd_enable;
 		priv->variant_display_disable = pl111_realview_clcd_disable;
 		dev_info(dev, "set up callbacks for RealView PL111\n");
-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 4/4] drm/pl111: Support the Versatile Express
  2018-03-02  9:09 ` Linus Walleij
@ 2018-03-02  9:09   ` Linus Walleij
  -1 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: linux-arm-kernel

The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) CLCD instances out to the single SiI9022
bridge.

Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then parse the memory
range argument to figure out what path the CLCD signal is
actually taking, and set up the mux accordingly.

If there is a CLCD instance on the core tile (the daughterboard
with the CPUs fitted) then that CLCD instance will take
precedence since it can address all memory.

Scale down the Versatile Express to 16BPP so we can support a
1024x768 display despite the bus bandwidth restrictions on this
platform.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/Makefile          |   1 +
 drivers/gpu/drm/pl111/pl111_drm.h       |   3 +-
 drivers/gpu/drm/pl111/pl111_versatile.c |  48 ++++++++++++++-
 drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
 5 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h

diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index 9c5e8dba8ac6..19a8189dc54f 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -3,6 +3,7 @@ pl111_drm-y +=	pl111_display.o \
 		pl111_versatile.o \
 		pl111_drv.o
 
+pl111_drm-$(CONFIG_ARCH_VEXPRESS) += pl111_vexpress.o
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
 
 obj-$(CONFIG_DRM_PL111) += pl111_drm.o
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 70b092670c04..e7c5d4a09238 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -64,7 +64,8 @@ struct pl111_drm_dev_private {
 	struct drm_bridge *bridge;
 	struct drm_simple_display_pipe pipe;
 
-	void *regs;
+	void __iomem *clcd_memory;
+	void __iomem *regs;
 	u32 memory_bw;
 	u32 ienb;
 	u32 ctrl;
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index f15391d994b6..0170c34fb653 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -1,12 +1,14 @@
 #include <linux/amba/clcd-regs.h>
 #include <linux/device.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 #include <linux/bitops.h>
 #include <linux/module.h>
 #include <drm/drmP.h>
 #include "pl111_versatile.h"
+#include "pl111_vexpress.h"
 #include "pl111_drm.h"
 
 static struct regmap *versatile_syscon_map;
@@ -22,6 +24,7 @@ enum versatile_clcd {
 	REALVIEW_CLCD_PB11MP,
 	REALVIEW_CLCD_PBA8,
 	REALVIEW_CLCD_PBX,
+	VEXPRESS_CLCD_V2M,
 };
 
 static const struct of_device_id versatile_clcd_of_match[] = {
@@ -53,6 +56,10 @@ static const struct of_device_id versatile_clcd_of_match[] = {
 		.compatible = "arm,realview-pbx-syscon",
 		.data = (void *)REALVIEW_CLCD_PBX,
 	},
+	{
+		.compatible = "arm,vexpress-muxfpga",
+		.data = (void *)VEXPRESS_CLCD_V2M,
+	},
 	{},
 };
 
@@ -286,12 +293,26 @@ static const struct pl111_variant_data pl111_realview = {
 	.fb_bpp = 16,
 };
 
+/*
+ * Versatile Express PL111 variant, again we just push the maximum
+ * BPP to 16 to be able to get 1024x768 without saturating the memory
+ * bus. The clockdivider also seems broken on the Versatile Express.
+ */
+static const struct pl111_variant_data pl111_vexpress = {
+	.name = "PL111 Versatile Express",
+	.formats = pl111_realview_pixel_formats,
+	.nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+	.fb_bpp = 16,
+	.broken_clockdivider = true,
+};
+
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 {
 	const struct of_device_id *clcd_id;
 	enum versatile_clcd versatile_clcd_type;
 	struct device_node *np;
 	struct regmap *map;
+	int ret;
 
 	np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
 					     &clcd_id);
@@ -301,7 +322,25 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 	}
 	versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
 
-	map = syscon_node_to_regmap(np);
+	/* Versatile Express special handling */
+	if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
+		struct platform_device *pdev;
+
+		/* Call into deep Vexpress configuration API */
+		pdev = of_find_device_by_node(np);
+		if (!pdev) {
+			dev_err(dev, "can't find the sysreg device, deferring\n");
+			return -EPROBE_DEFER;
+		}
+		map = dev_get_drvdata(&pdev->dev);
+		if (!map) {
+			dev_err(dev, "sysreg has not yet probed\n");
+			return -EPROBE_DEFER;
+		}
+	} else {
+		map = syscon_node_to_regmap(np);
+	}
+
 	if (IS_ERR(map)) {
 		dev_err(dev, "no Versatile syscon regmap\n");
 		return PTR_ERR(map);
@@ -340,6 +379,13 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 		priv->variant_display_disable = pl111_realview_clcd_disable;
 		dev_info(dev, "set up callbacks for RealView PL111\n");
 		break;
+	case VEXPRESS_CLCD_V2M:
+		priv->variant = &pl111_vexpress;
+		dev_info(dev, "initializing Versatile Express PL111\n");
+		ret = pl111_vexpress_clcd_init(dev, priv, map);
+		if (ret)
+			return ret;
+		break;
 	default:
 		dev_info(dev, "unknown Versatile system controller\n");
 		break;
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c b/drivers/gpu/drm/pl111/pl111_vexpress.c
new file mode 100644
index 000000000000..720244f497fe
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Versatile Express PL111 handling
+ * Copyright (C) 2018 Linus Walleij
+ *
+ * This module binds to the "arm,vexpress-muxfpga" device on the
+ * Versatile Express configuration bus and sets up which CLCD instance
+ * gets muxed out on the DVI bridge.
+ */
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/vexpress.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include "pl111_drm.h"
+#include "pl111_vexpress.h"
+
+#define VEXPRESS_FPGAMUX_MOTHERBOARD		0x00
+#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_1	0x01
+#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_2	0x02
+
+static bool daughterboard_muxed = false;
+static bool motherboard_muxed = false;
+
+int pl111_vexpress_clcd_init(struct device *dev,
+			     struct pl111_drm_dev_private *priv,
+			     struct regmap *map)
+{
+	struct device_node *memory;
+	u32 val;
+	int ret;
+
+	/*
+	 * The CLCD on the motherboard has a special memory region and
+	 * does not make use of CMA. We differentiate between the different
+	 * CLCD controllers using this memory region phandle.
+	 */
+	memory = of_parse_phandle(dev->of_node, "memory-region", 0);
+	if (!memory) {
+		if (motherboard_muxed) {
+			dev_info(dev, "motherboard CLCD muxed in\n");
+			dev_info(dev, "daughterboard takes precedence\n");
+			dev_info(dev, "motherboard CLCD will not be muxed out\n");
+		}
+		dev_info(dev,
+			 "DVI muxed to daughterboard 1 (core tile) CLCD\n");
+		val = VEXPRESS_FPGAMUX_DAUGHTERBOARD_1;
+		daughterboard_muxed = true;
+	} else {
+		priv->clcd_memory = of_iomap(memory, 0);
+		if (!priv->clcd_memory)
+			dev_err(dev, "could not remap CLCD memory\n");
+		/* Fall through and try to use CMA */
+		if (daughterboard_muxed) {
+			dev_info(dev, "daughterboard takes precedence\n");
+			dev_info(dev, "motherboard CLCD will not be muxed out\n");
+			return -ENODEV;
+		}
+		dev_info(dev, "DVI muxed to motherboard CLCD\n");
+		val = VEXPRESS_FPGAMUX_MOTHERBOARD;
+		motherboard_muxed = true;
+	}
+
+	ret = regmap_write(map, 0, val);
+	if (ret) {
+		dev_err(dev, "error setting DVI muxmode\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+/*
+ * This sets up the regmap pointer that will then be retrieved by
+ * the detection code in pl111_versatile.c and passed in to the
+ * pl111_vexpress_clcd_init() function above.
+ */
+static int vexpress_muxfpga_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct regmap *map;
+
+	map = devm_regmap_init_vexpress_config(&pdev->dev);
+	if (IS_ERR(map))
+		return PTR_ERR(map);
+	dev_set_drvdata(dev, map);
+
+	return 0;
+}
+
+static const struct of_device_id vexpress_muxfpga_match[] = {
+	{ .compatible = "arm,vexpress-muxfpga", }
+};
+
+static struct platform_driver vexpress_muxfpga_driver = {
+	.driver = {
+		.name = "vexpress-muxfpga",
+		.of_match_table = of_match_ptr(vexpress_muxfpga_match),
+	},
+	.probe = vexpress_muxfpga_probe,
+};
+
+module_platform_driver(vexpress_muxfpga_driver);
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h b/drivers/gpu/drm/pl111/pl111_vexpress.h
new file mode 100644
index 000000000000..49876417f7b6
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+
+struct device;
+struct pl111_drm_dev_private;
+struct regmap;
+
+#ifdef CONFIG_ARCH_VEXPRESS
+
+int pl111_vexpress_clcd_init(struct device *dev,
+			     struct pl111_drm_dev_private *priv,
+			     struct regmap *map);
+
+#else
+
+static int inline pl111_vexpress_clcd_init(struct device *dev,
+					   struct pl111_drm_dev_private *priv,
+					   struct regmap *map)
+{
+	return -ENODEV;
+}
+
+#endif
-- 
2.14.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 4/4] drm/pl111: Support the Versatile Express
@ 2018-03-02  9:09   ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02  9:09 UTC (permalink / raw)
  To: Daniel Vetter, Jani Nikula, Sean Paul, Eric Anholt, Liviu Dudau
  Cc: Pawel Moll, linux-arm-kernel, dri-devel

The Versatile Express uses a special configuration controller
deeply embedded in the system motherboard FPGA to multiplex the
two to three (!) CLCD instances out to the single SiI9022
bridge.

Set up an extra file with the logic to probe to the FPGA mux
register on the system controller bus, then parse the memory
range argument to figure out what path the CLCD signal is
actually taking, and set up the mux accordingly.

If there is a CLCD instance on the core tile (the daughterboard
with the CPUs fitted) then that CLCD instance will take
precedence since it can address all memory.

Scale down the Versatile Express to 16BPP so we can support a
1024x768 display despite the bus bandwidth restrictions on this
platform.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/gpu/drm/pl111/Makefile          |   1 +
 drivers/gpu/drm/pl111/pl111_drm.h       |   3 +-
 drivers/gpu/drm/pl111/pl111_versatile.c |  48 ++++++++++++++-
 drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
 5 files changed, 178 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h

diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index 9c5e8dba8ac6..19a8189dc54f 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -3,6 +3,7 @@ pl111_drm-y +=	pl111_display.o \
 		pl111_versatile.o \
 		pl111_drv.o
 
+pl111_drm-$(CONFIG_ARCH_VEXPRESS) += pl111_vexpress.o
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
 
 obj-$(CONFIG_DRM_PL111) += pl111_drm.o
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index 70b092670c04..e7c5d4a09238 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -64,7 +64,8 @@ struct pl111_drm_dev_private {
 	struct drm_bridge *bridge;
 	struct drm_simple_display_pipe pipe;
 
-	void *regs;
+	void __iomem *clcd_memory;
+	void __iomem *regs;
 	u32 memory_bw;
 	u32 ienb;
 	u32 ctrl;
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index f15391d994b6..0170c34fb653 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -1,12 +1,14 @@
 #include <linux/amba/clcd-regs.h>
 #include <linux/device.h>
 #include <linux/of.h>
+#include <linux/of_platform.h>
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 #include <linux/bitops.h>
 #include <linux/module.h>
 #include <drm/drmP.h>
 #include "pl111_versatile.h"
+#include "pl111_vexpress.h"
 #include "pl111_drm.h"
 
 static struct regmap *versatile_syscon_map;
@@ -22,6 +24,7 @@ enum versatile_clcd {
 	REALVIEW_CLCD_PB11MP,
 	REALVIEW_CLCD_PBA8,
 	REALVIEW_CLCD_PBX,
+	VEXPRESS_CLCD_V2M,
 };
 
 static const struct of_device_id versatile_clcd_of_match[] = {
@@ -53,6 +56,10 @@ static const struct of_device_id versatile_clcd_of_match[] = {
 		.compatible = "arm,realview-pbx-syscon",
 		.data = (void *)REALVIEW_CLCD_PBX,
 	},
+	{
+		.compatible = "arm,vexpress-muxfpga",
+		.data = (void *)VEXPRESS_CLCD_V2M,
+	},
 	{},
 };
 
@@ -286,12 +293,26 @@ static const struct pl111_variant_data pl111_realview = {
 	.fb_bpp = 16,
 };
 
+/*
+ * Versatile Express PL111 variant, again we just push the maximum
+ * BPP to 16 to be able to get 1024x768 without saturating the memory
+ * bus. The clockdivider also seems broken on the Versatile Express.
+ */
+static const struct pl111_variant_data pl111_vexpress = {
+	.name = "PL111 Versatile Express",
+	.formats = pl111_realview_pixel_formats,
+	.nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
+	.fb_bpp = 16,
+	.broken_clockdivider = true,
+};
+
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 {
 	const struct of_device_id *clcd_id;
 	enum versatile_clcd versatile_clcd_type;
 	struct device_node *np;
 	struct regmap *map;
+	int ret;
 
 	np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
 					     &clcd_id);
@@ -301,7 +322,25 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 	}
 	versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
 
-	map = syscon_node_to_regmap(np);
+	/* Versatile Express special handling */
+	if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
+		struct platform_device *pdev;
+
+		/* Call into deep Vexpress configuration API */
+		pdev = of_find_device_by_node(np);
+		if (!pdev) {
+			dev_err(dev, "can't find the sysreg device, deferring\n");
+			return -EPROBE_DEFER;
+		}
+		map = dev_get_drvdata(&pdev->dev);
+		if (!map) {
+			dev_err(dev, "sysreg has not yet probed\n");
+			return -EPROBE_DEFER;
+		}
+	} else {
+		map = syscon_node_to_regmap(np);
+	}
+
 	if (IS_ERR(map)) {
 		dev_err(dev, "no Versatile syscon regmap\n");
 		return PTR_ERR(map);
@@ -340,6 +379,13 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
 		priv->variant_display_disable = pl111_realview_clcd_disable;
 		dev_info(dev, "set up callbacks for RealView PL111\n");
 		break;
+	case VEXPRESS_CLCD_V2M:
+		priv->variant = &pl111_vexpress;
+		dev_info(dev, "initializing Versatile Express PL111\n");
+		ret = pl111_vexpress_clcd_init(dev, priv, map);
+		if (ret)
+			return ret;
+		break;
 	default:
 		dev_info(dev, "unknown Versatile system controller\n");
 		break;
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c b/drivers/gpu/drm/pl111/pl111_vexpress.c
new file mode 100644
index 000000000000..720244f497fe
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Versatile Express PL111 handling
+ * Copyright (C) 2018 Linus Walleij
+ *
+ * This module binds to the "arm,vexpress-muxfpga" device on the
+ * Versatile Express configuration bus and sets up which CLCD instance
+ * gets muxed out on the DVI bridge.
+ */
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/vexpress.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include "pl111_drm.h"
+#include "pl111_vexpress.h"
+
+#define VEXPRESS_FPGAMUX_MOTHERBOARD		0x00
+#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_1	0x01
+#define VEXPRESS_FPGAMUX_DAUGHTERBOARD_2	0x02
+
+static bool daughterboard_muxed = false;
+static bool motherboard_muxed = false;
+
+int pl111_vexpress_clcd_init(struct device *dev,
+			     struct pl111_drm_dev_private *priv,
+			     struct regmap *map)
+{
+	struct device_node *memory;
+	u32 val;
+	int ret;
+
+	/*
+	 * The CLCD on the motherboard has a special memory region and
+	 * does not make use of CMA. We differentiate between the different
+	 * CLCD controllers using this memory region phandle.
+	 */
+	memory = of_parse_phandle(dev->of_node, "memory-region", 0);
+	if (!memory) {
+		if (motherboard_muxed) {
+			dev_info(dev, "motherboard CLCD muxed in\n");
+			dev_info(dev, "daughterboard takes precedence\n");
+			dev_info(dev, "motherboard CLCD will not be muxed out\n");
+		}
+		dev_info(dev,
+			 "DVI muxed to daughterboard 1 (core tile) CLCD\n");
+		val = VEXPRESS_FPGAMUX_DAUGHTERBOARD_1;
+		daughterboard_muxed = true;
+	} else {
+		priv->clcd_memory = of_iomap(memory, 0);
+		if (!priv->clcd_memory)
+			dev_err(dev, "could not remap CLCD memory\n");
+		/* Fall through and try to use CMA */
+		if (daughterboard_muxed) {
+			dev_info(dev, "daughterboard takes precedence\n");
+			dev_info(dev, "motherboard CLCD will not be muxed out\n");
+			return -ENODEV;
+		}
+		dev_info(dev, "DVI muxed to motherboard CLCD\n");
+		val = VEXPRESS_FPGAMUX_MOTHERBOARD;
+		motherboard_muxed = true;
+	}
+
+	ret = regmap_write(map, 0, val);
+	if (ret) {
+		dev_err(dev, "error setting DVI muxmode\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+/*
+ * This sets up the regmap pointer that will then be retrieved by
+ * the detection code in pl111_versatile.c and passed in to the
+ * pl111_vexpress_clcd_init() function above.
+ */
+static int vexpress_muxfpga_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct regmap *map;
+
+	map = devm_regmap_init_vexpress_config(&pdev->dev);
+	if (IS_ERR(map))
+		return PTR_ERR(map);
+	dev_set_drvdata(dev, map);
+
+	return 0;
+}
+
+static const struct of_device_id vexpress_muxfpga_match[] = {
+	{ .compatible = "arm,vexpress-muxfpga", }
+};
+
+static struct platform_driver vexpress_muxfpga_driver = {
+	.driver = {
+		.name = "vexpress-muxfpga",
+		.of_match_table = of_match_ptr(vexpress_muxfpga_match),
+	},
+	.probe = vexpress_muxfpga_probe,
+};
+
+module_platform_driver(vexpress_muxfpga_driver);
diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h b/drivers/gpu/drm/pl111/pl111_vexpress.h
new file mode 100644
index 000000000000..49876417f7b6
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+
+struct device;
+struct pl111_drm_dev_private;
+struct regmap;
+
+#ifdef CONFIG_ARCH_VEXPRESS
+
+int pl111_vexpress_clcd_init(struct device *dev,
+			     struct pl111_drm_dev_private *priv,
+			     struct regmap *map);
+
+#else
+
+static int inline pl111_vexpress_clcd_init(struct device *dev,
+					   struct pl111_drm_dev_private *priv,
+					   struct regmap *map)
+{
+	return -ENODEV;
+}
+
+#endif
-- 
2.14.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 0/4] drm/pl111: RealView and Versatile Express
  2018-03-02  9:09 ` Linus Walleij
@ 2018-03-02 12:11   ` Robin Murphy
  -1 siblings, 0 replies; 22+ messages in thread
From: Robin Murphy @ 2018-03-02 12:11 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Linus,

On 02/03/18 09:09, Linus Walleij wrote:
> This is the base for finally getting RealView and Versatile
> Express supported in the PL111 DRM driver.
> 
> We have then moved all the way up from the first ARM
> Integrator versions to the last Versatile Express reference
> designs using PL111.
> 
> After this, forked hardware such as Nomadik and SPEAr
> remains to be moved over.
> 
> Some infrastructure for adjusting depth (ARGB5551) etc
> on the Integrator and some bridge fixups are still needed
> but this is the core of the support for these platforms
> and the rest can be done on top before switching over.
> 
> Also the Versatile Express CLCD on the motherboard has
> a dedicated video memory, and cannot use CMA (ha! complex!)
> and I will need to figure out a way to work around that.
> The CLCDs synthesized on the core tiles for CA9 work
> fine with this though.

Out of curiosity, what's the issue with declaring the VRAM as a CMA 
region? That's certainly worked for stuff like local RAM on FPGA tiles 
in the past, and I can't think offhand of any way in which VExpress is 
wildly different (but I am of course open to being wrong...)

Robin.

> Linus Walleij (4):
>    drm/pl111: Make the default BPP a per-variant variable
>    drm/pl111: Use max memory bandwidth for resolution
>    drm/pl111: Handle the RealView variant separately
>    drm/pl111: Support the Versatile Express
> 
>   drivers/gpu/drm/pl111/Makefile          |   1 +
>   drivers/gpu/drm/pl111/pl111_display.c   |  36 +++++++++++
>   drivers/gpu/drm/pl111/pl111_drm.h       |   6 +-
>   drivers/gpu/drm/pl111/pl111_drv.c       |  10 ++-
>   drivers/gpu/drm/pl111/pl111_versatile.c |  80 +++++++++++++++++++++++-
>   drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
>   7 files changed, 258 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
>   create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02 12:11   ` Robin Murphy
  0 siblings, 0 replies; 22+ messages in thread
From: Robin Murphy @ 2018-03-02 12:11 UTC (permalink / raw)
  To: Linus Walleij, Daniel Vetter, Jani Nikula, Sean Paul,
	Eric Anholt, Liviu Dudau
  Cc: dri-devel, linux-arm-kernel

Hi Linus,

On 02/03/18 09:09, Linus Walleij wrote:
> This is the base for finally getting RealView and Versatile
> Express supported in the PL111 DRM driver.
> 
> We have then moved all the way up from the first ARM
> Integrator versions to the last Versatile Express reference
> designs using PL111.
> 
> After this, forked hardware such as Nomadik and SPEAr
> remains to be moved over.
> 
> Some infrastructure for adjusting depth (ARGB5551) etc
> on the Integrator and some bridge fixups are still needed
> but this is the core of the support for these platforms
> and the rest can be done on top before switching over.
> 
> Also the Versatile Express CLCD on the motherboard has
> a dedicated video memory, and cannot use CMA (ha! complex!)
> and I will need to figure out a way to work around that.
> The CLCDs synthesized on the core tiles for CA9 work
> fine with this though.

Out of curiosity, what's the issue with declaring the VRAM as a CMA 
region? That's certainly worked for stuff like local RAM on FPGA tiles 
in the past, and I can't think offhand of any way in which VExpress is 
wildly different (but I am of course open to being wrong...)

Robin.

> Linus Walleij (4):
>    drm/pl111: Make the default BPP a per-variant variable
>    drm/pl111: Use max memory bandwidth for resolution
>    drm/pl111: Handle the RealView variant separately
>    drm/pl111: Support the Versatile Express
> 
>   drivers/gpu/drm/pl111/Makefile          |   1 +
>   drivers/gpu/drm/pl111/pl111_display.c   |  36 +++++++++++
>   drivers/gpu/drm/pl111/pl111_drm.h       |   6 +-
>   drivers/gpu/drm/pl111/pl111_drv.c       |  10 ++-
>   drivers/gpu/drm/pl111/pl111_versatile.c |  80 +++++++++++++++++++++++-
>   drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 ++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++++++
>   7 files changed, 258 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
>   create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 0/4] drm/pl111: RealView and Versatile Express
  2018-03-02 12:11   ` Robin Murphy
@ 2018-03-02 12:37     ` Linus Walleij
  -1 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02 12:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 02/03/18 09:09, Linus Walleij wrote:

>> Also the Versatile Express CLCD on the motherboard has
>> a dedicated video memory, and cannot use CMA (ha! complex!)
>> and I will need to figure out a way to work around that.
>> The CLCDs synthesized on the core tiles for CA9 work
>> fine with this though.
>
> Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
> That's certainly worked for stuff like local RAM on FPGA tiles in the past,
> and I can't think offhand of any way in which VExpress is wildly different
> (but I am of course open to being wrong...)

There is nothing wrong with that apart from my ignorance
of that solution. So thanks! :D

My experience with CMA is limited to using the 7 areas
that are defined by default in Kconfig and the DRM helpers
just plugging in on the front.

Do you have some pointers? Is this something I can
handily just set up in the device tree?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02 12:37     ` Linus Walleij
  0 siblings, 0 replies; 22+ messages in thread
From: Linus Walleij @ 2018-03-02 12:37 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Liviu Dudau, open list:DRM PANEL DRIVERS, Daniel Vetter, Linux ARM

On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 02/03/18 09:09, Linus Walleij wrote:

>> Also the Versatile Express CLCD on the motherboard has
>> a dedicated video memory, and cannot use CMA (ha! complex!)
>> and I will need to figure out a way to work around that.
>> The CLCDs synthesized on the core tiles for CA9 work
>> fine with this though.
>
> Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
> That's certainly worked for stuff like local RAM on FPGA tiles in the past,
> and I can't think offhand of any way in which VExpress is wildly different
> (but I am of course open to being wrong...)

There is nothing wrong with that apart from my ignorance
of that solution. So thanks! :D

My experience with CMA is limited to using the 7 areas
that are defined by default in Kconfig and the DRM helpers
just plugging in on the front.

Do you have some pointers? Is this something I can
handily just set up in the device tree?

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 0/4] drm/pl111: RealView and Versatile Express
  2018-03-02 12:37     ` Linus Walleij
@ 2018-03-02 13:50       ` Robin Murphy
  -1 siblings, 0 replies; 22+ messages in thread
From: Robin Murphy @ 2018-03-02 13:50 UTC (permalink / raw)
  To: linux-arm-kernel

On 02/03/18 12:37, Linus Walleij wrote:
> On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 02/03/18 09:09, Linus Walleij wrote:
> 
>>> Also the Versatile Express CLCD on the motherboard has
>>> a dedicated video memory, and cannot use CMA (ha! complex!)
>>> and I will need to figure out a way to work around that.
>>> The CLCDs synthesized on the core tiles for CA9 work
>>> fine with this though.
>>
>> Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
>> That's certainly worked for stuff like local RAM on FPGA tiles in the past,
>> and I can't think offhand of any way in which VExpress is wildly different
>> (but I am of course open to being wrong...)
> 
> There is nothing wrong with that apart from my ignorance
> of that solution. So thanks! :D
> 
> My experience with CMA is limited to using the 7 areas
> that are defined by default in Kconfig and the DRM helpers
> just plugging in on the front.
> 
> Do you have some pointers? Is this something I can
> handily just set up in the device tree?

It should be - the inner workings of dma-{coherent,contiguous} are a 
maze of twisty little passages, all alike, and it'll take me a while to 
page the details back in, but IIRC it's mostly just a case of having a 
reserved-memory node covering the VRAM with the right combination of 
magic properties for rmem_dma_setup() to pick up, such that it gets 
assigned as the CLCD's private region. The subsequent "just plugging in" 
aspect doesn't change, it just makes allocations start taking this route 
under the covers:

   drm_gem_cma_create()
     dma_alloc_wc()
       dma_alloc_attrs()
         dma_alloc_from_dev_coherent()

I could have sworn I've exchanged relevant FPGA DT fragments with Liviu 
in the past, but now I can't seem to find one to refer back to :(

Robin.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02 13:50       ` Robin Murphy
  0 siblings, 0 replies; 22+ messages in thread
From: Robin Murphy @ 2018-03-02 13:50 UTC (permalink / raw)
  To: Linus Walleij, Liviu Dudau
  Cc: open list:DRM PANEL DRIVERS, Daniel Vetter, Linux ARM

On 02/03/18 12:37, Linus Walleij wrote:
> On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 02/03/18 09:09, Linus Walleij wrote:
> 
>>> Also the Versatile Express CLCD on the motherboard has
>>> a dedicated video memory, and cannot use CMA (ha! complex!)
>>> and I will need to figure out a way to work around that.
>>> The CLCDs synthesized on the core tiles for CA9 work
>>> fine with this though.
>>
>> Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
>> That's certainly worked for stuff like local RAM on FPGA tiles in the past,
>> and I can't think offhand of any way in which VExpress is wildly different
>> (but I am of course open to being wrong...)
> 
> There is nothing wrong with that apart from my ignorance
> of that solution. So thanks! :D
> 
> My experience with CMA is limited to using the 7 areas
> that are defined by default in Kconfig and the DRM helpers
> just plugging in on the front.
> 
> Do you have some pointers? Is this something I can
> handily just set up in the device tree?

It should be - the inner workings of dma-{coherent,contiguous} are a 
maze of twisty little passages, all alike, and it'll take me a while to 
page the details back in, but IIRC it's mostly just a case of having a 
reserved-memory node covering the VRAM with the right combination of 
magic properties for rmem_dma_setup() to pick up, such that it gets 
assigned as the CLCD's private region. The subsequent "just plugging in" 
aspect doesn't change, it just makes allocations start taking this route 
under the covers:

   drm_gem_cma_create()
     dma_alloc_wc()
       dma_alloc_attrs()
         dma_alloc_from_dev_coherent()

I could have sworn I've exchanged relevant FPGA DT fragments with Liviu 
in the past, but now I can't seem to find one to refer back to :(

Robin.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 0/4] drm/pl111: RealView and Versatile Express
  2018-03-02 13:50       ` Robin Murphy
@ 2018-03-02 15:43         ` Liviu Dudau
  -1 siblings, 0 replies; 22+ messages in thread
From: Liviu Dudau @ 2018-03-02 15:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 02, 2018 at 01:50:20PM +0000, Robin Murphy wrote:
> On 02/03/18 12:37, Linus Walleij wrote:
> > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> > > On 02/03/18 09:09, Linus Walleij wrote:
> > 
> > > > Also the Versatile Express CLCD on the motherboard has
> > > > a dedicated video memory, and cannot use CMA (ha! complex!)
> > > > and I will need to figure out a way to work around that.
> > > > The CLCDs synthesized on the core tiles for CA9 work
> > > > fine with this though.
> > > 
> > > Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
> > > That's certainly worked for stuff like local RAM on FPGA tiles in the past,
> > > and I can't think offhand of any way in which VExpress is wildly different
> > > (but I am of course open to being wrong...)
> > 
> > There is nothing wrong with that apart from my ignorance
> > of that solution. So thanks! :D
> > 
> > My experience with CMA is limited to using the 7 areas
> > that are defined by default in Kconfig and the DRM helpers
> > just plugging in on the front.
> > 
> > Do you have some pointers? Is this something I can
> > handily just set up in the device tree?
> 
> It should be - the inner workings of dma-{coherent,contiguous} are a maze of
> twisty little passages, all alike, and it'll take me a while to page the
> details back in, but IIRC it's mostly just a case of having a
> reserved-memory node covering the VRAM with the right combination of magic
> properties for rmem_dma_setup() to pick up, such that it gets assigned as
> the CLCD's private region. The subsequent "just plugging in" aspect doesn't
> change, it just makes allocations start taking this route under the covers:
> 
>   drm_gem_cma_create()
>     dma_alloc_wc()
>       dma_alloc_attrs()
>         dma_alloc_from_dev_coherent()
> 
> I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in
> the past, but now I can't seem to find one to refer back to :(

Maybe something line this:
https://github.com/ARM-software/linux/blob/development/malidp/arch/arm64/boot/dts/arm/juno-base.dtsi#L792

And look at line 855 for the possible use of it.

That is how we currently make CMA allocate buffers in FPGA for the Mali
DP "hardware" (bitstream on FPGA) that we have in Juno.

Best regards,
Liviu

> 
> Robin.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/4] drm/pl111: RealView and Versatile Express
@ 2018-03-02 15:43         ` Liviu Dudau
  0 siblings, 0 replies; 22+ messages in thread
From: Liviu Dudau @ 2018-03-02 15:43 UTC (permalink / raw)
  To: Robin Murphy; +Cc: open list:DRM PANEL DRIVERS, Daniel Vetter, Linux ARM

On Fri, Mar 02, 2018 at 01:50:20PM +0000, Robin Murphy wrote:
> On 02/03/18 12:37, Linus Walleij wrote:
> > On Fri, Mar 2, 2018 at 1:11 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> > > On 02/03/18 09:09, Linus Walleij wrote:
> > 
> > > > Also the Versatile Express CLCD on the motherboard has
> > > > a dedicated video memory, and cannot use CMA (ha! complex!)
> > > > and I will need to figure out a way to work around that.
> > > > The CLCDs synthesized on the core tiles for CA9 work
> > > > fine with this though.
> > > 
> > > Out of curiosity, what's the issue with declaring the VRAM as a CMA region?
> > > That's certainly worked for stuff like local RAM on FPGA tiles in the past,
> > > and I can't think offhand of any way in which VExpress is wildly different
> > > (but I am of course open to being wrong...)
> > 
> > There is nothing wrong with that apart from my ignorance
> > of that solution. So thanks! :D
> > 
> > My experience with CMA is limited to using the 7 areas
> > that are defined by default in Kconfig and the DRM helpers
> > just plugging in on the front.
> > 
> > Do you have some pointers? Is this something I can
> > handily just set up in the device tree?
> 
> It should be - the inner workings of dma-{coherent,contiguous} are a maze of
> twisty little passages, all alike, and it'll take me a while to page the
> details back in, but IIRC it's mostly just a case of having a
> reserved-memory node covering the VRAM with the right combination of magic
> properties for rmem_dma_setup() to pick up, such that it gets assigned as
> the CLCD's private region. The subsequent "just plugging in" aspect doesn't
> change, it just makes allocations start taking this route under the covers:
> 
>   drm_gem_cma_create()
>     dma_alloc_wc()
>       dma_alloc_attrs()
>         dma_alloc_from_dev_coherent()
> 
> I could have sworn I've exchanged relevant FPGA DT fragments with Liviu in
> the past, but now I can't seem to find one to refer back to :(

Maybe something line this:
https://github.com/ARM-software/linux/blob/development/malidp/arch/arm64/boot/dts/arm/juno-base.dtsi#L792

And look at line 855 for the possible use of it.

That is how we currently make CMA allocate buffers in FPGA for the Mali
DP "hardware" (bitstream on FPGA) that we have in Juno.

Best regards,
Liviu

> 
> Robin.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution
  2018-03-02  9:09   ` Linus Walleij
@ 2018-03-06  0:29     ` Eric Anholt
  -1 siblings, 0 replies; 22+ messages in thread
From: Eric Anholt @ 2018-03-06  0:29 UTC (permalink / raw)
  To: linux-arm-kernel

Linus Walleij <linus.walleij@linaro.org> writes:

> We were previously selecting 1024x768 and 32BPP as the default
> set-up for the PL111 consumers.
>
> This does not work on elder systems: the device tree bindings
> support a property "max-memory-bandwidth" in bytes/second that
> states that if you exceed this the memory bus will saturate.
> The result is flickering and unstable images.
>
> Parse the "max-memory-bandwidth" and respect it when
> intializing the driver. On the RealView PB11MP, Versatile and
> Integrator/CP we get a nice console as default with this code.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Account for the case where there is no bandwidth limitation
>   so priv->memory_bw is zero. Then just accept any modes.
> ChangeLog v1->v2:
> - Exploit the new .mode_valid() callback we added to the
>   simple KMS helper.
> - Use the hardcoded bits per pixel per variant instead of
>   trying to be heuristic about this setting for now.
> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 36 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm.h     |  1 +
>  drivers/gpu/drm/pl111/pl111_drv.c     |  6 ++++++
>  3 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index d75923896609..577e61950e16 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
>  	return status;
>  }
>  
> +static enum drm_mode_status
> +pl111_mode_valid(struct drm_crtc *crtc,
> +		 const struct drm_display_mode *mode)
> +{
> +	struct drm_device *drm = crtc->dev;
> +	struct pl111_drm_dev_private *priv = drm->dev_private;
> +	u32 cpp = priv->variant->fb_bpp / 8;
> +	u64 bw;
> +
> +	/*
> +	 * We use the pixelclock to also account for interlaced modes, the
> +	 * resulting bandwidth is in bytes per second.
> +	 */
> +	bw = mode->clock * 1000; /* In Hz */
> +	bw = bw * mode->hdisplay * mode->vdisplay * cpp;
> +	bw = div_u64(bw, mode->htotal * mode->vtotal);
> +
> +	/*
> +	 * If no bandwidth constraints, anything goes, else
> +	 * check if we are too fast.
> +	 */
> +	if (priv->memory_bw && (bw > priv->memory_bw)) {
> +		DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
> +			 mode->hdisplay, mode->vdisplay,
> +			 mode->clock * 1000, cpp, bw);
> +
> +		return MODE_BAD;
> +	}
> +	DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
> +		 mode->hdisplay, mode->vdisplay,
> +		 mode->clock * 1000, cpp, bw);

I think the DRM_INFO should be DRM_DEBUG_KMS.  With that,

Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180305/4992f0a0/attachment.sig>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution
@ 2018-03-06  0:29     ` Eric Anholt
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Anholt @ 2018-03-06  0:29 UTC (permalink / raw)
  To: Linus Walleij, Daniel Vetter, Jani Nikula, Sean Paul, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 2753 bytes --]

Linus Walleij <linus.walleij@linaro.org> writes:

> We were previously selecting 1024x768 and 32BPP as the default
> set-up for the PL111 consumers.
>
> This does not work on elder systems: the device tree bindings
> support a property "max-memory-bandwidth" in bytes/second that
> states that if you exceed this the memory bus will saturate.
> The result is flickering and unstable images.
>
> Parse the "max-memory-bandwidth" and respect it when
> intializing the driver. On the RealView PB11MP, Versatile and
> Integrator/CP we get a nice console as default with this code.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Account for the case where there is no bandwidth limitation
>   so priv->memory_bw is zero. Then just accept any modes.
> ChangeLog v1->v2:
> - Exploit the new .mode_valid() callback we added to the
>   simple KMS helper.
> - Use the hardcoded bits per pixel per variant instead of
>   trying to be heuristic about this setting for now.
> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 36 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm.h     |  1 +
>  drivers/gpu/drm/pl111/pl111_drv.c     |  6 ++++++
>  3 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index d75923896609..577e61950e16 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
>  	return status;
>  }
>  
> +static enum drm_mode_status
> +pl111_mode_valid(struct drm_crtc *crtc,
> +		 const struct drm_display_mode *mode)
> +{
> +	struct drm_device *drm = crtc->dev;
> +	struct pl111_drm_dev_private *priv = drm->dev_private;
> +	u32 cpp = priv->variant->fb_bpp / 8;
> +	u64 bw;
> +
> +	/*
> +	 * We use the pixelclock to also account for interlaced modes, the
> +	 * resulting bandwidth is in bytes per second.
> +	 */
> +	bw = mode->clock * 1000; /* In Hz */
> +	bw = bw * mode->hdisplay * mode->vdisplay * cpp;
> +	bw = div_u64(bw, mode->htotal * mode->vtotal);
> +
> +	/*
> +	 * If no bandwidth constraints, anything goes, else
> +	 * check if we are too fast.
> +	 */
> +	if (priv->memory_bw && (bw > priv->memory_bw)) {
> +		DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
> +			 mode->hdisplay, mode->vdisplay,
> +			 mode->clock * 1000, cpp, bw);
> +
> +		return MODE_BAD;
> +	}
> +	DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
> +		 mode->hdisplay, mode->vdisplay,
> +		 mode->clock * 1000, cpp, bw);

I think the DRM_INFO should be DRM_DEBUG_KMS.  With that,

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 3/4] drm/pl111: Handle the RealView variant separately
  2018-03-02  9:09   ` Linus Walleij
@ 2018-03-06  0:34     ` Eric Anholt
  -1 siblings, 0 replies; 22+ messages in thread
From: Eric Anholt @ 2018-03-06  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

Linus Walleij <linus.walleij@linaro.org> writes:

> We want to cut down the default bpp to 16 on the RealView so
> we can have a 1024x768 framebuffer console by default. The
> memory bandwidth limitations makes this not work with the
> PL111 default of 32bpp.
>
> This builds on top of the earlier patches making the
> framebuffer default bpp a per-variant variable.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180305/0f62d6df/attachment.sig>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 3/4] drm/pl111: Handle the RealView variant separately
@ 2018-03-06  0:34     ` Eric Anholt
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Anholt @ 2018-03-06  0:34 UTC (permalink / raw)
  To: Linus Walleij, Daniel Vetter, Jani Nikula, Sean Paul, Liviu Dudau
  Cc: linux-arm-kernel, dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 471 bytes --]

Linus Walleij <linus.walleij@linaro.org> writes:

> We want to cut down the default bpp to 16 on the RealView so
> we can have a 1024x768 framebuffer console by default. The
> memory bandwidth limitations makes this not work with the
> PL111 default of 32bpp.
>
> This builds on top of the earlier patches making the
> framebuffer default bpp a per-variant variable.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2018-03-06  0:34 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-02  9:09 [PATCH 0/4] drm/pl111: RealView and Versatile Express Linus Walleij
2018-03-02  9:09 ` Linus Walleij
2018-03-02  9:09 ` [PATCH 1/4] drm/pl111: Make the default BPP a per-variant variable Linus Walleij
2018-03-02  9:09   ` Linus Walleij
2018-03-02  9:09 ` [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution Linus Walleij
2018-03-02  9:09   ` Linus Walleij
2018-03-06  0:29   ` Eric Anholt
2018-03-06  0:29     ` Eric Anholt
2018-03-02  9:09 ` [PATCH 3/4] drm/pl111: Handle the RealView variant separately Linus Walleij
2018-03-02  9:09   ` Linus Walleij
2018-03-06  0:34   ` Eric Anholt
2018-03-06  0:34     ` Eric Anholt
2018-03-02  9:09 ` [PATCH 4/4] drm/pl111: Support the Versatile Express Linus Walleij
2018-03-02  9:09   ` Linus Walleij
2018-03-02 12:11 ` [PATCH 0/4] drm/pl111: RealView and " Robin Murphy
2018-03-02 12:11   ` Robin Murphy
2018-03-02 12:37   ` Linus Walleij
2018-03-02 12:37     ` Linus Walleij
2018-03-02 13:50     ` Robin Murphy
2018-03-02 13:50       ` Robin Murphy
2018-03-02 15:43       ` Liviu Dudau
2018-03-02 15:43         ` Liviu Dudau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.