[PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

[PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

[Sven-Thorsten Dietrich]

Compile fix for new code in -rc2.

I'm not positive about the insertion point...

Subject: compile error fix (needs review)

RT changes __list_splice to require prev and next pointers. 

This changes the use in the new code to list_splice_tail, 
but the optimal insertion point needs to be analyzed.

Signed-off-by: Sven-Thorsten Dietrich <sdietrich@suse.de>

---
 drivers/dma/ioat_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23/drivers/dma/ioat_dma.c
===================================================================
--- linux-2.6.23.orig/drivers/dma/ioat_dma.c
+++ linux-2.6.23/drivers/dma/ioat_dma.c
@@ -244,7 +244,7 @@ static dma_cookie_t ioat_tx_submit(struc
 	/* write address into NextDescriptor field of last desc in chain */
 	to_ioat_desc(ioat_chan->used_desc.prev)->hw->next =
 							first->async_tx.phys;
-	__list_splice(&new_chain, ioat_chan->used_desc.prev);
+	list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
 
 	ioat_chan->pending += desc_count;
 	if (ioat_chan->pending >= 4) {

Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

[Nelson, Shannon]

On Nov 16, 2007 3:57 AM, Sven-Thorsten Dietrich <sdietrich@novell.com>
wrote:
> Compile fix for new code in -rc2.
> 
> I'm not positive about the insertion point...
> 
> Subject: compile error fix (needs review)
> 
> RT changes __list_splice to require prev and next pointers.
> 
> This changes the use in the new code to list_splice_tail,
> but the optimal insertion point needs to be analyzed.
> 
> Signed-off-by: Sven-Thorsten Dietrich <sdietrich@suse.de>
> 
> ---
>  drivers/dma/ioat_dma.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.23/drivers/dma/ioat_dma.c
> ===================================================================
> --- linux-2.6.23.orig/drivers/dma/ioat_dma.c
> +++ linux-2.6.23/drivers/dma/ioat_dma.c
> @@ -244,7 +244,7 @@ static dma_cookie_t ioat_tx_submit(struc
>         /* write address into NextDescriptor field of last desc in
chain */
>         to_ioat_desc(ioat_chan->used_desc.prev)->hw->next =
>
first->async_tx.phys;
> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
> 

NAK.

These functions do insertions differently.  The 'prev' is pointing to
the last valid descriptor in the queue and you really want to get the
new_chain stuck on after this.  Your list_splice_tail() will insert the
new_chain just before it which will muck up the order of the DMA
requests.

You might have more success with
	list_splice_tail(&new_chain, ioat_chan->used_desc);
where used_desc points to the whole list, rather than using the .prev
pointer to a specific node.

Please copy me on future ioatdma related comments.

Thanks,
sln
--
======================================================================
Mr. Shannon Nelson                 LAN Access Division, Intel Corp.
Shannon.Nelson@intel.com                I don't speak for Intel
(503) 712-7659                    Parents can't afford to be squeamish.

Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

[Steven Rostedt]

On Fri, 16 Nov 2007, Nelson, Shannon wrote:
> first->async_tx.phys;
> > -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
> > +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
> >
>
> NAK.
>
> These functions do insertions differently.  The 'prev' is pointing to
> the last valid descriptor in the queue and you really want to get the
> new_chain stuck on after this.  Your list_splice_tail() will insert the
> new_chain just before it which will muck up the order of the DMA
> requests.
>
> You might have more success with
> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
> where used_desc points to the whole list, rather than using the .prev
> pointer to a specific node.
>
> Please copy me on future ioatdma related comments.
>

And people wonder why we post RT related patches to LKML. This is exactly
why!

Thanks for the response Shannon!

-- Steve

Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

[trem]

Steven Rostedt wrote:
> On Fri, 16 Nov 2007, Nelson, Shannon wrote:
>> first->async_tx.phys;
>>> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
>>> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
>>>
>> NAK.
>>
>> These functions do insertions differently.  The 'prev' is pointing to
>> the last valid descriptor in the queue and you really want to get the
>> new_chain stuck on after this.  Your list_splice_tail() will insert the
>> new_chain just before it which will muck up the order of the DMA
>> requests.
>>
>> You might have more success with
>> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
>> where used_desc points to the whole list, rather than using the .prev
>> pointer to a specific node.
>>
>> Please copy me on future ioatdma related comments.
>>
> 
> And people wonder why we post RT related patches to LKML. This is exactly
> why!
> 
> Thanks for the response Shannon!
> 
> -- Steve
> 

Hi

I've tried this change, but it still don't compile. So I propose this patch.

regards,
trem

------------------------

Index: linux-2.6.23/drivers/dma/ioat_dma.c
===================================================================
--- linux-2.6.23.orig/drivers/dma/ioat_dma.c
+++ linux-2.6.23/drivers/dma/ioat_dma.c
@@ -244,7 +244,7 @@ static dma_cookie_t ioat_tx_submit(struc
        /* write address into NextDescriptor field of last desc in chain */
        to_ioat_desc(ioat_chan->used_desc.prev)->hw->next =
                                                        first->async_tx.phys;
-       __list_splice(&new_chain, ioat_chan->used_desc.prev);
+       list_splice_tail(&new_chain, &ioat_chan->used_desc);
 
        ioat_chan->pending += desc_count;
        if (ioat_chan->pending >= 4) {

[PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat_dma.c compile fix

[Sven-Thorsten Dietrich]

Hi Steve, 

looks like this patch didn't make it into 2.6.23-rc5-rt1.

I refreshed Trem's final version - please review and include in the next
RT release.

Thanks 

Sven 



On Tue, 2007-11-20 at 23:09 +0100, trem wrote:
> Steven Rostedt wrote:
> > On Fri, 16 Nov 2007, Nelson, Shannon wrote:
> >> first->async_tx.phys;
> >>> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
> >>> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
> >>>
> >> NAK.
> >>
> >> These functions do insertions differently.  The 'prev' is pointing
> to
> >> the last valid descriptor in the queue and you really want to get
> the
> >> new_chain stuck on after this.  Your list_splice_tail() will insert
> the
> >> new_chain just before it which will muck up the order of the DMA
> >> requests.
> >>
> >> You might have more success with
> >> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
> >> where used_desc points to the whole list, rather than using
> the .prev
> >> pointer to a specific node.
> >>
> >> Please copy me on future ioatdma related comments.
> >>
> > 

> Hi
> 
> I've tried this change, but it still don't compile. So I propose this patch.
> 
> regards,
> trem


From: trem <tremyfr@yahoo.fr>
Subject:  Re: [PATCH][RT] 2.6.24-rc2-rt1 drivers/dma/ioat_dma.c compile fix

Steven Rostedt wrote:
> On Fri, 16 Nov 2007, Nelson, Shannon wrote:
>> first->async_tx.phys;
>>> -       __list_splice(&new_chain, ioat_chan->used_desc.prev);
>>> +       list_splice_tail(&new_chain, ioat_chan->used_desc.prev);
>>>
>> NAK.
>>
>> These functions do insertions differently.  The 'prev' is pointing to
>> the last valid descriptor in the queue and you really want to get the
>> new_chain stuck on after this.  Your list_splice_tail() will insert the
>> new_chain just before it which will muck up the order of the DMA
>> requests.
>>
>> You might have more success with
>> 	list_splice_tail(&new_chain, ioat_chan->used_desc);
>> where used_desc points to the whole list, rather than using the .prev
>> pointer to a specific node.
>>
>> Please copy me on future ioatdma related comments.
>>
> 
> And people wonder why we post RT related patches to LKML. This is exactly
> why!
> 
> Thanks for the response Shannon!
> 
> -- Steve
> 

Hi

I've tried this change, but it still don't compile. So I propose this patch.

regards,
trem

Acked-by: Sven-Thorsten Dietrich <sdietrich@suse.de>

------------------------

---
 drivers/dma/ioat_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23/drivers/dma/ioat_dma.c
===================================================================
--- linux-2.6.23.orig/drivers/dma/ioat_dma.c
+++ linux-2.6.23/drivers/dma/ioat_dma.c
@@ -260,7 +260,7 @@ static dma_cookie_t ioat1_tx_submit(stru
 	/* write address into NextDescriptor field of last desc in chain */
 	to_ioat_desc(ioat_chan->used_desc.prev)->hw->next =
 							first->async_tx.phys;
-	__list_splice(&new_chain, ioat_chan->used_desc.prev);
+	list_splice(&new_chain, &ioat_chan->used_desc);
 
 	ioat_chan->dmacount += desc_count;
 	ioat_chan->pending += desc_count;

Re: [PATCH][RT] 2.6.24-rc5-rt1 drivers/dma/ioat_dma.c compile fix

[Steven Rostedt]

On Fri, 14 Dec 2007, Sven-Thorsten Dietrich wrote:

> Hi Steve,
>
> looks like this patch didn't make it into 2.6.23-rc5-rt1.
>
> I refreshed Trem's final version - please review and include in the next
> RT release.
>

Sven,

Thanks,  I'll take a look at it and if I don't find any issues I'll add it
to -rt2 (or rc6-rt1 which ever comes first).

-- Steve