Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8987537ybi; Fri, 7 Jun 2019 01:22:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyKW8Bm7UsQpXgrah3UgejP/Q5BvjaKlXOPOZvy2g8AQ4nwBjEAFFCiowI0S9VmSuQGezfb X-Received: by 2002:a17:90a:8a86:: with SMTP id x6mr4225700pjn.100.1559895735924; Fri, 07 Jun 2019 01:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559895735; cv=none; d=google.com; s=arc-20160816; b=EaLNykpf7dYuXaS7g1yBb+yxk1fJRcrF7BiDCYoZYitoM2k6UxeFmmpQhZGWQoE65m iub1ppJ0Zx34XKZInCXYskZDgXGIEuxsoJ/vjmOkJAaNzTrN74sKXAplrH2a6d6GU3fB id8HHBFLckOnUNGudv7IBu9XTVNo7gPwa68Jj7Owg3YJLwvYC91pwb5523RJlnqe11v4 igW/fZLzF6qpc5Qxlczuguvva5myAx+koBuAv0v6Qp9luUmGomlIcAQTIv137rShoaPE fFjx4pBjphyJE06U77Gdm5hnMrdlc6vI0PL9lrQqFxn4ZdOUBpzj/pt3tlKQWJ6AYIun eKmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=MEagnH+kxa/s49pg8767gTrJDW79F25A6Ljg2yywMAM=; b=jbHnsxu+rfyJJAChs+1BA/t2h26/mE2x3/i89NQSUQQAEoQD0+zO1J7UpO2hkUEcXT XNOViB5ldx4zsCLJJec1ODlCH5j3msKjMYmM4aowrzolA66SEy1mQNnUxxd1yb1c04ve xzKy+N32vW4zE/BdYVQEMsTGIjxXZPuwgDVWFoNnehSxDrnsyWEdr7m2Og0Px1+zrKes McDfJlcJZNuSynHVbuCmDvKwuIpIuIpXxTvJ7jcEAxofq13W3XzzqqPFWdzXlc78Uggb MhmV0rXE3kURF8eRFIhjgNct6gPGyfRw3lBK3nXyBpS4imACzmqd6H14Wr8SnYU1ZxUX MjpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b="f4Y/Z1dO"; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n129si1206009pfn.106.2019.06.07.01.21.56; Fri, 07 Jun 2019 01:22:15 -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=@ti.com header.s=ti-com-17Q1 header.b="f4Y/Z1dO"; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726656AbfFGHB4 (ORCPT + 99 others); Fri, 7 Jun 2019 03:01:56 -0400 Received: from lelv0143.ext.ti.com ([198.47.23.248]:45988 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726107AbfFGHBz (ORCPT ); Fri, 7 Jun 2019 03:01:55 -0400 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id x575ngl4006282; Fri, 7 Jun 2019 00:49:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1559886582; bh=MEagnH+kxa/s49pg8767gTrJDW79F25A6Ljg2yywMAM=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=f4Y/Z1dOPufN9GWrG/ITdjZw+4v5bZsUm/7AJAaIo619OzOzhBVvcN2odiJZm8sY/ QhrE2jn/CsinbMhp47a42n+xS1VDzkj/LadgxyoESHMLtVVWawgGCc9g1lp1btvZMu AvSg8JmBOvuHak6DBMnRTm/uQHH/BuYO8hnw4dbE= Received: from DFLE108.ent.ti.com (dfle108.ent.ti.com [10.64.6.29]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x575ngto024423 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 7 Jun 2019 00:49:42 -0500 Received: from DFLE107.ent.ti.com (10.64.6.28) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 7 Jun 2019 00:49:42 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE107.ent.ti.com (10.64.6.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Fri, 7 Jun 2019 00:49:42 -0500 Received: from [192.168.2.10] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id x575ndR3104523; Fri, 7 Jun 2019 00:49:40 -0500 Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member To: Jon Hunter , Sameer Pujar , Vinod Koul CC: , , , , , , , , linux-tegra References: <1556623828-21577-1-git-send-email-spujar@nvidia.com> <20190502060446.GI3845@vkoul-mobl.Dlink> <20190502122506.GP3845@vkoul-mobl.Dlink> <3368d1e1-0d7f-f602-5b96-a978fcf4d91b@nvidia.com> <20190504102304.GZ3845@vkoul-mobl.Dlink> <20190506155046.GH3845@vkoul-mobl.Dlink> <4cab47d0-41c3-5a87-48e1-d7f085c2e091@nvidia.com> <8a5b84db-c00b-fff4-543f-69d90c245660@nvidia.com> <3f836a10-eaf3-f59b-7170-6fe937cf2e43@ti.com> <4593f37c-5e89-8559-4e80-99dbfe4235de@nvidia.com> From: Peter Ujfalusi Message-ID: Date: Fri, 7 Jun 2019 08:50:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4593f37c-5e89-8559-4e80-99dbfe4235de@nvidia.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jon, On 06/06/2019 15.37, Jon Hunter wrote: >> Looking at the drivers/dma/tegra210-adma.c for the >> TEGRA*_FIFO_CTRL_DEFAULT definition it is still not clear where the >> remote FIFO size would fit. >> There are fields for overflow and starvation(?) thresholds and TX/RX >> size (assuming word length, 3 == 32bits?). > > The TX/RX size are the FIFO size. So 3 equates to a FIFO size of 3 * 64 > bytes. > >> Both threshold is set to one, so I assume currently ADMA is >> pushing/pulling data word by word. > > That's different. That indicates thresholds when transfers start. > >> Not sure what the burst size is used for, my guess would be that it is >> used on the memory (DDR) side for optimized, more efficient accesses? > > That is the actual burst size. > >> My guess is that the threshold values are the counter limits, if the DMA >> request counter reaches it then ADMA would do a threshold limit worth of >> push/pull to ADMAIF. >> Or there is another register where the remote FIFO size can be written >> and ADMA is counting back from there until it reaches the threshold (and >> pushes/pulling again threshold amount of data) so it keeps the FIFO >> filled with at least threshold amount of data? >> >> I think in both cases the threshold would be the maxburst. >> >> I suppose you have the patch for adma on how to use the fifo_size >> parameter? That would help understand what you are trying to achieve better. > > Its quite simple, we would just use the FIFO size to set the fields > TEGRAXXX_ADMA_CH_FIFO_CTRL_TXSIZE/RXSIZE in the > TEGRAXXX_ADMA_CH_FIFO_CTRL register. That's all. Hrm, it is still not clear how all of these fits together. What happens if you configure ADMA side: BURST = 10 TX/RXSIZE = 100 (100 * 64 bytes?) /* FIFO_SIZE? */ *THRES = 5 And if you change the *THRES to 10? And if you change the TX/RXSIZE to 50 (50 * 64 bytes?) And if you change the BURST to 5? In other words what is the relation between all of these? There must be a rule and constraints around these and if we do really need a new parameter for ADMA's FIFO_SIZE I'd like it to be defined in a generic way so others could benefit without 'misusing' a fifo_size parameter for similar, but not quite fifo_size information. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki