Message-ID: <CAJ9a7Vjh_RDgp6nKrgrmuKcAhs77iU_oKTuBhSBdkUUwiwZbSg@mail.gmail.com>
Date:   Fri, 24 May 2019 14:19:43 +0100
From:   Mike Leach <mike.leach@...aro.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     Leo Yan <leo.yan@...aro.org>, coresight@...ts.linaro.org,
        linux-kernel@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 00/30] coresight: Support for ACPI bindings

Hi Suzuki, Leo

On Thu, 23 May 2019 at 16:32, Suzuki K Poulose <suzuki.poulose@....com> wrote:
>
> Hi Leo,
>
> On 23/05/2019 15:32, Leo Yan wrote:
> > Hi Suzuki,
> >
> > On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote:
> >
> > [...]
> >
> >> 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

> >
> > 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@...ts.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight



--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK

Powered by blists - more mailing lists