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/[email protected]/
- 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/[email protected]/
- 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/[email protected]/
- 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/[email protected]/
- 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/[email protected]/
Cc: Ganapatrao Kulkarni <[email protected]>
Cc: Steve Clevenger <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Frank Rowand <[email protected]>
Cc: Russell King (Oracle) <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Mathieu Poirier <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
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 <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Anshuman Khandual <[email protected]>
---
.../coresight/coresight-etm4x-core.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 7e307022303a..264242ba345b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2046,17 +2046,14 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
{
- struct etmv4_drvdata *drvdata;
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
struct csdev_access access = { 0 };
struct etm4_init_arg init_arg = { 0 };
struct etm4_init_arg *delayed;
- drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata)
+ if (WARN_ON(!drvdata))
return -ENOMEM;
- dev_set_drvdata(dev, drvdata);
-
if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE)
pm_save_enable = coresight_loses_context_with_cpu(dev) ?
PARAM_PM_SAVE_SELF_HOSTED : PARAM_PM_SAVE_NEVER;
@@ -2108,6 +2105,7 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
{
+ struct etmv4_drvdata *drvdata;
void __iomem *base;
struct device *dev = &adev->dev;
struct resource *res = &adev->res;
@@ -2118,6 +2116,11 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
if (IS_ERR(base))
return PTR_ERR(base);
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, drvdata);
ret = etm4_probe(dev, base, id->id);
if (!ret)
pm_runtime_put(&adev->dev);
@@ -2127,8 +2130,14 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
static int etm4_probe_platform_dev(struct platform_device *pdev)
{
+ struct etmv4_drvdata *drvdata;
int ret;
+ drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ dev_set_drvdata(&pdev->dev, drvdata);
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
--
2.25.1
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 <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Anshuman Khandual <[email protected]>
---
.../coresight/coresight-etm4x-core.c | 29 ++++++++++---------
include/linux/coresight.h | 12 ++++++++
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index bf93147c23ca..e91e59ecec53 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -66,7 +66,6 @@ static u64 etm4_get_access_type(struct etmv4_config *config);
static enum cpuhp_state hp_online;
struct etm4_init_arg {
- unsigned int pid;
struct device *dev;
struct csdev_access *csa;
};
@@ -370,9 +369,17 @@ static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata)
}
static void etm4_check_arch_features(struct etmv4_drvdata *drvdata,
- unsigned int id)
+ struct csdev_access *csa)
{
- if (etm4_hisi_match_pid(id))
+ /*
+ * TRCPIDR* registers are not required for ETMs with system
+ * instructions. They must be identified by the MIDR+REVIDRs.
+ * Skip the TRCPID checks for now.
+ */
+ if (!csa->io_mem)
+ return;
+
+ if (etm4_hisi_match_pid(coresight_get_pid(csa)))
set_bit(ETM4_IMPDEF_HISI_CORE_COMMIT, drvdata->arch_features);
}
#else
@@ -385,7 +392,7 @@ static void etm4_disable_arch_specific(struct etmv4_drvdata *drvdata)
}
static void etm4_check_arch_features(struct etmv4_drvdata *drvdata,
- unsigned int id)
+ struct csdev_access *csa)
{
}
#endif /* CONFIG_ETM4X_IMPDEF_FEATURE */
@@ -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)
return 0;
}
-static int etm4_probe(struct device *dev, u32 etm_pid)
+static int etm4_probe(struct device *dev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
struct csdev_access access = { 0 };
@@ -2073,7 +2080,6 @@ static int etm4_probe(struct device *dev, u32 etm_pid)
init_arg.dev = dev;
init_arg.csa = &access;
- init_arg.pid = etm_pid;
/*
* Serialize against CPUHP callbacks to avoid race condition
@@ -2120,7 +2126,7 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
drvdata->base = base;
dev_set_drvdata(dev, drvdata);
- ret = etm4_probe(dev, id->id);
+ ret = etm4_probe(dev);
if (!ret)
pm_runtime_put(&adev->dev);
@@ -2142,12 +2148,7 @@ static int etm4_probe_platform_dev(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
- /*
- * System register based devices could match the
- * HW by reading appropriate registers on the HW
- * and thus we could skip the PID.
- */
- ret = etm4_probe(&pdev->dev, 0);
+ ret = etm4_probe(&pdev->dev);
pm_runtime_put(&pdev->dev);
return ret;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf70987240e4..255cfd283883 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -386,6 +386,18 @@ static inline u32 csdev_access_relaxed_read32(struct csdev_access *csa,
return csa->read(offset, true, false);
}
+#define CORESIGHT_PIDRn(i) (0xFE0 + ((i) * 4))
+
+static inline u32 coresight_get_pid(struct csdev_access *csa)
+{
+ u32 i, pid = 0;
+
+ for (i = 0; i < 4; i++)
+ pid |= csdev_access_relaxed_read32(csa, CORESIGHT_PIDRn(i)) << (i * 8);
+
+ return pid;
+}
+
static inline u64 csdev_access_relaxed_read_pair(struct csdev_access *csa,
u32 lo_offset, u32 hi_offset)
{
--
2.25.1
From: Suzuki K Poulose <[email protected]>
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 <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
---
drivers/hwtracing/coresight/coresight-platform.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 3e2e135cb8f6..c8940314cceb 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -669,8 +669,12 @@ static int acpi_coresight_parse_graph(struct device *dev,
struct coresight_connection *new_conn;
graph = acpi_get_coresight_graph(adev);
+ /*
+ * There are no graph connections, which is fine for some components.
+ * e.g., ETE
+ */
if (!graph)
- return -ENOENT;
+ return 0;
nlinks = graph->package.elements[2].integer.value;
if (!nlinks)
--
2.25.1
'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 <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: James Clark <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 264242ba345b..bf93147c23ca 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2044,7 +2044,7 @@ static int etm4_add_coresight_dev(struct etm4_init_arg *init_arg)
return 0;
}
-static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
+static int etm4_probe(struct device *dev, u32 etm_pid)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
struct csdev_access access = { 0 };
@@ -2065,8 +2065,6 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
return -ENOMEM;
}
- drvdata->base = base;
-
spin_lock_init(&drvdata->spinlock);
drvdata->cpu = coresight_get_cpu(dev);
@@ -2120,8 +2118,9 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
if (!drvdata)
return -ENOMEM;
+ drvdata->base = base;
dev_set_drvdata(dev, drvdata);
- ret = etm4_probe(dev, base, id->id);
+ ret = etm4_probe(dev, id->id);
if (!ret)
pm_runtime_put(&adev->dev);
@@ -2137,6 +2136,7 @@ static int etm4_probe_platform_dev(struct platform_device *pdev)
if (!drvdata)
return -ENOMEM;
+ drvdata->base = NULL;
dev_set_drvdata(&pdev->dev, drvdata);
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
@@ -2147,7 +2147,7 @@ static int etm4_probe_platform_dev(struct platform_device *pdev)
* HW by reading appropriate registers on the HW
* and thus we could skip the PID.
*/
- ret = etm4_probe(&pdev->dev, NULL, 0);
+ ret = etm4_probe(&pdev->dev, 0);
pm_runtime_put(&pdev->dev);
return ret;
--
2.25.1
From: Suzuki K Poulose <[email protected]>
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" <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Mathieu Poirier <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific changes)
Signed-off-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
---
drivers/acpi/acpi_amba.c | 1 -
drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
index f5b443ab01c2..099966cbac5a 100644
--- a/drivers/acpi/acpi_amba.c
+++ b/drivers/acpi/acpi_amba.c
@@ -22,7 +22,6 @@
static const struct acpi_device_id amba_id_list[] = {
{"ARMH0061", 0}, /* PL061 GPIO Device */
{"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
- {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
{"ARMHC501", 0}, /* ARM CoreSight ETR */
{"ARMHC502", 0}, /* ARM CoreSight STM */
{"ARMHC503", 0}, /* ARM CoreSight Debug */
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 43f583987250..703b6fcbb6a5 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -3,6 +3,7 @@
* 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>
@@ -2347,12 +2348,21 @@ static const struct of_device_id etm4_sysreg_match[] = {
{}
};
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id etm4x_acpi_ids[] = {
+ {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
+#endif
+
static struct platform_driver etm4_platform_driver = {
.probe = etm4_probe_platform_dev,
.remove = etm4_remove_platform_dev,
.driver = {
.name = "coresight-etm4x",
.of_match_table = etm4_sysreg_match,
+ .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
.suppress_bind_attrs = true,
.pm = &etm4_dev_pm_ops,
},
--
2.25.1
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 <[email protected]>
Cc: Suzuki K Poulose <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Leo Yan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Acked-by: Sudeep Holla <[email protected]>
Signed-off-by: Anshuman Khandual <[email protected]>
---
.../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(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index e91e59ecec53..43f583987250 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
+#include <linux/clk/clk-conf.h>
#include <asm/barrier.h>
#include <asm/sections.h>
@@ -1073,11 +1074,21 @@ static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata,
return true;
}
+static bool is_devtype_cpu_trace(void __iomem *base)
+{
+ u32 devtype = readl(base + TRCDEVTYPE);
+
+ return (devtype == CS_DEVTYPE_PE_TRACE);
+}
+
static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata,
struct csdev_access *csa)
{
u32 devarch = readl_relaxed(drvdata->base + TRCDEVARCH);
+ if (!is_coresight_device(drvdata->base) || !is_devtype_cpu_trace(drvdata->base))
+ return false;
+
/*
* All ETMs must implement TRCDEVARCH to indicate that
* the component is an ETMv4. Even though TRCIDR1 also
@@ -2135,6 +2146,7 @@ static int etm4_probe_amba(struct amba_device *adev, const struct amba_id *id)
static int etm4_probe_platform_dev(struct platform_device *pdev)
{
+ struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct etmv4_drvdata *drvdata;
int ret;
@@ -2142,7 +2154,18 @@ static int etm4_probe_platform_dev(struct platform_device *pdev)
if (!drvdata)
return -ENOMEM;
- drvdata->base = NULL;
+ drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev);
+ if (IS_ERR(drvdata->pclk))
+ return -ENODEV;
+
+ if (res) {
+ drvdata->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(drvdata->base)) {
+ clk_put(drvdata->pclk);
+ return PTR_ERR(drvdata->base);
+ }
+ }
+
dev_set_drvdata(&pdev->dev, drvdata);
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
@@ -2188,7 +2211,7 @@ static struct amba_cs_uci_id uci_id_etm4[] = {
/* ETMv4 UCI data */
.devarch = ETM_DEVARCH_ETMv4x_ARCH,
.devarch_mask = ETM_DEVARCH_ID_MASK,
- .devtype = 0x00000013,
+ .devtype = CS_DEVTYPE_PE_TRACE,
}
};
@@ -2244,6 +2267,10 @@ static int __exit etm4_remove_platform_dev(struct platform_device *pdev)
if (drvdata)
etm4_remove_dev(drvdata);
pm_runtime_disable(&pdev->dev);
+
+ if (drvdata->pclk)
+ clk_put(drvdata->pclk);
+
return 0;
}
@@ -2288,6 +2315,32 @@ static struct amba_driver etm4x_amba_driver = {
.id_table = etm4_ids,
};
+#ifdef CONFIG_PM
+static int etm4_runtime_suspend(struct device *dev)
+{
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
+
+ if (drvdata->pclk && !IS_ERR(drvdata->pclk))
+ clk_disable_unprepare(drvdata->pclk);
+
+ return 0;
+}
+
+static int etm4_runtime_resume(struct device *dev)
+{
+ struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
+
+ if (drvdata->pclk && !IS_ERR(drvdata->pclk))
+ clk_prepare_enable(drvdata->pclk);
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops etm4_dev_pm_ops = {
+ SET_RUNTIME_PM_OPS(etm4_runtime_suspend, etm4_runtime_resume, NULL)
+};
+
static const struct of_device_id etm4_sysreg_match[] = {
{ .compatible = "arm,coresight-etm4x-sysreg" },
{ .compatible = "arm,embedded-trace-extension" },
@@ -2301,6 +2354,7 @@ static struct platform_driver etm4_platform_driver = {
.name = "coresight-etm4x",
.of_match_table = etm4_sysreg_match,
.suppress_bind_attrs = true,
+ .pm = &etm4_dev_pm_ops,
},
};
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 27c8a9901868..20e2e4cb7614 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -701,6 +701,8 @@
#define ETM_DEVARCH_ETE_ARCH \
(ETM_DEVARCH_ARCHITECT_ARM | ETM_DEVARCH_ARCHID_ETE | ETM_DEVARCH_PRESENT)
+#define CS_DEVTYPE_PE_TRACE 0x00000013
+
#define TRCSTATR_IDLE_BIT 0
#define TRCSTATR_PMSTABLE_BIT 1
#define ETM_DEFAULT_ADDR_COMP 0
@@ -944,6 +946,7 @@ struct etmv4_save_state {
/**
* struct etm4_drvdata - specifics associated to an ETM component
+ * @pclk APB clock if present, otherwise NULL
* @base: Memory mapped base address for this component.
* @csdev: Component vitals needed by the framework.
* @spinlock: Only one at a time pls.
@@ -1009,6 +1012,7 @@ struct etmv4_save_state {
* @arch_features: Bitmap of arch features of etmv4 devices.
*/
struct etmv4_drvdata {
+ struct clk *pclk;
void __iomem *base;
struct coresight_device *csdev;
spinlock_t spinlock;
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 255cfd283883..a269fffaf991 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -6,6 +6,8 @@
#ifndef _LINUX_CORESIGHT_H
#define _LINUX_CORESIGHT_H
+#include <linux/amba/bus.h>
+#include <linux/clk.h>
#include <linux/device.h>
#include <linux/io.h>
#include <linux/perf_event.h>
@@ -386,6 +388,51 @@ static inline u32 csdev_access_relaxed_read32(struct csdev_access *csa,
return csa->read(offset, true, false);
}
+#define CORESIGHT_CIDRn(i) (0xFF0 + ((i) * 4))
+
+static inline u32 coresight_get_cid(void __iomem *base)
+{
+ u32 i, cid = 0;
+
+ for (i = 0; i < 4; i++)
+ cid |= readl(base + CORESIGHT_CIDRn(i)) << (i * 8);
+
+ return cid;
+}
+
+static inline bool is_coresight_device(void __iomem *base)
+{
+ u32 cid = coresight_get_cid(base);
+
+ return cid == CORESIGHT_CID;
+}
+
+/*
+ * Attempt to find and enable "APB clock" for the given device
+ *
+ * Returns:
+ *
+ * clk - Clock is found and enabled
+ * NULL - clock is not found
+ * ERROR - Clock is found but failed to enable
+ */
+static inline struct clk *coresight_get_enable_apb_pclk(struct device *dev)
+{
+ struct clk *pclk;
+ int ret;
+
+ pclk = clk_get(dev, "apb_pclk");
+ if (IS_ERR(pclk))
+ return NULL;
+
+ ret = clk_prepare_enable(pclk);
+ if (ret) {
+ clk_put(pclk);
+ return ERR_PTR(ret);
+ }
+ return pclk;
+}
+
#define CORESIGHT_PIDRn(i) (0xFE0 + ((i) * 4))
static inline u32 coresight_get_pid(struct csdev_access *csa)
--
2.25.1
Rafael, Len
On 10/07/2023 07:25, Anshuman Khandual wrote:
> From: Suzuki K Poulose <[email protected]>
>
> 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" <[email protected]>
> Cc: Len Brown <[email protected]>
> Cc: Mathieu Poirier <[email protected]>
> Cc: Suzuki K Poulose <[email protected]>
> Cc: Mike Leach <[email protected]>
> Cc: Leo Yan <[email protected]>
> Cc: Sudeep Holla <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific changes)
> Signed-off-by: Suzuki K Poulose <[email protected]>
> Signed-off-by: Anshuman Khandual <[email protected]>
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
> ---
> drivers/acpi/acpi_amba.c | 1 -
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> index f5b443ab01c2..099966cbac5a 100644
> --- a/drivers/acpi/acpi_amba.c
> +++ b/drivers/acpi/acpi_amba.c
> @@ -22,7 +22,6 @@
> static const struct acpi_device_id amba_id_list[] = {
> {"ARMH0061", 0}, /* PL061 GPIO Device */
> {"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
> - {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
> {"ARMHC501", 0}, /* ARM CoreSight ETR */
> {"ARMHC502", 0}, /* ARM CoreSight STM */
> {"ARMHC503", 0}, /* ARM CoreSight Debug */
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 43f583987250..703b6fcbb6a5 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -3,6 +3,7 @@
> * 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>
> @@ -2347,12 +2348,21 @@ static const struct of_device_id etm4_sysreg_match[] = {
> {}
> };
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id etm4x_acpi_ids[] = {
> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
> +#endif
> +
> static struct platform_driver etm4_platform_driver = {
> .probe = etm4_probe_platform_dev,
> .remove = etm4_remove_platform_dev,
> .driver = {
> .name = "coresight-etm4x",
> .of_match_table = etm4_sysreg_match,
> + .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
> .suppress_bind_attrs = true,
> .pm = &etm4_dev_pm_ops,
> },
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:
>> From: Suzuki K Poulose <[email protected]>
>>
>> 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" <[email protected]>
>> Cc: Len Brown <[email protected]>
>> Cc: Mathieu Poirier <[email protected]>
>> Cc: Suzuki K Poulose <[email protected]>
>> Cc: Mike Leach <[email protected]>
>> Cc: Leo Yan <[email protected]>
>> Cc: Sudeep Holla <[email protected]>
>> Cc: Lorenzo Pieralisi <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
>> changes)
>> Signed-off-by: Suzuki K Poulose <[email protected]>
>> Signed-off-by: Anshuman Khandual <[email protected]>
>
> 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
> Kind regards
> Suzuki
>
>
>> ---
>> drivers/acpi/acpi_amba.c | 1 -
>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>> index f5b443ab01c2..099966cbac5a 100644
>> --- a/drivers/acpi/acpi_amba.c
>> +++ b/drivers/acpi/acpi_amba.c
>> @@ -22,7 +22,6 @@
>> static const struct acpi_device_id amba_id_list[] = {
>> {"ARMH0061", 0}, /* PL061 GPIO Device */
>> {"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
>> - {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>> {"ARMHC501", 0}, /* ARM CoreSight ETR */
>> {"ARMHC502", 0}, /* ARM CoreSight STM */
>> {"ARMHC503", 0}, /* ARM CoreSight Debug */
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> index 43f583987250..703b6fcbb6a5 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> @@ -3,6 +3,7 @@
>> * 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>
>> @@ -2347,12 +2348,21 @@ static const struct of_device_id
>> etm4_sysreg_match[] = {
>> {}
>> };
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id etm4x_acpi_ids[] = {
>> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
>> +#endif
>> +
>> static struct platform_driver etm4_platform_driver = {
>> .probe = etm4_probe_platform_dev,
>> .remove = etm4_remove_platform_dev,
>> .driver = {
>> .name = "coresight-etm4x",
>> .of_match_table = etm4_sysreg_match,
>> + .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
>> .suppress_bind_attrs = true,
>> .pm = &etm4_dev_pm_ops,
>> },
>
Hi Rafael, Len, Suzuki,
> Rafael, Len
>
> Ping (packets 6, lost 100%).
>
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 <[email protected]>
With Regards,
Tanmay
>
> On 10/07/2023 17:40, Suzuki K Poulose wrote:
> > Rafael, Len
> >
> > On 10/07/2023 07:25, Anshuman Khandual wrote:
> >> From: Suzuki K Poulose <[email protected]>
> >>
> >> 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" <[email protected]>
> >> Cc: Len Brown <[email protected]>
> >> Cc: Mathieu Poirier <[email protected]>
> >> Cc: Suzuki K Poulose <[email protected]>
> >> Cc: Mike Leach <[email protected]>
> >> Cc: Leo Yan <[email protected]>
> >> Cc: Sudeep Holla <[email protected]>
> >> Cc: Lorenzo Pieralisi <[email protected]>
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
> >> changes)
> >> Signed-off-by: Suzuki K Poulose <[email protected]>
> >> Signed-off-by: Anshuman Khandual <[email protected]>
> >
> > 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
>
> > Kind regards
> > Suzuki
> >
> >
> >> ---
> >> drivers/acpi/acpi_amba.c | 1 -
> >> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
> >> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
> >> index f5b443ab01c2..099966cbac5a 100644
> >> --- a/drivers/acpi/acpi_amba.c
> >> +++ b/drivers/acpi/acpi_amba.c
> >> @@ -22,7 +22,6 @@
> >> static const struct acpi_device_id amba_id_list[] = {
> >> {"ARMH0061", 0}, /* PL061 GPIO Device */
> >> {"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
> >> - {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
> >> {"ARMHC501", 0}, /* ARM CoreSight ETR */
> >> {"ARMHC502", 0}, /* ARM CoreSight STM */
> >> {"ARMHC503", 0}, /* ARM CoreSight Debug */
> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> >> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> >> index 43f583987250..703b6fcbb6a5 100644
> >> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> >> @@ -3,6 +3,7 @@
> >> * 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>
> >> @@ -2347,12 +2348,21 @@ static const struct of_device_id
> >> etm4_sysreg_match[] = {
> >> {}
> >> };
> >> +#ifdef CONFIG_ACPI
> >> +static const struct acpi_device_id etm4x_acpi_ids[] = {
> >> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
> >> + {}
> >> +};
> >> +MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
> >> +#endif
> >> +
> >> static struct platform_driver etm4_platform_driver = {
> >> .probe = etm4_probe_platform_dev,
> >> .remove = etm4_remove_platform_dev,
> >> .driver = {
> >> .name = "coresight-etm4x",
> >> .of_match_table = etm4_sysreg_match,
> >> + .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
> >> .suppress_bind_attrs = true,
> >> .pm = &etm4_dev_pm_ops,
> >> },
> >
>
> _______________________________________________
> CoreSight mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
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:
>> Rafael, Len
>>
>> On 10/07/2023 07:25, Anshuman Khandual wrote:
>>> From: Suzuki K Poulose <[email protected]>
>>>
>>> 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" <[email protected]>
>>> Cc: Len Brown <[email protected]>
>>> Cc: Mathieu Poirier <[email protected]>
>>> Cc: Suzuki K Poulose <[email protected]>
>>> Cc: Mike Leach <[email protected]>
>>> Cc: Leo Yan <[email protected]>
>>> Cc: Sudeep Holla <[email protected]>
>>> Cc: Lorenzo Pieralisi <[email protected]>
>>> Cc: [email protected]
>>> Cc: [email protected]
>>> Cc: [email protected]
>>> Cc: [email protected]
>>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
>>> changes)
>>> Signed-off-by: Suzuki K Poulose <[email protected]>
>>> Signed-off-by: Anshuman Khandual <[email protected]>
>>
>> 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
>
> Kind regards
> Suzuki
>
>> Kind regards
>> Suzuki
>>
>>
>>> ---
>>> drivers/acpi/acpi_amba.c | 1 -
>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>>> index f5b443ab01c2..099966cbac5a 100644
>>> --- a/drivers/acpi/acpi_amba.c
>>> +++ b/drivers/acpi/acpi_amba.c
>>> @@ -22,7 +22,6 @@
>>> static const struct acpi_device_id amba_id_list[] = {
>>> {"ARMH0061", 0}, /* PL061 GPIO Device */
>>> {"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
>>> - {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>>> {"ARMHC501", 0}, /* ARM CoreSight ETR */
>>> {"ARMHC502", 0}, /* ARM CoreSight STM */
>>> {"ARMHC503", 0}, /* ARM CoreSight Debug */
>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>> index 43f583987250..703b6fcbb6a5 100644
>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>> @@ -3,6 +3,7 @@
>>> * 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>
>>> @@ -2347,12 +2348,21 @@ static const struct of_device_id
>>> etm4_sysreg_match[] = {
>>> {}
>>> };
>>> +#ifdef CONFIG_ACPI
>>> +static const struct acpi_device_id etm4x_acpi_ids[] = {
>>> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
>>> +#endif
>>> +
>>> static struct platform_driver etm4_platform_driver = {
>>> .probe = etm4_probe_platform_dev,
>>> .remove = etm4_remove_platform_dev,
>>> .driver = {
>>> .name = "coresight-etm4x",
>>> .of_match_table = etm4_sysreg_match,
>>> + .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
>>> .suppress_bind_attrs = true,
>>> .pm = &etm4_dev_pm_ops,
>>> },
>>
>
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:
>> 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:
>>>> From: Suzuki K Poulose <[email protected]>
>>>>
>>>> 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" <[email protected]>
>>>> Cc: Len Brown <[email protected]>
>>>> Cc: Mathieu Poirier <[email protected]>
>>>> Cc: Suzuki K Poulose <[email protected]>
>>>> Cc: Mike Leach <[email protected]>
>>>> Cc: Leo Yan <[email protected]>
>>>> Cc: Sudeep Holla <[email protected]>
>>>> Cc: Lorenzo Pieralisi <[email protected]>
>>>> Cc: [email protected]
>>>> Cc: [email protected]
>>>> Cc: [email protected]
>>>> Cc: [email protected]
>>>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
>>>> changes)
>>>> Signed-off-by: Suzuki K Poulose <[email protected]>
>>>> Signed-off-by: Anshuman Khandual <[email protected]>
>>>
>>> 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.
>
>>
>> Kind regards
>> Suzuki
>>
>>> Kind regards
>>> Suzuki
>>>
>>>
>>>> ---
>>>> drivers/acpi/acpi_amba.c | 1 -
>>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 10 ++++++++++
>>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/acpi/acpi_amba.c b/drivers/acpi/acpi_amba.c
>>>> index f5b443ab01c2..099966cbac5a 100644
>>>> --- a/drivers/acpi/acpi_amba.c
>>>> +++ b/drivers/acpi/acpi_amba.c
>>>> @@ -22,7 +22,6 @@
>>>> static const struct acpi_device_id amba_id_list[] = {
>>>> {"ARMH0061", 0}, /* PL061 GPIO Device */
>>>> {"ARMH0330", 0}, /* ARM DMA Controller DMA-330 */
>>>> - {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>>>> {"ARMHC501", 0}, /* ARM CoreSight ETR */
>>>> {"ARMHC502", 0}, /* ARM CoreSight STM */
>>>> {"ARMHC503", 0}, /* ARM CoreSight Debug */
>>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> index 43f583987250..703b6fcbb6a5 100644
>>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>>>> @@ -3,6 +3,7 @@
>>>> * 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>
>>>> @@ -2347,12 +2348,21 @@ static const struct of_device_id
>>>> etm4_sysreg_match[] = {
>>>> {}
>>>> };
>>>> +#ifdef CONFIG_ACPI
>>>> +static const struct acpi_device_id etm4x_acpi_ids[] = {
>>>> + {"ARMHC500", 0}, /* ARM CoreSight ETM4x */
>>>> + {}
>>>> +};
>>>> +MODULE_DEVICE_TABLE(acpi, etm4x_acpi_ids);
>>>> +#endif
>>>> +
>>>> static struct platform_driver etm4_platform_driver = {
>>>> .probe = etm4_probe_platform_dev,
>>>> .remove = etm4_remove_platform_dev,
>>>> .driver = {
>>>> .name = "coresight-etm4x",
>>>> .of_match_table = etm4_sysreg_match,
>>>> + .acpi_match_table = ACPI_PTR(etm4x_acpi_ids),
>>>> .suppress_bind_attrs = true,
>>>> .pm = &etm4_dev_pm_ops,
>>>> },
>>>
>>
>
On 25/07/2023 15:30, Rafael J. Wysocki wrote:
> On Tue, Jul 25, 2023 at 4:040x202FPM Suzuki K Poulose <[email protected]> wrote:
>>
>> On 25/07/2023 15:00, Rafael J. Wysocki wrote:
>>> On Tue, Jul 25, 2023 at 3:270x202FPM Suzuki K Poulose <[email protected]> wrote:
>>>>
>>>> On 25/07/2023 13:28, Rafael J. Wysocki wrote:
>>>>> On Tue, Jul 25, 2023 at 12:350x202FPM Suzuki K Poulose
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> Hi Rafael
>>>>>>
>>>>>> Apologies for hijacking this thread, but please please could
>>>>>> you respond to the following patch ?
>>>>>>
>>>>>> We have been waiting for your Ack since last two months.
>>>>>>
>>>>>> https://lkml.kernel.org/r/[email protected]
>>>>>
>>>>> Sorry about that, but I'm not sure why you need an ACK from me for
>>>>> this.0x00A0 AMBA is an ARM thing and I'm not even familiar with the driver
>>>>> in question.
>>>>>
>>>>
>>>> I understand, but there is a change to the drivers/acpi/acpi_amba.c ,
>>>> which is technically under your maintenance. The change is removing
>>>> the custom hook for the ETMv4 ID from the AMBA list and moving it
>>>> directly under the ETMv4 driver. Greg would like an Ack from you
>>>> before that can be queued. It missed the merged window last time
>>>> due to that and didn't want to miss it again this time.
>>>
>>> OK, so please feel free to add an ACK from me to that patch.
>>>
>>
>> Thanks.
>>
>>> It also would be good to find an ARM maintainer for acpi_amba.c, so
>>> people don't have to wait for my ACK on every change in that file.
>>
>> Sudeep Holla (our resident ACPI expert) has reviewed the patch, but
>> I guess he is in the Reviewer ranks.
>
> Well, next time you get a Reviewed-by from Sudeep on ARM-related ACPI
> material, it is far more meaningful than my ACK.0x00A0 You probably don't
> need the latter if you have the former.
Thanks Rafael.
For others wondering about the weird threading, the above happened via private
exchange of emails and linking to this patch for the record.
Suzuki
On Wed, Jul 26, 2023 at 03:05:15PM +0100, Suzuki K Poulose wrote:
> On 25/07/2023 15:30, Rafael J. Wysocki wrote:
> > On Tue, Jul 25, 2023 at 4:040x202FPM Suzuki K Poulose <[email protected]> wrote:
> >>
> >> On 25/07/2023 15:00, Rafael J. Wysocki wrote:
> >>> On Tue, Jul 25, 2023 at 3:270x202FPM Suzuki K Poulose <[email protected]> wrote:
> >>>>
> >>>> On 25/07/2023 13:28, Rafael J. Wysocki wrote:
> >>>>> On Tue, Jul 25, 2023 at 12:350x202FPM Suzuki K Poulose
> >>>>> <[email protected]> wrote:
> >>>>>>
> >>>>>> Hi Rafael
> >>>>>>
> >>>>>> Apologies for hijacking this thread, but please please could
> >>>>>> you respond to the following patch ?
> >>>>>>
> >>>>>> We have been waiting for your Ack since last two months.
> >>>>>>
> >>>>>> https://lkml.kernel.org/r/[email protected]
> >>>>>
> >>>>> Sorry about that, but I'm not sure why you need an ACK from me for
> >>>>> this.0x00A0 AMBA is an ARM thing and I'm not even familiar with the driver
> >>>>> in question.
> >>>>>
> >>>>
> >>>> I understand, but there is a change to the drivers/acpi/acpi_amba.c ,
> >>>> which is technically under your maintenance. The change is removing
> >>>> the custom hook for the ETMv4 ID from the AMBA list and moving it
> >>>> directly under the ETMv4 driver. Greg would like an Ack from you
> >>>> before that can be queued. It missed the merged window last time
> >>>> due to that and didn't want to miss it again this time.
> >>>
> >>> OK, so please feel free to add an ACK from me to that patch.
> >>>
> >>
> >> Thanks.
> >>
> >>> It also would be good to find an ARM maintainer for acpi_amba.c, so
> >>> people don't have to wait for my ACK on every change in that file.
> >>
> >> Sudeep Holla (our resident ACPI expert) has reviewed the patch, but
> >> I guess he is in the Reviewer ranks.
> >
> > Well, next time you get a Reviewed-by from Sudeep on ARM-related ACPI
> > material, it is far more meaningful than my ACK.0x00A0 You probably don't
> > need the latter if you have the former.
Thanks Rafael and this aligns with my understanding. I had mentioned to
Suzuki informally. Since I wasn't sure why this was not covered under
Arm ACPI maintainership for whatever historical reasons, I didn't make
it formally on the list. I think it would be better if we move that file
under it to be explicit and avoid any confusion in the future. I will
send the update soon.
--
Regards,
Sudeep
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
> <[email protected]> wrote:
> >
> >
> > 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:
> > >> 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:
> > >>>> From: Suzuki K Poulose <[email protected]>
> > >>>>
> > >>>> 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" <[email protected]>
> > >>>> Cc: Len Brown <[email protected]>
> > >>>> Cc: Mathieu Poirier <[email protected]>
> > >>>> Cc: Suzuki K Poulose <[email protected]>
> > >>>> Cc: Mike Leach <[email protected]>
> > >>>> Cc: Leo Yan <[email protected]>
> > >>>> Cc: Sudeep Holla <[email protected]>
> > >>>> Cc: Lorenzo Pieralisi <[email protected]>
> > >>>> Cc: [email protected]
> > >>>> Cc: [email protected]
> > >>>> Cc: [email protected]
> > >>>> Cc: [email protected]
> > >>>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
> > >>>> changes)
> > >>>> Signed-off-by: Suzuki K Poulose <[email protected]>
> > >>>> Signed-off-by: Anshuman Khandual <[email protected]>
> > >>>
> > >>> 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/[email protected]
>
> 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
On Tue, Jul 25, 2023 at 10:18 PM Steve Clevenger OS
<[email protected]> wrote:
>
>
> 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:
> >> 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:
> >>>> From: Suzuki K Poulose <[email protected]>
> >>>>
> >>>> 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" <[email protected]>
> >>>> Cc: Len Brown <[email protected]>
> >>>> Cc: Mathieu Poirier <[email protected]>
> >>>> Cc: Suzuki K Poulose <[email protected]>
> >>>> Cc: Mike Leach <[email protected]>
> >>>> Cc: Leo Yan <[email protected]>
> >>>> Cc: Sudeep Holla <[email protected]>
> >>>> Cc: Lorenzo Pieralisi <[email protected]>
> >>>> Cc: [email protected]
> >>>> Cc: [email protected]
> >>>> Cc: [email protected]
> >>>> Cc: [email protected]
> >>>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
> >>>> changes)
> >>>> Signed-off-by: Suzuki K Poulose <[email protected]>
> >>>> Signed-off-by: Anshuman Khandual <[email protected]>
> >>>
> >>> 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/[email protected]
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 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
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:
>> On Tue, Jul 25, 2023 at 10:18 PM Steve Clevenger OS
>> <[email protected]> wrote:
>>>
>>>
>>> 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:
>>>>> 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:
>>>>>>> From: Suzuki K Poulose <[email protected]>
>>>>>>>
>>>>>>> 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" <[email protected]>
>>>>>>> Cc: Len Brown <[email protected]>
>>>>>>> Cc: Mathieu Poirier <[email protected]>
>>>>>>> Cc: Suzuki K Poulose <[email protected]>
>>>>>>> Cc: Mike Leach <[email protected]>
>>>>>>> Cc: Leo Yan <[email protected]>
>>>>>>> Cc: Sudeep Holla <[email protected]>
>>>>>>> Cc: Lorenzo Pieralisi <[email protected]>
>>>>>>> Cc: [email protected]
>>>>>>> Cc: [email protected]
>>>>>>> Cc: [email protected]
>>>>>>> Cc: [email protected]
>>>>>>> Reviewed-by: Sudeep Holla <[email protected]> (for ACPI specific
>>>>>>> changes)
>>>>>>> Signed-off-by: Suzuki K Poulose <[email protected]>
>>>>>>> Signed-off-by: Anshuman Khandual <[email protected]>
>>>>>>
>>>>>> 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/[email protected]
>>
>> 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.
>
Thank you.
Steve C.
Hi Suzuki,
On 7/26/2023 9:59 AM, Suzuki K Poulose wrote:
> 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
Is there anyway to queue this for 6.5? Or has that ship sailed?
Thanks,
Steve C.
On 26/07/2023 18:03, Steve Clevenger OS wrote:
>
> Hi Suzuki,
>
> On 7/26/2023 9:59 AM, Suzuki K Poulose wrote:
>> 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
>
> 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
>
> Thanks,
>
> Steve C.