Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2087885ybk; Mon, 11 May 2020 11:36:47 -0700 (PDT) X-Google-Smtp-Source: APiQypJwDiZXOlHgNoK8UcMzrgBolUZ4ye6Z4h6A/mL3AOKiI7tgmo5ni/zV0BRbkhp8/7TuViIK X-Received: by 2002:aa7:d78a:: with SMTP id s10mr15207604edq.319.1589222207448; Mon, 11 May 2020 11:36:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589222207; cv=none; d=google.com; s=arc-20160816; b=lvv+7vV59wM+qwfS5Lv81UHMmym/wYiy21OFi+EWWI8ni7wH3+SyG46szKVciPYY5g DtZwcixYnhaoWRIGIUNf7joO/8Av0zXhocsZnJAWwJY7fFxlExkieremfURvI/5RWb8T A1PAuHAXCfftNTp6fY2rhtC34jG7K0DshsjcJXHuhVEEUqyNYzNDt9f/hAPTei0rOHQC PDs9aiMTFFa3igwibFxkQiEu/MerEwXMzvo47JnD08liTvTQM8DqEgvH+lhnACsjmmTE iO6kMhXGRpy9735gHmXf8ty939XlEMMsAiTxIk+IFCasEntZI9tej/De/Yi9PxjqyHyV j3xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=kIPfVkbD1xtTN6ktQjq/Bdjm6v1avauFOG64feFXd54=; b=budnDRcXO4RJIYNsJEa3lvNMyDPpEchExwUwK3iIPSVvcVWLda6hBVS4igVwGyTRpI 7DeYscVzcJEEsAl7xDRR6qHcSOAqJXdK5Vxm4MCk4Qz6uE932dUpaSowojb43e/W8Ru7 h6jNq2iMCYIlVozDMpzp9l556xGFwhktZAsWQbV2td2VmQR6rxJvtEwSK5bGOa2SwDIz BmB5JWuw9CtusoY58zPFjkvqFiLtkBXISFL3U7tzI0k1bDE+kKqMmyvZrcqXEreGdfs3 gQDkg+GfDlGH2pwaqZOFqI9XgaaO+7lYE9ywSzN+lA0fUx5tbrxitVjzWugfAmG3i211 XOng== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qk11si2993316ejb.436.2020.05.11.11.36.23; Mon, 11 May 2020 11:36:47 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731073AbgEKScv (ORCPT + 99 others); Mon, 11 May 2020 14:32:51 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:49770 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729727AbgEKScv (ORCPT ); Mon, 11 May 2020 14:32:51 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id 3A2FD803088B; Mon, 11 May 2020 18:32: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 P1N1qOkT7GET; Mon, 11 May 2020 21:32:47 +0300 (MSK) Date: Mon, 11 May 2020 21:32:47 +0300 From: Serge Semin To: Mark Brown CC: Serge Semin , Andy Shevchenko , Vinod Koul , Viresh Kumar , Dan Williams , Alexey Malahov , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , , , , Subject: Re: [PATCH v2 4/6] dmaengine: dw: Print warning if multi-block is unsupported Message-ID: <20200511183247.y6cfss22pe67nouf@mobilestation> References: <20200306131048.ADBE18030797@mail.baikalelectronics.ru> <20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru> <20200508105304.14065-5-Sergey.Semin@baikalelectronics.ru> <20200508112604.GJ185537@smile.fi.intel.com> <20200508115334.GE4820@sirena.org.uk> <20200511021016.wptcgnc3iq3kadgz@mobilestation> <20200511115813.GG8216@sirena.org.uk> <20200511134502.hjbu5evkiuh75chr@mobilestation> <20200511174414.GL8216@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200511174414.GL8216@sirena.org.uk> X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 06:44:14PM +0100, Mark Brown wrote: > On Mon, May 11, 2020 at 04:45:02PM +0300, Serge Semin wrote: > > On Mon, May 11, 2020 at 12:58:13PM +0100, Mark Brown wrote: > > > > That sounds like you need to also impose a limit on the maximum message > > > size as well then, with that you should be able to handle messages up > > > to whatever that limit is. There's code for that bit already, so long > > > as the limit is not too low it should be fine for most devices and > > > client drivers can see the limit so they can be updated to work with it > > > if needed. > > > Hmm, this might work. The problem will be with imposing such limitation through > > the DW APB SSI driver. In order to do this I need to know: > > > 1) Whether multi-block LLP is supported by the DW DMA controller. > > 2) Maximum DW DMA transfer block size. > > There is a constraint enumeration interface in the DMA API which you > should be able to extend for this if it doesn't already support what you > need. Yes, that's max segment size. > > > Then I'll be able to use this information in the can_dma() callback to enable > > the DMA xfers only for the safe transfers. Did you mean something like this when > > you said "There's code for that bit already" ? If you meant the max_dma_len > > parameter, then setting it won't work, because it just limits the SG items size > > not the total length of a single transfer. > > You can set max_transfer_size and/or max_message_size in the SPI driver > - you should be able to do this on probe. Thanks for the explanation. Max segment size being set to the DMA controller generic device should work well. There is no need in setting the transfer and messages size limitations. Besides I don't really see the max_transfer_size/max_message_size callbacks utilized in the SPI core. These functions are called in the spi-mem.c driver only. Do I miss something? -Sergey