From: Mao Jinlong <hidden> Date: 2021-12-09 14:16:22
This series adds support for the trace performance monitoring and
diagnostics hardware (TPDM and TPDA). It is composed of two major
elements.
a) Changes for original coresight framework to support for TPDM and TPDA.
b) Add driver code for TPDM and TPDA.
Introduction of changes for original coresight framework
Support TPDM as new coresight source.
Since only STM and ETM are supported as coresight source originally.
TPDM is a newly added coresight source. We need to change
the original way of saving coresight path to support more types source
for coresight driver.
The following patch is to add support more coresight sources.
Use IDR to maintain all the enabled sources' paths.
Introduction of TPDM and TPDA
TPDM - The trace performance monitoring and diagnostics monitor or TPDM in
short serves as data collection component for various dataset types
specified in the QPMDA(Qualcomm performance monitoring and diagnostics
architecture) spec. The primary use case of the TPDM is to collect data
from different data sources and send it to a TPDA for packetization,
timestamping and funneling.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware definitions
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
docs: sysfs: coresight: Add sysfs ABI documentation for TPDM
TPDA - The trace performance monitoring and diagnostics aggregator or
TPDA in short serves as an arbitration and packetization engine for the
performance monitoring and diagnostics network as specified in the QPMDA
(Qualcomm performance monitoring and diagnostics architecture)
specification. The primary use case of the TPDA is to provide
packetization, funneling and timestamping of Monitor data as specified
in the QPMDA specification.
The following patch is to add driver for TPDA.
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
The last patch of this series is a device tree modification, which add
the TPDM and TPDA configuration to device tree for validating.
ARM: dts: msm: Add coresight components for SM8250
Once this series patches are applied properly, the tpdm and tpda nodes
should be observed at the coresight path /sys/bus/coresight/devices
e.g.
/sys/bus/coresight/devices # ls -l | grep tpd
tpda0 -> ../../../devices/platform/soc@0/6004000.tpda/tpda0
tpdm0 -> ../../../devices/platform/soc@0/6c08000.mm.tpdm/tpdm0
We can use the commands are similar to the below to validate TPDMs.
Enable coresight sink first.
echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
The test data will be collected in the coresight sink which is enabled.
If rwp register of the sink is keeping updating when do
integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data
generated from TPDM to sink.
Changes from V1:
1. Use IDR to store the path of sources. (Mathieu Poirier)
2. Only add integration_test/enable/disable for TPDM. No other configs.
(Mathieu Poirier)
3. Move coresight dtsi changes to sm8250.dtsi. (Suzuki K Poulose)
Mao Jinlong (9):
Use IDR to maintain all the enabled sources' paths.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware definitions
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
docs: sysfs: coresight: Add sysfs ABI documentation for TPDM
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
ARM: dts: msm: Add coresight components for SM8250
.../testing/sysfs-bus-coresight-devices-tpdm | 12 +
.../bindings/arm/coresight-tpda.yaml | 131 ++++
.../bindings/arm/coresight-tpdm.yaml | 83 +++
.../devicetree/bindings/arm/coresight.txt | 7 +
MAINTAINERS | 13 +
.../arm64/boot/dts/qcom/sm8250-coresight.dtsi | 688 ++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +
drivers/hwtracing/coresight/Kconfig | 33 +
drivers/hwtracing/coresight/Makefile | 2 +
drivers/hwtracing/coresight/coresight-core.c | 79 +-
drivers/hwtracing/coresight/coresight-tpda.c | 201 +++++
drivers/hwtracing/coresight/coresight-tpda.h | 33 +
drivers/hwtracing/coresight/coresight-tpdm.c | 262 +++++++
drivers/hwtracing/coresight/coresight-tpdm.h | 62 ++
include/linux/coresight.h | 1 +
15 files changed, 1558 insertions(+), 51 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
create mode 100644 Documentation/devicetree/bindings/arm/coresight-tpda.yaml
create mode 100644 Documentation/devicetree/bindings/arm/coresight-tpdm.yaml
create mode 100644 arch/arm64/boot/dts/qcom/sm8250-coresight.dtsi
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.h
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.h
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mao Jinlong <hidden> Date: 2021-12-09 14:16:32
Use hash length of the source's device name to map to the pointer
of the enabled path. Using IDR will be more efficient than using
the list. And there could be other sources except STM and CPU etms
in the new HWs. It is better to maintain all the paths together.
Signed-off-by: Mao Jinlong <redacted>
---
drivers/hwtracing/coresight/coresight-core.c | 76 +++++++-------------
1 file changed, 26 insertions(+), 50 deletions(-)
@@ -1088,10 +1081,11 @@ static int coresight_validate_source(struct coresight_device *csdev,intcoresight_enable(structcoresight_device*csdev){-intcpu,ret=0;+intret=0;structcoresight_device*sink;structlist_head*path;enumcoresight_dev_subtype_sourcesubtype;+u32hash;subtype=csdev->subtype.source_subtype;
@@ -1133,26 +1127,14 @@ int coresight_enable(struct coresight_device *csdev)if(ret)gotoerr_source;-switch(subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-/*-*WhenworkingfromsysFSitisimportanttokeeptrack-*ofthepathsthatwerecreatedsothattheycanbe-*undonein'coresight_disable()'.Sincetherecanonly-*beasinglesessionpertracer(whenworkingfromsysFS)-*aper-cpuvariablewilldojustfine.-*/-cpu=source_ops(csdev)->cpu_id(csdev);-per_cpu(tracer_path,cpu)=path;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-stm_path=path;-break;-default:-/* We can't be here */-break;-}-+/*+*Usethehashlengthofsource'sdevicenameasID+*andmaptheIDtothepointerofthepath.+*/+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+ret=idr_alloc_u32(&path_idr,path,&hash,hash,GFP_KERNEL);+if(ret)+gotoerr_source;out:mutex_unlock(&coresight_mutex);returnret;
@@ -1180,21 +1163,13 @@ void coresight_disable(struct coresight_device *csdev)if(!csdev->enable||!coresight_disable_source(csdev))gotoout;-switch(csdev->subtype.source_subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-cpu=source_ops(csdev)->cpu_id(csdev);-path=per_cpu(tracer_path,cpu);-per_cpu(tracer_path,cpu)=NULL;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-path=stm_path;-stm_path=NULL;-break;-default:-/* We can't be here */-break;-}+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+/* Find the path by the hash length. */+path=idr_find(&path_idr,hash);+if(path==NULL)+return;+idr_remove(&path_idr,hash);coresight_disable_path(path);coresight_release_path(path);
@@ -1779,6 +1754,7 @@ static int __init coresight_init(void)staticvoid__exitcoresight_exit(void){+idr_destroy(&path_idr);cscfg_exit();etm_perf_exit();bus_unregister(&coresight_bustype);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Mao,
On Thu, Dec 09, 2021 at 10:15:35PM +0800, Mao Jinlong wrote:
quoted hunk
Use hash length of the source's device name to map to the pointer
of the enabled path. Using IDR will be more efficient than using
the list. And there could be other sources except STM and CPU etms
in the new HWs. It is better to maintain all the paths together.
Signed-off-by: Mao Jinlong <redacted>
---
drivers/hwtracing/coresight/coresight-core.c | 76 +++++++-------------
1 file changed, 26 insertions(+), 50 deletions(-)
@@ -1088,10 +1081,11 @@ static int coresight_validate_source(struct coresight_device *csdev,intcoresight_enable(structcoresight_device*csdev){-intcpu,ret=0;+intret=0;structcoresight_device*sink;structlist_head*path;enumcoresight_dev_subtype_sourcesubtype;+u32hash;subtype=csdev->subtype.source_subtype;
@@ -1133,26 +1127,14 @@ int coresight_enable(struct coresight_device *csdev)if(ret)gotoerr_source;-switch(subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-/*-*WhenworkingfromsysFSitisimportanttokeeptrack-*ofthepathsthatwerecreatedsothattheycanbe-*undonein'coresight_disable()'.Sincetherecanonly-*beasinglesessionpertracer(whenworkingfromsysFS)-*aper-cpuvariablewilldojustfine.-*/-cpu=source_ops(csdev)->cpu_id(csdev);-per_cpu(tracer_path,cpu)=path;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-stm_path=path;-break;-default:-/* We can't be here */-break;-}-+/*+*Usethehashlengthofsource'sdevicenameasID+*andmaptheIDtothepointerofthepath.+*/+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+ret=idr_alloc_u32(&path_idr,path,&hash,hash,GFP_KERNEL);+if(ret)+gotoerr_source;out:mutex_unlock(&coresight_mutex);returnret;
@@ -1180,21 +1163,13 @@ void coresight_disable(struct coresight_device *csdev)if(!csdev->enable||!coresight_disable_source(csdev))gotoout;-switch(csdev->subtype.source_subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-cpu=source_ops(csdev)->cpu_id(csdev);-path=per_cpu(tracer_path,cpu);-per_cpu(tracer_path,cpu)=NULL;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-path=stm_path;-stm_path=NULL;-break;-default:-/* We can't be here */-break;-}+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+/* Find the path by the hash length. */+path=idr_find(&path_idr,hash);+if(path==NULL)+return;
Please add a dev_err() here as this should really not be happening.
From: Jinlong Mao <hidden> Date: 2021-12-15 16:01:19
Hi Mathieu,
Thanks for the review.
On 12/15/2021 2:30 AM, Mathieu Poirier wrote:
Hi Mao,
On Thu, Dec 09, 2021 at 10:15:35PM +0800, Mao Jinlong wrote:
quoted
Use hash length of the source's device name to map to the pointer
of the enabled path. Using IDR will be more efficient than using
the list. And there could be other sources except STM and CPU etms
in the new HWs. It is better to maintain all the paths together.
Signed-off-by: Mao Jinlong <redacted>
---
drivers/hwtracing/coresight/coresight-core.c | 76 +++++++-------------
1 file changed, 26 insertions(+), 50 deletions(-)
@@ -1088,10 +1081,11 @@ static int coresight_validate_source(struct coresight_device *csdev,intcoresight_enable(structcoresight_device*csdev){-intcpu,ret=0;+intret=0;structcoresight_device*sink;structlist_head*path;enumcoresight_dev_subtype_sourcesubtype;+u32hash;subtype=csdev->subtype.source_subtype;
@@ -1133,26 +1127,14 @@ int coresight_enable(struct coresight_device *csdev)if(ret)gotoerr_source;-switch(subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-/*-*WhenworkingfromsysFSitisimportanttokeeptrack-*ofthepathsthatwerecreatedsothattheycanbe-*undonein'coresight_disable()'.Sincetherecanonly-*beasinglesessionpertracer(whenworkingfromsysFS)-*aper-cpuvariablewilldojustfine.-*/-cpu=source_ops(csdev)->cpu_id(csdev);-per_cpu(tracer_path,cpu)=path;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-stm_path=path;-break;-default:-/* We can't be here */-break;-}-+/*+*Usethehashlengthofsource'sdevicenameasID+*andmaptheIDtothepointerofthepath.+*/+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+ret=idr_alloc_u32(&path_idr,path,&hash,hash,GFP_KERNEL);+if(ret)+gotoerr_source;out:mutex_unlock(&coresight_mutex);returnret;
@@ -1180,21 +1163,13 @@ void coresight_disable(struct coresight_device *csdev)if(!csdev->enable||!coresight_disable_source(csdev))gotoout;-switch(csdev->subtype.source_subtype){-caseCORESIGHT_DEV_SUBTYPE_SOURCE_PROC:-cpu=source_ops(csdev)->cpu_id(csdev);-path=per_cpu(tracer_path,cpu);-per_cpu(tracer_path,cpu)=NULL;-break;-caseCORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE:-path=stm_path;-stm_path=NULL;-break;-default:-/* We can't be here */-break;-}+hash=hashlen_hash(hashlen_string(NULL,dev_name(&csdev->dev)));+/* Find the path by the hash length. */+path=idr_find(&path_idr,hash);+if(path==NULL)+return;
Please add a dev_err() here as this should really not be happening.
@@ -15560,6 +15560,14 @@ L: netdev@vger.kernel.org S: Supported F: drivers/net/ipa/+QCOM CORESIGHT COMPONENTS DRIVER+M: Tao Zhang <quic_taozha@quicinc.com>+M: Jinlong Mao <quic_jinlmao@quicinc.com>+M: Mathieu Poirier <mathieu.poirier@linaro.org>+M: Suzuki K Poulose <suzuki.poulose@arm.com>+S: Maintained+F: drivers/hwtracing/coresight/coresight-tpdm.c+
There is no need for an extra entry in the MAINTAINERS file. The checkpatch.pl
script is smart enough to know when to CC you and Tao every time the TPDM/TPDA
drivers are modified. Suzuki and I will simply wait for you guys to add your RB
tags before reviewing the patches. I have explained this in the previous revision.
quoted hunk
QEMU MACHINE EMULATOR AND VIRTUALIZER SUPPORT
M: Gabriel Somlo [off-list ref]
M: "Michael S. Tsirkin" [off-list ref]
Is this available on 32bit HW as well? If not please make it dependent on ARM64
as it for ETMv4x devices.
quoted hunk
+ help
+ This driver provides support for configuring monitor. Monitors are
+ primarily responsible for data set collection and support the
+ ability to collect any permutation of data set types. Monitors are
+ also responsible for interaction with system cross triggering.
+
+ To compile this driver as a module, choose M here: the module will be
+ called coresight-tpdm.
+
endif
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
@@ -15560,6 +15560,14 @@ L: netdev@vger.kernel.org S: Supported F: drivers/net/ipa/+QCOM CORESIGHT COMPONENTS DRIVER+M: Tao Zhang <quic_taozha@quicinc.com>+M: Jinlong Mao <quic_jinlmao@quicinc.com>+M: Mathieu Poirier <mathieu.poirier@linaro.org>+M: Suzuki K Poulose <suzuki.poulose@arm.com>+S: Maintained+F: drivers/hwtracing/coresight/coresight-tpdm.c+
There is no need for an extra entry in the MAINTAINERS file. The checkpatch.pl
script is smart enough to know when to CC you and Tao every time the TPDM/TPDA
drivers are modified. Suzuki and I will simply wait for you guys to add your RB
tags before reviewing the patches. I have explained this in the previous revision.
Hi Mathieu,
I will remove this entry.
quoted
QEMU MACHINE EMULATOR AND VIRTUALIZER SUPPORT
M: Gabriel Somlo [off-list ref]
M: "Michael S. Tsirkin" [off-list ref]
Is this available on 32bit HW as well? If not please make it dependent on ARM64
as it for ETMv4x devices.
This is available on 32bit HW as well.
quoted
+ help
+ This driver provides support for configuring monitor. Monitors are
+ primarily responsible for data set collection and support the
+ ability to collect any permutation of data set types. Monitors are
+ also responsible for interaction with system cross triggering.
+
+ To compile this driver as a module, choose M here: the module will be
+ called coresight-tpdm.
+
endif
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
Thanks
Jinlong Mao
@@ -15560,6 +15560,14 @@ L: netdev@vger.kernel.org S: Supported F: drivers/net/ipa/+QCOM CORESIGHT COMPONENTS DRIVER+M: Tao Zhang <quic_taozha@quicinc.com>+M: Jinlong Mao <quic_jinlmao@quicinc.com>+M: Mathieu Poirier <mathieu.poirier@linaro.org>+M: Suzuki K Poulose <suzuki.poulose@arm.com>+S: Maintained+F: drivers/hwtracing/coresight/coresight-tpdm.c+
There is no need for an extra entry in the MAINTAINERS file. The checkpatch.pl
script is smart enough to know when to CC you and Tao every time the TPDM/TPDA
drivers are modified. Suzuki and I will simply wait for you guys to add your RB
tags before reviewing the patches. I have explained this in the previous revision.
Hi Mathieu,
I will remove this entry.
quoted
quoted
QEMU MACHINE EMULATOR AND VIRTUALIZER SUPPORT
M: Gabriel Somlo [off-list ref]
M: "Michael S. Tsirkin" [off-list ref]
Is this available on 32bit HW as well? If not please make it dependent on ARM64
as it for ETMv4x devices.
This is available on 32bit HW as well.
quoted
quoted
+ help
+ This driver provides support for configuring monitor. Monitors are
+ primarily responsible for data set collection and support the
+ ability to collect any permutation of data set types. Monitors are
+ also responsible for interaction with system cross triggering.
+
+ To compile this driver as a module, choose M here: the module will be
+ called coresight-tpdm.
+
endif
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
Regards
Mike
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
Yes, you are correct.
quoted
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
I need to clarify something with Mike on this - I will get back to you on
Monday.
quoted
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
Yes, you are correct.
quoted
quoted
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
I need to clarify something with Mike on this - I will get back to you on
Monday.
Do you have more comments on this ?
quoted
quoted
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
Yes, you are correct.
quoted
quoted
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
I need to clarify something with Mike on this - I will get back to you on
Monday.
Do you have more comments on this ?
I just received clarifications on this - there is no need to continue enacting
the current scheme and as such reserving bits following the above formula will
not be needed either. Simply assigning free traceIDs based on request will
work just fine.
That of course is taking into account that 0x0, 0x1 and 0x70 - 0x7f are
reserved. 0x1 is currently used for STM and should eventually be fixed to
simply request a traceID the same way any other component do. You can fix it as
part of this set but it is not mandatory.
Let me know if there are things I haven't been clear on.
Thanks,
Mathieu
quoted
quoted
quoted
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
Yes, you are correct.
quoted
quoted
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
I need to clarify something with Mike on this - I will get back to you on
Monday.
Do you have more comments on this ?
I just received clarifications on this - there is no need to continue enacting
the current scheme and as such reserving bits following the above formula will
not be needed either. Simply assigning free traceIDs based on request will
work just fine.
That of course is taking into account that 0x0, 0x1 and 0x70 - 0x7f are
reserved. 0x1 is currently used for STM and should eventually be fixed to
simply request a traceID the same way any other component do. You can fix it as
part of this set but it is not mandatory.
Let me know if there are things I haven't been clear on.
Thanks,
Mathieu
Hi Mathieu,
Do you mean ETM sources and other sources can share the same
"coresight_get_trace_id" function ?
int trace_id = 1;
int coresight_get_trace_id ()
{
trace_id += 1;
if (trace_id > 1 && trace_id < 0x70)
return trace_id;
else
return -EINVAL;
}
or do we still need a different function for other sources like use
"coresight_get_system_trace_id" ?
Return the id from 1 and skip the ids which equeals to
CORESIGHT_ETM_PMU_SEED + (cpu * 2).
Thanks
Jinlong Mao
quoted
quoted
quoted
quoted
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
I have been specific on how to properly do this in the last revision. Given the
above about the MAINTAINERS file, I am not sure that I will continue reviewing this set.
There is also no need to rush another revision as I won't have the bandwidth to
process it before the holidays.
Thanks,
Mathieu
Hi Mathieu,
Sorry, not addressed your previous comments here.
For the trace id, each coresight component has 7 bits to store the trace
id. So the trace id should be from 1 to 127 as 0 is invalid.
IDs 0x70 - 0x7F (`112 - 127 ) are reserved - see the ARM Coresight
Architecture specification v3.0
Correct
quoted
quoted
Apart from TPDMs/STM/ETMs, we also have other coresight components in
our internal device. About 80 ids are already used.
Some components have fixed trace id in HW. If we use functions below to
count the trace id, there will be conflict to other components.
Can we use 1-15 for etm trace ids and 16 - 127 for other coresight
components ? And handle trace ids in its' own driver ?
This will limit systems to 15 cores - some have more!
Correct
quoted
quoted
static inline int coresight_get_system_trace_id(int id)
{
/* Start system IDs above the highest per CPU trace ID. */
return coresigth_get_trace_id(cpumask_last(cpu_possible_mask) + 1);
}
Looking at my own suggestion again this won't work since it returns the same traceID
when called multiple times.
For this patchset and _without_ taking into account internal devices that have
their traceID set in HW:
1. Define a bitmask that is 7 bit wide.
Should it be a 128 bit wide bitmask (0--127)?
quoted
2. By default, set bits under 0x10 and between 0x70 - 0x7F.
3. In coresight_get_system_trace_id(), drop the @id parameter and allocate the
first available bit after cpumask_last(cpu_possible_mask) + 1.
Should it allocate the first available bit after (cpumask_last(cpu_possible_mask) *2 ) + 0x10 ?
Return the first zero bit position as the trace id and set the bit.
Please ignore my email from January 26th and proceed exactly as you stated
above.
I had conversations with Suzuki and Mike and providing an appropriate fix for this
issue needs more investigation.
Aplogies for the flip-flopping, as I said earlier this is a complex problem
we've been restling with for quite some time now.
Thanks,
Mathieu
quoted
4. Define a new function called coresight_put_system_trace_id(int id) that
clears the bit in the mask corresponding to @id.
For now that should work.
quoted
quoted
static inline int coresight_get_trace_id(int cpu)
{
/*
* A trace ID of value 0 is invalid, so let's start at some
* random value that fits in 7 bits and go from there. Since
* the common convention is to have data trace IDs be I(N) + 1,
* set instruction trace IDs as a function of the CPU number.
*/
return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
}
This fixed relationship between cpu and trace ID is used in the perf
tooling to populate the elements in the perf.data file to correctly
allow association between CPU and trace data, and thus allow correct
trace decode.
TraceIDs associated to CPUs are communicated to the perf tooling by way of the
perf header - theoretically we should be able to change the allocation scheme
without impacting the decoding process.
quoted
It should be possible to create another more dynamic mapping scheme -
but this must include a way to support the perf requirements too.
TraceIDs have been a lurking problem for as long as the subsystem has existed.
For now what I have suggested above should be sufficient to provide an
in-between solution that doesn't hold back this patchset.
That being said, we need to start thinking about the best way to do this. I
will put a patchset together in the new year that aims in that direction.
@@ -0,0 +1,83 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+# Copyright (c) 2021 Qualcomm Innovation Center, Inc. All rights reserved.+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/coresight-tpdm.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Trace, Profiling and Diagnostics Monitor - TPDM++description:|+The TPDM or Monitor serves as data collection component for various dataset+types specified in the QPMDA spec. It covers Implementation defined ((ImplDef),+Basic Counts (BC), Tenure Counts (TC), Continuous Multi-Bit (CMB), and Discrete+Single Bit (DSB). It performs data collection in the data producing clock+domain and transfers it to the data collection time domain, generally ATB+clock domain.++The primary use case of the TPDM is to collect data from different data+sources and send it to a TPDA for packetization, timestamping, and funneling.++maintainers:+-Tao Zhang <quic_taozha@quicinc.com>+-Mao Jinlong <quic_jinlmao@quicinc.com>+-Suzuki K Poulose <suzuki.poulose@arm.com>+-Mathieu Poirier <mathieu.poirier@linaro.org>++properties:+$nodename:+pattern:"^tpdm(@[0-9a-f]+)$"+compatible:+items:+-const:qcom,coresight-tpdm+-const:arm,primecell++reg:+maxItems:1++clocks:+maxItems:1++clock-names:+items:+-const:apb_pclk++out-ports:+description:|+Output connections from the TPDM to legacy CoreSight trace bus.+$ref:/schemas/graph.yaml#/properties/ports+properties:+port:+description:Output connection from the TPDM to legacy CoreSight+Trace bus.+$ref:/schemas/graph.yaml#/properties/port++required:+-compatible+-reg+-clocks+-clock-names++additionalProperties:false++examples:+# minimum TPDM definition.+-|+tpdm@6980000 {+compatible = "qcom,coresight-tpdm", "arm,primecell";+reg = <0x6980000 0x1000>;++clocks = <&aoss_qmp>;+clock-names = "apb_pclk";++out-ports {+port {+tpdm_turing_out_funnel_turing:endpoint {+remote-endpoint =+<&funnel_turing_in_tpdm_turing>;+};+};+};+};++...
@@ -52,6 +52,10 @@ its hardware characteristcs. "arm,coresight-cti", "arm,primecell"; See coresight-cti.yaml for full CTI definitions.+ - Trace, Profiling and Diagnostics Monitor (TPDM):+ "qcom,coresight-tpdm", "arm,primecell";+ See coresight-tpdm.yaml for full TPDM definitions.+ * reg: physical base address and length of the register set(s) of the component.
@@ -82,6 +86,9 @@ its hardware characteristcs. * Required properties for Coresight Cross Trigger Interface (CTI) See coresight-cti.yaml for full CTI definitions.+* Required properties for Trace, Profiling and Diagnostics Monitor (TPDM)+ See coresight-tpdm.yaml for full TPDM definitions.+ * Required properties for devices that don't show up on the AMBA bus, such as non-configurable replicators and non-configurable funnels:
From: Mao Jinlong <hidden> Date: 2021-12-09 14:17:01
TPDM serves as data collection component for various dataset types.
DSB(Discrete Single Bit) is one of the dataset types. DSB subunit
can be enabled for data collection by writing 1 to the first bit of
DSB_CR register. This change is to add enable/disable function for
DSB dataset by writing DSB_CR register.
Signed-off-by: Tao Zhang <redacted>
Signed-off-by: Mao Jinlong <redacted>
---
drivers/hwtracing/coresight/coresight-tpdm.c | 56 ++++++++++++++++++++
drivers/hwtracing/coresight/coresight-tpdm.h | 23 ++++++++
2 files changed, 79 insertions(+)
@@ -20,6 +20,27 @@DEFINE_CORESIGHT_DEVLIST(tpdm_devs,"tpdm");+staticvoidtpdm_enable_dsb(structtpdm_drvdata*drvdata)+{+u32val;++/* Set the enable bit of DSB control register to 1 */+val=readl_relaxed(drvdata->base+TPDM_DSB_CR);+val=val|BIT(0);+writel_relaxed(val,drvdata->base+TPDM_DSB_CR);+}++staticvoid_tpdm_enable(structtpdm_drvdata*drvdata)+{+CS_UNLOCK(drvdata->base);++/* Check if DSB datasets is present for TPDM. */+if(test_bit(TPDM_DS_DSB,drvdata->datasets))+tpdm_enable_dsb(drvdata);++CS_LOCK(drvdata->base);+}+staticinttpdm_enable(structcoresight_device*csdev,structperf_event*event,u32mode){
@@ -31,6 +52,7 @@ static int tpdm_enable(struct coresight_device *csdev,return-EBUSY;}+_tpdm_enable(drvdata);drvdata->enable=true;mutex_unlock(&drvdata->lock);
@@ -38,6 +60,28 @@ static int tpdm_enable(struct coresight_device *csdev,return0;}+staticvoidtpdm_disable_dsb(structtpdm_drvdata*drvdata)+{+u32val;++/* Set the enable bit of DSB control register to 0 */+val=readl_relaxed(drvdata->base+TPDM_DSB_CR);+val=val&~BIT(0);+writel_relaxed(val,drvdata->base+TPDM_DSB_CR);+}++staticvoid_tpdm_disable(structtpdm_drvdata*drvdata)+{+CS_UNLOCK(drvdata->base);++/* Check if DSB datasets is present for TPDM. */+if(test_bit(TPDM_DS_DSB,drvdata->datasets))+tpdm_disable_dsb(drvdata);++CS_LOCK(drvdata->base);++}+staticvoidtpdm_disable(structcoresight_device*csdev,structperf_event*event){
@@ -75,8 +120,19 @@ static const struct coresight_ops tpdm_cs_ops = {staticvoidtpdm_init_default_data(structtpdm_drvdata*drvdata){staticinttraceid=TPDM_TRACE_ID_START;+inti;+u32pidr;+CS_UNLOCK(drvdata->base);drvdata->traceid=traceid++;++/* Get the datasets present on the TPDM. */+pidr=readl_relaxed(drvdata->base+CORESIGHT_PERIPHIDR0);+for(i=0;i<TPDM_DATASETS;i++){+if(pidr&BIT(i))+__set_bit(i,drvdata->datasets);+}+CS_LOCK(drvdata->base);}staticinttpdm_probe(structamba_device*adev,conststructamba_id*id)
@@ -8,6 +8,27 @@/* Default value of the traceid */#define TPDM_TRACE_ID_START 128+/* The max number of the datasets that TPDM supports */+#define TPDM_DATASETS 7++/* DSB Subunit Registers */+#define TPDM_DSB_CR (0x780)++/**+*ThisenumisforPERIPHIDR0registerofTPDM.+*Thefields[6:0]ofPERIPHIDR0areusedtodeterminewhat+*interfacesandsubunitsarepresentonagivenTPDM.+*+*PERIPHIDR0[0]:Fixto1ifImplDefsubunitpresent,else0.+*NoTPDMsupportsImplDefsubunitnow.But+*thefirstbitofPERIPHIDR0isforImplDef+*subunitforinitialdesign.+*PERIPHIDR0[1]:Fixto1ifDSBsubunitpresent,else0.+*/+enumtpdm_dataset{+TPDM_DS_IMPLDEF,+TPDM_DS_DSB,+};/***structtpdm_drvdata-specificsassociatedtoanTPDMcomponent
@@ -0,0 +1,12 @@+What: /sys/bus/coresight/devices/<tpdm-name>/available_datasets+Date: December 2021+KernelVersion 5.16+Contact: Jinlong Mao or Tao Zhang+Description: (Read) Show available datasets for TPDM.++What: /sys/bus/coresight/devices/<tpdm-name>/integration_test+Date: December 2020+KernelVersion 5.16+Contact: Jinlong Mao or Tao Zhang+Description: (Write) Run integration test for tpdm.+
@@ -0,0 +1,12 @@+What: /sys/bus/coresight/devices/<tpdm-name>/available_datasets+Date: December 2021+KernelVersion 5.16+Contact: Jinlong Mao or Tao Zhang+Description: (Read) Show available datasets for TPDM.
Sorry, forgot to remove the document of available_datasets.
Please help to review first. I will update in next version.
quoted hunk
+
+What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
+Date: December 2020
+KernelVersion 5.16
+Contact: Jinlong Mao or Tao Zhang
+Description: (Write) Run integration test for tpdm.
+
@@ -0,0 +1,12 @@+What: /sys/bus/coresight/devices/<tpdm-name>/available_datasets+Date: December 2021+KernelVersion 5.16+Contact: Jinlong Mao or Tao Zhang
Just keep one name? I am not sure if we are adding multiple names for
other files.
+Description: (Read) Show available datasets for TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
+Date: December 2020
From: Jinlong Mao <hidden> Date: 2021-12-10 01:03:45
Hi Trilok,
Thanks for the review.
On 12/10/2021 2:34 AM, Trilok Soni wrote:
Hello Jinlong,
On 12/9/2021 6:15 AM, Mao Jinlong wrote:
quoted
Add API usage document for sysfs API in TPDM driver.
Signed-off-by: Mao Jinlong <redacted>
---
.../ABI/testing/sysfs-bus-coresight-devices-tpdm | 12 ++++++++++++
MAINTAINERS | 1 +
2 files changed, 13 insertions(+)
create mode 100644
Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
diff --git
a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
new file mode 100644
index 000000000000..fdd0bd0e1c33
@@ -0,0 +1,12 @@+What: /sys/bus/coresight/devices/<tpdm-name>/available_datasets+Date: December 2021+KernelVersion 5.16+Contact: Jinlong Mao or Tao Zhang
Just keep one name? I am not sure if we are adding multiple names for
other files.
Yes. available_datasets need to be removed here as there is no changes
for available_dataset.
I forgot to remove it after removing he available_dataset changes. I
will update in next version.
quoted
+Description: (Read) Show available datasets for TPDM.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
+Date: December 2020
@@ -0,0 +1,12 @@+What: /sys/bus/coresight/devices/<tpdm-name>/available_datasets+Date: December 2021+KernelVersion 5.16
5.16 already has all of the new features, so this will not make it into
that release.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -0,0 +1,201 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(c)2021QualcommInnovationCenter,Inc.Allrightsreserved.+*/++#include<linux/amba/bus.h>+#include<linux/bitmap.h>+#include<linux/coresight.h>+#include<linux/device.h>+#include<linux/err.h>+#include<linux/fs.h>+#include<linux/io.h>+#include<linux/kernel.h>+#include<linux/module.h>+#include<linux/of.h>+#include<linux/platform_device.h>++#include"coresight-priv.h"+#include"coresight-tpda.h"++DEFINE_CORESIGHT_DEVLIST(tpda_devs,"tpda");++/* Settings pre enabling port control register */+staticvoidtpda_enable_pre_port(structtpda_drvdata*drvdata)+{+u32val;++val=readl_relaxed(drvdata->base+TPDA_CR);+val|=(drvdata->atid<<6);+writel_relaxed(val,drvdata->base+TPDA_CR);+}++staticvoidtpda_enable_port(structtpda_drvdata*drvdata,intport)+{+u32val;++val=readl_relaxed(drvdata->base+TPDA_Pn_CR(port));+/* Enable the port */+val=val|BIT(0);+writel_relaxed(val,drvdata->base+TPDA_Pn_CR(port));+}++/* Settings post enabling port control register */+staticvoidtpda_enable_post_port(structtpda_drvdata*drvdata)+{+u32val;++val=readl_relaxed(drvdata->base+TPDA_SYNCR);+/* Clear the mode */+val=val&~BIT(12);+/* Program the counter value */+val=val|0xFFF;+writel_relaxed(val,drvdata->base+TPDA_SYNCR);+}++staticvoid_tpda_enable(structtpda_drvdata*drvdata,intport)+{+CS_UNLOCK(drvdata->base);++if(!drvdata->enable)+tpda_enable_pre_port(drvdata);++tpda_enable_port(drvdata,port);++if(!drvdata->enable)+tpda_enable_post_port(drvdata);++CS_LOCK(drvdata->base);+}++staticinttpda_enable(structcoresight_device*csdev,intinport,intoutport)+{+structtpda_drvdata*drvdata=dev_get_drvdata(csdev->dev.parent);++mutex_lock(&drvdata->lock);+_tpda_enable(drvdata,inport);+drvdata->enable=true;+mutex_unlock(&drvdata->lock);++dev_info(drvdata->dev,"TPDA inport %d enabled\n",inport);+return0;+}++staticvoid_tpda_disable(structtpda_drvdata*drvdata,intport)+{+u32val;++CS_UNLOCK(drvdata->base);++val=readl_relaxed(drvdata->base+TPDA_Pn_CR(port));+val=val&~BIT(0);+writel_relaxed(val,drvdata->base+TPDA_Pn_CR(port));++CS_LOCK(drvdata->base);+}++staticvoidtpda_disable(structcoresight_device*csdev,intinport,+intoutport)+{+structtpda_drvdata*drvdata=dev_get_drvdata(csdev->dev.parent);++mutex_lock(&drvdata->lock);+_tpda_disable(drvdata,inport);+drvdata->enable=false;+mutex_unlock(&drvdata->lock);++dev_info(drvdata->dev,"TPDA inport %d disabled\n",inport);+}++staticconststructcoresight_ops_linktpda_link_ops={+.enable=tpda_enable,+.disable=tpda_disable,+};++staticconststructcoresight_opstpda_cs_ops={+.link_ops=&tpda_link_ops,+};++staticinttpda_parse_of_data(structtpda_drvdata*drvdata)+{+intret;+structdevice_node*node=drvdata->dev->of_node;++ret=of_property_read_u32(node,"qcom,tpda-atid",&drvdata->atid);+if(ret){+dev_err(drvdata->dev,"TPDA ATID is not specified\n");+return-EINVAL;+}+return0;+}++staticinttpda_probe(structamba_device*adev,conststructamba_id*id)+{+intret;+structdevice*dev=&adev->dev;+structcoresight_platform_data*pdata;+structtpda_drvdata*drvdata;+structcoresight_descdesc={0};++desc.name=coresight_alloc_device_name(&tpda_devs,dev);+if(!desc.name)+return-ENOMEM;+pdata=coresight_get_platform_data(dev);+if(IS_ERR(pdata))+returnPTR_ERR(pdata);+adev->dev.platform_data=pdata;++drvdata=devm_kzalloc(dev,sizeof(*drvdata),GFP_KERNEL);+if(!drvdata)+return-ENOMEM;++drvdata->dev=&adev->dev;+dev_set_drvdata(dev,drvdata);++drvdata->base=devm_ioremap_resource(dev,&adev->res);+if(!drvdata->base)+return-ENOMEM;++mutex_init(&drvdata->lock);++ret=tpda_parse_of_data(drvdata);+if(ret)+returnret;++desc.type=CORESIGHT_DEV_TYPE_LINK;+desc.subtype.link_subtype=CORESIGHT_DEV_SUBTYPE_LINK_MERG;+desc.ops=&tpda_cs_ops;+desc.pdata=adev->dev.platform_data;+desc.dev=&adev->dev;+drvdata->csdev=coresight_register(&desc);+if(IS_ERR(drvdata->csdev))+returnPTR_ERR(drvdata->csdev);++pm_runtime_put(&adev->dev);++dev_dbg(drvdata->dev,"TPDA initialized\n");+return0;+}++staticstructamba_idtpda_ids[]={+{+.id=0x000f0f00,+.mask=0x000fff00,+},+{0,0},+};++staticstructamba_drivertpda_driver={+.drv={+.name="coresight-tpda",+.owner=THIS_MODULE,+.suppress_bind_attrs=true,+},+.probe=tpda_probe,+.id_table=tpda_ids,+};++module_amba_driver(tpda_driver);++MODULE_LICENSE("GPL v2");+MODULE_DESCRIPTION("Trace, Profiling & Diagnostic Aggregator driver");
@@ -0,0 +1,131 @@+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause+# Copyright (c) 2021 Qualcomm Innovation Center, Inc. All rights reserved.+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/coresight-tpda.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Trace, Profiling and Diagnostics Aggregator - TPDA++description:|+TPDAs are responsible for packetization and timestamping of data sets+utilizing the MIPI STPv2 packet protocol. Pulling data sets from one or+more attached TPDM and pushing the resultant (packetized) data out a+master ATB interface. Performing an arbitrated ATB interleaving (funneling)+task for free-flowing data from TPDM (i.e. CMB and DSB data set flows).++maintainers:+-Tao Zhang <quic_taozha@quicinc.com>+-Mao Jinlong <quic_jinlmao@quicinc.com>+-Suzuki K Poulose <suzuki.poulose@arm.com>+-Mathieu Poirier <mathieu.poirier@linaro.org>++properties:+$nodename:+pattern:"^tpda(@[0-9a-f]+)$"+compatible:+items:+-const:qcom,coresight-tpda+-const:arm,primecell++reg:+maxItems:1++qcom,tpda-atid:+$ref:/schemas/types.yaml#/definitions/uint32-array+maxItems:1+description:|+Use the ATID field for trace source identification. This allows+multiple TPDMs to be interleaved and formatted via the Coresight+trace formatter framing protocol and de-formatted/parsed on a host+or debugger.++clocks:+maxItems:1++clock-names:+items:+-const:apb_pclk++in-ports:+type:object+description:|+Input connections from TPDM to TPDA+$ref:/schemas/graph.yaml#/properties/ports++properties:+'#address-cells':+const:1++'#size-cells':+const:0++patternProperties:+"^port@[0-9a-f]+$":+type:object+required:+-reg++required:+-'#size-cells'+-'#address-cells'++out-ports:+type:object+description:|+Output connections from the TPDA to legacy CoreSight trace bus.+$ref:/schemas/graph.yaml#/properties/ports++properties:+port:+description:+Output connection from the TPDA to legacy CoreSight Trace bus.+$ref:/schemas/graph.yaml#/properties/port++required:+-compatible+-reg+-qcom,tpda-atid+-clocks+-clock-names+-in-ports+-out-ports++additionalProperties:false++examples:+# minimum tpda definition.+-|+tpda@6004000 {+compatible = "qcom,coresight-tpda", "arm,primecell";+reg = <0x6004000 0x1000>;++qcom,tpda-atid = <65>;++clocks = <&aoss_qmp>;+clock-names = "apb_pclk";++in-ports {+#address-cells = <1>;+#size-cells = <0>;++port@0 {+reg = <0>;+tpda_qdss_0_in_tpdm_dcc:endpoint {+remote-endpoint =+<&tpdm_dcc_out_tpda_qdss_0>;+};+};+};++out-ports {+port {+tpda_qdss_out_funnel_in0:endpoint {+remote-endpoint =+<&funnel_in0_in_tpda_qdss>;+};+};+};+};++...