linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dan.j.williams@intel.com (Dan Williams)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] ARM: define the PrimeCell DMA API
Date: Wed, 24 Mar 2010 15:01:24 -0700	[thread overview]
Message-ID: <e9c3a7c21003241501x1f1ed857pcaaaf8ea8dc563ec@mail.gmail.com> (raw)
In-Reply-To: <CEE6BB42CAD6E947908279175AF8470A0391EEB1@EXDCVYMBSTM006.EQ1STM.local>

On Wed, Mar 24, 2010 at 2:38 PM, Linus WALLEIJ
<linus.walleij@stericsson.com> wrote:
> As it happens I'm entertaining myself with this patchset
> right now...
>
>> > +void dma_set_ambaconfig(struct dma_chan *chan,
>> > + ? ? ? ? ? ? ? ? ? ? ? struct amba_dma_channel_config *config);
>> > +void dma_stop_channel(struct dma_chan *chan);
>> > +u32 dma_get_channel_bytes_left(struct dma_chan *chan);
>>
>> I question if these last two can be generically promoted to dmaengine?
>
> OK...
>
> I renamed get_channel_bytes_left() to get_channel_residue() btw.
>
>> ?I already discussed a potential dma_get_channel_bytes() synonym with
>> Guennadi [1] (wrap ->device_is_tx_complete()),
>> and dma_stop_channel()
>> looks like it could wrap ->device_terminate_all().
>
> Actually its a little bit like STOP/PAUSE/UNPAUSE on a tape
> recorder, I find that in practice I have these two usecases:
>
> * STOP (as in cancel) the DMA transfer and retrieve the number
> ?of bytes left at that point
>
> * PAUSE the DMA transfer and retrieve the number of bytes
> ?left at that point, later UNPAUSE or STOP
>
> * retrieve the number of bytes left in an ongoing transfer,
> ?a fluctuating value. This is typically nice for audio
> ?progress bars to take some simple example.
>
> Right now, for the PrimeCells, I only need to be able to STOP the
> channel and get the residual bytes at this time. So I'll create
> something like dma_get_residue() in the DMA devices, and specify
> the sematics such that if device_terminate_all() is called before
> this point the residual at that time shall be returned, else
> the current fluctuating value, would that be OK?

Sounds ok, and I would not mind renaming device_is_tx_complete() to
device_tx_status() for this purpose.

What are your semantics for keeping the transaction information alive
until it gets consumed.  Currently the dma_ctrl_flags have the
DMA_CTRL_ACK bit to specify that the descriptor not be
recycled/destroyed until the client has a chance to attach a dependent
operation.  Seems you need something similar to indicate that the
residue information not be destroyed until it is consumed.  In other
words how does a client guarantee that the engine provides the
information it needs?

--
Dan

  reply	other threads:[~2010-03-24 22:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-08 13:52 [PATCH 1/5] ARM: define the PrimeCell DMA API Linus Walleij
2010-03-24 21:08 ` Dan Williams
2010-03-24 21:38   ` Linus WALLEIJ
2010-03-24 22:01     ` Dan Williams [this message]
2010-03-24 22:13       ` Linus WALLEIJ
2010-03-24 23:30         ` Dan Williams
2010-03-25  7:10           ` Linus WALLEIJ
2010-03-24 21:25 ` Dan Williams
2010-03-24 22:08   ` Linus WALLEIJ
2010-03-24 23:03     ` Dan Williams

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=e9c3a7c21003241501x1f1ed857pcaaaf8ea8dc563ec@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=linux-arm-kernel@lists.infradead.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).