On 11/26/2013 09:44 AM, Dan Williams wrote: > On Tue, Nov 26, 2013 at 8:37 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> 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 <swarren@xxxxxxxxxx> >>>> >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
