arinov; Pierre Ossman
>Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface
>
>On Fri, 15 Feb 2008 09:12:35 -0800
>"Nelson, Shannon" <[EMAIL PROTECTED]> wrote:
>
>> I'll jump in here briefly - I'm okay with the direction this
>is going,
>
On Feb 18, 2008 6:22 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> On Sat, 16 Feb 2008 13:06:54 -0700
> "Dan Williams" <[EMAIL PROTECTED]> wrote:
>
> > I like the direction of the patch, i.e. splitting out separate
> > functionality into separate structs. However, I do not want to break
> >
On Fri, 15 Feb 2008 09:12:35 -0800
"Nelson, Shannon" <[EMAIL PROTECTED]> wrote:
> I'll jump in here briefly - I'm okay with the direction this is going,
> but I want to be protective of ioatdma performance. As used in struct
> ioat_desc_sw, the cookie and ack elements end up very close to the end
On Sat, 16 Feb 2008 13:06:54 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> I like the direction of the patch, i.e. splitting out separate
> functionality into separate structs. However, I do not want to break
> the model of clients sourcing the operations and drivers sinking them
> which dma_
On Feb 15, 2008 2:53 AM, Haavard Skinnemoen
<[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008 20:24:02 +0100
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> > But looking at your latest patch series, I guess we can use the new
> > "next" field instead. It's not like we really need the full
> > c
re Ossman
>Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface
>
>On Wed, 13 Feb 2008 20:24:02 +0100
>Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
>> But looking at your latest patch series, I guess we can use the new
>> "next" field inst
On Wed, 13 Feb 2008 20:24:02 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> But looking at your latest patch series, I guess we can use the new
> "next" field instead. It's not like we really need the full
> capabilities of list_head.
On second thought, if we do this, we would be using the
On Wed, 13 Feb 2008 12:07:26 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> > +struct dma_slave_descriptor {
> > + struct dma_async_tx_descriptor txd;
> > + struct list_head client_node;
> > +};
>
> Can you explain a bit why client_node is needed? I do not think we
> need dma_sl
On Feb 12, 2008 9:43 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
[..]
> /**
> + * struct dma_slave_descriptor - extended DMA descriptor for slave DMA
> + * @async_tx: async transaction descriptor
> + * @client_node: for use by the client, for example when operating on
> + * scatterlists.
On Wed, 13 Feb 2008 00:21:41 -0700
"Dan Williams" <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 9:43 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> [..]
> > +enum dma_slave_direction {
> > + DMA_SLAVE_TO_MEMORY,
> > + DMA_SLAVE_FROM_MEMORY,
> > +};
>
> Just reuse enum dma_data_dir
On Feb 12, 2008 9:43 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
[..]
> +enum dma_slave_direction {
> + DMA_SLAVE_TO_MEMORY,
> + DMA_SLAVE_FROM_MEMORY,
> +};
Just reuse enum dma_data_direction from the dma-mapping api.
--
Dan
--
To unsubscribe from this list: send the line "unsu
This patch adds the necessary interfaces to the DMA Engine framework
to use functionality found on most embedded DMA controllers: DMA from
and to I/O registers with hardware handshaking.
In this context, hardware hanshaking means that the peripheral that
owns the I/O registers in question is able
12 matches
Mail list logo
