| Message ID | 1416924617-15939-1-git-send-email-j@bitron.ch (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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; > }
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
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
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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.
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
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...
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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(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 ?
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?
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.
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
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
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
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
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.
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; }
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(-)