Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2128754ybk; Mon, 11 May 2020 12:37:21 -0700 (PDT) X-Google-Smtp-Source: APiQypLoeRYOyFgmSHWBdx7HE55ckK1IjTklMsT/SwNcSF5/IZFcgTgFK+2dkCSuaZ2LXF4OlpT3 X-Received: by 2002:a17:906:f74e:: with SMTP id jp14mr15406567ejb.15.1589225841711; Mon, 11 May 2020 12:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589225841; cv=none; d=google.com; s=arc-20160816; b=cPU6PqxaDnfh/8W8KIvYZMma0xJl+Ry0fwVDvn+41Jo++hQjH5/b4ktp5Rr1Jr3bY4 cvO9vicAx6JmqposiUFlv19G0mgh9ziS1t63ERdTrQPE0esTbM156G8Uqy5RJzbOFvNW VMg/ZqL/mTwMaN2HFumGGNQulx7kwNDzJEqsB7f+e4169psqsO0tFV1Kyp/B0HzLhNkc akOaaTxbNVxzD4eF+oJbbdw/gfxriyYG1bu3FAp7AbiM2onkRhcvb27zcjXne4RQtEto +YHJrh3/0O2m/L9wJivaQS43mJuLmGUfk9a7RuKG27uc2gUnVdEan2DudBTI5uAEJ9hx 9Vdw== 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=zojuCRig/J/cpgar+pHvty3dqxZaVAy1YadGDXaCHh0=; b=oH/zcsJ8pcIPUjOq/4jgTw+ZrHuFGdr0PvQLBNaIMKl/GfKzrQMXO6x9LeRDUxDCBS JhbquM7FoUASBBQ+raBWljrDanEJuvCTOJQxZKQ7FZBkaSAAQF95nMbeh9/wzEtAIoPr ZHHmowL+g9lVfdQil2vWSzyXzKhEDrs+7oN4YoPaSeYvXE5xSoS2g8hPDTPj3EO0SU0S QW1MytwQXzGIaRwZKpcazgBTBXvbD0LjF8UbH4CdxHGFojP5BMXQbweR+L9MmBT8uzU4 D6fY8fs+YhDAGLjjfnI7kL2AmooJiu0xI8+rcSqao4vJIuBJsVn8ASWMfNvA07uN0DDu Z+7A== 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 y43si4642795ede.404.2020.05.11.12.36.57; Mon, 11 May 2020 12:37:21 -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 S1731384AbgEKTdC (ORCPT + 99 others); Mon, 11 May 2020 15:33:02 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:49834 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729453AbgEKTdB (ORCPT ); Mon, 11 May 2020 15:33:01 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id 45FF1803080A; Mon, 11 May 2020 19:32:58 +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 Q65asuHJMWNf; Mon, 11 May 2020 22:32:57 +0300 (MSK) Date: Mon, 11 May 2020 22:32:55 +0300 From: Serge Semin To: Andy Shevchenko CC: Serge Semin , Mark Brown , Andy Shevchenko , Vinod Koul , Viresh Kumar , Dan Williams , Alexey Malahov , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Rob Herring , , devicetree , dmaengine , Linux Kernel Mailing List Subject: Re: [PATCH v2 4/6] dmaengine: dw: Print warning if multi-block is unsupported Message-ID: <20200511193255.t6orpcdz5ukmwmqo@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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: 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 04:58:53PM +0300, Andy Shevchenko wrote: > On Mon, May 11, 2020 at 4:48 PM Serge Semin > wrote: > > > > On Mon, May 11, 2020 at 12:58:13PM +0100, Mark Brown wrote: > > > On Mon, May 11, 2020 at 05:10:16AM +0300, Serge Semin wrote: > > > > > > > Alas linearizing the SPI messages won't help in this case because the DW DMA > > > > driver will split it into the max transaction chunks anyway. > > > > > > 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. > > 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. > > > > So the question is of how to export the multi-block LLP flag from DW DMAc > > driver. Andy? > > I'm not sure I understand why do you need this being exported. Just > always supply SG list out of single entry and define the length > according to the maximum segment size (it's done IIRC in SPI core). Finally I see your point. So you suggest to feed the DMA engine with SG list entries one-by-one instead of sending all of them at once in a single dmaengine_prep_slave_sg() -> dmaengine_submit() -> dma_async_issue_pending() session. Hm, this solution will work, but there is an issue. There is no guarantee, that Tx and Rx SG lists are symmetric, consisting of the same number of items with the same sizes. It depends on the Tx/Rx buffers physical address alignment and their offsets within the memory pages. Though this problem can be solved by making the Tx and Rx SG lists symmetric. I'll have to implement a clever DMA IO loop, which would extract the DMA addresses/lengths from the SG entries and perform the single-buffer DMA transactions with the DMA buffers of the same length. Regarding noLLP being exported. Obviously I intended to solve the problem in a generic way since the problem is common for noLLP DW APB SSI/DW DMAC combination. In order to do this we need to know whether the multi-block LLP feature is unsupported by the DW DMA controller. We either make such info somehow exported from the DW DMA driver, so the DMA clients (like Dw APB SSI controller driver) could be ready to work around the problem; or just implement a flag-based quirk in the DMA client driver, which would be enabled in the platform-specific basis depending on the platform device actually detected (for instance, a specific version of the DW APB SSI IP). AFAICS You'd prefer the later option. Regarding SPI core toggling CS. It is irrelevant to this problem, since DMA transactions are implemented within a single SPI transfer so the CS won't be touched by the SPI core while we are working wht the xfer descriptor. Though the problem with DW APB SSI native CS automatic toggling will persist anyway no matter whether the multi-block LLPs are supported on not. -Sergey > > -- > With Best Regards, > Andy Shevchenko