Documentation/driver-api/dmaengine/pxa_dma.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/dmaengine/pxa_dma.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/dmaengine/pxa_dma.rst
Extension
.rst
Size
6805 bytes
Lines
191
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==============================
PXA/MMP - DMA Slave controller
==============================

Constraints
===========

a) Transfers hot queuing
A driver submitting a transfer and issuing it should be granted the transfer
is queued even on a running DMA channel.
This implies that the queuing doesn't wait for the previous transfer end,
and that the descriptor chaining is not only done in the irq/tasklet code
triggered by the end of the transfer.
A transfer which is submitted and issued on a phy doesn't wait for a phy to
stop and restart, but is submitted on a "running channel". The other
drivers, especially mmp_pdma waited for the phy to stop before relaunching
a new transfer.

b) All transfers having asked for confirmation should be signaled
Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call.
This implies that even if an irq/tasklet is triggered by end of tx1, but
at the time of irq/dma tx2 is already finished, tx1->complete() and
tx2->complete() should be called.

c) Channel running state
A driver should be able to query if a channel is running or not. For the
multimedia case, such as video capture, if a transfer is submitted and then
a check of the DMA channel reports a "stopped channel", the transfer should
not be issued until the next "start of frame interrupt", hence the need to
know if a channel is in running or stopped state.

d) Bandwidth guarantee
The PXA architecture has 4 levels of DMAs priorities : high, normal, low.
The high priorities get twice as much bandwidth as the normal, which get twice
as much as the low priorities.
A driver should be able to request a priority, especially the real-time
ones such as pxa_camera with (big) throughputs.

Design
======
a) Virtual channels
Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
channel" linked to the requester line, and the physical DMA channel is
assigned on the fly when the transfer is issued.

b) Transfer anatomy for a scatter-gather transfer

::

   +------------+-----+---------------+----------------+-----------------+
   | desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker |
   +------------+-----+---------------+----------------+-----------------+

This structure is pointed by dma->sg_cpu.
The descriptors are used as follows :

    - desc-sg[i]: i-th descriptor, transferring the i-th sg
      element to the video buffer scatter gather

    - status updater
      Transfers a single u32 to a well known dma coherent memory to leave
      a trace that this transfer is done. The "well known" is unique per
      physical channel, meaning that a read of this value will tell which
      is the last finished transfer at that point in time.

    - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN

    - linker: has ddadr= desc-sg[0] of next transfer, dcmd=0

c) Transfers hot-chaining

Annotation

Implementation Notes