From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Sameer Pujar <spujar@nvidia.com>, Vinod Koul <vkoul@kernel.org>
Cc: dan.j.williams@intel.com, tiwai@suse.com,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
sharadg@nvidia.com, rlokhande@nvidia.com, dramesh@nvidia.com,
mkumard@nvidia.com, linux-tegra <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH] [RFC] dmaengine: add fifo_size member
Date: Thu, 6 Jun 2019 20:25:14 +0300 [thread overview]
Message-ID: <457eb5e1-40cc-8c0f-e21c-3881c3c04de2@gmail.com> (raw)
In-Reply-To: <a652b103-979d-7910-5e3f-ec4bca3a3a3b@nvidia.com>
06.06.2019 19:53, Jon Hunter пишет:
>
> On 06/06/2019 17:44, Dmitry Osipenko wrote:
>> 06.06.2019 19:32, Jon Hunter пишет:
>>>
>>> On 06/06/2019 16:18, Dmitry Osipenko wrote:
>>>
>>> ...
>>>
>>>>>> 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.
>>>
>>> Actually, this is still very much relevant for the static case. Even if
>>> we defined a static configuration of the FIFO mapping in the ADMAIF
>>> driver we still need to pass this information to the ADMA. I don't
>>> really like the idea of having it statically defined in two different
>>> drivers.
>>
>> Ah, so you need to apply the same configuration in two places. Correct?
>>
>> Are ADMAIF and ADMA really two different hardware blocks? Or you
>> artificially decoupled the ADMA driver?
>
> These are two different hardware modules with their own register sets.
> Yes otherwise, it would be a lot simpler!
The register sets are indeed separated, but it looks like that ADMAIF is
really a part of ADMA that is facing to Audio Crossbar. No? What is the
purpose of ADMAIF? Maybe you could amend the ADMA hardware description
with the ADMAIF addition until it's too late.
next prev parent reply other threads:[~2019-06-06 17:25 UTC|newest]
Thread overview: 60+ 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 11:54 ` Peter Ujfalusi
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:36 ` Jon Hunter
2019-06-06 14:36 ` Dmitry Osipenko
2019-06-06 14:47 ` 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:44 ` Dmitry Osipenko
2019-06-06 16:53 ` Jon Hunter
2019-06-06 17:25 ` Dmitry Osipenko [this message]
2019-06-06 17:56 ` Dmitry Osipenko
2019-06-07 9:24 ` Jon Hunter
2019-06-07 5:50 ` Peter Ujfalusi
2019-06-07 9:18 ` Jon Hunter
2019-06-07 10:27 ` Jon Hunter
2019-06-07 12:17 ` Peter Ujfalusi
2019-06-07 12:58 ` Jon Hunter
2019-06-07 13:35 ` Peter Ujfalusi
2019-06-07 20:53 ` Dmitry Osipenko
2019-06-10 8:01 ` Jon Hunter
2019-06-10 7:59 ` Jon Hunter
2019-06-13 4:43 ` Vinod Koul
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=457eb5e1-40cc-8c0f-e21c-3881c3c04de2@gmail.com \
--to=digetx@gmail.com \
--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=linux-tegra@vger.kernel.org \
--cc=mkumard@nvidia.com \
--cc=peter.ujfalusi@ti.com \
--cc=rlokhande@nvidia.com \
--cc=sharadg@nvidia.com \
--cc=spujar@nvidia.com \
--cc=tiwai@suse.com \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).