[RFC PATCH 1/2] ARM: imx6q: Add GPR6 and GPR7 register definitions for iomuxc gpr

[RFC PATCH 1/2] ARM: imx6q: Add GPR6 and GPR7 register definitions for iomuxc gpr

[Philipp Zabel]

Masks for IPU AXI transaction QoS settings

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
index 866e355..ff44374 100644
--- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
+++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
@@ -242,6 +242,24 @@
 
 #define IMX6Q_GPR5_L2_CLK_STOP			BIT(8)
 
+#define IMX6Q_GPR6_IPU1_ID00_WR_QOS_MASK	(0xf << 0)
+#define IMX6Q_GPR6_IPU1_ID01_WR_QOS_MASK	(0xf << 4)
+#define IMX6Q_GPR6_IPU1_ID10_WR_QOS_MASK	(0xf << 8)
+#define IMX6Q_GPR6_IPU1_ID11_WR_QOS_MASK	(0xf << 12)
+#define IMX6Q_GPR6_IPU1_ID00_RD_QOS_MASK	(0xf << 16)
+#define IMX6Q_GPR6_IPU1_ID01_RD_QOS_MASK	(0xf << 20)
+#define IMX6Q_GPR6_IPU1_ID10_RD_QOS_MASK	(0xf << 24)
+#define IMX6Q_GPR6_IPU1_ID11_RD_QOS_MASK	(0xf << 28)
+
+#define IMX6Q_GPR7_IPU2_ID00_WR_QOS_MASK	(0xf << 0)
+#define IMX6Q_GPR7_IPU2_ID01_WR_QOS_MASK	(0xf << 4)
+#define IMX6Q_GPR7_IPU2_ID10_WR_QOS_MASK	(0xf << 8)
+#define IMX6Q_GPR7_IPU2_ID11_WR_QOS_MASK	(0xf << 12)
+#define IMX6Q_GPR7_IPU2_ID00_RD_QOS_MASK	(0xf << 16)
+#define IMX6Q_GPR7_IPU2_ID01_RD_QOS_MASK	(0xf << 20)
+#define IMX6Q_GPR7_IPU2_ID10_RD_QOS_MASK	(0xf << 24)
+#define IMX6Q_GPR7_IPU2_ID11_RD_QOS_MASK	(0xf << 28)
+
 #define IMX6Q_GPR8_TX_SWING_LOW			(0x7f << 25)
 #define IMX6Q_GPR8_TX_SWING_FULL		(0x7f << 18)
 #define IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB		(0x3f << 12)
-- 
1.8.5.3

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Philipp Zabel]

This is needed so that the IPU framebuffer scanout cannot be
starved by VPU or GPU activity.
Some boards like the SabreLite and SabreSD seem to set this in
the DCD already, but the documented register reset values do not
contain the necessary settings.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 arch/arm/mach-imx/mach-imx6q.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 76e5db4..f094bd3 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -194,6 +194,32 @@ static void __init imx6q_1588_init(void)
 
 }
 
+static void __init imx6q_axi_init(void)
+{
+	struct regmap *gpr;
+
+	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+	if (!IS_ERR(gpr)) {
+		/* Enable the cacheable attribute of VPU and IPU AXI transactions */
+		regmap_update_bits(gpr, IOMUXC_GPR4,
+				IMX6Q_GPR4_VPU_WR_CACHE_SEL | IMX6Q_GPR4_VPU_RD_CACHE_SEL |
+				IMX6Q_GPR4_VPU_P_WR_CACHE_VAL | IMX6Q_GPR4_VPU_P_RD_CACHE_VAL_MASK |
+				IMX6Q_GPR4_IPU_WR_CACHE_CTL | IMX6Q_GPR4_IPU_RD_CACHE_CTL,
+				IMX6Q_GPR4_VPU_WR_CACHE_SEL | IMX6Q_GPR4_VPU_RD_CACHE_SEL |
+				IMX6Q_GPR4_VPU_P_WR_CACHE_VAL | IMX6Q_GPR4_VPU_P_RD_CACHE_VAL_MASK |
+				IMX6Q_GPR4_IPU_WR_CACHE_CTL | IMX6Q_GPR4_IPU_RD_CACHE_CTL);
+		/* Increase IPU read QoS priority */
+		regmap_update_bits(gpr, IOMUXC_GPR6,
+				IMX6Q_GPR6_IPU1_ID00_RD_QOS_MASK | IMX6Q_GPR6_IPU1_ID01_RD_QOS_MASK,
+				(0xf << 16) | (0x7 << 20));
+		regmap_update_bits(gpr, IOMUXC_GPR7,
+				IMX6Q_GPR7_IPU2_ID00_RD_QOS_MASK | IMX6Q_GPR7_IPU2_ID01_RD_QOS_MASK,
+				(0xf << 16) | (0x7 << 20));
+	} else {
+		pr_warn("failed to find fsl,imx6q-iomuxc-gpr regmap\n");
+	}
+}
+
 static void __init imx6q_init_machine(void)
 {
 	struct device *parent;
@@ -214,6 +240,7 @@ static void __init imx6q_init_machine(void)
 	imx_anatop_init();
 	imx6q_pm_init();
 	imx6q_1588_init();
+	imx6q_axi_init();
 }
 
 #define OCOTP_CFG3			0x440
-- 
1.8.5.3

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Fabio Estevam]

On Thu, Feb 20, 2014 at 8:44 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> This is needed so that the IPU framebuffer scanout cannot be
> starved by VPU or GPU activity.
> Some boards like the SabreLite and SabreSD seem to set this in
> the DCD already, but the documented register reset values do not
> contain the necessary settings.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

Yes, better to configure it in the kernel than relying on the
bootloader to do this setup.

Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Shawn Guo]

On Thu, Feb 20, 2014 at 12:44:33PM +0100, Philipp Zabel wrote:
> This is needed so that the IPU framebuffer scanout cannot be
> starved by VPU or GPU activity.
> Some boards like the SabreLite and SabreSD seem to set this in
> the DCD already, but the documented register reset values do not
> contain the necessary settings.
> 
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

I'm fine with the patches, but not sure if I should just apply them
since you add 'RFC' tag in there.

Shawn

> ---
>  arch/arm/mach-imx/mach-imx6q.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 76e5db4..f094bd3 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -194,6 +194,32 @@ static void __init imx6q_1588_init(void)
>  
>  }
>  
> +static void __init imx6q_axi_init(void)
> +{
> +	struct regmap *gpr;
> +
> +	gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> +	if (!IS_ERR(gpr)) {
> +		/* Enable the cacheable attribute of VPU and IPU AXI transactions */
> +		regmap_update_bits(gpr, IOMUXC_GPR4,
> +				IMX6Q_GPR4_VPU_WR_CACHE_SEL | IMX6Q_GPR4_VPU_RD_CACHE_SEL |
> +				IMX6Q_GPR4_VPU_P_WR_CACHE_VAL | IMX6Q_GPR4_VPU_P_RD_CACHE_VAL_MASK |
> +				IMX6Q_GPR4_IPU_WR_CACHE_CTL | IMX6Q_GPR4_IPU_RD_CACHE_CTL,
> +				IMX6Q_GPR4_VPU_WR_CACHE_SEL | IMX6Q_GPR4_VPU_RD_CACHE_SEL |
> +				IMX6Q_GPR4_VPU_P_WR_CACHE_VAL | IMX6Q_GPR4_VPU_P_RD_CACHE_VAL_MASK |
> +				IMX6Q_GPR4_IPU_WR_CACHE_CTL | IMX6Q_GPR4_IPU_RD_CACHE_CTL);
> +		/* Increase IPU read QoS priority */
> +		regmap_update_bits(gpr, IOMUXC_GPR6,
> +				IMX6Q_GPR6_IPU1_ID00_RD_QOS_MASK | IMX6Q_GPR6_IPU1_ID01_RD_QOS_MASK,
> +				(0xf << 16) | (0x7 << 20));
> +		regmap_update_bits(gpr, IOMUXC_GPR7,
> +				IMX6Q_GPR7_IPU2_ID00_RD_QOS_MASK | IMX6Q_GPR7_IPU2_ID01_RD_QOS_MASK,
> +				(0xf << 16) | (0x7 << 20));
> +	} else {
> +		pr_warn("failed to find fsl,imx6q-iomuxc-gpr regmap\n");
> +	}
> +}
> +
>  static void __init imx6q_init_machine(void)
>  {
>  	struct device *parent;
> @@ -214,6 +240,7 @@ static void __init imx6q_init_machine(void)
>  	imx_anatop_init();
>  	imx6q_pm_init();
>  	imx6q_1588_init();
> +	imx6q_axi_init();
>  }
>  
>  #define OCOTP_CFG3			0x440
> -- 
> 1.8.5.3
> 

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Philipp Zabel]

Hi Shawn,

Am Freitag, den 21.02.2014, 10:19 +0800 schrieb Shawn Guo:
> On Thu, Feb 20, 2014 at 12:44:33PM +0100, Philipp Zabel wrote:
> > This is needed so that the IPU framebuffer scanout cannot be
> > starved by VPU or GPU activity.
> > Some boards like the SabreLite and SabreSD seem to set this in
> > the DCD already, but the documented register reset values do not
> > contain the necessary settings.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> 
> I'm fine with the patches, but not sure if I should just apply them
> since you add 'RFC' tag in there.

I'm not sure whether this specific fixed QoS configuration should be
imposed on everyone. OTOH, following the principle of least surprise,
it's probably better to have this here, out in the open, than included
hidden in bootloader DCD tables (or not, depending on the board).
So if nobody objects, feel free to apply them.

regards
Philipp

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Shawn Guo]

On Fri, Feb 21, 2014 at 11:28:16AM +0100, Philipp Zabel wrote:
> Hi Shawn,
> 
> Am Freitag, den 21.02.2014, 10:19 +0800 schrieb Shawn Guo:
> > On Thu, Feb 20, 2014 at 12:44:33PM +0100, Philipp Zabel wrote:
> > > This is needed so that the IPU framebuffer scanout cannot be
> > > starved by VPU or GPU activity.
> > > Some boards like the SabreLite and SabreSD seem to set this in
> > > the DCD already, but the documented register reset values do not
> > > contain the necessary settings.
> > > 
> > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > I'm fine with the patches, but not sure if I should just apply them
> > since you add 'RFC' tag in there.
> 
> I'm not sure whether this specific fixed QoS configuration should be
> imposed on everyone. OTOH, following the principle of least surprise,
> it's probably better to have this here, out in the open, than included
> hidden in bootloader DCD tables (or not, depending on the board).
> So if nobody objects, feel free to apply them.

Okay.  But can you please fix those unnecessary line-over-80-columns
warnings?

Shawn

[RFC PATCH 2/2] ARM: imx6q: Mark VPU and IPU AXI transfers as cacheable, increase IPU priority

[Philipp Zabel]

Am Montag, den 24.02.2014, 10:03 +0800 schrieb Shawn Guo:
> On Fri, Feb 21, 2014 at 11:28:16AM +0100, Philipp Zabel wrote:
> > Hi Shawn,
> > 
> > Am Freitag, den 21.02.2014, 10:19 +0800 schrieb Shawn Guo:
> > > On Thu, Feb 20, 2014 at 12:44:33PM +0100, Philipp Zabel wrote:
> > > > This is needed so that the IPU framebuffer scanout cannot be
> > > > starved by VPU or GPU activity.
> > > > Some boards like the SabreLite and SabreSD seem to set this in
> > > > the DCD already, but the documented register reset values do not
> > > > contain the necessary settings.
> > > > 
> > > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > 
> > > I'm fine with the patches, but not sure if I should just apply them
> > > since you add 'RFC' tag in there.
> > 
> > I'm not sure whether this specific fixed QoS configuration should be
> > imposed on everyone. OTOH, following the principle of least surprise,
> > it's probably better to have this here, out in the open, than included
> > hidden in bootloader DCD tables (or not, depending on the board).
> > So if nobody objects, feel free to apply them.
> 
> Okay.  But can you please fix those unnecessary line-over-80-columns
> warnings?

Ok, resent without RFC and with short lines.

regards
Philipp