All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] drm/arcpgu: Get use of dedicated memory area for frame buffer
@ 2016-04-27 14:34 ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:34 UTC (permalink / raw)
  To: dri-devel
  Cc: linux-kernel, linux-snps-arc, Alexey Brodkin, Cc: Dave Airlie,
	Daniel Vetter, devicetree

This mini-series allows to allocate frame buffer memory in desired
location. Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture which is typically set
as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Cc: Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: devicetree@vger.kernel.org

Alexey Brodkin (2):
  drm/arcpgu: use dedicated memory area for frame buffer
  ARC: [axs10x] Specify reserved memory for frame buffer

 arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
 arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++++++
 5 files changed, 54 insertions(+), 2 deletions(-)

-- 
2.5.5

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

* [PATCH 0/2] drm/arcpgu: Get use of dedicated memory area for frame buffer
@ 2016-04-27 14:34 ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:34 UTC (permalink / raw)
  To: linux-snps-arc

This mini-series allows to allocate frame buffer memory in desired
location. Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture which is typically set
as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Cc: Cc: Dave Airlie <airlied at gmail.com>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: devicetree at vger.kernel.org

Alexey Brodkin (2):
  drm/arcpgu: use dedicated memory area for frame buffer
  ARC: [axs10x] Specify reserved memory for frame buffer

 arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
 arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++++++
 5 files changed, 54 insertions(+), 2 deletions(-)

-- 
2.5.5

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

* [PATCH 1/2] drm/arcpgu: use dedicated memory area for frame buffer
  2016-04-27 14:34 ` Alexey Brodkin
  (?)
@ 2016-04-27 14:35   ` Alexey Brodkin
  -1 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: dri-devel
  Cc: linux-kernel, linux-snps-arc, Alexey Brodkin, Dave Airlie, Daniel Vetter

Now when ARC supports reserved memory areas and
per-device coherent DMA allocations we may switch ARC PGU
to use of those dedicated areas.

One of the benefits we may move frame-buffer area out
from IO Coherency aperture and so significantly
reduce IOC utilization allowing less demanding
peripherals to use all perks of IOC.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5b35e5db..76e187a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <linux/of_reserved_mem.h>
 
 #include "arcpgu.h"
 #include "arcpgu_regs.h"
@@ -135,6 +136,11 @@ static int arcpgu_load(struct drm_device *drm)
 	dev_info(drm->dev, "arc_pgu ID: 0x%x\n",
 		 arc_pgu_read(arcpgu, ARCPGU_REG_ID));
 
+	/* Get the optional framebuffer memory resource */
+	ret = of_reserved_mem_device_init(drm->dev);
+	if (ret && ret != -ENODEV)
+		return ret;
+
 	if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
 		return -ENODEV;
 
-- 
2.5.5

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

* [PATCH 1/2] drm/arcpgu: use dedicated memory area for frame buffer
@ 2016-04-27 14:35   ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: linux-snps-arc

Now when ARC supports reserved memory areas and
per-device coherent DMA allocations we may switch ARC PGU
to use of those dedicated areas.

One of the benefits we may move frame-buffer area out
from IO Coherency aperture and so significantly
reduce IOC utilization allowing less demanding
peripherals to use all perks of IOC.

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
Cc: Dave Airlie <airlied at gmail.com>
Cc: Daniel Vetter <daniel at ffwll.ch>
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5b35e5db..76e187a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <linux/of_reserved_mem.h>
 
 #include "arcpgu.h"
 #include "arcpgu_regs.h"
@@ -135,6 +136,11 @@ static int arcpgu_load(struct drm_device *drm)
 	dev_info(drm->dev, "arc_pgu ID: 0x%x\n",
 		 arc_pgu_read(arcpgu, ARCPGU_REG_ID));
 
+	/* Get the optional framebuffer memory resource */
+	ret = of_reserved_mem_device_init(drm->dev);
+	if (ret && ret != -ENODEV)
+		return ret;
+
 	if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
 		return -ENODEV;
 
-- 
2.5.5

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

* [PATCH 1/2] drm/arcpgu: use dedicated memory area for frame buffer
@ 2016-04-27 14:35   ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: dri-devel
  Cc: Dave Airlie, linux-snps-arc, Alexey Brodkin, linux-kernel, Daniel Vetter

Now when ARC supports reserved memory areas and
per-device coherent DMA allocations we may switch ARC PGU
to use of those dedicated areas.

One of the benefits we may move frame-buffer area out
from IO Coherency aperture and so significantly
reduce IOC utilization allowing less demanding
peripherals to use all perks of IOC.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5b35e5db..76e187a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <linux/of_reserved_mem.h>
 
 #include "arcpgu.h"
 #include "arcpgu_regs.h"
@@ -135,6 +136,11 @@ static int arcpgu_load(struct drm_device *drm)
 	dev_info(drm->dev, "arc_pgu ID: 0x%x\n",
 		 arc_pgu_read(arcpgu, ARCPGU_REG_ID));
 
+	/* Get the optional framebuffer memory resource */
+	ret = of_reserved_mem_device_init(drm->dev);
+	if (ret && ret != -ENODEV)
+		return ret;
+
 	if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
 		return -ENODEV;
 
-- 
2.5.5

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
  2016-04-27 14:34 ` Alexey Brodkin
  (?)
@ 2016-04-27 14:35   ` Alexey Brodkin
  -1 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-kernel, linux-snps-arc, Alexey Brodkin, devicetree

Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture
which is typically set as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Even though for AXS101 (which sorts ARC770 CPU) IOC is not
an option for a sake of keeping one DT description for the
base-board (axs10x_mb.dtsi) we're still defining reserved
memory location in the very end of DDR.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: devicetree@vger.kernel.org
---
 arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
 arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 420dcfd..ae6162d 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -95,6 +95,24 @@
 		#size-cells = <1>;
 		ranges = <0x00000000 0x80000000 0x40000000>;
 		device_type = "memory";
-		reg = <0x80000000 0x20000000>;	/* 512MiB */
+		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * We just move frame buffer area to the very end of
+		 * available DDR. And even though in case of ARC770 there's
+		 * no strict requirement for a frame-buffer to be in any
+		 * particular location it allows us to use the same
+		 * base board's DT node for ARC PGU as for ARc HS38.
+		 */
+		frame_buffer: frame_buffer@9f000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x9f000000 0x1000000>;
+			no-map;
+		};
 	};
 };
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index f90fadf..c7a95c2 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -100,4 +100,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
index 06a9f29..929ec8c 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -123,4 +123,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 823f15c..64b063d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -283,7 +283,7 @@
 			encoder-slave = <&adv7511>;
 			clocks = <&pguclk>;
 			clock-names = "pxlclk";
-
+			memory-region = <&frame_buffer>;
 			port {
 				pgu_output: endpoint {
 					remote-endpoint = <&adv7511_input>;
-- 
2.5.5

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-27 14:35   ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: dri-devel; +Cc: devicetree, linux-snps-arc, Alexey Brodkin, linux-kernel

Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture
which is typically set as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Even though for AXS101 (which sorts ARC770 CPU) IOC is not
an option for a sake of keeping one DT description for the
base-board (axs10x_mb.dtsi) we're still defining reserved
memory location in the very end of DDR.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: devicetree@vger.kernel.org
---
 arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
 arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 420dcfd..ae6162d 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -95,6 +95,24 @@
 		#size-cells = <1>;
 		ranges = <0x00000000 0x80000000 0x40000000>;
 		device_type = "memory";
-		reg = <0x80000000 0x20000000>;	/* 512MiB */
+		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * We just move frame buffer area to the very end of
+		 * available DDR. And even though in case of ARC770 there's
+		 * no strict requirement for a frame-buffer to be in any
+		 * particular location it allows us to use the same
+		 * base board's DT node for ARC PGU as for ARc HS38.
+		 */
+		frame_buffer: frame_buffer@9f000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x9f000000 0x1000000>;
+			no-map;
+		};
 	};
 };
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index f90fadf..c7a95c2 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -100,4 +100,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
index 06a9f29..929ec8c 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -123,4 +123,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer@a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 823f15c..64b063d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -283,7 +283,7 @@
 			encoder-slave = <&adv7511>;
 			clocks = <&pguclk>;
 			clock-names = "pxlclk";
-
+			memory-region = <&frame_buffer>;
 			port {
 				pgu_output: endpoint {
 					remote-endpoint = <&adv7511_input>;
-- 
2.5.5

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-27 14:35   ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-27 14:35 UTC (permalink / raw)
  To: linux-snps-arc

Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture
which is typically set as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Even though for AXS101 (which sorts ARC770 CPU) IOC is not
an option for a sake of keeping one DT description for the
base-board (axs10x_mb.dtsi) we're still defining reserved
memory location in the very end of DDR.

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
Cc: devicetree at vger.kernel.org
---
 arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
 arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 420dcfd..ae6162d 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -95,6 +95,24 @@
 		#size-cells = <1>;
 		ranges = <0x00000000 0x80000000 0x40000000>;
 		device_type = "memory";
-		reg = <0x80000000 0x20000000>;	/* 512MiB */
+		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * We just move frame buffer area to the very end of
+		 * available DDR. And even though in case of ARC770 there's
+		 * no strict requirement for a frame-buffer to be in any
+		 * particular location it allows us to use the same
+		 * base board's DT node for ARC PGU as for ARc HS38.
+		 */
+		frame_buffer: frame_buffer at 9f000000 {
+			compatible = "shared-dma-pool";
+			reg = <0x9f000000 0x1000000>;
+			no-map;
+		};
 	};
 };
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index f90fadf..c7a95c2 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -100,4 +100,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer at a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
index 06a9f29..929ec8c 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -123,4 +123,18 @@
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>;	/* 512MiB */
 	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		/*
+		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
+		 */
+		frame_buffer: frame_buffer at a0000000 {
+			compatible = "shared-dma-pool";
+			reg = <0xa0000000 0x1000000>;
+			no-map;
+		};
+	};
 };
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 823f15c..64b063d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -283,7 +283,7 @@
 			encoder-slave = <&adv7511>;
 			clocks = <&pguclk>;
 			clock-names = "pxlclk";
-
+			memory-region = <&frame_buffer>;
 			port {
 				pgu_output: endpoint {
 					remote-endpoint = <&adv7511_input>;
-- 
2.5.5

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28  4:26     ` Vineet Gupta
  0 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28  4:26 UTC (permalink / raw)
  To: Alexey Brodkin, dri-devel; +Cc: devicetree, linux-snps-arc, linux-kernel

On Wednesday 27 April 2016 08:05 PM, Alexey Brodkin wrote:
> Allocation of a frame buffer memory in a special memory region
> allows bypassing of so-called IO Coherency aperture
> which is typically set as a range 0x8z-0xAz.
> 
> I.e. all data traffic to PGU bypasses IO Coherency block
> and saves its bandwidth for other peripherals.
> 
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: devicetree@vger.kernel.org
> ---
>  arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
>  arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
>  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
>  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
>  4 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> index 420dcfd..ae6162d 100644
> --- a/arch/arc/boot/dts/axc001.dtsi
> +++ b/arch/arc/boot/dts/axc001.dtsi
> @@ -95,6 +95,24 @@
>  		#size-cells = <1>;
>  		ranges = <0x00000000 0x80000000 0x40000000>;
>  		device_type = "memory";
> -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */

Is 16MB fixed size or is this a function of display resolution / density etc.

> +	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * We just move frame buffer area to the very end of
> +		 * available DDR. And even though in case of ARC770 there's
> +		 * no strict requirement for a frame-buffer to be in any
> +		 * particular location it allows us to use the same
> +		 * base board's DT node for ARC PGU as for ARc HS38.
> +		 */
> +		frame_buffer: frame_buffer@9f000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x9f000000 0x1000000>;
> +			no-map;
> +		};
>  	};
>  };
> diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
> index f90fadf..c7a95c2 100644
> --- a/arch/arc/boot/dts/axc003.dtsi
> +++ b/arch/arc/boot/dts/axc003.dtsi
> @@ -100,4 +100,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer@a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;

Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
currently only uses 512M. Once we increase that, this will need fixing too. Better
to make this as far possible. Note that the IOC start alignment needs to follow
max(4k, size). What will be maximum size of frame buffer - 16M always !

Same for the idu DT below !

> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
> index 06a9f29..929ec8c 100644
> --- a/arch/arc/boot/dts/axc003_idu.dtsi
> +++ b/arch/arc/boot/dts/axc003_idu.dtsi
> @@ -123,4 +123,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer@a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;
> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 823f15c..64b063d 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -283,7 +283,7 @@
>  			encoder-slave = <&adv7511>;
>  			clocks = <&pguclk>;
>  			clock-names = "pxlclk";
> -
> +			memory-region = <&frame_buffer>;
>  			port {
>  				pgu_output: endpoint {
>  					remote-endpoint = <&adv7511_input>;
> 

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28  4:26     ` Vineet Gupta
  0 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28  4:26 UTC (permalink / raw)
  To: Alexey Brodkin, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Wednesday 27 April 2016 08:05 PM, Alexey Brodkin wrote:
> Allocation of a frame buffer memory in a special memory region
> allows bypassing of so-called IO Coherency aperture
> which is typically set as a range 0x8z-0xAz.
> 
> I.e. all data traffic to PGU bypasses IO Coherency block
> and saves its bandwidth for other peripherals.
> 
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
> 
> Signed-off-by: Alexey Brodkin <abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
>  arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
>  arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
>  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
>  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
>  4 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> index 420dcfd..ae6162d 100644
> --- a/arch/arc/boot/dts/axc001.dtsi
> +++ b/arch/arc/boot/dts/axc001.dtsi
> @@ -95,6 +95,24 @@
>  		#size-cells = <1>;
>  		ranges = <0x00000000 0x80000000 0x40000000>;
>  		device_type = "memory";
> -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */

Is 16MB fixed size or is this a function of display resolution / density etc.

> +	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * We just move frame buffer area to the very end of
> +		 * available DDR. And even though in case of ARC770 there's
> +		 * no strict requirement for a frame-buffer to be in any
> +		 * particular location it allows us to use the same
> +		 * base board's DT node for ARC PGU as for ARc HS38.
> +		 */
> +		frame_buffer: frame_buffer@9f000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x9f000000 0x1000000>;
> +			no-map;
> +		};
>  	};
>  };
> diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
> index f90fadf..c7a95c2 100644
> --- a/arch/arc/boot/dts/axc003.dtsi
> +++ b/arch/arc/boot/dts/axc003.dtsi
> @@ -100,4 +100,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer@a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;

Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
currently only uses 512M. Once we increase that, this will need fixing too. Better
to make this as far possible. Note that the IOC start alignment needs to follow
max(4k, size). What will be maximum size of frame buffer - 16M always !

Same for the idu DT below !

> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
> index 06a9f29..929ec8c 100644
> --- a/arch/arc/boot/dts/axc003_idu.dtsi
> +++ b/arch/arc/boot/dts/axc003_idu.dtsi
> @@ -123,4 +123,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer@a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;
> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 823f15c..64b063d 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -283,7 +283,7 @@
>  			encoder-slave = <&adv7511>;
>  			clocks = <&pguclk>;
>  			clock-names = "pxlclk";
> -
> +			memory-region = <&frame_buffer>;
>  			port {
>  				pgu_output: endpoint {
>  					remote-endpoint = <&adv7511_input>;
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28  4:26     ` Vineet Gupta
  0 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28  4:26 UTC (permalink / raw)
  To: linux-snps-arc

On Wednesday 27 April 2016 08:05 PM, Alexey Brodkin wrote:
> Allocation of a frame buffer memory in a special memory region
> allows bypassing of so-called IO Coherency aperture
> which is typically set as a range 0x8z-0xAz.
> 
> I.e. all data traffic to PGU bypasses IO Coherency block
> and saves its bandwidth for other peripherals.
> 
> Even though for AXS101 (which sorts ARC770 CPU) IOC is not
> an option for a sake of keeping one DT description for the
> base-board (axs10x_mb.dtsi) we're still defining reserved
> memory location in the very end of DDR.
> 
> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> Cc: devicetree at vger.kernel.org
> ---
>  arch/arc/boot/dts/axc001.dtsi     | 20 +++++++++++++++++++-
>  arch/arc/boot/dts/axc003.dtsi     | 14 ++++++++++++++
>  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++++++++++++++
>  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
>  4 files changed, 48 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> index 420dcfd..ae6162d 100644
> --- a/arch/arc/boot/dts/axc001.dtsi
> +++ b/arch/arc/boot/dts/axc001.dtsi
> @@ -95,6 +95,24 @@
>  		#size-cells = <1>;
>  		ranges = <0x00000000 0x80000000 0x40000000>;
>  		device_type = "memory";
> -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */

Is 16MB fixed size or is this a function of display resolution / density etc.

> +	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * We just move frame buffer area to the very end of
> +		 * available DDR. And even though in case of ARC770 there's
> +		 * no strict requirement for a frame-buffer to be in any
> +		 * particular location it allows us to use the same
> +		 * base board's DT node for ARC PGU as for ARc HS38.
> +		 */
> +		frame_buffer: frame_buffer at 9f000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x9f000000 0x1000000>;
> +			no-map;
> +		};
>  	};
>  };
> diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
> index f90fadf..c7a95c2 100644
> --- a/arch/arc/boot/dts/axc003.dtsi
> +++ b/arch/arc/boot/dts/axc003.dtsi
> @@ -100,4 +100,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer at a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;

Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
currently only uses 512M. Once we increase that, this will need fixing too. Better
to make this as far possible. Note that the IOC start alignment needs to follow
max(4k, size). What will be maximum size of frame buffer - 16M always !

Same for the idu DT below !

> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axc003_idu.dtsi b/arch/arc/boot/dts/axc003_idu.dtsi
> index 06a9f29..929ec8c 100644
> --- a/arch/arc/boot/dts/axc003_idu.dtsi
> +++ b/arch/arc/boot/dts/axc003_idu.dtsi
> @@ -123,4 +123,18 @@
>  		device_type = "memory";
>  		reg = <0x80000000 0x20000000>;	/* 512MiB */
>  	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +		/*
> +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> +		 */
> +		frame_buffer: frame_buffer at a0000000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0xa0000000 0x1000000>;
> +			no-map;
> +		};
> +	};
>  };
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 823f15c..64b063d 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -283,7 +283,7 @@
>  			encoder-slave = <&adv7511>;
>  			clocks = <&pguclk>;
>  			clock-names = "pxlclk";
> -
> +			memory-region = <&frame_buffer>;
>  			port {
>  				pgu_output: endpoint {
>  					remote-endpoint = <&adv7511_input>;
> 

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 13:46       ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 13:46 UTC (permalink / raw)
  To: Vineet Gupta; +Cc: dri-devel, linux-kernel, devicetree, linux-snps-arc

Hi Vineet,

On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:

[snip]

> > 
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> >  		#size-cells = <1>;
> >  		ranges = <0x00000000 0x80000000 0x40000000>;
> >  		device_type = "memory";
> > -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> > +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.

Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).

So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.

But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.

[snip]

> > +
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +		/*
> > +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > +		 */
> > +		frame_buffer: frame_buffer@bf000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.

Makes sense. Will move it to the very end of 1Gb.

> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !

What do you mean by that?

-Alexey

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 13:46       ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 13:46 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Vineet,

On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:

[snip]

> > 
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> >  		#size-cells = <1>;
> >  		ranges = <0x00000000 0x80000000 0x40000000>;
> >  		device_type = "memory";
> > -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> > +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.

Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).

So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.

But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.

[snip]

> > +
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +		/*
> > +		 * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > +		 */
> > +		frame_buffer: frame_buffer@bf000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.

Makes sense. Will move it to the very end of 1Gb.

> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !

What do you mean by that?

-Alexey--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 13:46       ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 13:46 UTC (permalink / raw)
  To: linux-snps-arc

Hi Vineet,

On Thu, 2016-04-28@09:56 +0530, Vineet Gupta wrote:

[snip]

> > 
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> > ?		#size-cells = <1>;
> > ?		ranges = <0x00000000 0x80000000 0x40000000>;
> > ?		device_type = "memory";
> > -		reg = <0x80000000 0x20000000>;	/* 512MiB */
> > +		reg = <0x80000000 0x1f000000>;	/* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.

Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).

So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.

But now I recalled that we also support?r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.

[snip]

> > +
> > +	reserved-memory {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +		/*
> > +		?* Move frame buffer out of IOC aperture (0x8z-0xAz).
> > +		?*/
> > +		frame_buffer: frame_buffer at bf000000 {
> > +			compatible = "shared-dma-pool";
> > +			reg = <0xbf000000 0x1000000>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. Better
> to make this as far possible.

Makes sense. Will move it to the very end of 1Gb.

> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !

What do you mean by that?

-Alexey

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
  2016-04-28 13:46       ` Alexey Brodkin
  (?)
@ 2016-04-28 13:56         ` Vineet Gupta
  -1 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28 13:56 UTC (permalink / raw)
  To: Alexey Brodkin; +Cc: dri-devel, lkml, devicetree, arcml

On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
>> > Note that the IOC start alignment needs to follow
>> > max(4k, size). What will be maximum size of frame buffer - 16M always !
> What do you mean by that?

For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
buffer start needs to be inside the IOC aperture base address. That value can't be
arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

-Vineet

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 13:56         ` Vineet Gupta
  0 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28 13:56 UTC (permalink / raw)
  To: Alexey Brodkin; +Cc: dri-devel, lkml, devicetree, arcml

On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
>> > Note that the IOC start alignment needs to follow
>> > max(4k, size). What will be maximum size of frame buffer - 16M always !
> What do you mean by that?

For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
buffer start needs to be inside the IOC aperture base address. That value can't be
arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

-Vineet

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 13:56         ` Vineet Gupta
  0 siblings, 0 replies; 20+ messages in thread
From: Vineet Gupta @ 2016-04-28 13:56 UTC (permalink / raw)
  To: linux-snps-arc

On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
>> > Note that the IOC start alignment needs to follow
>> > max(4k, size). What will be maximum size of frame buffer - 16M always !
> What do you mean by that?

For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
buffer start needs to be inside the IOC aperture base address. That value can't be
arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

-Vineet

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 14:38           ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 14:38 UTC (permalink / raw)
  To: Vineet Gupta; +Cc: dri-devel, linux-kernel, devicetree, linux-snps-arc

Hi Vineet,

On Thu, 2016-04-28 at 19:26 +0530, Vineet Gupta wrote:
> On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > Note that the IOC start alignment needs to follow
> > > > max(4k, size). What will be maximum size of frame buffer - 16M always !
> > What do you mean by that?
> For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
> buffer start needs to be inside the IOC aperture base address. That value can't be
> arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
> the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

The point is we want to put frame buffer memory OUTSIDE IOC aperture.
So we allocate FB memory in the very end of DDR which is far away from IOC.

And in that case IOC alignment issues are out of the question here.

-Alexey

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

* Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 14:38           ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 14:38 UTC (permalink / raw)
  To: Vineet Gupta
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Vineet,

On Thu, 2016-04-28 at 19:26 +0530, Vineet Gupta wrote:
> On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > Note that the IOC start alignment needs to follow
> > > > max(4k, size). What will be maximum size of frame buffer - 16M always !
> > What do you mean by that?
> For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
> buffer start needs to be inside the IOC aperture base address. That value can't be
> arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
> the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

The point is we want to put frame buffer memory OUTSIDE IOC aperture.
So we allocate FB memory in the very end of DDR which is far away from IOC.

And in that case IOC alignment issues are out of the question here.

-Alexey--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

* [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer
@ 2016-04-28 14:38           ` Alexey Brodkin
  0 siblings, 0 replies; 20+ messages in thread
From: Alexey Brodkin @ 2016-04-28 14:38 UTC (permalink / raw)
  To: linux-snps-arc

Hi Vineet,

On Thu, 2016-04-28@19:26 +0530, Vineet Gupta wrote:
> On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > Note that the IOC start alignment needs to follow
> > > > max(4k, size). What will be maximum size of frame buffer - 16M always !
> > What do you mean by that?
> For HS38, we intend to bypass the frame buffer traffic from IOC port. So the frame
> buffer start needs to be inside the IOC aperture base address. That value can't be
> arbitrary - it is atleast 4K aligned value and further also needs to be aligned to
> the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

The point is we want to put frame buffer memory OUTSIDE IOC aperture.
So we allocate FB memory in the very end of DDR which is far away from IOC.

And in that case IOC alignment issues are out of the question here.

-Alexey

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

end of thread, other threads:[~2016-04-28 14:38 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-27 14:34 [PATCH 0/2] drm/arcpgu: Get use of dedicated memory area for frame buffer Alexey Brodkin
2016-04-27 14:34 ` Alexey Brodkin
2016-04-27 14:35 ` [PATCH 1/2] drm/arcpgu: use " Alexey Brodkin
2016-04-27 14:35   ` Alexey Brodkin
2016-04-27 14:35   ` Alexey Brodkin
2016-04-27 14:35 ` [PATCH 2/2] ARC: [axs10x] Specify reserved memory " Alexey Brodkin
2016-04-27 14:35   ` Alexey Brodkin
2016-04-27 14:35   ` Alexey Brodkin
2016-04-28  4:26   ` Vineet Gupta
2016-04-28  4:26     ` Vineet Gupta
2016-04-28  4:26     ` Vineet Gupta
2016-04-28 13:46     ` Alexey Brodkin
2016-04-28 13:46       ` Alexey Brodkin
2016-04-28 13:46       ` Alexey Brodkin
2016-04-28 13:56       ` Vineet Gupta
2016-04-28 13:56         ` Vineet Gupta
2016-04-28 13:56         ` Vineet Gupta
2016-04-28 14:38         ` Alexey Brodkin
2016-04-28 14:38           ` Alexey Brodkin
2016-04-28 14:38           ` Alexey Brodkin

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.