From patchwork Mon Sep 24 13:00:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 10612465 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5F399157B for ; Mon, 24 Sep 2018 12:59:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4F63129C95 for ; Mon, 24 Sep 2018 12:59:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4346C29C9C; Mon, 24 Sep 2018 12:59:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 26B4A29C95 for ; Mon, 24 Sep 2018 12:59:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729283AbeIXTBr (ORCPT ); Mon, 24 Sep 2018 15:01:47 -0400 Received: from lelv0143.ext.ti.com ([198.47.23.248]:43594 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728863AbeIXTBq (ORCPT ); Mon, 24 Sep 2018 15:01:46 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id w8OCxesQ004216; Mon, 24 Sep 2018 07:59:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1537793980; bh=gPqhTvXaVhRf6JHEr/30ceQvrcW55aTJHiGHKgfGzB8=; h=From:To:CC:Subject:Date; b=W3q1BX4z8JuB9x6Gl0/2auHy9fRpGrghwW3lTjw7U5+KhZIEqkx2eZJOs4GlCOIJB 5RP57WoxIrIwA193sILnQChjL2ldQ3hqanvmHIBiZX0n2Q6hu5TRXyI0ELJGXod3oS Dz5+MzrdzxOFYU6FS9w7/HgYVb8/aKU9xKvxAXfc= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w8OCxeTx006429; Mon, 24 Sep 2018 07:59:40 -0500 Received: from DFLE110.ent.ti.com (10.64.6.31) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 24 Sep 2018 07:59:37 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE110.ent.ti.com (10.64.6.31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Mon, 24 Sep 2018 07:59:37 -0500 Received: from feketebors.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w8OCxZsD012211; Mon, 24 Sep 2018 07:59:35 -0500 From: Peter Ujfalusi To: , CC: , Subject: [RFC 0/5] dmaengine: ti: New DMA driver for Texas Instruments UDMA Date: Mon, 24 Sep 2018 16:00:16 +0300 Message-ID: <20180924130021.20530-1-peter.ujfalusi@ti.com> X-Mailer: git-send-email 2.18.0 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, the main purpose of the RFC series is to show one DMA driver which going to use the descriptor metadata functionality. The series will not compile in upstream kernel due to missing dependencies, like tisci resource management, ring accelerator driver, cppi5 header, etc. The AM65x TRM (http://www.ti.com/lit/pdf/spruid7) describes the Data Movement Architecture which is implmented by the k3-udma driver. This DMA architecture is a big departure from 'traditional' architecture where we had either EDMA or sDMA as system DMA. Packet DMAs were used as dedicated DMAs to service only networking (Kesytone2) or USB (am335x) while other peripherals were serviced by EDMA. In AM65x the UDMA (Unified DMA) is used for all data movment within the SoC, tasked to service all peripherals (UART, McSPI, McASP, networking, etc). The NAVSS/UDMA is built around CPPI5 (Communications Port Programming Interface) and it supports Packet mode (similar to CPPI4.1 in Keystone2 for networking) and TR mode (similar to EDMA descriptor). The data movement is done within a PSI-L fabric, all peripherals (including the UDMA-P). peripherals are not addressed by their I/O register as with traditional DMAs but with their PSI-L thread ID. In AM65x we have two main type of peripherals: Legacy: McASP, McSPI, UART, etc. to provide connectivity they are serviced by PDMA (Peripheral DMA) Native: Networking, security accelerator these peripherals have native support for PSI-L. To be able to use the DMA the following generic steps need to be taken: - configure a DMA channel (tchan for TX, rchan for RX) - channel mode: Packet or TR mode - for memcpy a tchan and rchan pair is used. - for packet mode RX we also need to configure a receive flow to configure the packet receiption - the source and destination threads must be paired - at minimum one pair of rings need to be configured: - tx: transfer ring and transfer completion ring - rx: free descriptor ring and receive ring - two interrupts: UDMA-P channel interrupt and ring interrupt for tc_ring/r_ring When the channel setup is completed we only interract with the rings: - TX: push a descriptor to t_ring and wait for it to be pushed to the tc_ring by the UDMA-P - RX: push a descriptor to the fd_ring and waith for UDMA-P to push it back to the r_ring. Notes for the core changes (first two patch): - Support for cached data reporting: Since we have FIFOs in the DMA fabric (UDMA-P, PSI-L and PDMA) which was not the case in previous DMAs we need to report the amount of data held in these FIFOs to clients (delay calculation for ALSA, UART FIFO flush support) I have added the dma_tx_state. - dmadev_get_slave_channel() I needed a way to request a channel from a specific dma_device which would invoke the filter function to get the needed parameters prior needed for the alloc_chan_resources. Note on the last patch: In Keystone2 the networking had dedicated DMA (packet DMA) which is not the case anymore and the DMAengine API currently missing support for the features we would need to support networking, things like - support for receive descriptor 'classification' - we need to support several receive queues for a channel. - the queues are used for packet priority handling for example, but they can be used to have pools of descriptors for different sizes. - out of order completion of descriptors on a channel - when we have several queues to handle different priority packets the descriptors will be completed 'out-of-order' - NAPI type of operation (polling instead of interrupt driven transfer) - without this we can not sustain gigabit speeds and we need to support NAPI - not to limit this to networking, but other high performance operations It is my intention to work on these to be able to remove the 'glue' layer and switch to DMAengine API - or have an API aside of DMAengine to have generic way to support networking, but given how controversial and not trivial these changes are we need something to support networking. Final note: driver names, prefixes might still change and some optimization and cleanup is still in the todo of mine. This is highly RFC! Regards, Peter --- Grygorii Strashko (1): dmaengine: ti: k3-udma: Add glue layer for non DMAengine users Peter Ujfalusi (4): dmaengine: Add support for reporting DMA cached data amount dmaengine: Add function to request slave channel from a dma_device dt-bindings: dma: ti: Add document for K3 UDMA dmaengine: ti: New driver for K3 UDMA .../devicetree/bindings/dma/ti/k3-udma.txt | 134 + drivers/dma/dmaengine.c | 20 + drivers/dma/dmaengine.h | 7 + drivers/dma/ti/Kconfig | 21 + drivers/dma/ti/Makefile | 2 + drivers/dma/ti/k3-navss-udma.c | 1133 +++++ drivers/dma/ti/k3-udma-private.c | 123 + drivers/dma/ti/k3-udma.c | 3626 +++++++++++++++++ drivers/dma/ti/k3-udma.h | 162 + include/dt-bindings/dma/k3-udma.h | 26 + include/linux/dma/k3-navss-udma.h | 152 + include/linux/dmaengine.h | 4 + 12 files changed, 5410 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt create mode 100644 drivers/dma/ti/k3-navss-udma.c create mode 100644 drivers/dma/ti/k3-udma-private.c create mode 100644 drivers/dma/ti/k3-udma.c create mode 100644 drivers/dma/ti/k3-udma.h create mode 100644 include/dt-bindings/dma/k3-udma.h create mode 100644 include/linux/dma/k3-navss-udma.h