From mboxrd@z Thu Jan 1 00:00:00 1970 From: dan.j.williams@intel.com (Dan Williams) Date: Wed, 24 Mar 2010 15:01:24 -0700 Subject: [PATCH 1/5] ARM: define the PrimeCell DMA API In-Reply-To: References: <1268056327-16577-1-git-send-email-linus.walleij@stericsson.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Mar 24, 2010 at 2:38 PM, Linus WALLEIJ 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