[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.

Provide support in the kernel for the same.

V2 of the series contains documentation update and a bug fix due to a
typo introduced during patch split :(

Nishanth Menon (2):
  ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
    programming
  ARM: l2c: AM437x: Introduce support for cache filter programming

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    2 ++
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 59 insertions(+)

-- 
1.7.9.5

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.

Provide support in the kernel for the same.

V2 of the series contains documentation update and a bug fix due to a
typo introduced during patch split :(

Nishanth Menon (2):
  ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
    programming
  ARM: l2c: AM437x: Introduce support for cache filter programming

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    2 ++
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 59 insertions(+)

-- 
1.7.9.5

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

Hi,
OMAP4 and AM437x ROM code provides services to program PL310's latency
registers and AM437x provides service for programming Address filter
registers.

Provide support in the kernel for the same.

V2 of the series contains documentation update and a bug fix due to a
typo introduced during patch split :(

Nishanth Menon (2):
  ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
    programming
  ARM: l2c: AM437x: Introduce support for cache filter programming

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    2 ++
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   36 ++++++++++++++++++++++++++++++++++++
 4 files changed, 59 insertions(+)

-- 
1.7.9.5

[PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming

[Nishanth Menon]

OMAP4 and AM437x generations of processors support programming the
PL310 L2Cache controller's Latency control registers using a secure
montior call. Unfortunately, this varies from other PL310 programming
sequence with a requirement of two parameters instead of the generic
single parameter configuration.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changed in V2: document data update for Aegis rom code doc

V1: https://patchwork.kernel.org/patch/5560131/

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   15 +++++++++++++++
 4 files changed, 37 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 19c9144..d5f8a9c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -240,6 +240,7 @@ extern void gic_dist_enable(void);
 extern bool gic_dist_disabled(void);
 extern void gic_timer_retrigger(void);
 extern void omap_smc1(u32 fn, u32 arg);
+extern void omap_smc1_2(u32 fn, u32 arg1, u32 arg2);
 extern void __iomem *omap4_get_sar_ram_base(void);
 extern void omap_do_wfi(void);
 
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index dec2b05..338fdab 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,7 @@
 #define OMAP4_MON_L2X0_DBG_CTRL_INDEX	0x100
 #define OMAP4_MON_L2X0_CTRL_INDEX	0x102
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
+#define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index fd90125..caf2bd1 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -33,6 +33,26 @@ ENTRY(omap_smc1)
 	ldmfd   sp!, {r2-r12, pc}
 ENDPROC(omap_smc1)
 
+/*
+ * This is common routine to manage secure monitor API
+ * used to modify the PL310 secure registers.
+ * 'r0' and 'r1' contains the value to be modified and 'r12' contains
+ * the monitor API number. It uses few CPU registers
+ * internally and hence they need be backed up including
+ * link register "lr".
+ * Function signature : void omap_smc1_2(u32 fn, u32 arg1, u32 arg2)
+ */
+
+ENTRY(omap_smc1_2)
+	stmfd   sp!, {r2-r12, lr}
+	mov	r12, r0
+	mov 	r0, r1
+	mov 	r1, r2
+	dsb
+	smc	#0
+	ldmfd   sp!, {r2-r12, pc}
+ENDPROC(omap_smc1_2)
+
 /**
  * u32 omap_smc2(u32 id, u32 falg, u32 pargs)
  * Low level common routine for secure HAL and PPA APIs.
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index fe99cef..25a0b2f 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -191,6 +191,21 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		pr_info_once("OMAP L2C310: ROM does not support power control setting\n");
 		return;
 
+	case L310_TAG_LATENCY_CTRL:
+	case L310_DATA_LATENCY_CTRL:
+	{
+		void __iomem *base = omap4_get_l2cache_base();
+		u32 data_latency, tag_latency;
+
+		tag_latency = (reg == L310_TAG_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_TAG_LATENCY_CTRL);
+		data_latency = (reg == L310_DATA_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_DATA_LATENCY_CTRL);
+		omap_smc1_2(OMAP4_MON_L2X0_SETLATENCY_INDEX, tag_latency,
+			    data_latency);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

[PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming

[Nishanth Menon]

OMAP4 and AM437x generations of processors support programming the
PL310 L2Cache controller's Latency control registers using a secure
montior call. Unfortunately, this varies from other PL310 programming
sequence with a requirement of two parameters instead of the generic
single parameter configuration.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changed in V2: document data update for Aegis rom code doc

V1: https://patchwork.kernel.org/patch/5560131/

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   15 +++++++++++++++
 4 files changed, 37 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 19c9144..d5f8a9c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -240,6 +240,7 @@ extern void gic_dist_enable(void);
 extern bool gic_dist_disabled(void);
 extern void gic_timer_retrigger(void);
 extern void omap_smc1(u32 fn, u32 arg);
+extern void omap_smc1_2(u32 fn, u32 arg1, u32 arg2);
 extern void __iomem *omap4_get_sar_ram_base(void);
 extern void omap_do_wfi(void);
 
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index dec2b05..338fdab 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,7 @@
 #define OMAP4_MON_L2X0_DBG_CTRL_INDEX	0x100
 #define OMAP4_MON_L2X0_CTRL_INDEX	0x102
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
+#define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index fd90125..caf2bd1 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -33,6 +33,26 @@ ENTRY(omap_smc1)
 	ldmfd   sp!, {r2-r12, pc}
 ENDPROC(omap_smc1)
 
+/*
+ * This is common routine to manage secure monitor API
+ * used to modify the PL310 secure registers.
+ * 'r0' and 'r1' contains the value to be modified and 'r12' contains
+ * the monitor API number. It uses few CPU registers
+ * internally and hence they need be backed up including
+ * link register "lr".
+ * Function signature : void omap_smc1_2(u32 fn, u32 arg1, u32 arg2)
+ */
+
+ENTRY(omap_smc1_2)
+	stmfd   sp!, {r2-r12, lr}
+	mov	r12, r0
+	mov 	r0, r1
+	mov 	r1, r2
+	dsb
+	smc	#0
+	ldmfd   sp!, {r2-r12, pc}
+ENDPROC(omap_smc1_2)
+
 /**
  * u32 omap_smc2(u32 id, u32 falg, u32 pargs)
  * Low level common routine for secure HAL and PPA APIs.
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index fe99cef..25a0b2f 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -191,6 +191,21 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		pr_info_once("OMAP L2C310: ROM does not support power control setting\n");
 		return;
 
+	case L310_TAG_LATENCY_CTRL:
+	case L310_DATA_LATENCY_CTRL:
+	{
+		void __iomem *base = omap4_get_l2cache_base();
+		u32 data_latency, tag_latency;
+
+		tag_latency = (reg == L310_TAG_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_TAG_LATENCY_CTRL);
+		data_latency = (reg == L310_DATA_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_DATA_LATENCY_CTRL);
+		omap_smc1_2(OMAP4_MON_L2X0_SETLATENCY_INDEX, tag_latency,
+			    data_latency);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

[PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming

[Nishanth Menon]

OMAP4 and AM437x generations of processors support programming the
PL310 L2Cache controller's Latency control registers using a secure
montior call. Unfortunately, this varies from other PL310 programming
sequence with a requirement of two parameters instead of the generic
single parameter configuration.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changed in V2: document data update for Aegis rom code doc

V1: https://patchwork.kernel.org/patch/5560131/

 arch/arm/mach-omap2/common.h       |    1 +
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap-smc.S     |   20 ++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c |   15 +++++++++++++++
 4 files changed, 37 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 19c9144..d5f8a9c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -240,6 +240,7 @@ extern void gic_dist_enable(void);
 extern bool gic_dist_disabled(void);
 extern void gic_timer_retrigger(void);
 extern void omap_smc1(u32 fn, u32 arg);
+extern void omap_smc1_2(u32 fn, u32 arg1, u32 arg2);
 extern void __iomem *omap4_get_sar_ram_base(void);
 extern void omap_do_wfi(void);
 
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index dec2b05..338fdab 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -42,6 +42,7 @@
 #define OMAP4_MON_L2X0_DBG_CTRL_INDEX	0x100
 #define OMAP4_MON_L2X0_CTRL_INDEX	0x102
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
+#define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index fd90125..caf2bd1 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -33,6 +33,26 @@ ENTRY(omap_smc1)
 	ldmfd   sp!, {r2-r12, pc}
 ENDPROC(omap_smc1)
 
+/*
+ * This is common routine to manage secure monitor API
+ * used to modify the PL310 secure registers.
+ * 'r0' and 'r1' contains the value to be modified and 'r12' contains
+ * the monitor API number. It uses few CPU registers
+ * internally and hence they need be backed up including
+ * link register "lr".
+ * Function signature : void omap_smc1_2(u32 fn, u32 arg1, u32 arg2)
+ */
+
+ENTRY(omap_smc1_2)
+	stmfd   sp!, {r2-r12, lr}
+	mov	r12, r0
+	mov 	r0, r1
+	mov 	r1, r2
+	dsb
+	smc	#0
+	ldmfd   sp!, {r2-r12, pc}
+ENDPROC(omap_smc1_2)
+
 /**
  * u32 omap_smc2(u32 id, u32 falg, u32 pargs)
  * Low level common routine for secure HAL and PPA APIs.
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index fe99cef..25a0b2f 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -191,6 +191,21 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		pr_info_once("OMAP L2C310: ROM does not support power control setting\n");
 		return;
 
+	case L310_TAG_LATENCY_CTRL:
+	case L310_DATA_LATENCY_CTRL:
+	{
+		void __iomem *base = omap4_get_l2cache_base();
+		u32 data_latency, tag_latency;
+
+		tag_latency = (reg == L310_TAG_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_TAG_LATENCY_CTRL);
+		data_latency = (reg == L310_DATA_LATENCY_CTRL) ? val :
+			       readl_relaxed(base + L310_DATA_LATENCY_CTRL);
+		omap_smc1_2(OMAP4_MON_L2X0_SETLATENCY_INDEX, tag_latency,
+			    data_latency);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.

Unfortunately, this secure monitor service is not supported on OMAP4
generation of processors.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---

Changes in V2:
	- smc call should use filter start in r0 and filter end in r1.
	- Document version update.

V1: https://patchwork.kernel.org/patch/5560111/
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap4-common.c |   21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 338fdab..569e167 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -44,6 +44,7 @@
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
 #define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
+#define AM43X_MON_L2X0_SETFILTER_INDEX	0x114
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
 #define OMAP5_MON_AMBA_IF_INDEX		0x108
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 25a0b2f..0b1454d 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -206,6 +206,27 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		return;
 	}
 
+	case L310_ADDR_FILTER_START:
+	case L310_ADDR_FILTER_END:
+	{
+		void __iomem *base;
+		u32 filter_start, filter_end;
+
+		if (!soc_is_am437x()) {
+			pr_info_once("OMAP L2C310: ROM does not support filter setting\n");
+			return;
+		}
+
+		base = omap4_get_l2cache_base();
+		filter_start = (reg == L310_ADDR_FILTER_START) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_START);
+		filter_end = (reg == L310_ADDR_FILTER_END) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_END);
+		omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
+			    filter_end);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.

Unfortunately, this secure monitor service is not supported on OMAP4
generation of processors.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---

Changes in V2:
	- smc call should use filter start in r0 and filter end in r1.
	- Document version update.

V1: https://patchwork.kernel.org/patch/5560111/
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap4-common.c |   21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 338fdab..569e167 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -44,6 +44,7 @@
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
 #define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
+#define AM43X_MON_L2X0_SETFILTER_INDEX	0x114
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
 #define OMAP5_MON_AMBA_IF_INDEX		0x108
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 25a0b2f..0b1454d 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -206,6 +206,27 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		return;
 	}
 
+	case L310_ADDR_FILTER_START:
+	case L310_ADDR_FILTER_END:
+	{
+		void __iomem *base;
+		u32 filter_start, filter_end;
+
+		if (!soc_is_am437x()) {
+			pr_info_once("OMAP L2C310: ROM does not support filter setting\n");
+			return;
+		}
+
+		base = omap4_get_l2cache_base();
+		filter_start = (reg == L310_ADDR_FILTER_START) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_START);
+		filter_end = (reg == L310_ADDR_FILTER_END) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_END);
+		omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
+			    filter_end);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

AM437x generation of processors support programming the PL310 L2Cache
controller's address filter start and end registers using a secure
montior service.

Unfortunately, this secure monitor service is not supported on OMAP4
generation of processors.

Information based on:
OMAP4430 Public ROM Code API Functional Specfication revision 0.6 (Oct
27, 2010)
OMAP4440 Public ROM Code API Functional Specfication revision 0.1 (Oct
27, 2010)
Aegis ROM Code Memory and Peripheral Booting Functional Specification
version 1.00 (Jan 21, 2014)

Signed-off-by: Nishanth Menon <nm@ti.com>
---

Changes in V2:
	- smc call should use filter start in r0 and filter end in r1.
	- Document version update.

V1: https://patchwork.kernel.org/patch/5560111/
 arch/arm/mach-omap2/omap-secure.h  |    1 +
 arch/arm/mach-omap2/omap4-common.c |   21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 338fdab..569e167 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -44,6 +44,7 @@
 #define OMAP4_MON_L2X0_AUXCTRL_INDEX	0x109
 #define OMAP4_MON_L2X0_SETLATENCY_INDEX	0x112
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
+#define AM43X_MON_L2X0_SETFILTER_INDEX	0x114
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
 #define OMAP5_MON_AMBA_IF_INDEX		0x108
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 25a0b2f..0b1454d 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -206,6 +206,27 @@ void omap4_l2c310_write_sec(unsigned long val, unsigned reg)
 		return;
 	}
 
+	case L310_ADDR_FILTER_START:
+	case L310_ADDR_FILTER_END:
+	{
+		void __iomem *base;
+		u32 filter_start, filter_end;
+
+		if (!soc_is_am437x()) {
+			pr_info_once("OMAP L2C310: ROM does not support filter setting\n");
+			return;
+		}
+
+		base = omap4_get_l2cache_base();
+		filter_start = (reg == L310_ADDR_FILTER_START) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_START);
+		filter_end = (reg == L310_ADDR_FILTER_END) ? val :
+			       readl_relaxed(base + L310_ADDR_FILTER_END);
+		omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
+			    filter_end);
+		return;
+	}
+
 	default:
 		WARN_ONCE(1, "OMAP L2C310: ignoring write to reg 0x%x\n", reg);
 		return;
-- 
1.7.9.5

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[santosh.shilimkar]

On 1/2/15 9:43 AM, Nishanth Menon wrote:
> Hi,
> OMAP4 and AM437x ROM code provides services to program PL310's latency
> registers and AM437x provides service for programming Address filter
> registers.
>
> Provide support in the kernel for the same.
>
> V2 of the series contains documentation update and a bug fix due to a
> typo introduced during patch split :(
>
> Nishanth Menon (2):
>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>      programming
>    ARM: l2c: AM437x: Introduce support for cache filter programming
>
Looks fine to me ...
Feel free to add my ack if you need one ...

Minor: The subject looks like I2C though it is L2C ;-)

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[santosh.shilimkar at oracle.com]

On 1/2/15 9:43 AM, Nishanth Menon wrote:
> Hi,
> OMAP4 and AM437x ROM code provides services to program PL310's latency
> registers and AM437x provides service for programming Address filter
> registers.
>
> Provide support in the kernel for the same.
>
> V2 of the series contains documentation update and a bug fix due to a
> typo introduced during patch split :(
>
> Nishanth Menon (2):
>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>      programming
>    ARM: l2c: AM437x: Introduce support for cache filter programming
>
Looks fine to me ...
Feel free to add my ack if you need one ...

Minor: The subject looks like I2C though it is L2C ;-)

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

On 01/02/2015 12:46 PM, santosh.shilimkar@oracle.com wrote:
> On 1/2/15 9:43 AM, Nishanth Menon wrote:
>> Hi,
>> OMAP4 and AM437x ROM code provides services to program PL310's latency
>> registers and AM437x provides service for programming Address filter
>> registers.
>>
>> Provide support in the kernel for the same.
>>
>> V2 of the series contains documentation update and a bug fix due to a
>> typo introduced during patch split :(
>>
>> Nishanth Menon (2):
>>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>>      programming
>>    ARM: l2c: AM437x: Introduce support for cache filter programming
>>
> Looks fine to me ...
> Feel free to add my ack if you need one ...
> 
> Minor: The subject looks like I2C though it is L2C ;-)
> 
Yeah, the thought did occur to me, but decided instead to go with the
existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
ARM: l2c: omap2+: get rid of init call
ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
ARM: l2c: omap2: remove explicit non-secure access bits
ARM: l2c: omap2: remove cache size override
ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
ARM: l2c: omap2: implement new write_sec method
ARM: l2c: remove platforms/SoCs setting early BRESP
ARM: l2c: fix register naming
ARM: l2c: omap2: remove ES1.0 support

..

If folks feel strongly about this, I can capitalize the same and post
a v3 to help confusing fonts on certain mail clients and terminals.
let me know if folks want me to.


-- 
Regards,
Nishanth Menon

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

On 01/02/2015 12:46 PM, santosh.shilimkar@oracle.com wrote:
> On 1/2/15 9:43 AM, Nishanth Menon wrote:
>> Hi,
>> OMAP4 and AM437x ROM code provides services to program PL310's latency
>> registers and AM437x provides service for programming Address filter
>> registers.
>>
>> Provide support in the kernel for the same.
>>
>> V2 of the series contains documentation update and a bug fix due to a
>> typo introduced during patch split :(
>>
>> Nishanth Menon (2):
>>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>>      programming
>>    ARM: l2c: AM437x: Introduce support for cache filter programming
>>
> Looks fine to me ...
> Feel free to add my ack if you need one ...
> 
> Minor: The subject looks like I2C though it is L2C ;-)
> 
Yeah, the thought did occur to me, but decided instead to go with the
existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
ARM: l2c: omap2+: get rid of init call
ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
ARM: l2c: omap2: remove explicit non-secure access bits
ARM: l2c: omap2: remove cache size override
ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
ARM: l2c: omap2: implement new write_sec method
ARM: l2c: remove platforms/SoCs setting early BRESP
ARM: l2c: fix register naming
ARM: l2c: omap2: remove ES1.0 support

..

If folks feel strongly about this, I can capitalize the same and post
a v3 to help confusing fonts on certain mail clients and terminals.
let me know if folks want me to.


-- 
Regards,
Nishanth Menon

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Nishanth Menon]

On 01/02/2015 12:46 PM, santosh.shilimkar at oracle.com wrote:
> On 1/2/15 9:43 AM, Nishanth Menon wrote:
>> Hi,
>> OMAP4 and AM437x ROM code provides services to program PL310's latency
>> registers and AM437x provides service for programming Address filter
>> registers.
>>
>> Provide support in the kernel for the same.
>>
>> V2 of the series contains documentation update and a bug fix due to a
>> typo introduced during patch split :(
>>
>> Nishanth Menon (2):
>>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>>      programming
>>    ARM: l2c: AM437x: Introduce support for cache filter programming
>>
> Looks fine to me ...
> Feel free to add my ack if you need one ...
> 
> Minor: The subject looks like I2C though it is L2C ;-)
> 
Yeah, the thought did occur to me, but decided instead to go with the
existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
ARM: l2c: omap2+: get rid of init call
ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
ARM: l2c: omap2: remove explicit non-secure access bits
ARM: l2c: omap2: remove cache size override
ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
ARM: l2c: omap2: implement new write_sec method
ARM: l2c: remove platforms/SoCs setting early BRESP
ARM: l2c: fix register naming
ARM: l2c: omap2: remove ES1.0 support

..

If folks feel strongly about this, I can capitalize the same and post
a v3 to help confusing fonts on certain mail clients and terminals.
let me know if folks want me to.


-- 
Regards,
Nishanth Menon

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [150102 11:50]:
> On 01/02/2015 12:46 PM, santosh.shilimkar@oracle.com wrote:
> > On 1/2/15 9:43 AM, Nishanth Menon wrote:
> >> Hi,
> >> OMAP4 and AM437x ROM code provides services to program PL310's latency
> >> registers and AM437x provides service for programming Address filter
> >> registers.
> >>
> >> Provide support in the kernel for the same.
> >>
> >> V2 of the series contains documentation update and a bug fix due to a
> >> typo introduced during patch split :(
> >>
> >> Nishanth Menon (2):
> >>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
> >>      programming
> >>    ARM: l2c: AM437x: Introduce support for cache filter programming
> >>
> > Looks fine to me ...
> > Feel free to add my ack if you need one ...
> > 
> > Minor: The subject looks like I2C though it is L2C ;-)
> > 
> Yeah, the thought did occur to me, but decided instead to go with the
> existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
> ARM: l2c: omap2+: get rid of init call
> ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
> ARM: l2c: omap2: remove explicit non-secure access bits
> ARM: l2c: omap2: remove cache size override
> ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
> ARM: l2c: omap2: implement new write_sec method
> ARM: l2c: remove platforms/SoCs setting early BRESP
> ARM: l2c: fix register naming
> ARM: l2c: omap2: remove ES1.0 support
> 
> ..
> 
> If folks feel strongly about this, I can capitalize the same and post
> a v3 to help confusing fonts on certain mail clients and terminals.
> let me know if folks want me to.

I guess no need to :)

Looks like these still won't fix the issue we found in the
series posted by Tomasz though. At least I'm still getting errors
on am437x with these and the patches from Tomasz applied.

Regards,

Tony

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [150102 11:50]:
> On 01/02/2015 12:46 PM, santosh.shilimkar at oracle.com wrote:
> > On 1/2/15 9:43 AM, Nishanth Menon wrote:
> >> Hi,
> >> OMAP4 and AM437x ROM code provides services to program PL310's latency
> >> registers and AM437x provides service for programming Address filter
> >> registers.
> >>
> >> Provide support in the kernel for the same.
> >>
> >> V2 of the series contains documentation update and a bug fix due to a
> >> typo introduced during patch split :(
> >>
> >> Nishanth Menon (2):
> >>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
> >>      programming
> >>    ARM: l2c: AM437x: Introduce support for cache filter programming
> >>
> > Looks fine to me ...
> > Feel free to add my ack if you need one ...
> > 
> > Minor: The subject looks like I2C though it is L2C ;-)
> > 
> Yeah, the thought did occur to me, but decided instead to go with the
> existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
> ARM: l2c: omap2+: get rid of init call
> ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
> ARM: l2c: omap2: remove explicit non-secure access bits
> ARM: l2c: omap2: remove cache size override
> ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
> ARM: l2c: omap2: implement new write_sec method
> ARM: l2c: remove platforms/SoCs setting early BRESP
> ARM: l2c: fix register naming
> ARM: l2c: omap2: remove ES1.0 support
> 
> ..
> 
> If folks feel strongly about this, I can capitalize the same and post
> a v3 to help confusing fonts on certain mail clients and terminals.
> let me know if folks want me to.

I guess no need to :)

Looks like these still won't fix the issue we found in the
series posted by Tomasz though. At least I'm still getting errors
on am437x with these and the patches from Tomasz applied.

Regards,

Tony

Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

Hi Nishanth,

2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
> AM437x generation of processors support programming the PL310 L2Cache
> controller's address filter start and end registers using a secure
> montior service.

typo: s/montior/monitor/

[snip]

> +               base = omap4_get_l2cache_base();
> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
> +                              readl_relaxed(base + L310_ADDR_FILTER_START);
> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
> +                              readl_relaxed(base + L310_ADDR_FILTER_END);
> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
> +                           filter_end);
> +               return;

I don't have any significant comments about this patch in particular,
but just noticed that you need to do read-backs here (and the typo
thanks to the spell checker of my mailing app). Maybe you should
consider switching to the .configure() API I introduced in my series?
This would let you get rid of the hardcoded static mapping.

Best regards,
Tomasz

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

Hi Nishanth,

2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
> AM437x generation of processors support programming the PL310 L2Cache
> controller's address filter start and end registers using a secure
> montior service.

typo: s/montior/monitor/

[snip]

> +               base = omap4_get_l2cache_base();
> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
> +                              readl_relaxed(base + L310_ADDR_FILTER_START);
> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
> +                              readl_relaxed(base + L310_ADDR_FILTER_END);
> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
> +                           filter_end);
> +               return;

I don't have any significant comments about this patch in particular,
but just noticed that you need to do read-backs here (and the typo
thanks to the spell checker of my mailing app). Maybe you should
consider switching to the .configure() API I introduced in my series?
This would let you get rid of the hardcoded static mapping.

Best regards,
Tomasz

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Tomasz Figa]

Hi Tony,

2015-01-03 9:23 GMT+09:00 Tony Lindgren <tony@atomide.com>:
> * Nishanth Menon <nm@ti.com> [150102 11:50]:
>> On 01/02/2015 12:46 PM, santosh.shilimkar@oracle.com wrote:
>> > On 1/2/15 9:43 AM, Nishanth Menon wrote:
>> >> Hi,
>> >> OMAP4 and AM437x ROM code provides services to program PL310's latency
>> >> registers and AM437x provides service for programming Address filter
>> >> registers.
>> >>
>> >> Provide support in the kernel for the same.
>> >>
>> >> V2 of the series contains documentation update and a bug fix due to a
>> >> typo introduced during patch split :(
>> >>
>> >> Nishanth Menon (2):
>> >>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>> >>      programming
>> >>    ARM: l2c: AM437x: Introduce support for cache filter programming
>> >>
>> > Looks fine to me ...
>> > Feel free to add my ack if you need one ...
>> >
>> > Minor: The subject looks like I2C though it is L2C ;-)
>> >
>> Yeah, the thought did occur to me, but decided instead to go with the
>> existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
>> ARM: l2c: omap2+: get rid of init call
>> ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
>> ARM: l2c: omap2: remove explicit non-secure access bits
>> ARM: l2c: omap2: remove cache size override
>> ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
>> ARM: l2c: omap2: implement new write_sec method
>> ARM: l2c: remove platforms/SoCs setting early BRESP
>> ARM: l2c: fix register naming
>> ARM: l2c: omap2: remove ES1.0 support
>>
>> ..
>>
>> If folks feel strongly about this, I can capitalize the same and post
>> a v3 to help confusing fonts on certain mail clients and terminals.
>> let me know if folks want me to.
>
> I guess no need to :)
>
> Looks like these still won't fix the issue we found in the
> series posted by Tomasz though. At least I'm still getting errors
> on am437x with these and the patches from Tomasz applied.

Indeed, as I figured out in the original thread about this issue,
additional patch fixing code unaffected by my series (besides changing
the condition which triggers calling it) is necessary. Namely, the
affected 4 registers need to be written using the write_sec wrapper,
instead of using writel*() directly.

Best regards,
Tomasz

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.

[Tomasz Figa]

Hi Tony,

2015-01-03 9:23 GMT+09:00 Tony Lindgren <tony@atomide.com>:
> * Nishanth Menon <nm@ti.com> [150102 11:50]:
>> On 01/02/2015 12:46 PM, santosh.shilimkar at oracle.com wrote:
>> > On 1/2/15 9:43 AM, Nishanth Menon wrote:
>> >> Hi,
>> >> OMAP4 and AM437x ROM code provides services to program PL310's latency
>> >> registers and AM437x provides service for programming Address filter
>> >> registers.
>> >>
>> >> Provide support in the kernel for the same.
>> >>
>> >> V2 of the series contains documentation update and a bug fix due to a
>> >> typo introduced during patch split :(
>> >>
>> >> Nishanth Menon (2):
>> >>    ARM: l2c: OMAP4/AM437x: Introduce support for cache latency
>> >>      programming
>> >>    ARM: l2c: AM437x: Introduce support for cache filter programming
>> >>
>> > Looks fine to me ...
>> > Feel free to add my ack if you need one ...
>> >
>> > Minor: The subject looks like I2C though it is L2C ;-)
>> >
>> Yeah, the thought did occur to me, but decided instead to go with the
>> existing $subject conventions of arch/arm/mach-omap2/omap4-common.c
>> ARM: l2c: omap2+: get rid of init call
>> ARM: l2c: omap2+: get rid of redundant cache replacement policy setting
>> ARM: l2c: omap2: remove explicit non-secure access bits
>> ARM: l2c: omap2: remove cache size override
>> ARM: l2c: omap2: remove explicit SMI calls to enable L2 cache
>> ARM: l2c: omap2: implement new write_sec method
>> ARM: l2c: remove platforms/SoCs setting early BRESP
>> ARM: l2c: fix register naming
>> ARM: l2c: omap2: remove ES1.0 support
>>
>> ..
>>
>> If folks feel strongly about this, I can capitalize the same and post
>> a v3 to help confusing fonts on certain mail clients and terminals.
>> let me know if folks want me to.
>
> I guess no need to :)
>
> Looks like these still won't fix the issue we found in the
> series posted by Tomasz though. At least I'm still getting errors
> on am437x with these and the patches from Tomasz applied.

Indeed, as I figured out in the original thread about this issue,
additional patch fixing code unaffected by my series (besides changing
the condition which triggers calling it) is necessary. Namely, the
affected 4 registers need to be written using the write_sec wrapper,
instead of using writel*() directly.

Best regards,
Tomasz

Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

On 15:40-20150103, Tomasz Figa wrote:
> Hi Nishanth,
> 
> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
> > AM437x generation of processors support programming the PL310 L2Cache
> > controller's address filter start and end registers using a secure
> > montior service.
> 
> typo: s/montior/monitor/
> 
> [snip]

Uggh.. yes indeed. I will post a v3 updating the comments. If the
following is ok.
> 
> > +               base = omap4_get_l2cache_base();
> > +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
> > +                              readl_relaxed(base + L310_ADDR_FILTER_START);
> > +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
> > +                              readl_relaxed(base + L310_ADDR_FILTER_END);
> > +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
> > +                           filter_end);
> > +               return;
> 
> I don't have any significant comments about this patch in particular,
> but just noticed that you need to do read-backs here (and the typo
> thanks to the spell checker of my mailing app). Maybe you should
> consider switching to the .configure() API I introduced in my series?
> This would let you get rid of the hardcoded static mapping.

Yeah, I have two choices there.. Either I provide the fundamental
write function for the generic l2c code to use OR I provide a
duplicate of resultant l2c_configure(aux write) + l2c310_configure.

To allow for reuse of improvements or anything like errata
implementations in the future, OMAP L2C implementation has chosen to provide the
low level code and allow the higherlevel configure/write/whatever of the
future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
not too complicated enough to warrant a replication of l2c310_configure.

So, I prefer the current implementation than providing a .configure
handler for outer_cache.configure from SoC level.

Let me know if anyone has a strong objection to this.

-- 
Regards,
Nishanth Menon

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

On 15:40-20150103, Tomasz Figa wrote:
> Hi Nishanth,
> 
> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
> > AM437x generation of processors support programming the PL310 L2Cache
> > controller's address filter start and end registers using a secure
> > montior service.
> 
> typo: s/montior/monitor/
> 
> [snip]

Uggh.. yes indeed. I will post a v3 updating the comments. If the
following is ok.
> 
> > +               base = omap4_get_l2cache_base();
> > +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
> > +                              readl_relaxed(base + L310_ADDR_FILTER_START);
> > +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
> > +                              readl_relaxed(base + L310_ADDR_FILTER_END);
> > +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
> > +                           filter_end);
> > +               return;
> 
> I don't have any significant comments about this patch in particular,
> but just noticed that you need to do read-backs here (and the typo
> thanks to the spell checker of my mailing app). Maybe you should
> consider switching to the .configure() API I introduced in my series?
> This would let you get rid of the hardcoded static mapping.

Yeah, I have two choices there.. Either I provide the fundamental
write function for the generic l2c code to use OR I provide a
duplicate of resultant l2c_configure(aux write) + l2c310_configure.

To allow for reuse of improvements or anything like errata
implementations in the future, OMAP L2C implementation has chosen to provide the
low level code and allow the higherlevel configure/write/whatever of the
future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
not too complicated enough to warrant a replication of l2c310_configure.

So, I prefer the current implementation than providing a .configure
handler for outer_cache.configure from SoC level.

Let me know if anyone has a strong objection to this.

-- 
Regards,
Nishanth Menon

Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.\

[Nishanth Menon]

On 15:42-20150103, Tomasz Figa wrote:
> Indeed, as I figured out in the original thread about this issue,
> additional patch fixing code unaffected by my series (besides changing
> the condition which triggers calling it) is necessary. Namely, the
> affected 4 registers need to be written using the write_sec wrapper,
> instead of using writel*() directly.
> 

Agreed. Would you like to post a patch (independent) of your series to address
this - sounds like a fix that should go in independent of your original
series.

-- 
Regards,
Nishanth Menon

[PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.\

[Nishanth Menon]

On 15:42-20150103, Tomasz Figa wrote:
> Indeed, as I figured out in the original thread about this issue,
> additional patch fixing code unaffected by my series (besides changing
> the condition which triggers calling it) is necessary. Namely, the
> affected 4 registers need to be written using the write_sec wrapper,
> instead of using writel*() directly.
> 

Agreed. Would you like to post a patch (independent) of your series to address
this - sounds like a fix that should go in independent of your original
series.

-- 
Regards,
Nishanth Menon

Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
> On 15:40-20150103, Tomasz Figa wrote:
>> Hi Nishanth,
>>
>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>> > AM437x generation of processors support programming the PL310 L2Cache
>> > controller's address filter start and end registers using a secure
>> > montior service.
>>
>> typo: s/montior/monitor/
>>
>> [snip]
>
> Uggh.. yes indeed. I will post a v3 updating the comments. If the
> following is ok.
>>
>> > +               base = omap4_get_l2cache_base();
>> > +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>> > +                              readl_relaxed(base + L310_ADDR_FILTER_START);
>> > +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>> > +                              readl_relaxed(base + L310_ADDR_FILTER_END);
>> > +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
>> > +                           filter_end);
>> > +               return;
>>
>> I don't have any significant comments about this patch in particular,
>> but just noticed that you need to do read-backs here (and the typo
>> thanks to the spell checker of my mailing app). Maybe you should
>> consider switching to the .configure() API I introduced in my series?
>> This would let you get rid of the hardcoded static mapping.
>
> Yeah, I have two choices there.. Either I provide the fundamental
> write function for the generic l2c code to use OR I provide a
> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>
> To allow for reuse of improvements or anything like errata
> implementations in the future, OMAP L2C implementation has chosen to provide the
> low level code and allow the higherlevel configure/write/whatever of the
> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
> not too complicated enough to warrant a replication of l2c310_configure.
>
> So, I prefer the current implementation than providing a .configure
> handler for outer_cache.configure from SoC level.
>
> Let me know if anyone has a strong objection to this.

Well, what l2c310_configure() does after my series is just writing the
registers. If they cannot be written normally (without some tricks
such as reading back other registers) then IMHO a separate function
should be provided.

This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
ask hypervisor to configure L2C) and what is used on Exynos which also
updates multiple registers in single SMC calls. You can find an
example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
callback for L2C-310). What's even more interesting is that approaches
similar to the one currently used on OMAP had been NAKed, when
proposed for Exynos and this is why we have the solution proposed by
my patches.

Note that .write_sec() callback is still used for L2X0_CTRL and
L2X0_DEBUG_CTRL registers, because there might be a need to write them
separately (e.g. to disable the controller and to perform debug
operations/workarounds when the controller is already enabled).

Best regards,
Tomasz

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
> On 15:40-20150103, Tomasz Figa wrote:
>> Hi Nishanth,
>>
>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>> > AM437x generation of processors support programming the PL310 L2Cache
>> > controller's address filter start and end registers using a secure
>> > montior service.
>>
>> typo: s/montior/monitor/
>>
>> [snip]
>
> Uggh.. yes indeed. I will post a v3 updating the comments. If the
> following is ok.
>>
>> > +               base = omap4_get_l2cache_base();
>> > +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>> > +                              readl_relaxed(base + L310_ADDR_FILTER_START);
>> > +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>> > +                              readl_relaxed(base + L310_ADDR_FILTER_END);
>> > +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
>> > +                           filter_end);
>> > +               return;
>>
>> I don't have any significant comments about this patch in particular,
>> but just noticed that you need to do read-backs here (and the typo
>> thanks to the spell checker of my mailing app). Maybe you should
>> consider switching to the .configure() API I introduced in my series?
>> This would let you get rid of the hardcoded static mapping.
>
> Yeah, I have two choices there.. Either I provide the fundamental
> write function for the generic l2c code to use OR I provide a
> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>
> To allow for reuse of improvements or anything like errata
> implementations in the future, OMAP L2C implementation has chosen to provide the
> low level code and allow the higherlevel configure/write/whatever of the
> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
> not too complicated enough to warrant a replication of l2c310_configure.
>
> So, I prefer the current implementation than providing a .configure
> handler for outer_cache.configure from SoC level.
>
> Let me know if anyone has a strong objection to this.

Well, what l2c310_configure() does after my series is just writing the
registers. If they cannot be written normally (without some tricks
such as reading back other registers) then IMHO a separate function
should be provided.

This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
ask hypervisor to configure L2C) and what is used on Exynos which also
updates multiple registers in single SMC calls. You can find an
example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
callback for L2C-310). What's even more interesting is that approaches
similar to the one currently used on OMAP had been NAKed, when
proposed for Exynos and this is why we have the solution proposed by
my patches.

Note that .write_sec() callback is still used for L2X0_CTRL and
L2X0_DEBUG_CTRL registers, because there might be a need to write them
separately (e.g. to disable the controller and to perform debug
operations/workarounds when the controller is already enabled).

Best regards,
Tomasz

Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

On 01/03/2015 10:16 AM, Tomasz Figa wrote:
> 2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
>> On 15:40-20150103, Tomasz Figa wrote:
>>> Hi Nishanth,
>>>
>>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>> AM437x generation of processors support programming the PL310 L2Cache
>>>> controller's address filter start and end registers using a secure
>>>> montior service.
>>>
>>> typo: s/montior/monitor/
>>>
>>> [snip]
>>
>> Uggh.. yes indeed. I will post a v3 updating the comments. If the
>> following is ok.
>>>
>>>> +               base = omap4_get_l2cache_base();
>>>> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>>>> +                              readl_relaxed(base + L310_ADDR_FILTER_START);
>>>> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>>>> +                              readl_relaxed(base + L310_ADDR_FILTER_END);
>>>> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
>>>> +                           filter_end);
>>>> +               return;
>>>
>>> I don't have any significant comments about this patch in particular,
>>> but just noticed that you need to do read-backs here (and the typo
>>> thanks to the spell checker of my mailing app). Maybe you should
>>> consider switching to the .configure() API I introduced in my series?
>>> This would let you get rid of the hardcoded static mapping.
>>
>> Yeah, I have two choices there.. Either I provide the fundamental
>> write function for the generic l2c code to use OR I provide a
>> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>>
>> To allow for reuse of improvements or anything like errata
>> implementations in the future, OMAP L2C implementation has chosen to provide the
>> low level code and allow the higherlevel configure/write/whatever of the
>> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
>> not too complicated enough to warrant a replication of l2c310_configure.
>>
>> So, I prefer the current implementation than providing a .configure
>> handler for outer_cache.configure from SoC level.
>>
>> Let me know if anyone has a strong objection to this.
>
> Well, what l2c310_configure() does after my series is just writing the
> registers. If they cannot be written normally (without some tricks
> such as reading back other registers) then IMHO a separate function
> should be provided.
>
> This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
> ask hypervisor to configure L2C) and what is used on Exynos which also
> updates multiple registers in single SMC calls. You can find an
> example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
> callback for L2C-310). What's even more interesting is that approaches
> similar to the one currently used on OMAP had been NAKed, when
> proposed for Exynos and this is why we have the solution proposed by
> my patches.
>
> Note that .write_sec() callback is still used for L2X0_CTRL and
> L2X0_DEBUG_CTRL registers, because there might be a need to write them
> separately (e.g. to disable the controller and to perform debug
> operations/workarounds when the controller is already enabled).


we dont have a machine descriptor for configure instead we overide the 
logic(in you case after firmware load, in OMAP case, I need to figure 
out). my point being unlike the exynos configure code, OMAP code will 
look exactly like current pl310_configure-2 lines of code which really 
does not benefit anything.


Thinking again, in fact, i'd rather drop this series than have to do a 
duplicated configure code(and force a resultant maintenance for the 
future) in OMAP code since none of OMAP4 or AM437x series need these 
patches. Interest for this series was non-mandatory, but just to be 
complete from SoC definition point of view.

Let me know which way you guys want me to go.

---
Regards,
Nishanth Menon

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Nishanth Menon]

On 01/03/2015 10:16 AM, Tomasz Figa wrote:
> 2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
>> On 15:40-20150103, Tomasz Figa wrote:
>>> Hi Nishanth,
>>>
>>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>> AM437x generation of processors support programming the PL310 L2Cache
>>>> controller's address filter start and end registers using a secure
>>>> montior service.
>>>
>>> typo: s/montior/monitor/
>>>
>>> [snip]
>>
>> Uggh.. yes indeed. I will post a v3 updating the comments. If the
>> following is ok.
>>>
>>>> +               base = omap4_get_l2cache_base();
>>>> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>>>> +                              readl_relaxed(base + L310_ADDR_FILTER_START);
>>>> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>>>> +                              readl_relaxed(base + L310_ADDR_FILTER_END);
>>>> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX, filter_start,
>>>> +                           filter_end);
>>>> +               return;
>>>
>>> I don't have any significant comments about this patch in particular,
>>> but just noticed that you need to do read-backs here (and the typo
>>> thanks to the spell checker of my mailing app). Maybe you should
>>> consider switching to the .configure() API I introduced in my series?
>>> This would let you get rid of the hardcoded static mapping.
>>
>> Yeah, I have two choices there.. Either I provide the fundamental
>> write function for the generic l2c code to use OR I provide a
>> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>>
>> To allow for reuse of improvements or anything like errata
>> implementations in the future, OMAP L2C implementation has chosen to provide the
>> low level code and allow the higherlevel configure/write/whatever of the
>> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
>> not too complicated enough to warrant a replication of l2c310_configure.
>>
>> So, I prefer the current implementation than providing a .configure
>> handler for outer_cache.configure from SoC level.
>>
>> Let me know if anyone has a strong objection to this.
>
> Well, what l2c310_configure() does after my series is just writing the
> registers. If they cannot be written normally (without some tricks
> such as reading back other registers) then IMHO a separate function
> should be provided.
>
> This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
> ask hypervisor to configure L2C) and what is used on Exynos which also
> updates multiple registers in single SMC calls. You can find an
> example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
> callback for L2C-310). What's even more interesting is that approaches
> similar to the one currently used on OMAP had been NAKed, when
> proposed for Exynos and this is why we have the solution proposed by
> my patches.
>
> Note that .write_sec() callback is still used for L2X0_CTRL and
> L2X0_DEBUG_CTRL registers, because there might be a need to write them
> separately (e.g. to disable the controller and to perform debug
> operations/workarounds when the controller is already enabled).


we dont have a machine descriptor for configure instead we overide the 
logic(in you case after firmware load, in OMAP case, I need to figure 
out). my point being unlike the exynos configure code, OMAP code will 
look exactly like current pl310_configure-2 lines of code which really 
does not benefit anything.


Thinking again, in fact, i'd rather drop this series than have to do a 
duplicated configure code(and force a resultant maintenance for the 
future) in OMAP code since none of OMAP4 or AM437x series need these 
patches. Interest for this series was non-mandatory, but just to be 
complete from SoC definition point of view.

Let me know which way you guys want me to go.

---
Regards,
Nishanth Menon

Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

2015-01-04 1:45 GMT+09:00 Nishanth Menon <nm@ti.com>:
> On 01/03/2015 10:16 AM, Tomasz Figa wrote:
>>
>> 2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>
>>> On 15:40-20150103, Tomasz Figa wrote:
>>>>
>>>> Hi Nishanth,
>>>>
>>>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>>>
>>>>> AM437x generation of processors support programming the PL310 L2Cache
>>>>> controller's address filter start and end registers using a secure
>>>>> montior service.
>>>>
>>>>
>>>> typo: s/montior/monitor/
>>>>
>>>> [snip]
>>>
>>>
>>> Uggh.. yes indeed. I will post a v3 updating the comments. If the
>>> following is ok.
>>>>
>>>>
>>>>> +               base = omap4_get_l2cache_base();
>>>>> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>>>>> +                              readl_relaxed(base +
>>>>> L310_ADDR_FILTER_START);
>>>>> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>>>>> +                              readl_relaxed(base +
>>>>> L310_ADDR_FILTER_END);
>>>>> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX,
>>>>> filter_start,
>>>>> +                           filter_end);
>>>>> +               return;
>>>>
>>>>
>>>> I don't have any significant comments about this patch in particular,
>>>> but just noticed that you need to do read-backs here (and the typo
>>>> thanks to the spell checker of my mailing app). Maybe you should
>>>> consider switching to the .configure() API I introduced in my series?
>>>> This would let you get rid of the hardcoded static mapping.
>>>
>>>
>>> Yeah, I have two choices there.. Either I provide the fundamental
>>> write function for the generic l2c code to use OR I provide a
>>> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>>>
>>> To allow for reuse of improvements or anything like errata
>>> implementations in the future, OMAP L2C implementation has chosen to
>>> provide the
>>> low level code and allow the higherlevel configure/write/whatever of the
>>> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
>>> not too complicated enough to warrant a replication of l2c310_configure.
>>>
>>> So, I prefer the current implementation than providing a .configure
>>> handler for outer_cache.configure from SoC level.
>>>
>>> Let me know if anyone has a strong objection to this.
>>
>>
>> Well, what l2c310_configure() does after my series is just writing the
>> registers. If they cannot be written normally (without some tricks
>> such as reading back other registers) then IMHO a separate function
>> should be provided.
>>
>> This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
>> ask hypervisor to configure L2C) and what is used on Exynos which also
>> updates multiple registers in single SMC calls. You can find an
>> example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
>> callback for L2C-310). What's even more interesting is that approaches
>> similar to the one currently used on OMAP had been NAKed, when
>> proposed for Exynos and this is why we have the solution proposed by
>> my patches.
>>
>> Note that .write_sec() callback is still used for L2X0_CTRL and
>> L2X0_DEBUG_CTRL registers, because there might be a need to write them
>> separately (e.g. to disable the controller and to perform debug
>> operations/workarounds when the controller is already enabled).
>
>
>
> we dont have a machine descriptor for configure instead we overide the
> logic(in you case after firmware load, in OMAP case, I need to figure out).
> my point being unlike the exynos configure code, OMAP code will look exactly
> like current pl310_configure-2 lines of code which really does not benefit
> anything.
>
>
> Thinking again, in fact, i'd rather drop this series than have to do a
> duplicated configure code(and force a resultant maintenance for the future)
> in OMAP code since none of OMAP4 or AM437x series need these patches.
> Interest for this series was non-mandatory, but just to be complete from SoC
> definition point of view.
>
> Let me know which way you guys want me to go.

Right, dropping this series would definitely solve the the read-back issue. :)

After all, if you don't need to override the latencies in the kernel
(i.e. have sane firmware, unlike certain Exynos boards ;)), then I
don't see a point of having this feature.

Best regards,
Tomasz

[PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming

[Tomasz Figa]

2015-01-04 1:45 GMT+09:00 Nishanth Menon <nm@ti.com>:
> On 01/03/2015 10:16 AM, Tomasz Figa wrote:
>>
>> 2015-01-04 0:34 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>
>>> On 15:40-20150103, Tomasz Figa wrote:
>>>>
>>>> Hi Nishanth,
>>>>
>>>> 2015-01-03 2:43 GMT+09:00 Nishanth Menon <nm@ti.com>:
>>>>>
>>>>> AM437x generation of processors support programming the PL310 L2Cache
>>>>> controller's address filter start and end registers using a secure
>>>>> montior service.
>>>>
>>>>
>>>> typo: s/montior/monitor/
>>>>
>>>> [snip]
>>>
>>>
>>> Uggh.. yes indeed. I will post a v3 updating the comments. If the
>>> following is ok.
>>>>
>>>>
>>>>> +               base = omap4_get_l2cache_base();
>>>>> +               filter_start = (reg == L310_ADDR_FILTER_START) ? val :
>>>>> +                              readl_relaxed(base +
>>>>> L310_ADDR_FILTER_START);
>>>>> +               filter_end = (reg == L310_ADDR_FILTER_END) ? val :
>>>>> +                              readl_relaxed(base +
>>>>> L310_ADDR_FILTER_END);
>>>>> +               omap_smc1_2(AM43X_MON_L2X0_SETFILTER_INDEX,
>>>>> filter_start,
>>>>> +                           filter_end);
>>>>> +               return;
>>>>
>>>>
>>>> I don't have any significant comments about this patch in particular,
>>>> but just noticed that you need to do read-backs here (and the typo
>>>> thanks to the spell checker of my mailing app). Maybe you should
>>>> consider switching to the .configure() API I introduced in my series?
>>>> This would let you get rid of the hardcoded static mapping.
>>>
>>>
>>> Yeah, I have two choices there.. Either I provide the fundamental
>>> write function for the generic l2c code to use OR I provide a
>>> duplicate of resultant l2c_configure(aux write) + l2c310_configure.
>>>
>>> To allow for reuse of improvements or anything like errata
>>> implementations in the future, OMAP L2C implementation has chosen to
>>> provide the
>>> low level code and allow the higherlevel configure/write/whatever of the
>>> future to stay in arch/arm/mm/cache-l2x0.c. The write_sec operation is
>>> not too complicated enough to warrant a replication of l2c310_configure.
>>>
>>> So, I prefer the current implementation than providing a .configure
>>> handler for outer_cache.configure from SoC level.
>>>
>>> Let me know if anyone has a strong objection to this.
>>
>>
>> Well, what l2c310_configure() does after my series is just writing the
>> registers. If they cannot be written normally (without some tricks
>> such as reading back other registers) then IMHO a separate function
>> should be provided.
>>
>> This is becomes possible after patch 3/8 (ARM: l2c: Add interface to
>> ask hypervisor to configure L2C) and what is used on Exynos which also
>> updates multiple registers in single SMC calls. You can find an
>> example of use in patch 6/8 (ARM: EXYNOS: Add .write_sec outer cache
>> callback for L2C-310). What's even more interesting is that approaches
>> similar to the one currently used on OMAP had been NAKed, when
>> proposed for Exynos and this is why we have the solution proposed by
>> my patches.
>>
>> Note that .write_sec() callback is still used for L2X0_CTRL and
>> L2X0_DEBUG_CTRL registers, because there might be a need to write them
>> separately (e.g. to disable the controller and to perform debug
>> operations/workarounds when the controller is already enabled).
>
>
>
> we dont have a machine descriptor for configure instead we overide the
> logic(in you case after firmware load, in OMAP case, I need to figure out).
> my point being unlike the exynos configure code, OMAP code will look exactly
> like current pl310_configure-2 lines of code which really does not benefit
> anything.
>
>
> Thinking again, in fact, i'd rather drop this series than have to do a
> duplicated configure code(and force a resultant maintenance for the future)
> in OMAP code since none of OMAP4 or AM437x series need these patches.
> Interest for this series was non-mandatory, but just to be complete from SoC
> definition point of view.
>
> Let me know which way you guys want me to go.

Right, dropping this series would definitely solve the the read-back issue. :)

After all, if you don't need to override the latencies in the kernel
(i.e. have sane firmware, unlike certain Exynos boards ;)), then I
don't see a point of having this feature.

Best regards,
Tomasz