From patchwork Wed Mar 18 00:15:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444267 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6619490 for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4628320757 for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ynp2qMHI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727224AbgCRARL (ORCPT ); Tue, 17 Mar 2020 20:17:11 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:56308 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726991AbgCRARJ (ORCPT ); Tue, 17 Mar 2020 20:17:09 -0400 Received: by mail-wm1-f68.google.com with SMTP id 6so1303211wmi.5; Tue, 17 Mar 2020 17:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=J+e5SK2e2LZ4MyHO9wWSsa40xkOFSDNcY+p2H5PaU+M=; b=Ynp2qMHIuiwOUtZ3QM8+AfwnmcGnkCuk4FQFn8Eto1QVXv7jYR2Ss/sb/kVH738oZu iVSOpVaIA3MIQ9KszW2EfUIRrEVCRZxabMXD6e0/3RWxKSJwpmkhMqahTD2z67QrqIAt gmWybPGOIHi07H1rdM/5kDntw1zPNAO13wjimFtPB0vTj0zJ/NEbZzokcBs8y67xS4K/ E4r+cJRajOj34rWb3sTLI1MComoF6+ZidtBCfffijh2DpqsExKSQ9vxEWrZZKlJq/Ber dtCbdZs6DubENgqC17ljQPdrq0b64t+d5JUIAVkP/sAVuHigFfgmgz80+HWQWMWIU+TR XQTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=J+e5SK2e2LZ4MyHO9wWSsa40xkOFSDNcY+p2H5PaU+M=; b=DJK1t+T0p3LcwI7wbX510gBBQMgUG6f/uTrLOCSkAxP8RZXD2ZVX44DkyTuYrOzzuf DTiMyY7oyzSYJvbcluu9S8eRLxxZjE5NJNH2Xauynj58M5m1kQOxNGnJIj18Bsk8PNk7 CvwSP9Lg29c3og88v9C8vIjx8fixGxc4bUa0nLZu4kTSwDx+8mR/kaj+IRYKeOPeuNR+ +ShzdkNl4dkKCkcJ4/l1ktcNZeLymCNczLXu9tIpl3m+gxpcTVADy9YaUj4UE0DXhBlt 4wiMsE6M7k5yJkoosF+bDZjuUFkD2DWg7vk8EtRhno0rocbMpd9fkvxGoS8vTInZzy13 58Pw== X-Gm-Message-State: ANhLgQ1tzsIY/fFgcguJ4tugBC6goYL8oRnbyJGuMBbQTa5nxo41NAWl Cv5IwkQFjBncWqeD/4W5z8k= X-Google-Smtp-Source: ADFU+vs7XKqVjr0PgUql0X5CC6cLuNW6Uv2W1EblIurQKjusZ+ze0jq2S+qyuUiW+Blezf+J0pNwSw== X-Received: by 2002:a05:600c:4145:: with SMTP id h5mr1529450wmm.3.1584490628310; Tue, 17 Mar 2020 17:17:08 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:07 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 01/12] spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR Date: Wed, 18 Mar 2020 02:15:52 +0200 Message-Id: <20200318001603.9650-2-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean The SPI_MCR_PCSIS macro assumes that the controller has a number of chip select signals equal to 6. That is not always the case, but actually is described through the driver-specific "spi-num-chipselects" device tree binding. LS1028A for example only has 4 chip selects. Don't write to the upper bits of the PCSIS field, which are reserved in the reference manual. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: None. Changes in v3: None. Changes in v2: Remove duplicate phrase in commit message. drivers/spi/spi-fsl-dspi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 50e3382f0c50..6ca35881881b 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -22,7 +22,7 @@ #define SPI_MCR 0x00 #define SPI_MCR_MASTER BIT(31) -#define SPI_MCR_PCSIS (0x3F << 16) +#define SPI_MCR_PCSIS(x) ((x) << 16) #define SPI_MCR_CLR_TXF BIT(11) #define SPI_MCR_CLR_RXF BIT(10) #define SPI_MCR_XSPI BIT(3) @@ -1200,7 +1200,10 @@ static const struct regmap_config dspi_xspi_regmap_config[] = { static void dspi_init(struct fsl_dspi *dspi) { - unsigned int mcr = SPI_MCR_PCSIS; + unsigned int mcr; + + /* Set idle states for all chip select signals to high */ + mcr = SPI_MCR_PCSIS(GENMASK(dspi->ctlr->num_chipselect - 1, 0)); if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE) mcr |= SPI_MCR_XSPI; From patchwork Wed Mar 18 00:15:53 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444269 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D2AEA1874 for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B233520757 for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Oq350yYd" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727151AbgCRAR6 (ORCPT ); Tue, 17 Mar 2020 20:17:58 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:51302 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726965AbgCRARL (ORCPT ); Tue, 17 Mar 2020 20:17:11 -0400 Received: by mail-wm1-f66.google.com with SMTP id c187so18176wme.1; Tue, 17 Mar 2020 17:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=pE6LjR29iwQf7D7RlG7d25qJJWFx3m2e6HQhVoX16AY=; b=Oq350yYdRqcZoUIYFTMtYKriySyDk2r83F7XAZna+/BNzTaoUFmeBpLsVWHCK5O7fm 2cwUAa3dCAZbr9rQK8gV7p7WRYwiGP5Osw39oImS3PEr4RL/AXeDf289CQNQ3fFP8CcN cD1N9KGwmhz+1067jVRAw1eHgwNbnZBwzxw0BWeV5/7sZ9CblzkwvkfEiqfyRddfVOmC ADv9QaYagVJyGvwp3pR5BHBlLQUMtK/61BD87Juhk8G9BKH9BTkG3WX5dws9VgXjyMxs tB7Fh6pSGDUBk8YV9/2FXaSb30XlpsvHm6xJTlXJldbBVsZlAiS1tF0lHBp15ScTuL8/ odoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=pE6LjR29iwQf7D7RlG7d25qJJWFx3m2e6HQhVoX16AY=; b=HMYMC2UueQkvQdK6P6xSVitfMm0jYytdI19V8eTu/jWbtUD/8Dc8z8TBs9+FReOhxq Yz9/yOMpwRjywHRcgCjWEAESt2uY4EuKoVlEtckO1d1F3a6I62QUzFAYaCsNrKIzCUsD A7Li+9TLyaDi6t7ciul5Of55ClbApgHYgJH9wxW7hmffJMw0tObfxo2l+ReGo1pwBAch 02QF1+I/8SZ1nKuMmgfkUkChHDgJvn2Pwn/Q/rrXJOebhrGLewNSwOnUurqRBe+MWDk5 TpFPUoq9iYegbCE4vutSYk5alCRQzcgrUU6iiTjpgrEjmLEgE5TMtwm7C2fn7GuAKxlM ssjg== X-Gm-Message-State: ANhLgQ3jKN30Opb5CRZrm5k1aXMoexLFCNCjK2m24s6KzxeGpxJVs97J iiTkTP4tc2yfA3wSZNTqXYA= X-Google-Smtp-Source: ADFU+vtZK5FtJiMPU4xFtis1grhOnhh8z5/n3TB5GJ3/bsDZWnoQsfVvYFUJLe8SFtyTi8q75VqjEg== X-Received: by 2002:a1c:6a08:: with SMTP id f8mr1510919wmc.53.1584490629614; Tue, 17 Mar 2020 17:17:09 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:09 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 02/12] spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA Date: Wed, 18 Mar 2020 02:15:53 +0200 Message-Id: <20200318001603.9650-3-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean In XSPI mode, the 32-bit PUSHR register can be written to separately: the higher 16 bits are for commands and the lower 16 bits are for data. This has nicely been hacked around, by defining a second regmap with a width of 16 bits, and effectively splitting a 32-bit register into 2 16-bit ones, from the perspective of this regmap_pushr. The problem is the assumption about the controller's endianness. If the controller is little endian (such as anything post-LS1046A), then the first 2 bytes, in the order imposed by memory layout, will actually hold the TXDATA, and the last 2 bytes will hold the CMD. So take the controller's endianness into account when performing split writes to PUSHR. The obvious and simple solution would have been to call regmap_get_val_endian(), but that is an internal regmap function and we don't want to change regmap just for this. Therefore, we just re-read the "big-endian" device tree property. Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: None. Changes in v3: None. Changes in v2: Parse "big-endian" device tree bindings instead of taking the decision based on compatible SoC. drivers/spi/spi-fsl-dspi.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 6ca35881881b..be717776dd98 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -103,10 +103,6 @@ #define SPI_FRAME_BITS(bits) SPI_CTAR_FMSZ((bits) - 1) #define SPI_FRAME_EBITS(bits) SPI_CTARE_FMSZE(((bits) - 1) >> 4) -/* Register offsets for regmap_pushr */ -#define PUSHR_CMD 0x0 -#define PUSHR_TX 0x2 - #define DMA_COMPLETION_TIMEOUT msecs_to_jiffies(3000) struct chip_data { @@ -240,6 +236,13 @@ struct fsl_dspi { int words_in_flight; + /* + * Offsets for CMD and TXDATA within SPI_PUSHR when accessed + * individually (in XSPI mode) + */ + int pushr_cmd; + int pushr_tx; + void (*host_to_dev)(struct fsl_dspi *dspi, u32 *txdata); void (*dev_to_host)(struct fsl_dspi *dspi, u32 rxdata); }; @@ -673,12 +676,12 @@ static void dspi_pushr_cmd_write(struct fsl_dspi *dspi, u16 cmd) */ if (dspi->len > dspi->oper_word_size) cmd |= SPI_PUSHR_CMD_CONT; - regmap_write(dspi->regmap_pushr, PUSHR_CMD, cmd); + regmap_write(dspi->regmap_pushr, dspi->pushr_cmd, cmd); } static void dspi_pushr_txdata_write(struct fsl_dspi *dspi, u16 txdata) { - regmap_write(dspi->regmap_pushr, PUSHR_TX, txdata); + regmap_write(dspi->regmap_pushr, dspi->pushr_tx, txdata); } static void dspi_xspi_write(struct fsl_dspi *dspi, int cnt, bool eoq) @@ -1259,6 +1262,7 @@ static int dspi_probe(struct platform_device *pdev) struct fsl_dspi *dspi; struct resource *res; void __iomem *base; + bool big_endian; ctlr = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi)); if (!ctlr) @@ -1284,6 +1288,7 @@ static int dspi_probe(struct platform_device *pdev) /* Only Coldfire uses platform data */ dspi->devtype_data = &devtype_data[MCF5441X]; + big_endian = true; } else { ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num); @@ -1305,6 +1310,15 @@ static int dspi_probe(struct platform_device *pdev) ret = -EFAULT; goto out_ctlr_put; } + + big_endian = of_device_is_big_endian(np); + } + if (big_endian) { + dspi->pushr_cmd = 0; + dspi->pushr_tx = 2; + } else { + dspi->pushr_cmd = 2; + dspi->pushr_tx = 0; } if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE) From patchwork Wed Mar 18 00:15:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444265 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3D042159A for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0A3142076C for ; Wed, 18 Mar 2020 00:17:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iM9OE7YW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727256AbgCRARP (ORCPT ); Tue, 17 Mar 2020 20:17:15 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:56311 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727222AbgCRARO (ORCPT ); Tue, 17 Mar 2020 20:17:14 -0400 Received: by mail-wm1-f66.google.com with SMTP id 6so1303279wmi.5; Tue, 17 Mar 2020 17:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=6P5WrwP6NjFcOpItmukkhUoQXsuZS/+qjDY/l5RWgYs=; b=iM9OE7YWFJe0lfd+LhhyBOspbI54Pb75wlsiHAZWkCO7pAstzGMFDc0LZpZgJft8pC xK/OiCFJP5zUOA8PYHBMcnOBUwRxSDbX1rDjX3WEVJ5H6KN39ct5kxIDoulWws9OVgg7 P1oMSnRA1PVjFzxnTGA7kAtsv2bkmCR+T9mXNZLNWa1nOHQCOfYSgeKE4BLH6P8ZJRgW xWuZG+kmtSU3C5bFE0RfsdDxSiU02GipPsNJKheYfyN+p6YaQZPUik34sCRBQLswnNsl JDTDCi/H2elf0Z/PoAeAfjaZCz2gqdb83JZeWx5fuEudiVf6LcPjjMxYiYDMFQ77e7H3 3JEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=6P5WrwP6NjFcOpItmukkhUoQXsuZS/+qjDY/l5RWgYs=; b=GkA3euANffowsJpyNFpb12NQsIyov/vLlzcRBAJkn2uO8UkJ5RZtbWdbjq3iCswecI U8zhwUACo3LRDyGyIPVxVECe0zw1LKTowK7HX5zb9n9DeLEdVF7AdNVoUA6pmN15KVjK ex9r7RKasmpGKidJkAPjlGfaVQfdKF3aFA3aJvgD/oc7E7hDVc7VJglVppoYzdaAM3Pa JRwOtfdIECXosMncGBmDlumSynSU+l5K8j3uDH+fnjDYW461VLkZgF5cxAcstcf59uqk HLDnsRSvhplrT8f1nuPYa3QVHEsd6nmOFeXgxd3VqCL4P53tqy+RBcgCLpu9xt3DgM+m pgXw== X-Gm-Message-State: ANhLgQ3v9bIeRL0Os+4mpoQ/MBvyx2o1XUjA7kn6O3Wb/+qB98Txh5pH ZQaHYacARhHiI9beq8pvOMc= X-Google-Smtp-Source: ADFU+vt0clnLMBfdIRPQwGVCPmvf8lHWKxe429OrL2ZgaCjg7k6GTBrrIl1s80P7xh1bj/5T2s5rww== X-Received: by 2002:a05:600c:d8:: with SMTP id u24mr1610402wmm.42.1584490630918; Tue, 17 Mar 2020 17:17:10 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:10 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 03/12] spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode Date: Wed, 18 Mar 2020 02:15:54 +0200 Message-Id: <20200318001603.9650-4-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean In DMA mode, dspi_setup_accel does not get called, which results in the dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be initialized properly. Because oper_word_size is zero, a few calculations end up being incorrect, and the DMA transfer eventually times out instead of sending anything on the wire. Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel for DMA mode too. Also take the opportunity and simplify the DMA buffer handling a little bit. Fixes: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Rebased on top of "spi: spi-fsl-dspi: fix DMA mapping". Stopped uselessly writing to SPI_CTAR in dspi_transfer_one_message, since we already do that in dspi_setup_accel which we now call. Update message->actual_length before submitting the DMA transfer. Changes in v3: Pretty much re-did the patch. Before, dspi_setup_accel was called just once at the beginning of dspi_dma_xfer. Now it is called in the while loop. Everything else is just refactoring that follows along. Changes in v2: None. drivers/spi/spi-fsl-dspi.c | 86 ++++++++++++++------------------------ 1 file changed, 32 insertions(+), 54 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index be717776dd98..8f2b73cc6ed7 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -119,7 +119,6 @@ struct fsl_dspi_devtype_data { enum dspi_trans_mode trans_mode; u8 max_clock_factor; int fifo_size; - int dma_bufsize; }; enum { @@ -138,7 +137,6 @@ static const struct fsl_dspi_devtype_data devtype_data[] = { [VF610] = { .trans_mode = DSPI_DMA_MODE, .max_clock_factor = 2, - .dma_bufsize = 4096, .fifo_size = 4, }, [LS1021A] = { @@ -167,19 +165,16 @@ static const struct fsl_dspi_devtype_data devtype_data[] = { }, [LS2080A] = { .trans_mode = DSPI_DMA_MODE, - .dma_bufsize = 8, .max_clock_factor = 8, .fifo_size = 4, }, [LS2085A] = { .trans_mode = DSPI_DMA_MODE, - .dma_bufsize = 8, .max_clock_factor = 8, .fifo_size = 4, }, [LX2160A] = { .trans_mode = DSPI_DMA_MODE, - .dma_bufsize = 8, .max_clock_factor = 8, .fifo_size = 4, }, @@ -191,9 +186,6 @@ static const struct fsl_dspi_devtype_data devtype_data[] = { }; struct fsl_dspi_dma { - /* Length of transfer in words of dspi->fifo_size */ - u32 curr_xfer_len; - u32 *tx_dma_buf; struct dma_chan *chan_tx; dma_addr_t tx_dma_phys; @@ -352,7 +344,7 @@ static void dspi_rx_dma_callback(void *arg) int i; if (dspi->rx) { - for (i = 0; i < dma->curr_xfer_len; i++) + for (i = 0; i < dspi->words_in_flight; i++) dspi_push_rx(dspi, dspi->dma->rx_dma_buf[i]); } @@ -366,12 +358,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi) int time_left; int i; - for (i = 0; i < dma->curr_xfer_len; i++) + for (i = 0; i < dspi->words_in_flight; i++) dspi->dma->tx_dma_buf[i] = dspi_pop_tx_pushr(dspi); dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx, dma->tx_dma_phys, - dma->curr_xfer_len * + dspi->words_in_flight * DMA_SLAVE_BUSWIDTH_4_BYTES, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK); @@ -389,7 +381,7 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi) dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx, dma->rx_dma_phys, - dma->curr_xfer_len * + dspi->words_in_flight * DMA_SLAVE_BUSWIDTH_4_BYTES, DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT | DMA_CTRL_ACK); @@ -437,46 +429,42 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi) return 0; } +static void dspi_setup_accel(struct fsl_dspi *dspi); + static int dspi_dma_xfer(struct fsl_dspi *dspi) { struct spi_message *message = dspi->cur_msg; struct device *dev = &dspi->pdev->dev; - struct fsl_dspi_dma *dma = dspi->dma; - int curr_remaining_bytes; - int bytes_per_buffer; int ret = 0; - curr_remaining_bytes = dspi->len; - bytes_per_buffer = dspi->devtype_data->dma_bufsize / - dspi->devtype_data->fifo_size; - while (curr_remaining_bytes) { - /* Check if current transfer fits the DMA buffer */ - dma->curr_xfer_len = curr_remaining_bytes / - dspi->oper_word_size; - if (dma->curr_xfer_len > bytes_per_buffer) - dma->curr_xfer_len = bytes_per_buffer; + /* + * dspi->len gets decremented by dspi_pop_tx_pushr in + * dspi_next_xfer_dma_submit + */ + while (dspi->len) { + /* Figure out operational bits-per-word for this chunk */ + dspi_setup_accel(dspi); + + dspi->words_in_flight = dspi->len / dspi->oper_word_size; + if (dspi->words_in_flight > dspi->devtype_data->fifo_size) + dspi->words_in_flight = dspi->devtype_data->fifo_size; + + message->actual_length += dspi->words_in_flight * + dspi->oper_word_size; ret = dspi_next_xfer_dma_submit(dspi); if (ret) { dev_err(dev, "DMA transfer failed\n"); - goto exit; - - } else { - const int len = dma->curr_xfer_len * - dspi->oper_word_size; - curr_remaining_bytes -= len; - message->actual_length += len; - if (curr_remaining_bytes < 0) - curr_remaining_bytes = 0; + break; } } -exit: return ret; } static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) { + int dma_bufsize = dspi->devtype_data->fifo_size * 2; struct device *dev = &dspi->pdev->dev; struct dma_slave_config cfg; struct fsl_dspi_dma *dma; @@ -501,16 +489,16 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) } dma->tx_dma_buf = dma_alloc_coherent(dma->chan_tx->device->dev, - dspi->devtype_data->dma_bufsize, - &dma->tx_dma_phys, GFP_KERNEL); + dma_bufsize, &dma->tx_dma_phys, + GFP_KERNEL); if (!dma->tx_dma_buf) { ret = -ENOMEM; goto err_tx_dma_buf; } dma->rx_dma_buf = dma_alloc_coherent(dma->chan_rx->device->dev, - dspi->devtype_data->dma_bufsize, - &dma->rx_dma_phys, GFP_KERNEL); + dma_bufsize, &dma->rx_dma_phys, + GFP_KERNEL); if (!dma->rx_dma_buf) { ret = -ENOMEM; goto err_rx_dma_buf; @@ -547,12 +535,10 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) err_slave_config: dma_free_coherent(dma->chan_rx->device->dev, - dspi->devtype_data->dma_bufsize, - dma->rx_dma_buf, dma->rx_dma_phys); + dma_bufsize, dma->rx_dma_buf, dma->rx_dma_phys); err_rx_dma_buf: dma_free_coherent(dma->chan_tx->device->dev, - dspi->devtype_data->dma_bufsize, - dma->tx_dma_buf, dma->tx_dma_phys); + dma_bufsize, dma->tx_dma_buf, dma->tx_dma_phys); err_tx_dma_buf: dma_release_channel(dma->chan_tx); err_tx_channel: @@ -566,6 +552,7 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr) static void dspi_release_dma(struct fsl_dspi *dspi) { + int dma_bufsize = dspi->devtype_data->fifo_size * 2; struct fsl_dspi_dma *dma = dspi->dma; if (!dma) @@ -573,15 +560,13 @@ static void dspi_release_dma(struct fsl_dspi *dspi) if (dma->chan_tx) { dma_unmap_single(dma->chan_tx->device->dev, dma->tx_dma_phys, - dspi->devtype_data->dma_bufsize, - DMA_TO_DEVICE); + dma_bufsize, DMA_TO_DEVICE); dma_release_channel(dma->chan_tx); } if (dma->chan_rx) { dma_unmap_single(dma->chan_rx->device->dev, dma->rx_dma_phys, - dspi->devtype_data->dma_bufsize, - DMA_FROM_DEVICE); + dma_bufsize, DMA_FROM_DEVICE); dma_release_channel(dma->chan_rx); } } @@ -833,7 +818,7 @@ static void dspi_setup_accel(struct fsl_dspi *dspi) dspi->oper_word_size = DIV_ROUND_UP(dspi->oper_bits_per_word, 8); /* - * Update CTAR here (code is common for both EOQ and XSPI modes). + * Update CTAR here (code is common for EOQ, XSPI and DMA modes). * We will update CTARE in the portion specific to XSPI, when we * also know the preload value (DTCP). */ @@ -960,13 +945,6 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF, SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF); - /* - * Static CTAR setup for modes that don't dynamically adjust it - * via dspi_setup_accel (aka for DMA) - */ - regmap_write(dspi->regmap, SPI_CTAR(0), - dspi->cur_chip->ctar_val | - SPI_FRAME_BITS(transfer->bits_per_word)); spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer, dspi->progress, !dspi->irq); From patchwork Wed Mar 18 00:15:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444247 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2F9B6159A for ; Wed, 18 Mar 2020 00:17:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E78020754 for ; Wed, 18 Mar 2020 00:17:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jbSOl1Aw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbgCRARP (ORCPT ); Tue, 17 Mar 2020 20:17:15 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:56315 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726991AbgCRARO (ORCPT ); Tue, 17 Mar 2020 20:17:14 -0400 Received: by mail-wm1-f68.google.com with SMTP id 6so1303305wmi.5; Tue, 17 Mar 2020 17:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=LtJjhRPIy7AYBnH/+FNJCutzC44JnMplfSDwQrTUa8w=; b=jbSOl1Awue/1LPRRc+xSPb9r+8QvOIlbvb25O6i8BGZgfpAtA1ZOnCyPHRosISF29I Ezp/SyZTuH3p2oeNcSk8B51hijLOv/S3UhcF+MUiHyRbxdPUKZRHALBHAuOPiqEJ4tCF J4orZviFR1gSge+5sFACQXQmzWW8/PeBHnW6qDaRYMYeAXVX+j32QzRO4LaKXnaWXJCT jeNkLOHqZaHk7fICB7yV0wQTrRJX1W6pa1Scdx3JhTrzqUMeGEC+MXUaAZGeUu5ygi1r hk0En70j4+s45QLwK7KAnIcZ+2+/7WB5LE9ZjRNtvS/WR9VSU4DnkyX7qjvc3gi3LDI2 dMkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=LtJjhRPIy7AYBnH/+FNJCutzC44JnMplfSDwQrTUa8w=; b=KLbno19G/uX4BmOYYXLeGvJCeCAdFfxMjwu7qVG/rI7pcG3SRfiC+z62Do79Umvk/C 5dJ5cHc2P3CtCyzcewGwRSl1gjvonbsnFxZQMSbNLZhpTUnGgwYac8x7fA5bQSFiCgrl NPgtdnfkns12KXWcbm33v3ZBGK0le4j/cA9qcOo3U9HjIR1iZKjqX/NUmE2GpbvrWQmW XTr66LWse8sFDIWntu/ElsyBI0KAXNdvzTF4FBTR2WaWGxYoOMwLbHzzrNMbTUIbD9mF kvKNF39eg+CpIdLEVZ3d3q8huMzKK+7fErQm+06viw2mLP+qQHneAIKsLsbsVIeuFM9k I0aw== X-Gm-Message-State: ANhLgQ01IuxCxCxw0zC4IPfwjKt1km7I2FFcFfxDa7rZE6mfFPn5MJeg 3DrlMni7vyPb4eBeYGr5iFEgc7/N0X2+Iw== X-Google-Smtp-Source: ADFU+vv2Vh7Eu15pOeJ/8F/ptvM5dbg6R3B92VKZ7YtIKaJesNpIXOy/Yipqg7DRWKcpi43GLhf52w== X-Received: by 2002:a1c:de82:: with SMTP id v124mr1539863wmg.70.1584490632322; Tue, 17 Mar 2020 17:17:12 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:11 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 04/12] spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode Date: Wed, 18 Mar 2020 02:15:55 +0200 Message-Id: <20200318001603.9650-5-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean If dspi->words_in_flight is populated with the hardware FIFO size, then in dspi_fifo_read it will attempt to read more data at the end of a buffer that is not a multiple of 16 bytes in length. It will probably time out attempting to do so. So limit the num_fifo_entries variable to the actual number of FIFO entries that is going to be used. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Patch is new. drivers/spi/spi-fsl-dspi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 8f2b73cc6ed7..51224b772680 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -739,13 +739,16 @@ static void dspi_eoq_fifo_write(struct fsl_dspi *dspi) int num_fifo_entries = dspi->devtype_data->fifo_size; u16 xfer_cmd = dspi->tx_cmd; + if (num_fifo_entries * dspi->oper_word_size > dspi->len) + num_fifo_entries = dspi->len / dspi->oper_word_size; + dspi->words_in_flight = num_fifo_entries; /* Fill TX FIFO with as many transfers as possible */ - while (dspi->len && num_fifo_entries--) { + while (num_fifo_entries--) { dspi->tx_cmd = xfer_cmd; /* Request EOQF for last transfer in FIFO */ - if (dspi->len == dspi->oper_word_size || num_fifo_entries == 0) + if (num_fifo_entries == 0) dspi->tx_cmd |= SPI_PUSHR_CMD_EOQ; /* Write combined TX FIFO and CMD FIFO entry */ dspi_pushr_write(dspi); From patchwork Wed Mar 18 00:15:56 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444249 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 79FB9159A for ; Wed, 18 Mar 2020 00:17:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3982720738 for ; Wed, 18 Mar 2020 00:17:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MffqPYB0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727298AbgCRARR (ORCPT ); Tue, 17 Mar 2020 20:17:17 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:41390 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727249AbgCRARQ (ORCPT ); Tue, 17 Mar 2020 20:17:16 -0400 Received: by mail-wr1-f66.google.com with SMTP id f11so11315355wrp.8; Tue, 17 Mar 2020 17:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=xVknuaNdOMQX03RuI0SzV8850sN44K94XjBLipDYOqs=; b=MffqPYB0yAfhNUEUaOWqsKLh0wTbP5IJztAsaokxaK9fi/RBhjVpJGPAwXbI5wjEwA 2VKCQuPwZHOX39VhWNQOaYC8BYYh9VAsZgAZhORweQ0pLp/nMVmri1XSmdyi6lhIDAoz 2wU+qj/5mZG8YEAt9DQC7w7pLoRkDMNLF5PC0cfllC/yKGf2W+eh0WWX0U217wCbgWsz 8CYZ9XZX0E5ij1P4npCWx//HB4kXsxHpYqDeZ92HbU/C7KL5/zeWl2DqkIO2PP5HlCE3 XREeuKchiWwmsloNCXVv/jci4vv2tGj6lBZ5mjw+a5ls6imYUlW79B2L0yMuEnAVIy+o LLDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=xVknuaNdOMQX03RuI0SzV8850sN44K94XjBLipDYOqs=; b=mLJjjXaScFW/O6fZghNR+901qoeAEV90vNsOpY2A+igdptAXZh1+UXhnjov8Zo47gs I3NXtpDCNxRmhdnoF2TLRSrEGaNf6pGoaqNBSf6twL5lo2/KcO9gYgMRcX7EIneg7zZU 3ITdlIlx5BPmAnY/zQLX0RUh7bgiJNE+TEOufLP8LYXG9dRZPcf2hRt3H4TZ0TrR9pam CkjkMqANCIbFSQrBvUaAaOiJ8HtDj91bHjfV+KaOh0mQgV3gLKuyUtlpbHUj2GTp3BRr 0gpIfvmNNz2A8+gD1ZO3S/DzXn7blVxEr2ztrbPMTno8F2zKbKBJ4X9VE2kriDcyAGxQ cTOg== X-Gm-Message-State: ANhLgQ3Xdjv3xeOquXyMIlOCnREarXRrOmaw0H2LAin9wbY4qi7jKlhz 2EabSBCeIyJK+CkXdURVzys/4QStURrZCA== X-Google-Smtp-Source: ADFU+vtAi5S9Jfj4w5lAMDwnkAgqW2+H+8HxTz/zgr14Rf9/ax3hjoovuSkwaeWKuCRkw8L7UKVfTg== X-Received: by 2002:adf:fcce:: with SMTP id f14mr1626163wrs.200.1584490633738; Tue, 17 Mar 2020 17:17:13 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:13 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 05/12] spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight Date: Wed, 18 Mar 2020 02:15:56 +0200 Message-Id: <20200318001603.9650-6-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean dspi->words_in_flight is a variable populated in the *_write functions and used in the dspi_fifo_read function. It is also used in dspi_fifo_write, immediately after transmission, to update the message->actual_length variable used by higher layers such as spi-mem for integrity checking. But it may happen that the IRQ which calls dspi_fifo_read to be triggered before the updating of message->actual_length takes place. In that case, dspi_fifo_read will decrement dspi->words_in_flight to -1, and that will cause an invalid modification of message->actual_length. For that, we make the simplest fix possible: to not decrement the actual shared variable in dspi->words_in_flight from dspi_fifo_read, but actually a copy of it which is on stack. But even if dspi_fifo_read from the next IRQ does not interfere with the dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still can. So we must assume that everything after the last write to the TX FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write function must be safe against that. This means refactoring the 2 flavours of FIFO writes (for EOQ and XSPI) such that the calculation of the number of words to be written is common and happens a priori. This way, the code for updating the message->actual_length variable works with a copy and not with the volatile dspi->words_in_flight. After some interior debate, the dspi->progress variable used for software timestamping was *not* backed up against preemption in a copy on stack. Because if preemption does occur between spi_take_timestamp_pre and spi_take_timestamp_post, there's really no point in trying to save anything. The first-in-time spi_take_timestamp_post call with a dspi->progress higher than the requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true anyway and will close the deal. To understand the above a bit better, consider a transfer with xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI controller timestamps in chunks of 4 bytes at a time, and preemption occurs in the middle of timestamping the first chunk: spi_take_timestamp_pre(0) . . (preemption) . . spi_take_timestamp_pre(4) . . spi_take_timestamp_post(7) . spi_take_timestamp_post(3) So the reason I'm not bothering to back up dspi->progress for that spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going to (a) be more honest, (b) provide better accuracy and (c) already render the spi_take_timestamp_post(3) into a noop by setting xfer->timestamped = true anyway. Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Reported-by: Michael Walle Signed-off-by: Vladimir Oltean --- Changes in v5: Enhanced the patch such that dspi->words_in_flight is protected against races with the next dspi_fifo_write too. This implied rather major refactoring of dspi_xspi_fifo_write and dspi_eoq_fifo_write unfortunately. Perhaps the good side of things is that the dspi_xspi_write function has now disappeared (has merged with dspi_xspi_fifo_write). Changes in v4: Patch is new. drivers/spi/spi-fsl-dspi.c | 111 +++++++++++++++++-------------------- 1 file changed, 52 insertions(+), 59 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 51224b772680..f7e1e7085e31 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -669,17 +669,26 @@ static void dspi_pushr_txdata_write(struct fsl_dspi *dspi, u16 txdata) regmap_write(dspi->regmap_pushr, dspi->pushr_tx, txdata); } -static void dspi_xspi_write(struct fsl_dspi *dspi, int cnt, bool eoq) +static void dspi_xspi_fifo_write(struct fsl_dspi *dspi, int num_words) { + int num_bytes = num_words * dspi->oper_word_size; u16 tx_cmd = dspi->tx_cmd; - if (eoq) + /* + * If the PCS needs to de-assert (i.e. we're at the end of the buffer + * and cs_change does not want the PCS to stay on), then we need a new + * PUSHR command, since this one (for the body of the buffer) + * necessarily has the CONT bit set. + * So send one word less during this go, to force a split and a command + * with a single word next time, when CONT will be unset. + */ + if (!(dspi->tx_cmd & SPI_PUSHR_CMD_CONT) && num_bytes == dspi->len) tx_cmd |= SPI_PUSHR_CMD_EOQ; /* Update CTARE */ regmap_write(dspi->regmap, SPI_CTARE(0), SPI_FRAME_EBITS(dspi->oper_bits_per_word) | - SPI_CTARE_DTCP(cnt)); + SPI_CTARE_DTCP(num_words)); /* * Write the CMD FIFO entry first, and then the two @@ -688,7 +697,7 @@ static void dspi_xspi_write(struct fsl_dspi *dspi, int cnt, bool eoq) dspi_pushr_cmd_write(dspi, tx_cmd); /* Fill TX FIFO with as many transfers as possible */ - while (cnt--) { + while (num_words--) { u32 data = dspi_pop_tx(dspi); dspi_pushr_txdata_write(dspi, data & 0xFFFF); @@ -697,58 +706,15 @@ static void dspi_xspi_write(struct fsl_dspi *dspi, int cnt, bool eoq) } } -static void dspi_xspi_fifo_write(struct fsl_dspi *dspi) -{ - int num_fifo_entries = dspi->devtype_data->fifo_size; - int bytes_in_flight; - bool eoq = false; - - /* In XSPI mode each 32-bit word occupies 2 TX FIFO entries */ - if (dspi->oper_word_size == 4) - num_fifo_entries /= 2; - - /* - * Integer division intentionally trims off odd (or non-multiple of 4) - * numbers of bytes at the end of the buffer, which will be sent next - * time using a smaller oper_word_size. - */ - dspi->words_in_flight = dspi->len / dspi->oper_word_size; - - if (dspi->words_in_flight > num_fifo_entries) - dspi->words_in_flight = num_fifo_entries; - - bytes_in_flight = dspi->words_in_flight * dspi->oper_word_size; - - /* - * If the PCS needs to de-assert (i.e. we're at the end of the buffer - * and cs_change does not want the PCS to stay on), then we need a new - * PUSHR command, since this one (for the body of the buffer) - * necessarily has the CONT bit set. - * So send one word less during this go, to force a split and a command - * with a single word next time, when CONT will be unset. - */ - if (!(dspi->tx_cmd & SPI_PUSHR_CMD_CONT) && - bytes_in_flight == dspi->len) - eoq = true; - - dspi_xspi_write(dspi, dspi->words_in_flight, eoq); -} - -static void dspi_eoq_fifo_write(struct fsl_dspi *dspi) +static void dspi_eoq_fifo_write(struct fsl_dspi *dspi, int num_words) { - int num_fifo_entries = dspi->devtype_data->fifo_size; u16 xfer_cmd = dspi->tx_cmd; - if (num_fifo_entries * dspi->oper_word_size > dspi->len) - num_fifo_entries = dspi->len / dspi->oper_word_size; - - dspi->words_in_flight = num_fifo_entries; - /* Fill TX FIFO with as many transfers as possible */ - while (num_fifo_entries--) { + while (num_words--) { dspi->tx_cmd = xfer_cmd; /* Request EOQF for last transfer in FIFO */ - if (num_fifo_entries == 0) + if (num_words == 0) dspi->tx_cmd |= SPI_PUSHR_CMD_EOQ; /* Write combined TX FIFO and CMD FIFO entry */ dspi_pushr_write(dspi); @@ -765,8 +731,10 @@ static u32 dspi_popr_read(struct fsl_dspi *dspi) static void dspi_fifo_read(struct fsl_dspi *dspi) { + int num_fifo_entries = dspi->words_in_flight; + /* Read one FIFO entry and push to rx buffer */ - while (dspi->words_in_flight--) + while (num_fifo_entries--) dspi_push_rx(dspi, dspi_popr_read(dspi)); } @@ -832,23 +800,48 @@ static void dspi_setup_accel(struct fsl_dspi *dspi) static void dspi_fifo_write(struct fsl_dspi *dspi) { + int num_fifo_entries = dspi->devtype_data->fifo_size; struct spi_transfer *xfer = dspi->cur_transfer; struct spi_message *msg = dspi->cur_msg; - int bytes_sent; + int num_words, num_bytes; dspi_setup_accel(dspi); + /* In XSPI mode each 32-bit word occupies 2 TX FIFO entries */ + if (dspi->oper_word_size == 4) + num_fifo_entries /= 2; + + /* + * Integer division intentionally trims off odd (or non-multiple of 4) + * numbers of bytes at the end of the buffer, which will be sent next + * time using a smaller oper_word_size. + */ + num_words = dspi->len / dspi->oper_word_size; + if (num_words > num_fifo_entries) + num_words = num_fifo_entries; + + /* Update total number of bytes that were transferred */ + num_bytes = num_words * dspi->oper_word_size; + msg->actual_length += num_bytes; + dspi->progress += num_bytes / DIV_ROUND_UP(xfer->bits_per_word, 8); + + /* + * Update shared variable for use in the next interrupt (both in + * dspi_fifo_read and in dspi_fifo_write). + */ + dspi->words_in_flight = num_words; + spi_take_timestamp_pre(dspi->ctlr, xfer, dspi->progress, !dspi->irq); if (dspi->devtype_data->trans_mode == DSPI_EOQ_MODE) - dspi_eoq_fifo_write(dspi); + dspi_eoq_fifo_write(dspi, num_words); else - dspi_xspi_fifo_write(dspi); - - /* Update total number of bytes that were transferred */ - bytes_sent = dspi->words_in_flight * dspi->oper_word_size; - msg->actual_length += bytes_sent; - dspi->progress += bytes_sent / DIV_ROUND_UP(xfer->bits_per_word, 8); + dspi_xspi_fifo_write(dspi, num_words); + /* + * Everything after this point is in a potential race with the next + * interrupt, so we must never use dspi->words_in_flight again since it + * might already be modified by the next dspi_fifo_write. + */ spi_take_timestamp_post(dspi->ctlr, dspi->cur_transfer, dspi->progress, !dspi->irq); From patchwork Wed Mar 18 00:15:57 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444261 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A5AD390 for ; Wed, 18 Mar 2020 00:17:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7B2DD2076C for ; Wed, 18 Mar 2020 00:17:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UvC3s0r/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727323AbgCRARU (ORCPT ); Tue, 17 Mar 2020 20:17:20 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:36086 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727286AbgCRARS (ORCPT ); Tue, 17 Mar 2020 20:17:18 -0400 Received: by mail-wr1-f66.google.com with SMTP id s5so28155175wrg.3; Tue, 17 Mar 2020 17:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=YHxBv1zCyr+7Y7Cl8HOKgnuldXvTo4vjeYMsdD/nitk=; b=UvC3s0r/EJR2aPWiUJWjZaapXdifCNO6jlzkDAh4umNPM9XShMWaNv25/jEcduqENf aVdyj0JyhotSnwEZxpd43SjZYUkxnDPxpGsAgULXcmepLUrVnD/AyddD1T18VjWYYZ0T IIufPl8KUBzobzAj4GTqw/AqBDG3Qh2ktwUuDMDdz4SnwehF1HwvSD+daKjS71lgsYeC hDqjdti1VV30gd9IG7iSYWA9ZYgOXMFuyAkUu868a5M8IeqOj9jzX8o/Rbr4cwmfELpv P607NkjUV2u5Uk+V5pDMOvA7vi44byH6uRmtFKIFe99aie9EBbIpCc0FAhMcSgg1Y64P 7nsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=YHxBv1zCyr+7Y7Cl8HOKgnuldXvTo4vjeYMsdD/nitk=; b=KV72And82EdJFdNcpUkYG6HZl0kYMMDH7ayM9P8lbf6pzgvezWbHzS5q+6tToHYOsw pW6CEF8B303yiSR+/HWDfRX/TnIeMEwDpUH1ma7V+NTTopZHAUQFiEBaJCCvhsqYamVS /M3j+I7IU5tfloIAH2vLbnxT3aAs232N7+EBeSFCcDaIoqyM0YP5FMQpqAuzAXYpahxk 49ezdBgInppG9CUCfgujoRJQ2MCPUSE5kBjYeMSBLMsBAHpvf7HvcddTTxnouos99JWg efHqmRkX2meRmIiWfbpVxAxV+80kMgvFxaOsIzLNbH0NrQqxwUL39YawaFcszMEAqpyt 5M9Q== X-Gm-Message-State: ANhLgQ0fnAvcTDpRg8TYf7w7n7gsipYGY2x5BiypIZi/DYKTx8mYgCPa 2KPg7N8r5u89b2SXXePFtCE= X-Google-Smtp-Source: ADFU+vvZ9vN3yhW/hBCy/gzs2wLKwLV7QWg6LS27Eh8qkQr3sWFj/tSJDECfhC/oEE0XEV27/jDulQ== X-Received: by 2002:a5d:474b:: with SMTP id o11mr1560013wrs.4.1584490635082; Tue, 17 Mar 2020 17:17:15 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:14 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 06/12] spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion Date: Wed, 18 Mar 2020 02:15:57 +0200 Message-Id: <20200318001603.9650-7-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean Currently the driver puts the process in interruptible sleep waiting for the interrupt train to finish transfer to/from the tx_buf and rx_buf. But exiting the process with ctrl-c may make the kernel panic: the wait_event_interruptible call will return -ERESTARTSYS, which a proper driver implementation is perhaps supposed to handle, but nonetheless this one doesn't, and aborts the transfer altogether. Actually when the task is interrupted, there is still a high chance that the dspi_interrupt is still triggering. And if dspi_transfer_one_message returns execution all the way to the spi_device driver, that can free the spi_message and spi_transfer structures, leaving the interrupts to access a freed tx_buf and rx_buf. hexdump -C /dev/mtd0 00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff |.uhu............| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * ^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed! [ 38.503097] spi_master spi2: failed to transfer one message from queue [ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377 [ 38.517676] Mem abort info: [ 38.520474] ESR = 0x96000045 [ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.528861] SET = 0, FnV = 0 [ 38.531921] EA = 0, S1PTW = 0 [ 38.535067] Data abort info: [ 38.537952] ISV = 0, ISS = 0x00000045 [ 38.541797] CM = 0, WnR = 1 [ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000 [ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000 [ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 38.565819] Modules linked in: [ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193 [ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110 [ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90 [ 38.601203] sp : ffff800010003d90 [ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000 [ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400 [ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0 [ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377 [ 38.625841] x21: 000000000000146e x20: ffff8000120c3000 [ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948 [ 38.636498] x17: 0000000000000000 x16: 0000000000000000 [ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720 [ 38.647155] x13: 0720072007200765 x12: 0775076507750771 [ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040 [ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8 [ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60 [ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377 [ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0 [ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026 [ 38.684454] Call trace: [ 38.686905] ktime_get_real_ts64+0x3c/0x110 [ 38.691100] spi_take_timestamp_pre+0x40/0x90 [ 38.695470] dspi_fifo_write+0x58/0x2c0 [ 38.699315] dspi_interrupt+0xbc/0xd0 [ 38.702987] __handle_irq_event_percpu+0x78/0x2c0 [ 38.707706] handle_irq_event_percpu+0x3c/0x90 [ 38.712161] handle_irq_event+0x4c/0xd0 [ 38.716008] handle_fasteoi_irq+0xbc/0x170 [ 38.720115] generic_handle_irq+0x2c/0x40 [ 38.724135] __handle_domain_irq+0x68/0xc0 [ 38.728243] gic_handle_irq+0xc8/0x160 [ 38.732000] el1_irq+0xb8/0x180 [ 38.735149] spi_nor_spimem_read_data+0xe0/0x140 [ 38.739779] spi_nor_read+0xc4/0x120 [ 38.743364] mtd_read_oob+0xa8/0xc0 [ 38.746860] mtd_read+0x4c/0x80 [ 38.750007] mtdchar_read+0x108/0x2a0 [ 38.753679] __vfs_read+0x20/0x50 [ 38.757002] vfs_read+0xa4/0x190 [ 38.760237] ksys_read+0x6c/0xf0 [ 38.763471] __arm64_sys_read+0x20/0x30 [ 38.767319] el0_svc_common.constprop.3+0x90/0x160 [ 38.772125] do_el0_svc+0x28/0x90 [ 38.775449] el0_sync_handler+0x118/0x190 [ 38.779468] el0_sync+0x140/0x180 [ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0) [ 38.788910] ---[ end trace 55da560db4d6bef7 ]--- [ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt [ 38.799914] SMP: stopping secondary CPUs [ 38.803849] Kernel Offset: disabled [ 38.807344] CPU features: 0x10002,20006008 [ 38.811451] Memory Limit: none [ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- So it is clear that the "interruptible" part isn't handled correctly. When the process receives a signal, one could either attempt a clean abort (which appears to be difficult with this hardware) or just keep restarting the sleep until the wait queue really completes. But checking in a loop for -ERESTARTSYS is a bit too complicated for this driver, so just make the sleep uninterruptible, to avoid all that nonsense. The wait queue was actually restructured as a completion, after polling other drivers for the most "popular" approach. Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Reported-by: Michael Walle Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Removed the dspi_disable_interrupts and dspi_enable_interrupts approach and replaced it with this method. Changes in v3: Patch is new. drivers/spi/spi-fsl-dspi.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index f7e1e7085e31..b65c21d048f9 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -218,8 +218,7 @@ struct fsl_dspi { u16 tx_cmd; const struct fsl_dspi_devtype_data *devtype_data; - wait_queue_head_t waitq; - u32 waitflags; + struct completion xfer_done; struct fsl_dspi_dma *dma; @@ -890,10 +889,8 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id) if (!(spi_sr & (SPI_SR_EOQF | SPI_SR_CMDTCF))) return IRQ_NONE; - if (dspi_rxtx(dspi) == 0) { - dspi->waitflags = 1; - wake_up_interruptible(&dspi->waitq); - } + if (dspi_rxtx(dspi) == 0) + complete(&dspi->xfer_done); return IRQ_HANDLED; } @@ -973,13 +970,9 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, status = dspi_poll(dspi); } while (status == -EINPROGRESS); } else if (trans_mode != DSPI_DMA_MODE) { - status = wait_event_interruptible(dspi->waitq, - dspi->waitflags); - dspi->waitflags = 0; + wait_for_completion(&dspi->xfer_done); + reinit_completion(&dspi->xfer_done); } - if (status) - dev_err(&dspi->pdev->dev, - "Waiting for transfer to complete failed!\n"); spi_transfer_delay_exec(transfer); } @@ -1359,7 +1352,7 @@ static int dspi_probe(struct platform_device *pdev) goto out_clk_put; } - init_waitqueue_head(&dspi->waitq); + init_completion(&dspi->xfer_done); poll_mode: From patchwork Wed Mar 18 00:15:58 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444251 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2999B90 for ; Wed, 18 Mar 2020 00:17:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 076F520738 for ; Wed, 18 Mar 2020 00:17:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nF80gTQe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727325AbgCRARV (ORCPT ); Tue, 17 Mar 2020 20:17:21 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:42913 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727297AbgCRARS (ORCPT ); Tue, 17 Mar 2020 20:17:18 -0400 Received: by mail-wr1-f68.google.com with SMTP id v11so28140554wrm.9; Tue, 17 Mar 2020 17:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=do7ELkqPnkaQdQSXxeirNxxb2K6EQjDuUS0MOsNqAx0=; b=nF80gTQePFcG6c8yIYXVht24MAiuD6AdREzl1+Co6qjbvmpJhY5B/bXdWORSmaLc8J /XwYdjJuVVYuYhc0ZrBRHWJxv0efsOj/HMeN/NUyGi0FDeDbClfGNNawBOYxBrCZu/ZZ t876/49RrpHuhtZIbCb3y+PsmO25U0zxv5EfS9Jz8WifFxXdBLcbqIo9IpnhpP+vkBkh UU9h280KDbmDiajlwBEVnvsxqaHfHBnWSNsmuZ5YULONIjCJJQbroUXaPJ77Dzq3lRM2 TiEtVmIri5A66vcUTarwwVbCBATretv4Ji6Gd2wa9W7yTxln1/MX2OVUagwrvrEEn9m/ YI/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=do7ELkqPnkaQdQSXxeirNxxb2K6EQjDuUS0MOsNqAx0=; b=NyjUWyRqt85R4KopTw+x79Au45sUC2GiGfq1yL5QXLjA7rW2SKvZmhJ5iQEow9kqc9 HQSUi6V5389EXFGNseNypD9f/dNNOl+6ikNtK5BSeT8zk5R0sKohwlIVurDuZG7bmsMt d35qOopHNPkjAws+ONNJwsdl+SG/t+STMaF+xmPfsgWlmScJkUOX3W/54anyglpasOMa Bck+Xv4N5zy+pFH4AqCLwC2Z7lzYLn3HlU0ZXhwLPO4k2AH4z5W9n5zWJNWHDnYFL61b VT+Uv9PyObHX6u5wlsMp3Vp4cRx3IVZywK7HXjk16DC1d3Af/PlJbgWjKliOvO/clmhL NMbg== X-Gm-Message-State: ANhLgQ3ZsZBecH3xo+k/wqxnWS4KHiWeld8/Olmzh2mUtsFAZu/l0Cbh cXe/VkFS70aW5Mp9Rm1XsVw= X-Google-Smtp-Source: ADFU+vstrTQcynMf9WAA55e8it4/BwbpsEpc3yAFiGVSlVNtYsJjVRRU5nNXXh0X0tGtvFCg9+iPHQ== X-Received: by 2002:adf:97d5:: with SMTP id t21mr1542972wrb.45.1584490636460; Tue, 17 Mar 2020 17:17:16 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:15 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 07/12] spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA mode Date: Wed, 18 Mar 2020 02:15:58 +0200 Message-Id: <20200318001603.9650-8-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean The driver does not create the dspi->dma structure unless operating in DSPI_DMA_MODE, so it makes sense to check for that. Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Patch is new. drivers/spi/spi-fsl-dspi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index b65c21d048f9..81e22b6eadc7 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -1192,8 +1192,10 @@ static int dspi_slave_abort(struct spi_master *master) * Terminate all pending DMA transactions for the SPI working * in SLAVE mode. */ - dmaengine_terminate_sync(dspi->dma->chan_rx); - dmaengine_terminate_sync(dspi->dma->chan_tx); + if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) { + dmaengine_terminate_sync(dspi->dma->chan_rx); + dmaengine_terminate_sync(dspi->dma->chan_tx); + } /* Clear the internal DSPI RX and TX FIFO buffers */ regmap_update_bits(dspi->regmap, SPI_MCR, From patchwork Wed Mar 18 00:15:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444263 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AEE5B159A for ; Wed, 18 Mar 2020 00:17:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D90220757 for ; Wed, 18 Mar 2020 00:17:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KwyMwcTv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727301AbgCRARU (ORCPT ); Tue, 17 Mar 2020 20:17:20 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:44249 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727313AbgCRART (ORCPT ); Tue, 17 Mar 2020 20:17:19 -0400 Received: by mail-wr1-f68.google.com with SMTP id y2so12610245wrn.11; Tue, 17 Mar 2020 17:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=00i66m1wtM2+P1s/tRhqDIGUbMRLcSr0KSarPdUP5w0=; b=KwyMwcTvlZwqq7M8RopS1rcsR9Pl4g3h8aAWTRuCDWS/Y+PAsOCDZV89UouR8StFl8 /sMiQT1OWTZN3nSViZGALrlWN80fh+L1WbdBv/e0lMGWY4U2edaugJnZEuZ6oP7wgHbA 3w8LEef+quCgr8bHoce/njjXXsPenhxo95XM1YqdDJlQ1BZQRQ9rG1pR684o663i+/M7 jfSgPCBfcuwU114PeueZtBc2XnUZblJQT2lHXTfLfVZyceuzLiEeIfV9uOhMtuvcOeUc kf6H9C5IPaJR++D15CbHz+F6GTkRXNNTbpNQcojxqX8DYMx5ltIj0z7urfTU8NMHAO7k CnmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=00i66m1wtM2+P1s/tRhqDIGUbMRLcSr0KSarPdUP5w0=; b=nRHA9c3N9OLxFjMGpj4URTDAaKTnrBlf/7vyUq0Bu0B9DHuVadXYHDPu88imPq6DbA Rd4Do7FzI3k8SHORFj1IJJ9eRbLMu6FBlRik/ePDc37dmAvE/U2NGSMovXy1hC6TLYIj ZftgIZ1tU6zA0cbbQ2B6wojcglK5RlupAd7tZ9nkaM7kPC6bwG31pjQJxkr+0dfDQ1pY A6/k4k7BKOciR8Rfk6VJ2F3yTJ+t/Vby33WN5zeVsniH6wH+IeFGHNMZcSAI1au+Mq4N n61+BIgEOLoN6ccqW+UNHtWRlEY2VVupxqQmBsyTtn21W2R+eZmxOPbzJTVjXMovvNzB +8Sg== X-Gm-Message-State: ANhLgQ33oTR2aBwgsRJSQ2cohdEOY4ezD8nU37dZHK8QarLzxqNp/c12 mhLhNFd5JW4ZMBvrvxhlPVU= X-Google-Smtp-Source: ADFU+vvtlrjqyj2EntsV/CBRdNvwL6+zfzVjVL1dzehHxplW/HnQN2fzjCzAS9/vuC8hEo2yuTH7Hg== X-Received: by 2002:a5d:6150:: with SMTP id y16mr1631350wrt.352.1584490637777; Tue, 17 Mar 2020 17:17:17 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:17 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 08/12] spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code path Date: Wed, 18 Mar 2020 02:15:59 +0200 Message-Id: <20200318001603.9650-9-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean Interrupts are not necessary for DMA functionality, since the completion event is provided by the DMA driver. But if the driver fails to request the IRQ defined in the device tree, it will call dspi_poll which would make the driver hang waiting for data to become available in the RX FIFO. Fixes: c55be3059159 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing") Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Patch is new. drivers/spi/spi-fsl-dspi.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 81e22b6eadc7..fcc6f20b6631 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -965,13 +965,15 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, goto out; } - if (!dspi->irq) { - do { - status = dspi_poll(dspi); - } while (status == -EINPROGRESS); - } else if (trans_mode != DSPI_DMA_MODE) { - wait_for_completion(&dspi->xfer_done); - reinit_completion(&dspi->xfer_done); + if (trans_mode != DSPI_DMA_MODE) { + if (dspi->irq) { + wait_for_completion(&dspi->xfer_done); + reinit_completion(&dspi->xfer_done); + } else { + do { + status = dspi_poll(dspi); + } while (status == -EINPROGRESS); + } } spi_transfer_delay_exec(transfer); From patchwork Wed Mar 18 00:16:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444253 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E0E99159A for ; Wed, 18 Mar 2020 00:17:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B729A20738 for ; Wed, 18 Mar 2020 00:17:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dHeui0iF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727341AbgCRARV (ORCPT ); Tue, 17 Mar 2020 20:17:21 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:41400 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727249AbgCRARU (ORCPT ); Tue, 17 Mar 2020 20:17:20 -0400 Received: by mail-wr1-f68.google.com with SMTP id f11so11315567wrp.8; Tue, 17 Mar 2020 17:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=dbvFXr++MU/HIreOWScTU6cmRztuJ1BeSWU0vX/lVDQ=; b=dHeui0iFI86MShMTkkkK4yVQ4udUyV54/uCPA9EgN/FntTBiJX7K5n1WmXzwuAHiTb ia6L1qvLCph71EEc7P3YgRiwbdAygv6dD+q4NSoY744vx6nj0X7cgNwCocfm7is57jNV Vu5KCj49OtJGOZWR5/WhagN5ufcZ+yC6wFTOxp0/DnlW9y7VPGB9NvBdL6z0d62b1lB7 Z+mgUD2IYjM6W6acMuR51So4538e3xWJ7e5W0BBvEpNMtQg+En3T42wiJFgOKC9Yen3S P16BYfpLtXGaTEyzJcj9A17gpIBMrH4DMNShV+lqOWIv5ookfWhXMex3MEQ7HCyuUmiL Q3sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=dbvFXr++MU/HIreOWScTU6cmRztuJ1BeSWU0vX/lVDQ=; b=Xdr1TT8Ct6ahw+qF7qpYTDcWvRnQpaGdeoU9Y24YqJjXuCIf1MzW9oFsvuIEpljXvy V8G3aOF9JTpTxGXoYSnZIHAoCpAO2uzzWODnbC85kAip4Oveobvmwmun1szz8L2QiQe9 Jf06qaOHP3oTpJEHlsm5kzii2L2363zW87p+VJFzdfa4o1ekv86sg/pxTvtPSLr3fRRy LZ5iNMGfm7Yv0KjVIHVF8fmw8hHDJC8EHhGNXRUdW/xu2G9M9gP35uUQfopM9O0mAl65 OVD5o05itf09y8osRCxOnpBaTCA1z4LRod9fftlAVHvqyZalFXQs/2IIAAAHMbw31UTf 0Ytg== X-Gm-Message-State: ANhLgQ0lO2bBik+T4sC3937+3zeCLfJ6Jd41fZvDED6u/j//ozrfWySi GCvAK9zwmaHAurBGWPeoMLM= X-Google-Smtp-Source: ADFU+vsn9i0us/0rHexiF9zR35isGlBBbO5WaP4lsV3v8HW+nsk58CiPOoYGHF22BzU3fKDChWVczw== X-Received: by 2002:adf:df04:: with SMTP id y4mr1595978wrl.318.1584490639120; Tue, 17 Mar 2020 17:17:19 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:18 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 09/12] spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_message Date: Wed, 18 Mar 2020 02:16:00 +0200 Message-Id: <20200318001603.9650-10-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean The operating mode (DMA, XSPI, EOQ) is not going to change across the lifetime of the device. So it makes no sense to keep writing to SPI_RSER on each message. Move this configuration to dspi_init instead. Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: Patch is new. drivers/spi/spi-fsl-dspi.c | 55 ++++++++++++++++++++------------------ 1 file changed, 29 insertions(+), 26 deletions(-) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index fcc6f20b6631..5873752a091e 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -900,7 +900,6 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, { struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr); struct spi_device *spi = message->spi; - enum dspi_trans_mode trans_mode; struct spi_transfer *transfer; int status = 0; @@ -942,30 +941,11 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer, dspi->progress, !dspi->irq); - trans_mode = dspi->devtype_data->trans_mode; - switch (trans_mode) { - case DSPI_EOQ_MODE: - regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE); - dspi_fifo_write(dspi); - break; - case DSPI_XSPI_MODE: - regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_CMDTCFE); - dspi_fifo_write(dspi); - break; - case DSPI_DMA_MODE: - regmap_write(dspi->regmap, SPI_RSER, - SPI_RSER_TFFFE | SPI_RSER_TFFFD | - SPI_RSER_RFDFE | SPI_RSER_RFDFD); + if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) { status = dspi_dma_xfer(dspi); - break; - default: - dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n", - trans_mode); - status = -EINVAL; - goto out; - } + } else { + dspi_fifo_write(dspi); - if (trans_mode != DSPI_DMA_MODE) { if (dspi->irq) { wait_for_completion(&dspi->xfer_done); reinit_completion(&dspi->xfer_done); @@ -975,11 +955,12 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr, } while (status == -EINPROGRESS); } } + if (status) + break; spi_transfer_delay_exec(transfer); } -out: message->status = status; spi_finalize_current_message(ctlr); @@ -1170,7 +1151,7 @@ static const struct regmap_config dspi_xspi_regmap_config[] = { }, }; -static void dspi_init(struct fsl_dspi *dspi) +static int dspi_init(struct fsl_dspi *dspi) { unsigned int mcr; @@ -1184,6 +1165,26 @@ static void dspi_init(struct fsl_dspi *dspi) regmap_write(dspi->regmap, SPI_MCR, mcr); regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR); + + switch (dspi->devtype_data->trans_mode) { + case DSPI_EOQ_MODE: + regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE); + break; + case DSPI_XSPI_MODE: + regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_CMDTCFE); + break; + case DSPI_DMA_MODE: + regmap_write(dspi->regmap, SPI_RSER, + SPI_RSER_TFFFE | SPI_RSER_TFFFD | + SPI_RSER_RFDFE | SPI_RSER_RFDFD); + break; + default: + dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n", + dspi->devtype_data->trans_mode); + return -EINVAL; + } + + return 0; } static int dspi_slave_abort(struct spi_master *master) @@ -1339,7 +1340,9 @@ static int dspi_probe(struct platform_device *pdev) if (ret) goto out_ctlr_put; - dspi_init(dspi); + ret = dspi_init(dspi); + if (ret) + goto out_clk_put; dspi->irq = platform_get_irq(pdev, 0); if (dspi->irq <= 0) { From patchwork Wed Mar 18 00:16:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444257 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AD33F159A for ; Wed, 18 Mar 2020 00:17:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8CCFC20752 for ; Wed, 18 Mar 2020 00:17:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rvaJFHhG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727357AbgCRARY (ORCPT ); Tue, 17 Mar 2020 20:17:24 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:43521 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727339AbgCRARW (ORCPT ); Tue, 17 Mar 2020 20:17:22 -0400 Received: by mail-wr1-f65.google.com with SMTP id b2so21867548wrj.10; Tue, 17 Mar 2020 17:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=e8zpgtiG0w2opJ4PQ2uuwoYe8iOMFJzU+1DygKuJLws=; b=rvaJFHhGMAYFRsIhjMw3stPetGwHRLpuYoUup/pPcFMokhLv76eYrYuwsxXW82AThE Le7LTysiWqmJV5kGluDvnnSKUBhd3sUtY+sPsJKA/paMBl6Z/JhCqmG9gxcr5xVBe+QD OuqkjG9wCwe1YP9C0mpklSkUqMCmrIfDI33QF4wpadkrSveq/vZ8e8bSIFdIXQt7/dGZ ne5GEPP+l5lDukbrA6KAf++aoZFflGFAiyFa+j4wBHjaTcYxBUf8x+UbEJuHxET2UPSS awFjJXp1+075Xfx+l9T782jG0ZqrvDwIY1q65EnYEHYLau6P2gKXS00H/sWCTF3Vk9YE q9Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=e8zpgtiG0w2opJ4PQ2uuwoYe8iOMFJzU+1DygKuJLws=; b=P99Kb+MwHzB5xbH3ZA8rFUWkV+mWORLSmemHJtpMHZOFRHzhO6HL/T1lybbsHp1fdB WPjhdt7Re0bIAhQyaYpsL8BFATx9DiWul5WbwWxJZAmZM20lgVRwuRNyx2CfcyblTijo OMA5HCgQzw30y1Ytzd6w5a7Us4aFgTe657QeBzeIEGaHiCsXpTPF1/fVTAtLSn6oQUM7 dV3GTkcTYIw6DAKsKQOSfCLYgJ6z2wJ0Fm+4gL8BCbNSGlTBBYrZx4w1o6A+9DRHzjbU 0f3jSO9HyCFli7HE/3RTaP2Q8P/FDwiwbAQNuiZWgBrayTbtRZsOSgRl7CaPDeP1759v XMFA== X-Gm-Message-State: ANhLgQ1JrOEum8KPoCEGhZ2W4ADXKlGQEonReVpteRSZFiLd1L4Oc+XJ 8cIII/w68No1BhmTEmVxDAQ= X-Google-Smtp-Source: ADFU+vsM/azJbIuB3F79HdGdu7i/oU05oFfDvB6gssRHXn6C51cOxUsILqywLikbctYCfzlYFZjxhQ== X-Received: by 2002:adf:dfc6:: with SMTP id q6mr1508818wrn.375.1584490640603; Tue, 17 Mar 2020 17:17:20 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:19 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 10/12] spi: spi-fsl-dspi: Add support for LS1028A Date: Wed, 18 Mar 2020 02:16:01 +0200 Message-Id: <20200318001603.9650-11-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean This is similar to the DSPI instantiation on LS1028A, except that: - The A-011218 erratum has been fixed, so DMA works - The endianness is different, which has implications on XSPI mode Some benchmarking with the following command: spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI mode, the same command goes up to 4700 kbps. This is somewhat to be expected, since the DMA buffer size is extremely small at 8 bytes, the winner becomes whomever can prepare the buffers for transmission quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has been chosen as the operating mode for this chip. Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: None. Changes in v3: Removed the dma_bufsize variable (obsoleted by 03/12). Changes in v2: Switch to DSPI_XSPI_MODE. drivers/spi/spi-fsl-dspi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 5873752a091e..50e41f66a2d7 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -124,6 +124,7 @@ struct fsl_dspi_devtype_data { enum { LS1021A, LS1012A, + LS1028A, LS1043A, LS1046A, LS2080A, @@ -151,6 +152,11 @@ static const struct fsl_dspi_devtype_data devtype_data[] = { .max_clock_factor = 8, .fifo_size = 16, }, + [LS1028A] = { + .trans_mode = DSPI_XSPI_MODE, + .max_clock_factor = 8, + .fifo_size = 4, + }, [LS1043A] = { /* Has A-011218 DMA erratum */ .trans_mode = DSPI_XSPI_MODE, @@ -1050,6 +1056,9 @@ static const struct of_device_id fsl_dspi_dt_ids[] = { }, { .compatible = "fsl,ls1012a-dspi", .data = &devtype_data[LS1012A], + }, { + .compatible = "fsl,ls1028a-dspi", + .data = &devtype_data[LS1028A], }, { .compatible = "fsl,ls1043a-dspi", .data = &devtype_data[LS1043A], From patchwork Wed Mar 18 00:16:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444259 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0697D90 for ; Wed, 18 Mar 2020 00:17:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D992420752 for ; Wed, 18 Mar 2020 00:17:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YAxGVZFK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727379AbgCRARn (ORCPT ); Tue, 17 Mar 2020 20:17:43 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:36919 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727351AbgCRARZ (ORCPT ); Tue, 17 Mar 2020 20:17:25 -0400 Received: by mail-wm1-f67.google.com with SMTP id a141so1340804wme.2; Tue, 17 Mar 2020 17:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=+CKolpVnm8hPQhvF+U00QiMPywL83J4L7WoEEVZs7Y4=; b=YAxGVZFKelCPAISTEeyY4J0MmWrW07hpzp9IU8uQKMN4Aa7OsMiziNbrQWK1ajVUi+ +5HaKrqbgiFl2JxHpv+Ocj7PKxV6+HSst48MNughMD/Cg+gi132mgfm2gf4bvgVN7y0F Dn3U0KqLKcxm71AmfHoXnisFON5LYrIWqCD51WegBUpIpVvbsY2gHipfy++OhQ80exiI NYgcq95rQwRysBu7tnSwE6+qF2uiBSS+C2RQfqBs/9cmV5jyKFqhamRqQdtCfFp8nhR8 TASfCtSfJPQ/pAUl9By8bxbifcPv0tlZa3SAVvUgwBl6rGdm3GxmrRqzTVAJTDwQZKRT NPCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=+CKolpVnm8hPQhvF+U00QiMPywL83J4L7WoEEVZs7Y4=; b=j51szrA/dyuH+zOUPQ4qAVn5umL8lxL/NYGzrTl+YQf4CdUIqnoMFO27r7Hyd0XDWB PQId7Tmi55IPdYf8qCC11PLqMvwxQWxTWpQnjKzF0lzb7rPZZJ8b5Ubs86O8Y5fKHX0W Xe+CHgqM0YxkayQ2zqnAN4yxG90qFNtLEhkSN2ugYOfzMR6lBHoL5iHJbf5Jjzf7bxrT g/DJc+liSDrSA6YuzjLB0Y6MSN/HHIHmV4aI0LeC09l+kqy9bc/Ik7b3YStBmEWJnVF2 OHotwqq0Hmj+OBFAYTHxHfPJJbwwiiLCjEPIpbSzbM3CT6meGNF1AT0FE0f59pC+w4Xc pH8Q== X-Gm-Message-State: ANhLgQ3vNPpPGacVp83kPr1ANmeRZ9F22fSeH4SP3dYJh78CkzHd8qUx 1SUMJalAHLUOYYVnYFMmwPk= X-Google-Smtp-Source: ADFU+vvywxHGNmBFE/MLWUrifPTd+P13bsgmQ+bsVntWw9X6dBtFt8DNpz0JU2lOTRvskN/Xq80jKA== X-Received: by 2002:a05:600c:2713:: with SMTP id 19mr1663760wmm.180.1584490641895; Tue, 17 Mar 2020 17:17:21 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:21 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 11/12] arm64: dts: ls1028a: Specify the DMA channels for the DSPI controllers Date: Wed, 18 Mar 2020 02:16:02 +0200 Message-Id: <20200318001603.9650-12-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean LS1028A has a functional connection to the eDMA module. Even if the spi-fsl-dspi.c driver is not using DMA for LS1028A now, define the slots in the DMAMUX for connecting the eDMA channels to the 3 DSPI controllers. Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: None. Changes in v3: None. Changes in v2: None. arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi index 515e0a1b934f..18155273a46e 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi @@ -298,6 +298,8 @@ interrupts = ; clock-names = "dspi"; clocks = <&clockgen 4 1>; + dmas = <&edma0 0 62>, <&edma0 0 60>; + dma-names = "tx", "rx"; spi-num-chipselects = <4>; little-endian; status = "disabled"; @@ -311,6 +313,8 @@ interrupts = ; clock-names = "dspi"; clocks = <&clockgen 4 1>; + dmas = <&edma0 0 58>, <&edma0 0 56>; + dma-names = "tx", "rx"; spi-num-chipselects = <4>; little-endian; status = "disabled"; @@ -324,6 +328,8 @@ interrupts = ; clock-names = "dspi"; clocks = <&clockgen 4 1>; + dmas = <&edma0 0 54>, <&edma0 0 2>; + dma-names = "tx", "rx"; spi-num-chipselects = <3>; little-endian; status = "disabled"; From patchwork Wed Mar 18 00:16:03 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 11444255 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BBC67159A for ; Wed, 18 Mar 2020 00:17:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9ADAA20752 for ; Wed, 18 Mar 2020 00:17:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YYUwe03P" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727368AbgCRARZ (ORCPT ); Tue, 17 Mar 2020 20:17:25 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:32894 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727354AbgCRARZ (ORCPT ); Tue, 17 Mar 2020 20:17:25 -0400 Received: by mail-wm1-f67.google.com with SMTP id r7so1068369wmg.0; Tue, 17 Mar 2020 17:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=KAXWu0UANDOVatXihProEuzz/73Lcoq083Tlz6zFj1c=; b=YYUwe03PUuNG50h89cb3aEGYaLRC8phyef/6VGQ9Nh1CTR05B+SJ3fswY+FiI5ccia fQYToImXXpkKNToZD30gpK8F357fG9i9sF91tYjq6qeIPK8iXNbfgvfRJTSXqT29HbGo oZu+VVnsOcwnK7nFxmGOhKXLTZkYXyc0wYZUKVxOBpRe72djfsvbs+5KfHWekD8EzK5K b4I0Lpo3oeg9QG1LxsVRKEGLbMrIZIVaZbfL/rSKB1YkOfbpRU6Bl2tyzdQzffa3UtFQ JA3zLOcGpR7T8/SUvned7VSNFtmV8sUmEkMwmu/ClI+Bd3tSPHWpI2qrrrEms5qMx7XG 2log== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=KAXWu0UANDOVatXihProEuzz/73Lcoq083Tlz6zFj1c=; b=CkYyBWiE4855o+r6yWSBQ4/WY2hzzrZYFN8aul1W2P8CtP5qoGFknbv4mhNP3KEUNO rTwMop/7wZPiO6wENPRlKWB6XCnUV3y8Lx3kfGhvSP61chrRkPPk72XaHBEmEYoLn4ny TbsAk/pTK0K+JkYgEy18r1EzprZcDJjm93vinIBg9OUgIE6UVvaOMwM3SPxlTrW1nlyx I8NDra4KIAU6YfriTAoJn1iA1H3HsodVMqC4OdeOJjJNJvh3vljx/47ZGuYeaQqf81lx ieeKY0AxXP9It3YnUx4lFw26M1Whkgda5qNJNO0XsfH++AkXSyhxoOCrLyxsfBw5QVRd 0IYg== X-Gm-Message-State: ANhLgQ2CE7eLf3yiawH231fn7ep+Sp+jIN4uCrib0XSQ1mZs98gtds98 oufDkhY0qWQWBNr/AJEUQsY= X-Google-Smtp-Source: ADFU+vsKo9J+cypNb8ARLgt7IQtM0UosmL8XHUoariuqjuXHG+bgJ7JdHUk/RH4KYx7B5E8osBOsjQ== X-Received: by 2002:a7b:cc06:: with SMTP id f6mr1543969wmh.65.1584490643264; Tue, 17 Mar 2020 17:17:23 -0700 (PDT) Received: from localhost.localdomain ([79.115.60.40]) by smtp.gmail.com with ESMTPSA id i6sm6584600wru.40.2020.03.17.17.17.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2020 17:17:22 -0700 (PDT) From: Vladimir Oltean To: broonie@kernel.org Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, shawnguo@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, eha@deif.com, angelo@sysam.it, andrew.smirnov@gmail.com, gustavo@embeddedor.com, weic@nvidia.com, mhosny@nvidia.com, michael@walle.cc, peng.ma@nxp.com Subject: [PATCH v5 12/12] arm64: dts: ls1028a-rdb: Add a spidev node for the mikroBUS Date: Wed, 18 Mar 2020 02:16:03 +0200 Message-Id: <20200318001603.9650-13-olteanv@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200318001603.9650-1-olteanv@gmail.com> References: <20200318001603.9650-1-olteanv@gmail.com> Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org From: Vladimir Oltean For debugging, it is useful to have access to the DSPI controller signals. On the reference design board, these are exported to either the mikroBUS1 or mikroBUS2 connector (according to the CPLD register BRDCFG3[SPI3]). Signed-off-by: Vladimir Oltean --- Changes in v5: None. Changes in v4: None. Changes in v3: None. Changes in v2: Change compatible string for spidev node. arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts index 6d05b76c2c7a..0d27b5667b8c 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts @@ -83,6 +83,20 @@ }; }; +&dspi2 { + bus-num = <2>; + status = "okay"; + + /* mikroBUS1 */ + spidev@0 { + compatible = "rohm,dh2228fv"; + spi-max-frequency = <20000000>; + fsl,spi-cs-sck-delay = <100>; + fsl,spi-sck-cs-delay = <100>; + reg = <0>; + }; +}; + &esdhc { sd-uhs-sdr104; sd-uhs-sdr50;