| Message ID | 1422658466-23984-3-git-send-email-mathieu.poirier@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 2 February 2015 at 06:45, Will Deacon <will.deacon@arm.com> wrote: > On Fri, Jan 30, 2015 at 10:54:26PM +0000, mathieu.poirier@linaro.org wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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; }