Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8146870ybi; Thu, 6 Jun 2019 07:28:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqym0fwbdtJq4DlmF5IKzIwnCcPD3FcAKA5NstowJnPdQ/CBKqcT3Hhk0juMzh9cZzkOX/sD X-Received: by 2002:a63:7ca:: with SMTP id 193mr3595662pgh.240.1559831297887; Thu, 06 Jun 2019 07:28:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559831297; cv=none; d=google.com; s=arc-20160816; b=Ih89Cn+U5im88uMGZGfE/xFJluoRmJRZbSJNtjchDzhkfYfjYdESx82D778p62w+g5 M6erKg0Db3zxBebo8NcL7qjTgLhzUsrl6JgXppQkRboazVRFrPdWIFSZSAAfbUbhL5fM 16krZsegpsio+cZGiY0Go9z8o13llg4e3R4rrGsH2cmaS/NSVDHuybbZl/COFrWhz+fm Sa8o89h+De9UKf+7MGq/oW0UrtfrQ8T/EYyzlZthQBfhHbn55a0G0hLqp1YjOAluBXVX kmkfs2vQWL45LlVtCTSq9DubK3hf/MOr9XQGlV72XWeaP7PQl+X9fYRlBnrgRpIsrV6J rpcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=pt8OpEErKYbhkXIgmn6opvxFqa26QMAFqOBaWPAbo7o=; b=yJiV3/r5hoWrd3EEZQR7KvkbLkFrNviurFVz3TLNQLPrfEQZPnn6z6NiBbnEwtXUi5 65WdJnoZ7jkJJj5alDbp3b3LiCRBxkVVOqQN4YgeGIma+65KjUoCRTVkn8zbZKBZ2E65 ZO4zaDTKsZqbQsg+OR0/OPphEgJhhqLEyjLreJVs8IMuP+BocaXGdca9MSQ2csiCHdK/ lPfaxlItYAGu9MYk1yFMOcFgHrug7/IL0DBkaWOiNfPQxjXOYJjwy6nzHsstII2FsGtS 8ycMyT9Qinw5bdEqtb51/RAXoOfPYK2yBv3qfBA55kx54v6pCBM9iv59NUcdYfr3SDJn CT7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=ai+dmP+P; 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=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 12si2144420pgo.535.2019.06.06.07.28.01; Thu, 06 Jun 2019 07:28:17 -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=@nvidia.com header.s=n1 header.b=ai+dmP+P; 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=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728824AbfFFO0q (ORCPT + 99 others); Thu, 6 Jun 2019 10:26:46 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:5161 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727133AbfFFO0p (ORCPT ); Thu, 6 Jun 2019 10:26:45 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 06 Jun 2019 07:26:42 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Thu, 06 Jun 2019 07:26:44 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Thu, 06 Jun 2019 07:26:44 -0700 Received: from [10.21.132.148] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Jun 2019 14:26:41 +0000 Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member To: Dmitry Osipenko , Peter Ujfalusi , 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> <71795bb0-2b8f-2b58-281c-e7e15bca3164@gmail.com> From: Jon Hunter Message-ID: <2eab4777-79b8-0aea-c22f-ac9d11284889@nvidia.com> Date: Thu, 6 Jun 2019 15:26:39 +0100 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: <71795bb0-2b8f-2b58-281c-e7e15bca3164@gmail.com> X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL103.nvidia.com (172.20.187.11) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1559831202; bh=pt8OpEErKYbhkXIgmn6opvxFqa26QMAFqOBaWPAbo7o=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=ai+dmP+PBxtgnschw0qAiGY54eI/hQNDZ9EGMHkjY4Rsxf/XCm4N+3ruDNgw97Vpg Q5g51ygKVBTZBlQYYqUKqcL8wnabmkgiRTaWhs6RpQRPa15GzKHUwSgEHbKAKD0Sx0 HOaSYMhO42ZW7thgxxh5ehpZccUTwbHoEV8wowiY1GCN3kzd7xPzwp2nsp1n1tDDDJ NnZHxx9R5MqzOJzB8VPW0ItrqEeSxJHkGtkYpTUMLSaZuJ/dO/HjgnGk4HLTIR0yAU EGxsvDxlIpN/2ergBoe8MtRSLDLiH8rebQpSNCinj3AjOHFNFc1ufLEuyQy1ZgySJL Kj/lTx0/IaMsQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/06/2019 14:55, Dmitry Osipenko wrote: > 06.06.2019 16:45, Dmitry Osipenko =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> 06.06.2019 15:37, Jon Hunter =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> >>> On 06/06/2019 12:54, Peter Ujfalusi wrote: >>>> >>>> >>>> On 06/06/2019 13.49, Jon Hunter wrote: >>>>> >>>>> On 06/06/2019 11:22, Peter Ujfalusi wrote: >>>>> >>>>> ... >>>>> >>>>>>>>> It does sounds like that FIFO_SIZE =3D=3D src/dst_maxburst in you= r case as >>>>>>>>> well. >>>>>>>> Not exactly equal. >>>>>>>> ADMA burst_size can range from 1(WORD) to 16(WORDS) >>>>>>>> FIFO_SIZE can be adjusted from 16(WORDS) to 1024(WORDS) [can vary = in >>>>>>>> multiples of 16] >>>>>>> >>>>>>> So I think that the key thing to highlight here, is that the as Sam= eer >>>>>>> highlighted above for the Tegra ADMA there are two values that need= to >>>>>>> be programmed; the DMA client FIFO size and the max burst size. The= ADMA >>>>>>> has register fields for both of these. >>>>>> >>>>>> How does the ADMA uses the 'client FIFO size' and 'max burst size' >>>>>> values and what is the relation of these values to the peripheral si= de >>>>>> (ADMAIF)? >>>>> >>>>> Per Sameer's previous comment, the FIFO size is used by the ADMA to >>>>> determine how much space is available in the FIFO. I assume the burst >>>>> size just limits how much data is transferred per transaction. >>>>> >>>>>>> As you can see from the above the FIFO size can be much greater tha= n the >>>>>>> burst size and so ideally both of these values would be passed to t= he DMA. >>>>>>> >>>>>>> We could get by with just passing the FIFO size (as the max burst s= ize) >>>>>>> and then have the DMA driver set the max burst size depending on th= is, >>>>>>> but this does feel quite correct for this DMA. Hence, ideally, we w= ould >>>>>>> like to pass both. >>>>>>> >>>>>>> We are also open to other ideas. >>>>>> >>>>>> I can not find public documentation (I think they are walled off by >>>>>> registration), but correct me if I'm wrong: >>>>> >>>>> No unfortunately, you are not wrong here :-( >>>>> >>>>>> ADMAIF - peripheral side >>>>>> - kind of a small DMA for audio preipheral(s)? >>>>> >>>>> Yes this is the interface to the APE (audio processing engine) and da= ta >>>>> sent to the ADMAIF is then sent across a crossbar to one of many >>>>> devices/interfaces (I2S, DMIC, etc). Basically a large mux that is us= er >>>>> configurable depending on the use-case. >>>>> >>>>>> - Variable FIFO size >>>>> >>>>> Yes. >>>>> >>>>>> - sends DMA request to ADMA per words >>>>> >>>>> From Sameer's notes it says the ADMAIF send a signal to the ADMA per >>>>> word, yes. >>>>> >>>>>> ADMA - system DMA >>>>>> - receives the DMA requests from ADMAIF >>>>>> - counts the requests >>>>>> - based on some threshold of the counter it will send/read from ADM= AIF? >>>>>> - maxburst number of words probably? >>>>> >>>>> Sounds about right to me. >>>>> >>>>>> ADMA needs to know the ADMAIF's FIFO size because, it is the one who= is >>>>>> managing that FIFO from the outside, making sure that it does not ov= er >>>>>> or underrun? >>>>> >>>>> Yes. >>>>> >>>>>> And it is the one who sets the pace (in effect the DMA burst size - = how >>>>>> many bytes the DMA jumps between refills) of refills to the ADMAIF's= FIFO? >>>>> >>>>> Yes. >>>>> >>>>> So currently, if you look at the ADMA driver >>>>> (drivers/dma/tegra210-adma.c) you will see we use the src/dst_maxburs= t >>>>> for the burst, but the FIFO size is hard-coded (see the >>>>> TEGRA210_FIFO_CTRL_DEFAULT and TEGRA186_FIFO_CTRL_DEFAULT definitions= ). >>>>> Ideally, we should not hard-code this but pass it. >>>> >>>> Sure, hardcoding is never good ;) >>>> >>>>> Given that there are no current users of the ADMA upstream, we could >>>>> change the usage of the src/dst_maxburst, but being able to set the F= IFO >>>>> size as well would be ideal. >>>> >>>> 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 =3D=3D 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 D= MA >>>> 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 (a= nd >>>> 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 b= etter. >>> >>> 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. >>> >>> Jon >>> >> >> Hi, >> >> If I understood everything correctly, the FIFO buffer is shared among >> all of the ADMA clients and hence it should be up to the ADMA driver to >> manage the quotas of the clients. So if there is only one client that >> uses ADMA at a time, then this client will get a whole FIFO buffer, but >> once another client starts to use ADMA, then the ADMA driver will have >> to reconfigure hardware to split the quotas. >> >=20 > You could also simply hardcode the quotas per client in the ADMA driver > if the quotas are going to be static anyway. Essentially this is what we have done so far, but Sameer is looking for a way to make this more programmable/flexible. We can always do that if there is no other option indeed. However, seems like a good time to see if there is a better way. Jon --=20 nvpublic