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,
>> but I
: [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,
but I want to be protective of ioatdma performance. As used
in struct
ioat_desc_sw, the cookie
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
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
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
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
of a
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
the model of
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
> >
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
capabilities of
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 i
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
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 next
: [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 instead. It's not like we really need the full
capabilities of list_head.
On second
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
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
> + *
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
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_direction from the
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 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_slave_descriptor
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
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
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
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
24 matches
Mail list logo
