Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp762622imm; Wed, 20 Jun 2018 06:16:58 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJMAwVHsqs42AhSXdThjIsKV75YZrYLTYzU9gyiW14kwwQwUzPN+B0d9/sTo7jctvsK3dE7 X-Received: by 2002:a65:49cb:: with SMTP id t11-v6mr18587991pgs.218.1529500618276; Wed, 20 Jun 2018 06:16:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529500618; cv=none; d=google.com; s=arc-20160816; b=ST8Nj6KFo1/myZzTaSlLwUfArqgZo51fYNf++FVHcF8ysM0zbnKdamOXIbDCrNBekD EViJJO2pEfiVfEEu2CQPetfPCWYXE1FOyxYfpG6D2/soV0c07r+z4w+LWOU1Whf1i6dB QPwaA1hdqEe3pQQfcj/kJuOPsIFMQ8rc4i129rBAbKQt9bmPWTqRrMu6vShOsepPZwW2 ydjDAl0xIrQDrX4uUKcrMvitLNUd+JtKBks/qB1ZqvottpTDMjLznyTc5pWJ6QpI+M87 GBdYqc2LuMU+zmLYA7L83IzOZkbb4qdEBMw0G2b0iK61n01okAw4FlYN/FVgwZe3ZgfW 2xgg== 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 :references:in-reply-to:reply-to:mime-version:dkim-signature :arc-authentication-results; bh=tB73JhffxrpYdtji+q3qnZzVuto+tI3jWk47X3c1nvA=; b=ihOvfqHfRHL4ct6jwb7AOwn8NRXH/HyQzAvXsGxuToTTG72B5FHXhcxhKqsGh0p1Zt X3vtJXvKCci5u7BNAQJ7/tchFxUgpuowQH3mw1G5oxqn1j9g/8O14dW1YmcRV2zA2ZUX tHG4s+7u8cZdwuDAyBqyk9UgmkDayNKZsj953Mz7Gb14GmFbV5n39aCtVn5LYnrP72P8 LSx2aAoGL9TjaEEluEF4K5v5iUNj5+I9KZVbGuHKitQuPHMMft6qWwJSaen0W1mCTBCt yrOecHDVYBmQ/6ZZCSfcd3hJbEv0U9trMogsE91BvM976wZRC53IF3EfUhPFznopI90S lBnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="S/0juxyi"; 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 y34-v6si2401716plb.317.2018.06.20.06.16.34; Wed, 20 Jun 2018 06:16:58 -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="S/0juxyi"; 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 S1754084AbeFTNPg (ORCPT + 99 others); Wed, 20 Jun 2018 09:15:36 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:35554 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753952AbeFTNPd (ORCPT ); Wed, 20 Jun 2018 09:15:33 -0400 Received: by mail-wr0-f196.google.com with SMTP id l8-v6so1711003wrr.2; Wed, 20 Jun 2018 06:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tB73JhffxrpYdtji+q3qnZzVuto+tI3jWk47X3c1nvA=; b=S/0juxyilLFA4aaUga/27I71xkSW3d1tw24uJNM9BA+a8ybsDwBUtSi0Ik49QRblqy mNgu+1TxjELlWRgFE4mXls4v9rcRfrl7yaFzAQNN7u8srFWC3F+Jdngswv6oyWS8RkC1 ONUT/+DiVofLpsmI6AvednVMxLQUSO3DVdovTmEUHAN0NPE54ZxWxS879/NkMLz18KtU BEt3Jv12H+xoMAS/O9SWcmtKkkRDH2wlv7Q8NKtV/iF88/NdN8Tpq1C+l5RqmsoXxdef U5i4NUhoKsOwCIz3TycAmMAPMtND/bP04NNCegpxctzYC6GZoJLD+H36lZEi3ajSlUZM ACrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=tB73JhffxrpYdtji+q3qnZzVuto+tI3jWk47X3c1nvA=; b=iIjjpooqXCPSK0MHhE5wtwxS1/iZ03CYaFXkz4JKFRrAf3FcUfQWTYQShqtyzbW5Ej qah6q/bCNinW/9NWGau3FH430O0mzgxMBro4XwkhIFdnEiWvsKpqYy0XcRjAuXOSfEkI 3bX1Bg1V579eP9HoA6YoSjbyfX2Szk5Sg1P6fl5InQwsbJid8W1iy7d7s3aWlHW67Do2 L9L6nhOQDVdk+VfgS0Zldds4Aij5h/tLiQhsWFUITXagUqWxHvEvjOfKSv5BEqAYggVs 1Mcs59+7y94E2g1XgXuj63xWECxmRuYQWoWaapVi5hSRxBs+OmZFhKy0UZHcJVtrJmNh geoA== X-Gm-Message-State: APt69E3sQNAF9VqKtYk8Rz9GQ2lFqq/4/M4xBoayYVA8QtU6IFVMenO4 9YmFLIOePp2fjSdtvZh3daHoS8uLrKhJWJMH6sM= X-Received: by 2002:adf:9025:: with SMTP id h34-v6mr19026421wrh.123.1529500532253; Wed, 20 Jun 2018 06:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:5c8d:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 06:15:11 -0700 (PDT) Reply-To: andrea.merello@gmail.com In-Reply-To: References: <20180620083653.17010-1-andrea.merello@gmail.com> From: Andrea Merello Date: Wed, 20 Jun 2018 15:15:11 +0200 Message-ID: Subject: Re: [PATCH 1/6] dmaengine: xilinx_dma: fix splitting transfer causes misalignments To: Radhey Shyam Pandey Cc: "vkoul@kernel.org" , "dan.j.williams@intel.com" , Michal Simek , Appana Durga Kedareswara Rao , "dmaengine@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" 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 Wed, Jun 20, 2018 at 1:37 PM, Radhey Shyam Pandey wrote: >> -----Original Message----- >> From: dmaengine-owner@vger.kernel.org [mailto:dmaengine- >> owner@vger.kernel.org] On Behalf Of Andrea Merello >> Sent: Wednesday, June 20, 2018 2:07 PM >> To: vkoul@kernel.org; dan.j.williams@intel.com; Michal Simek >> ; Appana Durga Kedareswara Rao >> ; dmaengine@vger.kernel.org >> Cc: linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; >> Andrea Merello >> Subject: [PATCH 1/6] dmaengine: xilinx_dma: fix splitting transfer causes >> misalignments > > We should rephrase commit message to something like "In axidma > slave_sg and dma_cylic mode align split descriptors" OK >> >> 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. > This seems fatal for the HW if DRE is not enabled. OK >> >> This patch eventually adjusts the transfer size in order to make sure >> all operations start from an aligned address. >> >> Signed-off-by: Andrea Merello >> --- >> drivers/dma/xilinx/xilinx_dma.c | 27 ++++++++++++++++++++------- >> 1 file changed, 20 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c >> index 27b523530c4a..a516e7ffef21 100644 >> --- a/drivers/dma/xilinx/xilinx_dma.c >> +++ b/drivers/dma/xilinx/xilinx_dma.c >> @@ -376,6 +376,7 @@ struct xilinx_dma_chan { >> void (*start_transfer)(struct xilinx_dma_chan *chan); >> int (*stop_transfer)(struct xilinx_dma_chan *chan); >> u16 tdest; >> + u32 copy_mask; > We can reuse copy_align itself. See below. OK >> }; >> >> /** >> @@ -1789,10 +1790,14 @@ 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 >> + * making sure it is less than the hw limit and that >> + * the next chuck start address is aligned > > /s/chuck/chunk OK >> */ >> - copy = min_t(size_t, sg_dma_len(sg) - sg_used, >> - XILINX_DMA_MAX_TRANS_LEN); >> + copy = sg_dma_len(sg) - sg_used; >> + if (copy > XILINX_DMA_MAX_TRANS_LEN) >> + copy = XILINX_DMA_MAX_TRANS_LEN & >> + chan->copy_mask; >> + > > > In below implementation, we can reuse copy_align. > Same for dma_cyclic. > > if ((copy + sg_used < sg_dma_len(sg)) && > 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)); > } OK for the general idea. But to me it seems a bit more complicated than needed: What's the point in setting 'copy' with min_t, performing also the subtraction sg_dma_len(sg) - sg_used, and then add sg_used again? What about something like: - copy = min_t(size_t, sg_dma_len(sg) - sg_used, - XILINX_DMA_MAX_TRANS_LEN); + copy = sg_dma_len(sg) - sg_used; + if (copy > XILINX_DMA_MAX_TRANS_LEN && + chan->xdev->common.copy_align) + copy = rounddown(XILINX_DMA_MAX_TRANS_LEN, + (1 << chan->xdev->common.copy_align)); + >> hw = &segment->hw; >> >> /* Fill in the descriptor */ >> @@ -1894,10 +1899,14 @@ static struct dma_async_tx_descriptor >> *xilinx_dma_prep_dma_cyclic( >> >> /* >> * Calculate the maximum number of bytes to transfer, >> - * making sure it is less than the hw limit >> + * making sure it is less than the hw limit and that >> + * the next chuck start address is aligned >> */ >> - copy = min_t(size_t, period_len - sg_used, >> - XILINX_DMA_MAX_TRANS_LEN); >> + copy = period_len - sg_used; >> + if (copy > XILINX_DMA_MAX_TRANS_LEN) >> + copy = XILINX_DMA_MAX_TRANS_LEN & >> + chan->copy_mask; >> + >> hw = &segment->hw; >> xilinx_axidma_buf(chan, hw, buf_addr, sg_used, >> period_len * i); >> @@ -2402,8 +2411,12 @@ static int xilinx_dma_chan_probe(struct >> xilinx_dma_device *xdev, >> if (width > 8) >> has_dre = false; >> >> - if (!has_dre) >> + if (has_dre) { >> + chan->copy_mask = ~0; >> + } else { >> xdev->common.copy_align = fls(width - 1); >> + chan->copy_mask = ~(width - 1); >> + } > > As mentioned above we don't need this additional field. OK >> >> if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s-channel") || >> of_device_is_compatible(node, "xlnx,axi-dma-mm2s-channel") || >> -- >> 2.17.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe dmaengine" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html