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

On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: > On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > Another idea would be to remove the filter function from struct dma_chan_map > and pass the map through platform

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

On 11/20/2015 02:24 PM, Andy Shevchenko wrote: > On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> Another idea would be to remove the filter function from

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

On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote: > > >> For legacy the filter function is pretty much needed to handle the > >> differences > >> between the platforms as not all of them does the filtering in a same way. > >> So > >> the first type of map would be feasible IMHO. > > >

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

On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi wrote: > On 11/20/2015 02:24 PM, Andy Shevchenko wrote: >> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: On 11/19/2015 01:25 PM, Arnd

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

On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: > On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> dma_request_channel(mask); /* memcpy. etc, non slave mostly */ > >> > >> Not sure how to name this as reusing existing (good, descriptive) function > >> names would mean changes all over

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

On 11/20/2015 12:58 PM, Arnd Bergmann wrote: >>> That way the vast majority of drivers can use one of the two nice interfaces >>> and the rest can be converted to use __dma_request_chan(). >>> >>> On a related topic, we had in the past considered providing a way for >>> platform code to register a

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

On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> If we have two main APIs, one to request slave channels and one to get any >> channel with given capability >> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave >> */ >> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /*

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

On 11/18/2015 05:46 PM, Andy Shevchenko wrote: > On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi wrote: >> Hi Vinod, >> >> bringing this old thread back to life as I just started to work on this. > > What I remember we need to convert drivers to use new API meanwhile it >

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

On Thursday 19 November 2015 12:34:22 Peter Ujfalusi wrote: > > I think we can go with a single API, but I don't really like that: > dma_request_channel(dev, name, *mask, fn, fn_param); > > This would cover all current uses being legacy, DT/ACPI, compat, etc: > dma_request_channel(NULL, NULL, ,

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

On 11/18/2015 05:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: 2. non slave channel requests, where only the functionality matters,

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

On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: >> > >> > I assume that the sst-firmware.c case is a mistake, it should just use a >> > plain DMA_SLAVE and not DMA_MEMCPY. >> >> Other way around. >> > > Ok, I

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

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: > On 11/18/2015 04:29 PM, Arnd Bergmann wrote: > > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > >> 2. non slave channel requests, where only the functionality matters, like > >> memcpy, interleaved, memset, etc. > >> We

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

On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi wrote: > Hi Vinod, > > bringing this old thread back to life as I just started to work on this. What I remember we need to convert drivers to use new API meanwhile it is good to keep old one to avoid patch storm which does

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

On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: >> On 11/18/2015 04:29 PM, Arnd Bergmann wrote: >> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> >> 2. non slave channel requests, where only the

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

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > plain DMA_SLAVE and not DMA_MEMCPY. > > Other way around. > Ok, I see. In that case I guess it also shouldn't call dmaengine_slave_config(), right?

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

On Wed, Nov 18, 2015 at 04:51:54PM +0100, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > > plain DMA_SLAVE and not DMA_MEMCPY. > > > > Other way around. > > > > Ok, I

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

Hi Vinod, bringing this old thread back to life as I just started to work on this. On 06/24/2015 07:24 PM, Vinod Koul wrote: >> We would end up with the following APIs, all returning with error code on >> failure: >> dma_request_slave_channel(dev, name); >> dma_request_channel_legacy(mask, fn,

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

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > 2. non slave channel requests, where only the functionality matters, like > memcpy, interleaved, memset, etc. > We could have a simple: > dma_request_channel(mask); > > But looking at the drivers using dmaengine legacy

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

On 11/18/2015 04:29 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: >> 2. non slave channel requests, where only the functionality matters, like >> memcpy, interleaved, memset, etc. >> We could have a simple: >> dma_request_channel(mask); >> >> But looking

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

On Wednesday 24 June 2015 21:54:01 Vinod Koul wrote: It would be nice to find another name for the dma_request_slave_channel_compat() so with the new name we could have chance to rearrange the parameters: (dev, name, mask, fn, fn_param) We would end up with the following APIs, all

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

On Mon, Jun 22, 2015 at 02:31:00PM +0300, Peter Ujfalusi wrote: On 06/12/2015 03:58 PM, Vinod Koul wrote: Sorry this slipped thru I was away for a week anyways ;) Thinking about it again, I think we should coverge to two APIs and mark the legacy depracuated and look to convert folks

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

On 06/12/2015 03:58 PM, Vinod Koul wrote: Sorry this slipped thru I was away for a week anyways ;) 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 Currently, w/o this series we have these APIs: /* to

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

On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote: Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:

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

Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com

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

On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300,

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

On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: 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

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

On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: 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

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

On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents

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

On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up

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

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