* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: Tony Lindgren, Russell King
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Santosh, Sekhar Nori, 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
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming
2015-01-02 17:43 ` Nishanth Menon
(?)
@ 2015-01-02 17:43 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: Tony Lindgren, Russell King
Cc: Nishanth Menon, Sekhar Nori, Tomasz Figa, linux-kernel, Santosh,
linux-omap, linux-arm-kernel, Marek Szyprowski
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: Tony Lindgren, Russell King
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Santosh, Sekhar Nori, 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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH V2 1/2] ARM: l2c: OMAP4/AM437x: Introduce support for cache latency programming
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-02 17:43 ` Nishanth Menon
(?)
@ 2015-01-02 17:43 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: Tony Lindgren, Russell King
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Santosh, Sekhar Nori, 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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: Tony Lindgren, Russell King
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Santosh, Sekhar Nori, 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
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-02 17:43 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-02 17:43 ` Nishanth Menon
@ 2015-01-03 6:40 ` Tomasz Figa
-1 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 6:40 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tony Lindgren, Russell King, linux-omap, linux-kernel,
linux-arm-kernel, Marek Szyprowski, Santosh, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-03 6:40 ` Tomasz Figa
0 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 6:40 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-03 6:40 ` Tomasz Figa
@ 2015-01-03 15:34 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 15:34 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tony Lindgren, Russell King, linux-omap, linux-kernel,
linux-arm-kernel, Marek Szyprowski, Santosh, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-03 15:34 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 15:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-03 15:34 ` Nishanth Menon
@ 2015-01-03 16:16 ` Tomasz Figa
-1 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 16:16 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tony Lindgren, Russell King, linux-omap, linux-kernel,
linux-arm-kernel, Marek Szyprowski, Santosh, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-03 16:16 ` Tomasz Figa
0 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 16:16 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-03 16:16 ` Tomasz Figa
@ 2015-01-03 16:45 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 16:45 UTC (permalink / raw)
To: Tomasz Figa
Cc: Russell King, Tony Lindgren, Sekhar Nori, linux-kernel, Santosh,
linux-omap, linux-arm-kernel, Marek Szyprowski
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-03 16:45 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 16:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
2015-01-03 16:45 ` Nishanth Menon
@ 2015-01-04 7:47 ` Tomasz Figa
-1 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-04 7:47 UTC (permalink / raw)
To: Nishanth Menon
Cc: Russell King, Tony Lindgren, Sekhar Nori, linux-kernel, Santosh,
linux-omap, linux-arm-kernel, Marek Szyprowski
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 2/2] ARM: l2c: AM437x: Introduce support for cache filter programming
@ 2015-01-04 7:47 ` Tomasz Figa
0 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-04 7:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
2015-01-02 17:43 ` Nishanth Menon
@ 2015-01-02 18:46 ` santosh.shilimkar at oracle.com
-1 siblings, 0 replies; 30+ messages in thread
From: santosh.shilimkar @ 2015-01-02 18:46 UTC (permalink / raw)
To: Nishanth Menon, Tony Lindgren, Russell King
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Santosh, Sekhar Nori
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 ;-)
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-02 18:46 ` santosh.shilimkar at oracle.com
0 siblings, 0 replies; 30+ messages in thread
From: santosh.shilimkar at oracle.com @ 2015-01-02 18:46 UTC (permalink / raw)
To: linux-arm-kernel
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 ;-)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
2015-01-02 18:46 ` santosh.shilimkar at oracle.com
(?)
@ 2015-01-02 19:47 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 19:47 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com, Tony Lindgren, Russell King,
Santosh
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-02 19:47 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 19:47 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com, Tony Lindgren, Russell King,
Santosh
Cc: linux-omap, linux-kernel, linux-arm-kernel, Marek Szyprowski,
Tomasz Figa, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-02 19:47 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-02 19:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
2015-01-02 19:47 ` Nishanth Menon
@ 2015-01-03 0:23 ` Tony Lindgren
-1 siblings, 0 replies; 30+ messages in thread
From: Tony Lindgren @ 2015-01-03 0:23 UTC (permalink / raw)
To: Nishanth Menon
Cc: santosh.shilimkar@oracle.com, Russell King, Santosh, linux-omap,
linux-kernel, linux-arm-kernel, Marek Szyprowski, Tomasz Figa,
Sekhar Nori
* 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-03 0:23 ` Tony Lindgren
0 siblings, 0 replies; 30+ messages in thread
From: Tony Lindgren @ 2015-01-03 0:23 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
2015-01-03 0:23 ` Tony Lindgren
@ 2015-01-03 6:42 ` Tomasz Figa
-1 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 6:42 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, santosh.shilimkar@oracle.com, Russell King,
Santosh, linux-omap, linux-kernel, linux-arm-kernel,
Marek Szyprowski, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.
@ 2015-01-03 6:42 ` Tomasz Figa
0 siblings, 0 replies; 30+ messages in thread
From: Tomasz Figa @ 2015-01-03 6:42 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.\
2015-01-03 6:42 ` Tomasz Figa
@ 2015-01-03 15:39 ` Nishanth Menon
-1 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 15:39 UTC (permalink / raw)
To: Tomasz Figa
Cc: Tony Lindgren, santosh.shilimkar@oracle.com, Russell King,
Santosh, linux-omap, linux-kernel, linux-arm-kernel,
Marek Szyprowski, Sekhar Nori
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH V2 0/2] ARM: l2c: OMAP4/AM437x: Additional register programming support.\
@ 2015-01-03 15:39 ` Nishanth Menon
0 siblings, 0 replies; 30+ messages in thread
From: Nishanth Menon @ 2015-01-03 15:39 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread