Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp414154imm; Fri, 28 Sep 2018 00:12:22 -0700 (PDT) X-Google-Smtp-Source: ACcGV602JQygMHb4oYY6nvvEoiLzaTRMDqVDoqebXeEeAfv9S1y6qoAoQL7weL0kHO9uqHxkEPwA X-Received: by 2002:a17:902:62:: with SMTP id 89-v6mr14955843pla.298.1538118742450; Fri, 28 Sep 2018 00:12:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538118742; cv=none; d=google.com; s=arc-20160816; b=YpX2DY4l8KLBPIk89CM28efGiKcOXQRG1vD7Y54/Gy4afdPXQrftlOLwSkqKNbqBsg 6LrpWiRBMnxrO4Dy98cQjXqvVnKoduHQrbO3f2nwc+Cva98QO68+JXBjlr2u8adVegl9 EuJS9Eny1ARUuRX6W2eJ588sdqN0mxfUcHFMWBnnqqqvWlQ42xzOUJS4COnhmkiP7bLP cp1AgUsmZH8vv0roHzB8zl0nS0u3u3jw8vTv5/3rdZtJkH32JuG1ryMlgWZOalUljvmw hizwVzcoWC+rClsaZ9d++bH2eTByAvd8nK2SS0ovpL2A2HgjlgQzd1cKmWdFmmqwbYUk YRHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=qQ8TbzZiFZ7lvQBm0XTQUB+HtYV4NxETXRNqnH6EQCg=; b=ozRaPWA3zl+Y68S2hIg/ETP3y1r4ZprULD6xs2QasjV20lBaZQ2wJA3riii8yhnOcs K34nEkc1dB14NNIRXQR7BQFUEjt7UYuaEPNiiTZUT4HDKR5T9fHtuss4mxRuuXSQRWRe ai92PXJWkGabCIqgTID3huV6KFjYXOs3CDqlYyCWShOffoQREdJxCh46C5E+xbf5l2IW Pv4oFiEV93hAVBQcIIBZ8Fjl2JmuurEhqiioQ08V9QlrbqWrjBjoxXABOkdAFNKMEj0z cyDVuYflFeGlQIOdanFY12ufYROM7bFfDVSSkwrfLWnUV2Rc+MkHl85psjNcCxHsbFso cKsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XCfKeKo7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id y10-v6si4325470pge.615.2018.09.28.00.11.51; Fri, 28 Sep 2018 00:12:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XCfKeKo7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728897AbeI1Nd4 (ORCPT + 99 others); Fri, 28 Sep 2018 09:33:56 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:52694 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726106AbeI1Ndz (ORCPT ); Fri, 28 Sep 2018 09:33:55 -0400 Received: by mail-wm1-f68.google.com with SMTP id 189-v6so796246wmw.2; Fri, 28 Sep 2018 00:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=qQ8TbzZiFZ7lvQBm0XTQUB+HtYV4NxETXRNqnH6EQCg=; b=XCfKeKo7KdL0vfZ5Yu0E1xOJqsP1dBchuyHQ0KSmnWRAwEt8mnNeCQCu5cuXusLgIe qBEOG2S3432fHm4Aek1OxXP4z1LjUsAFsTDwVWKPyq7GV7xtoupMhXubu+KOZ5rbyk29 QgPkmqohZnVzr03WYn6fnk5St3agScuB47rwwAtGE6162jtOESyHqWT1Hnx9oTyhWVRm WXpVVBhUF2VLXEYPFEfpw7f869JhyTd2maWSoq5c+j+ghQnLkueIMXQbUoISSZ1hAbQy Zg+EgCqABUz04byIGdi5frhzOn8p/ve3w3quOIMSX6fkkMUBEinf+dOI8dkAg++/UtpX ordw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=qQ8TbzZiFZ7lvQBm0XTQUB+HtYV4NxETXRNqnH6EQCg=; b=mu2tjWpaTAEVH3JcR7zDmIPVB7LK0XHLsShN/G4mhk5SQ4NjgOS1TQ0vjb1GHYnuRh IGNaijvyg6fwS+qVAugpn8e4l+lOScrk4aQSyqdfB1CbgaBE4WhmCIdbriPGYC/XVzGR aGPpaaa/J1oFwc9DfAOaQ1VMUjZyy9ROxFjqdcH1JQrn8fGFb2fDo02gl2lHP2K4JtvY Len7dcocWDkCmeFbFrTlFbl1QWQNmcZdkQLHpv47pUqAzt9Z7U6fwXI2/A0Fj/ZddCzI Bh9rlFV9Yi82YpE42VeHDUzymRZGMqHHlyKVAEda3AsuYjkHWrkRH9ked4o61eIEPO6M gQFQ== X-Gm-Message-State: ABuFfoh7/Iz1fSHOkZ3NGgT66EIT118ppC+TJO+bs6nfqnpke1yTVvk7 +TbzgHc39OpfET2Ri8gpCnY+gN9IbkPxBPaeUj0= X-Received: by 2002:a1c:1f50:: with SMTP id f77-v6mr757189wmf.52.1538118693062; Fri, 28 Sep 2018 00:11:33 -0700 (PDT) MIME-Version: 1.0 References: <20180907062502.8241-1-andrea.merello@gmail.com> <20180907062502.8241-2-andrea.merello@gmail.com> <20180918162105.GC2613@vkoul-mobl> In-Reply-To: <20180918162105.GC2613@vkoul-mobl> Reply-To: andrea.merello@gmail.com From: Andrea Merello Date: Fri, 28 Sep 2018 09:11:19 +0200 Message-ID: Subject: Re: [PATCH v5 2/7] dmaengine: xilinx_dma: in axidma slave_sg and dma_cyclic mode align split descriptors To: Vinod Cc: dan.j.williams@intel.com, michal.simek@xilinx.com, appana.durga.rao@xilinx.com, dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel , Rob Herring , Mark Rutland , devicetree , Radhey Shyam Pandey Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 18, 2018 at 6:21 PM Vinod wrote: > > On 07-09-18, 08:24, Andrea Merello wrote: > > Whenever a single or cyclic transaction is prepared, the driver > > could eventually split it over several SG descriptors in order > > to deal with the HW maximum transfer length. > > > > This could end up in DMA operations starting from a misaligned > > address. This seems fatal for the HW if DRE (Data Realignment Engine) > > is not enabled. > > > > This patch eventually adjusts the transfer size in order to make sure > > all operations start from an aligned address. > > > > Cc: Radhey Shyam Pandey > > Signed-off-by: Andrea Merello > > Reviewed-by: Radhey Shyam Pandey > > --- > > Changes in v2: > > - don't introduce copy_mask field, rather rely on already-esistent > > copy_align field. Suggested by Radhey Shyam Pandey > > - reword title > > Changes in v3: > > - fix bug introduced in v2: wrong copy size when DRE is enabled > > - use implementation suggested by Radhey Shyam Pandey > > Changes in v4: > > - rework on the top of 1/6 > > Changes in v5: > > - fix typo in commit title > > - add hint about "DRE" meaning in commit message > > --- > > drivers/dma/xilinx/xilinx_dma.c | 22 ++++++++++++++++++---- > > 1 file changed, 18 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c > > index a3aaa0e34cc7..aaa6de8a70e4 100644 > > --- a/drivers/dma/xilinx/xilinx_dma.c > > +++ b/drivers/dma/xilinx/xilinx_dma.c > > @@ -954,15 +954,28 @@ static int xilinx_dma_alloc_chan_resources(struct dma_chan *dchan) > > > > /** > > * xilinx_dma_calc_copysize - Calculate the amount of data to copy > > + * @chan: Driver specific DMA channel > > * @size: Total data that needs to be copied > > * @done: Amount of data that has been already copied > > * > > * Return: Amount of data that has to be copied > > */ > > -static int xilinx_dma_calc_copysize(int size, int done) > > +static int xilinx_dma_calc_copysize(struct xilinx_dma_chan *chan, > > + int size, int done) > > align to preceeding line opening brace please After applying, I'm seeing it already aligned as you requested; 4 tabs + 4 spaces so the 2nd line starts right under the "s" near the opened brace.. Patch sent using git, so it should pass through without being ruined; don't know why you see it misaligned :( > > { > > - return min_t(size_t, size - done, > > + size_t copy = min_t(size_t, size - done, > > XILINX_DMA_MAX_TRANS_LEN); > > so we can do this way in patch 1: > > size t copy; > > copy = min_t(size_t, size - done, > XILINX_DMA_MAX_TRANS_LEN); > > return copy; > > and then add these here, feels like we are redoing change introduced in > patch 1.. OK, this sounds good :) > > > + if ((copy + done < size) && > > + chan->xdev->common.copy_align) { > > + /* > > + * If this is not the last descriptor, make sure > > + * the next one will be properly aligned > > + */ > > + copy = rounddown(copy, > > + (1 << chan->xdev->common.copy_align)); > > + } > > + return copy; > > } > > > > /** > > @@ -1804,7 +1817,7 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_slave_sg( > > * Calculate the maximum number of bytes to transfer, > > * making sure it is less than the hw limit > > */ > > - copy = xilinx_dma_calc_copysize(sg_dma_len(sg), > > + copy = xilinx_dma_calc_copysize(chan, sg_dma_len(sg), > > why not keep chan in patch 1 and add only handling in patch 2, seems > less churn to me.. Indeed this was something I was unsure about.. I ended up in feeling better not to add introduce a function that takes an unused (yet) argument, but I can change this of course :) > -- > ~Vinod