CoreSight ETM4x devices could be accessed either via MMIO (handled via
amba_driver) or CPU system instructions (handled via platform driver). But
this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on
adding the "known" PIDs to get it working with AMBA driver. While
the ETM4 architecture (and CoreSight architecture) defines way to
identify a device as ETM4. Thus older kernels won't be able to
"discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the device
irrespective of the mode of access. This creates a problem where two
different drivers (both AMBA based driver and platform driver) would
hook into the "HID" and could conflict. e.g., if AMBA driver gets
hold of a non-MMIO device, the probe fails. If we have single driver
hooked into the given "HID", we could handle them seamlessly,
irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With
ACPI, amba_driver doesn't get us anywhere with handling the power
and thus one need to always turn the power ON to use them. Moving to
platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices to be
supported via tha platform driver. The series makes the existing platform
driver generic to handle both type of the access modes. Although existing
AMBA driver would still continue to support DT based etm4x MMIO devices.
Although some problems still remain, such as manually adding PIDs for all
new AMBA DT based devices.
The series applies on 6.5-rc1.
Changes in V6:
- Rebased on 6.5-rc1
Changes in V5:
https://lore.kernel.org/all/20230529062511.52016-1-anshuman.khandual@arm.com/
- Updated the comment for apb clock in drvdata structure
- Updated conditional check in etm4_runtime_suspend/resume()
- Asserted that the APB clock is present and also enabled
Changes in V4:
https://lore.kernel.org/all/20230523044553.1525048-1-anshuman.khandual@arm.com/
- Changed in-code comment in etm4_check_arch_features()
- Re-ordered pm_runtime_disable() in etm4_remove_platform_dev()
- Renamed back etm4_match as etm4_sysreg_match
- Moved back [PATCH 6/6] as [PATCH 5/6]
Changes in V3:
https://lore.kernel.org/all/20230519052149.1367814-1-anshuman.khandual@arm.com/
- Returned from etm4_check_arch_features() for non iomem devices
- Renamed ETM_DEVTYPE_ETMv4x_ARCH as CS_DEVTYPE_PE_TRACE
- Renamed is_etm4x_devtype() as is_devtype_cpu_trace()
- Added a patch to ignore the absence of graph connections
Changes in V2:
https://lore.kernel.org/all/20230327050537.30861-1-anshuman.khandual@arm.com/
- Enables ACPI etm4x device support in the existing platform driver
- Dropped last two patches from the series
- Dropped redundant 'devarch' checking from is_etm4x_device()
- Renamed updated is_etm4x_device() as is_etm4x_devtype()
- Fixed arguments in fallback stub for etm4_check_arch_features()
- Tagged etm4_dev_pm_ops with etm4_platform_driver
- Updated the comment for coresight_get_enable_apb_pclk() helper
- Updated the comment for new 'pclk' element in struct etm4_drvdata
- Dropped the clock when devm_ioremap_resource() fails
- Convert IS_ERR() into a direct pointer check in etm4_remove_platform_dev()
- Dropped "arm,coresight-etm4x" compatible property from etm4_match[]
Changes in V1:
https://lore.kernel.org/all/20230317030501.1811905-1-anshuman.khandual@arm.com/
Cc: Ganapatrao Kulkarni <redacted>
Cc: Steve Clevenger <redacted>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <redacted>
Cc: Russell King (Oracle) <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: devicetree@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Anshuman Khandual (4):
coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier
coresight: etm4x: Drop iomem 'base' argument from etm4_probe()
coresight: etm4x: Drop pid argument from etm4_probe()
coresight: etm4x: Change etm4_platform_driver driver for MMIO devices
Suzuki K Poulose (2):
coresight: platform: acpi: Ignore the absence of graph
coresight: etm4x: Add ACPI support in platform driver
drivers/acpi/acpi_amba.c | 1 -
.../coresight/coresight-etm4x-core.c | 118 ++++++++++++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 4 +
.../hwtracing/coresight/coresight-platform.c | 6 +-
include/linux/coresight.h | 59 +++++++++
5 files changed, 164 insertions(+), 24 deletions(-)
--
2.25.1
Allocate and device assign 'struct etmv4_drvdata' earlier during the driver
probe, ensuring that it can be retrieved in power management based runtime
callbacks if required. This will also help in dropping iomem base address
argument from the function etm4_probe() later.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <redacted>
---
.../coresight/coresight-etm4x-core.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
'struct etm4_drvdata' itself can carry the base address before etm4_probe()
gets called. Just drop that redundant argument from etm4_probe().
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: James Clark <redacted>
Signed-off-by: Anshuman Khandual <redacted>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Coresight device pid can be retrieved from its iomem base address, which is
stored in 'struct etm4x_drvdata'. This drops pid argument from etm4_probe()
and 'struct etm4_init_arg'. Instead etm4_check_arch_features() derives the
coresight device pid with a new helper coresight_get_pid(), right before it
is consumed in etm4_hisi_match_pid().
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <redacted>
---
.../coresight/coresight-etm4x-core.c | 29 ++++++++++---------
include/linux/coresight.h | 12 ++++++++
2 files changed, 27 insertions(+), 14 deletions(-)
@@ -1161,7 +1168,7 @@ static void etm4_init_arch_data(void *info)etm4_os_unlock_csa(drvdata,csa);etm4_cs_unlock(drvdata,csa);-etm4_check_arch_features(drvdata,init_arg->pid);+etm4_check_arch_features(drvdata,csa);/* find all capabilities of the tracing unit */etmidr0=etm4x_relaxed_read32(csa,TRCIDR0);
@@ -2044,7 +2051,7 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)return0;}-staticintetm4_probe(structdevice*dev,u32etm_pid)+staticintetm4_probe(structdevice*dev){structetmv4_drvdata*drvdata=dev_get_drvdata(dev);structcsdev_accessaccess={0};
Add support for handling MMIO based devices via platform driver. We need to
make sure that :
1) The APB clock, if present is enabled at probe and via runtime_pm ops
2) Use the ETM4x architecture or CoreSight architecture registers to
identify a device as CoreSight ETM4x, instead of relying a white list of
"Peripheral IDs"
The driver doesn't get to handle the devices yet, until we wire the ACPI
changes to move the devices to be handled via platform driver than the
etm4_amba driver.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Sudeep Holla <redacted>
Signed-off-by: Anshuman Khandual <redacted>
---
.../coresight/coresight-etm4x-core.c | 58 ++++++++++++++++++-
drivers/hwtracing/coresight/coresight-etm4x.h | 4 ++
include/linux/coresight.h | 47 +++++++++++++++
3 files changed, 107 insertions(+), 2 deletions(-)
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Some components may not have graph connections for describing
the trace path. e.g., ETE, where it could directly use the per
CPU TRBE. Ignore the absence of graph connections
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
---
drivers/hwtracing/coresight/coresight-platform.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
---
drivers/acpi/acpi_amba.c | 1 -
drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2023-07-10 16:40:10
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Kind regards
Suzuki
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2023-07-19 10:11:44
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
We have a Marvell SoC based on ARMv9 architecture with Coresight ETE.
Without this patchset, we get following error on our platform:
[ 0.042733] acpi ARMHC500:00: amba_handler_attach(): amba_device_add() failed (-16)
This patchset fixes the issue and helps in successfully probing
the Coresight ETE device when booted with ACPI tables.
Tested-by: Tanmay Jagdale <redacted>
With Regards,
Tanmay
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just
move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific
changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
_______________________________________________
CoreSight mailing list -- coresight@lists.linaro.org
To unsubscribe send an email to coresight-leave@lists.linaro.org
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2023-07-24 16:25:38
Hi Rafael/Len
On 19/07/2023 11:11, Suzuki K Poulose wrote:
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Please could one of you respond to this patch ? We are blocked on your Ack for queuing this. There are machines out there, which rely on this
patch to use Arm self-hosted tracing based on CoreSight.
Kind regards
Suzuki
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
From: Steve Clevenger OS <hidden> Date: 2023-07-25 20:18:17
Hi Rafael, Len,
On 7/24/2023 9:25 AM, Suzuki K Poulose wrote:
Hi Rafael/Len
On 19/07/2023 11:11, Suzuki K Poulose wrote:
quoted
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just
move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific
changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Please could one of you respond to this patch ? We are blocked on your
Ack for queuing this. There are machines out there, which rely on this
patch to use Arm self-hosted tracing based on CoreSight.
Kind regards
Suzuki
Ampere Computing AmpereOne machines rely on this patch series to enable
System Register Access to the ETMv4. Ampere removed the ETM MMIO
descriptions from our CoreSight ACPI to use this.
Suzuki's e-mail requests for review/Ack of this patch thread date back
to May 30.
Thanks in advance,
Steve C.
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2023-07-26 14:33:42
On Tue, Jul 25, 2023 at 10:18 PM Steve Clevenger OS
[off-list ref] wrote:
Hi Rafael, Len,
On 7/24/2023 9:25 AM, Suzuki K Poulose wrote:
quoted
Hi Rafael/Len
On 19/07/2023 11:11, Suzuki K Poulose wrote:
quoted
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just
move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific
changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Please could one of you respond to this patch ? We are blocked on your
Ack for queuing this. There are machines out there, which rely on this
patch to use Arm self-hosted tracing based on CoreSight.
Kind regards
Suzuki
Ampere Computing AmpereOne machines rely on this patch series to enable
System Register Access to the ETMv4. Ampere removed the ETM MMIO
descriptions from our CoreSight ACPI to use this.
Suzuki's e-mail requests for review/Ack of this patch thread date back
to May 30.
I've just talked to Suzuki about this:
https://lore.kernel.org/linux-acpi/20230726140515.368981-1-suzuki.poulose@arm.com
This patch has received a Reviewed-by from Sudeep which for all
purposes should be sufficient for any ARM-related ACPI material that
doesn't affect any other architectures. An ACK from me (or Len for
that matter) would not make any real difference from the technical
perspective.
I would appreciate assigning an official ARM maintainer to acpi_amba.c
so as to avoid such unnecessary delays in the future.
On Wed, Jul 26, 2023 at 04:33:26PM +0200, Rafael J. Wysocki wrote:
On Tue, Jul 25, 2023 at 10:18 PM Steve Clevenger OS
[off-list ref] wrote:
quoted
Hi Rafael, Len,
On 7/24/2023 9:25 AM, Suzuki K Poulose wrote:
quoted
Hi Rafael/Len
On 19/07/2023 11:11, Suzuki K Poulose wrote:
quoted
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just
move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific
changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Please could one of you respond to this patch ? We are blocked on your
Ack for queuing this. There are machines out there, which rely on this
patch to use Arm self-hosted tracing based on CoreSight.
Kind regards
Suzuki
Ampere Computing AmpereOne machines rely on this patch series to enable
System Register Access to the ETMv4. Ampere removed the ETM MMIO
descriptions from our CoreSight ACPI to use this.
Suzuki's e-mail requests for review/Ack of this patch thread date back
to May 30.
I've just talked to Suzuki about this:
https://lore.kernel.org/linux-acpi/20230726140515.368981-1-suzuki.poulose@arm.com
This patch has received a Reviewed-by from Sudeep which for all
purposes should be sufficient for any ARM-related ACPI material that
doesn't affect any other architectures. An ACK from me (or Len for
that matter) would not make any real difference from the technical
perspective.
I would appreciate assigning an official ARM maintainer to acpi_amba.c
so as to avoid such unnecessary delays in the future.
Ah I just crossed and replied on other thread. I will soon send an update
to add this file under Arm ACPI for the maintenance.
--
Regards,
Sudeep
From: Steve Clevenger OS <hidden> Date: 2023-07-26 16:30:55
Hi Sudeep,
On 7/26/2023 8:03 AM, Sudeep Holla wrote:
On Wed, Jul 26, 2023 at 04:33:26PM +0200, Rafael J. Wysocki wrote:
quoted
On Tue, Jul 25, 2023 at 10:18 PM Steve Clevenger OS
[off-list ref] wrote:
quoted
Hi Rafael, Len,
On 7/24/2023 9:25 AM, Suzuki K Poulose wrote:
quoted
Hi Rafael/Len
On 19/07/2023 11:11, Suzuki K Poulose wrote:
quoted
Rafael, Len
Ping (packets 6, lost 100%).
On 10/07/2023 17:40, Suzuki K Poulose wrote:
quoted
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
quoted
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Drop ETM4X ACPI ID from the AMBA ACPI device list, and instead just
move it
inside the new ACPI devices list detected and used via platform driver.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mike Leach <redacted>
Cc: Leo Yan <redacted>
Cc: Sudeep Holla <redacted>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Sudeep Holla <redacted> (for ACPI specific
changes)
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <redacted>
We would like to queue this via coresight tree. The acpi_amba bits have
been reviewed by Sudeep. Please could you give us an Ack, if you are
happy with the proposal ?
Please could one of you respond to this patch ? We are blocked on your
Ack for queuing this. There are machines out there, which rely on this
patch to use Arm self-hosted tracing based on CoreSight.
Kind regards
Suzuki
Ampere Computing AmpereOne machines rely on this patch series to enable
System Register Access to the ETMv4. Ampere removed the ETM MMIO
descriptions from our CoreSight ACPI to use this.
Suzuki's e-mail requests for review/Ack of this patch thread date back
to May 30.
I've just talked to Suzuki about this:
https://lore.kernel.org/linux-acpi/20230726140515.368981-1-suzuki.poulose@arm.com
This patch has received a Reviewed-by from Sudeep which for all
purposes should be sufficient for any ARM-related ACPI material that
doesn't affect any other architectures. An ACK from me (or Len for
that matter) would not make any real difference from the technical
perspective.
I would appreciate assigning an official ARM maintainer to acpi_amba.c
so as to avoid such unnecessary delays in the future.
Ah I just crossed and replied on other thread. I will soon send an update
to add this file under Arm ACPI for the maintenance.
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2023-07-26 16:59:59
On 10/07/2023 07:24, Anshuman Khandual wrote:
CoreSight ETM4x devices could be accessed either via MMIO (handled via
amba_driver) or CPU system instructions (handled via platform driver). But
this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on
adding the "known" PIDs to get it working with AMBA driver. While
the ETM4 architecture (and CoreSight architecture) defines way to
identify a device as ETM4. Thus older kernels won't be able to
"discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the device
irrespective of the mode of access. This creates a problem where two
different drivers (both AMBA based driver and platform driver) would
hook into the "HID" and could conflict. e.g., if AMBA driver gets
hold of a non-MMIO device, the probe fails. If we have single driver
hooked into the given "HID", we could handle them seamlessly,
irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With
ACPI, amba_driver doesn't get us anywhere with handling the power
and thus one need to always turn the power ON to use them. Moving to
platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices to be
supported via tha platform driver. The series makes the existing platform
driver generic to handle both type of the access modes. Although existing
AMBA driver would still continue to support DT based etm4x MMIO devices.
Although some problems still remain, such as manually adding PIDs for all
new AMBA DT based devices.
The series applies on 6.5-rc1.
Changes in V6:
- Rebased on 6.5-rc1
I have queued this version for v6.6, should appear on coresight/next soon.
Suzuki
From: Steve Clevenger OS <hidden> Date: 2023-07-26 17:03:41
Hi Suzuki,
On 7/26/2023 9:59 AM, Suzuki K Poulose wrote:
On 10/07/2023 07:24, Anshuman Khandual wrote:
quoted
CoreSight ETM4x devices could be accessed either via MMIO (handled via
amba_driver) or CPU system instructions (handled via platform driver).
But
this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on
adding the "known" PIDs to get it working with AMBA driver. While
the ETM4 architecture (and CoreSight architecture) defines way to
identify a device as ETM4. Thus older kernels won't be able to
"discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the
device
irrespective of the mode of access. This creates a problem where two
different drivers (both AMBA based driver and platform driver) would
hook into the "HID" and could conflict. e.g., if AMBA driver gets
hold of a non-MMIO device, the probe fails. If we have single driver
hooked into the given "HID", we could handle them seamlessly,
irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With
ACPI, amba_driver doesn't get us anywhere with handling the power
and thus one need to always turn the power ON to use them. Moving to
platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices
to be
supported via tha platform driver. The series makes the existing platform
driver generic to handle both type of the access modes. Although existing
AMBA driver would still continue to support DT based etm4x MMIO devices.
Although some problems still remain, such as manually adding PIDs for all
new AMBA DT based devices.
The series applies on 6.5-rc1.
Changes in V6:
- Rebased on 6.5-rc1
I have queued this version for v6.6, should appear on coresight/next soon.
Suzuki
Is there anyway to queue this for 6.5? Or has that ship sailed?
Thanks,
Steve C.
From: Suzuki K Poulose <suzuki.poulose@arm.com> Date: 2023-07-26 17:33:12
On 26/07/2023 18:03, Steve Clevenger OS wrote:
Hi Suzuki,
On 7/26/2023 9:59 AM, Suzuki K Poulose wrote:
quoted
On 10/07/2023 07:24, Anshuman Khandual wrote:
quoted
CoreSight ETM4x devices could be accessed either via MMIO (handled via
amba_driver) or CPU system instructions (handled via platform driver).
But
this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on
adding the "known" PIDs to get it working with AMBA driver. While
the ETM4 architecture (and CoreSight architecture) defines way to
identify a device as ETM4. Thus older kernels won't be able to
"discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the
device
irrespective of the mode of access. This creates a problem where two
different drivers (both AMBA based driver and platform driver) would
hook into the "HID" and could conflict. e.g., if AMBA driver gets
hold of a non-MMIO device, the probe fails. If we have single driver
hooked into the given "HID", we could handle them seamlessly,
irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With
ACPI, amba_driver doesn't get us anywhere with handling the power
and thus one need to always turn the power ON to use them. Moving to
platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices
to be
supported via tha platform driver. The series makes the existing platform
driver generic to handle both type of the access modes. Although existing
AMBA driver would still continue to support DT based etm4x MMIO devices.
Although some problems still remain, such as manually adding PIDs for all
new AMBA DT based devices.
The series applies on 6.5-rc1.
Changes in V6:
- Rebased on 6.5-rc1
I have queued this version for v6.6, should appear on coresight/next soon.
Suzuki
Is there anyway to queue this for 6.5? Or has that ship sailed?
Only fixes are allowed for v6.5 at this time.
Suzuki