Re: [RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

2015-12-02 Thread Andy Shevchenko
On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi wrote: > Hi, > > I keep this still as RFC. > > Changes since RFC v02: > - Using has_acpi_companion() instead ACPI_HANDLE() > - mask matching change within private_candidate() > - Fallback in dma_request_chan() when DT/ACPI lookup fails. > - Rename

[RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

2015-12-02 Thread Peter Ujfalusi
Hi, I keep this still as RFC. Changes since RFC v02: - Using has_acpi_companion() instead ACPI_HANDLE() - mask matching change within private_candidate() - Fallback in dma_request_chan() when DT/ACPI lookup fails. - Rename dma_get_channel() -> find_candidate() - Arch code changes as suggested by

Re: [RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

2015-12-02 Thread Andy Shevchenko
On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi wrote: > Hi, > > I keep this still as RFC. > > Changes since RFC v02: > - Using has_acpi_companion() instead ACPI_HANDLE() > - mask matching change within private_candidate() > - Fallback in dma_request_chan() when DT/ACPI

[RFC v03 00/15] dmaengine: New 'universal' API for requesting channel

2015-12-02 Thread Peter Ujfalusi
Hi, I keep this still as RFC. Changes since RFC v02: - Using has_acpi_companion() instead ACPI_HANDLE() - mask matching change within private_candidate() - Fallback in dma_request_chan() when DT/ACPI lookup fails. - Rename dma_get_channel() -> find_candidate() - Arch code changes as suggested by