From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
Tony Lindgren <tony@atomide.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>,
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: Mon, 22 Jun 2015 14:31:00 +0300 [thread overview]
Message-ID: <5587F1F4.1060905@ti.com> (raw)
In-Reply-To: <20150612125837.GJ28601@localhost>
On 06/12/2015 03:58 PM, Vinod Koul wrote:
> Sorry this slipped thru
I was away for a week anyways ;)
> Thinking about it again, I think we should coverge to two APIs and mark the
> legacy depracuated and look to convert folks and phase that out
Currently, w/o this series we have these APIs:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* NULL on failure */
dma_request_slave_channel_reason(dev, name) /* error code on failure */
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel(mask, fn, fn_param) /* NULL on failure */
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* NULL on
failure */
To request _any_ channel to be used for memcpy one has to use
dma_request_channel(mask, NULL, NULL);
If I did not missed something.
As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI
lookup) and the good API names are already taken, we might need to settle:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* error code on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Mark dma_request_slave_channel_reason() deprecated and convert the current users
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code
on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Do not try legacy mode if either OF or ACPI failed because of real error
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */
- convert users of dma_request_channel()
- mark dma_request_channel() deprecated
/* to be used to get a channel for memcpy for example */
dma_request_any_channel(mask) /* error code on failure */
- Convert current dma_request_channel(mask, NULL, NULL) users
I know, any of the other function could be prepared to handle this when
parameters are missing, but it is a bit cleaner to have separate API for this.
It would be nice to find another name for the
dma_request_slave_channel_compat() so with the new name we could have chance
to rearrange the parameters: (dev, name, mask, fn, fn_param)
We would end up with the following APIs, all returning with error code on failure:
dma_request_slave_channel(dev, name);
dma_request_channel_legacy(mask, fn, fn_param);
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
dma_request_any_channel(mask);
What do you think?
--
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: Mon, 22 Jun 2015 14:31:00 +0300 [thread overview]
Message-ID: <5587F1F4.1060905@ti.com> (raw)
In-Reply-To: <20150612125837.GJ28601@localhost>
On 06/12/2015 03:58 PM, Vinod Koul wrote:
> Sorry this slipped thru
I was away for a week anyways ;)
> Thinking about it again, I think we should coverge to two APIs and mark the
> legacy depracuated and look to convert folks and phase that out
Currently, w/o this series we have these APIs:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* NULL on failure */
dma_request_slave_channel_reason(dev, name) /* error code on failure */
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel(mask, fn, fn_param) /* NULL on failure */
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* NULL on
failure */
To request _any_ channel to be used for memcpy one has to use
dma_request_channel(mask, NULL, NULL);
If I did not missed something.
As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI
lookup) and the good API names are already taken, we might need to settle:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* error code on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Mark dma_request_slave_channel_reason() deprecated and convert the current users
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code
on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Do not try legacy mode if either OF or ACPI failed because of real error
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */
- convert users of dma_request_channel()
- mark dma_request_channel() deprecated
/* to be used to get a channel for memcpy for example */
dma_request_any_channel(mask) /* error code on failure */
- Convert current dma_request_channel(mask, NULL, NULL) users
I know, any of the other function could be prepared to handle this when
parameters are missing, but it is a bit cleaner to have separate API for this.
It would be nice to find another name for the
dma_request_slave_channel_compat() so with the new name we could have chance
to rearrange the parameters: (dev, name, mask, fn, fn_param)
We would end up with the following APIs, all returning with error code on failure:
dma_request_slave_channel(dev, name);
dma_request_channel_legacy(mask, fn, fn_param);
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
dma_request_any_channel(mask);
What do you think?
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
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: Mon, 22 Jun 2015 14:31:00 +0300 [thread overview]
Message-ID: <5587F1F4.1060905@ti.com> (raw)
In-Reply-To: <20150612125837.GJ28601@localhost>
On 06/12/2015 03:58 PM, Vinod Koul wrote:
> Sorry this slipped thru
I was away for a week anyways ;)
> Thinking about it again, I think we should coverge to two APIs and mark the
> legacy depracuated and look to convert folks and phase that out
Currently, w/o this series we have these APIs:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* NULL on failure */
dma_request_slave_channel_reason(dev, name) /* error code on failure */
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel(mask, fn, fn_param) /* NULL on failure */
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* NULL on
failure */
To request _any_ channel to be used for memcpy one has to use
dma_request_channel(mask, NULL, NULL);
If I did not missed something.
As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI
lookup) and the good API names are already taken, we might need to settle:
/* to be used with DT/ACPI */
dma_request_slave_channel(dev, name) /* error code on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Mark dma_request_slave_channel_reason() deprecated and convert the current users
/* to be used with DT/ACPI or legacy boot */
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code
on failure */
- Convert users to check IS_ERR_OR_NULL() instead against NULL
- Do not try legacy mode if either OF or ACPI failed because of real error
/* Legacy mode only - no DT/ACPI lookup */
dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */
- convert users of dma_request_channel()
- mark dma_request_channel() deprecated
/* to be used to get a channel for memcpy for example */
dma_request_any_channel(mask) /* error code on failure */
- Convert current dma_request_channel(mask, NULL, NULL) users
I know, any of the other function could be prepared to handle this when
parameters are missing, but it is a bit cleaner to have separate API for this.
It would be nice to find another name for the
dma_request_slave_channel_compat() so with the new name we could have chance
to rearrange the parameters: (dev, name, mask, fn, fn_param)
We would end up with the following APIs, all returning with error code on failure:
dma_request_slave_channel(dev, name);
dma_request_channel_legacy(mask, fn, fn_param);
dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
dma_request_any_channel(mask);
What do you think?
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
next prev parent reply other threads:[~2015-06-22 11:31 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 [this message]
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=5587F1F4.1060905@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: link
Be 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.