From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Vinod Koul <vinod.koul@intel.com> Cc: 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, 4 Jun 2015 18:58:06 +0300 [thread overview] Message-ID: <5570758E.6030302@ti.com> (raw) In-Reply-To: <20150602125535.GS3140@localhost> Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: > On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: >> On 05/29/2015 01:18 PM, Vinod Koul wrote: >>> On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: >>>> On Fri, May 29, 2015 at 11:33 AM, Vinod Koul <vinod.koul@intel.com> wrote: >>>>> On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: >>>>>> dma_request_slave_channel_compat() 'eats' up the returned error codes which >>>>>> prevents drivers using the compat call to be able to do deferred probing. >>>>>> >>>>>> The new wrapper is identical in functionality but it will return with error >>>>>> code in case of failure and will pass the -EPROBE_DEFER to the caller in >>>>>> case dma_request_slave_channel_reason() returned with it. >>>>> This is okay but am worried about one more warpper, how about fixing >>>>> dma_request_slave_channel_compat() >>>> >>>> Then all callers of dma_request_slave_channel_compat() have to be >>>> modified to handle ERR_PTR first. >>>> >>>> The same is true for (the existing) dma_request_slave_channel_reason() >>>> vs. dma_request_slave_channel(). >>> Good point, looking again, I think we should rather fix >>> dma_request_slave_channel_reason() as it was expected to return err code and >>> add new users. Anyway users of this API do expect the reason... >> >> Hrm, they are for different use.dma_request_slave_channel()/_reason() is for >> drivers only working via DT or ACPI while >> dma_request_slave_channel_compat()/_reason() is for drivers expected to run in >> DT/ACPI or legacy mode as well. >> >> I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci >> drivers are using this to request channels - they need to support DT and >> legacy mode. > I think we should hide these things behind the API and do this behind the > hood for ACPI/DT systems. > > Also it makes sense to use right API and mark rest as depricated So to convert the dma_request_slave_channel_compat() and not to create _reason variant? Or to have single API to request channel? The problem with that is that we need different parameters for legacy and DT for example. >> >> But it is doable to do this for both the non _compat and _compat version: >> 1. change all users to check IS_ERR_OR_NULL(chan) >> return the PTR_ERR if not NULL, or do whatever the driver was doing in case >> of chan == NULL. >> 2. change the non _compat and _compat versions to do the same as the _reason >> variants, #define the _reason ones to the non _reason names >> 3. Rename the _reason use to non _reason function in drivers >> 4. Remove the #defines for the _reason functions >> 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers >> The result: >> Both dma_request_slave_channel() and dma_request_slave_channel_compat() will >> return ERR_PTR in case of failure or in success they will return the pinter to >> chan. >> >> Is this what you were asking? >> It is a bit broader than what this series was doing: taking care of >> OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) > Yes but it would make sense right? I know it is a larger work but then we > wouldn't want another dma_request_slave_xxx API, at some point we have stop > it exapnding, perhpas now :) Yes, it make sense to get rid if the _reason() things and have the dma_request_slave_channel() and dma_request_slave_channel_compat() return with error code One thing we need to do for this is to change the error codes coming back from the _dt() and _acpi() calls when we boot in legacy mode. Right now the only error code which comes back is -ENODEV and -EPROBE_DEFER. We need to differentiate between 'real' errors and from the fact that we did not booted with DT or the ACPI is not available. IMHO if we boot with DT and the channel request fails with other than -EPROBE_DEFER we should not go and try to get the channel via legacy API. > Yes I am all ears to stage this work and not do transition gardually.. > -- Péter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com> To: Vinod Koul <vinod.koul@intel.com> Cc: 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, 4 Jun 2015 18:58:06 +0300 [thread overview] Message-ID: <5570758E.6030302@ti.com> (raw) In-Reply-To: <20150602125535.GS3140@localhost> Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: > On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: >> On 05/29/2015 01:18 PM, Vinod Koul wrote: >>> On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: >>>> On Fri, May 29, 2015 at 11:33 AM, Vinod Koul <vinod.koul@intel.com> wrote: >>>>> On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: >>>>>> dma_request_slave_channel_compat() 'eats' up the returned error codes which >>>>>> prevents drivers using the compat call to be able to do deferred probing. >>>>>> >>>>>> The new wrapper is identical in functionality but it will return with error >>>>>> code in case of failure and will pass the -EPROBE_DEFER to the caller in >>>>>> case dma_request_slave_channel_reason() returned with it. >>>>> This is okay but am worried about one more warpper, how about fixing >>>>> dma_request_slave_channel_compat() >>>> >>>> Then all callers of dma_request_slave_channel_compat() have to be >>>> modified to handle ERR_PTR first. >>>> >>>> The same is true for (the existing) dma_request_slave_channel_reason() >>>> vs. dma_request_slave_channel(). >>> Good point, looking again, I think we should rather fix >>> dma_request_slave_channel_reason() as it was expected to return err code and >>> add new users. Anyway users of this API do expect the reason... >> >> Hrm, they are for different use.dma_request_slave_channel()/_reason() is for >> drivers only working via DT or ACPI while >> dma_request_slave_channel_compat()/_reason() is for drivers expected to run in >> DT/ACPI or legacy mode as well. >> >> I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci >> drivers are using this to request channels - they need to support DT and >> legacy mode. > I think we should hide these things behind the API and do this behind the > hood for ACPI/DT systems. > > Also it makes sense to use right API and mark rest as depricated So to convert the dma_request_slave_channel_compat() and not to create _reason variant? Or to have single API to request channel? The problem with that is that we need different parameters for legacy and DT for example. >> >> But it is doable to do this for both the non _compat and _compat version: >> 1. change all users to check IS_ERR_OR_NULL(chan) >> return the PTR_ERR if not NULL, or do whatever the driver was doing in case >> of chan == NULL. >> 2. change the non _compat and _compat versions to do the same as the _reason >> variants, #define the _reason ones to the non _reason names >> 3. Rename the _reason use to non _reason function in drivers >> 4. Remove the #defines for the _reason functions >> 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers >> The result: >> Both dma_request_slave_channel() and dma_request_slave_channel_compat() will >> return ERR_PTR in case of failure or in success they will return the pinter to >> chan. >> >> Is this what you were asking? >> It is a bit broader than what this series was doing: taking care of >> OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) > Yes but it would make sense right? I know it is a larger work but then we > wouldn't want another dma_request_slave_xxx API, at some point we have stop > it exapnding, perhpas now :) Yes, it make sense to get rid if the _reason() things and have the dma_request_slave_channel() and dma_request_slave_channel_compat() return with error code One thing we need to do for this is to change the error codes coming back from the _dt() and _acpi() calls when we boot in legacy mode. Right now the only error code which comes back is -ENODEV and -EPROBE_DEFER. We need to differentiate between 'real' errors and from the fact that we did not booted with DT or the ACPI is not available. IMHO if we boot with DT and the channel request fails with other than -EPROBE_DEFER we should not go and try to get the channel via legacy API. > Yes I am all ears to stage this work and not do transition gardually.. > -- Péter
next prev parent reply other threads:[~2015-06-04 15:58 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 [this message] 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 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=5570758E.6030302@ti.com \ --to=peter.ujfalusi@ti.com \ --cc=alsa-devel@alsa-project.org \ --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.