Merge branch 'topic/xilinx' into fixes

# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

%YAML 1.2

---

$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dpdma.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Xilinx ZynqMP DisplayPort DMA Controller Device Tree Bindings

description: |

  These bindings describe the DMA engine included in the Xilinx ZynqMP

  DisplayPort Subsystem. The DMA engine supports up to 6 DMA channels (3

  channels for a video stream, 1 channel for a graphics stream, and 2 channels

  for an audio stream).

maintainers:

  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>

allOf:

  - $ref: "../dma-controller.yaml#"

properties:

  "#dma-cells":

    const: 1

    description: |

      The cell is the DMA channel ID (see dt-bindings/dma/xlnx-zynqmp-dpdma.h

      for a list of channel IDs).

  compatible:

    const: xlnx,zynqmp-dpdma

  reg:

    maxItems: 1

  interrupts:

    maxItems: 1

  clocks:

    description: The AXI clock

    maxItems: 1

  clock-names:

    const: axi_clk

required:

  - "#dma-cells"

  - compatible

  - reg

  - interrupts

  - clocks

  - clock-names

additionalProperties: false

examples:

  - |

    #include <dt-bindings/interrupt-controller/arm-gic.h>

    dma: dma-controller@fd4c0000 {

      compatible = "xlnx,zynqmp-dpdma";

      reg = <0x0 0xfd4c0000 0x0 0x1000>;

      interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;

      interrupt-parent = <&gic>;

      clocks = <&dpdma_clk>;

      clock-names = "axi_clk";

      #dma-cells = <1>;

    };

...

  - interleaved_dma: This is common to Slave as well as M2M clients. For slave

    address of devices' fifo could be already known to the driver.

    Various types of operations could be expressed by setting

    appropriate values to the 'dma_interleaved_template' members.

    appropriate values to the 'dma_interleaved_template' members. Cyclic

    interleaved DMA transfers are also possible if supported by the channel by

    setting the DMA_PREP_REPEAT transfer flag.

  A non-NULL return of this transfer API represents a "descriptor" for

  the given transaction.

    identifier for each descriptor sent to the DMA device in order to

    properly track the completion.

- DMA_REPEAT

  - The device supports repeated transfers. A repeated transfer, indicated by

    the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that

    it gets automatically repeated when it ends, but can additionally be

    replaced by the client.

  - This feature is limited to interleaved transfers, this flag should thus not

    be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on

    the current needs of DMA clients, support for additional transfer types

    should be added in the future if and when the need arises.

- DMA_LOAD_EOT

  - The device supports replacing repeated transfers at end of transfer (EOT)

    by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set.

  - Support for replacing a currently running transfer at another point (such

    as end of burst instead of end of transfer) will be added in the future

    based on DMA clients needs, if and when the need arises.

These various types will also affect how the source and destination

addresses change over time.

    writes for which the descriptor should be in different format from

    normal data descriptors.

- DMA_PREP_REPEAT

  - If set, the transfer will be automatically repeated when it ends until a

    new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag.

    If the next transfer to be queued on the channel does not have the

    DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the

    client terminates all transfers.

  - This flag is only supported if the channel reports the DMA_REPEAT

    capability.

- DMA_PREP_LOAD_EOT

  - If set, the transfer will replace the transfer currently being executed at

    the end of the transfer.

  - This is the default behaviour for non-repeated transfers, specifying

    DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference.

  - When using repeated transfers, DMA clients will usually need to set the

    DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep

    repeating the last repeated transfer and ignore the new transfers being

    queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was

    stuck on the previous transfer.

  - This flag is only supported if the channel reports the DMA_LOAD_EOT

    capability.

General Design Notes

====================

F:	drivers/media/platform/xilinx/

F:	include/uapi/linux/xilinx-v4l2-controls.h

XILINX ZYNQMP DPDMA DRIVER

M:	Hyun Kwon <hyun.kwon@xilinx.com>

M:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>

L:	dmaengine@vger.kernel.org

S:	Supported

F:	Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml

F:	drivers/dma/xilinx/xilinx_dpdma.c

F:	include/dt-bindings/dma/xlnx-zynqmp-dpdma.h

XILLYBUS DRIVER

M:	Eli Billauer <eli.billauer@gmail.com>

L:	linux-kernel@vger.kernel.org

	help

	  Enable support for Xilinx ZynqMP DMA controller.

config XILINX_ZYNQMP_DPDMA

	tristate "Xilinx DPDMA Engine"

	select DMA_ENGINE

	select DMA_VIRTUAL_CHANNELS

	help

	  Enable support for Xilinx ZynqMP DisplayPort DMA. Choose this option

	  if you have a Xilinx ZynqMP SoC with a DisplayPort subsystem. The

	  driver provides the dmaengine required by the DisplayPort subsystem

	  display driver.

config ZX_DMA

	tristate "ZTE ZX DMA support"

	depends on ARCH_ZX || COMPILE_TEST