On 1/15/21 2:36 AM, Anshuman Khandual wrote:


On 1/13/21 3:13 PM, Suzuki K Poulose wrote:
On 1/13/21 4:18 AM, Anshuman Khandual wrote:
Add support for dedicated sinks that are bound to individual CPUs. (e.g,
TRBE). To allow quicker access to the sink for a given CPU bound source,
keep a percpu array of the sink devices. Also, add support for building
a path to the CPU local sink from the ETM.

This adds a new percpu sink type CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM.
This new sink type is exclusively available and can only work with percpu
source type device CORESIGHT_DEV_SUBTYPE_SOURCE_PERCPU_PROC.

This defines a percpu structure that accommodates a single coresight_device
which can be used to store an initialized instance from a sink driver. As
these sinks are exclusively linked and dependent on corresponding percpu
sources devices, they should also be the default sink device during a perf
session.

Outwards device connections are scanned while establishing paths between a
source and a sink device. But such connections are not present for certain
percpu source and sink devices which are exclusively linked and dependent.
Build the path directly and skip connection scanning for such devices.

Cc: Mathieu Poirier <mathieu.poir...@linaro.org>
Cc: Mike Leach <mike.le...@linaro.org>
Cc: Suzuki K Poulose <suzuki.poul...@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khand...@arm.com>
---
   drivers/hwtracing/coresight/coresight-core.c | 14 ++++++++++++++
   include/linux/coresight.h                    | 12 ++++++++++++
   2 files changed, 26 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-core.c 
b/drivers/hwtracing/coresight/coresight-core.c
index 0062c89..b300606 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -23,6 +23,7 @@
   #include "coresight-priv.h"
     static DEFINE_MUTEX(coresight_mutex);
+DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
     /**
    * struct coresight_node - elements of a path, from source to sink
@@ -784,6 +785,13 @@ static int _coresight_build_path(struct coresight_device 
*csdev,
       if (csdev == sink)
           goto out;
   +    if (coresight_is_percpu_source(csdev) && coresight_is_percpu_sink(sink) 
&&
+        sink == per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev))) {
+        _coresight_build_path(sink, sink, path);
+        found = true;
+        goto out;
+    }
+
       /* Not a sink - recursively explore each port found on this element */
       for (i = 0; i < csdev->pdata->nr_outport; i++) {
           struct coresight_device *child_dev;
@@ -998,6 +1006,12 @@ coresight_find_default_sink(struct coresight_device 
*csdev)
   {
       int depth = 0;
   +    if (coresight_is_percpu_source(csdev)) {

On a system without per_cpu sink, this would reset the default sink for the 
source device
every single time and fallback to searching every single time.

Right.

So I think it would be better if did check if the def_sink was not set.
We could fold this into the case below may be. i.e,


     if (!csdev->def_sink) {
         if (coresight_is_percpu_source(csdev))
             csdev->def_sink = per_cpu(csdev_sink, 
source_ops(csdev)->cpu_id(csdev));
         if (!csdev->def_sink)            csdev->def_sink = 
coresight_find_sink(csdev, &depth);
     }

Otherwise looks good to me.

struct coresight_device *
coresight_find_default_sink(struct coresight_device *csdev)
{
         int depth = 0;

         /* look for a default sink if we have not found for this device */
         if (!csdev->def_sink) {
                 if (coresight_is_percpu_source(csdev))
                         csdev->def_sink = per_cpu(csdev_sink, 
source_ops(csdev)->cpu_id(csdev));
                 if (!csdev->def_sink)
                         csdev->def_sink = coresight_find_sink(csdev, &depth);
         }
         return csdev->def_sink;
}

Would this be better instead ? coresight_find_sink() is invoked both when the
source is not percpu (traditional coresight sources) and also as a fallback in
case a percpu sink is not found for the percpu source device.
Yes, this is exactly what I proposed above.

Cheers
Suzuki

Reply via email to