Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Mike Leach <mike.leach@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Leo Yan <leo.yan@linaro.org>
Subject: Re: [PATCH v4 00/30] coresight: Support for ACPI bindings
Date: Fri, 24 May 2019 14:19:43 +0100
Message-ID: <CAJ9a7Vjh_RDgp6nKrgrmuKcAhs77iU_oKTuBhSBdkUUwiwZbSg@mail.gmail.com> (raw)
In-Reply-To: <23a50436-4bcf-3439-c189-093e1a58438d@arm.com>

Hi Suzuki, Leo

On Thu, 23 May 2019 at 16:32, Suzuki K Poulose <suzuki.poulose@arm.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@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

  parent reply index

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 10:34 Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 01/30] coresight: funnel: Clean up device book keeping Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 02/30] coresight: replicator: Cleanup device tracking Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 03/30] coresight: tmc: Clean up device specific data Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 04/30] coresight: catu: Cleanup " Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 05/30] coresight: tpiu: Clean up " Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 06/30] coresight: stm: Cleanup " Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 07/30] coresight: etm: Clean up " Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 08/30] coresight: etb10: " Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 09/30] coresight: Use coresight device names for sinks in PMU attribute Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 10/30] coresight: Rename of_coresight to coresight-platform Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 11/30] coresight: etm3x: Rearrange cp14 access detection Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 12/30] coresight: stm: Rearrange probing the stimulus area Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 13/30] coresight: tmc-etr: Rearrange probing default buffer size Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 14/30] coresight: platform: Make memory allocation helper generic Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 15/30] coresight: Make sure device uses DT for obsolete compatible check Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 16/30] coresight: Introduce generic platform data helper Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 17/30] coresight: Make device to CPU mapping generic Suzuki K Poulose
2019-06-03 10:07   ` Mike Leach
2019-06-06 12:56     ` Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 18/30] coresight: Remove cpu field from platform data Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 19/30] coresight: Remove name from platform description Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 20/30] coresight: Cleanup coresight_remove_conns Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 21/30] coresight: Reuse platform data structure for connection tracking Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 22/30] coresight: Rearrange platform data probing Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 23/30] coresight: Add support for releasing platform specific data Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 24/30] coresight: platform: Use fwnode handle for device search Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 25/30] coresight: Use fwnode handle instead of device names Suzuki K Poulose
2019-05-22 10:34 ` [PATCH v4 26/30] coresight: Use platform agnostic names Suzuki K Poulose
2019-05-29  9:32   ` Mike Leach
2019-06-03 10:12     ` Suzuki K Poulose
2019-05-22 10:35 ` [PATCH v4 27/30] coresight: stm: ACPI support for parsing stimulus base Suzuki K Poulose
2019-05-22 10:35 ` [PATCH v4 28/30] coresight: Support for ACPI bindings Suzuki K Poulose
2019-05-22 10:35 ` [PATCH v4 29/30] coresight: acpi: Support for AMBA components Suzuki K Poulose
2019-05-22 10:35 ` [PATCH v4 30/30] coresight: acpi: Support for platform devices Suzuki K Poulose
2019-05-22 10:35 ` [TEST PATCH 31/30][EDK2] edk2-platform: juno: Update ACPI CoreSight Bindings Suzuki K Poulose
2019-05-23 13:37 ` [PATCH v4 00/30] coresight: Support for ACPI bindings Suzuki K Poulose
2019-05-23 14:32 ` Leo Yan
2019-05-23 15:31   ` Suzuki K Poulose
2019-05-24  1:38     ` Leo Yan
2019-05-24 13:19     ` Mike Leach [this message]
2019-05-28  5:19 ` Leo Yan
2019-05-28  8:08   ` Leo Yan
2019-05-28 14:51   ` Mathieu Poirier
2019-05-29  6:34     ` Leo Yan
2019-05-28 17:32 ` Mathieu Poirier
2019-05-28 17:36   ` Mathieu Poirier
2019-05-28 17:40     ` Suzuki K Poulose

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ9a7Vjh_RDgp6nKrgrmuKcAhs77iU_oKTuBhSBdkUUwiwZbSg@mail.gmail.com \
    --to=mike.leach@linaro.org \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org infradead-linux-arm-kernel@archiver.kernel.org
	public-inbox-index linux-arm-kernel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox