* [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure @ 2014-11-25 14:10 Jürg Billeter 2014-11-27 0:07 ` Laurent Pinchart 2014-12-08 11:36 ` Vinod Koul 0 siblings, 2 replies; 18+ messages in thread From: Jürg Billeter @ 2014-11-25 14:10 UTC (permalink / raw) To: Laurent Pinchart Cc: Simon Horman, Magnus Damm, Vinod Koul, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine, 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-11-25 14:10 [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure Jürg Billeter @ 2014-11-27 0:07 ` Laurent Pinchart 2014-12-08 11:36 ` Vinod Koul 1 sibling, 0 replies; 18+ messages in thread From: Laurent Pinchart @ 2014-11-27 0:07 UTC (permalink / raw) To: Jürg Billeter, Simon Horman Cc: Magnus Damm, Vinod Koul, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-11-25 14:10 [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure Jürg Billeter 2014-11-27 0:07 ` Laurent Pinchart @ 2014-12-08 11:36 ` Vinod Koul 2014-12-08 16:50 ` Jürg Billeter 1 sibling, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-08 11:36 UTC (permalink / raw) To: Jürg Billeter Cc: Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 > -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-08 11:36 ` Vinod Koul @ 2014-12-08 16:50 ` Jürg Billeter 2014-12-08 17:19 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Jürg Billeter @ 2014-12-08 16:50 UTC (permalink / raw) To: Vinod Koul Cc: Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-08 16:50 ` Jürg Billeter @ 2014-12-08 17:19 ` Vinod Koul 2014-12-08 17:40 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-08 17:19 UTC (permalink / raw) To: Jürg Billeter Cc: Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-08 17:19 ` Vinod Koul @ 2014-12-08 17:40 ` Laurent Pinchart 2014-12-08 17:50 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Laurent Pinchart @ 2014-12-08 17:40 UTC (permalink / raw) To: Vinod Koul Cc: Jürg Billeter, Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-08 17:40 ` Laurent Pinchart @ 2014-12-08 17:50 ` Vinod Koul 2014-12-09 6:39 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-08 17:50 UTC (permalink / raw) To: Laurent Pinchart Cc: Jürg Billeter, Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-08 17:50 ` Vinod Koul @ 2014-12-09 6:39 ` Vinod Koul 2014-12-10 16:09 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-09 6:39 UTC (permalink / raw) To: Laurent Pinchart Cc: Jürg Billeter, Laurent Pinchart, Simon Horman, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-09 6:39 ` Vinod Koul @ 2014-12-10 16:09 ` Laurent Pinchart 2014-12-11 1:16 ` Kuninori Morimoto 0 siblings, 1 reply; 18+ messages in thread From: Laurent Pinchart @ 2014-12-10 16:09 UTC (permalink / raw) To: Vinod Koul, Simon Horman Cc: Jürg Billeter, Magnus Damm, Phil Edworthy, Kuninori Morimoto, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-10 16:09 ` Laurent Pinchart @ 2014-12-11 1:16 ` Kuninori Morimoto 2014-12-12 19:41 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Kuninori Morimoto @ 2014-12-11 1:16 UTC (permalink / raw) To: Laurent Pinchart Cc: Vinod Koul, Simon Horman, =?ISO-2022-JP-2?B?ShskKEQrZBsoQnJn?= Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-11 1:16 ` Kuninori Morimoto @ 2014-12-12 19:41 ` Laurent Pinchart 2014-12-15 6:38 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Laurent Pinchart @ 2014-12-12 19:41 UTC (permalink / raw) To: Vinod Koul Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine (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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-12 19:41 ` Laurent Pinchart @ 2014-12-15 6:38 ` Vinod Koul 2014-12-15 20:04 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-15 6:38 UTC (permalink / raw) To: Laurent Pinchart Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-15 6:38 ` Vinod Koul @ 2014-12-15 20:04 ` Laurent Pinchart 2014-12-16 7:04 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Laurent Pinchart @ 2014-12-15 20:04 UTC (permalink / raw) To: Vinod Koul Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-15 20:04 ` Laurent Pinchart @ 2014-12-16 7:04 ` Vinod Koul 2014-12-16 23:57 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-16 7:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-16 7:04 ` Vinod Koul @ 2014-12-16 23:57 ` Laurent Pinchart 2014-12-17 12:54 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Laurent Pinchart @ 2014-12-16 23:57 UTC (permalink / raw) To: Vinod Koul Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-16 23:57 ` Laurent Pinchart @ 2014-12-17 12:54 ` Vinod Koul 2014-12-22 15:02 ` Vinod Koul 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-17 12:54 UTC (permalink / raw) To: Laurent Pinchart Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-17 12:54 ` Vinod Koul @ 2014-12-22 15:02 ` Vinod Koul 2014-12-23 9:14 ` Laurent Pinchart 0 siblings, 1 reply; 18+ messages in thread From: Vinod Koul @ 2014-12-22 15:02 UTC (permalink / raw) To: Laurent Pinchart Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure 2014-12-22 15:02 ` Vinod Koul @ 2014-12-23 9:14 ` Laurent Pinchart 0 siblings, 0 replies; 18+ messages in thread From: Laurent Pinchart @ 2014-12-23 9:14 UTC (permalink / raw) To: Vinod Koul Cc: Kuninori Morimoto, Simon Horman, Jürg Billeter, Magnus Damm, Phil Edworthy, linux-kernel, linux-sh, dmaengine 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-12-23 9:14 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-11-25 14:10 [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure Jürg Billeter 2014-11-27 0:07 ` Laurent Pinchart 2014-12-08 11:36 ` Vinod Koul 2014-12-08 16:50 ` Jürg Billeter 2014-12-08 17:19 ` Vinod Koul 2014-12-08 17:40 ` Laurent Pinchart 2014-12-08 17:50 ` Vinod Koul 2014-12-09 6:39 ` Vinod Koul 2014-12-10 16:09 ` Laurent Pinchart 2014-12-11 1:16 ` Kuninori Morimoto 2014-12-12 19:41 ` Laurent Pinchart 2014-12-15 6:38 ` Vinod Koul 2014-12-15 20:04 ` Laurent Pinchart 2014-12-16 7:04 ` Vinod Koul 2014-12-16 23:57 ` Laurent Pinchart 2014-12-17 12:54 ` Vinod Koul 2014-12-22 15:02 ` Vinod Koul 2014-12-23 9:14 ` Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).