Re: [PATCHv2] DMAEngine: Define generic transfer request api

[Jassi Brar]

On 16 September 2011 22:36, Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
>> >> Define a new api that could be used for doing fancy data transfers
>> >> like interleaved to contiguous copy and vice-versa.
>> > Then this is a very specific type of transfer this API supports, so the
>> > name generic_xxx is not apt!
>>
>> Currently it doesn't support every operation, perhaps there will be an
>> operation that couldn't ever be merged into this.
>> But it does support interleaved(async and slave), memcpy, memset, dma_sg,
>> slave_sg, and cyclic.
>> Please feel free to suggest a better name.
> ATM, this api is for interleaved like dma operation. so
> prep_interleaved_dma may be better suited.
Well, ok I can live with that.

> Let the generalization be discussed separately...
As you wish.

>> >> +/**
>> >> + * Generic Transfer Request
>> >> + * ------------------------
>> >> + * A chunk is collection of contiguous bytes to be transfered.
>> >> + * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>> >> + * ICGs may or maynot change between chunks.
>> >> + * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>> >> + *  that when repeated an integral number of times, specifies the transfer.
>> >> + * A transfer template is specification of a Frame, the number of times
>> >> + *  it is to be repeated and other per-transfer attributes.
>> >> + *
>> >> + * Practically, a client driver would have ready a template for each
>> >> + *  type of transfer it is going to need during its lifetime and
>> >> + *  set only 'src_start' and 'dst_start' before submitting the requests.
>> >> + *
>> >> + *
>> >> + *  |      Frame-1        |       Frame-2       | ~ |       Frame-'numf'  |
>> >> + *  |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>> >> + *
>> >> + *    ==  Chunk size
>> >> + *    ... ICG
>> >> + */
>> >> +
>> >> +/**
>> >> + * struct data_chunk - Element of scatter-gather list that makes a frame.
>> >> + * @size: Number of bytes to read from source.
>> >> + *     size_dst := fn(op, size_src), so doesn't mean much for destination.
>> >> + * @icg: Number of bytes to jump after last src/dst address of this
>> >> + *    chunk and before first src/dst address for next chunk.
>> >> + *    Ignored for dst(assumed 0), if dst_inc is true and dst_sgl is false.
>> >> + *    Ignored for src(assumed 0), if src_inc is true and src_sgl is false.
>> >> + */
>> >> +struct data_chunk {
>> >> +     size_t size;
>> >> +     size_t icg;
>> >> +};
>> >> +
>> >> +/**
>> >> + * struct dmaxfer_template - Template to convey DMAC the transfer pattern
>> >> + *    and attributes.
>> >> + * @src_start: Bus address of source for the first chunk.
>> >> + * @dst_start: Bus address of destination for the first chunk.
>> >> + * @src_inc: If the source address increments after reading from it.
>> >> + * @dst_inc: If the destination address increments after writing to it.
>> >> + * @src_sgl: If the 'icg' of sgl[] applies to Source (scattered read).
>> >> + *           Otherwise, source is read contiguously (icg ignored).
>> >> + *           Ignored if src_inc is false.
>> >> + * @dst_sgl: If the 'icg' of sgl[] applies to Destination (scattered write).
>> >> + *           Otherwise, destination is filled contiguously (icg ignored).
>> >> + *           Ignored if dst_inc is false.
>> >> + * @frm_irq: If the client expects DMAC driver to do callback after each frame.
>> >> + * @numf: Number of frames in this template.
>> >> + * @frame_size: Number of chunks in a frame i.e, size of sgl[].
>> >> + * @sgl: Array of {chunk,icg} pairs that make up a frame.
>> >> + */
>> >> +struct dmaxfer_template {
>> >> +     dma_addr_t src_start;
>> >> +     dma_addr_t dst_start;
>> >> +     bool src_inc;
>> >> +     bool dst_inc;
>> >> +     bool src_sgl;
>> >> +     bool dst_sgl;
>> >> +     bool frm_irq;
>> >> +     size_t numf;
>> >> +     size_t frame_size;
>> >> +     struct data_chunk sgl[0];
>> >> +};
>> > This kind of transfer can be either slave (audio interleaved) based or
>> > mem-to-mem (extracting still image from a buffer),
>> > How do you propose the dmac know about this is unclear to me
>>
>> Every 'prepare' callback already passes the channel chosen for the transfer.
>> And the DMAC driver already knows if that channel is SLAVE capable or not.
> How about above params, you should add they may/may not be valid
> depending upon the mode.
If you look at the documentation above the 'struct dmaxfer_template', I have
already mentioned what params are ignored/invalid when.
Or is there something else you want mentioned ?

> Pls also send updates to documentation for this API
Ok, I'll write some notes on using this api in Documentation/dmaengine.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/