Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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,
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
(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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
(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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 > 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 > Tested-by: Wolfram Sang > > > --- > > 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 > 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 > Tested-by: Wolfram Sang > > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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+rene...@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+rene...@ideasonboard.com Tested-by: Wolfram Sang wsa+rene...@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+rene...@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+rene...@ideasonboard.com Tested-by: Wolfram Sang wsa+rene...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 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 Tested-by: Wolfram Sang --- 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 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 Tested-by: Wolfram Sang --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
> 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
> ---
> 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, >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 >async_tx;
> }
> --
> 2.1.3
>
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
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
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 dmaeng...@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+rene...@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+rene...@ideasonboard.com Tested-by: Wolfram Sang wsa+rene...@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+rene...@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+rene...@ideasonboard.com Tested-by: Wolfram Sang wsa+rene...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
> 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
Acked-by: Laurent Pinchart
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, >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 >async_tx;
> }
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
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.pinch...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
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
---
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, >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 >async_tx;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
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 0004
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
