From patchwork Fri Mar 6 13:10:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 203726 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DA4BC10DCE for ; Fri, 6 Mar 2020 13:10:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0CFCE2072A for ; Fri, 6 Mar 2020 13:10:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726314AbgCFNKv (ORCPT ); Fri, 6 Mar 2020 08:10:51 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:36494 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726054AbgCFNKv (ORCPT ); Fri, 6 Mar 2020 08:10:51 -0500 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id ADBE18030797; Fri, 6 Mar 2020 13:10:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFg444i0-JS6; Fri, 6 Mar 2020 16:10:43 +0300 (MSK) From: CC: Serge Semin , Serge Semin , Alexey Malahov , Maxim Kaurkin , Pavel Parkhomenko , Ramil Zaripov , Ekaterina Skachko , Vadim Vlasov , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Viresh Kumar , Andy Shevchenko , Dan Williams , Vinod Koul , Rob Herring , Mark Rutland , , , Subject: [PATCH 0/5] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account Date: Fri, 6 Mar 2020 16:10:29 +0300 MIME-Version: 1.0 X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Message-Id: <20200306131048.ADBE18030797@mail.baikalelectronics.ru> To: unlisted-recipients:; (no To-header on input) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org From: Serge Semin Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible with currently implemented in the kernel DW DMAC driver, but there are some peculiarities which must be taken into account in order to have the device fully supported. First of all traditionally we replaced the legacy plain text-based dt-binding file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight channels, which alas have different max burst length configuration. In particular first two channels may burst up to 128 bits (16 bytes) at a time while the rest of them just up to 32 bits. We must make sure that the DMA subsystem doesn't set values exceeding these limitations otherwise the controller will hang up. In third currently we discovered the problem in using the DW APB SPI driver together with DW DMAC. The problem happens if there is no natively implemented multi-block LLP transfers support and the SPI-transfer length exceeds the max lock size. In this case due to asynchronous handling of Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use the DMAC to asynchronously execute the transfers we'd have to at least warn the user of the possible errors. Finally there is a bug in the algorithm of the nollp flag detection. In particular even if DW DMAC parameters state the multi-block transfers support there is still HC_LLP (hardcode LLP) flag, which if set makes expected by the driver true multi-block LLP functionality unusable. This happens cause' if HC_LLP flag is set the LLP registers will be hardcoded to zero so the contiguous multi-block transfers will be only supported. We must take the flag into account when detecting the LLP support otherwise the driver just won't work correctly. This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4: commit 98d54f81e36b ("Linux 5.6-rc4"). Signed-off-by: Serge Semin Signed-off-by: Alexey Malahov Cc: Maxim Kaurkin Cc: Pavel Parkhomenko Cc: Ramil Zaripov Cc: Ekaterina Skachko Cc: Vadim Vlasov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Viresh Kumar Cc: Andy Shevchenko Cc: Dan Williams Cc: Vinod Koul Cc: Rob Herring Cc: Mark Rutland Cc: dmaengine@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Serge Semin (5): dt-bindings: dma: dw: Replace DW DMAC legacy bindings with YAML-based one dt-bindings: dma: dw: Add max burst transaction length property bindings dmaengine: dw: Add LLP and block size config accessors dmaengine: dw: Introduce max burst length hw config dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config .../bindings/dma/snps,dma-spear1340.yaml | 180 ++++++++++++++++++ .../devicetree/bindings/dma/snps-dma.txt | 69 ------- drivers/dma/dw/core.c | 24 ++- drivers/dma/dw/dw.c | 1 + drivers/dma/dw/of.c | 9 + drivers/dma/dw/regs.h | 3 + include/linux/platform_data/dma-dw.h | 22 +++ 7 files changed, 238 insertions(+), 70 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt