Thread (58 messages) 58 messages, 5 authors, 2019-09-16

Re: [PATCH] [RFC] dmaengine: add fifo_size member

From: Dmitry Osipenko <digetx@gmail.com>
Date: 2019-06-06 15:18:33
Also in: linux-tegra, lkml

06.06.2019 17:25, Jon Hunter пишет:

On 06/06/2019 14:45, Dmitry Osipenko wrote:
quoted
06.06.2019 15:37, Jon Hunter пишет:
quoted
On 06/06/2019 12:54, Peter Ujfalusi wrote:
quoted

On 06/06/2019 13.49, Jon Hunter wrote:
quoted
On 06/06/2019 11:22, Peter Ujfalusi wrote:

...
quoted
quoted
quoted
quoted
It does sounds like that FIFO_SIZE == src/dst_maxburst in your 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 Sameer
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 side
(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.
quoted
quoted
As you can see from the above the FIFO size can be much greater than the
burst size and so ideally both of these values would be passed to the DMA.

We could get by with just passing the FIFO size (as the max burst size)
and then have the DMA driver set the max burst size depending on this,
but this does feel quite correct for this DMA. Hence, ideally, we would
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 :-(
quoted
ADMAIF - peripheral side
 - kind of a small DMA for audio preipheral(s)?
Yes this is the interface to the APE (audio processing engine) and data
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 user
configurable depending on the use-case.
quoted
 - Variable FIFO size
Yes.
quoted
 - sends DMA request to ADMA per words
From Sameer's notes it says the ADMAIF send a signal to the ADMA per
word, yes.
quoted
ADMA - system DMA
 - receives the DMA requests from ADMAIF
 - counts the requests
 - based on some threshold of the counter it will send/read from ADMAIF?
  - maxburst number of words probably?
Sounds about right to me.
quoted
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 over
or underrun?
Yes.
quoted
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_maxburst
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 ;)
quoted
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 FIFO
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 == 32bits?).
The TX/RX size are the FIFO size. So 3 equates to a FIFO size of 3 * 64
bytes.
quoted
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.
quoted
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.
quoted
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.

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.
The FIFO quotas are managed by the ADMAIF driver (does not exist in
mainline currently but we are working to upstream this) because it is
this device that owns and needs to configure the FIFOs. So it is really
a means to pass the information from the ADMAIF to the ADMA.
So you'd want to reserve a larger FIFO for an audio channel that has a
higher audio rate since it will perform reads more often. You could also
prioritize one channel over the others, like in a case of audio call for
example.

Is the shared buffer smaller than may be needed by clients in a worst
case scenario? If you could split the quotas statically such that each
client won't ever starve, then seems there is no much need in the
dynamic configuration.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help