Re: [PATCH v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
Vinod Koul writes: >> Hi Vinod, >> >> Is this serie good for you or do you have remaining comments to be addressed >> ? > > Hi Robert, > > This series looks good, but I am afraid we are very close to merge window I > would like this to be deffered to next one for more stabililty tests and > coverage > > I have pushed this to topic/test/desc_reuse now. > > This will be in -next after merge window Okay, that's good for me, thanks. Cheers. -- Robert -- 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 v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
Vinod Koulwrites: >> Hi Vinod, >> >> Is this serie good for you or do you have remaining comments to be addressed >> ? > > Hi Robert, > > This series looks good, but I am afraid we are very close to merge window I > would like this to be deffered to next one for more stabililty tests and > coverage > > I have pushed this to topic/test/desc_reuse now. > > This will be in -next after merge window Okay, that's good for me, thanks. Cheers. -- Robert -- 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 v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
On Sat, Oct 24, 2015 at 11:57:53AM +0200, Robert Jarzmik wrote: > Robert Jarzmik writes: > > > This patch attempts to enhance the case of a transfer submitted multiple > > times, and where the cost of creating the descriptors chain is not > > negligible. > > > > This happens with big video buffers (several megabytes, ie. several > > thousands of linked descriptors in one scatter-gather list). In these > > cases, a video driver would want to do : > > - tx = dmaengine_prep_slave_sg() > > - dma_engine_submit(tx); > > - dma_async_issue_pending() > > - wait for video completion > > - read video data (or not, skipping a frame is also possible) > > - dma_engine_submit(tx) > >=> here, the descriptors chain recalculation will take time > >=> the dma coherent allocation over and over might create holes in > > the dma pool, which is counter-productive. > > - dma_async_issue_pending() > > - etc ... > > > > In order to cope with this case, virt-dma is modified to prevent freeing > > the descriptors upon completion if DMA_CTRL_REUSE flag is set in the > > transfer. > > > > This patch is a respin of the former DMA_CTRL_ACK approach, which was > > reverted due to a regression in audio drivers. > > > > Signed-off-by: Robert Jarzmik > > --- > > Since v1: added doxygen commit to vchan_tx_desc_free > > Hi Vinod, > > Is this serie good for you or do you have remaining comments to be addressed ? Hi Robert, This series looks good, but I am afraid we are very close to merge window I would like this to be deffered to next one for more stabililty tests and coverage I have pushed this to topic/test/desc_reuse now. This will be in -next after merge window Thanks for fixing this up -- ~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 v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
On Sat, Oct 24, 2015 at 11:57:53AM +0200, Robert Jarzmik wrote: > Robert Jarzmikwrites: > > > This patch attempts to enhance the case of a transfer submitted multiple > > times, and where the cost of creating the descriptors chain is not > > negligible. > > > > This happens with big video buffers (several megabytes, ie. several > > thousands of linked descriptors in one scatter-gather list). In these > > cases, a video driver would want to do : > > - tx = dmaengine_prep_slave_sg() > > - dma_engine_submit(tx); > > - dma_async_issue_pending() > > - wait for video completion > > - read video data (or not, skipping a frame is also possible) > > - dma_engine_submit(tx) > >=> here, the descriptors chain recalculation will take time > >=> the dma coherent allocation over and over might create holes in > > the dma pool, which is counter-productive. > > - dma_async_issue_pending() > > - etc ... > > > > In order to cope with this case, virt-dma is modified to prevent freeing > > the descriptors upon completion if DMA_CTRL_REUSE flag is set in the > > transfer. > > > > This patch is a respin of the former DMA_CTRL_ACK approach, which was > > reverted due to a regression in audio drivers. > > > > Signed-off-by: Robert Jarzmik > > --- > > Since v1: added doxygen commit to vchan_tx_desc_free > > Hi Vinod, > > Is this serie good for you or do you have remaining comments to be addressed ? Hi Robert, This series looks good, but I am afraid we are very close to merge window I would like this to be deffered to next one for more stabililty tests and coverage I have pushed this to topic/test/desc_reuse now. This will be in -next after merge window Thanks for fixing this up -- ~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 v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
Robert Jarzmik writes: > This patch attempts to enhance the case of a transfer submitted multiple > times, and where the cost of creating the descriptors chain is not > negligible. > > This happens with big video buffers (several megabytes, ie. several > thousands of linked descriptors in one scatter-gather list). In these > cases, a video driver would want to do : > - tx = dmaengine_prep_slave_sg() > - dma_engine_submit(tx); > - dma_async_issue_pending() > - wait for video completion > - read video data (or not, skipping a frame is also possible) > - dma_engine_submit(tx) >=> here, the descriptors chain recalculation will take time >=> the dma coherent allocation over and over might create holes in > the dma pool, which is counter-productive. > - dma_async_issue_pending() > - etc ... > > In order to cope with this case, virt-dma is modified to prevent freeing > the descriptors upon completion if DMA_CTRL_REUSE flag is set in the > transfer. > > This patch is a respin of the former DMA_CTRL_ACK approach, which was > reverted due to a regression in audio drivers. > > Signed-off-by: Robert Jarzmik > --- > Since v1: added doxygen commit to vchan_tx_desc_free Hi Vinod, Is this serie good for you or do you have remaining comments to be addressed ? Cheers. -- Robert -- 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 v2 1/3] dmaengine: virt-dma: don't always free descriptor upon completion
Robert Jarzmikwrites: > This patch attempts to enhance the case of a transfer submitted multiple > times, and where the cost of creating the descriptors chain is not > negligible. > > This happens with big video buffers (several megabytes, ie. several > thousands of linked descriptors in one scatter-gather list). In these > cases, a video driver would want to do : > - tx = dmaengine_prep_slave_sg() > - dma_engine_submit(tx); > - dma_async_issue_pending() > - wait for video completion > - read video data (or not, skipping a frame is also possible) > - dma_engine_submit(tx) >=> here, the descriptors chain recalculation will take time >=> the dma coherent allocation over and over might create holes in > the dma pool, which is counter-productive. > - dma_async_issue_pending() > - etc ... > > In order to cope with this case, virt-dma is modified to prevent freeing > the descriptors upon completion if DMA_CTRL_REUSE flag is set in the > transfer. > > This patch is a respin of the former DMA_CTRL_ACK approach, which was > reverted due to a regression in audio drivers. > > Signed-off-by: Robert Jarzmik > --- > Since v1: added doxygen commit to vchan_tx_desc_free Hi Vinod, Is this serie good for you or do you have remaining comments to be addressed ? Cheers. -- Robert -- 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/