On 2022/7/25 22:32, Mathieu Poirier wrote: > On Fri, 22 Jul 2022 at 08:53, Yicong Yang <yangyccccc@xxxxxxxxx> wrote: >> >> 在 7/21/2022 11:43 PM, Mathieu Poirier 写道: >>> On Thu, 21 Jul 2022 at 07:03, <yangyicong@xxxxxxxxxx> wrote: >>>> From: Yicong Yang <yangyicong@xxxxxxxxxxxxx> >>>> >>>> HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex >>>> integrated Endpoint (RCiEP) device, providing the capability >>>> to dynamically monitor and tune the PCIe traffic (tune), >>>> and trace the TLP headers (trace). >>>> >>>> PTT tune is designed for monitoring and adjusting PCIe link parameters. >>>> We provide several parameters of the PCIe link. Through the driver, >>>> user can adjust the value of certain parameter to affect the PCIe link >>>> for the purpose of enhancing the performance in certian situation. >>>> >>>> PTT trace is designed for dumping the TLP headers to the memory, which >>>> can be used to analyze the transactions and usage condition of the PCIe >>>> Link. Users can choose filters to trace headers, by either requester >>>> ID, or those downstream of a set of Root Ports on the same core of the >>>> PTT device. It's also supported to trace the headers of certain type and >>>> of certain direction. >>>> >>>> The driver registers a PMU device for each PTT device. The trace can >>>> be used through `perf record` and the traced headers can be decoded >>>> by `perf report`. The perf command support for the device is also >>>> added in this patchset. The tune can be used through the sysfs >>>> attributes of related PMU device. See the documentation for the >>>> detailed usage. >>>> >>>> Change since v10: >>>> - Use title case in the documentation >>>> - Add RB from Bagas, thanks. >>>> Link: https://lore.kernel.org/lkml/20220714092710.53486-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v9: >>>> - Add sysfs ABI description documentation >>>> - Remove the controversial available_{root_port, requester}_filters sysfs file >>>> - Shorten 2 tune sysfs attributes name and add some comments >>>> - Move hisi_ptt_process_auxtrace_info() to Patch 6. >>>> - Add RB from Leo and Ack-by from Mathieu, thanks! >>> You can add my Ack-by to patch 03 as well. See below for another comment. >> >> Thanks! >> >>>> Link: https://lore.kernel.org/lkml/20220606115555.41103-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v8: >>>> - Cleanups and one minor fix from Jonathan and John, thanks >>>> Link: https://lore.kernel.org/lkml/20220516125223.32012-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v7: >>>> - Configure the DMA in probe rather than in runtime. Also use devres to manage >>>> PMU device as we have no order problem now >>>> - Refactor the config validation function per John and Leo >>>> - Use a spinlock hisi_ptt::pmu_lock instead of mutex to serialize the perf process >>>> in pmu::start as it's in atomic context >>>> - Only commit the traced data when stop, per Leo and James >>>> - Drop the filter dynamically updating patch from this series to simply the review >>>> of the driver. That patch will be send separately. >>>> - add a cpumask sysfs attribute and handle the cpu hotplug events, follow the >>>> uncore PMU convention >>>> - Other cleanups and fixes, both in driver and perf tool >>>> Link: https://lore.kernel.org/lkml/20220407125841.3678-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v6: >>>> - Fix W=1 errors reported by lkp test, thanks >>>> >>>> Change since v5: >>>> - Squash the PMU patch into PATCH 2 suggested by John >>>> - refine the commit message of PATCH 1 and some comments >>>> Link: https://lore.kernel.org/lkml/20220308084930.5142-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v4: >>>> Address the comments from Jonathan, John and Ma Ca, thanks. >>>> - Use devm* also for allocating the DMA buffers >>>> - Remove the IRQ handler stub in Patch 2 >>>> - Make functions waiting for hardware state return boolean >>>> - Manual remove the PMU device as it should be removed first >>>> - Modifier the orders in probe and removal to make them matched well >>>> - Make available {directions,type,format} array const and non-global >>>> - Using the right filter list in filters show and well protect the >>>> list with mutex >>>> - Record the trace status with a boolean @started rather than enum >>>> - Optimize the process of finding the PTT devices of the perf-tool >>>> Link: https://lore.kernel.org/linux-pci/20220221084307.33712-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v3: >>>> Address the comments from Jonathan and John, thanks. >>>> - drop members in the common struct which can be get on the fly >>>> - reduce buffer struct and organize the buffers with array instead of list >>>> - reduce the DMA reset wait time to avoid long time busy loop >>>> - split the available_filters sysfs attribute into two files, for root port >>>> and requester respectively. Update the documentation accordingly >>>> - make IOMMU mapping check earlier in probe to avoid race condition. Also >>>> make IOMMU quirk patch prior to driver in the series >>>> - Cleanups and typos fixes from John and Jonathan >>>> Link: https://lore.kernel.org/linux-pci/20220124131118.17887-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v2: >>>> - address the comments from Mathieu, thanks. >>>> - rename the directory to ptt to match the function of the device >>>> - spinoff the declarations to a separate header >>>> - split the trace function to several patches >>>> - some other comments. >>>> - make default smmu domain type of PTT device to identity >>>> Drop the RMR as it's not recommended and use an iommu_def_domain_type >>>> quirk to passthrough the device DMA as suggested by Robin. >>>> Link: https://lore.kernel.org/linux-pci/20211116090625.53702-1-yangyicong@xxxxxxxxxxxxx/ >>>> >>>> Change since v1: >>>> - switch the user interface of trace to perf from debugfs >>>> - switch the user interface of tune to sysfs from debugfs >>>> - add perf tool support to start trace and decode the trace data >>>> - address the comments of documentation from Bjorn >>>> - add RMR[1] support of the device as trace works in RMR mode or >>>> direct DMA mode. RMR support is achieved by common APIs rather >>>> than the APIs implemented in [1]. >>>> Link: https://lore.kernel.org/lkml/1618654631-42454-1-git-send-email-yangyicong@xxxxxxxxxxxxx/ >>>> [1] https://lore.kernel.org/linux-acpi/20210805080724.480-1-shameerali.kolothum.thodi@xxxxxxxxxx/ >>>> >>>> Qi Liu (3): >>>> perf tool: arm: Refactor event list iteration in >>>> auxtrace_record__init() >>>> perf tool: Add support for HiSilicon PCIe Tune and Trace device driver >>>> perf tool: Add support for parsing HiSilicon PCIe Trace packet >>>> >>>> Yicong Yang (5): >>>> iommu/arm-smmu-v3: Make default domain type of HiSilicon PTT device to >>>> identity >>>> hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe >>>> Tune and Trace device >>>> hwtracing: hisi_ptt: Add tune function support for HiSilicon PCIe Tune >>>> and Trace device >>>> docs: trace: Add HiSilicon PTT device driver documentation >>>> MAINTAINERS: Add maintainer for HiSilicon PTT driver >>>> >>>> .../ABI/testing/sysfs-devices-hisi_ptt | 61 + >>>> Documentation/trace/hisi-ptt.rst | 298 +++++ >>>> Documentation/trace/index.rst | 1 + >>>> MAINTAINERS | 8 + >>>> drivers/Makefile | 1 + >>>> drivers/hwtracing/Kconfig | 2 + >>>> drivers/hwtracing/ptt/Kconfig | 12 + >>>> drivers/hwtracing/ptt/Makefile | 2 + >>>> drivers/hwtracing/ptt/hisi_ptt.c | 1032 +++++++++++++++++ >>>> drivers/hwtracing/ptt/hisi_ptt.h | 200 ++++ >>>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 21 + >>> Everything above needs to go in one patchset and everything below in >>> another one. The first patchset will need to be merged before the >>> second one. Someone already commented on that. >> >> ok. I put them together to provide an overall view of this and thought maintainers can take >> them separately. Will spilt the driver part and perf tool patches. >> >> I still don't know who will finally take the driver part. It should be Alexander from maintainer >> list but I got no response yet for a long time. Any hint for this? > > It will either be Peter, Greg or myself. We'll see when we get there. Thanks a lot for the information! Since it's going to be the merge window soon, I'll continue this on the next cycle. Regards.
