linux-kernel - Re: [PATCHv2] DMAEngine: Define generic transfer request api

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4whS+_hEdyNgOKOUzRBCn=99Z4x0x_jg1qnsL+uTmjt+A@mail.gmail.com>
Date:	Fri, 16 Sep 2011 15:17:03 +0800
From:	Barry Song <21cnbao@...il.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	dan.j.williams@...el.com, vkoul@...radead.org,
	linux-kernel@...r.kernel.org, rmk+kernel@....linux.org.uk
Subject: Re: [PATCHv2] DMAEngine: Define generic transfer request api

2011/9/15 Jassi Brar <jaswinder.singh@...aro.org>:
> Define a new api that could be used for doing fancy data transfers
> like interleaved to contiguous copy and vice-versa.
> Traditional SG_list based transfers tend to be very inefficient in
> such cases as where the interleave and chunk are only a few bytes,
> which call for a very condensed api to convey pattern of the transfer.
>
> This api supports all 4 variants of scatter-gather and contiguous transfer.
> Besides, in future it could also represent common operations like
>        device_prep_dma_{cyclic, memset, memcpy}
> and maybe some more that I am not sure of.
>
> Of course, neither can this api help transfers that don't lend to DMA by
> nature, i.e, scattered tiny read/writes with no periodic pattern.
>
> Signed-off-by: Jassi Brar <jaswinder.singh@...aro.org>
> ---
>
> Changes since v1:
>   1) Dropped the 'dma_transaction_type' member until we really
>      merge another type into this api. Instead added special
>      type for this api - DMA_GENXFER in dma_transaction_type.
>   2) Renamed 'xfer_template' to 'dmaxfer_template' inorder to
>      preserve namespace, closer to as suggested by Barry Song.
>
>  drivers/dma/dmaengine.c   |    2 +
>  include/linux/dmaengine.h |   71 +++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 73 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index b48967b..63284f6 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -699,6 +699,8 @@ int dma_async_device_register(struct dma_device *device)
>                !device->device_prep_dma_cyclic);
>        BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
>                !device->device_control);
> +       BUG_ON(dma_has_cap(DMA_GENXFER, device->cap_mask) &&
> +               !device->device_prep_dma_genxfer);

i don't think it is what i want here. device_prep_dma_genxfer should
be able to cover memcpy, slave or other modes, but not parallel with
them.
For example, if i use genxfer, but my devices are slave. i might not
need a device_prep_slave_sg since i have already prep_dma_genxfer, but
anyway, i need a DMA_SLAVE_CONFIG to set burst size or others. then
i'd like to have DMA_SLAVE flag but without device_prep_slave_sg
callback.

>
>        BUG_ON(!device->device_alloc_chan_resources);
>        BUG_ON(!device->device_free_chan_resources);
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 8fbf40e..68ebe6c 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -71,11 +71,79 @@ enum dma_transaction_type {
>        DMA_ASYNC_TX,
>        DMA_SLAVE,
>        DMA_CYCLIC,
> +       DMA_GENXFER,
>  };

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/