From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62157C433E0 for ; Mon, 18 May 2020 12:53:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47200206D4 for ; Mon, 18 May 2020 12:53:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726739AbgERMxB (ORCPT ); Mon, 18 May 2020 08:53:01 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:47326 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726709AbgERMxA (ORCPT ); Mon, 18 May 2020 08:53:00 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id B7B468030875; Mon, 18 May 2020 12:52:55 +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 txmeJSYd8bdj; Mon, 18 May 2020 15:52:55 +0300 (MSK) Date: Mon, 18 May 2020 15:52:53 +0300 From: Serge Semin To: Andy Shevchenko CC: Serge Semin , Mark Brown , Alexey Malahov , Thomas Bogendoerfer , Paul Burton , Ralf Baechle , Arnd Bergmann , Allison Randal , Gareth Williams , Rob Herring , , , Georgy Vlasov , Ramil Zaripov , Jarkko Nikula , Thomas Gleixner , Wan Ahmad Zainie , Linus Walleij , Clement Leger , , Subject: Re: [PATCH v2 10/19] spi: dw: Use DMA max burst to set the request thresholds Message-ID: <20200518125253.r4fpr4mjflclqpym@mobilestation> References: <20200508132943.9826-1-Sergey.Semin@baikalelectronics.ru> <20200515104758.6934-1-Sergey.Semin@baikalelectronics.ru> <20200515104758.6934-11-Sergey.Semin@baikalelectronics.ru> <20200515143842.GG1634618@smile.fi.intel.com> <20200516200133.wmaqnfjbr7234fzo@mobilestation> <20200518110343.GY1634618@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200518110343.GY1634618@smile.fi.intel.com> X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org On Mon, May 18, 2020 at 02:03:43PM +0300, Andy Shevchenko wrote: > On Sat, May 16, 2020 at 11:01:33PM +0300, Serge Semin wrote: > > On Fri, May 15, 2020 at 05:38:42PM +0300, Andy Shevchenko wrote: > > > On Fri, May 15, 2020 at 01:47:49PM +0300, Serge Semin wrote: > > > > Each channel of DMA controller may have a limited length of burst > > > > transaction (number of IO operations performed at ones in a single > > > > DMA client request). This parameter can be used to setup the most > > > > optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer > > > > overrun we can set the DMA Tx level to be of FIFO depth minus the > > > > maximum burst transactions length. To prevent the Rx buffer underflow > > > > the DMA Rx level should be set to the maximum burst transactions length. > > > > This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels > > > > in accordance with these rules. > > ... > > > > > /* DMA info */ > > > > struct dma_chan *txchan; > > > > + u32 txburst; > > > > struct dma_chan *rxchan; > > > > + u32 rxburst; > > > > > > Leave u32 together, it may be optimal on 64-bit architectures where ABIs require padding. > > > > It's not like anyone cared about padding in this structure in the first place) > > I think I have been caring (to some extend). Well, If you have then instead of asking to rearrange just two members (which by the way finely grouped by the Tx-Rx affiliation) why not sending a patch, which would refactor the whole structure so to be optimal for the x64 platforms? I don't really see why this gets very important for you seeing Mark is Ok with this. My current commit follows the common driver design including the DW SSI data members grouping. On the second thought I'll leave it as is then. -Sergey > > > Though if v3 is required I'll group these members together. > > From what I see v3 is what Mark and me are waiting for. Mark, are we on the > same page here? > > -- > With Best Regards, > Andy Shevchenko > >