These tests record in a mode that includes kernel trace but look for
samples of a userspace process. This makes them sensitive to any kernel
compilation options that increase the amount of time spent in the
kernel. If the trace buffer is completely filled before userspace is
reached then the test will fail. Double the buffer size to fix this.
The other tests in the same file aren't sensitive to this for various
reasons, for example the iterate devices test filters by userspace
trace only. But in order to keep coverage of all the modes, increase the
buffer size rather than filtering by userspace for the basic tests.
Fixes: d1efa4a0a696 ("perf cs-etm: Add separate decode paths for timeless and per-thread modes")
Signed-off-by: James Clark <james.clark(a)arm.com>
---
tools/perf/tests/shell/test_arm_coresight.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh
index 65dd85207125..3302ea0b9672 100755
--- a/tools/perf/tests/shell/test_arm_coresight.sh
+++ b/tools/perf/tests/shell/test_arm_coresight.sh
@@ -188,7 +188,7 @@ arm_cs_etm_snapshot_test() {
arm_cs_etm_basic_test() {
echo "Recording trace with '$*'"
- perf record -o ${perfdata} "$@" -- ls > /dev/null 2>&1
+ perf record -o ${perfdata} "$@" -m,8M -- ls > /dev/null 2>&1
perf_script_branch_samples ls &&
perf_report_branch_samples ls &&
--
2.34.1
+ Greg
Hi Krzysztof,
On 30/03/2024 18:00, Krzysztof Kozlowski wrote:
> On 30/03/2024 18:58, Krzysztof Kozlowski wrote:
>>
>> On Tue, 26 Mar 2024 21:23:30 +0100, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>>
>>> Description
>>> ===========
>>> Modules registering driver with amba_driver_register() often forget to
>>> set .owner field.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [01/19] amba: store owner from modules with amba_driver_register()
>> (no commit info)
>
> Patchset applied here:
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt.git/log/?h=fo…
How do you plan to push this ? Given this affects most of the drivers/,
do you plan to send this to Greg ? We have changes in the coresight
tree that would conflict with this "tag" ( I haven't merged them yet,
but is in my local queue). I want to make sure we can avoid the
conflicts. I am happy to merge this to my local tree and base the
changes on this, if this is going in for v6.10 and all are in agreement.
Kind regards
Suzuki
>
> Best regards,
> Krzysztof
>
Our CPUidle state save restore has some bugs which are triggered for an ETM with
system instructions (e.g. ETE). This is a series of fixes to address them.
Suzuki K Poulose (3):
coresight: etm4x: Do not hardcode IOMEM access for register restore
coresight: etm4x: Do not save/restore Data trace control registers
coresight: etm4x: Safe access for TRCQCLTR
.../coresight/coresight-etm4x-core.c | 20 +++++++++----------
drivers/hwtracing/coresight/coresight-etm4x.h | 6 +++---
2 files changed, 13 insertions(+), 13 deletions(-)
--
2.34.1
Hello CoreSight friends,
There is a bug recently reported on ChromeOS (with the linux kernel
6.6), https://issuetracker.google.com/329285580.
Lockdep detected a deadlock in TMC ETR in a debug kernel build.
[12453.456471] WARNING: possible circular locking dependency detected
[12453.456518] 6.6.21-lockdep-01250-gbecf1787b73c #1 Not tainted
[12453.456575] ------------------------------------------------------
[12453.456618] perf/12414 is trying to acquire lock:
[12453.456671] ffffffc084bc0990 (&dma_entry_hash[i].lock){-.-.}-{2:2},
at: check_sync+0x84/0x11a0
[12453.456896]
but task is already holding lock:
[12453.456938] ffffff80cdb940f8 (&drvdata->spinlock){....}-{2:2}, at:
tmc_update_etr_buffer+0xbc/0x898 [coresight_tmc]
[12453.457332]
which lock already depends on the new lock.
Could you please take a look?
Thanks,
Denis Nikitin
On 27/03/2024 05:57, Krzysztof Kozlowski wrote:
> On 27/03/2024 00:24, Suzuki K Poulose wrote:
>> Hi Krzysztof
>>
>> On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
>>> Merging
>>> =======
>>> All further patches depend on the first amba patch, therefore please ack
>>> and this should go via one tree.
>>
>> Are you able to provide a stable branch with these patches once you pull
>
> I doubt I will be merging this. I think amba code goes through Russell.
>
>> them in to "one tree" here ? We have changes coming up in the coresight
>> tree, which would conflict with the changes here (horribly).
>>
>
> You mean conflict with coresight conversion to platform driver? Worst
Yes.
> case it is solveable: just drop .owner.
Or, we could merge the CoreSight changes (as they are really not
affected by the problem this series is trying to address) after the
base changes land in AMBA, via the CoreSight tree.
Suzuki
>
> Best regards,
> Krzysztof
>
Hi Krzysztof
On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.
Are you able to provide a stable branch with these patches once you pull
them in to "one tree" here ? We have changes coming up in the coresight
tree, which would conflict with the changes here (horribly).
FWIW,
For patches 1 to 13 :
Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Suzuki
Hi Krzysztof
On 25/03/2024 10:40, Krzysztof Kozlowski wrote:
> "in-ports" and "out-ports" are defined by graph schema, so defining its
> type is redundant.
>
> Acked-by: Rob Herring <robh(a)kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Both patches look good to me. How would you like to pull this ? I could
queue them for v6.10 via coresight tree.
If you would like to take them,
Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Suzuki
>
> ---
>
> No changes, but patches were split from previous set. First patch in
> previouis series was being discussed, so let's just make these accepted.
>
> v1: https://lore.kernel.org/all/20231206115332.22712-1-krzysztof.kozlowski@lina…
> ---
> Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
> index ea3c5db6b52d..7fbd855a66a0 100644
> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
> @@ -66,13 +66,11 @@ properties:
> - const: apb_pclk
>
> in-ports:
> - type: object
> description: |
> Input connections from TPDM to TPDA
> $ref: /schemas/graph.yaml#/properties/ports
>
> out-ports:
> - type: object
> description: |
> Output connections from the TPDA to legacy CoreSight trace bus.
> $ref: /schemas/graph.yaml#/properties/ports
On 3/21/2024 10:42 PM, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>> Add new property "label" to label the source corresponding to the
>> output connection. When the funnel supports multi-output, this
>> property needs to be introduced to mark which source component a
>> certain output connection corresponds to.
>>
>> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com>
>> ---
>> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++---
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> index 44a1041cb0fc..cde62c286d29 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> @@ -66,13 +66,39 @@ properties:
>> $ref: /schemas/graph.yaml#/properties/port
>>
>> out-ports:
>> - $ref: /schemas/graph.yaml#/properties/ports
>> - additionalProperties: false
>> -
>> + type: object
>> properties:
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> port:
>> + type: object
>> +
>> + patternProperties:
>> + '^port(@[0-7])?$':
>> + type: object
>> description: Output connection to CoreSight Trace bus
>> - $ref: /schemas/graph.yaml#/properties/port
>
> Nope, now you have no constraints on port node properties. Please look
> at how other bindings are done to add properties on endpoint node.
>
Thanks for pointing this out, Rob. Shall we ref port-base and
endpoint-base then add new properties on endpoint? In this way, the
redundant code from port schema is not required.
>> +
>> + patternProperties:
>> + "^endpoint(@[0-9a-f]+)?$":
>> + type: object
>> + properties:
>> + remote-endpoint:
>> + description: |
>> + phandle to an 'endpoint' subnode of a remote device node.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>
> Don't need this.
>
>> + label:
>> + description: Label the source corresponding to the output connection
>> + $ref: /schemas/types.yaml#/definitions/string
>
> label already has a type.
>
> As this node is an output, aren't you labeling what the destination is,
> not the "source"?
>
> Why can't you look at the remote connection to identify what it is?
>
This funnel can route data stream from different trace source to
different output ports. This lable property is added to describe which
source is routed to this output port.
For example, the graph is as below. Funnel3 routes trace data from TPDM0
to output[0] and output[0] of funnel3 is connected to input[0] of TPDA0.
While Funnels routes trace data from TPDM1 to output[1] which connects
to input[1] of TPDA0. Hope that clarifies this a little bit.
|---------| |---------| |---------| |---------| |---------|
| TPDM0 | | TPDM1 | | TPDM2 | | TPDM3 | | TPDM4 |
|---------| |---------| |---------| |---------| |---------|
| | | | |
| | | | |
| | | | |
|-----| |-----| |-----| |-----| |
| | | | |
| | | | |
[0]| |[1] [0]| |[1] |
\-------------/ \-------------/ \------------/
\ FUNNEL0 / \ FUNNEL1 / \ FUNNEL2 /
----------- ----------- -----------
| | |
\-------------/ \-------------/ |
\ FUNNEL3 / \ FUNNEL4 / |
----------- ----------- |
| | | |
[0]| |[1] [0]| |[1] |
| |---------- | | |
| | | | |
|-------| | |------- | | |--------- |
| | | | |
| | | | |
[0]| |[1] |[2] |[3] |[4]
\ ---------------------------------------------------/
\ TPDA0 /
\ /
------------------------------------------------
>
>> + oneOf:
>> + - required:
>> + - port
>> + - required:
>> + - "#address-cells"
>> + - "#size-cells"
>
> The common schema that you removed handles this.
>
> Rob
--
Thanks,
Tingwei