Re: [RFD RESEND] dmaengine: add new sleepy alloc descriptor and slave sg APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/24/2017 01:13 AM, Vinod Koul wrote:
> There have been discussions on need for change of dmaengine API for
> a) allow sleepy invocation of the prepare descriptor so that drivers can
> do the runtime pm (maybe move into core as well)
> b) split the prepare operation to allocate and new prepare methods
> 
> TBD: Should the new prepare be atomic or not
> TBD: Should we move the pm calls to core
> TBA: Documentation and wrappers for these calls

I'm not convinced by this approach. You only know how much memory you need
to allocate once you know what the content of the DMA descriptor is. E.g.
depending on the length of the transfer the transfer might need to be split
into multiple internal segments. So you'd still have to do a alloc operation
in the device_desc_prep_slave_sg() callback.

For PM I'd much rather have explicit PM operations which signal intent to
use the DMA channel. E.g. dmaengine_channel_pm_{get,put}() or something
similar. For audio these could for example be called when the PCM device is
opened/closed.

> 
> Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx>
> ---
> 
> resend with CC list, missed first try...
> 
>  include/linux/dmaengine.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 533680860865..33edcc5bc723 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -658,6 +658,11 @@ struct dma_filter {
>  	const struct dma_slave_map *map;
>  };
>  
> +enum dmaengine_operation {
> +	DMAENGINE_SLAVE_SG = 1,
> +	DMAENGINE_SLAVE_LAST = DMAENGINE_SLAVE_SG,
> +};
> +
>  /**
>   * struct dma_device - info on the entity supplying DMA services
>   * @chancnt: how many DMA channels are supported
> @@ -700,6 +705,10 @@ struct dma_filter {
>   *	be called after period_len bytes have been transferred.
>   * @device_prep_interleaved_dma: Transfer expression in a generic way.
>   * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
> + * @device_alloc_descriptor: Allocate a dma descriptor for dmaengine operation
> + * 	specfied. Can by invoked from sleepy context.
> + * 	Cannot be called from callback context.
> + * @device_desc_prep_slave_sg: Prepare a slave sg txn for a given descriptor
>   * @device_config: Pushes a new configuration to a channel, return 0 or an error
>   *	code
>   * @device_pause: Pauses any transfer happening on a channel. Returns
> @@ -792,6 +801,12 @@ struct dma_device {
>  		struct dma_chan *chan, dma_addr_t dst, u64 data,
>  		unsigned long flags);
>  
> +	struct dma_async_tx_descriptor *(*device_alloc_descriptor)(
> +		struct dma_chan *chan, enum dmaengine_operation op);
> +	int (*device_desc_prep_slave_sg)(struct dma_chan *chan,
> +		struct scatterlist *sgl, unsigned int sg_len,
> +		enum dma_transfer_direction direction, unsigned long flags);
> +
>  	int (*device_config)(struct dma_chan *chan,
>  			     struct dma_slave_config *config);
>  	int (*device_pause)(struct dma_chan *chan);
> 

--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux