[PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Jürg Billeter]

If the atomic DMA coherent pool is too small, disable use of hardware
descriptor lists instead of crashing the system:

ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!

Unable to handle kernel NULL pointer dereference at virtual address 00000004
Internal error: Oops: a07 [#1] PREEMPT SMP ARM

PC is at rcar_dmac_chan_reinit+0x3c/0x160
LR is at _raw_spin_lock_irqsave+0x18/0x5c

[<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
[<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
[<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
[<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
[<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
[<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
[<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
[<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)

Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Jürg Billeter <j@bitron.ch>
---
 drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index f8f70eb..f18b1b6 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
 	desc->hwdescs.size = size;
 }
 
-static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
-				  struct rcar_dmac_desc *desc)
+static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
+				 struct rcar_dmac_desc *desc)
 {
 	struct rcar_dmac_xfer_chunk *chunk;
 	struct rcar_dmac_hw_desc *hwdesc;
@@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
 
 	hwdesc = desc->hwdescs.mem;
 	if (!hwdesc)
-		return;
+		return -ENOMEM;
 
 	list_for_each_entry(chunk, &desc->chunks, node) {
 		hwdesc->sar = chunk->src_addr;
@@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
 		hwdesc->tcr = chunk->size >> desc->xfer_shift;
 		hwdesc++;
 	}
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------------
@@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
 	 * additional complexity remains to be investigated.
 	 */
 	desc->hwdescs.use = !highmem && nchunks > 1;
-	if (desc->hwdescs.use)
-		rcar_dmac_fill_hwdesc(chan, desc);
+	if (desc->hwdescs.use) {
+		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
+			desc->hwdescs.use = false;
+	}
 
 	return &desc->async_tx;
 }
-- 
2.1.3

[PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Jürg Billeter]

If the atomic DMA coherent pool is too small, disable use of hardware
descriptor lists instead of crashing the system:

ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!

Unable to handle kernel NULL pointer dereference at virtual address 00000004
Internal error: Oops: a07 [#1] PREEMPT SMP ARM

PC is at rcar_dmac_chan_reinit+0x3c/0x160
LR is at _raw_spin_lock_irqsave+0x18/0x5c

[<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
[<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
[<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
[<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
[<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
[<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
[<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
[<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)

Kernel panic - not syncing: Fatal exception in interrupt

Signed-off-by: Jürg Billeter <j@bitron.ch>
---
 drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index f8f70eb..f18b1b6 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
 	desc->hwdescs.size = size;
 }
 
-static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
-				  struct rcar_dmac_desc *desc)
+static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
+				 struct rcar_dmac_desc *desc)
 {
 	struct rcar_dmac_xfer_chunk *chunk;
 	struct rcar_dmac_hw_desc *hwdesc;
@@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
 
 	hwdesc = desc->hwdescs.mem;
 	if (!hwdesc)
-		return;
+		return -ENOMEM;
 
 	list_for_each_entry(chunk, &desc->chunks, node) {
 		hwdesc->sar = chunk->src_addr;
@@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
 		hwdesc->tcr = chunk->size >> desc->xfer_shift;
 		hwdesc++;
 	}
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------------
@@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
 	 * additional complexity remains to be investigated.
 	 */
 	desc->hwdescs.use = !highmem && nchunks > 1;
-	if (desc->hwdescs.use)
-		rcar_dmac_fill_hwdesc(chan, desc);
+	if (desc->hwdescs.use) {
+		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
+			desc->hwdescs.use = false;
+	}
 
 	return &desc->async_tx;
 }
-- 
2.1.3

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Jürg,

Thank you for the patch.

On Tuesday 25 November 2014 15:10:17 Jürg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
> 
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
> 
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
> 
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>]
> (rcar_dmac_isr_error+0x84/0xa0) [<80214818>] (rcar_dmac_isr_error) from
> [<80060484>] (handle_irq_event_percpu+0x50/0x150) [<80060484>]
> (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>]
> (handle_fasteoi_irq+0xb8/0x198) [<8006350c>] (handle_fasteoi_irq) from
> [<8005fdb0>] (generic_handle_irq+0x20/0x30) [<8005fdb0>]
> (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4) [<8000fcd0>]
> (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c) [<800092cc>]
> (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
> 
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> Signed-off-by: Jürg Billeter <j@bitron.ch>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

and applied to my tree.

> ---
>  drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct
> rcar_dmac_chan *chan, desc->hwdescs.size = size;
>  }
> 
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> -				  struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> +				 struct rcar_dmac_desc *desc)
>  {
>  	struct rcar_dmac_xfer_chunk *chunk;
>  	struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan,
> 
>  	hwdesc = desc->hwdescs.mem;
>  	if (!hwdesc)
> -		return;
> +		return -ENOMEM;
> 
>  	list_for_each_entry(chunk, &desc->chunks, node) {
>  		hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan, hwdesc->tcr = chunk->size >> desc->xfer_shift;
>  		hwdesc++;
>  	}
> +
> +	return 0;
>  }
> 
>  /* ------------------------------------------------------------------------
>  @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan,
> struct scatterlist *sgl, * additional complexity remains to be
> investigated.
>  	 */
>  	desc->hwdescs.use = !highmem && nchunks > 1;
> -	if (desc->hwdescs.use)
> -		rcar_dmac_fill_hwdesc(chan, desc);
> +	if (desc->hwdescs.use) {
> +		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> +			desc->hwdescs.use = false;
> +	}
> 
>  	return &desc->async_tx;
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Jürg,

Thank you for the patch.

On Tuesday 25 November 2014 15:10:17 Jürg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
> 
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
> 
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
> 
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>]
> (rcar_dmac_isr_error+0x84/0xa0) [<80214818>] (rcar_dmac_isr_error) from
> [<80060484>] (handle_irq_event_percpu+0x50/0x150) [<80060484>]
> (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>]
> (handle_fasteoi_irq+0xb8/0x198) [<8006350c>] (handle_fasteoi_irq) from
> [<8005fdb0>] (generic_handle_irq+0x20/0x30) [<8005fdb0>]
> (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4) [<8000fcd0>]
> (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c) [<800092cc>]
> (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
> 
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> Signed-off-by: Jürg Billeter <j@bitron.ch>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

and applied to my tree.

> ---
>  drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct
> rcar_dmac_chan *chan, desc->hwdescs.size = size;
>  }
> 
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> -				  struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> +				 struct rcar_dmac_desc *desc)
>  {
>  	struct rcar_dmac_xfer_chunk *chunk;
>  	struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan,
> 
>  	hwdesc = desc->hwdescs.mem;
>  	if (!hwdesc)
> -		return;
> +		return -ENOMEM;
> 
>  	list_for_each_entry(chunk, &desc->chunks, node) {
>  		hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan
> *chan, hwdesc->tcr = chunk->size >> desc->xfer_shift;
>  		hwdesc++;
>  	}
> +
> +	return 0;
>  }
> 
>  /* ------------------------------------------------------------------------
>  @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan,
> struct scatterlist *sgl, * additional complexity remains to be
> investigated.
>  	 */
>  	desc->hwdescs.use = !highmem && nchunks > 1;
> -	if (desc->hwdescs.use)
> -		rcar_dmac_fill_hwdesc(chan, desc);
> +	if (desc->hwdescs.use) {
> +		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> +			desc->hwdescs.use = false;
> +	}
> 
>  	return &desc->async_tx;
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Tue, Nov 25, 2014 at 03:10:17PM +0100, Jürg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
> 
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
> 
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
> 
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
> [<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
> [<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
> [<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
> [<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
> [<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
> [<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
> 
> Kernel panic - not syncing: Fatal exception in interrupt

Can you please rebase this on my next, this fails to apply for me

Thanks
-- 
~Vinod
> 
> Signed-off-by: Jürg Billeter <j@bitron.ch>
> ---
>  drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
>  	desc->hwdescs.size = size;
>  }
>  
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> -				  struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> +				 struct rcar_dmac_desc *desc)
>  {
>  	struct rcar_dmac_xfer_chunk *chunk;
>  	struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>  
>  	hwdesc = desc->hwdescs.mem;
>  	if (!hwdesc)
> -		return;
> +		return -ENOMEM;
>  
>  	list_for_each_entry(chunk, &desc->chunks, node) {
>  		hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>  		hwdesc->tcr = chunk->size >> desc->xfer_shift;
>  		hwdesc++;
>  	}
> +
> +	return 0;
>  }
>  
>  /* -----------------------------------------------------------------------------
> @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
>  	 * additional complexity remains to be investigated.
>  	 */
>  	desc->hwdescs.use = !highmem && nchunks > 1;
> -	if (desc->hwdescs.use)
> -		rcar_dmac_fill_hwdesc(chan, desc);
> +	if (desc->hwdescs.use) {
> +		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> +			desc->hwdescs.use = false;
> +	}
>  
>  	return &desc->async_tx;
>  }
> -- 
> 2.1.3
> 

-- 

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Tue, Nov 25, 2014 at 03:10:17PM +0100, Jürg Billeter wrote:
> If the atomic DMA coherent pool is too small, disable use of hardware
> descriptor lists instead of crashing the system:
> 
> ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> Internal error: Oops: a07 [#1] PREEMPT SMP ARM
> 
> PC is at rcar_dmac_chan_reinit+0x3c/0x160
> LR is at _raw_spin_lock_irqsave+0x18/0x5c
> 
> [<802132c0>] (rcar_dmac_chan_reinit) from [<80214818>] (rcar_dmac_isr_error+0x84/0xa0)
> [<80214818>] (rcar_dmac_isr_error) from [<80060484>] (handle_irq_event_percpu+0x50/0x150)
> [<80060484>] (handle_irq_event_percpu) from [<800605c0>] (handle_irq_event+0x3c/0x5c)
> [<800605c0>] (handle_irq_event) from [<8006350c>] (handle_fasteoi_irq+0xb8/0x198)
> [<8006350c>] (handle_fasteoi_irq) from [<8005fdb0>] (generic_handle_irq+0x20/0x30)
> [<8005fdb0>] (generic_handle_irq) from [<8000fcd0>] (handle_IRQ+0x50/0xc4)
> [<8000fcd0>] (handle_IRQ) from [<800092cc>] (gic_handle_irq+0x28/0x5c)
> [<800092cc>] (gic_handle_irq) from [<80012700>] (__irq_svc+0x40/0x70)
> 
> Kernel panic - not syncing: Fatal exception in interrupt

Can you please rebase this on my next, this fails to apply for me

Thanks
-- 
~Vinod
> 
> Signed-off-by: Jürg Billeter <j@bitron.ch>
> ---
>  drivers/dma/sh/rcar-dmac.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index f8f70eb..f18b1b6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -679,8 +679,8 @@ static void rcar_dmac_realloc_hwdesc(struct rcar_dmac_chan *chan,
>  	desc->hwdescs.size = size;
>  }
>  
> -static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> -				  struct rcar_dmac_desc *desc)
> +static int rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
> +				 struct rcar_dmac_desc *desc)
>  {
>  	struct rcar_dmac_xfer_chunk *chunk;
>  	struct rcar_dmac_hw_desc *hwdesc;
> @@ -689,7 +689,7 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>  
>  	hwdesc = desc->hwdescs.mem;
>  	if (!hwdesc)
> -		return;
> +		return -ENOMEM;
>  
>  	list_for_each_entry(chunk, &desc->chunks, node) {
>  		hwdesc->sar = chunk->src_addr;
> @@ -697,6 +697,8 @@ static void rcar_dmac_fill_hwdesc(struct rcar_dmac_chan *chan,
>  		hwdesc->tcr = chunk->size >> desc->xfer_shift;
>  		hwdesc++;
>  	}
> +
> +	return 0;
>  }
>  
>  /* -----------------------------------------------------------------------------
> @@ -933,8 +935,10 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_chan *chan, struct scatterlist *sgl,
>  	 * additional complexity remains to be investigated.
>  	 */
>  	desc->hwdescs.use = !highmem && nchunks > 1;
> -	if (desc->hwdescs.use)
> -		rcar_dmac_fill_hwdesc(chan, desc);
> +	if (desc->hwdescs.use) {
> +		if (rcar_dmac_fill_hwdesc(chan, desc) < 0)
> +			desc->hwdescs.use = false;
> +	}
>  
>  	return &desc->async_tx;
>  }
> -- 
> 2.1.3
> 

-- 

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Jürg Billeter]

Hi Vinod,

On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> Can you please rebase this on my next, this fails to apply for me

This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
to be in your next yet. Laurent has already merged my patch into his
dma/next branch and included it in his pull request from November 27.

[GIT PULL FOR v3.19] R-Car DMA engine driver
http://www.spinics.net/lists/linux-sh/msg37764.html

Please let me know if there is still a rebase required from my side.

Regards,
Jürg

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Jürg Billeter]

Hi Vinod,

On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> Can you please rebase this on my next, this fails to apply for me

This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
to be in your next yet. Laurent has already merged my patch into his
dma/next branch and included it in his pull request from November 27.

[GIT PULL FOR v3.19] R-Car DMA engine driver
http://www.spinics.net/lists/linux-sh/msg37764.html

Please let me know if there is still a rebase required from my side.

Regards,
Jürg

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> Hi Vinod,
> 
> On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > Can you please rebase this on my next, this fails to apply for me
> 
> This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> to be in your next yet. Laurent has already merged my patch into his
> dma/next branch and included it in his pull request from November 27.
> 
> [GIT PULL FOR v3.19] R-Car DMA engine driver
> http://www.spinics.net/lists/linux-sh/msg37764.html
And I dont seem to have this request in my Inbox :(
Yes I do see it in archieves, so not sure how this is not present, not sure
if the servers mangeled it!!

I will pull this tomorrow...

> Please let me know if there is still a rebase required from my side.
Nope

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> Hi Vinod,
> 
> On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > Can you please rebase this on my next, this fails to apply for me
> 
> This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> to be in your next yet. Laurent has already merged my patch into his
> dma/next branch and included it in his pull request from November 27.
> 
> [GIT PULL FOR v3.19] R-Car DMA engine driver
> http://www.spinics.net/lists/linux-sh/msg37764.html
And I dont seem to have this request in my Inbox :(
Yes I do see it in archieves, so not sure how this is not present, not sure
if the servers mangeled it!!

I will pull this tomorrow...

> Please let me know if there is still a rebase required from my side.
Nope

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > Hi Vinod,
> > 
> > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > Can you please rebase this on my next, this fails to apply for me
> > 
> > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > to be in your next yet. Laurent has already merged my patch into his
> > dma/next branch and included it in his pull request from November 27.
> > 
> > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > http://www.spinics.net/lists/linux-sh/msg37764.html
> 
> And I dont seem to have this request in my Inbox :(
> Yes I do see it in archieves, so not sure how this is not present, not sure
> if the servers mangeled it!!

I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
have reached you through the mailing list though (I assume you're subscribed 
to dmaengine@vger.kernel.org ;-)).

> I will pull this tomorrow...

Thank you.

> > Please let me know if there is still a rebase required from my side.
> 
> Nope

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > Hi Vinod,
> > 
> > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > Can you please rebase this on my next, this fails to apply for me
> > 
> > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > to be in your next yet. Laurent has already merged my patch into his
> > dma/next branch and included it in his pull request from November 27.
> > 
> > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > http://www.spinics.net/lists/linux-sh/msg37764.html
> 
> And I dont seem to have this request in my Inbox :(
> Yes I do see it in archieves, so not sure how this is not present, not sure
> if the servers mangeled it!!

I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
have reached you through the mailing list though (I assume you're subscribed 
to dmaengine@vger.kernel.org ;-)).

> I will pull this tomorrow...

Thank you.

> > Please let me know if there is still a rebase required from my side.
> 
> Nope

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > > Hi Vinod,
> > > 
> > > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > > Can you please rebase this on my next, this fails to apply for me
> > > 
> > > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > > to be in your next yet. Laurent has already merged my patch into his
> > > dma/next branch and included it in his pull request from November 27.
> > > 
> > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > 
> > And I dont seem to have this request in my Inbox :(
> > Yes I do see it in archieves, so not sure how this is not present, not sure
> > if the servers mangeled it!!
> 
> I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
> have reached you through the mailing list though (I assume you're subscribed 
> to dmaengine@vger.kernel.org ;-)).
Yes I am, so should have reached me even though i wasnt cced
I do see email reaching me from list without me being in CC, but then it
wont hit my inbox and go to ML folder :)
So generally its a good practice to CC relvant folks, lots of folks do ask
that if ML is high volume

Hopefully the Intel servers are playing nice with vger, that is my bigger
worry here.

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > > Hi Vinod,
> > > 
> > > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > > Can you please rebase this on my next, this fails to apply for me
> > > 
> > > This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> > > to be in your next yet. Laurent has already merged my patch into his
> > > dma/next branch and included it in his pull request from November 27.
> > > 
> > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > 
> > And I dont seem to have this request in my Inbox :(
> > Yes I do see it in archieves, so not sure how this is not present, not sure
> > if the servers mangeled it!!
> 
> I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
> have reached you through the mailing list though (I assume you're subscribed 
> to dmaengine@vger.kernel.org ;-)).
Yes I am, so should have reached me even though i wasnt cced
I do see email reaching me from list without me being in CC, but then it
wont hit my inbox and go to ML folder :)
So generally its a good practice to CC relvant folks, lots of folks do ask
that if ML is high volume

Hopefully the Intel servers are playing nice with vger, that is my bigger
worry here.

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > 
> > > And I dont seem to have this request in my Inbox :(
> > > Yes I do see it in archieves, so not sure how this is not present, not sure
> > > if the servers mangeled it!!
> > 
> > I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
> > have reached you through the mailing list though (I assume you're subscribed 
> > to dmaengine@vger.kernel.org ;-)).
> Yes I am, so should have reached me even though i wasnt cced
> I do see email reaching me from list without me being in CC, but then it
> wont hit my inbox and go to ML folder :)
> So generally its a good practice to CC relvant folks, lots of folks do ask
> that if ML is high volume

Hey Laurent,

I see that the oddity in commitlogs with change since artifacts after SOB,
can you please fix that up

	commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	Date:   Sat Jul 19 00:05:14 2014 +0200

	    dmaengine: rcar-dmac: Cache hardware descriptors memory

	    Unlike DMA transfers descriptors that are preallocated and cached,
	    memory used to store hardware descriptors is allocated and freed with
	    the DMA coherent allocation API for every transfer. Besides degrading
	    performances, this creates a CMA stress test that seems to cause issues.
	    Running dmatest with the noverify option produces

	    [   50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
	    [   50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e) failed
	    [   52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848) failed
	    [   54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
	    [   56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850) failed

	    The root cause needs to be fixed, but in the meantime, as a workaround
	    and a performance improvement, cache hardware descriptors.

	    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

	    ---

	    Changes since v2:

	    - Typo fixes
	    - Align allocated hwdesc size to page size
	    - Ignore allocated hwdesc memory when the transfer doesn't use hwdescs

	commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	Date:   Wed Jul 16 23:15:48 2014 +0200

	    dmaengine: rcar-dmac: Implement support for hardware descriptor lists

	    The DMAC supports hardware-based auto-configuration from descriptor
	    lists. This reduces the number of interrupts required for processing a
	    DMA transfer. Support that mode in the driver.

	    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

	    ---

	    Changes since v2:

	    - Typo fixes
	    - Use GFP_NOWAIT to allocate hardware descriptors
	    - Clear descriptor stage end interrupt when halting the channel

and many more...

Thanks
-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > 
> > > And I dont seem to have this request in my Inbox :(
> > > Yes I do see it in archieves, so not sure how this is not present, not sure
> > > if the servers mangeled it!!
> > 
> > I haven't CC'ed you, I'll make sure to do so next time. The mail should still 
> > have reached you through the mailing list though (I assume you're subscribed 
> > to dmaengine@vger.kernel.org ;-)).
> Yes I am, so should have reached me even though i wasnt cced
> I do see email reaching me from list without me being in CC, but then it
> wont hit my inbox and go to ML folder :)
> So generally its a good practice to CC relvant folks, lots of folks do ask
> that if ML is high volume

Hey Laurent,

I see that the oddity in commitlogs with change since artifacts after SOB,
can you please fix that up

	commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	Date:   Sat Jul 19 00:05:14 2014 +0200

	    dmaengine: rcar-dmac: Cache hardware descriptors memory

	    Unlike DMA transfers descriptors that are preallocated and cached,
	    memory used to store hardware descriptors is allocated and freed with
	    the DMA coherent allocation API for every transfer. Besides degrading
	    performances, this creates a CMA stress test that seems to cause issues.
	    Running dmatest with the noverify option produces

	    [   50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
	    [   50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e) failed
	    [   52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848) failed
	    [   54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
	    [   56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850) failed

	    The root cause needs to be fixed, but in the meantime, as a workaround
	    and a performance improvement, cache hardware descriptors.

	    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

	    ---

	    Changes since v2:

	    - Typo fixes
	    - Align allocated hwdesc size to page size
	    - Ignore allocated hwdesc memory when the transfer doesn't use hwdescs

	commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	Date:   Wed Jul 16 23:15:48 2014 +0200

	    dmaengine: rcar-dmac: Implement support for hardware descriptor lists

	    The DMAC supports hardware-based auto-configuration from descriptor
	    lists. This reduces the number of interrupts required for processing a
	    DMA transfer. Support that mode in the driver.

	    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
	    Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

	    ---

	    Changes since v2:

	    - Typo fixes
	    - Use GFP_NOWAIT to allocate hardware descriptors
	    - Clear descriptor stage end interrupt when halting the channel

and many more...

Thanks
-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Tuesday 09 December 2014 12:09:12 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > 
> > > > And I dont seem to have this request in my Inbox :(
> > > > Yes I do see it in archieves, so not sure how this is not present, not
> > > > sure if the servers mangeled it!!
> > > 
> > > I haven't CC'ed you, I'll make sure to do so next time. The mail should
> > > still have reached you through the mailing list though (I assume you're
> > > subscribed to dmaengine@vger.kernel.org ;-)).
> > 
> > Yes I am, so should have reached me even though i wasnt cced
> > I do see email reaching me from list without me being in CC, but then it
> > wont hit my inbox and go to ML folder :)
> > So generally its a good practice to CC relvant folks, lots of folks do ask
> > that if ML is high volume
> 
> Hey Laurent,
> 
> I see that the oddity in commitlogs with change since artifacts after SOB,
> can you please fix that up

My bad. I've fixed the problem and pushed the result to the same branch

	git://linuxtv.org/pinchartl/fbdev.git dma/next

The only difference lies in the commit logs.

> 	commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
> 	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 	Date:   Sat Jul 19 00:05:14 2014 +0200
> 
> 	    dmaengine: rcar-dmac: Cache hardware descriptors memory
> 
> 	    Unlike DMA transfers descriptors that are preallocated and cached,
> 	    memory used to store hardware descriptors is allocated and freed with
> 	    the DMA coherent allocation API for every transfer. Besides degrading
> 	    performances, this creates a CMA stress test that seems to cause
> issues. Running dmatest with the noverify option produces
> 
> 	    [   50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846)
> failed [   50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e)
> failed [   52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848)
> failed [   54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844)
> failed [   56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850)
> failed
> 
> 	    The root cause needs to be fixed, but in the meantime, as a 
workaround
> 	    and a performance improvement, cache hardware descriptors.
> 
> 	    Signed-off-by: Laurent Pinchart
> <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Wolfram Sang
> <wsa+renesas@sang-engineering.com>
> 
> 	    ---
> 
> 	    Changes since v2:
> 
> 	    - Typo fixes
> 	    - Align allocated hwdesc size to page size
> 	    - Ignore allocated hwdesc memory when the transfer doesn't use 
hwdescs
> 
> 	commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
> 	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 	Date:   Wed Jul 16 23:15:48 2014 +0200
> 
> 	    dmaengine: rcar-dmac: Implement support for hardware descriptor lists
> 
> 	    The DMAC supports hardware-based auto-configuration from descriptor
> 	    lists. This reduces the number of interrupts required for processing 
a
> 	    DMA transfer. Support that mode in the driver.
> 
> 	    Signed-off-by: Laurent Pinchart
> <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Wolfram Sang
> <wsa+renesas@sang-engineering.com>
> 
> 	    ---
> 
> 	    Changes since v2:
> 
> 	    - Typo fixes
> 	    - Use GFP_NOWAIT to allocate hardware descriptors
> 	    - Clear descriptor stage end interrupt when halting the channel
> 
> and many more...

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Tuesday 09 December 2014 12:09:12 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > 
> > > > And I dont seem to have this request in my Inbox :(
> > > > Yes I do see it in archieves, so not sure how this is not present, not
> > > > sure if the servers mangeled it!!
> > > 
> > > I haven't CC'ed you, I'll make sure to do so next time. The mail should
> > > still have reached you through the mailing list though (I assume you're
> > > subscribed to dmaengine@vger.kernel.org ;-)).
> > 
> > Yes I am, so should have reached me even though i wasnt cced
> > I do see email reaching me from list without me being in CC, but then it
> > wont hit my inbox and go to ML folder :)
> > So generally its a good practice to CC relvant folks, lots of folks do ask
> > that if ML is high volume
> 
> Hey Laurent,
> 
> I see that the oddity in commitlogs with change since artifacts after SOB,
> can you please fix that up

My bad. I've fixed the problem and pushed the result to the same branch

	git://linuxtv.org/pinchartl/fbdev.git dma/next

The only difference lies in the commit logs.

> 	commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
> 	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 	Date:   Sat Jul 19 00:05:14 2014 +0200
> 
> 	    dmaengine: rcar-dmac: Cache hardware descriptors memory
> 
> 	    Unlike DMA transfers descriptors that are preallocated and cached,
> 	    memory used to store hardware descriptors is allocated and freed with
> 	    the DMA coherent allocation API for every transfer. Besides degrading
> 	    performances, this creates a CMA stress test that seems to cause
> issues. Running dmatest with the noverify option produces
> 
> 	    [   50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846)
> failed [   50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e)
> failed [   52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848)
> failed [   54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844)
> failed [   56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850)
> failed
> 
> 	    The root cause needs to be fixed, but in the meantime, as a 
workaround
> 	    and a performance improvement, cache hardware descriptors.
> 
> 	    Signed-off-by: Laurent Pinchart
> <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Wolfram Sang
> <wsa+renesas@sang-engineering.com>
> 
> 	    ---
> 
> 	    Changes since v2:
> 
> 	    - Typo fixes
> 	    - Align allocated hwdesc size to page size
> 	    - Ignore allocated hwdesc memory when the transfer doesn't use 
hwdescs
> 
> 	commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
> 	Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 	Date:   Wed Jul 16 23:15:48 2014 +0200
> 
> 	    dmaengine: rcar-dmac: Implement support for hardware descriptor lists
> 
> 	    The DMAC supports hardware-based auto-configuration from descriptor
> 	    lists. This reduces the number of interrupts required for processing 
a
> 	    DMA transfer. Support that mode in the driver.
> 
> 	    Signed-off-by: Laurent Pinchart
> <laurent.pinchart+renesas@ideasonboard.com> Tested-by: Wolfram Sang
> <wsa+renesas@sang-engineering.com>
> 
> 	    ---
> 
> 	    Changes since v2:
> 
> 	    - Typo fixes
> 	    - Use GFP_NOWAIT to allocate hardware descriptors
> 	    - Clear descriptor stage end interrupt when halting the channel
> 
> and many more...

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Kuninori Morimoto]

Hi Laurent

> > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > > 
> > > > > And I dont seem to have this request in my Inbox :(
> > > > > Yes I do see it in archieves, so not sure how this is not present, not
> > > > > sure if the servers mangeled it!!
> > > > 
> > > > I haven't CC'ed you, I'll make sure to do so next time. The mail should
> > > > still have reached you through the mailing list though (I assume you're
> > > > subscribed to dmaengine@vger.kernel.org ;-)).
> > > 
> > > Yes I am, so should have reached me even though i wasnt cced
> > > I do see email reaching me from list without me being in CC, but then it
> > > wont hit my inbox and go to ML folder :)
> > > So generally its a good practice to CC relvant folks, lots of folks do ask
> > > that if ML is high volume
> > 
> > Hey Laurent,
> > 
> > I see that the oddity in commitlogs with change since artifacts after SOB,
> > can you please fix that up
> 
> My bad. I've fixed the problem and pushed the result to the same branch
> 
> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> 
> The only difference lies in the commit logs.

If my understanding was correct, we need to be based on Vinod's
topic/slave_caps_device_control_fix

Best regards
---
Kuninori Morimoto

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

(Resend, as the message doesn't seem to have made it to the mailing lists)

On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > >>> 
> > > >>> And I dont seem to have this request in my Inbox :(
> > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > >>> not sure if the servers mangeled it!!
> > > >> 
> > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > >> should still have reached you through the mailing list though (I
> > > >> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > > > 
> > > > Yes I am, so should have reached me even though i wasnt cced
> > > > I do see email reaching me from list without me being in CC, but then
> > > > it wont hit my inbox and go to ML folder :)
> > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > ask that if ML is high volume
> > > 
> > > Hey Laurent,
> > > 
> > > I see that the oddity in commitlogs with change since artifacts after
> > > SOB, can you please fix that up
> > 
> > My bad. I've fixed the problem and pushed the result to the same branch
> > 
> > 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > 
> > The only difference lies in the commit logs.
> 
> If my understanding was correct, we need to be based on Vinod's
> topic/slave_caps_device_control_fix

Vinod, could you please comment on that ? To which kernel version do you plan 
to push this series ? Do I need to rebase it ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

(Resend, as the message doesn't seem to have made it to the mailing lists)

On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > >>> 
> > > >>> And I dont seem to have this request in my Inbox :(
> > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > >>> not sure if the servers mangeled it!!
> > > >> 
> > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > >> should still have reached you through the mailing list though (I
> > > >> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > > > 
> > > > Yes I am, so should have reached me even though i wasnt cced
> > > > I do see email reaching me from list without me being in CC, but then
> > > > it wont hit my inbox and go to ML folder :)
> > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > ask that if ML is high volume
> > > 
> > > Hey Laurent,
> > > 
> > > I see that the oddity in commitlogs with change since artifacts after
> > > SOB, can you please fix that up
> > 
> > My bad. I've fixed the problem and pushed the result to the same branch
> > 
> > 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > 
> > The only difference lies in the commit logs.
> 
> If my understanding was correct, we need to be based on Vinod's
> topic/slave_caps_device_control_fix

Vinod, could you please comment on that ? To which kernel version do you plan 
to push this series ? Do I need to rebase it ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> (Resend, as the message doesn't seem to have made it to the mailing lists)
> 
> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > >>> 
> > > > >>> And I dont seem to have this request in my Inbox :(
> > > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > > >>> not sure if the servers mangeled it!!
> > > > >> 
> > > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > > >> should still have reached you through the mailing list though (I
> > > > >> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > > > > 
> > > > > Yes I am, so should have reached me even though i wasnt cced
> > > > > I do see email reaching me from list without me being in CC, but then
> > > > > it wont hit my inbox and go to ML folder :)
> > > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > > ask that if ML is high volume
> > > > 
> > > > Hey Laurent,
> > > > 
> > > > I see that the oddity in commitlogs with change since artifacts after
> > > > SOB, can you please fix that up
> > > 
> > > My bad. I've fixed the problem and pushed the result to the same branch
> > > 
> > > 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > > 
> > > The only difference lies in the commit logs.
> > 
> > If my understanding was correct, we need to be based on Vinod's
> > topic/slave_caps_device_control_fix
> 
> Vinod, could you please comment on that ? To which kernel version do you plan 
> to push this series ? Do I need to rebase it ?
Hi Laurent,

I did a quick at the series, looks fine mostly. I have already sent by pull
request to linus earlier last week and its merged, so we need to merge it
for next one. So yes we need to fix and test this for caps and control API
fix. Can you do that and I will pull and put in my next for 3.20

One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
you please explain a bit more on it, why do you need to modify addresses
based on config option?

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> (Resend, as the message doesn't seem to have made it to the mailing lists)
> 
> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > >>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > >>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > > > >>> 
> > > > >>> And I dont seem to have this request in my Inbox :(
> > > > >>> Yes I do see it in archieves, so not sure how this is not present,
> > > > >>> not sure if the servers mangeled it!!
> > > > >> 
> > > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > > > >> should still have reached you through the mailing list though (I
> > > > >> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > > > > 
> > > > > Yes I am, so should have reached me even though i wasnt cced
> > > > > I do see email reaching me from list without me being in CC, but then
> > > > > it wont hit my inbox and go to ML folder :)
> > > > > So generally its a good practice to CC relvant folks, lots of folks do
> > > > > ask that if ML is high volume
> > > > 
> > > > Hey Laurent,
> > > > 
> > > > I see that the oddity in commitlogs with change since artifacts after
> > > > SOB, can you please fix that up
> > > 
> > > My bad. I've fixed the problem and pushed the result to the same branch
> > > 
> > > 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > > 
> > > The only difference lies in the commit logs.
> > 
> > If my understanding was correct, we need to be based on Vinod's
> > topic/slave_caps_device_control_fix
> 
> Vinod, could you please comment on that ? To which kernel version do you plan 
> to push this series ? Do I need to rebase it ?
Hi Laurent,

I did a quick at the series, looks fine mostly. I have already sent by pull
request to linus earlier last week and its merged, so we need to merge it
for next one. So yes we need to fix and test this for caps and control API
fix. Can you do that and I will pull and put in my next for 3.20

One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
you please explain a bit more on it, why do you need to modify addresses
based on config option?

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>> 
> >>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>> present, not sure if the servers mangeled it!!
> >>>>>> 
> >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>> should still have reached you through the mailing list though (I
> >>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> >>>>> 
> >>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>> I do see email reaching me from list without me being in CC, but
> >>>>> then it wont hit my inbox and go to ML folder :)
> >>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>> folks do ask that if ML is high volume
> >>>> 
> >>>> Hey Laurent,
> >>>> 
> >>>> I see that the oddity in commitlogs with change since artifacts
> >>>> after SOB, can you please fix that up
> >>> 
> >>> My bad. I've fixed the problem and pushed the result to the same
> >>> branch
> >>> 
> >>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>> 
> >>> The only difference lies in the commit logs.
> >> 
> >> If my understanding was correct, we need to be based on Vinod's
> >> topic/slave_caps_device_control_fix
> > 
> > Vinod, could you please comment on that ? To which kernel version do you
> > plan to push this series ? Do I need to rebase it ?
> 
> Hi Laurent,
> 
> I did a quick at the series, looks fine mostly. I have already sent by pull
> request to linus earlier last week and its merged, so we need to merge it
> for next one. So yes we need to fix and test this for caps and control API
> fix. Can you do that and I will pull and put in my next for 3.20

That's very annoying given that I have users waiting for the driver to be 
merged, and that I've sent the pull request two weeks and a half ago.

I suppose I have no choice anyway. Please provide me with a v3.20 development 
branch on which I can rebase the patch set, I don't want to rebase it twice.

> One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> you please explain a bit more on it, why do you need to modify addresses
> based on config option?

Because there's no need to write the upper bits (above 32) of the DMA 
addresses when the DMA address spans 32 bits only, and because there's no need 
to check for transfers that cross a 4GB boundary (that's a hardware 
limitation) when the DMA address space is 4GB in total.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>> 
> >>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>> present, not sure if the servers mangeled it!!
> >>>>>> 
> >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>> should still have reached you through the mailing list though (I
> >>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> >>>>> 
> >>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>> I do see email reaching me from list without me being in CC, but
> >>>>> then it wont hit my inbox and go to ML folder :)
> >>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>> folks do ask that if ML is high volume
> >>>> 
> >>>> Hey Laurent,
> >>>> 
> >>>> I see that the oddity in commitlogs with change since artifacts
> >>>> after SOB, can you please fix that up
> >>> 
> >>> My bad. I've fixed the problem and pushed the result to the same
> >>> branch
> >>> 
> >>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>> 
> >>> The only difference lies in the commit logs.
> >> 
> >> If my understanding was correct, we need to be based on Vinod's
> >> topic/slave_caps_device_control_fix
> > 
> > Vinod, could you please comment on that ? To which kernel version do you
> > plan to push this series ? Do I need to rebase it ?
> 
> Hi Laurent,
> 
> I did a quick at the series, looks fine mostly. I have already sent by pull
> request to linus earlier last week and its merged, so we need to merge it
> for next one. So yes we need to fix and test this for caps and control API
> fix. Can you do that and I will pull and put in my next for 3.20

That's very annoying given that I have users waiting for the driver to be 
merged, and that I've sent the pull request two weeks and a half ago.

I suppose I have no choice anyway. Please provide me with a v3.20 development 
branch on which I can rebase the patch set, I don't want to rebase it twice.

> One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> you please explain a bit more on it, why do you need to modify addresses
> based on config option?

Because there's no need to write the upper bits (above 32) of the DMA 
addresses when the DMA address spans 32 bits only, and because there's no need 
to check for transfers that cross a 4GB boundary (that's a hardware 
limitation) when the DMA address space is 4GB in total.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> > On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > >>>>>>> 
> > >>>>>>> And I dont seem to have this request in my Inbox :(
> > >>>>>>> Yes I do see it in archieves, so not sure how this is not
> > >>>>>>> present, not sure if the servers mangeled it!!
> > >>>>>> 
> > >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > >>>>>> should still have reached you through the mailing list though (I
> > >>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > >>>>> 
> > >>>>> Yes I am, so should have reached me even though i wasnt cced
> > >>>>> I do see email reaching me from list without me being in CC, but
> > >>>>> then it wont hit my inbox and go to ML folder :)
> > >>>>> So generally its a good practice to CC relvant folks, lots of
> > >>>>> folks do ask that if ML is high volume
> > >>>> 
> > >>>> Hey Laurent,
> > >>>> 
> > >>>> I see that the oddity in commitlogs with change since artifacts
> > >>>> after SOB, can you please fix that up
> > >>> 
> > >>> My bad. I've fixed the problem and pushed the result to the same
> > >>> branch
> > >>> 
> > >>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > >>> 
> > >>> The only difference lies in the commit logs.
> > >> 
> > >> If my understanding was correct, we need to be based on Vinod's
> > >> topic/slave_caps_device_control_fix
> > > 
> > > Vinod, could you please comment on that ? To which kernel version do you
> > > plan to push this series ? Do I need to rebase it ?
> > 
> > Hi Laurent,
> > 
> > I did a quick at the series, looks fine mostly. I have already sent by pull
> > request to linus earlier last week and its merged, so we need to merge it
> > for next one. So yes we need to fix and test this for caps and control API
> > fix. Can you do that and I will pull and put in my next for 3.20
> 
> That's very annoying given that I have users waiting for the driver to be 
> merged, and that I've sent the pull request two weeks and a half ago.
Sorry cant help if I dont see the PULL request :( Apprently once a year
intel domain gets kicked out causing us to be unsubscribed, just bad timing
here...

> I suppose I have no choice anyway. Please provide me with a v3.20 development 
> branch on which I can rebase the patch set, I don't want to rebase it twice.
Please use topic/slave_caps_device_control_fix. I am going to rebase this
once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
impact you.

> > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> > DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> > you please explain a bit more on it, why do you need to modify addresses
> > based on config option?
> 
> Because there's no need to write the upper bits (above 32) of the DMA 
> addresses when the DMA address spans 32 bits only, and because there's no need 
> to check for transfers that cross a 4GB boundary (that's a hardware 
> limitation) when the DMA address space is 4GB in total.
I was hoping that dma_addr_t should take care of this... but lots of HW
limitations

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
> 
> On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> > On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> > > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> > >>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> > >>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > >>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> > >>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> > >>>>>>> 
> > >>>>>>> And I dont seem to have this request in my Inbox :(
> > >>>>>>> Yes I do see it in archieves, so not sure how this is not
> > >>>>>>> present, not sure if the servers mangeled it!!
> > >>>>>> 
> > >>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> > >>>>>> should still have reached you through the mailing list though (I
> > >>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> > >>>>> 
> > >>>>> Yes I am, so should have reached me even though i wasnt cced
> > >>>>> I do see email reaching me from list without me being in CC, but
> > >>>>> then it wont hit my inbox and go to ML folder :)
> > >>>>> So generally its a good practice to CC relvant folks, lots of
> > >>>>> folks do ask that if ML is high volume
> > >>>> 
> > >>>> Hey Laurent,
> > >>>> 
> > >>>> I see that the oddity in commitlogs with change since artifacts
> > >>>> after SOB, can you please fix that up
> > >>> 
> > >>> My bad. I've fixed the problem and pushed the result to the same
> > >>> branch
> > >>> 
> > >>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> > >>> 
> > >>> The only difference lies in the commit logs.
> > >> 
> > >> If my understanding was correct, we need to be based on Vinod's
> > >> topic/slave_caps_device_control_fix
> > > 
> > > Vinod, could you please comment on that ? To which kernel version do you
> > > plan to push this series ? Do I need to rebase it ?
> > 
> > Hi Laurent,
> > 
> > I did a quick at the series, looks fine mostly. I have already sent by pull
> > request to linus earlier last week and its merged, so we need to merge it
> > for next one. So yes we need to fix and test this for caps and control API
> > fix. Can you do that and I will pull and put in my next for 3.20
> 
> That's very annoying given that I have users waiting for the driver to be 
> merged, and that I've sent the pull request two weeks and a half ago.
Sorry cant help if I dont see the PULL request :( Apprently once a year
intel domain gets kicked out causing us to be unsubscribed, just bad timing
here...

> I suppose I have no choice anyway. Please provide me with a v3.20 development 
> branch on which I can rebase the patch set, I don't want to rebase it twice.
Please use topic/slave_caps_device_control_fix. I am going to rebase this
once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
impact you.

> > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2
> > DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can
> > you please explain a bit more on it, why do you need to modify addresses
> > based on config option?
> 
> Because there's no need to write the upper bits (above 32) of the DMA 
> addresses when the DMA address spans 32 bits only, and because there's no need 
> to check for transfers that cross a 4GB boundary (that's a hardware 
> limitation) when the DMA address space is 4GB in total.
I was hoping that dma_addr_t should take care of this... but lots of HW
limitations

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Tuesday 16 December 2014 12:34:13 Vinod Koul wrote:
> On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> > On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> >> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>>>> 
> >>>>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>>>> present, not sure if the servers mangeled it!!
> >>>>>>>> 
> >>>>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>>>> should still have reached you through the mailing list though (I
> >>>>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> >>>>>>> 
> >>>>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>>>> I do see email reaching me from list without me being in CC, but
> >>>>>>> then it wont hit my inbox and go to ML folder :)
> >>>>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>>>> folks do ask that if ML is high volume
> >>>>>> 
> >>>>>> Hey Laurent,
> >>>>>> 
> >>>>>> I see that the oddity in commitlogs with change since artifacts
> >>>>>> after SOB, can you please fix that up
> >>>>> 
> >>>>> My bad. I've fixed the problem and pushed the result to the same
> >>>>> branch
> >>>>> 
> >>>>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>>>> 
> >>>>> The only difference lies in the commit logs.
> >>>> 
> >>>> If my understanding was correct, we need to be based on Vinod's
> >>>> topic/slave_caps_device_control_fix
> >>> 
> >>> Vinod, could you please comment on that ? To which kernel version do
> >>> you plan to push this series ? Do I need to rebase it ?
> >> 
> >> Hi Laurent,
> >> 
> >> I did a quick at the series, looks fine mostly. I have already sent by
> >> pull request to linus earlier last week and its merged, so we need to
> >> merge it for next one. So yes we need to fix and test this for caps and
> >> control API fix. Can you do that and I will pull and put in my next for
> >> 3.20
> > 
> > That's very annoying given that I have users waiting for the driver to be
> > merged, and that I've sent the pull request two weeks and a half ago.
> 
> Sorry cant help if I dont see the PULL request :( Apprently once a year
> intel domain gets kicked out causing us to be unsubscribed, just bad timing
> here...

Do you mean that every Intel employee needs to resubscribe to all vger mailing 
list once a year ? :-o

> > I suppose I have no choice anyway. Please provide me with a v3.20
> > development branch on which I can rebase the patch set, I don't want to
> > rebase it twice.
>
> Please use topic/slave_caps_device_control_fix. I am going to rebase this
> once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> impact you.

Done. I'll rebase it once again when you will have rebased your branch, and 
will then send a pull request. Could you please rebase your branch early after 
the -rc1 release ?

> > > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car
> > > Gen2 DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT
> > > code. Can you please explain a bit more on it, why do you need to
> > > modify addresses based on config option?
> > 
> > Because there's no need to write the upper bits (above 32) of the DMA
> > addresses when the DMA address spans 32 bits only, and because there's no
> > need to check for transfers that cross a 4GB boundary (that's a hardware
> > limitation) when the DMA address space is 4GB in total.
> 
> I was hoping that dma_addr_t should take care of this... but lots of HW
> limitations

dma_addr_t gets a different size depending on whether large physical address 
extension is enabled or not, but that's only part of the solution. It doesn't 
magically remove code that ends up not being needed anymore, and worse than 
that, it causes the following build warnings:

  CC [M]  drivers/dma/sh/rcar-dmac.o
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_start_xfer’:
drivers/dma/sh/rcar-dmac.c:333:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:377:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:379:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_prep_sg’:
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type 
[enabled by default

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Tuesday 16 December 2014 12:34:13 Vinod Koul wrote:
> On Mon, Dec 15, 2014 at 10:04:45PM +0200, Laurent Pinchart wrote:
> > On Monday 15 December 2014 12:08:35 Vinod Koul wrote:
> >> On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote:
> >>> On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote:
> >>>>>> On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> >>>>>>> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> >>>>>>>>>> [GIT PULL FOR v3.19] R-Car DMA engine driver
> >>>>>>>>>> http://www.spinics.net/lists/linux-sh/msg37764.html
> >>>>>>>>> 
> >>>>>>>>> And I dont seem to have this request in my Inbox :(
> >>>>>>>>> Yes I do see it in archieves, so not sure how this is not
> >>>>>>>>> present, not sure if the servers mangeled it!!
> >>>>>>>> 
> >>>>>>>> I haven't CC'ed you, I'll make sure to do so next time. The mail
> >>>>>>>> should still have reached you through the mailing list though (I
> >>>>>>>> assume you're subscribed to dmaengine@vger.kernel.org ;-)).
> >>>>>>> 
> >>>>>>> Yes I am, so should have reached me even though i wasnt cced
> >>>>>>> I do see email reaching me from list without me being in CC, but
> >>>>>>> then it wont hit my inbox and go to ML folder :)
> >>>>>>> So generally its a good practice to CC relvant folks, lots of
> >>>>>>> folks do ask that if ML is high volume
> >>>>>> 
> >>>>>> Hey Laurent,
> >>>>>> 
> >>>>>> I see that the oddity in commitlogs with change since artifacts
> >>>>>> after SOB, can you please fix that up
> >>>>> 
> >>>>> My bad. I've fixed the problem and pushed the result to the same
> >>>>> branch
> >>>>> 
> >>>>> 	git://linuxtv.org/pinchartl/fbdev.git dma/next
> >>>>> 
> >>>>> The only difference lies in the commit logs.
> >>>> 
> >>>> If my understanding was correct, we need to be based on Vinod's
> >>>> topic/slave_caps_device_control_fix
> >>> 
> >>> Vinod, could you please comment on that ? To which kernel version do
> >>> you plan to push this series ? Do I need to rebase it ?
> >> 
> >> Hi Laurent,
> >> 
> >> I did a quick at the series, looks fine mostly. I have already sent by
> >> pull request to linus earlier last week and its merged, so we need to
> >> merge it for next one. So yes we need to fix and test this for caps and
> >> control API fix. Can you do that and I will pull and put in my next for
> >> 3.20
> > 
> > That's very annoying given that I have users waiting for the driver to be
> > merged, and that I've sent the pull request two weeks and a half ago.
> 
> Sorry cant help if I dont see the PULL request :( Apprently once a year
> intel domain gets kicked out causing us to be unsubscribed, just bad timing
> here...

Do you mean that every Intel employee needs to resubscribe to all vger mailing 
list once a year ? :-o

> > I suppose I have no choice anyway. Please provide me with a v3.20
> > development branch on which I can rebase the patch set, I don't want to
> > rebase it twice.
>
> Please use topic/slave_caps_device_control_fix. I am going to rebase this
> once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> impact you.

Done. I'll rebase it once again when you will have rebased your branch, and 
will then send a pull request. Could you please rebase your branch early after 
the -rc1 release ?

> > > One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car
> > > Gen2 DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT
> > > code. Can you please explain a bit more on it, why do you need to
> > > modify addresses based on config option?
> > 
> > Because there's no need to write the upper bits (above 32) of the DMA
> > addresses when the DMA address spans 32 bits only, and because there's no
> > need to check for transfers that cross a 4GB boundary (that's a hardware
> > limitation) when the DMA address space is 4GB in total.
> 
> I was hoping that dma_addr_t should take care of this... but lots of HW
> limitations

dma_addr_t gets a different size depending on whether large physical address 
extension is enabled or not, but that's only part of the solution. It doesn't 
magically remove code that ends up not being needed anymore, and worse than 
that, it causes the following build warnings:

  CC [M]  drivers/dma/sh/rcar-dmac.o
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_start_xfer’:
drivers/dma/sh/rcar-dmac.c:333:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:377:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:379:10: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c: In function ‘rcar_dmac_chan_prep_sg’:
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:873:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:875:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type 
[enabled by default]
drivers/dma/sh/rcar-dmac.c:883:4: warning: right shift count >= width of type 
[enabled by default

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> Do you mean that every Intel employee needs to resubscribe to all vger mailing 
> list once a year ? :-o
Unfortuntely yes... :( I need to set my infradead account up again now for
backup..

> 
> > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > development branch on which I can rebase the patch set, I don't want to
> > > rebase it twice.
> >
> > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > impact you.
> 
> Done. I'll rebase it once again when you will have rebased your branch, and 
> will then send a pull request. Could you please rebase your branch early after 
> the -rc1 release ?
Sure, within a day or so of its release it should be done.

Do note that am out during Christmas and the weekend with no email access,
will be lucky if my phone works, email very unlikely and I think you guys
will be out too.

But if your patches are done, feel free to send them

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> Do you mean that every Intel employee needs to resubscribe to all vger mailing 
> list once a year ? :-o
Unfortuntely yes... :( I need to set my infradead account up again now for
backup..

> 
> > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > development branch on which I can rebase the patch set, I don't want to
> > > rebase it twice.
> >
> > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > impact you.
> 
> Done. I'll rebase it once again when you will have rebased your branch, and 
> will then send a pull request. Could you please rebase your branch early after 
> the -rc1 release ?
Sure, within a day or so of its release it should be done.

Do note that am out during Christmas and the weekend with no email access,
will be lucky if my phone works, email very unlikely and I think you guys
will be out too.

But if your patches are done, feel free to send them

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> > Do you mean that every Intel employee needs to resubscribe to all vger mailing 
> > list once a year ? :-o
> Unfortuntely yes... :( I need to set my infradead account up again now for
> backup..
> 
> > 
> > > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > > development branch on which I can rebase the patch set, I don't want to
> > > > rebase it twice.
> > >
> > > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > > impact you.
> > 
> > Done. I'll rebase it once again when you will have rebased your branch, and 
> > will then send a pull request. Could you please rebase your branch early after 
> > the -rc1 release ?
> Sure, within a day or so of its release it should be done.
> 
> Do note that am out during Christmas and the weekend with no email access,
> will be lucky if my phone works, email very unlikely and I think you guys
> will be out too.
> 
> But if your patches are done, feel free to send them
And I have rebased and pushed. These should be linux-next for tomorrow

Thanks

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> > Do you mean that every Intel employee needs to resubscribe to all vger mailing 
> > list once a year ? :-o
> Unfortuntely yes... :( I need to set my infradead account up again now for
> backup..
> 
> > 
> > > > I suppose I have no choice anyway. Please provide me with a v3.20
> > > > development branch on which I can rebase the patch set, I don't want to
> > > > rebase it twice.
> > >
> > > Please use topic/slave_caps_device_control_fix. I am going to rebase this
> > > once rc1 is declared (eow i guess). It would plain git rebase, so shouldn't
> > > impact you.
> > 
> > Done. I'll rebase it once again when you will have rebased your branch, and 
> > will then send a pull request. Could you please rebase your branch early after 
> > the -rc1 release ?
> Sure, within a day or so of its release it should be done.
> 
> Do note that am out during Christmas and the weekend with no email access,
> will be lucky if my phone works, email very unlikely and I think you guys
> will be out too.
> 
> But if your patches are done, feel free to send them
And I have rebased and pushed. These should be linux-next for tomorrow

Thanks

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 22 December 2014 20:32:19 Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> > On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> >> Do you mean that every Intel employee needs to resubscribe to all vger
> >> mailing list once a year ? :-o
> > 
> > Unfortuntely yes... :( I need to set my infradead account up again now for
> > backup..
> > 
> >>>> I suppose I have no choice anyway. Please provide me with a v3.20
> >>>> development branch on which I can rebase the patch set, I don't want
> >>>> to rebase it twice.
> >>> 
> >>> Please use topic/slave_caps_device_control_fix. I am going to rebase
> >>> this once rc1 is declared (eow i guess). It would plain git rebase, so
> >>> shouldn't impact you.
> >> 
> >> Done. I'll rebase it once again when you will have rebased your branch,
> >> and will then send a pull request. Could you please rebase your branch
> >> early after the -rc1 release ?
> > 
> > Sure, within a day or so of its release it should be done.
> > 
> > Do note that am out during Christmas and the weekend with no email access,
> > will be lucky if my phone works, email very unlikely and I think you guys
> > will be out too.
> > 
> > But if your patches are done, feel free to send them
> 
> And I have rebased and pushed. These should be linux-next for tomorrow

Thank you. I've rebased my branch, I'm testing it, and will send you a pull 
request right afterwards.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Laurent Pinchart]

Hi Vinod,

On Monday 22 December 2014 20:32:19 Vinod Koul wrote:
> On Wed, Dec 17, 2014 at 06:24:06PM +0530, Vinod Koul wrote:
> > On Wed, Dec 17, 2014 at 01:57:30AM +0200, Laurent Pinchart wrote:
> >> Do you mean that every Intel employee needs to resubscribe to all vger
> >> mailing list once a year ? :-o
> > 
> > Unfortuntely yes... :( I need to set my infradead account up again now for
> > backup..
> > 
> >>>> I suppose I have no choice anyway. Please provide me with a v3.20
> >>>> development branch on which I can rebase the patch set, I don't want
> >>>> to rebase it twice.
> >>> 
> >>> Please use topic/slave_caps_device_control_fix. I am going to rebase
> >>> this once rc1 is declared (eow i guess). It would plain git rebase, so
> >>> shouldn't impact you.
> >> 
> >> Done. I'll rebase it once again when you will have rebased your branch,
> >> and will then send a pull request. Could you please rebase your branch
> >> early after the -rc1 release ?
> > 
> > Sure, within a day or so of its release it should be done.
> > 
> > Do note that am out during Christmas and the weekend with no email access,
> > will be lucky if my phone works, email very unlikely and I think you guys
> > will be out too.
> > 
> > But if your patches are done, feel free to send them
> 
> And I have rebased and pushed. These should be linux-next for tomorrow

Thank you. I've rebased my branch, I'm testing it, and will send you a pull 
request right afterwards.

-- 
Regards,

Laurent Pinchart