]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'sparx5-dma'
authorDavid S. Miller <davem@davemloft.net>
Fri, 20 Aug 2021 13:28:55 +0000 (14:28 +0100)
committerDavid S. Miller <davem@davemloft.net>
Fri, 20 Aug 2021 13:28:55 +0000 (14:28 +0100)
commita202500a6a349fff0db9a3c638602492aabc78d0
tree4a6e6acbaa2079bfd81bc73b67bcd7eab7523455
parent3c5311e73a5d5311b88e307613d077f53e91adc5
parentf2b9ede182b7262002f7e30416d83d5a02355ebf
Merge branch 'sparx5-dma'

Steen Hegelund says:

====================
Adding Frame DMA functionality to Sparx5

v2:
    Removed an unused variable (proc_ctrl) from sparx5_fdma_start.

This add frame DMA functionality to the Sparx5 platform.

Until now the Sparx5 SwitchDev driver has been using register based
injection and extraction when sending frames to/from the host CPU.

With this series the Frame DMA functionality now added.

The Frame DMA is only used if the Frame DMA interrupt is configured in the
device tree; otherwise the existing register based injection and extraction
is used.

The Sparx5 has two ports that can be used for sending and receiving frames,
but there are 8 channels that can be configured: 6 for injection and 2 for
extraction.

The additional channels can be used for more advanced scenarios e.g. where
virtual cores are used, but currently the driver only uses port 0 and
channel 0 and 6 respectively.

DCB (data control block) structures are passed to the Frame DMA with
suitable information about frame start/end etc, as well as pointers to DB
(data blocks) buffers.

The Frame DMA engine can use interrupts to signal back when the frames have
been injected or extracted.

There is a limitation on the DB alignment also for injection: Block must
start on 16byte boundaries, and this is why the driver currently copies the
data to into separate buffers.

The Sparx5 switch core needs a IFH (Internal Frame Header) to pass
information from the port to the switch core, and this header is added
before injection and stripped after extraction.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>