From: Vinod Koul <vinod.koul@intel.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
andriy.shevchenko@intel.com, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH V4] dma: add channel request API that supports deferred probe
Date: Tue, 10 Dec 2013 17:51:59 +0530 [thread overview]
Message-ID: <20131210122159.GJ29580@intel.com> (raw)
In-Reply-To: <1385485462-30376-1-git-send-email-swarren@wwwdotorg.org>
On Tue, Nov 26, 2013 at 10:04:22AM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> dma_request_slave_channel() simply returns NULL whenever DMA channel
> lookup fails. Lookup could fail for two distinct reasons:
>
> a) No DMA specification exists for the channel name.
> This includes situations where no DMA specifications exist at all, or
> other general lookup problems.
>
> b) A DMA specification does exist, yet the driver for that channel is not
> yet registered.
>
> Case (b) should trigger deferred probe in client drivers. However, since
> they have no way to differentiate the two situations, it cannot.
>
> Implement new function dma_request_slave_channel_reason(), which performs
> identically to dma_request_slave_channel(), except that it returns an
> error-pointer rather than NULL, which allows callers to detect when
> deferred probe should occur.
>
> Eventually, all drivers should be converted to this new API, the old API
> removed, and the new API renamed to the more desirable name. This patch
> doesn't convert the existing API and all drivers in one go, since some
> drivers call dma_request_slave_channel() then dma_request_channel() if
> that fails. That would require either modifying dma_request_channel() in
> the same way, or adding extra error-handling code to all affected
> drivers, and there are close to 100 drivers using the other API, rather
> than just the 15-20 or so that use dma_request_slave_channel(), which
> might be tenable in a single patch.
>
> acpi_dma_request_slave_chan_by_name() doesn't currently implement
> deferred probe. It should, but this will be addressed later.
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Applied, to topic/defer_probe, this wont be rebased so feel free to merge
--
~Vinod
next prev parent reply other threads:[~2013-12-10 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 17:04 [PATCH V4] dma: add channel request API that supports deferred probe Stephen Warren
2013-12-03 17:50 ` Stephen Warren
2013-12-10 12:21 ` Vinod Koul [this message]
2013-12-10 17:34 ` Stephen Warren
2013-12-11 11:14 ` 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=20131210122159.GJ29580@intel.com \
--to=vinod.koul@intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).