Hi Suzuki, Leo

On Thu, 23 May 2019 at 16:32, Suzuki K Poulose [off-list ref] wrote:

Hi Leo,

On 23/05/2019 15:32, Leo Yan wrote:

quoted

Hi Suzuki,

On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote:

[...]

quoted

Changes since v2:
  - Drop the patches exposing device links via sysfs, to be posted as separate
    series.

Thanks for sharing the git tree linkage in another email.  Just want
to confirm, since patch set v3 you have dropped the patch "coresight:
Expose device connections via sysfs" [1], will you send out this patch
after ACPI binding support patches has been merged?

We are awaiting Mike's comment on the approach, as his CTI support also
needs something similar.

I fully agree that there is requirement to expose device connections
as Suzuki's patches provided. As commented in the original patch, it
removes the need for users to have knowledge of hardware specifics or
access to device tree source.

For the trace datapath a simple link is sufficient to express this
information. The nature of the data and connection is known - it is
the trace data running from source to sink. The linked components are
guaranteed to be registered coresight devices

However, the requirement for the CTI is different.

CTI is not limited to connecting to other coresight devices. Any
device can be wired into a CTI trigger signal. These devices may or
may not have drivers  / entries in the device tree.
For each connection a client needs to know the signals connected to
the cti, the signal directions, the signal prupose if possible, and
the device connected.
For this reason we dynamically fill out a connections infomation
sub-dir in sysfs containing _name, _trigin_sig, _trigout_sig,
_trigin_type, _trigout_type - described in the patch [1].

This information is sufficient and necessary to enable a user to
program a CTI in most cases.

As an example look at the Juno dtsi in [2].
CTI 0 is connected to ETR, ETF, STM and TPIU - all coresight devices.
CTI 1 is connected to REF_CLK, system profiler and watchdog - no
coresight devices at all.
CTI 2 is connected to ETF, and two ELA devices - so 1 coresight device
and 2 not coresight devices.

So my view is that for the case where CTI is connected to another
CoreSight device the sysfs link could be used in addition to the
information described above.

Regards.

Mike

[1] https://lists.linaro.org/pipermail/coresight/2019-May/002587.html
[2] https://lists.linaro.org/pipermail/coresight/2019-May/002589.html

quoted

When you send out the new patch for exposing device connection, please
loop me so that I can base on it for perf testing related works.

Sure, will do. As such, the perf testing should not be affected by that
series. It is just a helper to demonstrate the connections. But yes, it
will definitely help you to choose an ETF for a cluster, if you had multiple
ETFs on the system. Otherwise, you should be OK.

Please be aware that the power management support is missing on ACPI platform.
So you must make sure, by other means, that the debug domain is powered up.


Cheers
Suzuki
_______________________________________________
CoreSight mailing list
CoreSight@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/coresight

--
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