I haven't done any meaningful work for a long while on Arm CoreSight and
it's unlikely I'll be able to do related work in the future.
Remove myself from the Arm CoreSight "Reviewers" list.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ad886d3163..342b8a3e19e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2102,7 +2102,6 @@ N: digicolor
ARM/CORESIGHT FRAMEWORK AND DRIVERS
M: Suzuki K Poulose <suzuki.poulose(a)arm.com>
R: Mike Leach <mike.leach(a)linaro.org>
-R: Leo Yan <leo.yan(a)linaro.org>
L: coresight(a)lists.linaro.org (moderated for non-subscribers)
L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers)
S: Maintained
--
2.39.2
On 6/20/2023 3:37 PM, Greg Kroah-Hartman wrote:
> On Tue, Jun 20, 2023 at 03:32:37PM +0800, Tao Zhang wrote:
>> Add the nodes to set value for DSB edge control and DSB edge
>> control mask. Each DSB subunit TPDM has maximum of n(n<16) EDCR
>> resgisters to configure edge control. DSB edge detection control
>> 00: Rising edge detection
>> 01: Falling edge detection
>> 10: Rising and falling edge detection (toggle detection)
>> And each DSB subunit TPDM has maximum of m(m<8) ECDMR registers to
>> configure mask. Eight 32 bit registers providing DSB interface
>> edge detection mask control.
>>
>> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com>
>> ---
>> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 32 +++++
>> drivers/hwtracing/coresight/coresight-tpdm.c | 143 ++++++++++++++++++++-
>> drivers/hwtracing/coresight/coresight-tpdm.h | 22 ++++
>> 3 files changed, 196 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> index 2a82cd0..34189e4a 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>> @@ -60,3 +60,35 @@ Description:
>> Bit[3] : Set to 0 for low performance mode.
>> Set to 1 for high performance mode.
>> Bit[4:8] : Select byte lane for high performance mode.
>> +
>> +What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge_ctrl
>> +Date: March 2023
>> +KernelVersion 6.5
>> +Contact: Jinlong Mao (QUIC) <quic_jinlmao(a)quicinc.com>, Tao Zhang (QUIC) <quic_taozha(a)quicinc.com>
>> +Description:
>> + Read/Write a set of the edge control registers of the DSB
>> + in TPDM.
>> +
>> + Expected format is the following:
>> + <integer1> <integer2> <integer3>
> sysfs is "one value", not 3. Please never have to parse a sysfs file.
Do you mean sysfs file can only accept "one value"?
I see that more than one value are written to the sysfs file
"trigout_attach".
>
>> +static ssize_t dsb_edge_ctrl_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> + ssize_t size = 0;
>> + unsigned long bytes;
>> + int i;
>> +
>> + spin_lock(&drvdata->spinlock);
>> + for (i = 0; i < TPDM_DSB_MAX_EDCR; i++) {
>> + bytes = sysfs_emit_at(buf, size,
>> + "Index:0x%x Val:0x%x\n", i,
> Again, no, one value, no "string" needed to parse anything.
I also see other sysfs files can be read more than one value in other
drivers.
Is this "one value" limitation the usage rule of Linux sysfs system?
Or am I misunderstanding what you mean?
Best,
Tao
>
> greg k-h
This patch series is to add support for a streaming interface for
TMC ETR to allow for continuous log collection to secondary storage.
An interrupt based mechanism is used to stream out the data from the device.
QDSS_CS_QDSSCSR_ETRIRQCTRL register is used to set the IRQ byte counter
value. The value of this registers defines the number of bytes that when moved by
the ETR AXI interface. It will casues an interrupt which can be used by an
userspace program to know how much data is present in memory requiring copy to some
other location. A zero setting disables the interrupt.A one setting
means 8 bytes, two 16 bytes, etc. In other words, the value in this
register is the interrupt threshold times 8 bytes. ETR must be enabled
when use this interrupt function.
Sample:
echo 4096 > /sys/bus/coresight/devices/tmc_etr0/block_size
echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
echo 1 > /sys/bus/coresight/devices/stm0/enabl_source
cat /dev/byte-cntr > /data/qdss_etr.bin &
The log collection will stop after disabling the ETR.
Commit link:
https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/coresight-b…
Mao Jinlong (3):
Coresight: Add driver to support for CSR
coresight-tmc: byte-cntr: Add support for streaming interface for ETR
dt-bindings: arm: Adds CoreSight CSR hardware definitions
.../testing/sysfs-bus-coresight-devices-tmc | 7 +
.../bindings/arm/qcom,coresight-csr.yaml | 62 ++++
drivers/hwtracing/coresight/Kconfig | 12 +
drivers/hwtracing/coresight/Makefile | 3 +-
.../hwtracing/coresight/coresight-byte-cntr.c | 304 ++++++++++++++++++
.../hwtracing/coresight/coresight-byte-cntr.h | 49 +++
drivers/hwtracing/coresight/coresight-csr.c | 168 ++++++++++
drivers/hwtracing/coresight/coresight-csr.h | 59 ++++
.../hwtracing/coresight/coresight-tmc-core.c | 66 ++++
.../hwtracing/coresight/coresight-tmc-etr.c | 8 +-
drivers/hwtracing/coresight/coresight-tmc.h | 12 +-
11 files changed, 745 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-csr.yaml
create mode 100644 drivers/hwtracing/coresight/coresight-byte-cntr.c
create mode 100644 drivers/hwtracing/coresight/coresight-byte-cntr.h
create mode 100644 drivers/hwtracing/coresight/coresight-csr.c
create mode 100644 drivers/hwtracing/coresight/coresight-csr.h
--
2.17.1
On 23/06/2023 19:22, Tanmay Jagdale wrote:
> The existing method of synthesizing instruction samples has the
> following issues:
> 1. Non-branch instructions have mnemonics of branch instructions.
> 2. Branch target address is missing.
>
> Set the sample flags only when we reach the last instruction in
> the tidq (which would be a branch instruction) to solve issue 1).
>
> To fix issue 2), start synthesizing the instructions from the
> previous packet (tidq->prev_packet) instead of current packet
> (tidq->packet). This way, it is easy to figure out the target
> address of the branch instruction in tidq->prev_packet which
> is the current packet's (tidq->packet) first executed instruction.
>
> After the switch to processing the previous packet first, we no
> longer need to swap the packets during cs_etm__flush().
Hi Tanmay,
I think the fix for setting the right flags and instruction type makes
sense, but is it possible to do it without the change to swapping in
cs_etm__flush() or some of the other changes to
cs_etm__synth_instruction_sample()?
I'm seeing some differences in the output related to the PID that's
assigned to a sample and some of the addresses that aren't explained by
the commit message. Also there is no corresponding change to
cs_etm__synth_branch_sample(), which is also using prev_packet etc so
I'm wondering if that's correct now without the swap? That function gets
used with the default itrace options or itrace=b
For example if I run 'perf script --itrace=i100ns' and diff the output
before and after your change I see a difference even though branch and
instruction info isn't printed, so I wouldn't expect to see any changes.
This is on a systemwide recording of a system under load.
Thanks
James
>
> Signed-off-by: Tanmay Jagdale <tanmay(a)marvell.com>
> ---
> tools/perf/util/cs-etm.c | 32 +++++++++++++++++++++++++-------
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 91299cc56bf7..446e00d98fd5 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1418,10 +1418,26 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> sample.stream_id = etmq->etm->instructions_id;
> sample.period = period;
> sample.cpu = tidq->packet->cpu;
> - sample.flags = tidq->prev_packet->flags;
> sample.cpumode = event->sample.header.misc;
>
> - cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
> + cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet, &sample);
> +
> + /* Populate branch target information only when we encounter
> + * branch instruction, which is at the end of tidq->prev_packet.
> + */
> + if (addr == (tidq->prev_packet->end_addr - 4)) {
> + /* Update the perf_sample flags using the prev_packet
> + * since that is the queue we are synthesizing.
> + */
> + sample.flags = tidq->prev_packet->flags;
> +
> + /* The last instruction of the previous queue would be a
> + * branch operation. Get the target of that branch by looking
> + * into the first executed instruction of the current packet
> + * queue.
> + */
> + sample.addr = cs_etm__first_executed_instr(tidq->packet);
> + }
>
> if (etm->synth_opts.last_branch)
> sample.branch_stack = tidq->last_branch;
> @@ -1641,7 +1657,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> /* Get instructions remainder from previous packet */
> instrs_prev = tidq->period_instructions;
>
> - tidq->period_instructions += tidq->packet->instr_count;
> + tidq->period_instructions += tidq->prev_packet->instr_count;
>
> /*
> * Record a branch when the last instruction in
> @@ -1721,8 +1737,11 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
> * been executed, but PC has not advanced to next
> * instruction)
> */
> + /* Get address from prev_packet since we are synthesizing
> + * that in cs_etm__synth_instruction_sample()
> + */
> addr = cs_etm__instr_addr(etmq, trace_chan_id,
> - tidq->packet, offset - 1);
> + tidq->prev_packet, offset - 1);
> ret = cs_etm__synth_instruction_sample(
> etmq, tidq, addr,
> etm->instructions_sample_period);
> @@ -1786,7 +1805,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq,
>
> /* Handle start tracing packet */
> if (tidq->prev_packet->sample_type == CS_ETM_EMPTY)
> - goto swap_packet;
> + goto reset_last_br;
>
> if (etmq->etm->synth_opts.last_branch &&
> etmq->etm->synth_opts.instructions &&
> @@ -1822,8 +1841,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq,
> return err;
> }
>
> -swap_packet:
> - cs_etm__packet_swap(etm, tidq);
> +reset_last_br:
>
> /* Reset last branches after flush the trace */
> if (etm->synth_opts.last_branch)
On 27/06/2023 18:19, Ian Rogers wrote:
> On Tue, Jun 27, 2023 at 9:58 AM Namhyung Kim <namhyung(a)kernel.org> wrote:
>>
>> On Tue, Jun 27, 2023 at 9:43 AM Ian Rogers <irogers(a)google.com> wrote:
>>>
>>> On Mon, Jun 26, 2023 at 5:02 PM Namhyung Kim <namhyung(a)kernel.org> wrote:
>>>>
>>>> On Mon, Jun 26, 2023 at 05:10:58PM +0100, James Clark wrote:
>>>>> thread__find_map() chooses to exit without assigning a thread to the
>>>>> addr_location in some scenarios, for example when there are samples from
>>>>> a guest and perf_guest == false. This results in a segfault when adding
>>>>> to the histogram because it uses unguarded accesses to the thread member
>>>>> of the addr_location.
>>>>
>>>> Looking at the commit 0dd5041c9a0ea ("perf addr_location: Add
>>>> init/exit/copy functions") that introduced the change, I'm not sure if
>>>> it's the intend behavior.
>>>>
>>>> It might change maps and map, but not thread. Then I think no reason
>>>> to not set the al->thread at the beginning.
>>>>
>>>> How about this? Ian?
>>>> (I guess we can get rid of the duplicate 'al->map = NULL' part)
>>>
>>> It seemed strange that we were failing to find a map (the function's
>>> purpose) but then populating the address_location. The change below
>>> brings back that somewhat odd behavior. I'm okay with reverting to the
>>> old behavior, clearly there were users relying on it. We should
>>> probably also copy maps and not just thread, as that was the previous
>>> behavior.
>>
>> Probably. But it used to support samples without maps and I think
>> that's why it ignores the return value of thread__find_map(). So
>> we can expect al.map is NULL and maybe fine to leave it for now.
>>
>> As machine__resolve() returns -1 if it gets no thread, we should set
>> al.thread when it returns 0.
>>
>> Can I get your Acked-by?
>
> Yep:
> Acked-by: Ian Rogers <irogers(a)google.com>
Looks good to me too. Should I resend the set with this change instead
of my one?
>
> Thanks,
> Ian
>
>> Thanks,
>> Namhyung
On 6/20/2023 4:49 PM, Greg Kroah-Hartman wrote:
> On Tue, Jun 20, 2023 at 04:31:59PM +0800, Tao Zhang wrote:
>> On 6/20/2023 3:37 PM, Greg Kroah-Hartman wrote:
>>> On Tue, Jun 20, 2023 at 03:32:37PM +0800, Tao Zhang wrote:
>>>> Add the nodes to set value for DSB edge control and DSB edge
>>>> control mask. Each DSB subunit TPDM has maximum of n(n<16) EDCR
>>>> resgisters to configure edge control. DSB edge detection control
>>>> 00: Rising edge detection
>>>> 01: Falling edge detection
>>>> 10: Rising and falling edge detection (toggle detection)
>>>> And each DSB subunit TPDM has maximum of m(m<8) ECDMR registers to
>>>> configure mask. Eight 32 bit registers providing DSB interface
>>>> edge detection mask control.
>>>>
>>>> Signed-off-by: Tao Zhang<quic_taozha(a)quicinc.com>
>>>> ---
>>>> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 32 +++++
>>>> drivers/hwtracing/coresight/coresight-tpdm.c | 143 ++++++++++++++++++++-
>>>> drivers/hwtracing/coresight/coresight-tpdm.h | 22 ++++
>>>> 3 files changed, 196 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> index 2a82cd0..34189e4a 100644
>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
>>>> @@ -60,3 +60,35 @@ Description:
>>>> Bit[3] : Set to 0 for low performance mode.
>>>> Set to 1 for high performance mode.
>>>> Bit[4:8] : Select byte lane for high performance mode.
>>>> +
>>>> +What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge_ctrl
>>>> +Date: March 2023
>>>> +KernelVersion 6.5
>>>> +Contact: Jinlong Mao (QUIC)<quic_jinlmao(a)quicinc.com>, Tao Zhang (QUIC)<quic_taozha(a)quicinc.com>
>>>> +Description:
>>>> + Read/Write a set of the edge control registers of the DSB
>>>> + in TPDM.
>>>> +
>>>> + Expected format is the following:
>>>> + <integer1> <integer2> <integer3>
>>> sysfs is "one value", not 3. Please never have to parse a sysfs file.
>> Do you mean sysfs file can only accept "one value"?
> Yes.
Hi Greg,
I‘d like to clarify the usage of this sysfs file again.
In the current design, three integers will be written to "dsb_edge_ctrl"
to configure DSB edge detection.
Integer #1: The start number of edge detection which needs to be configured.
Integer #2: The end number of edge detection which needs to be configured.
Integer #3: The type of the edge detection needs to be configured.
Below is an example.
echo 0x3 0x25 0x1 > dsb_edge_ctrl
It will configure edge detection #3 to #37 as "falling edge detection".
Since these three integers are interrelated and written to achieve the
same function, can we use these three integers as "one tuple" here?
Best,
Tao
>
>> I see that more than one value are written to the sysfs file
>> "trigout_attach".
> Then someone missed that and it needs to be fixed.
>
>>>> +static ssize_t dsb_edge_ctrl_show(struct device *dev,
>>>> + struct device_attribute *attr,
>>>> + char *buf)
>>>> +{
>>>> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>>> + ssize_t size = 0;
>>>> + unsigned long bytes;
>>>> + int i;
>>>> +
>>>> + spin_lock(&drvdata->spinlock);
>>>> + for (i = 0; i < TPDM_DSB_MAX_EDCR; i++) {
>>>> + bytes = sysfs_emit_at(buf, size,
>>>> + "Index:0x%x Val:0x%x\n", i,
>>> Again, no, one value, no "string" needed to parse anything.
>> I also see other sysfs files can be read more than one value in other
>> drivers.
> Again, they are broken, please send patches to fix them.
>
>> Is this "one value" limitation the usage rule of Linux sysfs system?
> Yes.
>
> thanks,
>
> greg k-h
On 27/06/2023 10:20, Greg Kroah-Hartman wrote:
> On Tue, Jun 27, 2023 at 10:06:11AM +0100, Suzuki K Poulose wrote:
>> Hi Greg,
>>
>> On 29/05/2023 07:25, Anshuman Khandual wrote:
>>> From: Suzuki K Poulose <suzuki.poulose(a)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(a)kernel.org>
>>> Cc: Len Brown <lenb(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: Sudeep Holla <sudeep.holla(a)arm.com>
>>> Cc: Lorenzo Pieralisi <lpieralisi(a)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
>>> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> (for ACPI specific changes)
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual(a)arm.com>
>>> ---
>>> 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 */
>>
>> This is a bit awkward request.
>>
>> I would like to get your opinion on merging this to coresight tree.
>> This change is removing the coresight ETMv4 from the ACPI AMBA
>> scan list and moving it to the coresight driver. This change is
>> essential for
>> 1) Adding ACPI support for later versions of ETMv4 that are not AMBA
>> devices.
>> 2) Adding power management support for AMBA ETMv4 with ACPI.
>>
>> The above change has been reviewed by Sudeep (Arm64 ACPI reviewer), but
>> hasn't been Acked by the ACPI maintainer (Rafael) even after a month of
>> follow up with at least 4 reminders [0].
>>
>> Are you happy with the Reviews from Sudeep and given the minimal
>> change to the drivers/acpi/acpi_amba.c file ?
>
> As we can't do anything now with the merge window open, please resend
> after 6.5-rc1 is out and ask for the ACPI developers to ack this.
Sure, will do that.
Thanks
Greg
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-rc4.
Changes in V5:
- 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.…
- 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
A couple of changes related to edge cases since commit 8d3031d39fe8
("perf cs-etm: Track exception level").
I think the second one is low risk seeing as any path requiring a thread
leading up to adding to the histogram would already have been crashing.
Maybe the thread check could also be added to hist_entry_iter__add()
although other users of it don't seem to have the same issue, and there
is another use of al.thread above in builtin-report.c so it's probably
ok where I've added it.
Applies to perf-tools-next/perf-tools-next (929ff679b69)
James Clark (2):
perf cs-etm: Handle per-thread mode on EL1 host kernel case
perf report: Don't add to histogram when there is no thread found
tools/perf/builtin-report.c | 3 +++
tools/perf/util/cs-etm.c | 11 +++++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
base-commit: 929ff679b694f0f9656aec38b3a7d5c440c5ca24
--
2.34.1
Greg,
Please find the changes for coresight and hwtracing subsystem, targeting v6.5.
Please note that, I have pulled James' devm_krealloc_array() patch -
( commit d388f06aced3 "devres: Provide krealloc_array" )
- into the coresight tree from your driver-core-next, for CTI module refcount
fixes depend on it.
Please let me know if this looks alright and kindly pull if it is fine.
Kind regards
Suzuki
The following changes since commit 7877cb91f1081754a1487c144d85dc0d2e2e7fc4:
Linux 6.4-rc4 (2023-05-28 07:49:00 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git tags/coresight-next-v6.5
for you to fetch changes up to 6c50384ef8b94a527445e3694ae6549e1f15d859:
hwtracing: hisi_ptt: Fix potential sleep in atomic context (2023-06-21 11:52:39 +0100)
----------------------------------------------------------------
coresight: Updates for v6.5
CoreSight and hwtracing subsystem updates for v6.5 includes:
- Fixes to the CTI module reference leaks. This involves,
redesign of how the helper devices are tracked and CTI
devices have been converted to helper devices.
- Fix removal of the trctraceidr file from sysfs for ETMs.
- Match all ETMv4 instances based on the ETMv4 architected
registers and the CoreSight Component ID (CID), than having
to add individual PIDs for CPUs.
- Add support for Dummy CoreSight source and sink drivers.
- Add James Clark as Reviewer for the CoreSight kernel drivers
- Fixes to HiSilicon PCIe Tune and Trace Device driver
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
----------------------------------------------------------------
Hao Zhang (3):
Coresight: Add coresight dummy driver
dt-bindings: arm: Add support for Coresight dummy trace
Documentation: trace: Add documentation for Coresight Dummy Trace
James Clark (14):
devres: Provide krealloc_array
coresight: Fix loss of connection info when a module is unloaded
coresight: Use enum type for cs_mode wherever possible
coresight: Change name of pdata->conns
coresight: Rename nr_outports to nr_outconns
coresight: Rename connection members to make the direction explicit
coresight: Dynamically add connections
coresight: Store pointers to connections rather than an array of them
coresight: Simplify connection fixup mechanism
coresight: Store in-connections as well as out-connections
coresight: Make refcount a property of the connection
coresight: Refactor out buffer allocation function for ETR
coresight: Enable and disable helper devices adjacent to the path
coresight: Fix CTI module refcount leak by making it a helper device
Mike Leach (1):
coresight: etm4x: Fix missing trctraceidr file in sysfs
Nathan Chancellor (1):
coresight: dummy: Update type of mode parameter in dummy_{sink,source}_enable()
Suzuki K Poulose (2):
coresight: etm4x: Match all ETM4 instances based on DEVARCH and DEVTYPE
MAINTAINERS: coresight: Add James Clark as Reviewer
Uwe Kleine-König (1):
coresight: etm4x: Make etm4_remove_dev() return void
Yicong Yang (5):
hwtracing: hisi_ptt: Factor out filter allocation and release operation
hwtracing: hisi_ptt: Add support for dynamically updating the filter list
hwtracing: hisi_ptt: Export available filters through sysfs
hwtracing: hisi_ptt: Advertise PERF_PMU_CAP_NO_EXCLUDE for PTT PMU
hwtracing: hisi_ptt: Fix potential sleep in atomic context
Documentation/ABI/testing/sysfs-devices-hisi_ptt | 52 ++
.../bindings/arm/arm,coresight-dummy-sink.yaml | 73 +++
.../bindings/arm/arm,coresight-dummy-source.yaml | 71 +++
Documentation/driver-api/driver-model/devres.rst | 1 +
Documentation/trace/coresight/coresight-dummy.rst | 32 ++
Documentation/trace/hisi-ptt.rst | 12 +-
MAINTAINERS | 1 +
drivers/hwtracing/coresight/Kconfig | 11 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-catu.c | 21 +-
drivers/hwtracing/coresight/coresight-core.c | 623 +++++++++++----------
drivers/hwtracing/coresight/coresight-cti-core.c | 52 +-
drivers/hwtracing/coresight/coresight-cti-sysfs.c | 4 +-
drivers/hwtracing/coresight/coresight-cti.h | 4 +-
drivers/hwtracing/coresight/coresight-dummy.c | 163 ++++++
drivers/hwtracing/coresight/coresight-etb10.c | 13 +-
drivers/hwtracing/coresight/coresight-etm-perf.c | 4 +-
drivers/hwtracing/coresight/coresight-etm3x-core.c | 6 +-
drivers/hwtracing/coresight/coresight-etm4x-core.c | 20 +-
.../hwtracing/coresight/coresight-etm4x-sysfs.c | 27 +-
drivers/hwtracing/coresight/coresight-funnel.c | 26 +-
drivers/hwtracing/coresight/coresight-platform.c | 269 ++++-----
drivers/hwtracing/coresight/coresight-priv.h | 36 +-
drivers/hwtracing/coresight/coresight-replicator.c | 23 +-
drivers/hwtracing/coresight/coresight-stm.c | 6 +-
drivers/hwtracing/coresight/coresight-sysfs.c | 17 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 26 +-
drivers/hwtracing/coresight/coresight-tmc-etr.c | 110 ++--
drivers/hwtracing/coresight/coresight-tmc.h | 2 +
drivers/hwtracing/coresight/coresight-tpda.c | 23 +-
drivers/hwtracing/coresight/coresight-tpdm.c | 4 +-
drivers/hwtracing/coresight/coresight-tpiu.c | 7 +-
drivers/hwtracing/coresight/coresight-trbe.c | 3 +-
drivers/hwtracing/coresight/ultrasoc-smb.c | 11 +-
drivers/hwtracing/coresight/ultrasoc-smb.h | 2 +-
drivers/hwtracing/ptt/hisi_ptt.c | 454 +++++++++++++--
drivers/hwtracing/ptt/hisi_ptt.h | 56 ++
include/linux/coresight.h | 127 +++--
include/linux/device.h | 11 +
39 files changed, 1662 insertions(+), 742 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-dummy-sink.yaml
create mode 100644 Documentation/devicetree/bindings/arm/arm,coresight-dummy-source.yaml
create mode 100644 Documentation/trace/coresight/coresight-dummy.rst
create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c