[PATCH v10 4/7] Coresight: Introduce a new struct coresight_path

James Clark james.clark at linaro.org
Mon Feb 17 01:23:21 PST 2025



On 17/02/2025 1:14 am, Jie Gan wrote:
> 
> 
> On 2/14/2025 7:09 PM, James Clark wrote:
>>
>>
>> On 14/02/2025 1:34 am, Jie Gan wrote:
>>>
>>>
>>> On 2/14/2025 12:00 AM, James Clark wrote:
>>>>
>>>>
>>>> On 07/02/2025 6:42 am, Jie Gan wrote:
>>>>> Add 'struct coresight_path' to store the data that is needed by
>>>>> coresight_enable_path/coresight_disable_path. The structure will be
>>>>> transmitted to any required devices to enable related 
>>>>> funcationalities.
>>>>>
>>>>> The trace_id will be allocated after the path is built. Consequently,
>>>>> The ETM3x and ETM4x devices will directly read the trace_id from path
>>>>> which result in etm_read_alloc_trace_id and etm4_read_alloc_trace_id
>>>>> being deleted.
>>>>>
>>>>> Co-developed-by: James Clark <james.clark at linaro.org>
>>>>> Signed-off-by: James Clark <james.clark at linaro.org>
>>>>> Signed-off-by: Jie Gan <quic_jiegan at quicinc.com>
>>>>> ---
>>>>>   drivers/hwtracing/coresight/coresight-core.c  | 106 ++++++++++++ 
>>>>> +-----
>>>>>   drivers/hwtracing/coresight/coresight-dummy.c |   5 +-
>>>>>   .../hwtracing/coresight/coresight-etm-perf.c  |  30 +++--
>>>>>   .../hwtracing/coresight/coresight-etm-perf.h  |   2 +-
>>>>>   drivers/hwtracing/coresight/coresight-etm.h   |   1 -
>>>>>   .../coresight/coresight-etm3x-core.c          |  54 ++-------
>>>>>   .../coresight/coresight-etm4x-core.c          |  54 ++-------
>>>>>   drivers/hwtracing/coresight/coresight-etm4x.h |   1 -
>>>>>   drivers/hwtracing/coresight/coresight-priv.h  |  12 +-
>>>>>   drivers/hwtracing/coresight/coresight-stm.c   |   3 +-
>>>>>   drivers/hwtracing/coresight/coresight-sysfs.c |  17 ++-
>>>>>   drivers/hwtracing/coresight/coresight-tpdm.c  |   3 +-
>>>>>   include/linux/coresight.h                     |  12 +-
>>>>>   13 files changed, 143 insertions(+), 157 deletions(-)
>>>>>
>>>> [...]
>>>>> @@ -352,7 +352,7 @@ static void *etm_setup_aux(struct perf_event 
>>>>> *event, void **pages,
>>>>>        * CPUs, we can handle it and fail the session.
>>>>>        */
>>>>>       for_each_cpu(cpu, mask) {
>>>>> -        struct list_head *path;
>>>>> +        struct coresight_path *path;
>>>>>           struct coresight_device *csdev;
>>>>>           csdev = per_cpu(csdev_src, cpu);
>>>>> @@ -405,15 +405,15 @@ static void *etm_setup_aux(struct perf_event 
>>>>> *event, void **pages,
>>>>>               cpumask_clear_cpu(cpu, mask);
>>>>>               continue;
>>>>>           }
>>>>> -
>>>>>           /* ensure we can allocate a trace ID for this CPU */
>>>>> -        trace_id = coresight_trace_id_get_cpu_id_map(cpu, &sink- 
>>>>> >perf_sink_id_map);
>>>>> -        if (!IS_VALID_CS_TRACE_ID(trace_id)) {
>>>>> +        trace_id = coresight_path_assign_trace_id(path, 
>>>>> CS_MODE_PERF);
>>>>> +
>>>>> +        /* Can be 0 and valid, ETE doesn't need an ID */
>>>>> +        if (trace_id < 0) {
>>>>
>>>> Not sure why I wrote it like this, but I think we should leave it as 
>>>> it was with !IS_VALID_CS_TRACE_ID(). Even with ETE it calls the 
>>>> trace ID allocator, so nothing has changed here.
>>>>
>>> Sure, Will restore. For ETE or ETM, we dont need traverse the path, 
>>> just directly allocate the trace id based on cpu id.
>>>
>>> Jie
>>>
>>>
>>
>> Sorry I meant to only keep the !IS_VALID_CS_TRACE_ID() bit. We still 
>> need to call the new coresight_path_assign_trace_id() otherwise it 
>> doesn't get assigned to the path. I saw that got removed in v11.
>>
>>
> Sorry for the misunderstanding, I was focused on "nothing has changed 
> here", lol.
> 
> I got your point here.
> So the updated codes should be:
> ...
>                  /* ensure we can allocate a trace ID for this CPU */
>                  trace_id = coresight_path_assign_trace_id(path, 
> CS_MODE_PERF);
>                  if (!IS_VALID_CS_TRACE_ID(trace_id)) {
>                          cpumask_clear_cpu(cpu, mask);
>                          coresight_release_path(path);
>                          continue;
>                  }
> ...
> 
> 
> Thanks,
> Jie

Yes that looks good.




More information about the linux-arm-kernel mailing list