All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: vinod.koul@intel.com, andy.shevchenko@gmail.com,
	linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	nsekhar@ti.com, tony@atomide.com
Subject: Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel
Date: Thu, 3 Dec 2015 17:42:31 +0200	[thread overview]
Message-ID: <566062E7.2020705@ti.com> (raw)
In-Reply-To: <6922343.04ZpTXZq7O@wuerfel>

On 12/03/2015 05:32 PM, Arnd Bergmann wrote:
> On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:       pointer to client device structure
>> + * @name:      slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +       struct dma_device *d, *_d;
>> +       struct dma_chan *chan = NULL;
>> +
>> +       /* If device-tree is present get slave info from here */
>> +       if (dev->of_node)
>> +               chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +       /* If device was enumerated by ACPI get slave info from here */
>> +       if (has_acpi_companion(dev) && !chan)
>> +               chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> I just noticed that you are creating this as a new interface, rather than
> changing dma_request_slave_channel_reason() and making the old interface
> a static inline wrapper. What is the reasoning behind that?

Oh, it was in my plans. Will do it for v02

> I think if we make both interfaces do the same thing, it's easier
> to do the migration.
> 
>> +       if (chan) {
>> +               /* Valid channel found */
>> +               if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
>> +                       return chan;
>> +
>> +               pr_warn("%s: %s DMA request failed, falling back to legacy\n",
>> +                       __func__, dev->of_node ? "OF" : "ACPI");
>> +       }
> 
> Maybe print the error code as well?

Or remove the print altogether?
In a healthy system we will either get the channel or the EPROBE_DEFER, in
case of the platforms where the DT lookup does not work we expect errors and
it is 'normal'.
I think if we fail via DT/ACPI and we fail with legacy also then the client
driver will say something about it anyways, or deal with it as it see fits.

-- 
Péter

WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel
Date: Thu, 3 Dec 2015 17:42:31 +0200	[thread overview]
Message-ID: <566062E7.2020705@ti.com> (raw)
In-Reply-To: <6922343.04ZpTXZq7O@wuerfel>

On 12/03/2015 05:32 PM, Arnd Bergmann wrote:
> On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:       pointer to client device structure
>> + * @name:      slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +       struct dma_device *d, *_d;
>> +       struct dma_chan *chan = NULL;
>> +
>> +       /* If device-tree is present get slave info from here */
>> +       if (dev->of_node)
>> +               chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +       /* If device was enumerated by ACPI get slave info from here */
>> +       if (has_acpi_companion(dev) && !chan)
>> +               chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> I just noticed that you are creating this as a new interface, rather than
> changing dma_request_slave_channel_reason() and making the old interface
> a static inline wrapper. What is the reasoning behind that?

Oh, it was in my plans. Will do it for v02

> I think if we make both interfaces do the same thing, it's easier
> to do the migration.
> 
>> +       if (chan) {
>> +               /* Valid channel found */
>> +               if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
>> +                       return chan;
>> +
>> +               pr_warn("%s: %s DMA request failed, falling back to legacy\n",
>> +                       __func__, dev->of_node ? "OF" : "ACPI");
>> +       }
> 
> Maybe print the error code as well?

Or remove the print altogether?
In a healthy system we will either get the channel or the EPROBE_DEFER, in
case of the platforms where the DT lookup does not work we expect errors and
it is 'normal'.
I think if we fail via DT/ACPI and we fail with legacy also then the client
driver will say something about it anyways, or deal with it as it see fits.

-- 
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@intel.com>, <andy.shevchenko@gmail.com>,
	<linux-kernel@vger.kernel.org>, <dmaengine@vger.kernel.org>,
	<linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <nsekhar@ti.com>,
	<tony@atomide.com>
Subject: Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel
Date: Thu, 3 Dec 2015 17:42:31 +0200	[thread overview]
Message-ID: <566062E7.2020705@ti.com> (raw)
In-Reply-To: <6922343.04ZpTXZq7O@wuerfel>

On 12/03/2015 05:32 PM, Arnd Bergmann wrote:
> On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:       pointer to client device structure
>> + * @name:      slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +       struct dma_device *d, *_d;
>> +       struct dma_chan *chan = NULL;
>> +
>> +       /* If device-tree is present get slave info from here */
>> +       if (dev->of_node)
>> +               chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +       /* If device was enumerated by ACPI get slave info from here */
>> +       if (has_acpi_companion(dev) && !chan)
>> +               chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> I just noticed that you are creating this as a new interface, rather than
> changing dma_request_slave_channel_reason() and making the old interface
> a static inline wrapper. What is the reasoning behind that?

Oh, it was in my plans. Will do it for v02

> I think if we make both interfaces do the same thing, it's easier
> to do the migration.
> 
>> +       if (chan) {
>> +               /* Valid channel found */
>> +               if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
>> +                       return chan;
>> +
>> +               pr_warn("%s: %s DMA request failed, falling back to legacy\n",
>> +                       __func__, dev->of_node ? "OF" : "ACPI");
>> +       }
> 
> Maybe print the error code as well?

Or remove the print altogether?
In a healthy system we will either get the channel or the EPROBE_DEFER, in
case of the platforms where the DT lookup does not work we expect errors and
it is 'normal'.
I think if we fail via DT/ACPI and we fail with legacy also then the client
driver will say something about it anyways, or deal with it as it see fits.

-- 
Péter

  reply	other threads:[~2015-12-03 15:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 14:33 [PATCH 0/4] dmaengine: New 'universal' API for requesting channel Peter Ujfalusi
2015-12-03 14:33 ` Peter Ujfalusi
2015-12-03 14:33 ` Peter Ujfalusi
2015-12-03 14:33 ` [PATCH 1/4] dmaengine: core: Skip mask matching when it is not provided to private_candidate Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33 ` [PATCH 2/4] dmaengine: core: Move and merge the code paths using private_candidate Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33 ` [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 15:32   ` Arnd Bergmann
2015-12-03 15:32     ` Arnd Bergmann
2015-12-03 15:42     ` Peter Ujfalusi [this message]
2015-12-03 15:42       ` Peter Ujfalusi
2015-12-03 15:42       ` Peter Ujfalusi
2015-12-03 15:45       ` Arnd Bergmann
2015-12-03 15:45         ` Arnd Bergmann
2015-12-03 16:30   ` Andy Shevchenko
2015-12-03 16:30     ` Andy Shevchenko
2015-12-03 14:33 ` [PATCH 4/4] dmaengine: edma: Add support for DMA filter mapping to slave devices Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 14:33   ` Peter Ujfalusi
2015-12-03 15:38   ` Arnd Bergmann
2015-12-03 15:38     ` Arnd Bergmann
2015-12-03 15:46     ` Peter Ujfalusi
2015-12-03 15:46       ` Peter Ujfalusi
2015-12-03 15:46       ` Peter Ujfalusi
2015-12-08 13:15       ` Peter Ujfalusi
2015-12-08 13:15         ` Peter Ujfalusi
2015-12-08 13:15         ` Peter Ujfalusi
2015-12-03 16:32 ` [PATCH 0/4] dmaengine: New 'universal' API for requesting channel Andy Shevchenko
2015-12-03 16:32   ` Andy Shevchenko

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=566062E7.2020705@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --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.