2019-05-19 13:07:45 +01:00
|
|
|
|
2006-05-23 17:18:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
2007-11-28 16:21:43 -08:00
|
|
|
|
2009-06-03 14:22:28 -07:00
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
2007-11-28 16:21:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-27 01:21:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-23 17:18:44 -07:00
|
|
|
|
2010-02-09 22:34:54 +01:00
|
|
|
|
2019-11-21 04:19:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-09 22:34:54 +01:00
|
|
|
|
|
|
|
|
|
2019-11-21 04:19:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-09 22:34:54 +01:00
|
|
|
|
|
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
2006-06-17 21:24:58 -07:00
|
|
|
|
2006-05-23 17:35:34 -07:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2010-10-07 16:44:50 -07:00
|
|
|
|
2009-09-08 17:42:51 -07:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-07 14:11:19 +02:00
|
|
|
|
|
|
|
|
|
2021-05-21 19:13:10 -07:00
|
|
|
|
2017-07-07 14:11:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-28 15:57:37 +02:00
|
|
|
|
|
|
|
|
|
2012-10-23 13:01:54 -07:00
|
|
|
|
2010-09-28 15:57:37 +02:00
|
|
|
|
2012-05-26 14:09:53 +01:00
|
|
|
|
2010-09-28 15:57:37 +02:00
|
|
|
|
2017-05-20 23:42:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-28 15:57:37 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-11 14:12:06 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2022-05-31 23:36:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-12 12:05:10 +00:00
|
|
|
|
|
|
|
|
|
2025-04-22 20:11:19 +02:00
|
|
|
|
2025-03-12 12:05:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2025-11-05 18:24:05 -08:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2022-10-25 12:03:06 +03:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-02 20:36:06 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-11 16:27:31 +01:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2019-06-06 13:45:50 +03:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2020-04-16 12:30:54 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2017-05-15 10:34:54 +05:30
|
|
|
|
|
|
|
|
|
2017-05-18 15:25:25 +02:00
|
|
|
|
|
|
|
|
|
2017-05-15 10:34:54 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-03 10:53:00 +05:30
|
|
|
|
2017-05-15 10:34:54 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2025-11-20 12:50:16 +01:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-29 23:32:48 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-02 15:31:42 +05:30
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-22 17:11:31 +01:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-24 12:27:58 -05:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-06 14:46:14 +03:00
|
|
|
|
|
|
|
|
|
2022-08-03 22:34:48 +02:00
|
|
|
|
2021-01-25 09:32:50 +08:00
|
|
|
|
2018-03-06 14:46:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2016-09-02 15:38:43 +05:30
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-07 21:58:45 +08:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 10:36:00 +08:00
|
|
|
|
2019-11-21 04:19:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-30 10:36:00 +08:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2019-11-21 04:19:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2019-11-21 04:19:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2020-01-16 14:10:57 +08:00
|
|
|
|
|
|
|
|
|
2022-11-21 16:23:53 +01:00
|
|
|
|
2020-03-28 19:41:33 +08:00
|
|
|
|
2020-01-16 14:10:57 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-20 00:57:00 +08:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-11 14:12:06 +02:00
|
|
|
|
2015-09-21 22:18:45 +05:30
|
|
|
|
2015-09-04 11:10:18 -07:00
|
|
|
|
2023-07-07 21:58:45 +08:00
|
|
|
|
2015-09-04 11:10:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-15 11:44:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:43:59 -07:00
|
|
|
|
|
|
|
|
|
2021-06-25 10:38:10 +02:00
|
|
|
|
2020-07-13 23:35:39 -07:00
|
|
|
|
2021-08-19 09:34:06 -07:00
|
|
|
|
2020-06-15 13:54:26 -07:00
|
|
|
|
2020-01-21 16:43:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-15 11:44:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-27 10:34:35 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dmaengine: idxd: Add IDXD performance monitor support
Implement the IDXD performance monitor capability (named 'perfmon' in
the DSA (Data Streaming Accelerator) spec [1]), which supports the
collection of information about key events occurring during DSA and
IAX (Intel Analytics Accelerator) device execution, to assist in
performance tuning and debugging.
The idxd perfmon support is implemented as part of the IDXD driver and
interfaces with the Linux perf framework. It has several features in
common with the existing uncore pmu support:
- it does not support sampling
- does not support per-thread counting
However it also has some unique features not present in the core and
uncore support:
- all general-purpose counters are identical, thus no event constraints
- operation is always system-wide
While the core perf subsystem assumes that all counters are by default
per-cpu, the uncore pmus are socket-scoped and use a cpu mask to
restrict counting to one cpu from each socket. IDXD counters use a
similar strategy but expand the scope even further; since IDXD
counters are system-wide and can be read from any cpu, the IDXD perf
driver picks a single cpu to do the work (with cpu hotplug notifiers
to choose a different cpu if the chosen one is taken off-line).
More specifically, the perf userspace tool by default opens a counter
for each cpu for an event. However, if it finds a cpumask file
associated with the pmu under sysfs, as is the case with the uncore
pmus, it will open counters only on the cpus specified by the cpumask.
Since perfmon only needs to open a single counter per event for a
given IDXD device, the perfmon driver will create a sysfs cpumask file
for the device and insert the first cpu of the system into it. When a
user uses perf to open an event, perf will open a single counter on
the cpu specified by the cpu mask. This amounts to the default
system-wide rather than per-cpu counting mentioned previously for
perfmon pmu events. In order to keep the cpu mask up-to-date, the
driver implements cpu hotplug support for multiple devices, as IDXD
usually enumerates and registers more than one idxd device.
The perfmon driver implements basic perfmon hardware capability
discovery and configuration, and is initialized by the IDXD driver's
probe function. During initialization, the driver retrieves the total
number of supported performance counters, the pmu ID, and the device
type from idxd device, and registers itself under the Linux perf
framework.
The perf userspace tool can be used to monitor single or multiple
events depending on the given configuration, as well as event groups,
which are also supported by the perfmon driver. The user configures
events using the perf tool command-line interface by specifying the
event and corresponding event category, along with an optional set of
filters that can be used to restrict counting to specific work queues,
traffic classes, page and transfer sizes, and engines (See [1] for
specifics).
With the configuration specified by the user, the perf tool issues a
system call passing that information to the kernel, which uses it to
initialize the specified event(s). The event(s) are opened and
started, and following termination of the perf command, they're
stopped. At that point, the perfmon driver will read the latest count
for the event(s), calculate the difference between the latest counter
values and previously tracked counter values, and display the final
incremental count as the event count for the cycle. An overflow
handler registered on the IDXD irq path is used to account for counter
overflows, which are signaled by an overflow interrupt.
Below are a couple of examples of perf usage for monitoring DSA events.
The following monitors all events in the 'engine' category. Becuuse
no filters are specified, this captures all engine events for the
workload, which in this case is 19 iterations of the work generated by
the kernel dmatest module.
Details describing the events can be found in Appendix D of [1],
Performance Monitoring Events, but briefly they are:
event 0x1: total input data processed, in 32-byte units
event 0x2: total data written, in 32-byte units
event 0x4: number of work descriptors that read the source
event 0x8: number of work descriptors that write the destination
event 0x10: number of work descriptors dispatched from batch descriptors
event 0x20: number of work descriptors dispatched from work queues
# perf stat -e dsa0/event=0x1,event_category=0x1/,
dsa0/event=0x2,event_category=0x1/,
dsa0/event=0x4,event_category=0x1/,
dsa0/event=0x8,event_category=0x1/,
dsa0/event=0x10,event_category=0x1/,
dsa0/event=0x20,event_category=0x1/
modprobe dmatest channel=dma0chan0 timeout=2000
iterations=19 run=1 wait=1
Performance counter stats for 'system wide':
5,332 dsa0/event=0x1,event_category=0x1/
5,327 dsa0/event=0x2,event_category=0x1/
19 dsa0/event=0x4,event_category=0x1/
19 dsa0/event=0x8,event_category=0x1/
0 dsa0/event=0x10,event_category=0x1/
19 dsa0/event=0x20,event_category=0x1/
21.977436186 seconds time elapsed
The command below illustrates filter usage with a simple example. It
specifies that MEM_MOVE operations should be counted for the DSA
device dsa0 (event 0x8 corresponds to the EV_MEM_MOVE event - Number
of Memory Move Descriptors, which is part of event category 0x3 -
Operations. The detailed category and event IDs are available in
Appendix D, Performance Monitoring Events, of [1]). In addition to
the event and event category, a number of filters are also specified
(the detailed filter values are available in Chapter 6.4 (Filter
Support) of [1]), which will restrict counting to only those events
that meet all of the filter criteria. In this case, the filters
specify that only MEM_MOVE operations that are serviced by work queue
wq0 and specifically engine number engine0 and traffic class tc0
having sizes between 0 and 4k and page size of between 0 and 1G result
in a counter hit; anything else will be filtered out and not appear in
the final count. Note that filters are optional - any filter not
specified is assumed to be all ones and will pass anything.
# perf stat -e dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
modprobe dmatest channel=dma0chan0 timeout=2000
iterations=19 run=1 wait=1
Performance counter stats for 'system wide':
19 dsa0/filter_wq=0x1,filter_tc=0x1,filter_sz=0x7,
filter_eng=0x1,event=0x8,event_category=0x3/
21.865914091 seconds time elapsed
The output above reflects that the unspecified workload resulted in
the counting of 19 MEM_MOVE operation events that met the filter
criteria.
[1]: https://software.intel.com/content/www/us/en/develop/download/intel-data-streaming-accelerator-preliminary-architecture-specification.html
[ Based on work originally by Jing Lin. ]
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Link: https://lore.kernel.org/r/0c5080a7d541904c4ad42b848c76a1ce056ddac7.1619276133.git.zanussi@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-04-24 10:04:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-23 17:35:34 -07:00
|
|
|
|
|
|
|
|
|
2021-08-09 11:24:09 +02:00
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
2013-12-09 10:33:16 -08:00
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines
The Intel(R) IOP series of i/o processors integrate an Xscale core with
raid acceleration engines. The capabilities per platform are:
iop219:
(2) copy engines
iop321:
(2) copy engines
(1) xor and block fill engine
iop33x:
(2) copy and crc32c engines
(1) xor, xor zero sum, pq, pq zero sum, and block fill engine
iop34x (iop13xx):
(2) copy, crc32c, xor, xor zero sum, and block fill engines
(1) copy, crc32c, xor, xor zero sum, pq, pq zero sum, and block fill engine
The driver supports the features of the async_tx api:
* asynchronous notification of operation completion
* implicit (interupt triggered) handling of inter-channel transaction
dependencies
The driver adapts to the platform it is running by two methods.
1/ #include <asm/arch/adma.h> which defines the hardware specific
iop_chan_* and iop_desc_* routines as a series of static inline
functions
2/ The private platform data attached to the platform_device defines the
capabilities of the channels
20070626: Callbacks are run in a tasklet. Given the recent discussion on
LKML about killing tasklets in favor of workqueues I did a quick conversion
of the driver. Raid5 resync performance dropped from 50MB/s to 30MB/s, so
the tasklet implementation remains until a generic softirq interface is
available.
Changelog:
* fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
slots to be requested eventually leading to data corruption
* enabled the slot allocation routine to attempt to free slots before
returning -ENOMEM
* switched the cleanup routine to solely use the software chain and the
status register to determine if a descriptor is complete. This is
necessary to support other IOP engines that do not have status writeback
capability
* make the driver iop generic
* modified the allocation routines to understand allocating a group of
slots for a single operation
* added a null xor initialization operation for the xor only channel on
iop3xx
* support xor operations on buffers larger than the hardware maximum
* split the do_* routines into separate prep, src/dest set, submit stages
* added async_tx support (dependent operations initiation at cleanup time)
* simplified group handling
* added interrupt support (callbacks via tasklets)
* brought the pending depth inline with ioat (i.e. 4 descriptors)
* drop dma mapping methods, suggested by Chris Leech
* don't use inline in C files, Adrian Bunk
* remove static tasklet declarations
* make iop_adma_alloc_slots easier to read and remove chances for a
corrupted descriptor chain
* fix locking bug in iop_adma_alloc_chan_resources, Benjamin Herrenschmidt
* convert capabilities over to dma_cap_mask_t
* fixup sparse warnings
* add descriptor flush before iop_chan_enable
* checkpatch.pl fixes
* gpl v2 only correction
* move set_src, set_dest, submit to async_tx methods
* move group_list and phys to async_tx
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2007-01-02 13:52:26 -07:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2023-09-24 17:23:32 +02:00
|
|
|
|
2015-07-27 18:04:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2015-07-27 18:04:02 +03:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-25 13:38:05 -07:00
|
|
|
|
2024-06-28 17:20:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-19 19:27:16 +02:00
|
|
|
|
|
|
|
|
|
2024-05-28 13:54:22 +02:00
|
|
|
|
2018-08-19 19:27:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-14 22:33:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-14 22:32:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2021-01-21 12:03:55 +01:00
|
|
|
|
2025-08-22 11:06:31 +08:00
|
|
|
|
2009-07-03 19:24:33 +02:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2009-07-03 19:24:33 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2021-01-21 12:03:56 +01:00
|
|
|
|
2016-09-02 15:57:09 +05:30
|
|
|
|
2014-10-22 17:22:18 +02:00
|
|
|
|
2016-10-06 17:59:53 -04:00
|
|
|
|
2014-10-22 17:22:18 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2014-10-22 17:22:18 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-01 07:42:48 -07:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-23 16:24:42 +02:00
|
|
|
|
2010-02-05 03:42:52 +00:00
|
|
|
|
|
|
|
|
|
2010-10-27 01:52:57 +02:00
|
|
|
|
2010-02-05 03:42:52 +00:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2010-02-05 03:42:52 +00:00
|
|
|
|
|
|
|
|
|
2008-07-08 11:58:36 -07:00
|
|
|
|
|
|
|
|
|
2016-04-29 09:49:08 +02:00
|
|
|
|
2008-07-08 11:58:36 -07:00
|
|
|
|
2013-12-09 10:33:16 -08:00
|
|
|
|
2010-10-07 16:44:50 -07:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2008-07-08 11:58:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-16 14:28:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-11 14:54:40 +01:00
|
|
|
|
2020-06-14 01:50:22 +09:00
|
|
|
|
2016-06-16 14:28:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2026-02-25 16:41:43 -05:00
|
|
|
|
2017-06-08 19:46:23 -03:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-16 11:58:46 -03:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-26 10:36:57 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
dmaengine: pxa: add pxa dmaengine driver
This is a new driver for pxa SoCs, which is also compatible with the former
mmp_pdma.
The rationale behind a new driver (as opposed to incremental patching) was :
- the new driver relies on virt-dma, which obsoletes all the internal
structures of mmp_pdma (sw_desc, hw_desc, ...), and by consequence all the
functions
- mmp_pdma allocates dma coherent descriptors containing not only hardware
descriptors but linked list information
The new driver only puts the dma hardware descriptors (ie. 4 u32) into the
dma pool allocated memory. This changes completely the way descriptors are
handled
- the architecture behind the interrupt/tasklet management was rewritten to be
more conforming to virt-dma
- the buffers alignment is handled differently
The former driver assumed that the DMA channel stopped between each
descriptor. The new one chains descriptors to let the channel running. This
is a necessary guarantee for real-time high bandwidth usecases such as video
capture on "old" architectures such as pxa.
- hot chaining / cold chaining / no chaining
Whenever possible, submitting a descriptor "hot chains" it to a running
channel. There is still no guarantee that the descriptor will be issued, as
the channel might be stopped just before the descriptor is submitted. Yet
this allows to submit several video buffers, and resubmit a buffer while
another is under handling.
As before, dma_async_issue_pending() is the only guarantee to have all the
buffers issued.
When an alignment issue is detected (ie. one address in a descriptor is not
a multiple of 8), if the already running channel is in "aligned mode", the
channel will stop, and restarted in "misaligned mode" to finished the issued
list.
- descriptors reusing
A submitted, issued and completed descriptor can be reused, ie resubmitted if
it was prepared with the proper flag (DMA_PREP_ACK). Only a channel
resources release will in this case release that buffer.
This allows a rolling ring of buffers to be reused, where there are several
thousands of hardware descriptors used (video buffer for example).
Additionally, a set of more casual features is introduced :
- debugging traces
- lockless way to know if a descriptor is terminated or not
The driver was tested on zylonite board (pxa3xx) and mioa701 (pxa27x),
with dmatest, pxa_camera and pxamci.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-05-25 23:29:20 +02:00
|
|
|
|
|
|
|
|
|
2025-01-14 20:13:16 +01:00
|
|
|
|
dmaengine: pxa: add pxa dmaengine driver
This is a new driver for pxa SoCs, which is also compatible with the former
mmp_pdma.
The rationale behind a new driver (as opposed to incremental patching) was :
- the new driver relies on virt-dma, which obsoletes all the internal
structures of mmp_pdma (sw_desc, hw_desc, ...), and by consequence all the
functions
- mmp_pdma allocates dma coherent descriptors containing not only hardware
descriptors but linked list information
The new driver only puts the dma hardware descriptors (ie. 4 u32) into the
dma pool allocated memory. This changes completely the way descriptors are
handled
- the architecture behind the interrupt/tasklet management was rewritten to be
more conforming to virt-dma
- the buffers alignment is handled differently
The former driver assumed that the DMA channel stopped between each
descriptor. The new one chains descriptors to let the channel running. This
is a necessary guarantee for real-time high bandwidth usecases such as video
capture on "old" architectures such as pxa.
- hot chaining / cold chaining / no chaining
Whenever possible, submitting a descriptor "hot chains" it to a running
channel. There is still no guarantee that the descriptor will be issued, as
the channel might be stopped just before the descriptor is submitted. Yet
this allows to submit several video buffers, and resubmit a buffer while
another is under handling.
As before, dma_async_issue_pending() is the only guarantee to have all the
buffers issued.
When an alignment issue is detected (ie. one address in a descriptor is not
a multiple of 8), if the already running channel is in "aligned mode", the
channel will stop, and restarted in "misaligned mode" to finished the issued
list.
- descriptors reusing
A submitted, issued and completed descriptor can be reused, ie resubmitted if
it was prepared with the proper flag (DMA_PREP_ACK). Only a channel
resources release will in this case release that buffer.
This allows a rolling ring of buffers to be reused, where there are several
thousands of hardware descriptors used (video buffer for example).
Additionally, a set of more casual features is introduced :
- debugging traces
- lockless way to know if a descriptor is terminated or not
The driver was tested on zylonite board (pxa3xx) and mioa701 (pxa27x),
with dmatest, pxa_camera and pxamci.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2015-05-25 23:29:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-03 14:20:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-11 16:09:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-16 14:55:32 +02:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 10:39:11 +01:00
|
|
|
|
|
|
|
|
|
2025-11-05 18:20:15 -08:00
|
|
|
|
2016-11-17 15:23:01 +05:30
|
|
|
|
2016-10-18 10:39:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-24 13:47:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-02 14:04:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-23 00:40:30 +09:00
|
|
|
|
|
|
|
|
|
2022-02-22 10:04:28 +01:00
|
|
|
|
2009-04-23 00:40:30 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-25 18:50:44 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-05 17:32:36 +08:00
|
|
|
|
2022-02-25 18:50:44 +05:30
|
|
|
|
2023-03-29 13:21:29 -04:00
|
|
|
|
2022-02-25 18:50:44 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-06 10:55:27 +05:30
|
|
|
|
2020-02-09 19:33:52 +03:00
|
|
|
|
2020-02-09 19:33:54 +03:00
|
|
|
|
2012-06-06 10:55:27 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-12 18:02:23 +01:00
|
|
|
|
2016-10-22 18:25:10 -04:00
|
|
|
|
2024-01-12 09:32:56 +00:00
|
|
|
|
2016-05-12 18:02:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-12 09:32:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-12 18:02:23 +01:00
|
|
|
|
2010-03-25 19:44:21 +01:00
|
|
|
|
|
|
|
|
|
2016-09-02 16:07:05 +05:30
|
|
|
|
2010-03-25 19:44:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-12 01:41:03 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-21 16:52:30 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-23 20:28:19 -07:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
|
|
|
|
|
2010-05-23 20:28:19 -07:00
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2014-01-17 09:46:05 +01:00
|
|
|
|
2016-06-24 10:51:25 +05:30
|
|
|
|
|
|
|
|
|
2023-05-31 09:01:41 +00:00
|
|
|
|
2014-04-23 20:23:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-24 10:51:25 +05:30
|
|
|
|
2014-04-23 20:23:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-24 10:51:25 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:30:22 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-23 20:23:26 +05:30
|
|
|
|
2023-01-19 08:32:05 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-01 17:07:06 +05:30
|
|
|
|
|
|
|
|
|
2021-08-26 11:47:38 +02:00
|
|
|
|
2016-07-01 17:07:06 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-23 20:23:26 +05:30
|
|
|
|
2020-07-17 04:33:35 +03:00
|
|
|
|
|
|
|
|
|
2021-05-20 18:24:17 +03:00
|
|
|
|
2020-07-17 04:33:35 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2024-08-19 14:19:48 -07:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2014-12-11 14:59:17 -08:00
|
|
|
|
2018-03-15 15:40:36 +08:00
|
|
|
|
|
|
|
|
|
2016-02-04 23:34:32 -05:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2015-03-18 19:17:34 +05:30
|
|
|
|
dmaengine: Add Synopsys eDMA IP core driver
Add Synopsys PCIe Endpoint eDMA IP core driver to kernel.
This IP is generally distributed with Synopsys PCIe Endpoint IP (depends
of the use and licensing agreement).
This core driver, initializes and configures the eDMA IP using vma-helpers
functions and dma-engine subsystem.
This driver can be compile as built-in or external module in kernel.
To enable this driver just select DW_EDMA option in kernel configuration,
however it requires and selects automatically DMA_ENGINE and
DMA_VIRTUAL_CHANNELS option too.
In order to transfer data from point A to B as fast as possible this IP
requires a dedicated memory space containing linked list of elements.
All elements of this linked list are continuous and each one describes a
data transfer (source and destination addresses, length and a control
variable).
For the sake of simplicity, lets assume a memory space for channel write
0 which allows about 42 elements.
+---------+
| Desc #0 |-+
+---------+ |
V
+----------+
| Chunk #0 |-+
| CB = 1 | | +----------+ +-----+ +-----------+ +-----+
+----------+ +->| Burst #0 |->| ... |->| Burst #41 |->| llp |
| +----------+ +-----+ +-----------+ +-----+
V
+----------+
| Chunk #1 |-+
| CB = 0 | | +-----------+ +-----+ +-----------+ +-----+
+----------+ +->| Burst #42 |->| ... |->| Burst #83 |->| llp |
| +-----------+ +-----+ +-----------+ +-----+
V
+----------+
| Chunk #2 |-+
| CB = 1 | | +-----------+ +-----+ +------------+ +-----+
+----------+ +->| Burst #84 |->| ... |->| Burst #125 |->| llp |
| +-----------+ +-----+ +------------+ +-----+
V
+----------+
| Chunk #3 |-+
| CB = 0 | | +------------+ +-----+ +------------+ +-----+
+----------+ +->| Burst #126 |->| ... |->| Burst #129 |->| llp |
+------------+ +-----+ +------------+ +-----+
Legend:
- Linked list, also know as Chunk
- Linked list element*, also know as Burst *CB*, also know as Change Bit,
it's a control bit (and typically is toggled) that allows to easily
identify and differentiate between the current linked list and the
previous or the next one.
- LLP, is a special element that indicates the end of the linked list
element stream also informs that the next CB should be toggle
On every last Burst of the Chunk (Burst #41, Burst #83, Burst #125 or
even Burst #129) is set some flags on their control variable (RIE and
LIE bits) that will trigger the send of "done" interruption.
On the interruptions callback, is decided whether to recycle the linked
list memory space by writing a new set of Bursts elements (if still
exists Chunks to transfer) or is considered completed (if there is no
Chunks available to transfer).
On scatter-gather transfer mode, the client will submit a scatter-gather
list of n (on this case 130) elements, that will be divide in multiple
Chunks, each Chunk will have (on this case 42) a limited number of
Bursts and after transferring all Bursts, an interrupt will be
triggered, which will allow to recycle the all linked list dedicated
memory again with the new information relative to the next Chunk and
respective Burst associated and repeat the whole cycle again.
On cyclic transfer mode, the client will submit a buffer pointer, length
of it and number of repetitions, in this case each burst will correspond
directly to each repetition.
Each Burst can describes a data transfer from point A(source) to point
B(destination) with a length that can be from 1 byte up to 4 GB. Since
dedicated the memory space where the linked list will reside is limited,
the whole n burst elements will be organized in several Chunks, that
will be used later to recycle the dedicated memory space to initiate a
new sequence of data transfers.
The whole transfer is considered has completed when it was transferred
all bursts.
Currently this IP has a set well-known register map, which includes
support for legacy and unroll modes. Legacy mode is version of this
register map that has multiplexer register that allows to switch
registers between all write and read channels and the unroll modes
repeats all write and read channels registers with an offset between
them. This register map is called v0.
The IP team is creating a new register map more suitable to the latest
PCIe features, that very likely will change the map register, which this
version will be called v1. As soon as this new version is released by
the IP team the support for this version in be included on this driver.
According to the logic, patches 1, 2 and 3 should be squashed into 1
unique patch, but for the sake of simplicity of review, it was divided
in this 3 patches files.
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
2019-06-04 15:29:22 +02:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
2019-11-07 16:49:21 +08:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2013-02-12 09:15:02 -08:00
|
|
|
|
2018-04-25 11:45:03 +03:00
|
|
|
|
|
|
|
|
|
2019-09-30 02:04:40 +00:00
|
|
|
|
|
|
|
|
|
2020-12-03 12:10:44 +08:00
|
|
|
|
|
|
|
|
|
2026-03-07 11:25:10 +08:00
|
|
|
|
|
|
|
|
|
2024-05-31 17:07:02 +02:00
|
|
|
|
|
|
|
|
|
2015-08-24 13:43:14 +05:30
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-25 09:13:25 -07:00
|
|
|
|
|
|
|
|
|
2009-09-08 15:06:10 -07:00
|
|
|
|
2009-03-25 09:13:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-08 11:58:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-27 14:21:40 +02:00
|
|
|
|
2008-07-08 11:58:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-09 10:33:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-16 01:27:42 -07:00
|
|
|
|
