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 clearly looks like a platform (HW / S
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 people have argu
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 let's say higher tha
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 se
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 see. In that case I
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? I
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 nothing useful
(IIRC Russe
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 capabi
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 functionality m
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 at 4:14 PM, Arnd Bergmann wro
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
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 at
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 dma_request_chan
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,
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 stores the physical address of
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 interr
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, which requires the use of type c
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 out at 200Mhz and sdc3
18 matches
Mail list logo