linux-kernel - Re: [PATCHv4] DMAEngine: Define interleaved 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 28 Sep 2011 20:45:45 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	linux-kernel@...r.kernel.org, dan.j.williams@...el.com,
	rmk@....linux.org.uk, 21cnbao@...il.com
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

On 28 September 2011 14:33, Vinod Koul <vinod.koul@...el.com> wrote:
> On Wed, 2011-09-28 at 12:09 +0530, Jassi Brar wrote:

>>
>> +     struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
>> +             struct dma_chan *chan, struct dmaxfer_template *xt,
>> +             unsigned long flags);
> what's the flags used for?
Same as for device_prep_slave_sg, device_prep_dma_sg, device_prep_dma_interrupt,
device_prep_dma_memset etc. Usually for flagging buffer map/unmap'ing
in this case.
Btw, this was present in v3 as well.


>> +enum xfer_direction {
>> +     MEM_TO_MEM,
>> +     MEM_TO_DEV,
>> +     DEV_TO_MEM,
>> +     DEV_TO_DEV,
> Use/update dma_data_direction.
dma_data_direction is the mapping attribute of a buffer.
While that info is what some dmac driver might need ultimately, our main
aim here is to tell exactly if Src and Dst is Memory or a device's FIFO.

Mapping attribute of src/dst buffers could be very well deducted from
xfer_direction, but dma_data_direction isn't meant to tell if Src and Dst
is Mem or FIFO.
Also, for (SLAVE && !src_inc && !dst_inc) we need to disambiguate three
options  Mem->Fifo,  Fifo->Mem,  *Fifo->Fifo*(not impossible)
So while using dma_data_direction would work today, that sure is hacky
and not future-proof.


>> +/**
>> + * 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.
>> + * @dir: Specifies the type of Source and Destination.
>> + * @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.
> I thought you were going to remove this?
Yes, I just forgot.
--
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/