| Message ID | 1558521304-27469-1-git-send-email-suzuki.poulose@arm.com |
|---|---|
| Headers | show |
| Series | coresight: Support for ACPI bindings | expand |
On 22/05/2019 11:34, Suzuki K Poulose wrote: > This series adds the support for CoreSight devices on ACPI based > platforms. The device connections are encoded as _DSD graph property[0], > with CoreSight specific extensions to indicate the direction of data > flow as described in [1]. Components attached to CPUs are listed > as child devices of the corresponding CPU, removing explicit links > to the CPU like we do in the DT. > > The majority of the series cleans up the driver and prepares the subsystem > for platform agnostic firwmare probing, naming scheme, searching etc. > > We introduce platform independent helpers to parse the platform supplied > information. Thus we rename the platform handling code from: > of_coresight.c => coresight-platform.c > > The CoreSight driver creates shadow devices that appear on the Coresight > bus, in addition to the real devices (e.g, AMBA bus devices). The name > of these devices match the real device. This makes the device name > a bit cryptic for ACPI platform. So this series also introduces a generic > platform agnostic device naming scheme for the shadow Coresight devices. > Towards this we also make changes to the way we lookup devices to resolve > the connections, as we can't use the names to identify the devices. So, > we use the "fwnode_handle" of the real device for the device lookups. > Towards that we clean up the drivers to keep track of the "CoreSight" > device rather than the "real" device. However, all real operations, > like DMA allocation, Power management etc. must be performed on > the real device which is the parent of the shadow device. > > Finally we add the support for parsing the ACPI platform data. The power > management support is missing in the ACPI (and this is not specific to > CoreSight). The firmware must ensure that the respective power domains > are turned on. > > Applies on v5.2-rc1 > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > top of [2]. You would need to make sure that the debug power domain is > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > Juno board while at UEFI). arm32 code is only compile tested. > > [0] ACPI Device Graphs using _DSD (Not available online yet, approved but > awaiting publish and eventually should be linked at). > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm > [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platform-design-document > [2] https://github.com/tianocore/edk2-platforms.git The kernel patches are also available at : git://linux-arm.org/linux-skp.git coresight-acpi/v4 Suzuki
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? 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. Thanks, Leo Yan [1] https://lkml.org/lkml/2019/4/15/658
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. > > 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
Hi Suzuki, On Thu, May 23, 2019 at 04:31:54PM +0100, Suzuki K Poulose wrote: [...] > > 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. Thanks a lot! > 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. Yeah, the perf testing approach is heavily based on sysfs out/in nodes to find the trace pathes. > 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. Thanks for reminding; for the first step, I will not add any power management enabling steps in the testing script, we can add the related operations if later we have clear idea for this. Thanks, Leo Yan
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
Hi Suzuki, On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote: > This series adds the support for CoreSight devices on ACPI based > platforms. The device connections are encoded as _DSD graph property[0], > with CoreSight specific extensions to indicate the direction of data > flow as described in [1]. Components attached to CPUs are listed > as child devices of the corresponding CPU, removing explicit links > to the CPU like we do in the DT. > > The majority of the series cleans up the driver and prepares the subsystem > for platform agnostic firwmare probing, naming scheme, searching etc. > > We introduce platform independent helpers to parse the platform supplied > information. Thus we rename the platform handling code from: > of_coresight.c => coresight-platform.c > > The CoreSight driver creates shadow devices that appear on the Coresight > bus, in addition to the real devices (e.g, AMBA bus devices). The name > of these devices match the real device. This makes the device name > a bit cryptic for ACPI platform. So this series also introduces a generic > platform agnostic device naming scheme for the shadow Coresight devices. > Towards this we also make changes to the way we lookup devices to resolve > the connections, as we can't use the names to identify the devices. So, > we use the "fwnode_handle" of the real device for the device lookups. > Towards that we clean up the drivers to keep track of the "CoreSight" > device rather than the "real" device. However, all real operations, > like DMA allocation, Power management etc. must be performed on > the real device which is the parent of the shadow device. > > Finally we add the support for parsing the ACPI platform data. The power > management support is missing in the ACPI (and this is not specific to > CoreSight). The firmware must ensure that the respective power domains > are turned on. > > Applies on v5.2-rc1 > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > top of [2]. You would need to make sure that the debug power domain is > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > Juno board while at UEFI). arm32 code is only compile tested. After I applied this patch set, I found all device names under '/sys/bus/event_source/devices/cs_etm/sinks/' have been changed as below on my DB410c board: # ls /sys/bus/event_source/devices/cs_etm/sinks/ tmc_etf0 tmc_etr0 tpiu0 This leads to below command failure when open PMU device: # perf record -e cs_etm/@826000.etr/ --per-thread uname failed to set sink "826000.etr" on event cs_etm/@826000.etr/ with 2 (No such file or directory) I must use below command so that perf can match string with the device name under '/sys/bus/event_source/devices/cs_etm/sinks/': # perf record -e cs_etm/@tmc_etr0/ --per-thread uname Seems to me, this is an unexpected change and when I worked on the patch set v2, IIRC that version still can use '826000.etr' to open PMU device. Please help confirm for this. Thanks! Leo.
Hi Suzuki, Mathieu, On Tue, May 28, 2019 at 01:19:24PM +0800, Leo Yan wrote: [...] > After I applied this patch set, I found all device names under > '/sys/bus/event_source/devices/cs_etm/sinks/' have been changed as > below on my DB410c board: > # ls /sys/bus/event_source/devices/cs_etm/sinks/ > tmc_etf0 tmc_etr0 tpiu0 > > This leads to below command failure when open PMU device: > # perf record -e cs_etm/@826000.etr/ --per-thread uname > failed to set sink "826000.etr" on event cs_etm/@826000.etr/ with 2 (No such file or directory) > > I must use below command so that perf can match string with the > device name under '/sys/bus/event_source/devices/cs_etm/sinks/': > # perf record -e cs_etm/@tmc_etr0/ --per-thread uname > > Seems to me, this is an unexpected change and when I worked on the > patch set v2, IIRC that version still can use '826000.etr' to open PMU > device. > > Please help confirm for this. Thanks! Finally, this is narrowed down to the patch 09/30 'coresight: Use coresight device names for sinks in PMU attribute', so this is delibrately to change to use new name format for perf command; if so, maybe also update the documentation to reflect this change? Thanks, Leo Yan
Good day, On Tue, May 28, 2019 at 01:19:24PM +0800, Leo Yan wrote: > Hi Suzuki, > > On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote: > > This series adds the support for CoreSight devices on ACPI based > > platforms. The device connections are encoded as _DSD graph property[0], > > with CoreSight specific extensions to indicate the direction of data > > flow as described in [1]. Components attached to CPUs are listed > > as child devices of the corresponding CPU, removing explicit links > > to the CPU like we do in the DT. > > > > The majority of the series cleans up the driver and prepares the subsystem > > for platform agnostic firwmare probing, naming scheme, searching etc. > > > > We introduce platform independent helpers to parse the platform supplied > > information. Thus we rename the platform handling code from: > > of_coresight.c => coresight-platform.c > > > > The CoreSight driver creates shadow devices that appear on the Coresight > > bus, in addition to the real devices (e.g, AMBA bus devices). The name > > of these devices match the real device. This makes the device name > > a bit cryptic for ACPI platform. So this series also introduces a generic > > platform agnostic device naming scheme for the shadow Coresight devices. > > Towards this we also make changes to the way we lookup devices to resolve > > the connections, as we can't use the names to identify the devices. So, > > we use the "fwnode_handle" of the real device for the device lookups. > > Towards that we clean up the drivers to keep track of the "CoreSight" > > device rather than the "real" device. However, all real operations, > > like DMA allocation, Power management etc. must be performed on > > the real device which is the parent of the shadow device. > > > > Finally we add the support for parsing the ACPI platform data. The power > > management support is missing in the ACPI (and this is not specific to > > CoreSight). The firmware must ensure that the respective power domains > > are turned on. > > > > Applies on v5.2-rc1 > > > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > > top of [2]. You would need to make sure that the debug power domain is > > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > > Juno board while at UEFI). arm32 code is only compile tested. > > After I applied this patch set, I found all device names under > '/sys/bus/event_source/devices/cs_etm/sinks/' have been changed as > below on my DB410c board: > # ls /sys/bus/event_source/devices/cs_etm/sinks/ > tmc_etf0 tmc_etr0 tpiu0 Yes, that is the expected behavior. > > This leads to below command failure when open PMU device: > # perf record -e cs_etm/@826000.etr/ --per-thread uname > failed to set sink "826000.etr" on event cs_etm/@826000.etr/ with 2 (No such file or directory) Correct. > > I must use below command so that perf can match string with the > device name under '/sys/bus/event_source/devices/cs_etm/sinks/': > # perf record -e cs_etm/@tmc_etr0/ --per-thread uname Correct. > > Seems to me, this is an unexpected change and when I worked on the > patch set v2, IIRC that version still can use '826000.etr' to open PMU > device. Correct - v2 did not address the new naming convention for devices present under 'event_source', something that was corrected in v3. > Please help confirm for this. Thanks! > > Leo.
On Wed, 22 May 2019 at 04:35, Suzuki K Poulose <suzuki.poulose@arm.com> wrote: > > This series adds the support for CoreSight devices on ACPI based > platforms. The device connections are encoded as _DSD graph property[0], > with CoreSight specific extensions to indicate the direction of data > flow as described in [1]. Components attached to CPUs are listed > as child devices of the corresponding CPU, removing explicit links > to the CPU like we do in the DT. > > The majority of the series cleans up the driver and prepares the subsystem > for platform agnostic firwmare probing, naming scheme, searching etc. > > We introduce platform independent helpers to parse the platform supplied > information. Thus we rename the platform handling code from: > of_coresight.c => coresight-platform.c > > The CoreSight driver creates shadow devices that appear on the Coresight > bus, in addition to the real devices (e.g, AMBA bus devices). The name > of these devices match the real device. This makes the device name > a bit cryptic for ACPI platform. So this series also introduces a generic > platform agnostic device naming scheme for the shadow Coresight devices. > Towards this we also make changes to the way we lookup devices to resolve > the connections, as we can't use the names to identify the devices. So, > we use the "fwnode_handle" of the real device for the device lookups. > Towards that we clean up the drivers to keep track of the "CoreSight" > device rather than the "real" device. However, all real operations, > like DMA allocation, Power management etc. must be performed on > the real device which is the parent of the shadow device. > > Finally we add the support for parsing the ACPI platform data. The power > management support is missing in the ACPI (and this is not specific to > CoreSight). The firmware must ensure that the respective power domains > are turned on. > > Applies on v5.2-rc1 > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > top of [2]. You would need to make sure that the debug power domain is > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > Juno board while at UEFI). arm32 code is only compile tested. > > [0] ACPI Device Graphs using _DSD (Not available online yet, approved but > awaiting publish and eventually should be linked at). > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm > [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platform-design-document > [2] https://github.com/tianocore/edk2-platforms.git > > Changes since v3: > - Add tags from Mathieu > > Changes since v2: > - Fix the symlink name for ETM devices under cs_etm PMU (Patch by Mathieu) > - Drop patches merged already in the tree. > - Add the tags from Mathieu > - More documentation with examples of ACPI graph in ACPI bindings support. > - Fix ETM4 error return path (Mathieu) > - Drop the patches exposing device links via sysfs, to be posted as separate > series. > - Drop the generic helper for device search by fwnode for a better cleanup > later. > - Split the ACPI bindings support patch for AMBA and platform devices. > - Return integer error for <platform>_get_platform_data() helpers. > - Fix comment about the return code for acpi_get_coresight_cpu(). > - Ensure we don't have devices part of multiple graphs (Mathieu). > > Changes since v1: > > [ http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/639963.html ] > > - Dropped the replicator driver merge changes as they were pulled already. > - Cleanups for Power management in the drivers. > - Reuse platform description for connection information. Also introduce > routines to clean up the platform description to make sure we drop > the references (fwnode_handle). > - Add RFC patches for exposing the device-links via sysfs. > - Drop tracking the device in favour of coresight_device. > - Name etb10 as "etb" > - Fix other comments in v1. > - Use a generic helper for searching with fwnode_handle rather than adding > one for CoreSight. > > > Mathieu Poirier (1): > coresight: Use coresight device names for sinks in PMU attribute > > Suzuki K Poulose (29): > coresight: funnel: Clean up device book keeping > coresight: replicator: Cleanup device tracking > coresight: tmc: Clean up device specific data > coresight: catu: Cleanup device specific data > coresight: tpiu: Clean up device specific data > coresight: stm: Cleanup device specific data > coresight: etm: Clean up device specific data > coresight: etb10: Clean up device specific data > coresight: Rename of_coresight to coresight-platform > coresight: etm3x: Rearrange cp14 access detection > coresight: stm: Rearrange probing the stimulus area > coresight: tmc-etr: Rearrange probing default buffer size > coresight: platform: Make memory allocation helper generic > coresight: Make sure device uses DT for obsolete compatible check > coresight: Introduce generic platform data helper > coresight: Make device to CPU mapping generic > coresight: Remove cpu field from platform data > coresight: Remove name from platform description > coresight: Cleanup coresight_remove_conns > coresight: Reuse platform data structure for connection tracking > coresight: Rearrange platform data probing > coresight: Add support for releasing platform specific data > coresight: platform: Use fwnode handle for device search > coresight: Use fwnode handle instead of device names > coresight: Use platform agnostic names > coresight: stm: ACPI support for parsing stimulus base > coresight: Support for ACPI bindings > coresight: acpi: Support for AMBA components > coresight: acpi: Support for platform devices > > drivers/acpi/acpi_amba.c | 9 + > drivers/hwtracing/coresight/Makefile | 3 +- > drivers/hwtracing/coresight/coresight-catu.c | 40 +- > drivers/hwtracing/coresight/coresight-catu.h | 1 - > drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +- > drivers/hwtracing/coresight/coresight-etb10.c | 51 +- > drivers/hwtracing/coresight/coresight-etm-perf.c | 8 +- > drivers/hwtracing/coresight/coresight-etm.h | 6 +- > .../hwtracing/coresight/coresight-etm3x-sysfs.c | 12 +- > drivers/hwtracing/coresight/coresight-etm3x.c | 45 +- > drivers/hwtracing/coresight/coresight-etm4x.c | 37 +- > drivers/hwtracing/coresight/coresight-etm4x.h | 2 - > drivers/hwtracing/coresight/coresight-funnel.c | 35 +- > drivers/hwtracing/coresight/coresight-platform.c | 810 +++++++++++++++++++++ > drivers/hwtracing/coresight/coresight-priv.h | 4 + > drivers/hwtracing/coresight/coresight-replicator.c | 42 +- > drivers/hwtracing/coresight/coresight-stm.c | 118 ++- > drivers/hwtracing/coresight/coresight-tmc-etf.c | 9 +- > drivers/hwtracing/coresight/coresight-tmc-etr.c | 44 +- > drivers/hwtracing/coresight/coresight-tmc.c | 96 +-- > drivers/hwtracing/coresight/coresight-tmc.h | 2 - > drivers/hwtracing/coresight/coresight-tpiu.c | 24 +- > drivers/hwtracing/coresight/coresight.c | 164 ++++- > drivers/hwtracing/coresight/of_coresight.c | 297 -------- > include/linux/coresight.h | 61 +- > 25 files changed, 1332 insertions(+), 591 deletions(-) > create mode 100644 drivers/hwtracing/coresight/coresight-platform.c > delete mode 100644 drivers/hwtracing/coresight/of_coresight.c I have applied this set. Thanks, Mathieu > > ACPI bindings for Juno-r0 (applies on [2] above) > > Suzuki K Poulose (1): > edk2-platform: juno: Update ACPI CoreSight Bindings > > Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl | 241 +++++++++++++++++++++++++++++++ > 1 file changed, 241 insertions(+) > > -- > 2.7.4 >
On Tue, 28 May 2019 at 11:32, Mathieu Poirier <mathieu.poirier@linaro.org> wrote: > > On Wed, 22 May 2019 at 04:35, Suzuki K Poulose <suzuki.poulose@arm.com> wrote: > > > > This series adds the support for CoreSight devices on ACPI based > > platforms. The device connections are encoded as _DSD graph property[0], > > with CoreSight specific extensions to indicate the direction of data > > flow as described in [1]. Components attached to CPUs are listed > > as child devices of the corresponding CPU, removing explicit links > > to the CPU like we do in the DT. > > > > The majority of the series cleans up the driver and prepares the subsystem > > for platform agnostic firwmare probing, naming scheme, searching etc. > > > > We introduce platform independent helpers to parse the platform supplied > > information. Thus we rename the platform handling code from: > > of_coresight.c => coresight-platform.c > > > > The CoreSight driver creates shadow devices that appear on the Coresight > > bus, in addition to the real devices (e.g, AMBA bus devices). The name > > of these devices match the real device. This makes the device name > > a bit cryptic for ACPI platform. So this series also introduces a generic > > platform agnostic device naming scheme for the shadow Coresight devices. > > Towards this we also make changes to the way we lookup devices to resolve > > the connections, as we can't use the names to identify the devices. So, > > we use the "fwnode_handle" of the real device for the device lookups. > > Towards that we clean up the drivers to keep track of the "CoreSight" > > device rather than the "real" device. However, all real operations, > > like DMA allocation, Power management etc. must be performed on > > the real device which is the parent of the shadow device. > > > > Finally we add the support for parsing the ACPI platform data. The power > > management support is missing in the ACPI (and this is not specific to > > CoreSight). The firmware must ensure that the respective power domains > > are turned on. > > > > Applies on v5.2-rc1 > > > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > > top of [2]. You would need to make sure that the debug power domain is > > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > > Juno board while at UEFI). arm32 code is only compile tested. > > > > [0] ACPI Device Graphs using _DSD (Not available online yet, approved but > > awaiting publish and eventually should be linked at). > > https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm > > [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platform-design-document > > [2] https://github.com/tianocore/edk2-platforms.git > > > > Changes since v3: > > - Add tags from Mathieu > > > > Changes since v2: > > - Fix the symlink name for ETM devices under cs_etm PMU (Patch by Mathieu) > > - Drop patches merged already in the tree. > > - Add the tags from Mathieu > > - More documentation with examples of ACPI graph in ACPI bindings support. > > - Fix ETM4 error return path (Mathieu) > > - Drop the patches exposing device links via sysfs, to be posted as separate > > series. > > - Drop the generic helper for device search by fwnode for a better cleanup > > later. > > - Split the ACPI bindings support patch for AMBA and platform devices. > > - Return integer error for <platform>_get_platform_data() helpers. > > - Fix comment about the return code for acpi_get_coresight_cpu(). > > - Ensure we don't have devices part of multiple graphs (Mathieu). > > > > Changes since v1: > > > > [ http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/639963.html ] > > > > - Dropped the replicator driver merge changes as they were pulled already. > > - Cleanups for Power management in the drivers. > > - Reuse platform description for connection information. Also introduce > > routines to clean up the platform description to make sure we drop > > the references (fwnode_handle). > > - Add RFC patches for exposing the device-links via sysfs. > > - Drop tracking the device in favour of coresight_device. > > - Name etb10 as "etb" > > - Fix other comments in v1. > > - Use a generic helper for searching with fwnode_handle rather than adding > > one for CoreSight. > > > > > > Mathieu Poirier (1): > > coresight: Use coresight device names for sinks in PMU attribute > > > > Suzuki K Poulose (29): > > coresight: funnel: Clean up device book keeping > > coresight: replicator: Cleanup device tracking > > coresight: tmc: Clean up device specific data > > coresight: catu: Cleanup device specific data > > coresight: tpiu: Clean up device specific data > > coresight: stm: Cleanup device specific data > > coresight: etm: Clean up device specific data > > coresight: etb10: Clean up device specific data > > coresight: Rename of_coresight to coresight-platform > > coresight: etm3x: Rearrange cp14 access detection > > coresight: stm: Rearrange probing the stimulus area > > coresight: tmc-etr: Rearrange probing default buffer size > > coresight: platform: Make memory allocation helper generic > > coresight: Make sure device uses DT for obsolete compatible check > > coresight: Introduce generic platform data helper > > coresight: Make device to CPU mapping generic > > coresight: Remove cpu field from platform data > > coresight: Remove name from platform description > > coresight: Cleanup coresight_remove_conns > > coresight: Reuse platform data structure for connection tracking > > coresight: Rearrange platform data probing > > coresight: Add support for releasing platform specific data > > coresight: platform: Use fwnode handle for device search > > coresight: Use fwnode handle instead of device names > > coresight: Use platform agnostic names > > coresight: stm: ACPI support for parsing stimulus base > > coresight: Support for ACPI bindings > > coresight: acpi: Support for AMBA components > > coresight: acpi: Support for platform devices > > > > drivers/acpi/acpi_amba.c | 9 + > > drivers/hwtracing/coresight/Makefile | 3 +- > > drivers/hwtracing/coresight/coresight-catu.c | 40 +- > > drivers/hwtracing/coresight/coresight-catu.h | 1 - > > drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +- > > drivers/hwtracing/coresight/coresight-etb10.c | 51 +- > > drivers/hwtracing/coresight/coresight-etm-perf.c | 8 +- > > drivers/hwtracing/coresight/coresight-etm.h | 6 +- > > .../hwtracing/coresight/coresight-etm3x-sysfs.c | 12 +- > > drivers/hwtracing/coresight/coresight-etm3x.c | 45 +- > > drivers/hwtracing/coresight/coresight-etm4x.c | 37 +- > > drivers/hwtracing/coresight/coresight-etm4x.h | 2 - > > drivers/hwtracing/coresight/coresight-funnel.c | 35 +- > > drivers/hwtracing/coresight/coresight-platform.c | 810 +++++++++++++++++++++ > > drivers/hwtracing/coresight/coresight-priv.h | 4 + > > drivers/hwtracing/coresight/coresight-replicator.c | 42 +- > > drivers/hwtracing/coresight/coresight-stm.c | 118 ++- > > drivers/hwtracing/coresight/coresight-tmc-etf.c | 9 +- > > drivers/hwtracing/coresight/coresight-tmc-etr.c | 44 +- > > drivers/hwtracing/coresight/coresight-tmc.c | 96 +-- > > drivers/hwtracing/coresight/coresight-tmc.h | 2 - > > drivers/hwtracing/coresight/coresight-tpiu.c | 24 +- > > drivers/hwtracing/coresight/coresight.c | 164 ++++- > > drivers/hwtracing/coresight/of_coresight.c | 297 -------- > > include/linux/coresight.h | 61 +- > > 25 files changed, 1332 insertions(+), 591 deletions(-) > > create mode 100644 drivers/hwtracing/coresight/coresight-platform.c > > delete mode 100644 drivers/hwtracing/coresight/of_coresight.c > > I have applied this set. As Leo pointed out it would be interesting to update the documentation in "Documentation/trace/coresight.txt". > > Thanks, > Mathieu > > > > > ACPI bindings for Juno-r0 (applies on [2] above) > > > > Suzuki K Poulose (1): > > edk2-platform: juno: Update ACPI CoreSight Bindings > > > > Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl | 241 +++++++++++++++++++++++++++++++ > > 1 file changed, 241 insertions(+) > > > > -- > > 2.7.4 > >
Hi Mathieu, On 28/05/2019 18:36, Mathieu Poirier wrote: > On Tue, 28 May 2019 at 11:32, Mathieu Poirier > <mathieu.poirier@linaro.org> wrote: >> ... >> >> I have applied this set. Thanks. > > As Leo pointed out it would be interesting to update the documentation > in "Documentation/trace/coresight.txt". I am on it, will send it out soon. Cheers Suzuki
On Tue, May 28, 2019 at 08:51:26AM -0600, Mathieu Poirier wrote: > Good day, > > On Tue, May 28, 2019 at 01:19:24PM +0800, Leo Yan wrote: > > Hi Suzuki, > > > > On Wed, May 22, 2019 at 11:34:33AM +0100, Suzuki K Poulose wrote: > > > This series adds the support for CoreSight devices on ACPI based > > > platforms. The device connections are encoded as _DSD graph property[0], > > > with CoreSight specific extensions to indicate the direction of data > > > flow as described in [1]. Components attached to CPUs are listed > > > as child devices of the corresponding CPU, removing explicit links > > > to the CPU like we do in the DT. > > > > > > The majority of the series cleans up the driver and prepares the subsystem > > > for platform agnostic firwmare probing, naming scheme, searching etc. > > > > > > We introduce platform independent helpers to parse the platform supplied > > > information. Thus we rename the platform handling code from: > > > of_coresight.c => coresight-platform.c > > > > > > The CoreSight driver creates shadow devices that appear on the Coresight > > > bus, in addition to the real devices (e.g, AMBA bus devices). The name > > > of these devices match the real device. This makes the device name > > > a bit cryptic for ACPI platform. So this series also introduces a generic > > > platform agnostic device naming scheme for the shadow Coresight devices. > > > Towards this we also make changes to the way we lookup devices to resolve > > > the connections, as we can't use the names to identify the devices. So, > > > we use the "fwnode_handle" of the real device for the device lookups. > > > Towards that we clean up the drivers to keep track of the "CoreSight" > > > device rather than the "real" device. However, all real operations, > > > like DMA allocation, Power management etc. must be performed on > > > the real device which is the parent of the shadow device. > > > > > > Finally we add the support for parsing the ACPI platform data. The power > > > management support is missing in the ACPI (and this is not specific to > > > CoreSight). The firmware must ensure that the respective power domains > > > are turned on. > > > > > > Applies on v5.2-rc1 > > > > > > Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on > > > top of [2]. You would need to make sure that the debug power domain is > > > turned on before the Linux kernel boots. (e.g, connect the DS-5 to the > > > Juno board while at UEFI). arm32 code is only compile tested. > > > > After I applied this patch set, I found all device names under > > '/sys/bus/event_source/devices/cs_etm/sinks/' have been changed as > > below on my DB410c board: > > # ls /sys/bus/event_source/devices/cs_etm/sinks/ > > tmc_etf0 tmc_etr0 tpiu0 > > Yes, that is the expected behavior. > > > > > This leads to below command failure when open PMU device: > > # perf record -e cs_etm/@826000.etr/ --per-thread uname > > failed to set sink "826000.etr" on event cs_etm/@826000.etr/ with 2 (No such file or directory) > > Correct. > > > > > I must use below command so that perf can match string with the > > device name under '/sys/bus/event_source/devices/cs_etm/sinks/': > > # perf record -e cs_etm/@tmc_etr0/ --per-thread uname > > Correct. > > > > > Seems to me, this is an unexpected change and when I worked on the > > patch set v2, IIRC that version still can use '826000.etr' to open PMU > > device. > > Correct - v2 did not address the new naming convention for devices present under > 'event_source', something that was corrected in v3. Thanks for confirmation, Mathieu.
This series adds the support for CoreSight devices on ACPI based platforms. The device connections are encoded as _DSD graph property[0], with CoreSight specific extensions to indicate the direction of data flow as described in [1]. Components attached to CPUs are listed as child devices of the corresponding CPU, removing explicit links to the CPU like we do in the DT. The majority of the series cleans up the driver and prepares the subsystem for platform agnostic firwmare probing, naming scheme, searching etc. We introduce platform independent helpers to parse the platform supplied information. Thus we rename the platform handling code from: of_coresight.c => coresight-platform.c The CoreSight driver creates shadow devices that appear on the Coresight bus, in addition to the real devices (e.g, AMBA bus devices). The name of these devices match the real device. This makes the device name a bit cryptic for ACPI platform. So this series also introduces a generic platform agnostic device naming scheme for the shadow Coresight devices. Towards this we also make changes to the way we lookup devices to resolve the connections, as we can't use the names to identify the devices. So, we use the "fwnode_handle" of the real device for the device lookups. Towards that we clean up the drivers to keep track of the "CoreSight" device rather than the "real" device. However, all real operations, like DMA allocation, Power management etc. must be performed on the real device which is the parent of the shadow device. Finally we add the support for parsing the ACPI platform data. The power management support is missing in the ACPI (and this is not specific to CoreSight). The firmware must ensure that the respective power domains are turned on. Applies on v5.2-rc1 Tested on a Juno-r0 board with ACPI bindings patch (Patch 31/30) added on top of [2]. You would need to make sure that the debug power domain is turned on before the Linux kernel boots. (e.g, connect the DS-5 to the Juno board while at UEFI). arm32 code is only compile tested. [0] ACPI Device Graphs using _DSD (Not available online yet, approved but awaiting publish and eventually should be linked at). https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platform-design-document [2] https://github.com/tianocore/edk2-platforms.git Changes since v3: - Add tags from Mathieu Changes since v2: - Fix the symlink name for ETM devices under cs_etm PMU (Patch by Mathieu) - Drop patches merged already in the tree. - Add the tags from Mathieu - More documentation with examples of ACPI graph in ACPI bindings support. - Fix ETM4 error return path (Mathieu) - Drop the patches exposing device links via sysfs, to be posted as separate series. - Drop the generic helper for device search by fwnode for a better cleanup later. - Split the ACPI bindings support patch for AMBA and platform devices. - Return integer error for <platform>_get_platform_data() helpers. - Fix comment about the return code for acpi_get_coresight_cpu(). - Ensure we don't have devices part of multiple graphs (Mathieu). Changes since v1: [ http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/639963.html ] - Dropped the replicator driver merge changes as they were pulled already. - Cleanups for Power management in the drivers. - Reuse platform description for connection information. Also introduce routines to clean up the platform description to make sure we drop the references (fwnode_handle). - Add RFC patches for exposing the device-links via sysfs. - Drop tracking the device in favour of coresight_device. - Name etb10 as "etb" - Fix other comments in v1. - Use a generic helper for searching with fwnode_handle rather than adding one for CoreSight. Mathieu Poirier (1): coresight: Use coresight device names for sinks in PMU attribute Suzuki K Poulose (29): coresight: funnel: Clean up device book keeping coresight: replicator: Cleanup device tracking coresight: tmc: Clean up device specific data coresight: catu: Cleanup device specific data coresight: tpiu: Clean up device specific data coresight: stm: Cleanup device specific data coresight: etm: Clean up device specific data coresight: etb10: Clean up device specific data coresight: Rename of_coresight to coresight-platform coresight: etm3x: Rearrange cp14 access detection coresight: stm: Rearrange probing the stimulus area coresight: tmc-etr: Rearrange probing default buffer size coresight: platform: Make memory allocation helper generic coresight: Make sure device uses DT for obsolete compatible check coresight: Introduce generic platform data helper coresight: Make device to CPU mapping generic coresight: Remove cpu field from platform data coresight: Remove name from platform description coresight: Cleanup coresight_remove_conns coresight: Reuse platform data structure for connection tracking coresight: Rearrange platform data probing coresight: Add support for releasing platform specific data coresight: platform: Use fwnode handle for device search coresight: Use fwnode handle instead of device names coresight: Use platform agnostic names coresight: stm: ACPI support for parsing stimulus base coresight: Support for ACPI bindings coresight: acpi: Support for AMBA components coresight: acpi: Support for platform devices drivers/acpi/acpi_amba.c | 9 + drivers/hwtracing/coresight/Makefile | 3 +- drivers/hwtracing/coresight/coresight-catu.c | 40 +- drivers/hwtracing/coresight/coresight-catu.h | 1 - drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +- drivers/hwtracing/coresight/coresight-etb10.c | 51 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 8 +- drivers/hwtracing/coresight/coresight-etm.h | 6 +- .../hwtracing/coresight/coresight-etm3x-sysfs.c | 12 +- drivers/hwtracing/coresight/coresight-etm3x.c | 45 +- drivers/hwtracing/coresight/coresight-etm4x.c | 37 +- drivers/hwtracing/coresight/coresight-etm4x.h | 2 - drivers/hwtracing/coresight/coresight-funnel.c | 35 +- drivers/hwtracing/coresight/coresight-platform.c | 810 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-priv.h | 4 + drivers/hwtracing/coresight/coresight-replicator.c | 42 +- drivers/hwtracing/coresight/coresight-stm.c | 118 ++- drivers/hwtracing/coresight/coresight-tmc-etf.c | 9 +- drivers/hwtracing/coresight/coresight-tmc-etr.c | 44 +- drivers/hwtracing/coresight/coresight-tmc.c | 96 +-- drivers/hwtracing/coresight/coresight-tmc.h | 2 - drivers/hwtracing/coresight/coresight-tpiu.c | 24 +- drivers/hwtracing/coresight/coresight.c | 164 ++++- drivers/hwtracing/coresight/of_coresight.c | 297 -------- include/linux/coresight.h | 61 +- 25 files changed, 1332 insertions(+), 591 deletions(-) create mode 100644 drivers/hwtracing/coresight/coresight-platform.c delete mode 100644 drivers/hwtracing/coresight/of_coresight.c ACPI bindings for Juno-r0 (applies on [2] above) Suzuki K Poulose (1): edk2-platform: juno: Update ACPI CoreSight Bindings Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl | 241 +++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) -- 2.7.4