Thread (58 messages) 58 messages, 10 authors, 2015-11-20

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

From: Vinod Koul <hidden>
Date: 2015-06-12 12:57:21
Also in: alsa-devel, linux-crypto, linux-media, linux-mmc, linux-omap, linux-serial, linux-spi, lkml

On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote:
Vinod,

On 06/02/2015 03:55 PM, Vinod Koul wrote:
quoted
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
quoted
On 05/29/2015 01:18 PM, Vinod Koul wrote:
quoted
On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
quoted
On Fri, May 29, 2015 at 11:33 AM, Vinod Koul [off-list ref] wrote:
quoted
On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
quoted
dma_request_slave_channel_compat() 'eats' up the returned error codes which
prevents drivers using the compat call to be able to do deferred probing.

The new wrapper is identical in functionality but it will return with error
code in case of failure and will pass the -EPROBE_DEFER to the caller in
case dma_request_slave_channel_reason() returned with it.
This is okay but am worried about one more warpper, how about fixing
dma_request_slave_channel_compat()
Then all callers of dma_request_slave_channel_compat() have to be
modified to handle ERR_PTR first.

The same is true for (the existing) dma_request_slave_channel_reason()
vs. dma_request_slave_channel().
Good point, looking again, I think we should rather fix
dma_request_slave_channel_reason() as it was expected to return err code and
add new users. Anyway users of this API do expect the reason...
Hrm, they are for different use.dma_request_slave_channel()/_reason() is for
drivers only working via DT or ACPI while
dma_request_slave_channel_compat()/_reason() is for drivers expected to run in
DT/ACPI or legacy mode as well.

I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci
drivers are using this to request channels - they need to support DT and
legacy mode.
I think we should hide these things behind the API and do this behind the
hood for ACPI/DT systems.

Also it makes sense to use right API and mark rest as depricated
So to convert the dma_request_slave_channel_compat() and not to create _reason
variant?

Or to have single API to request channel? The problem with that is that we
need different parameters for legacy and DT for example.
Sorry this slipped thru

Thinking about it again, I think we should coverge to two APIs and mark the
legacy depracuated and look to convert folks and phase that out


-- 
~Vinod
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help