Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3188367pxu; Mon, 19 Oct 2020 06:20:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHnbHLbOeTgvNfWKMiiZOVD3/vzSjNGRW/nH66XKlJ7JDVB45WDlIRHxB6GJUgxWeVtnqD X-Received: by 2002:a17:906:4e06:: with SMTP id z6mr17662152eju.370.1603113612372; Mon, 19 Oct 2020 06:20:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603113612; cv=none; d=google.com; s=arc-20160816; b=rHdOjCC6xPmPPG6Umf4Qjbc8y/DBxAOpmh5Z9nUA6NbcchA3fqI9oSEid70XQXq/XU 9A4/32ZW3vE/azD6YvFaPCCTqucw6r2bcTH5juhkDhvXgn/j14L+rtTDDJSG5Jkq9VZ9 H4PIRJHBvpFfRAp49qofEP3l8/eCQHluaxZm9asclPyhbn6QImTXBNqos+u3ZHtUEXbA OpIqXrZ0nhtE6mkGLNp7qIWWX2gvSH8KQAP4b69ZJakHsISHgo1asQz6uE4++1SCbP8b 0Kk1CLbnxULZ3HiZZvZif4csvA3LFJJGWQTSeyD8SPbMHLl2SmvHnGfhasAP8talihCt xElg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=eyVe3eY1HRRluzHENTQ4QB46IRWz5HaCquFh7riHmyM=; b=Be/IvOhj02n+Vltes6CM5Eu4srpKlQQWSRhq5zbg2zJu0pqZncANLyReDK/eKo3sQB OZDosGTu6S7JDXMaK312l/GI68q8dBWaJvJz8Q9ZnxMOM47ETXpkWSn8JGkEaa9S/D9i X2OyURQsq+hJYfc5BVMPsq+aFis63wYMAaiTsLvHAxa9KseWrnqllFji5bbnBOXt3eea 3xchrnxc8GNRpBR4z9bDPjAJrihRerZKyFZ/Cb8Gt4PtjNUAU6jg3/SfItznWuVYs/NR rmtuosxgH2xMe0Be76Xqu2GuTx3OlZhJf+2nxNYnAsopY267mFauVurHR2x/CVQMPO/B 1f9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=O6bgASTC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ch19si7884665ejb.738.2020.10.19.06.19.49; Mon, 19 Oct 2020 06:20:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=O6bgASTC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727843AbgJSNRW (ORCPT + 99 others); Mon, 19 Oct 2020 09:17:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727297AbgJSNRW (ORCPT ); Mon, 19 Oct 2020 09:17:22 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C0DBC0613CE; Mon, 19 Oct 2020 06:17:21 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id i2so11865106ljg.4; Mon, 19 Oct 2020 06:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eyVe3eY1HRRluzHENTQ4QB46IRWz5HaCquFh7riHmyM=; b=O6bgASTCO+5SVFYSGm98qhohELtfQC8k4FK59gjtMuevGiqZhwUSoyWA9iZTltdME7 J/xrLdIHAwuLqqYJgNKq9K6wuXRfhQjXwcQaR6gb2ksKnKHgiqWNlv8wqbdmg6Wf0leu 5sk5qxGTsvZuKU2WvERGqAOdu+M5BzhH2KUCT7N5AMdEIdrHP+aSGF7h3nrl3KwluS1L nJcXh8IvnP19GhBDg0rhn5akfqDdT3Hk8hHIyQ3J5geGckLhoMHwudcqoHHF9sVnTUXr THtFK/n/wXjHRBQ/lrytvh8IBkGYVYx1XXrId57VotGot6S7eNOw9VP60UF7XY09zdcX I9Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eyVe3eY1HRRluzHENTQ4QB46IRWz5HaCquFh7riHmyM=; b=P2ou53+0Rzh3jim1zJpjQo2uwAl6JD4oHd6VJS3O94YsA1OxKsAFIeL2UUAASjo8Fp kyVwaYiMSv1PlmRHaFwUQvUoat5ruPaDNHa0VoKhx3bPNhOH1yyVKqR83Hp/UbGSvnxP TQauPqq9srDcS57VelomIfwPWtqnSdKrKY1OBsRG7eOsEJw91/DUcuTLS/ySk+cQwdR/ XAKOurSHeJVuMTC++9HI5yC29H4nSR8T99e+w1h3hXlP77DJn/t4nHcuLAo+1+86Vslb gp/8VG6WrYe4WIGmZ4ut4CSLOpbrK8a8v97E8ZRtTwz7dx3e1mCpKhzXQy1hIv3mb1J4 f9Zw== X-Gm-Message-State: AOAM5322ibpclsl4K3kiuPtFizvbBr8yNLEzRHz22q3zs8WE+CLOdhy9 h9NoN4D87HN/DxoUVsSJgxA= X-Received: by 2002:a2e:9a4c:: with SMTP id k12mr6124327ljj.388.1603113439731; Mon, 19 Oct 2020 06:17:19 -0700 (PDT) Received: from [192.168.8.144] ([80.87.144.137]) by smtp.gmail.com with ESMTPSA id x8sm3258070lff.222.2020.10.19.06.17.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 06:17:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [PATCH] spi: spi-sun6i: implement DMA-based transfer mode From: Alexander Kochetkov In-Reply-To: <20201019082129.myxpxla5xwoqwldo@gilmour.lan> Date: Mon, 19 Oct 2020 16:17:18 +0300 Cc: Mark Brown , Chen-Yu Tsai , linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <4B0B0459-DFCF-4307-8CAE-A2B579B0AF5E@gmail.com> References: <20201015154740.20825-1-al.kochet@gmail.com> <20201019082129.myxpxla5xwoqwldo@gilmour.lan> To: Maxime Ripard X-Mailer: Apple Mail (2.3608.120.23.2.4) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Maxime! Thanks for reviewing patches! >>=20 >> +static int sun6i_spi_prepare_dma(struct sun6i_spi *sspi, >> + struct spi_transfer *tfr) >> +{ >> + struct dma_async_tx_descriptor *rxdesc, *txdesc; >> + struct spi_master *master =3D sspi->master; >> + >> + rxdesc =3D NULL; >> + if (tfr->rx_buf) { >> + struct dma_slave_config rxconf =3D { >> + .direction =3D DMA_DEV_TO_MEM, >> + .src_addr =3D sspi->dma_addr_rx, >> + .src_addr_width =3D 1, >> + .src_maxburst =3D 1, >> + }; >=20 > That doesn't really look optimal, the controller seems to be able to > read / write 32 bits at a time from its FIFO and we probably can > increase the burst length too? I had doubts if it would work. I didn=E2=80=99t know will DMA work for = transfers with lengths not aligned to 32 bits. For example, if we init DMA with src_addr_width =3D = 1 and .src_maxburst =3D 8 will DMA work for transfer with length 11? I expect = that DMA fill FIFO with 16 bytes and SPI transfer only 11 bytes and 5 bytes will leave in = TX fifo. I did the test and there is no additional data left in the fifo buffer. Also at = reception the is no memory overwrites. I made test with src_addr_width =3D 4, src_maxburst =3D 1 and transfer = length 3. Looks like in that case DMA doesn=E2=80=99t issue 4 bytes transfer. For test with src_addr_width =3D 4, src_maxburst =3D 8 I had to adjust = RF_RDY_TRIG_LEVEL_BITS and TF_ERQ_TRIG_LEVEL_BITS of FIFO_CTL_REG to half of FIFO (32 bytes). = With the config DMA will transfer burst of half of FIFO length during transfer and = remaining bytes at the end of transfer. >>=20 >> @@ -343,7 +436,8 @@ static irqreturn_t sun6i_spi_handler(int irq, = void *dev_id) >> /* Transfer complete */ >> if (status & SUN6I_INT_CTL_TC) { >> sun6i_spi_write(sspi, SUN6I_INT_STA_REG, = SUN6I_INT_CTL_TC); >> - sun6i_spi_drain_fifo(sspi); >> + if (!sspi->use_dma) >> + sun6i_spi_drain_fifo(sspi); >=20 > Is it causing any issue? The FIFO will be drained only if there's > something remaining in the FIFO, which shouldn't happen with DMA? >=20 No. It=E2=80=99s for make code patch explicit. Remove the change? Alexander.