From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Arnd Bergmann <arnd@arndb.de> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, ALSA Development Mailing List <alsa-devel@alsa-project.org>, Vinod Koul <vinod.koul@intel.com>, Linux MMC List <linux-mmc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-spi <linux-spi@vger.kernel.org>, Tony Lindgren <tony@atomide.com>, Geert Uytterhoeven <geert@linux-m68k.org>, linux-crypto@vger.kernel.org, "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>, dmaengine@vger.kernel.org, Dan Williams <dan.j.williams@intel.com>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, Linux Media Mailing List <linux-media@vger.kernel.org> Subject: Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason() Date: Thu, 19 Nov 2015 12:34:22 +0200 [thread overview] Message-ID: <564DA5AE.3060608@ti.com> (raw) In-Reply-To: <6358656.jIv3GGCCXu@wuerfel> On 11/18/2015 05:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >>>> 2. non slave channel requests, where only the functionality matters, like >>>> memcpy, interleaved, memset, etc. >>>> We could have a simple: >>>> dma_request_channel(mask); >>>> >>>> But looking at the drivers using dmaengine legacy dma_request_channel() API: >>>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: >>>> drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG >>>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG >>>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE >>>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY >>>> >>>> as examples. >>>> Not sure how valid are these... > > I just had a look myself. carma has been removed fortunately in linux-next, > so we don't have to worry about that any more. > > I assume that the sst-firmware.c case is a mistake, it should just use a > plain DMA_SLAVE and not DMA_MEMCPY. > > Aside from these, everyone else uses either DMA_CYCLIC in addition to > DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is > redundant in slave drivers and can be removed. Yep, CYCLIC. How could I forgot that ;) >>> It's usually not much harder to separate out the legacy case from >>> the normal dma_request_slave_channel_reason(), so those drivers don't >>> really need to use the unified compat API. >> >> The current dma_request_slave_channel()/_reason() is not the 'legacy' API. >> Currently there is no way to get the reason why the dma channel request fails >> when using the _compat() version of the API, which is used by drivers which >> can be used in DT or in legacy mode as well. Sure, they all could have local >> if(){}else{} for handling this, but it is not a nice thing. >> >> As it was discussed instead of adding the _reason() version for the _compat >> call, we should simplify the dmaengine API for getting the channel and at the >> same time we will have ERR_PTR returned instead of NULL. > > What I meant was that we don't need to handle them with the unified > simple interface. The users of DMA_CYCLIC can just keep using > an internal helper that only deals with the legacy case, or use > dma_request_slave() or whatever is the new API for the DT case. I think we can go with a single API, but I don't really like that: dma_request_channel(dev, name, *mask, fn, fn_param); This would cover all current uses being legacy, DT/ACPI, compat, etc: dma_request_channel(NULL, NULL, &mask, fn, fn_param); /* Legacy slave */ dma_request_channel(NULL, NULL, &mask, NULL, NULL); /* memcpy. etc */ dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */ dma_request_channel(dev, name, &mask, fn, fn_param); /* current compat */ Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask optional. If we have two main APIs, one to request slave channels and one to get any channel with given capability dma_request_slave_channel(NULL, NULL, &mask, fn, fn_param); /* Legacy slave */ dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */ dma_request_slave_channel(dev, name, &mask, fn, fn_param); /* current compat*/ This way we can omit the mask also in cases when the client only want to get DMA_SLAVE, we can just build up the mask within the function. If the mask is provided we would copy the bits from the provided mask, so for example if you want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC, the DMA_SLAVE is going to be set anyways. dma_request_channel(mask); /* memcpy. etc, non slave mostly */ Not sure how to name this as reusing existing (good, descriptive) function names would mean changes all over the kernel to start off this. Not used and request_dma_channel(); /* as _irq/_mem_region/_resource, etc */ request_dma(); dma_channel_request(); All in all, not sure which way would be better... -- Péter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Vinod Koul <vinod.koul@intel.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Tony Lindgren <tony@atomide.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Dan Williams <dan.j.williams@intel.com>, <dmaengine@vger.kernel.org>, "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, Linux MMC List <linux-mmc@vger.kernel.org>, <linux-crypto@vger.kernel.org>, linux-spi <linux-spi@vger.kernel.org>, Linux Media Mailing List <linux-media@vger.kernel.org>, ALSA Development Mailing List <alsa-devel@alsa-project.org> Subject: Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason() Date: Thu, 19 Nov 2015 12:34:22 +0200 [thread overview] Message-ID: <564DA5AE.3060608@ti.com> (raw) In-Reply-To: <6358656.jIv3GGCCXu@wuerfel> On 11/18/2015 05:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >>>> 2. non slave channel requests, where only the functionality matters, like >>>> memcpy, interleaved, memset, etc. >>>> We could have a simple: >>>> dma_request_channel(mask); >>>> >>>> But looking at the drivers using dmaengine legacy dma_request_channel() API: >>>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: >>>> drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG >>>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG >>>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE >>>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY >>>> >>>> as examples. >>>> Not sure how valid are these... > > I just had a look myself. carma has been removed fortunately in linux-next, > so we don't have to worry about that any more. > > I assume that the sst-firmware.c case is a mistake, it should just use a > plain DMA_SLAVE and not DMA_MEMCPY. > > Aside from these, everyone else uses either DMA_CYCLIC in addition to > DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is > redundant in slave drivers and can be removed. Yep, CYCLIC. How could I forgot that ;) >>> It's usually not much harder to separate out the legacy case from >>> the normal dma_request_slave_channel_reason(), so those drivers don't >>> really need to use the unified compat API. >> >> The current dma_request_slave_channel()/_reason() is not the 'legacy' API. >> Currently there is no way to get the reason why the dma channel request fails >> when using the _compat() version of the API, which is used by drivers which >> can be used in DT or in legacy mode as well. Sure, they all could have local >> if(){}else{} for handling this, but it is not a nice thing. >> >> As it was discussed instead of adding the _reason() version for the _compat >> call, we should simplify the dmaengine API for getting the channel and at the >> same time we will have ERR_PTR returned instead of NULL. > > What I meant was that we don't need to handle them with the unified > simple interface. The users of DMA_CYCLIC can just keep using > an internal helper that only deals with the legacy case, or use > dma_request_slave() or whatever is the new API for the DT case. I think we can go with a single API, but I don't really like that: dma_request_channel(dev, name, *mask, fn, fn_param); This would cover all current uses being legacy, DT/ACPI, compat, etc: dma_request_channel(NULL, NULL, &mask, fn, fn_param); /* Legacy slave */ dma_request_channel(NULL, NULL, &mask, NULL, NULL); /* memcpy. etc */ dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */ dma_request_channel(dev, name, &mask, fn, fn_param); /* current compat */ Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask optional. If we have two main APIs, one to request slave channels and one to get any channel with given capability dma_request_slave_channel(NULL, NULL, &mask, fn, fn_param); /* Legacy slave */ dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */ dma_request_slave_channel(dev, name, &mask, fn, fn_param); /* current compat*/ This way we can omit the mask also in cases when the client only want to get DMA_SLAVE, we can just build up the mask within the function. If the mask is provided we would copy the bits from the provided mask, so for example if you want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC, the DMA_SLAVE is going to be set anyways. dma_request_channel(mask); /* memcpy. etc, non slave mostly */ Not sure how to name this as reusing existing (good, descriptive) function names would mean changes all over the kernel to start off this. Not used and request_dma_channel(); /* as _irq/_mem_region/_resource, etc */ request_dma(); dma_channel_request(); All in all, not sure which way would be better... -- Péter
next prev parent reply other threads:[~2015-11-19 10:34 UTC|newest] Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-26 13:25 [PATCH 00/13] dmaengine + omap drivers: support fro deferred probing Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` [PATCH 01/13] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason() Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-29 9:33 ` Vinod Koul 2015-05-29 9:42 ` Geert Uytterhoeven 2015-05-29 9:42 ` Geert Uytterhoeven 2015-05-29 10:18 ` Vinod Koul 2015-05-29 14:32 ` Peter Ujfalusi 2015-05-29 14:32 ` Peter Ujfalusi 2015-06-02 12:55 ` Vinod Koul 2015-06-04 15:58 ` Peter Ujfalusi 2015-06-04 15:58 ` Peter Ujfalusi 2015-06-12 12:58 ` Vinod Koul 2015-06-22 11:31 ` Peter Ujfalusi 2015-06-22 11:31 ` Peter Ujfalusi 2015-06-22 11:31 ` Peter Ujfalusi 2015-06-24 16:24 ` Vinod Koul 2015-06-25 11:15 ` Arnd Bergmann 2015-11-18 14:21 ` Peter Ujfalusi 2015-11-18 14:21 ` Peter Ujfalusi 2015-11-18 14:21 ` Peter Ujfalusi 2015-11-18 14:29 ` Arnd Bergmann 2015-11-18 14:41 ` Peter Ujfalusi 2015-11-18 14:41 ` Peter Ujfalusi 2015-11-18 14:41 ` Peter Ujfalusi 2015-11-18 15:07 ` Arnd Bergmann 2015-11-18 15:43 ` Andy Shevchenko 2015-11-18 15:43 ` Andy Shevchenko [not found] ` <CAHp75VeZFXp9i_zz7CBkVQVPGQxuzYk9AbWbbbn33r8YX3LCdw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-18 15:51 ` Arnd Bergmann 2015-11-18 15:51 ` Arnd Bergmann 2015-11-18 16:00 ` Andy Shevchenko 2015-11-18 16:06 ` Vinod Koul 2015-11-18 16:06 ` Vinod Koul 2015-11-19 10:34 ` Peter Ujfalusi [this message] 2015-11-19 10:34 ` Peter Ujfalusi 2015-11-19 11:25 ` Arnd Bergmann 2015-11-20 10:25 ` Peter Ujfalusi 2015-11-20 10:25 ` Peter Ujfalusi 2015-11-20 10:58 ` Arnd Bergmann 2015-11-20 10:58 ` Arnd Bergmann 2015-11-20 12:24 ` Andy Shevchenko 2015-11-20 12:24 ` Andy Shevchenko [not found] ` <CAHp75VdoHqPMNGFfz4mPhX+Lw+vxgiyqFS8j5+kQ9Z9CHt=OTA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-20 12:30 ` Peter Ujfalusi 2015-11-20 12:30 ` Peter Ujfalusi [not found] ` <564F1253.4000800-l0cyMroinI0@public.gmane.org> 2015-11-20 14:08 ` Andy Shevchenko 2015-11-20 14:08 ` Andy Shevchenko 2015-11-20 12:52 ` Peter Ujfalusi 2015-11-20 12:52 ` Peter Ujfalusi 2015-11-20 12:52 ` Peter Ujfalusi [not found] ` <564F1773.9030006-l0cyMroinI0@public.gmane.org> 2015-11-20 13:48 ` Arnd Bergmann 2015-11-20 13:48 ` Arnd Bergmann 2015-11-18 15:46 ` Andy Shevchenko 2015-11-19 10:36 ` Peter Ujfalusi 2015-11-19 10:36 ` Peter Ujfalusi 2015-05-26 13:25 ` [PATCH 04/13] mmc: omap_hsmmc: No need to check DMA channel validity at module remove Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-28 7:20 ` Ulf Hansson 2015-05-26 13:26 ` [PATCH 05/13] mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi [not found] ` <1432646768-12532-6-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org> 2015-05-28 7:23 ` Ulf Hansson 2015-05-28 7:23 ` Ulf Hansson 2015-05-26 13:26 ` [PATCH 06/13] mmc: omap: " Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` [PATCH 07/13] mmc: davinci_mmc: " Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-28 7:31 ` Ulf Hansson 2015-05-26 13:26 ` [PATCH 08/13] crypto: omap-aes - " Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` [PATCH 10/13] crypto: omap-sham - Support for deferred probing when requesting DMA channel Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 15:27 ` Mark Brown 2015-05-27 11:15 ` Peter Ujfalusi 2015-05-27 11:15 ` Peter Ujfalusi [not found] ` <5565A740.2020707-l0cyMroinI0@public.gmane.org> 2015-05-27 17:48 ` Mark Brown 2015-05-27 17:48 ` Mark Brown 2015-05-27 17:48 ` Mark Brown 2015-05-26 13:26 ` [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-11-09 19:50 ` Laurent Pinchart 2015-11-10 7:56 ` Peter Ujfalusi 2015-11-10 7:56 ` Peter Ujfalusi 2015-11-10 7:56 ` Peter Ujfalusi [not found] ` <1432646768-12532-1-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org> 2015-05-26 13:25 ` [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi 2015-05-26 13:25 ` Peter Ujfalusi [not found] ` <1432646768-12532-4-git-send-email-peter.ujfalusi-l0cyMroinI0@public.gmane.org> 2015-05-26 14:44 ` Greg Kroah-Hartman 2015-05-26 14:44 ` Greg Kroah-Hartman 2015-05-27 10:41 ` Peter Ujfalusi 2015-05-27 10:41 ` Peter Ujfalusi 2015-05-27 10:41 ` Peter Ujfalusi 2015-05-27 10:41 ` Peter Ujfalusi 2015-05-26 15:08 ` Tony Lindgren 2015-05-26 15:08 ` Tony Lindgren 2015-05-27 10:58 ` Peter Ujfalusi 2015-05-27 10:58 ` Peter Ujfalusi 2015-05-26 13:26 ` [PATCH 09/13] crypto: omap-des - " Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` [PATCH 13/13] ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason() Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-26 13:26 ` Peter Ujfalusi 2015-05-27 17:48 ` Mark Brown
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=564DA5AE.3060608@ti.com \ --to=peter.ujfalusi@ti.com \ --cc=alsa-devel@alsa-project.org \ --cc=arnd@arndb.de \ --cc=dan.j.williams@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dmaengine@vger.kernel.org \ --cc=geert@linux-m68k.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=tony@atomide.com \ --cc=vinod.koul@intel.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.