Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address

On Wed, Nov 18, 2015 at 2:38 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 11:35:27 Andy Shevchenko wrote: >> On Fri, Nov 13, 2015 at 11:35 AM, Arnd Bergmann wrote: >> > On Friday 13 November 2015 03:10:13 Andy Shevchenko wrote: >> >> On Thu, Nov 12, 2015

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] mmc: dw_mmc: use resource_size_t to store physical address

On Wednesday 18 November 2015 17:29:19 Andy Shevchenko wrote: > > I understand most of the things here, what I don't is how a platform > is supposed to work if you have the following: > a) HW, that uses register space let's say higher than 32-bit; > b) DMA engine, which should provide a DMA

Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address

On Wed, Nov 18, 2015 at 5:45 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:29:19 Andy Shevchenko wrote: >> >> I understand most of the things here, what I don't is how a platform >> is supposed to work if you have the following: >> a) HW, that uses register space

Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address

On Wednesday 18 November 2015 18:17:32 Andy Shevchenko wrote: > On Wed, Nov 18, 2015 at 5:45 PM, Arnd Bergmann wrote: > > On Wednesday 18 November 2015 17:29:19 Andy Shevchenko wrote: > >> For me it clearly looks like a platform (HW / SW) configuration issue. > > > > I think some

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] mmc: dw_mmc: use resource_size_t to store physical address

On Wed, Nov 18, 2015 at 6:22 PM, Arnd Bergmann wrote: > On Wednesday 18 November 2015 18:17:32 Andy Shevchenko wrote: >> On Wed, Nov 18, 2015 at 5:45 PM, Arnd Bergmann wrote: >> > On Wednesday 18 November 2015 17:29:19 Andy Shevchenko wrote: > >> >> For me it

Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address

On Wednesday 18 November 2015 11:35:27 Andy Shevchenko wrote: > On Fri, Nov 13, 2015 at 11:35 AM, Arnd Bergmann wrote: > > On Friday 13 November 2015 03:10:13 Andy Shevchenko wrote: > >> On Thu, Nov 12, 2015 at 4:14 PM, Arnd Bergmann wrote: > >> > The dw_mmc driver

Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

On 18 November 2015 at 02:38, Stephen Boyd wrote: > On 11/16, Ulf Hansson wrote: >> [...] >> >> >> > >> > In case you're wondering, the max frequency for sdc1 on 8974ac is >> > 400MHz. If it's just a plain 8974pro then the max frequency is >> > 200MHz. Otherwise, sdc2 maxes

[PATCH] mmc: sdhci: Fix strings broken across multiple lines

This is a trivial patch which fixes printed strings split across two or more lines in the source. I tried to grep for some error output*, but I couldn't find it easily because it was broken across multiple lines. This patch makes my life easier. * in particular "Timeout waiting for hardware

Re: [PATCH] mmc: dw_mmc: use resource_size_t to store physical address

On Fri, Nov 13, 2015 at 11:35 AM, Arnd Bergmann wrote: > On Friday 13 November 2015 03:10:13 Andy Shevchenko wrote: >> On Thu, Nov 12, 2015 at 4:14 PM, Arnd Bergmann wrote: >> > The dw_mmc driver stores the physical address of the MMIO registers >> > in a pointer,

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 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 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