On 01/06/2023 10:33, Greg KH wrote:
> On Wed, May 31, 2023 at 11:44:55PM +0100, Suzuki K Poulose wrote:
>> (Removed irrelevant recipients), +Cc: coresight ml
>>
>> Hi Greg,
>>
>> On 15/05/2023 12:55, Greg KH wrote:
>>> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>>>
>>>>
>>>> On 13/05/2023 12:04, Greg KH wrote:
>>>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>>>> do their own multiplication overflow check so provide one.
>>>>>>
>>>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
>>>>>> Signed-off-by: James Clark <james.clark(a)arm.com>
>>>>>> ---
>>>>>> Documentation/driver-api/driver-model/devres.rst | 1 +
>>>>>> include/linux/device.h | 11 +++++++++++
>>>>>> 2 files changed, 12 insertions(+)
>>
>> ...
>>
>>>> Maybe something could be done with some macro magic, but it would
>>>> probably end up being worse than just copying them and would affect the
>>>> real ones as well. So yeah I can't think of any easy gains either.
>>>
>>> Ok, that's good. Given a lack of objections from others, I'll just take
>>> this through my driver core tree in a few days.
>>
>> Apologies for hijacking the thread. We have a series for CoreSight[1]
>> that depends on this series, which I see that, is queued in your
>> driver-core-next.
>>
>> I would like to queue [1] for the next version (as there are other
>> work that depend on this, e.g., [2]). Do you have any
>> recommendations/comments on the proposal ? Are you able to share a
>> stable branch which can be merged to coresight/next and queue the
>> series ontop ? (PS: I haven't queued anything for coresight/next yet).
>
> You can pull from my driver-core-next branch just fine and assume it
> will be stable. So just pull in that one commit and all should be good
> in the future.
Thanks Greg, I will give it a go
Suzuki
>
> thanks,
>
> greg k-h
All,
This is an RFC patch to allow all ETM4 instances to be detected via AMBA driver
without having to add the PIDs to the list. The AMBA driver already supports
checking the DEVTYPE and DEVARCH registers for CoreSight components. This patch
adds a pid,mask value that is bound to match all PIDs (with PIDR2.JEDEC field
mandated to be RA0).
With this patch, we wouldn't need to add the PIDs for newer CPUs to be able to
use them. An entry in the device tree is all we need. The only side effect of
this patch is :
If a DT description exists for an ETM and the CPU ETM has an erratum, the
driver may still probe it and use it. But then the DT shouldn't have
described it in the first place.
Thoughts?
Suzuki
---8>---
coresight: etm4x: Match all ETM4 instances based on DEVARCH
Instead of adding the PIDs forever to the list for the new CPUs, let us detect
a component to be ETMv4 based on the CoreSight CID, DEVTYPE=PE_TRACE and
DEVARCH=ETMv4. This is already done for some of the ETMs. We can extend the PID
matching to match the PIDR2:JEDEC, BIT[3], which must be 1 (RA0) always.
Link: https://lkml.kernel.org/r/20230317030501.1811905-1-anshuman.khandual@arm.com
Cc: Anshuman Khandual <anshuman.khandual(a)arm.com>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: frowand.list(a)gmail.com
Cc: linux(a)armlinux.org.uk
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
---
.../coresight/coresight-etm4x-core.c | 5 +++++
drivers/hwtracing/coresight/coresight-priv.h | 19 +++++++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 4c15fae534f3..8a2e24d5686a 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2260,6 +2260,11 @@ static const struct amba_id etm4_ids[] = {
CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
CS_AMBA_UCI_ID(0x000b6d01, uci_id_etm4),/* HiSilicon-Hip08 */
CS_AMBA_UCI_ID(0x000b6d02, uci_id_etm4),/* HiSilicon-Hip09 */
+ /*
+ * Match all PIDs with ETM4 DEVARCH. No need for adding any of the new
+ * CPUs to the list here.
+ */
+ CS_AMBA_MATCH_ALL_UCI(uci_id_etm4),
{},
};
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 595ce5862056..72ec36c9232c 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -193,12 +193,27 @@ extern void coresight_remove_cti_ops(void);
}
/* coresight AMBA ID, full UCI structure: id table entry. */
-#define CS_AMBA_UCI_ID(pid, uci_ptr) \
+#define __CS_AMBA_UCI_ID(pid, m, uci_ptr) \
{ \
.id = pid, \
- .mask = 0x000fffff, \
+ .mask = m, \
.data = (void *)uci_ptr \
}
+#define CS_AMBA_UCI_ID(pid, uci) __CS_AMBA_UCI_ID(pid, 0x000fffff, uci)
+/*
+ * PIDR2[JEDEC], BIT(3) must be 1 (Read As One) to indicate that rest of the
+ * PIDR1, PIDR2 DES_* fields follow JEDEC encoding for the designer. Use that
+ * as a match value for blanket matching all devices in the given CoreSight
+ * device type and architecture.
+ */
+#define PIDR2_JEDEC BIT(3)
+#define PID_PIDR2_JEDEC (PIDR2_JEDEC << 16)
+/*
+ * Match all PIDs in a given CoreSight device type and architecture, defined
+ * by the uci.
+ */
+#define CS_AMBA_MATCH_ALL_UCI(uci) \
+ __CS_AMBA_UCI_ID(PID_PIDR2_JEDEC, PID_PIDR2_JEDEC, uci)
/* extract the data value from a UCI structure given amba_id pointer. */
static inline void *coresight_get_uci_data(const struct amba_id *id)
--
2.34.1
This series converts TRBE registers to automatic generation, after renaming
their fields as per the auto-gen tools format. Although the following field
still renames in arch/arm64/include/asm/sysreg.h, as it cannot be converted
(shares bits with other fields) in the tools format.
#define TRBSR_EL1_BSC_MASK GENMASK(5, 0)
#define TRBSR_EL1_BSC_SHIFT 0
This series applies on v6.4-rc4.
Changes in V2:
- Renamed each individual TRBE register fields as per auto-gen tools
- Converted each individual TRBE registers as per auto-gen tools
- Added new register fields as per DDI0601 2023-03
Changes in V1:
https://lore.kernel.org/all/20230531055524.16562-1-anshuman.khandual@arm.co…
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Will Deacon <will(a)kernel.org>
Cc: Marc Zyngier <maz(a)kernel.org>
Cc: Mark Brown <broonie(a)kernel.org>
Cc: Rob Herring <robh(a)kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
Cc: kvmarm(a)lists.linux.dev
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Anshuman Khandual (14):
arm64/sysreg: Rename TRBLIMITR_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBPTR_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBBASER_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBSR_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBMAR_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBTRG_EL1 fields per auto-gen tools format
arm64/sysreg: Rename TRBIDR_EL1 fields per auto-gen tools format
arm64/sysreg: Convert TRBLIMITR_EL1 register to automatic generation
arm64/sysreg: Convert TRBPTR_EL1 register to automatic generation
arm64/sysreg: Convert TRBBASER_EL1 register to automatic generation
arm64/sysreg: Convert TRBSR_EL1 register to automatic generation
arm64/sysreg: Convert TRBMAR_EL1 register to automatic generation
arm64/sysreg: Convert TRBTRG_EL1 register to automatic generation
arm64/sysreg: Convert TRBIDR_EL1 register to automatic generation
arch/arm64/include/asm/el2_setup.h | 2 +-
arch/arm64/include/asm/sysreg.h | 50 +--------------
arch/arm64/kvm/debug.c | 2 +-
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 2 +-
arch/arm64/tools/sysreg | 64 ++++++++++++++++++++
drivers/hwtracing/coresight/coresight-trbe.c | 33 +++++-----
drivers/hwtracing/coresight/coresight-trbe.h | 38 +++++-------
7 files changed, 101 insertions(+), 90 deletions(-)
--
2.25.1
On 5/23/2023 3:50 PM, Tao Zhang wrote:
> On 4/28/2023 12:53 AM, Suzuki K Poulose wrote:
>> On 27/04/2023 10:00, Tao Zhang wrote:
>>> Introduction of TPDM DSB subunit
>>> DSB subunit is responsible for creating a dataset element, and is also
>>> optionally responsible for packing it to fit multiple elements on a
>>> single ATB transfer if possible in the configuration. The TPDM Core
>>> Datapath requests timestamps be stored by the TPDA and then delivering
>>> ATB sized data (depending on ATB width and element size, this could
>>> be smaller or larger than a dataset element) to the ATB Mast FSM.
>>>
>>> The DSB subunit must be configured prior to enablement. This series
>>> adds support for TPDM to configure the configure DSB subunit.
>>>
>>> Once this series patches are applied properly, the new tpdm nodes for
>>> should be observed at the tpdm path /sys/bus/coresight/devices/tpdm*
>>> which supports DSB subunit.
>>> e.g.
>>> /sys/devices/platform/soc(a)0/69d0000.tpdm/tpdm0#ls -l | grep dsb
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_edge_ctrl_mask
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_mode
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_mask
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_ts
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_type
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_patt_val
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_mask
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_patt_val
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_ts
>>> -rw-r--r-- 1 root root 4096 Jan 1 00:01 dsb_trig_type
>>>
>>> We can use the commands are similar to the below to configure the
>>> TPDMs which support DSB subunit. Enable coresight sink first.
>>> echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
>>> echo 1 > /sys/bus/coresight/devices/tpdm0/reset
>>> echo 0x3 0x3 0x1 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl_mask
>>> echo 0x6d 0x6d 0 > /sys/bus/coresight/devices/tpdm0/dsb_edge_ctrl
>>> echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_ts
>>> echo 1 > /sys/bus/coresight/devices/tpdm0/dsb_patt_type
>>> echo 0 > /sys/bus/coresight/devices/tpdm0/dsb_trig_ts
>>> echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_patt_mask
>>> echo 0 0xFFFFFFFF > /sys/bus/coresight/devices/tpdm0/dsb_trig_patt_val
>>>
>>> This patch series depends on patch series "[PATCH v2 0/9] coresight:
>>> Fix CTI module refcount leak by making it a helper device"
>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20230425143542.…
>>>
>>
>> There is v6 available for the above and there may be changes in the data
>> structures. But the series is stable now, and may be you could cordinate
>> with James and repost the series at rc1 ?
>
> This patch series has depended on James's v6 patch series. It's a
> description mistake.
>
> The link I posted is James's v6 patch series.
>
> Would you mind continue to review this patch series first?
>
>
> Tao
>
Hi Suzuki,
Do you have more review comments on the rest of the patches(#5-#11) in
this series?
Or do you prefer me to update patches(#1-#4) and resubmit first?
Best,
Tao
>>
>> Suzuki
>>
>> _______________________________________________
>> CoreSight mailing list -- coresight(a)lists.linaro.org
>> To unsubscribe send an email to coresight-leave(a)lists.linaro.org
(Removed irrelevant recipients), +Cc: coresight ml
Hi Greg,
On 15/05/2023 12:55, Greg KH wrote:
> On Mon, May 15, 2023 at 08:55:33AM +0100, James Clark wrote:
>>
>>
>> On 13/05/2023 12:04, Greg KH wrote:
>>> On Tue, May 09, 2023 at 10:49:38AM +0100, James Clark wrote:
>>>> There is no krealloc_array equivalent in devres. Users would have to
>>>> do their own multiplication overflow check so provide one.
>>>>
>>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
>>>> Signed-off-by: James Clark <james.clark(a)arm.com>
>>>> ---
>>>> Documentation/driver-api/driver-model/devres.rst | 1 +
>>>> include/linux/device.h | 11 +++++++++++
>>>> 2 files changed, 12 insertions(+)
...
>> Maybe something could be done with some macro magic, but it would
>> probably end up being worse than just copying them and would affect the
>> real ones as well. So yeah I can't think of any easy gains either.
>
> Ok, that's good. Given a lack of objections from others, I'll just take
> this through my driver core tree in a few days.
Apologies for hijacking the thread. We have a series for CoreSight[1]
that depends on this series, which I see that, is queued in your
driver-core-next.
I would like to queue [1] for the next version (as there are other
work that depend on this, e.g., [2]). Do you have any
recommendations/comments on the proposal ? Are you able to share a
stable branch which can be merged to coresight/next and queue the
series ontop ? (PS: I haven't queued anything for coresight/next yet).
Kind regards
Suzuki
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.4-rc3.
Changes in V4:
- 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.…
- 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.co…
- 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.…
Cc: Ganapatrao Kulkarni <gankulkarni(a)os.amperecomputing.com>
Cc: Steve Clevenger <scclevenger(a)os.amperecomputing.com>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Frank Rowand <frowand.list(a)gmail.com>
Cc: Russell King (Oracle) <linux(a)armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael(a)kernel.org>
Cc: Len Brown <lenb(a)kernel.org>
Cc: Sudeep Holla <sudeep.holla(a)arm.com>
Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org>
Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Cc: Mike Leach <mike.leach(a)linaro.org>
Cc: Leo Yan <leo.yan(a)linaro.org>
Cc: devicetree(a)vger.kernel.org
Cc: linux-acpi(a)vger.kernel.org
Cc: coresight(a)lists.linaro.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)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 | 117 ++++++++++++++----
drivers/hwtracing/coresight/coresight-etm4x.h | 4 +
.../hwtracing/coresight/coresight-platform.c | 6 +-
include/linux/coresight.h | 59 +++++++++
5 files changed, 163 insertions(+), 24 deletions(-)
--
2.25.1
Hi Suzuki & Anshuman.
I have some questions about the new ACPI HID for ARM CoreSight ETE
and need to get you help to confirm.
a)Has ARM distributed a new ACPI HID for ETE, or is it plans to do so?
If possible, can the new HID be provided in advance?
b) Or Is it possible to add an new ACPI HID (HISI0461) for
HiSilicon ETE.
Best regards,
Junhao.
Copy the kernel version of the header to fix the header diff build
warning. Some new definitions were only added to the tools side header,
but these are only used in Perf so move them to a different header.
Signed-off-by: James Clark <james.clark(a)arm.com>
---
tools/include/linux/coresight-pmu.h | 13 -------------
tools/perf/util/cs-etm.h | 13 +++++++++++++
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/tools/include/linux/coresight-pmu.h b/tools/include/linux/coresight-pmu.h
index cef3b1c25335..51ac441a37c3 100644
--- a/tools/include/linux/coresight-pmu.h
+++ b/tools/include/linux/coresight-pmu.h
@@ -21,19 +21,6 @@
*/
#define CORESIGHT_LEGACY_CPU_TRACE_ID(cpu) (0x10 + (cpu * 2))
-/* CoreSight trace ID is currently the bottom 7 bits of the value */
-#define CORESIGHT_TRACE_ID_VAL_MASK GENMASK(6, 0)
-
-/*
- * perf record will set the legacy meta data values as unused initially.
- * This allows perf report to manage the decoders created when dynamic
- * allocation in operation.
- */
-#define CORESIGHT_TRACE_ID_UNUSED_FLAG BIT(31)
-
-/* Value to set for unused trace ID values */
-#define CORESIGHT_TRACE_ID_UNUSED_VAL 0x7F
-
/*
* Below are the definition of bit offsets for perf option, and works as
* arbitrary values for all ETM versions.
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 70cac0375b34..ecca40787ac9 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -227,6 +227,19 @@ struct cs_etm_packet_queue {
#define INFO_HEADER_SIZE (sizeof(((struct perf_record_auxtrace_info *)0)->type) + \
sizeof(((struct perf_record_auxtrace_info *)0)->reserved__))
+/* CoreSight trace ID is currently the bottom 7 bits of the value */
+#define CORESIGHT_TRACE_ID_VAL_MASK GENMASK(6, 0)
+
+/*
+ * perf record will set the legacy meta data values as unused initially.
+ * This allows perf report to manage the decoders created when dynamic
+ * allocation in operation.
+ */
+#define CORESIGHT_TRACE_ID_UNUSED_FLAG BIT(31)
+
+/* Value to set for unused trace ID values */
+#define CORESIGHT_TRACE_ID_UNUSED_VAL 0x7F
+
int cs_etm__process_auxtrace_info(union perf_event *event,
struct perf_session *session);
struct perf_event_attr *cs_etm_get_default_config(struct perf_pmu *pmu);
--
2.34.1