From: Robert Jarzmik <robert.jarzmik@free.fr> To: Daniel Mack <zonque@gmail.com> Cc: mark.rutland@arm.com, s.neumann@raumfeld.com, linux-mtd@lists.infradead.org, haojian.zhuang@linaro.org, cxie4@marvell.com, lars@metafoo.de, nico@linaro.org, vinod.koul@intel.com, marek.vasut@gmail.com, ezequiel.garcia@free-electrons.com, rmk+kernel@arm.linux.org.uk, devicetree@vger.kernel.org, samuel@sortiz.org, arnd@arndb.de, broonie@kernel.org, mika.westerberg@linux.intel.com, linux-arm-kernel@lists.infradead.org, thomas.petazzoni@free-electrons.com, eric.y.miao@gmail.com, gregkh@linuxfoundation.org, davem@davemloft.net, sachin.kamat@linaro.org, kernel@pengutronix.de, djbw@fb.com, g.liakhovetski@gmx.de Subject: Re: [PATCH 00/20] ARM: pxa: move core and drivers to dmaengine Date: Sun, 11 Aug 2013 22:05:04 +0200 [thread overview] Message-ID: <874nawyowf.fsf@free.fr> (raw) In-Reply-To: 52061C53.4050905@gmail.com Daniel Mack <zonque@gmail.com> writes: > Hi Robert, We might reduce the thread broadcast, I don't think these many people care about pxa camera specifics, and its DMA constraints. >> All that is described in there : >> Documentation/video4linux/pxa_camera.txt > > Yes, I've seen that, and while the documentation about all that is > excellent, I lack an explanation why things are so complicated for this > application, and why a simple cyclic DMA approach does not suffice here. > I'm sure there's a reason though. Well, I think there is a good one. The current video4linux flow, for video capture, is : 1) userland prepares buffers (ie. dma transfers are prepared, one sg list for each "image" or "frame") 2) userland queues buffers (no hardware operation) 3) userland starts the capture 4) userland poll for each frame end a) When a frame is finished, userland unqueues it => no overwrite of this frame is possible anymore b) Userland treats is (might be sent to storage, or compressed, ...) c) Userland requeues it (while other frame is being DMAed) Moreover, it should be assumed that waiting for a "end of DMA transfer" before requeuing the next one (ie. "cold queuing" instead of "hot queueing") will imply the miss of the next frame start, and one frame will be missed. With a cyclic DMA, if I understand dmaengine correctly, step 4a. is not posssible (ie. if userland is slow enough, the frame will be overwritten without userland knowing it, and while userland is handling it). > There might be need to teach the dmaengine core more functionality, but > in order to do that, we first need to understand the exact requirements. The first one that comes to my mind is : - enable to submit a transfer to a running channel, the same one that served a previous transfer : => this will guarantee ordering of DMA transfers => this will guarantee no DMA stops if 2 or more buffers are queued => this will try to chain this transfer to the last one queued on the channel => if by bad luck the "miss window is hit", ie. the DMA finishes while the chaining was being done, restart the DMA on its stop >> Another point I'd like to know, is what is the performance penalty in using >> dmaengine, and do you have any figures ? > The DMA transfers themselves certainly perform equally well, and the > framework is just a thin layer. Where would you expect performance penalty? Well, last time I had a look (in [1]), I think I remember having a 3% penalty on SD card transfers (pxamci driver, mioa701 board, transcend 16Go SD card). It's been a while and my memory is a bit fuzzy about it. The loss I had at the time was in queuing/unqueuing the DMA requests IIRC. >> Lastly, they was debug information to debug descriptors chaining, channel >> statuses, requestors. I didn't see where these had gone, could you point me to >> the right file ? > > Such a debug interface is not part of the mmp-pdma implementation at > this point, and the core doesn't have a generic debugfs feature either. > If you need that, we'd have to add it back. Well, I use that. It's not vital for DMA to work of course, but it's very nice to have when you mess with DMA transfers :) > FWIW, I attached my work-in-progress patch for this driver which just > does some basic dmaengine preparations. Be aware that this does not even > compile, it's really just a snapshot. OK, cool. Once the dmaengine stuff is clearer in my mind, and if "hot submitting" is already possible in dmaengine, it shouldn't be that hard to convert. Cheers. -- Robert [1] http://archive.arm.linux.org.uk/lurker/message/20090517.194809.b18c79c8.en.html
WARNING: multiple messages have this Message-ID (diff)
From: robert.jarzmik@free.fr (Robert Jarzmik) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/20] ARM: pxa: move core and drivers to dmaengine Date: Sun, 11 Aug 2013 22:05:04 +0200 [thread overview] Message-ID: <874nawyowf.fsf@free.fr> (raw) In-Reply-To: 52061C53.4050905@gmail.com Daniel Mack <zonque@gmail.com> writes: > Hi Robert, We might reduce the thread broadcast, I don't think these many people care about pxa camera specifics, and its DMA constraints. >> All that is described in there : >> Documentation/video4linux/pxa_camera.txt > > Yes, I've seen that, and while the documentation about all that is > excellent, I lack an explanation why things are so complicated for this > application, and why a simple cyclic DMA approach does not suffice here. > I'm sure there's a reason though. Well, I think there is a good one. The current video4linux flow, for video capture, is : 1) userland prepares buffers (ie. dma transfers are prepared, one sg list for each "image" or "frame") 2) userland queues buffers (no hardware operation) 3) userland starts the capture 4) userland poll for each frame end a) When a frame is finished, userland unqueues it => no overwrite of this frame is possible anymore b) Userland treats is (might be sent to storage, or compressed, ...) c) Userland requeues it (while other frame is being DMAed) Moreover, it should be assumed that waiting for a "end of DMA transfer" before requeuing the next one (ie. "cold queuing" instead of "hot queueing") will imply the miss of the next frame start, and one frame will be missed. With a cyclic DMA, if I understand dmaengine correctly, step 4a. is not posssible (ie. if userland is slow enough, the frame will be overwritten without userland knowing it, and while userland is handling it). > There might be need to teach the dmaengine core more functionality, but > in order to do that, we first need to understand the exact requirements. The first one that comes to my mind is : - enable to submit a transfer to a running channel, the same one that served a previous transfer : => this will guarantee ordering of DMA transfers => this will guarantee no DMA stops if 2 or more buffers are queued => this will try to chain this transfer to the last one queued on the channel => if by bad luck the "miss window is hit", ie. the DMA finishes while the chaining was being done, restart the DMA on its stop >> Another point I'd like to know, is what is the performance penalty in using >> dmaengine, and do you have any figures ? > The DMA transfers themselves certainly perform equally well, and the > framework is just a thin layer. Where would you expect performance penalty? Well, last time I had a look (in [1]), I think I remember having a 3% penalty on SD card transfers (pxamci driver, mioa701 board, transcend 16Go SD card). It's been a while and my memory is a bit fuzzy about it. The loss I had at the time was in queuing/unqueuing the DMA requests IIRC. >> Lastly, they was debug information to debug descriptors chaining, channel >> statuses, requestors. I didn't see where these had gone, could you point me to >> the right file ? > > Such a debug interface is not part of the mmp-pdma implementation at > this point, and the core doesn't have a generic debugfs feature either. > If you need that, we'd have to add it back. Well, I use that. It's not vital for DMA to work of course, but it's very nice to have when you mess with DMA transfers :) > FWIW, I attached my work-in-progress patch for this driver which just > does some basic dmaengine preparations. Be aware that this does not even > compile, it's really just a snapshot. OK, cool. Once the dmaengine stuff is clearer in my mind, and if "hot submitting" is already possible in dmaengine, it shouldn't be that hard to convert. Cheers. -- Robert [1] http://archive.arm.linux.org.uk/lurker/message/20090517.194809.b18c79c8.en.html
next prev parent reply other threads:[~2013-08-11 20:05 UTC|newest] Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-07 15:33 [PATCH 00/20] ARM: pxa: move core and drivers to dmaengine Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:33 ` [PATCH 01/20] mtd: pxa3xx-nand: replace pxa_request_dma with dmaengine Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 17:46 ` Ezequiel Garcia 2013-08-07 17:46 ` Ezequiel Garcia 2013-08-08 6:42 ` Daniel Mack 2013-08-08 6:42 ` Daniel Mack 2013-08-08 10:12 ` Ezequiel Garcia 2013-08-08 10:12 ` Ezequiel Garcia 2013-08-08 10:14 ` Daniel Mack 2013-08-08 10:14 ` Daniel Mack 2013-08-07 15:33 ` [PATCH 02/20] mtd: pxa3xx-nand: use mmp_pdma_filter_fn and dma_request_slave_channel_compat Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:33 ` [PATCH 03/20] ARM: pxa: ssp: add shortcut for &pdev->dev Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-08 7:32 ` Brian Norris 2013-08-08 7:32 ` Brian Norris 2013-08-08 7:52 ` Artem Bityutskiy 2013-08-08 7:52 ` Artem Bityutskiy 2013-08-08 8:20 ` Daniel Mack 2013-08-08 8:20 ` Daniel Mack 2013-08-07 15:33 ` [PATCH 04/20] ARM: pxa: ssp: add DT bindings Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:54 ` Arnd Bergmann 2013-08-07 15:54 ` Arnd Bergmann 2013-08-07 15:33 ` [PATCH 05/20] ARM: pxa: ssp: use devm_ functions Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:33 ` [PATCH 06/20] tty: serial: pxa: remove old cruft Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-12 8:19 ` Daniel Mack 2013-08-12 18:08 ` Greg KH 2013-08-07 15:33 ` [PATCH 07/20] spi: spi-pxa2xx: remove legacy PXA DMA bits Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:55 ` Mark Brown 2013-08-07 15:55 ` Mark Brown 2013-08-07 15:59 ` Daniel Mack 2013-08-07 15:59 ` Daniel Mack 2013-08-07 16:41 ` Mark Brown 2013-08-07 16:41 ` Mark Brown 2013-08-07 15:33 ` [PATCH 08/20] mmc: host: pxamci: switch over to dmaengine use Daniel Mack 2013-08-07 15:33 ` Daniel Mack [not found] ` <1375889649-14638-9-git-send-email-zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2014-10-15 18:32 ` Vasily Khoruzhick 2014-10-15 18:32 ` Vasily Khoruzhick 2014-10-15 18:32 ` Vasily Khoruzhick [not found] ` <CA+E=qVe5zRoR8qVa_gyJu+qpuGHFmqoGvEHowcu_hXR01GBzTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-10-16 17:57 ` Vasily Khoruzhick 2014-10-16 17:57 ` Vasily Khoruzhick 2014-10-16 17:57 ` Vasily Khoruzhick 2013-08-07 15:33 ` [PATCH 09/20] ata: pdata_pxa: migrate over to dmaengine usage Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:59 ` Arnd Bergmann 2013-08-07 15:59 ` Arnd Bergmann 2013-08-07 15:33 ` [PATCH 10/20] net: irda: pxaficp_ir: switch to dmaengine Daniel Mack 2013-08-07 15:33 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 11/20] net: smc91x.c: switch to generic buf-to-buf DMA offload Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 12/20] net: smc911x.c: switch to dmaengine API Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 13/20] ASoC: pxa: pxa-ssp: add DT bindings Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 16:40 ` Mark Brown 2013-08-07 16:40 ` Mark Brown 2013-08-08 9:39 ` Daniel Mack 2013-08-08 9:39 ` Daniel Mack 2013-08-08 13:20 ` Mark Brown 2013-08-08 13:20 ` Mark Brown 2013-08-09 13:03 ` Daniel Mack 2013-08-09 13:03 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 14/20] ASoC: pxa: use snd_dmaengine_dai_dma_data Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:57 ` Mark Brown 2013-08-07 15:57 ` Mark Brown 2013-08-07 15:34 ` [PATCH 15/20] ASoC: pxa: pxa-ssp: set dma filter data from startup hook Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:58 ` Mark Brown 2013-08-07 15:58 ` Mark Brown 2013-08-07 15:34 ` [PATCH 16/20] ASoC: pxa: add DT bindings for pxa2xx-pcm Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 16:06 ` Mark Brown 2013-08-07 16:06 ` Mark Brown 2013-08-07 15:34 ` [PATCH 17/20] ASoC: pxa: pxa-pcm-lib: switch over to snd-soc-dmaengine-pcm Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 16:07 ` Mark Brown 2013-08-07 16:07 ` Mark Brown 2013-08-07 16:10 ` Daniel Mack 2013-08-07 16:10 ` Daniel Mack 2013-08-07 16:32 ` Mark Brown 2013-08-07 16:32 ` Mark Brown 2013-08-08 8:18 ` Daniel Mack 2013-08-08 8:18 ` Daniel Mack 2013-08-08 8:44 ` Lars-Peter Clausen 2013-08-08 8:44 ` Lars-Peter Clausen 2013-08-08 9:03 ` Daniel Mack 2013-08-08 9:03 ` Daniel Mack 2013-08-08 9:36 ` Mark Brown 2013-08-08 9:36 ` Mark Brown 2013-08-08 9:43 ` Daniel Mack 2013-08-08 9:43 ` Daniel Mack 2013-08-08 10:35 ` Mark Brown 2013-08-08 10:35 ` Mark Brown 2013-08-08 10:39 ` Daniel Mack 2013-08-08 10:39 ` Daniel Mack 2013-08-08 11:03 ` Mark Brown 2013-08-08 11:03 ` Mark Brown 2013-08-08 10:25 ` Russell King - ARM Linux 2013-08-08 10:25 ` Russell King - ARM Linux 2013-08-07 15:34 ` [PATCH 18/20] ARM: pxa: register static mmp_pdma device Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 19/20] ARM: mmp: " Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 15:34 ` [PATCH 20/20] ARM: pxa: remove old DMA implementation Daniel Mack 2013-08-07 15:34 ` Daniel Mack 2013-08-07 16:08 ` [PATCH 00/20] ARM: pxa: move core and drivers to dmaengine Arnd Bergmann 2013-08-07 16:08 ` Arnd Bergmann 2013-08-09 22:50 ` Robert Jarzmik 2013-08-09 22:50 ` Robert Jarzmik 2013-08-10 10:56 ` Daniel Mack 2013-08-10 10:56 ` Daniel Mack 2013-08-11 20:05 ` Robert Jarzmik [this message] 2013-08-11 20:05 ` Robert Jarzmik 2013-08-14 10:00 ` Vinod Koul 2013-08-14 10:00 ` Vinod Koul 2013-08-15 15:22 ` Robert Jarzmik 2013-08-15 15:22 ` Robert Jarzmik 2013-08-15 15:30 ` Daniel Mack 2013-08-15 15:30 ` Daniel Mack
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=874nawyowf.fsf@free.fr \ --to=robert.jarzmik@free.fr \ --cc=arnd@arndb.de \ --cc=broonie@kernel.org \ --cc=cxie4@marvell.com \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=djbw@fb.com \ --cc=eric.y.miao@gmail.com \ --cc=ezequiel.garcia@free-electrons.com \ --cc=g.liakhovetski@gmx.de \ --cc=gregkh@linuxfoundation.org \ --cc=haojian.zhuang@linaro.org \ --cc=kernel@pengutronix.de \ --cc=lars@metafoo.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=marek.vasut@gmail.com \ --cc=mark.rutland@arm.com \ --cc=mika.westerberg@linux.intel.com \ --cc=nico@linaro.org \ --cc=rmk+kernel@arm.linux.org.uk \ --cc=s.neumann@raumfeld.com \ --cc=sachin.kamat@linaro.org \ --cc=samuel@sortiz.org \ --cc=thomas.petazzoni@free-electrons.com \ --cc=vinod.koul@intel.com \ --cc=zonque@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.