From: Vinod Koul <vkoul@kernel.org>
To: Sameer Pujar <spujar@nvidia.com>
Cc: dan.j.williams@intel.com, tiwai@suse.com, jonathanh@nvidia.com,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
sharadg@nvidia.com, rlokhande@nvidia.com, dramesh@nvidia.com,
mkumard@nvidia.com
Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member
Date: Thu, 13 Jun 2019 10:13:52 +0530 [thread overview]
Message-ID: <20190613044352.GC9160@vkoul-mobl.Dlink> (raw)
In-Reply-To: <b7e28e73-7214-f1dc-866f-102410c88323@nvidia.com>
On 06-06-19, 09:19, Sameer Pujar wrote:
> > you are really going other way around about the whole picture. FWIW that
> > is how *other* folks do audio with dmaengine!
> I discussed this internally with HW folks and below is the reason why DMA
> needs
> to know FIFO size.
>
> - FIFOs reside in peripheral device(ADMAIF), which is the ADMA interface to
> the audio sub-system.
> - ADMAIF has multiple channels and share FIFO buffer for individual
> operations. There is a provision
> to allocate specific fifo size for each individual ADMAIF channel from the
> shared buffer.
> - Tegra Audio DMA(ADMA) architecture is different from the usual DMA
> engines, which you described earlier.
> - The flow control logic is placed inside ADMA. Slave peripheral
> device(ADMAIF) signals ADMA whenever a
> read or write happens on the FIFO(per WORD basis). Please note that the
> signaling is per channel. There is
> no other signaling present from ADMAIF to ADMA.
> - ADMA keeps a counter related to above signaling. Whenever a sufficient
when is signal triggered? When there is space available or some
threshold of space is reached?
> space is available, it initiates a transfer.
> But the question is, how does it know when to transfer. This is the
> reason, why ADMA has to be aware of FIFO
> depth of ADMAIF channel. Depending on the counters and FIFO depth, it
> knows exactly when a free space is available
> in the context of a specific channel. On ADMA, FIFO_SIZE is just a value
> which should match to actual FIFO_DEPTH/SIZE
> of ADMAIF channel.
That doesn't sound too different from typical dmaengine. To give an
example of a platform (and general DMAengine principles as well) I worked
on the FIFO was 16 word deep. DMA didn't knew!
Peripheral driver would signal to DMA when a threshold is reached and
DMA would send a burst controlled by src/dst_burst_size. For example if
you have a FIFO with 16 words depth, typical burst_size would be 8 words
and peripheral will configure signalling for FIFO having 8 words, so
signal from peripheral will make dma transfer 8 words.
Here the peripheral driver FIFO is important, but the driver
configures it and sets burst_size accordingly.
So can you explain me what is the difference here that the peripheral
cannot configure and use burst size with passing fifo depth?
> - Now consider two cases based on above logic,
> * Case 1: when DMA_FIFO_SIZE > SLAVE_FIFO_SIZE
> In this case, ADMA thinks that there is enough space available for
> transfer, when actually the FIFO data
> on slave is not consumed yet. It would result in OVERRUN.
> * Case 2: when DMA_FIFO_SIZE < SLAVE_FIFO_SIZE
> This is case where ADMA won’t transfer, even though sufficient space is
> available, resulting in UNDERRUN.
> - The guideline is to program, DMA_FIFO_SIZE(on ADMA side) =
> SLAVE_FIFO_SIZE(on ADMAIF side) and hence we need a
> way to communicate fifo size info to ADMA.
--
~Vinod
next prev parent reply other threads:[~2019-06-13 16:48 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 11:30 [RFC] dmaengine: add fifo_size member Sameer Pujar
2019-04-30 11:30 ` [PATCH] " Sameer Pujar
2019-05-02 6:04 ` Vinod Koul
2019-05-02 6:04 ` [PATCH] " Vinod Koul
2019-05-02 10:53 ` Sameer Pujar
2019-05-02 12:25 ` Vinod Koul
2019-05-02 13:29 ` Sameer Pujar
2019-05-03 19:10 ` Peter Ujfalusi
2019-05-04 10:23 ` Vinod Koul
2019-05-06 13:04 ` Sameer Pujar
2019-05-06 15:50 ` Vinod Koul
2019-06-06 3:49 ` Sameer Pujar
2019-06-06 6:00 ` Peter Ujfalusi
2019-06-06 6:41 ` Sameer Pujar
2019-06-06 7:14 ` Jon Hunter
2019-06-06 10:22 ` Peter Ujfalusi
2019-06-06 10:49 ` Jon Hunter
2019-06-06 10:49 ` Jon Hunter
2019-06-06 11:54 ` Peter Ujfalusi
2019-06-06 11:54 ` Peter Ujfalusi
2019-06-06 12:37 ` Jon Hunter
2019-06-06 12:37 ` Jon Hunter
2019-06-06 13:45 ` Dmitry Osipenko
2019-06-06 13:55 ` Dmitry Osipenko
2019-06-06 14:26 ` Jon Hunter
2019-06-06 14:26 ` Jon Hunter
2019-06-06 14:36 ` Jon Hunter
2019-06-06 14:36 ` Jon Hunter
2019-06-06 14:36 ` Dmitry Osipenko
2019-06-06 14:47 ` Jon Hunter
2019-06-06 14:47 ` Jon Hunter
2019-06-06 14:25 ` Jon Hunter
2019-06-06 14:25 ` Jon Hunter
2019-06-06 15:18 ` Dmitry Osipenko
2019-06-06 16:32 ` Jon Hunter
2019-06-06 16:32 ` Jon Hunter
2019-06-06 16:44 ` Dmitry Osipenko
2019-06-06 16:53 ` Jon Hunter
2019-06-06 16:53 ` Jon Hunter
2019-06-06 17:25 ` Dmitry Osipenko
2019-06-06 17:56 ` Dmitry Osipenko
2019-06-07 9:24 ` Jon Hunter
2019-06-07 9:24 ` Jon Hunter
2019-06-07 5:50 ` Peter Ujfalusi
2019-06-07 5:50 ` Peter Ujfalusi
2019-06-07 9:18 ` Jon Hunter
2019-06-07 9:18 ` Jon Hunter
2019-06-07 10:27 ` Jon Hunter
2019-06-07 10:27 ` Jon Hunter
2019-06-07 12:17 ` Peter Ujfalusi
2019-06-07 12:17 ` Peter Ujfalusi
2019-06-07 12:58 ` Jon Hunter
2019-06-07 12:58 ` Jon Hunter
2019-06-07 13:35 ` Peter Ujfalusi
2019-06-07 13:35 ` Peter Ujfalusi
2019-06-07 20:53 ` Dmitry Osipenko
2019-06-10 8:01 ` Jon Hunter
2019-06-10 8:01 ` Jon Hunter
2019-06-10 7:59 ` Jon Hunter
2019-06-10 7:59 ` Jon Hunter
2019-06-13 4:43 ` Vinod Koul [this message]
2019-06-17 7:07 ` Sameer Pujar
2019-06-18 4:33 ` Vinod Koul
2019-06-20 10:29 ` Sameer Pujar
2019-06-24 6:26 ` Vinod Koul
2019-06-25 2:57 ` Sameer Pujar
2019-07-05 6:15 ` Sameer Pujar
2019-07-15 15:42 ` Sameer Pujar
2019-07-19 5:04 ` Vinod Koul
2019-07-23 5:54 ` Sameer Pujar
2019-07-29 6:10 ` Vinod Koul
2019-07-31 9:48 ` Jon Hunter
2019-07-31 15:16 ` Vinod Koul
2019-08-02 8:51 ` Jon Hunter
2019-08-08 12:38 ` Vinod Koul
2019-08-19 15:56 ` Jon Hunter
2019-08-20 11:05 ` Vinod Koul
2019-09-16 9:02 ` Sameer Pujar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190613044352.GC9160@vkoul-mobl.Dlink \
--to=vkoul@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=dramesh@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkumard@nvidia.com \
--cc=rlokhande@nvidia.com \
--cc=sharadg@nvidia.com \
--cc=spujar@nvidia.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.