From: Mike Leach <mike.leach@linaro.org> To: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Leo Yan <leo.yan@linaro.org>, coresight@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 00/30] coresight: Support for ACPI bindings Date: Fri, 24 May 2019 14:19:43 +0100 [thread overview] 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
WARNING: multiple messages have this Message-ID (diff)
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 [thread overview] 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
next prev parent reply other threads:[~2019-05-24 13:19 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-22 10:34 [PATCH v4 00/30] coresight: Support for ACPI bindings Suzuki K Poulose 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 ` 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 ` 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 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 04/30] coresight: catu: Cleanup " Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 05/30] coresight: tpiu: Clean up " Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 06/30] coresight: stm: Cleanup " Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 07/30] coresight: etm: Clean up " Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 08/30] coresight: etb10: " Suzuki K Poulose 2019-05-22 10:34 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 17/30] coresight: Make device to CPU mapping generic Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-06-03 10:07 ` Mike Leach 2019-06-03 10:07 ` Mike Leach 2019-06-06 12:56 ` Suzuki K Poulose 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Suzuki K Poulose 2019-05-22 10:34 ` [PATCH v4 26/30] coresight: Use platform agnostic names Suzuki K Poulose 2019-05-22 10:34 ` Suzuki K Poulose 2019-05-29 9:32 ` Mike Leach 2019-05-29 9:32 ` Mike Leach 2019-06-03 10:12 ` Suzuki K Poulose 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 ` 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 ` 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 ` 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 ` 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-22 10:35 ` Suzuki K Poulose 2019-05-23 13:37 ` [PATCH v4 00/30] coresight: Support for ACPI bindings Suzuki K Poulose 2019-05-23 13:37 ` Suzuki K Poulose 2019-05-23 14:32 ` Leo Yan 2019-05-23 14:32 ` Leo Yan 2019-05-23 15:31 ` Suzuki K Poulose 2019-05-23 15:31 ` Suzuki K Poulose 2019-05-24 1:38 ` Leo Yan 2019-05-24 1:38 ` Leo Yan 2019-05-24 13:19 ` Mike Leach [this message] 2019-05-24 13:19 ` Mike Leach 2019-05-28 5:19 ` Leo Yan 2019-05-28 5:19 ` Leo Yan 2019-05-28 8:08 ` Leo Yan 2019-05-28 8:08 ` Leo Yan 2019-05-28 14:51 ` Mathieu Poirier 2019-05-28 14:51 ` Mathieu Poirier 2019-05-29 6:34 ` Leo Yan 2019-05-29 6:34 ` Leo Yan 2019-05-28 17:32 ` Mathieu Poirier 2019-05-28 17:32 ` Mathieu Poirier 2019-05-28 17:36 ` Mathieu Poirier 2019-05-28 17:36 ` Mathieu Poirier 2019-05-28 17:40 ` Suzuki K Poulose 2019-05-28 17:40 ` Suzuki K Poulose
Reply instructions: You may reply publicly 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.