[PATCH 0/8] ARM: sun8i: a33: Mali improvements

[PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Maxime Ripard]

Hi,

This serie is building on the recently merged bindings for the ARM Mali
Utgard GPU.

The two features that are supported with this serie are DVFS and the fbdev
support. The first one uses devfreq and is pretty standard, the only
addition being the generic OPP mechanism we have, plus some DT and Kconfig
patches.

Running on framebuffer is a bit more tedious, since we need to access the
CMA memory region size and base. This is quite trivial to do as well
through the memory-region bindings, but require to export a few symbols
along the way to make sure our module builds properly.

Let me know what you think,
Maxime

Maxime Ripard (8):
  ARM: sun8i: Fix the mali clock rate
  dt-bindings: gpu: mali: Add optional memory-region
  mm: cma: Export a few symbols
  drm/sun4i: Grab reserved memory region
  ARM: sun8i: a33: Add shared display memory pool
  dt-bindings: gpu: mali: Add optional OPPs
  ARM: sunxi: Select PM_OPP
  ARM: sun8i: a33: Add the Mali OPPs

 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt |  8 ++-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi                      |  2 +-
 arch/arm/boot/dts/sun8i-a33.dtsi                          | 34 ++++++++-
 arch/arm/mach-sunxi/Kconfig                               |  1 +-
 drivers/base/dma-contiguous.c                             |  1 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c                         | 19 ++--
 mm/cma.c                                                  |  2 +-
 7 files changed, 61 insertions(+), 6 deletions(-)

base-commit: a2138ce584d59571dd18a6cf3417cb90be7625d8
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 1/8] ARM: sun8i: Fix the mali clock rate

[Maxime Ripard]

The Mali clock rate was improperly assumed to be 408MHz, while it was
really 384Mhz, 408MHz being the "extreme" frequency, and definitely not
stable.

Switch for the stable, correct frequency for the GPU.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 35008b78d899..8a880ecc4dda 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -495,7 +495,7 @@
 			resets = <&ccu RST_BUS_GPU>;
 
 			assigned-clocks = <&ccu CLK_GPU>;
-			assigned-clock-rates = <408000000>;
+			assigned-clock-rates = <384000000>;
 		};
 
 		gic: interrupt-controller@01c81000 {
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 1/8] ARM: sun8i: Fix the mali clock rate

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Thu, Feb 09, 2017 at 05:39:15PM +0100, Maxime Ripard wrote:
> The Mali clock rate was improperly assumed to be 408MHz, while it was
> really 384Mhz, 408MHz being the "extreme" frequency, and definitely not
> stable.
> 
> Switch for the stable, correct frequency for the GPU.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[PATCH 2/8] dt-bindings: gpu: mali: Add optional memory-region

[Maxime Ripard]

The reserved memory bindings allow us to specify which memory areas our
buffers can be allocated from.

Let's use it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index 476f5ea6c627..88df4a276607 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -35,6 +35,10 @@ Optional properties:
   - interrupt-names and interrupts:
     * pmu: Power Management Unit interrupt, if implemented in hardware
 
+  - memory-region:
+    Memory region to allocate from, as defined in
+    Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
+
 Vendor-specific bindings
 ------------------------
 
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/8] dt-bindings: gpu: mali: Add optional memory-region

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:16PM +0100, Maxime Ripard wrote:
> The reserved memory bindings allow us to specify which memory areas our
> buffers can be allocated from.
> 
> Let's use it.

You didn't think of this when you just added Mali binding? 

> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
>  1 file changed, 4 insertions(+), 0 deletions(-)

Acked-by: Rob Herring <robh@kernel.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 2/8] dt-bindings: gpu: mali: Add optional memory-region

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Thu, Feb 09, 2017 at 05:39:16PM +0100, Maxime Ripard wrote:
> The reserved memory bindings allow us to specify which memory areas our
> buffers can be allocated from.
> 
> Let's use it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Applied with Rob Acked-by.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[PATCH 3/8] mm: cma: Export a few symbols

[Maxime Ripard]

Modules might want to check their CMA pool size and address for debugging
and / or have additional checks.

The obvious way to do this would be through dev_get_cma_area and
cma_get_base and cma_get_size, that are currently not exported, which
results in a build failure.

Export them to prevent such a failure.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/base/dma-contiguous.c | 1 +
 mm/cma.c                      | 2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1bccb..60f5c2591ccd 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -35,6 +35,7 @@
 #endif
 
 struct cma *dma_contiguous_default_area;
+EXPORT_SYMBOL(dma_contiguous_default_area);
 
 /*
  * Default global CMA area size can be defined in kernel's .config.
diff --git a/mm/cma.c b/mm/cma.c
index c960459eda7e..b50245282a18 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -47,11 +47,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
 {
 	return PFN_PHYS(cma->base_pfn);
 }
+EXPORT_SYMBOL(cma_get_base);
 
 unsigned long cma_get_size(const struct cma *cma)
 {
 	return cma->count << PAGE_SHIFT;
 }
+EXPORT_SYMBOL(cma_get_size);
 
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
 					     int align_order)
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Michal Hocko]

[CC CMA people]

On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> Modules might want to check their CMA pool size and address for debugging
> and / or have additional checks.
> 
> The obvious way to do this would be through dev_get_cma_area and
> cma_get_base and cma_get_size, that are currently not exported, which
> results in a build failure.
> 
> Export them to prevent such a failure.

Who actually uses those exports. None of the follow up patches does
AFAICS.

> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/base/dma-contiguous.c | 1 +
>  mm/cma.c                      | 2 ++
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index e167a1e1bccb..60f5c2591ccd 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -35,6 +35,7 @@
>  #endif
>  
>  struct cma *dma_contiguous_default_area;
> +EXPORT_SYMBOL(dma_contiguous_default_area);
>  
>  /*
>   * Default global CMA area size can be defined in kernel's .config.
> diff --git a/mm/cma.c b/mm/cma.c
> index c960459eda7e..b50245282a18 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -47,11 +47,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
>  {
>  	return PFN_PHYS(cma->base_pfn);
>  }
> +EXPORT_SYMBOL(cma_get_base);
>  
>  unsigned long cma_get_size(const struct cma *cma)
>  {
>  	return cma->count << PAGE_SHIFT;
>  }
> +EXPORT_SYMBOL(cma_get_size);
>  
>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>  					     int align_order)
> -- 
> git-series 0.8.11
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Hi Michal,

On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> [CC CMA people]
> 
> On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > Modules might want to check their CMA pool size and address for debugging
> > and / or have additional checks.
> > 
> > The obvious way to do this would be through dev_get_cma_area and
> > cma_get_base and cma_get_size, that are currently not exported, which
> > results in a build failure.
> > 
> > Export them to prevent such a failure.
> 
> Who actually uses those exports. None of the follow up patches does
> AFAICS.

This is for the ARM Mali GPU driver that is out of tree, unfortunately.

In one case (using the legacy fbdev API), the driver wants to (and
probably should) validate that the buffer as indeed been allocated
from the memory allocation pool.

Rob suggested that instead of hardcoding it to cover the whole RAM
(which defeats the purpose of that check in the first place), we used
the memory-region bindings in the DT and follow that, which does work
great, but we still have to retrieve the base address and size of that
region, hence why this patches are needed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Michal Hocko]

On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> Hi Michal,
> 
> On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > [CC CMA people]
> > 
> > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > Modules might want to check their CMA pool size and address for debugging
> > > and / or have additional checks.
> > > 
> > > The obvious way to do this would be through dev_get_cma_area and
> > > cma_get_base and cma_get_size, that are currently not exported, which
> > > results in a build failure.
> > > 
> > > Export them to prevent such a failure.
> > 
> > Who actually uses those exports. None of the follow up patches does
> > AFAICS.
> 
> This is for the ARM Mali GPU driver that is out of tree, unfortunately.

We do not export symbols which do not have any in-tree users.

> In one case (using the legacy fbdev API), the driver wants to (and
> probably should) validate that the buffer as indeed been allocated
> from the memory allocation pool.
> 
> Rob suggested that instead of hardcoding it to cover the whole RAM
> (which defeats the purpose of that check in the first place), we used
> the memory-region bindings in the DT and follow that, which does work
> great, but we still have to retrieve the base address and size of that
> region, hence why this patches are needed.

Anyway I would suggest talking to CMA people to find a better API for
modules to use...

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Maxime Ripard]

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

On Mon, Feb 20, 2017 at 01:35:50PM +0100, Michal Hocko wrote:
> On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> > Hi Michal,
> > 
> > On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > > [CC CMA people]
> > > 
> > > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > > Modules might want to check their CMA pool size and address for debugging
> > > > and / or have additional checks.
> > > > 
> > > > The obvious way to do this would be through dev_get_cma_area and
> > > > cma_get_base and cma_get_size, that are currently not exported, which
> > > > results in a build failure.
> > > > 
> > > > Export them to prevent such a failure.
> > > 
> > > Who actually uses those exports. None of the follow up patches does
> > > AFAICS.
> > 
> > This is for the ARM Mali GPU driver that is out of tree, unfortunately.
> 
> We do not export symbols which do not have any in-tree users.

Ok, sorry for the noise.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 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

[PATCH 4/8] drm/sun4i: Grab reserved memory region

[Maxime Ripard]

Allow to provide an optional memory region to allocate from for our DRM
driver.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 4ce665349f6b..7ed7a159c9c1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -12,6 +12,7 @@
 
 #include <linux/component.h>
 #include <linux/of_graph.h>
+#include <linux/of_reserved_mem.h>
 
 #include <drm/drmP.h>
 #include <drm/drm_crtc_helper.h>
@@ -133,10 +134,16 @@ static int sun4i_drv_bind(struct device *dev)
 	drm_vblank_init(drm, 1);
 	drm_mode_config_init(drm);
 
+	ret = of_reserved_mem_device_init(dev);
+	if (ret && ret != -ENODEV) {
+		dev_err(drm->dev, "Couldn't claim our memory region\n");
+		goto free_drm;
+	}
+
 	ret = component_bind_all(drm->dev, drm);
 	if (ret) {
 		dev_err(drm->dev, "Couldn't bind all pipelines components\n");
-		goto free_drm;
+		goto free_mem_region;
 	}
 
 	/* Create our layers */
@@ -144,7 +151,7 @@ static int sun4i_drv_bind(struct device *dev)
 	if (IS_ERR(drv->layers)) {
 		dev_err(drm->dev, "Couldn't create the planes\n");
 		ret = PTR_ERR(drv->layers);
-		goto free_drm;
+		goto free_mem_region;
 	}
 
 	/* Create our CRTC */
@@ -152,7 +159,7 @@ static int sun4i_drv_bind(struct device *dev)
 	if (!drv->crtc) {
 		dev_err(drm->dev, "Couldn't create the CRTC\n");
 		ret = -EINVAL;
-		goto free_drm;
+		goto free_mem_region;
 	}
 	drm->irq_enabled = true;
 
@@ -164,7 +171,7 @@ static int sun4i_drv_bind(struct device *dev)
 	if (IS_ERR(drv->fbdev)) {
 		dev_err(drm->dev, "Couldn't create our framebuffer\n");
 		ret = PTR_ERR(drv->fbdev);
-		goto free_drm;
+		goto free_mem_region;
 	}
 
 	/* Enable connectors polling */
@@ -172,10 +179,12 @@ static int sun4i_drv_bind(struct device *dev)
 
 	ret = drm_dev_register(drm, 0);
 	if (ret)
-		goto free_drm;
+		goto free_mem_region;
 
 	return 0;
 
+free_mem_region:
+	of_reserved_mem_device_release(dev);
 free_drm:
 	drm_dev_unref(drm);
 	return ret;
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 4/8] drm/sun4i: Grab reserved memory region

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Thu, Feb 09, 2017 at 05:39:18PM +0100, Maxime Ripard wrote:
> Allow to provide an optional memory region to allocate from for our DRM
> driver.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Fixed the conflicts and applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[PATCH 5/8] ARM: sun8i: a33: Add shared display memory pool

[Maxime Ripard]

The memory buffers might need to be allocated and shared from both the
scanout and the GPU.

Create a memory region reserved for their own usage so that each can
allocate from it, and get the informations on the region that is going to
be used (size and offset).

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 5a9ba43ccb07..043b1b017276 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -97,6 +97,7 @@
 	de: display-engine {
 		compatible = "allwinner,sun8i-a33-display-engine";
 		allwinner,pipelines = <&fe0>;
+		memory-region = <&display_pool>;
 		status = "disabled";
 	};
 
@@ -104,6 +105,18 @@
 		reg = <0x40000000 0x80000000>;
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		display_pool: cma {
+			compatible = "shared-dma-pool";
+			size = <0x1000000>;
+			reusable;
+		};
+	};
+
 	soc@01c00000 {
 		tcon0: lcd-controller@01c0c000 {
 			compatible = "allwinner,sun8i-a33-tcon";
@@ -267,6 +280,10 @@
 	compatible = "allwinner,sun8i-a33-ccu";
 };
 
+&mali {
+	memory-region = <&display_pool>;
+};
+
 &pio {
 	compatible = "allwinner,sun8i-a33-pinctrl";
 	interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Maxime Ripard]

The operating-points-v2 binding gives a way to provide the OPP of the GPU.
Let's use it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index 88df4a276607..2b6243e730f6 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -39,6 +39,10 @@ Optional properties:
     Memory region to allocate from, as defined in
     Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
 
+  - operating-points-v2:
+    Operating Points for the GPU, as defined in
+    Documentation/devicetree/bindings/opp/opp.txt
+
 Vendor-specific bindings
 ------------------------
 
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:20PM +0100, Maxime Ripard wrote:
> The operating-points-v2 binding gives a way to provide the OPP of the GPU.
> Let's use it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
>  1 file changed, 4 insertions(+), 0 deletions(-)

Bindings should not unnecessarily evolve. The h/w does not evolve in 
this way. This should have been part of the original binding given that 
it was just added.

Acked-by: Rob Herring <robh@kernel.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Maxime Ripard]

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

On Thu, Feb 09, 2017 at 05:39:20PM +0100, Maxime Ripard wrote:
> The operating-points-v2 binding gives a way to provide the OPP of the GPU.
> Let's use it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Applied with Rob Acked-by.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 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

[PATCH 7/8] ARM: sunxi: Select PM_OPP

[Maxime Ripard]

Device frequency scaling is implemented through devfreq in the kernel,
which requires CONFIG_PM_OPP.

Let's select it.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/mach-sunxi/Kconfig | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index b9863f9a35fa..58153cdf025b 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -6,6 +6,7 @@ menuconfig ARCH_SUNXI
 	select GENERIC_IRQ_CHIP
 	select GPIOLIB
 	select PINCTRL
+	select PM_OPP
 	select SUN4I_TIMER
 	select RESET_CONTROLLER
 
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 7/8] ARM: sunxi: Select PM_OPP

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Thu, Feb 09, 2017 at 05:39:21PM +0100, Maxime Ripard wrote:
> Device frequency scaling is implemented through devfreq in the kernel,
> which requires CONFIG_PM_OPP.
> 
> Let's select it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Applied.
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Maxime Ripard]

The Mali GPU in the A33 has various operating frequencies used in the
Allwinner BSP.

Add them to our DT.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 043b1b017276..e1b0abfee42f 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -101,6 +101,22 @@
 		status = "disabled";
 	};
 
+	mali_opp_table: opp_table1 {
+		compatible = "operating-points-v2";
+
+		opp@144000000 {
+			opp-hz = /bits/ 64 <144000000>;
+		};
+
+		opp@240000000 {
+			opp-hz = /bits/ 64 <240000000>;
+		};
+
+		opp@384000000 {
+			opp-hz = /bits/ 64 <384000000>;
+		};
+	};
+
 	memory {
 		reg = <0x40000000 0x80000000>;
 	};
@@ -282,6 +298,7 @@
 
 &mali {
 	memory-region = <&display_pool>;
+	operating-points-v2 = <&mali_opp_table>;
 };
 
 &pio {
-- 
git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Rob Herring]

On Thu, Feb 09, 2017 at 05:39:22PM +0100, Maxime Ripard wrote:
> The Mali GPU in the A33 has various operating frequencies used in the
> Allwinner BSP.
> 
> Add them to our DT.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 043b1b017276..e1b0abfee42f 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -101,6 +101,22 @@
>  		status = "disabled";
>  	};
>  
> +	mali_opp_table: opp_table1 {

gpu-opp-table

> +		compatible = "operating-points-v2";
> +
> +		opp@144000000 {
> +			opp-hz = /bits/ 64 <144000000>;
> +		};
> +
> +		opp@240000000 {
> +			opp-hz = /bits/ 64 <240000000>;
> +		};
> +
> +		opp@384000000 {
> +			opp-hz = /bits/ 64 <384000000>;
> +		};
> +	};
> +
>  	memory {
>  		reg = <0x40000000 0x80000000>;
>  	};
> @@ -282,6 +298,7 @@
>  
>  &mali {
>  	memory-region = <&display_pool>;
> +	operating-points-v2 = <&mali_opp_table>;
>  };
>  
>  &pio {
> -- 
> git-series 0.8.11

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Maxime Ripard]

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

On Wed, Feb 15, 2017 at 05:40:29PM -0600, Rob Herring wrote:
> On Thu, Feb 09, 2017 at 05:39:22PM +0100, Maxime Ripard wrote:
> > The Mali GPU in the A33 has various operating frequencies used in the
> > Allwinner BSP.
> > 
> > Add them to our DT.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> >  arch/arm/boot/dts/sun8i-a33.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> > index 043b1b017276..e1b0abfee42f 100644
> > --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> > @@ -101,6 +101,22 @@
> >  		status = "disabled";
> >  	};
> >  
> > +	mali_opp_table: opp_table1 {
> 
> gpu-opp-table

Applied with that change. Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 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