From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH V3] dma: add channel request API that supports deferred probe Date: Thu, 05 Dec 2013 09:59:16 -0700 Message-ID: <52A0B0E4.7000204@wwwdotorg.org> References: <1385416039-3170-1-git-send-email-swarren@wwwdotorg.org> <1385474368.1871.6.camel@smile> <5294CE5C.1090901@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dan Williams , "Koul, Vinod" Cc: "Shevchenko, Andriy" , Stephen Warren , "treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" , "pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 11/26/2013 09:44 AM, Dan Williams wrote: > On Tue, Nov 26, 2013 at 8:37 AM, Stephen Warren wrote: >> On 11/26/2013 06:59 AM, Shevchenko, Andriy wrote: >>> On Mon, 2013-11-25 at 14:47 -0700, Stephen Warren wrote: >>>> From: Stephen Warren >>>> >>>> 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_or_err(), 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. ... >> OK, I've fixed that up locally. I assume it's not worth a repost just >> for that change, although I will repost if the DMA maintainers want to >> create the topic branches rather than me, but there's been no word on >> that yet. > > That might be best and Vinod should be back. Vinod do you want to > queue this one up to a topic branch so that the arm-soc tree can pull > it? Vinod, V4 of this patch addressed Dan's final minor comments on this patch. Does it look OK to you? If you could apply it to a topic branch[1] soon, that would be extremely helpful; I'm waiting for this patch (and also "dma: add dma_get_any_slave_channel(), for use in of_xlate()") in order to apply a lot of others. [1] see notes I posted in the patch: This patch is a dependency for: * A series that reworks many of the Tegra drivers. * A series that enhances ASoC's dmaengine code to support deferred probe. As such, it needs to go into a topic branch on its own, based directly on 3.13-rc1. If the DMA maintainers ack the patches I'm happy to create this topic branch myself and send a pull request to the DMA tree. Or the patches can be applied to a topic branch by the DMA maintainers and I will merge their topic branch into the Tegra rework branch that I mentioned. Thanks.