[v4,00/30] coresight: Support for ACPI bindings
mbox series

Message ID 1558521304-27469-1-git-send-email-suzuki.poulose@arm.com
Headers show
Series
  • coresight: Support for ACPI bindings
Related show

Message

Suzuki Kuruppassery Poulose May 22, 2019, 10:34 a.m. UTC
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(+)

Comments

Suzuki Kuruppassery Poulose May 23, 2019, 1:37 p.m. UTC | #1
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
Leo Yan May 23, 2019, 2:32 p.m. UTC | #2
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
Suzuki Kuruppassery Poulose May 23, 2019, 3:31 p.m. UTC | #3
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
Leo Yan May 24, 2019, 1:38 a.m. UTC | #4
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
Mike Leach May 24, 2019, 1:19 p.m. UTC | #5
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
Leo Yan May 28, 2019, 5:19 a.m. UTC | #6
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.
Leo Yan May 28, 2019, 8:08 a.m. UTC | #7
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
Mathieu Poirier May 28, 2019, 2:51 p.m. UTC | #8
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.
Mathieu Poirier May 28, 2019, 5:32 p.m. UTC | #9
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
>
Mathieu Poirier May 28, 2019, 5:36 p.m. UTC | #10
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
> >
Suzuki Kuruppassery Poulose May 28, 2019, 5:40 p.m. UTC | #11
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
Leo Yan May 29, 2019, 6:34 a.m. UTC | #12
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.