The current method for allocating trace source ID values to sources is
to use a fixed algorithm for CPU based sources of (cpu_num * 2 + 0x10).
The STM is allocated ID 0x1.
This fixed algorithm is used in both the CoreSight driver code, and by
perf when writing the trace metadata in the AUXTRACE_INFO record.
The method needs replacing as currently:-
1. It is inefficient in using available IDs.
2. Does not scale to larger systems with many cores and the algorithm
has no limits so will generate invalid trace IDs for cpu number > 44.
Additionally requirements to allocate additional system IDs on some
systems have been seen.
This patch set introduces an API that allows the allocation of trace IDs
in a dynamic manner.
Architecturally reserved IDs are never allocated, and the system is
limited to allocating only valid IDs.
Each of the current trace sources ETM3.x, ETM4.x and STM is updated to use
the new API.
For the ETMx.x devices IDs are allocated on certain events
a) When using sysfs, an ID will be allocated on hardware enable, or a read of
sysfs TRCTRACEID register and freed when the sysfs reset is written.
b) When using perf, ID is allocated on during setup AUX event, and freed on
event free. IDs are communicated using the AUX_OUTPUT_HW_ID packet.
The ID allocator is notified when perf sessions start and stop
so CPU based IDs are kept constant throughout any perf session.
Note: This patchset breaks some backward compatibility for perf record and
perf report.
The version of the AUXTRACE_INFO has been updated to reflect the fact that
the trace source IDs are generated differently. This will
mean older versions of perf report cannot decode the newer file.
Appies to coresight/next
Changes since v6:
1) Export perf_report_aux_output_id() Acked by Peter,
2) Update to ETMv3 docs requested by suzuki
3) rebased and re-tested on coresight/next (6.2-rc2)
Changes since v5: (requested by suzuki)
1) Prefer odd ID values for system IDs to avoid overlap with legacy CPU IDs
2) Some style changes
Changes since v4:
1) update to ensure that compiling after each individual patch added still
works - ie. git bisect not broken through the patchset..
2) Revision to some of the now redundant code in cs-etm (James)
3) Comments and other minor fixes requested by Suzuki.
Changes since v3:
1) Fixed aarch32 build error in ETM3.x driver.
Reported-by: kernel test robot <lkp(a)intel.com>
Changes since v2:
1) Improved backward compatibility: (requested by James)
Using the new version of perf on an old kernel will generate a usable file
legacy metadata values are set by the new perf and will be used if mew
ID packets are not present in the file.
Using an older version of perf / simpleperf on an updated kernel may still
work. The trace ID allocator has been updated to use the legacy ID values
where possible, so generated file and used trace IDs will match up to the
point where the legacy algorithm is broken anyway.
2) Various changes to the ID allocator and ID packet format.
(suggested by Suzuki)
3) per CPU ID info in allocator now stored as atomic type to allow a passive read
without taking the allocator spinlock. perf flow now allocates and releases ID
values in setup_aux / free_event. Device enable and event enable use the passive
read to set the allocated values. This simplifies the locking mechanisms on the
perf run and fixes issues that arose with locking dependencies.
Changes since v1:
(after feedback & discussion with Mathieu & Suzuki).
1) API has changed. The global trace ID map is managed internally, so it
is no longer passed in to the API functions.
2) perf record does not use sysfs to find the trace IDs. These are now
output as AUX_OUTPUT_HW_ID events. The drivers, perf record, and perf report
have been updated accordingly to generate and handle these events.
Mike Leach (15):
coresight: trace-id: Add API to dynamically assign Trace ID values
coresight: Remove obsolete Trace ID unniqueness checks
coresight: perf: traceid: Add perf ID allocation and notifiers
coresight: stm: Update STM driver to use Trace ID API
coresight: etm4x: Update ETM4 driver to use Trace ID API
coresight: etm3x: Update ETM3 driver to use Trace ID API
coresight: etmX.X: stm: Remove trace_id() callback
coresight: trace id: Remove legacy get trace ID function.
perf: cs-etm: Move mapping of Trace ID and cpu into helper function
perf: cs-etm: Update record event to use new Trace ID protocol
kernel: events: Export perf_report_aux_output_id()
perf: cs-etm: Handle PERF_RECORD_AUX_OUTPUT_HW_ID packet
coresight: events: PERF_RECORD_AUX_OUTPUT_HW_ID used for Trace ID
coresight: trace-id: Add debug & test macros to Trace ID allocation
coresight: etm3x: docs: Alter sysfs documentation for trace id updates
.../testing/sysfs-bus-coresight-devices-etm3x | 2 +-
drivers/hwtracing/coresight/Makefile | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 45 ---
.../hwtracing/coresight/coresight-etm-perf.c | 23 ++
drivers/hwtracing/coresight/coresight-etm.h | 3 +-
.../coresight/coresight-etm3x-core.c | 93 +++--
.../coresight/coresight-etm3x-sysfs.c | 27 +-
.../coresight/coresight-etm4x-core.c | 73 +++-
.../coresight/coresight-etm4x-sysfs.c | 27 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +
drivers/hwtracing/coresight/coresight-stm.c | 49 +--
.../hwtracing/coresight/coresight-trace-id.c | 298 ++++++++++++++++
.../hwtracing/coresight/coresight-trace-id.h | 156 +++++++++
include/linux/coresight-pmu.h | 34 +-
include/linux/coresight.h | 3 -
kernel/events/core.c | 1 +
tools/include/linux/coresight-pmu.h | 48 ++-
tools/perf/arch/arm/util/cs-etm.c | 21 +-
.../perf/util/cs-etm-decoder/cs-etm-decoder.c | 7 +
tools/perf/util/cs-etm.c | 325 +++++++++++++++---
tools/perf/util/cs-etm.h | 14 +-
21 files changed, 1024 insertions(+), 230 deletions(-)
create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.c
create mode 100644 drivers/hwtracing/coresight/coresight-trace-id.h
--
2.17.1
On 18/01/2023 07:49, Yang Yingliang wrote:
> platform_get_resource() returns NULL pointer not PTR_ERR(), replace
> the IS_ERR() check with NULL pointer check.
>
> Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver")
We cannot use a Fixes tag on a commit that is not in Linus's tree.
I will queue this without the tag.
Thanks
Suzuki
> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com>
> ---
> drivers/hwtracing/coresight/ultrasoc-smb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
> index 2560fdbb8ebf..b317342c7ce5 100644
> --- a/drivers/hwtracing/coresight/ultrasoc-smb.c
> +++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
> @@ -455,7 +455,7 @@ static int smb_init_data_buffer(struct platform_device *pdev,
> void *base;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, SMB_BUF_ADDR_RES);
> - if (IS_ERR(res)) {
> + if (!res) {
> dev_err(&pdev->dev, "SMB device failed to get resource\n");
> return -EINVAL;
> }
This series adds support for the trace performance monitoring and
diagnostics hardware (TPDM and TPDA). It is composed of two major
elements.
a) Changes for original coresight framework to support for TPDM and TPDA.
b) Add driver code for TPDM and TPDA.
Introduction of changes for original coresight framework
Support TPDM as new coresight source.
Since only STM and ETM are supported as coresight source originally.
TPDM is a newly added coresight source. We need to change
the original way of saving coresight path to support more types source
for coresight driver.
The following patch is to add support more coresight sources.
coresight: core: Use IDR for non-cpu bound sources' paths.
Introduction of TPDM and TPDA
TPDM - The trace performance monitoring and diagnostics monitor or TPDM in
short serves as data collection component for various dataset types
specified in the QPMDA(Qualcomm performance monitoring and diagnostics
architecture) spec. The primary use case of the TPDM is to collect data
from different data sources and send it to a TPDA for packetization,
timestamping and funneling.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware definitions
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
TPDA - The trace performance monitoring and diagnostics aggregator or
TPDA in short serves as an arbitration and packetization engine for the
performance monitoring and diagnostics network as specified in the QPMDA
(Qualcomm performance monitoring and diagnostics architecture)
specification. The primary use case of the TPDA is to provide
packetization, funneling and timestamping of Monitor data as specified
in the QPMDA specification.
The following patch is to add driver for TPDA.
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
The last patch of this series is a device tree modification, which add
the TPDM and TPDA configuration to device tree for validating.
ARM: dts: msm: Add tpdm mm/prng for sm8250
Once this series patches are applied properly, the tpdm and tpda nodes
should be observed at the coresight path /sys/bus/coresight/devices
e.g.
/sys/bus/coresight/devices # ls -l | grep tpd
tpda0 -> ../../../devices/platform/soc(a)0/6004000.tpda/tpda0
tpdm0 -> ../../../devices/platform/soc(a)0/6c08000.mm.tpdm/tpdm0
We can use the commands are similar to the below to validate TPDMs.
Enable coresight sink first.
echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 > /sys/bus/coresight/devices/tpdm0/enable_source
echo 1 > /sys/bus/coresight/devices/tpdm0/integration_test
echo 2 > /sys/bus/coresight/devices/tpdm0/integration_test
The test data will be collected in the coresight sink which is enabled.
If rwp register of the sink is keeping updating when do
integration_test (by cat tmc_etf0/mgmt/rwp), it means there is data
generated from TPDM to sink.
There must be a tpda between tpdm and the sink. When there are some
other trace event hw components in the same HW block with tpdm, tpdm
and these hw components will connect to the coresight funnel. When
there is only tpdm trace hw in the HW block, tpdm will connect to
tpda directly.
+---------------+ +-------------+
| tpdm@6c08000 | |tpdm@684C000 |
+-------|-------+ +------|------+
| |
+-------|-------+ |
| funnel@6c0b000| |
+-------|-------+ |
| |
+-------|-------+ |
|funnel@6c2d000 | |
+-------|-------+ |
| |
| +---------------+ |
+----- tpda@6004000 -----------+
+-------|-------+
|
+-------|-------+
|funnel@6005000 |
+---------------+
This patch series depends on patch series:
"[v6,00/14] coresight: Add new API to allocate trace source ID values"
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20221123195010.…
TPDM_TPDA commit tree:
https://git.codelinaro.org/clo/linux-kernel/coresight/-/commits/tpdm-tpda-v…
Changes in V16:
1. Update device tree changes to match up with device tree bindings.
3. Update the copyright year to 2023.
Changes in V15:
1. coresight-tpda: Add more comments in trace id function.
2. qcom,coresight-tpdm.yaml: Add more comments in description.
3. Push "arm64: dts: qcom: sm8250: Add coresight components" out this series.
Changes in V14:
rebase to "[v5,00/14] coresight: Add new API to allocate trace source ID values" and latest 6.x kernel
Changes in V13:
1. Fix the conflicts when apply patches to the latest base line.
Changes in V12:
1. Clear bits for atid before setting them and relese atid when tpda
remove. -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
Changes in V11:
1. Change dev_info to dev_dbg in TPDM/TPDA drivers. -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
2. Merge sysfs API change of integration_test to integration_test driver
change. -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
Changes in V10:
1. Fix the error of TPDM yaml file. -- Rob Herring <robh(a)kernel.org>
Changes in V9:
1. Rename yaml file for TPDM/TPDA and fix the error for the yaml files.
-- Rob Herring <robh(a)kernel.org>
Changes in V8:
1. Use spinlock to protect drvdata of TPDM/TPDA -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
2. Use CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS as source type for TPDM -- Suzuki K Poulose <suzuki.poulose(a)arm.com>
3. Fix the warning for yaml file of TPDM/TPDA -- Rob Herring <robh(a)kernel.org>
Changes in V7:
1. Update the commit title and move the changes to right place which
is sorted by address for dtsi changes. -- Konrad Dybcio <konrad.dybcio(a)somainline.org>
Changes in V6:
1. Update maintainers in tpdm/tpda yaml file. -- Mike Leach <mike.leach(a)linaro.org>
2. Set the .remove function pointer in the amba_driver structure
of tpdm/tpda driver. Add tpda_remove function for tpda driver. -- Mike Leach <mike.leach(a)linaro.org>
3. Define datasets of tpdm as unsigned long. -- Mike Leach <mike.leach(a)linaro.org>
4. Move all coresight nodes to sm8250.dtsi.
-- Mike Leach <mike.leach(a)linaro.org>;Konrad Dybcio <konrad.dybcio(a)somainline.org>
5. Remove CORESIGHT_TPDM_INTEGRATION_TEST config. -- Mike Leach <mike.leach(a)linaro.org>
Changes in V5:
1. Keep the ETM source paths per-CPU and use IDR for other sources'
paths. (Suzuki K Poulose <suzuki.poulose(a)arm.com>)
Changes in V4:
1. Drop trace id for tpdm source as its trace atid is defined by the tpda.
Allocate tpda's atid dynamically. (Mike Leach)
Changes in V3:
1. Use bitmap to assign the trace id. (Mathieu Poirier)
Changes in V2:
1. Use IDR to store the path of sources. (Mathieu Poirier)
2. Only add integration_test/enable/disable for TPDM. No other configs.
(Mathieu Poirier)
3. Move coresight dtsi changes to sm8250.dtsi. (Suzuki K Poulose)
Mao Jinlong (8):
coresight: core: Use IDR for non-cpu bound sources' paths.
Coresight: Add coresight TPDM source driver
dt-bindings: arm: Adds CoreSight TPDM hardware
coresight-tpdm: Add DSB dataset support
coresight-tpdm: Add integration test support
Coresight: Add TPDA link driver
dt-bindings: arm: Adds CoreSight TPDA hardware definitions
arm64: dts: qcom: sm8250: Add tpdm mm/prng
.../testing/sysfs-bus-coresight-devices-tpdm | 13 +
.../bindings/arm/qcom,coresight-tpda.yaml | 129 +++++++++
.../bindings/arm/qcom,coresight-tpdm.yaml | 93 +++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/qcom/sm8250.dtsi | 164 +++++++++++
drivers/hwtracing/coresight/Kconfig | 23 ++
drivers/hwtracing/coresight/Makefile | 2 +
drivers/hwtracing/coresight/coresight-core.c | 42 ++-
drivers/hwtracing/coresight/coresight-tpda.c | 211 ++++++++++++++
drivers/hwtracing/coresight/coresight-tpda.h | 35 +++
drivers/hwtracing/coresight/coresight-tpdm.c | 259 ++++++++++++++++++
drivers/hwtracing/coresight/coresight-tpdm.h | 62 +++++
include/linux/coresight.h | 1 +
13 files changed, 1023 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpda.h
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.c
create mode 100644 drivers/hwtracing/coresight/coresight-tpdm.h
--
2.39.0
Hi Christoph
On Tue, 27 Dec 2022 at 17:09, Christoph Hellwig <hch(a)infradead.org> wrote:
>
> On Mon, Dec 19, 2022 at 11:46:35PM +0000, Mike Leach wrote:
> > Add in functionality and binary attribute to load and unload
> > configurations as binary data.
> >
> > Files are loaded via the 'load' binary attribute. System reads the incoming
> > file, which must be formatted correctly as defined in the file reader code.
> > This will create configuration(s) and/or feature(s) and load them
> > into the system.
>
> Binary attributes are intended to pass things such as firmware
> through. Defining your own structured file format seems like a
> major abuse of the configfs design. What's the advantage of this
> over simply using an ioctl?
The coresight configurations loaded here, represent programming of the
entire coresight subsystem - possibly tens of registers (especially on
the ETM), across multiple devices, in ways that are not possible using
the limited parameters of the perf command line.
The ETM can be programmed in ways that use counters. sequencers, and
optionally interact with other components such as CTI / CTM to send
conditional hardware triggers, all of which control the when and how
the trace is collected. Additionally there are system trace components
that might need to run at the same time - such as ELA, and other
system monitors that output data on the trace bus currently being
introduce by some chip designers.
As such the configuration must be loaded into the coresight system as
a single operation - with the individual drivers validating the
requested programming, where any error will fail the configuration
load. The individual drivers are also responsible for defining which
device registers user configurations can use - these being limited to
those that affect the scope of trace collected, with other operational
functions being reserved to the drivers themselves.
To achieve this a variable sized table of programming descriptors is
defined, that are transferred into the individual devices. The very
limited set of built in configurations - where the programming
descriptors are compiled into the driver modules themselves use the
same set of descriptors. however, recompiling kernel modules to
program new configurations is neither scaleable, flexible or desirable
- so we need a way of loading configurations at runtime. So the file
structure is simple a serialisation of these descriptor tables - with
a header defining the input type and overall size..
The advantage of these runtime configurations is that they can be
portable - and dependent on the hardware in the system, not the kernel
build version. Moreover, there are trace scenarios when we want to
trace what is present, not recompile a module / kernel to achieve
this, especially investigating issues on production systems.
1) using configfs to load these configurations keeps all the coresight
configuration ABI in a single file system - configfs. The current
builtin configurations can be viewed, enabled, and parameters
configrured in the current configfs that we have upstreamed. Adding
load / unload here is a logical extension of this.
2) because of the nature of configurations described above - we would
need a separate device to represent the whole subsystem - in order to
provide the ioctl support for loading. This device approach to
managing configurations has been previously rejected by the Coresight
maintainers, who suggested that configfs was the correct way to
configure a complex sub-system.
3) configurations are variable in size, An ioctl command would provide
a pointer to the configuration data - but the kernel would have to
trust that the underlying data is correctly formed. With a configfs
file write we get the buffer _and_ its size which is a good deal safer
from an input perspective.
4) ioctl use would require a loader program - configfs allows load
directly from the command line.
I agree that ioctls certainly have there uses, especially with small,
fixed size data types - but configfs is far better suited to this
complex use case.
Indeed the ioctl documentation suggests using configfs for
configuration cases that are too complex for sysfs, when an ioctl may
not be suitable.
This use of binary attributes is based on the existing use of a
configfs binary attribute is for the ACPI tables - the ACPI driver
here takes the buffer, does some initial validation of the file size
etc, then calls the inslall ./ validate ACPI routines where the table
is added to an internal list of tables maintained by the kernel. These
tables may well be shared by firmware - but are also used by the
kernel.
There appears to be nothing in the configfs documentation limiting the
use of binary attributes for passing firmware, Even the sysfs docs
suggest that this is an expected use but it is not a hard and fast
rule if there are no alternatives.
Granted in the vast majority of cases there are better alternatives.
I believe that loading via configfs is the best and safest engineering
solution for this particular use case.
Regards
Mike
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Hi Bagas,
On Wed, 21 Dec 2022 at 03:55, Bagas Sanjaya <bagasdotme(a)gmail.com> wrote:
>
> On Mon, Dec 19, 2022 at 11:46:38PM +0000, Mike Leach wrote:
> > diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst
> > index 6d5ffa6f7347..109053eb1b93 100644
> > --- a/Documentation/trace/coresight/coresight-config.rst
> > +++ b/Documentation/trace/coresight/coresight-config.rst
> > @@ -141,11 +141,11 @@ Mount configfs as normal and the 'cs-syscfg' subsystem will appear::
> > $ ls /config
> > cs-syscfg stp-policy
> >
> > -This has two sub-directories::
> > +This has two sub-directories, with the load and unload attribute files::
> >
> > $ cd cs-syscfg/
> > $ ls
> > - configurations features
> > + configurations features load unload
> >
> > The system has the configuration 'autofdo' built in. It may be examined as
> > follows::
> > @@ -278,9 +278,16 @@ Creating and Loading Custom Configurations
> > ==========================================
> >
> > Custom configurations and / or features can be dynamically loaded into the
> > -system by using a loadable module.
> > +system by using a loadable module, or by loading a binary configuration
> > +file in configfs.
> >
> > -An example of a custom configuration is found in ./samples/coresight.
> > +Loaded configurations can use previously loaded features. The system will
> > +ensure that it is not possible to unload a feature that is currently in
> > +use, by enforcing the unload order as the strict reverse of the load order.
> > +
> > +
> > +Using a Loadable Module
> > +-----------------------
> >
> > This creates a new configuration that uses the existing built in
> > strobing feature, but provides a different set of presets.
> > @@ -289,6 +296,187 @@ When the module is loaded, then the configuration appears in the configfs
> > file system and is selectable in the same way as the built in configuration
> > described above.
> >
> > -Configurations can use previously loaded features. The system will ensure
> > -that it is not possible to unload a feature that is currently in use, by
> > -enforcing the unload order as the strict reverse of the load order.
> > +The file 'coresight-cfg-sample.c' contains the configuration and module
> > +initialisation code needed to create the loadable module.
> > +
> > +This will be built alongside the kernel modules if select in KConfig.
>
> What config options (CONFIG_) are required for above to work?
>
> > +
> > +An example of a custom configuration module is found in './samples/coresight'.
> > +
> > +Using a Binary Configuration File
> > +---------------------------------
> > +
> > +The './tools/coresight' directory contains example programs to generate and
> > +read and print binary configuration files.
> > +
> > +Building the tools creates the 'coresight-cfg-file-gen' program that will
> > +generate a configuration binary 'example1.cscfg' that can be loaded into the
> > +system using configfs. The configuration declared in the source file
> > +'coresight-cfg-example1.c' is named 'autofdo3' - the name that will be used
> > +once loaded.
> > +
> > +The source files 'coresight-cfg-bufw.h' and 'coresight-cfg-bufw.c' provide a
> > +standard function to convert a configuration declared in 'C' into the correct
> > +binary buffer format. These files can be re-used to create new custom
> > +configurations. Alternatively, addition examples can be added to the
>
> s/addition/additional/
>
> > +'coresight-cfg-file-gen' program::
> > +
> > + $ ./coresight-cfg-file-gen
> > + Coresight Configuration file Generator
> > +
> > + Generating example1 example
> > + Generating example2 example
> > +
> > +The program 'coresight-cfg-file-read' can read back and print a configuration
> > +binary. This is built using the file reader from the driver code
> > +(coresight-config-file.c), which is copied over into './tools/coresight' at
> > +build time.::
> > +
> > + ./coresight-cfg-file-read example1.cscfg
> > + CoreSight Configuration file reader
> > + ============================================
> > +
> > + Configuration 1
> > + Name:- autofdo3
> > + Description:-
> > + Setup ETMs with strobing for autofdo
> > + Supplied presets allow experimentation with mark-space ratio for various loads
> > +
> > + Uses 1 features:-
> > + Feature-1: strobing
> > +
> > + Provides 4 sets of preset values, 2 presets per set
> > + set[0]: 0x7d0, 0x64,
> > + set[1]: 0x7d0, 0x3e8,
> > + set[2]: 0x7d0, 0x1388,
> > + set[3]: 0x7d0, 0x2710,
> > +
> > + ============================================
> > + File contains no features
> > +
> > +There are additional attributes in the cs-syscfg directory - load and
> > +unload that can be used to load and unload configuration binary files. To
> > +load, 'cat' the binary config into the load attribute::
> > +
> > + $ ls /config/cs-syscfg
> > + configurations features load unload
> > + $ cat example1.cscfg > /config/cs-syscfg/load
> > + $ ls /config/cs-syscfg/configurations/
> > + autofdo autofdo3
> > +
> > +To unload, use the same file in the unload attribute::
> > +
> > + $ cat example1.cscfg > /config/cs-syscfg/unload
> > + ls /config/cs-syscfg/configurations/
> > + autofdo
> > +
> > +
> > +
> > +Binary Configuration File Format
> > +--------------------------------
> > +
> > +The file format is defined in the source file **coresight-config-file.h**
>
> Use single-quote for identifier names for consistency here.
>
> > +
> > +The source reader and generator examples produce a binary of this format.
> > +
> > +This arrangement is reproduced below:-
> > +
> > +Overall File structure
> > +~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +::
> > +
> > + [cscfg_file_header] // Mandatory
> > + [CONFIG_ELEM]* // Optional - multiple, defined by cscfg_file_header.nr_configs
> > + [FEATURE_ELEM]* // Optional - multiple, defined by cscfg_file_header.nr_features
> > +
> > +File is invalid if both [CONFIG_ELEM] and [FEATURE_ELEM] are omitted.
> > +
> > +A file that contains only [FEATURE_ELEM] may be loaded, and the features used
> > +by subsequently loaded files with [CONFIG_ELEM] elements.
> > +
> > +Element Name Strings
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +Configuration name strings are required to consist of alphanumeric characters and '_' only. Other special characters are not permitted.
> > +
> > +::
> > + my_config_2 // is a valid name.
> > + this-bad-config#5 // this will not work
>
> Instead of using code-block for name examples, what about "... For
> example, foo_bar is a valid name where as foo-bar# is not."?
>
> > +
> > +This is in order to comply with the requirements of the perf command line.
> > +
> > +It is recommended that Feature and Parameter names use the same convention to allow for future enhancements to the command line syntax.
> > +
> > +CONFIG_ELEM element
> > +~~~~~~~~~~~~~~~~~~~
> > +
> > +::
> > +
> > + [cscfg_file_elem_header] // header length value to end of feature strings.
> > + [cscfg_file_elem_str] // name of the configuration.
> > + // (see element string name requirements)
> > + [cscfg_file_elem_str] // description of configuration.
> > + [u16 value](nr_presets) // number of defined sets presets values.
> > + [u32 value](nr_total_params) // total parameters defined by all used features.
> > + [u16 value](nr_feat_refs) // number of features referenced by the configuration
> > + [u64 values] * (nr_presets * nr_total_params) // the preset values.
> > + [cscfg_file_elem_str] * (nr_feat_refs) // names of features used in the configurations.
> > +
> > +FEATURE_ELEM element
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +::
> > +
> > + [cscfg_file_elem_header] // header length is total bytes to end of param structures.
> > + [cscfg_file_elem_str] // feature name.
> > + [cscfg_file_elem_str] // feature description.
> > + [u32 value](match_flags) // flags to associate the feature with a device.
> > + [u16 value](nr_regs) // number of registers.
> > + [u16 value](nr_params) // number of parameters.
> > + [cscfg_regval_desc struct] * (nr_regs) // register definitions
> > + [PARAM_ELEM] * (nr_params) // parameters definitions
> > +
> > +PARAM_ELEM element
> > +~~~~~~~~~~~~~~~~~~
> > +
> > +::
> > +
> > + [cscfg_file_elem_str] // parameter name.
> > + [u64 value](param_value) // initial value.
> > +
> > +Additional definitions.
> > +~~~~~~~~~~~~~~~~~~~~~~~
>
> Trim trailing period for section names
>
> > +
> > +The following structures are defined in **coresight-config-file.h**
> > +
> > + * **struct cscfg_file_header** : This structure contains an initial magic number, the total
> > + length of the file, and the number of configurations and features in the file.
> > + * **struct cscfg_file_elem_header**: This defines the total length and type of a CONFIG_ELEM
> > + or a FEATURE_ELEM.
> > + * **struct cscfg_file_elem_str**: This defines a string and its length.
>
> Again, for consistency, wrap identifier names in single-quotes.
>
> > +
> > +The magic number in cscfg_file_header is defined as two bitfields::
> > +
> > + [31:8] Fixed magic number to identify file type.
> > + [7:0] Current file format version.
> > +
> > +The following defines determine the maximum overall file size and maximum individual
> > +string size::
> > +
> > + CSCFG_FILE_MAXSIZE // maximum overall file size.
> > + CSCFG_FILE_STR_MAXSIZE // maximum individual string size.
>
> For parameter lists in elements, use bullet lists instead.
>
> > +
> > +Load Dependencies.
> > +~~~~~~~~~~~~~~~~~~
>
> Trim trailing period for section names.
> > +
> > +Files may be unloaded only in the strict reverse order of loading. This is enforced by the
> > +configuration system.
> > +
> > +This is to ensure that any load dependencies are maintained.
> > +
> > +A configuration file that contains a CONFIG_ELEM that references named features "feat_A" and "feat_B" will load only if either:-
> > +a) "feat_A" and/or "feat_B" has been loaded previously, or are present as built-in / module loaded features.
> > +b) "feat_A" and/or "feat_B" are declared as FEAT_ELEM in the same file as the CONFIG_ELEM.
>
> Separate the preceding paragraph and the list with a blank line in order
> for the list to be rendered as list.
>
The next version will contain all the adjustments that you suggested,
though rather than using single quotes, I have changed all the
occurrences to consistently the double back tick to make the filenames
etc fixed width font.
Thanks for the review
Mike
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
I'll rework this in the next set.
Thanks for the review
Mike
On Tue, 27 Dec 2022 at 17:10, Christoph Hellwig <hch(a)infradead.org> wrote:
>
> On Mon, Dec 19, 2022 at 11:46:36PM +0000, Mike Leach wrote:
> > Update coresight-config.h and the coresight-config-file.c & .h
> > to allow use in userspace programs.
> >
> > Use __KERNEL__ defines to filter out driver only structures and
> > elements so that user space programs can use the descriptor structures.
> >
> > Abstract memory allocation in coresight-config-file.c to allow read
> > file functions to be run in userspace and kernel drivers.
>
> That's now how kernel code is written.
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Add support for UltraSoc System Memory Buffer.
Change since v15:
- Modify document based on Bagas and Suzuki's comments.
- Link: https://lore.kernel.org/lkml/20221220092945.30722-1-hejunhao3@huawei.com/
Change since v14:
- Add some helpers to the buffer and simplify dumping data according to Jonathan's comment.
- Link: https://lore.kernel.org/lkml/20221123123823.27973-1-hejunhao3@huawei.com/
Change since v13:
- Modify document and the patches description according to Bagas's comment.
- Add dependency on config ACPI, drop redundant enable hw in smb_update_buffer(),
Modify smb_purge_data() description according to Suzuki's comment.
- Link: https://lore.kernel.org/lkml/20221114090316.63157-1-hejunhao3@huawei.com/
Change since v12:
- Modify the code style and add "#ifdef CONFIG_ACPI" according to Jonathan's comment.
- Address the comments from Yicong, included drop "buf_base"__iomem attribute,
modify the "reading" type to bool and fix FIELD_PREP.
- Link: https://lore.kernel.org/lkml/20221109135008.9485-1-hejunhao3@huawei.com/
Change since v11:
- Modify the code style and rename the macro according to Jonathan's comment.
- Link: https://lore.kernel.org/lkml/20221107130624.59886-1-hejunhao3@huawei.com/
Change since v10:
- Rebase onto v6.1-rc4, included similar sysfs register accessors (as same as James's patch)
- Link: https://lore.kernel.org/lkml/20221022115929.7503-1-hejunhao3@huawei.com/
Change since v9:
- Update the Contact tag in SMB document.
- Replace the spinlock with mutex.
- Do some clean-ups in "smb_enable()" and "smb_release()".
- Use classic memory mapped interface.
- Link: https://lore.kernel.org/linux-arm-kernel/20220818132231.28240-1-hejunhao3@h…
Change since v8:
- Insert a blank line at the end of the config tag in Kconfig according to Randy's comment.
- Link: https://lore.kernel.org/linux-arm-kernel/20220816131634.38195-1-hejunhao3@h…
Change since v7:
- Use the macros for register bit flags and numbers of resource.
- Cleanup punctuation.
- Update the Date tag and the KernelVersion tag in the document.
- Link: https://lore.kernel.org/lkml/20220712091353.34540-1-hejunhao3@huawei.com/
Change since v6:
- Modify the code style and driver description according to Suzuki's comment.
- Modify configuration of "drvdata->reading", to void problems in open/read
concurrency scenario.
- Rename the macro of "SMB_FLOW_MASK".
- Use the "handle->head" to determine the page number and offset.
- Link: https://lore.kernel.org/linux-arm-kernel/20220606130223.57354-1-liuqi115@hu…
Change since v5:
- Address the comments from Suzuki, add some comments in SMB document, and modify
configuration of "drvdata->reading", to void problems in multi-core concurrency scenario
- Link: https://lore.kernel.org/linux-arm-kernel/20220416083953.52610-1-liuqi115@hu…
Change since v4:
- Add a simple document of SMB driver according to Suzuki's comment.
- Address the comments from Suzuki.
- Link: https://lore.kernel.org/linux-arm-kernel/20220128061755.31909-1-liuqi115@hu…
Change since v3:
- Modify the file header according to community specifications.
- Address the comments from Mathieu.
- Link: https://lore.kernel.org/linux-arm-kernel/20211118110016.40398-1-liuqi115@hu…
Change since v2:
- Move ultrasoc driver to drivers/hwtracing/coresight by Mathieu's comment.
- Link: https://lists.linaro.org/pipermail/coresight/2021-November/007310.html
Change since v1:
- Drop the document of UltraSoc according to Mathieu's comment.
- Add comments to explain some private hardware settings.
- Address the comments from Mathieu.
- Link: https://lists.linaro.org/pipermail/coresight/2021-August/006842.html
Change since RFC:
- Move driver to drivers/hwtracing/coresight/ultrasoc.
- Remove ultrasoc-axi-com.c, as AXI-COM doesn't need to be configured in
basic tracing function.
- Remove ultrasoc.c as SMB does not need to register with the ultrasoc core.
- Address the comments from Mathieu and Suzuki.
- Link: https://lists.linaro.org/pipermail/coresight/2021-June/006535.html
Qi Liu (2):
drivers/coresight: Add UltraSoc System Memory Buffer driver
Documentation: Add document for UltraSoc SMB driver
.../sysfs-bus-coresight-devices-ultra_smb | 31 +
.../trace/coresight/ultrasoc-smb.rst | 83 +++
drivers/hwtracing/coresight/Kconfig | 12 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/ultrasoc-smb.c | 648 ++++++++++++++++++
drivers/hwtracing/coresight/ultrasoc-smb.h | 125 ++++
6 files changed, 900 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-ultra_smb
create mode 100644 Documentation/trace/coresight/ultrasoc-smb.rst
create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.c
create mode 100644 drivers/hwtracing/coresight/ultrasoc-smb.h
--
2.33.0