[PATCH 0/2] Coresight Support for arm64

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Other than tracers, the coresight IP blocks are 64-bit ready.  This
would normally be a trivial addition had it not been for the first
patch that is adding cpu index lookup functionality.

The feature exists in the 32 world and the fact that it doesn't on
64 bit means that 1) nobody needed it as of yet or 2) people have found
a different way to proceed.

Please have a look and tell me what you think.

Many thanks,
Mathieu

Mathieu Poirier (2):
  arm64: adding cpu lookup functionality
  coresight: Adding coresight support to arm64

 arch/arm64/Kconfig.debug            | 48 +++++++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/smp_plat.h   | 12 ++++++++++
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 4 files changed, 62 insertions(+), 2 deletions(-)

-- 
1.9.1

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Aside from tracers, all currently supported coresight IP blocks
are 64 bit ready.  As such add the required symbol definition to
compile the framework and drivers.

Also fixing a couple of warnings picked up by the 64bit compiler.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/arm64/Kconfig.debug            | 48 +++++++++++++++++++++++++++++++++++++
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 3 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 5fdd6dce8061..77dfebbcbffe 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug

@@ -66,4 +66,52 @@ config DEBUG_SET_MODULE_RONX
           against certain classes of kernel exploits.
           If in doubt, say "N".
 
+menuconfig CORESIGHT
+	bool "CoreSight Tracing Support"
+	select ARM_AMBA
+	help
+	  This framework provides a kernel interface for the CoreSight debug
+	  and trace drivers to register themselves with. It's intended to build
+	  a topological view of the CoreSight components based on a DT
+	  specification and configure the right serie of components when a
+	  trace source gets enabled.
+
+if CORESIGHT
+config CORESIGHT_LINKS_AND_SINKS
+	bool "CoreSight Link and Sink drivers"
+	help
+	  This enables support for CoreSight link and sink drivers that are
+	  responsible for transporting and collecting the trace data
+	  respectively.  Link and sinks are dynamically aggregated with a trace
+	  entity at run time to form a complete trace path.
+
+config CORESIGHT_LINK_AND_SINK_TMC
+	bool "Coresight generic TMC driver"
+	depends on CORESIGHT_LINKS_AND_SINKS
+	help
+	  This enables support for the Trace Memory Controller driver.
+	  Depending on its configuration the device can act as a link (embedded
+	  trace router - ETR) or sink (embedded trace FIFO).  The driver
+	  complies with the generic implementation of the component without
+	  special enhancement or added features.
+
+config CORESIGHT_SINK_TPIU
+	bool "Coresight generic TPIU driver"
+	depends on CORESIGHT_LINKS_AND_SINKS
+	help
+	  This enables support for the Trace Port Interface Unit driver,
+	  responsible for bridging the gap between the on-chip coresight
+	  components and a trace for bridging the gap between the on-chip
+	  coresight components and a trace port collection engine, typically
+	  connected to an external host for use case capturing more traces than
+	  the on-board coresight memory can handle.
+
+config CORESIGHT_SINK_ETBV10
+	bool "Coresight ETBv1.0 driver"
+	depends on CORESIGHT_LINKS_AND_SINKS
+	help
+	  This enables support for the Embedded Trace Buffer version 1.0 driver
+	  that complies with the generic implementation of the component without
+	  special enhancement or added features.
+endif
 endmenu

diff --git a/drivers/coresight/coresight-etb10.c b/drivers/coresight/coresight-etb10.c
index c9acd406f0d0..aa47d31fe2a2 100644
--- a/drivers/coresight/coresight-etb10.c
+++ b/drivers/coresight/coresight-etb10.c

@@ -314,7 +314,7 @@ static ssize_t etb_read(struct file *file, char __user *data,
 	*ppos += len;
 
 	dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n",
-		__func__, len, (int) (depth * 4 - *ppos));
+		__func__, (int)len, (int)(depth * 4 - *ppos));
 	return len;
 }
 

diff --git a/drivers/coresight/coresight-tmc.c b/drivers/coresight/coresight-tmc.c
index 3ff232f9ddf7..d08460327bd2 100644
--- a/drivers/coresight/coresight-tmc.c
+++ b/drivers/coresight/coresight-tmc.c

@@ -534,7 +534,7 @@ static ssize_t tmc_read(struct file *file, char __user *data, size_t len,
 	*ppos += len;
 
 	dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n",
-		__func__, len, (int) (drvdata->size - *ppos));
+		__func__, (int)len, (int)(drvdata->size - *ppos));
 	return len;
 }
 

-- 
1.9.1

On Fri, Jan 30, 2015 at 10:54:26PM +0000, mathieu.poirier at linaro.org wrote:

Why does this need to be duplicated by each architecture wanting to make
use of coresight capabilities defined under drivers/coresight? Can't we
instead have this menuconfig and associated suboptions defined by a core
Kconfig file, then have HAVE_ARCH_CORESIGHT_TRACE or something which can
be selected by architectures wanting to make use of the framework?

Will

On 2 February 2015 at 06:45, Will Deacon [off-list ref] wrote:

On Fri, Jan 30, 2015 at 10:54:26PM +0000, mathieu.poirier at linaro.org wrote:

quoted

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Aside from tracers, all currently supported coresight IP blocks
are 64 bit ready.  As such add the required symbol definition to
compile the framework and drivers.

Also fixing a couple of warnings picked up by the 64bit compiler.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/arm64/Kconfig.debug            | 48 +++++++++++++++++++++++++++++++++++++
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 3 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 5fdd6dce8061..77dfebbcbffe 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug

@@ -66,4 +66,52 @@ config DEBUG_SET_MODULE_RONX
           against certain classes of kernel exploits.
           If in doubt, say "N".

+menuconfig CORESIGHT
+     bool "CoreSight Tracing Support"
+     select ARM_AMBA
+     help
+       This framework provides a kernel interface for the CoreSight debug
+       and trace drivers to register themselves with. It's intended to build
+       a topological view of the CoreSight components based on a DT
+       specification and configure the right serie of components when a
+       trace source gets enabled.

Why does this need to be duplicated by each architecture wanting to make
use of coresight capabilities defined under drivers/coresight? Can't we
instead have this menuconfig and associated suboptions defined by a core
Kconfig file, then have HAVE_ARCH_CORESIGHT_TRACE or something which can
be selected by architectures wanting to make use of the framework?

Will

"arch/arm/Kconfig.debug" and "arch/arm64/Kconfig.debug" already have a
fair amount of duplication so I wasn't sure if this is the approach
you guys wanted to take.  I agree that a common core Kconfig file
would make much more sense and I see a couple of ways to do this:

1) lib/Kconfig.debug being sourced by both arm/Kconfig.debug and
arm64/Kconfig.debug.  We can add a lib/Kconfig.coresight or
lib/Kconfig.arm and source them the same way.

2) Adding coresight entries to the Kconfig.debug made sense a while
back.  Maybe it is time to move them to drivers/coresight/Kconfig...
That way it would be easily accessible by both arm and arm64.

You may have ideas of your own too...

Thanks,
Mathieu

On Mon, Feb 02, 2015 at 10:06:16PM +0000, Mathieu Poirier wrote:

On 2 February 2015 at 06:45, Will Deacon [off-list ref] wrote:

quoted

On Fri, Jan 30, 2015 at 10:54:26PM +0000, mathieu.poirier at linaro.org wrote:

quoted

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Aside from tracers, all currently supported coresight IP blocks
are 64 bit ready.  As such add the required symbol definition to
compile the framework and drivers.

Also fixing a couple of warnings picked up by the 64bit compiler.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/arm64/Kconfig.debug            | 48 +++++++++++++++++++++++++++++++++++++
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 3 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 5fdd6dce8061..77dfebbcbffe 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug

@@ -66,4 +66,52 @@ config DEBUG_SET_MODULE_RONX
           against certain classes of kernel exploits.
           If in doubt, say "N".

+menuconfig CORESIGHT
+     bool "CoreSight Tracing Support"
+     select ARM_AMBA
+     help
+       This framework provides a kernel interface for the CoreSight debug
+       and trace drivers to register themselves with. It's intended to build
+       a topological view of the CoreSight components based on a DT
+       specification and configure the right serie of components when a
+       trace source gets enabled.

Why does this need to be duplicated by each architecture wanting to make
use of coresight capabilities defined under drivers/coresight? Can't we
instead have this menuconfig and associated suboptions defined by a core
Kconfig file, then have HAVE_ARCH_CORESIGHT_TRACE or something which can
be selected by architectures wanting to make use of the framework?

Will

"arch/arm/Kconfig.debug" and "arch/arm64/Kconfig.debug" already have a
fair amount of duplication so I wasn't sure if this is the approach
you guys wanted to take.  I agree that a common core Kconfig file
would make much more sense and I see a couple of ways to do this:

1) lib/Kconfig.debug being sourced by both arm/Kconfig.debug and
arm64/Kconfig.debug.  We can add a lib/Kconfig.coresight or
lib/Kconfig.arm and source them the same way.

2) Adding coresight entries to the Kconfig.debug made sense a while
back.  Maybe it is time to move them to drivers/coresight/Kconfig...
That way it would be easily accessible by both arm and arm64.

Since the C files and Makefile are in drivers/coresight/, it makes sense
to add a drivers/coresight/Kconfig that could be sourced from
arch/arm*/Kconfig (we do this with PCI for example).

-- 
Catalin

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Adding a lookup function allowing for quick and easy mapping
between processor HWID (as found, for example) in DT specifications
and the CPU index known to the kernel.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/arm64/include/asm/smp_plat.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/include/asm/smp_plat.h b/arch/arm64/include/asm/smp_plat.h
index 59e282311b58..8e4b011303b1 100644
--- a/arch/arm64/include/asm/smp_plat.h
+++ b/arch/arm64/include/asm/smp_plat.h

@@ -19,6 +19,7 @@
 #ifndef __ASM_SMP_PLAT_H
 #define __ASM_SMP_PLAT_H
 
+#include <linux/cpumask.h>
 #include <asm/types.h>
 
 struct mpidr_hash {

@@ -40,4 +41,15 @@ static inline u32 mpidr_hash_size(void)
 extern u64 __cpu_logical_map[NR_CPUS];
 #define cpu_logical_map(cpu)    __cpu_logical_map[cpu]
 
+static inline int get_logical_index(u64 mpidr)
+{
+	int cpu;
+
+	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+		if (cpu_logical_map(cpu) == mpidr)
+			return cpu;
+	return -EINVAL;
+}
+
+
 #endif /* __ASM_SMP_PLAT_H */

-- 
1.9.1

On Fri, Jan 30, 2015 at 10:54:25PM +0000, mathieu.poirier at linaro.org wrote:

Can you not achieve the same thing using arch_find_n_match_cpu_physical_id
in the coresight code?

Will

On 2 February 2015 at 06:50, Will Deacon [off-list ref] wrote:

On Fri, Jan 30, 2015 at 10:54:25PM +0000, mathieu.poirier at linaro.org wrote:

quoted

From: Mathieu Poirier <mathieu.poirier@linaro.org>

Adding a lookup function allowing for quick and easy mapping
between processor HWID (as found, for example) in DT specifications
and the CPU index known to the kernel.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
 arch/arm64/include/asm/smp_plat.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/include/asm/smp_plat.h b/arch/arm64/include/asm/smp_plat.h
index 59e282311b58..8e4b011303b1 100644
--- a/arch/arm64/include/asm/smp_plat.h
+++ b/arch/arm64/include/asm/smp_plat.h

@@ -19,6 +19,7 @@
 #ifndef __ASM_SMP_PLAT_H
 #define __ASM_SMP_PLAT_H

+#include <linux/cpumask.h>
 #include <asm/types.h>

 struct mpidr_hash {

@@ -40,4 +41,15 @@ static inline u32 mpidr_hash_size(void)
 extern u64 __cpu_logical_map[NR_CPUS];
 #define cpu_logical_map(cpu)    __cpu_logical_map[cpu]

+static inline int get_logical_index(u64 mpidr)
+{
+     int cpu;
+
+     for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+             if (cpu_logical_map(cpu) == mpidr)
+                     return cpu;
+     return -EINVAL;
+}

Can you not achieve the same thing using arch_find_n_match_cpu_physical_id
in the coresight code?

Will

I ended up using "of_get_cpu_node()", which uses
"arch_find_n_match_cpu_physical_id()".  Thanks for pointing this out.

Mathieu

On Fri, Jan 30, 2015 at 10:54:25PM +0000, mathieu.poirier at linaro.org wrote:

Are there some pending updates for of_coresight.c that aren't in
mainline yet? It looks like even with this the parsing would be broken
if /cpus/#address-cells is greater than 1 (as with juno.dts), and it'll
just assume CPU0 in that case.

It would be nicer if we instead had a CPU node to logical ID mapping
function in the core OF code. We already have the inverse with
of_get_cpu_node, so I assume the necessary infrastructure is already
there.

Mark.