[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VeYanNJrEyTtcxb5g5DB8=609nebgZm8zVAeJdmSgHjkQ@mail.gmail.com>
Date: Sat, 7 Mar 2015 21:43:35 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Stanimir Varbanov <stanimir.varbanov@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-spi@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Kumar Gala <galak@...eaurora.org>,
Andy Gross <agross@...eaurora.org>,
Sagar Dharia <sdharia@...eaurora.org>,
Daniel Sneddon <dsneddon@...eaurora.org>
Subject: Re: [PATCH v4] spi: qup: Add DMA capabilities
On Sat, Mar 7, 2015 at 1:21 PM, Mark Brown <broonie@...nel.org> wrote:
> On Wed, Mar 04, 2015 at 12:02:05PM +0200, Stanimir Varbanov wrote:
>> From: Andy Gross <agross@...eaurora.org>
>>
>> This patch adds DMA capabilities to the spi-qup driver. If DMA channels are
>> present, the QUP will use DMA instead of block mode for transfers to/from SPI
>> peripherals for transactions larger than the length of a block.
>
> Applied, but why is there no devm_dma_request_slave_channel_reason()?
I suppose the answer would be "we have a lot of slightly different
cases and we have to get rid of current mess with legacy API calls".
The most problematic stuff now inside DMA slave subsystem is so called
"filter function". It's a main impediment right now as I understand.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists