From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, Vinod Koul <vinod.koul@intel.com>
Cc: <andy.shevchenko@gmail.com>, <linux-kernel@vger.kernel.org>,
<dmaengine@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mmc@vger.kernel.org>, <nsekhar@ti.com>,
<linux-spi@vger.kernel.org>
Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 2 Dec 2015 14:29:33 +0200 [thread overview]
Message-ID: <565EE42D.2030705@ti.com> (raw)
In-Reply-To: <3124382.EhiMyQGKTA@wuerfel>
On 12/01/2015 10:17 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
>> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
>>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
>>> it will use a filter lookup table and retrieves the needed information from
>>> the dma_filter_map provided by the DMA drivers.
>>
>> That sounds right, for the third case would the arch, driver or someone else
>> configure this?
>
> The typical case is for the configuration to be defined in arch or platform
> code and passed down to the dmaengine driver.
>
> I just noticed that the text above (and probably the code too) should
> be changed so we always fall back to this. There are cases where the
> platform is booted with DT in principle, but the DMA engine does not
> (yet) use DT and still wants to be converted. I think we can easily
> handle that case by always trying this if the other methods fail.
Yes, it was intentional actually to not fall back to legacy lookup. With the
dma_request_slave_channel_compat() I have had cases when the DT binding was
not correct - or actually when trying to get deferred working that the code
would fall back to legacy mode and it got me a channel which is not usable.
I did not know that we have platforms booting in DT but the dma binding is not
working so it uses other method to get channel.
I think, if we allow the fall back within dma_request_chan() it would not
cause the same issue as the dma_request_slave_channel_compat() did as long as
we are not providing the lookup table on DT booted cases when the DMA binding
is working correctly.
Let me see the flow, but I think it is doable.
--
Péter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, Vinod Koul <vinod.koul@intel.com>
Cc: andy.shevchenko@gmail.com, linux-kernel@vger.kernel.org,
dmaengine@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
nsekhar@ti.com, linux-spi@vger.kernel.org
Subject: Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 2 Dec 2015 14:29:33 +0200 [thread overview]
Message-ID: <565EE42D.2030705@ti.com> (raw)
In-Reply-To: <3124382.EhiMyQGKTA@wuerfel>
On 12/01/2015 10:17 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
>> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
>>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
>>> it will use a filter lookup table and retrieves the needed information from
>>> the dma_filter_map provided by the DMA drivers.
>>
>> That sounds right, for the third case would the arch, driver or someone else
>> configure this?
>
> The typical case is for the configuration to be defined in arch or platform
> code and passed down to the dmaengine driver.
>
> I just noticed that the text above (and probably the code too) should
> be changed so we always fall back to this. There are cases where the
> platform is booted with DT in principle, but the DMA engine does not
> (yet) use DT and still wants to be converted. I think we can easily
> handle that case by always trying this if the other methods fail.
Yes, it was intentional actually to not fall back to legacy lookup. With the
dma_request_slave_channel_compat() I have had cases when the DT binding was
not correct - or actually when trying to get deferred working that the code
would fall back to legacy mode and it got me a channel which is not usable.
I did not know that we have platforms booting in DT but the dma binding is not
working so it uses other method to get channel.
I think, if we allow the fall back within dma_request_chan() it would not
cause the same issue as the dma_request_slave_channel_compat() did as long as
we are not providing the lookup table on DT booted cases when the DMA binding
is working correctly.
Let me see the flow, but I think it is doable.
--
Péter
WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Date: Wed, 2 Dec 2015 14:29:33 +0200 [thread overview]
Message-ID: <565EE42D.2030705@ti.com> (raw)
In-Reply-To: <3124382.EhiMyQGKTA@wuerfel>
On 12/01/2015 10:17 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
>> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
>>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
>>> it will use a filter lookup table and retrieves the needed information from
>>> the dma_filter_map provided by the DMA drivers.
>>
>> That sounds right, for the third case would the arch, driver or someone else
>> configure this?
>
> The typical case is for the configuration to be defined in arch or platform
> code and passed down to the dmaengine driver.
>
> I just noticed that the text above (and probably the code too) should
> be changed so we always fall back to this. There are cases where the
> platform is booted with DT in principle, but the DMA engine does not
> (yet) use DT and still wants to be converted. I think we can easily
> handle that case by always trying this if the other methods fail.
Yes, it was intentional actually to not fall back to legacy lookup. With the
dma_request_slave_channel_compat() I have had cases when the DT binding was
not correct - or actually when trying to get deferred working that the code
would fall back to legacy mode and it got me a channel which is not usable.
I did not know that we have platforms booting in DT but the dma binding is not
working so it uses other method to get channel.
I think, if we allow the fall back within dma_request_chan() it would not
cause the same issue as the dma_request_slave_channel_compat() did as long as
we are not providing the lookup table on DT booted cases when the DMA binding
is working correctly.
Let me see the flow, but I think it is doable.
--
P?ter
next prev parent reply other threads:[~2015-12-02 12:30 UTC|newest]
Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 13:45 [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask() Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 14:35 ` Andy Shevchenko
2015-11-30 14:35 ` Andy Shevchenko
2015-11-30 14:35 ` Andy Shevchenko
2015-12-01 9:47 ` Peter Ujfalusi
2015-12-01 9:47 ` Peter Ujfalusi
2015-12-01 12:58 ` Andy Shevchenko
2015-12-01 12:58 ` Andy Shevchenko
2015-12-01 17:06 ` Vinod Koul
2015-12-01 17:06 ` Vinod Koul
2015-11-30 13:45 ` [RFC v02 02/15] dmaengine: core: Move and merge the code paths using private_candidate Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 14:42 ` Andy Shevchenko
2015-11-30 14:42 ` Andy Shevchenko
2015-12-01 8:41 ` Peter Ujfalusi
2015-12-01 8:41 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 14:09 ` Arnd Bergmann
2015-11-30 14:09 ` Arnd Bergmann
2015-11-30 14:09 ` Arnd Bergmann
2015-12-01 9:48 ` Peter Ujfalusi
2015-12-01 9:48 ` Peter Ujfalusi
2015-12-01 9:48 ` Peter Ujfalusi
2015-11-30 14:51 ` Andy Shevchenko
2015-11-30 14:51 ` Andy Shevchenko
2015-11-30 14:51 ` Andy Shevchenko
2015-12-01 9:56 ` Peter Ujfalusi
2015-12-01 9:56 ` Peter Ujfalusi
2015-12-01 10:07 ` Andy Shevchenko
2015-12-01 10:07 ` Andy Shevchenko
2015-11-30 15:51 ` Tony Lindgren
2015-11-30 15:51 ` Tony Lindgren
2015-11-30 15:51 ` Tony Lindgren
2015-12-01 8:13 ` Peter Ujfalusi
2015-12-01 8:13 ` Peter Ujfalusi
2015-12-01 8:13 ` Peter Ujfalusi
2015-12-01 17:00 ` Tony Lindgren
2015-12-01 17:00 ` Tony Lindgren
2015-12-02 10:00 ` Peter Ujfalusi
2015-12-02 10:00 ` Peter Ujfalusi
2015-12-02 10:00 ` Peter Ujfalusi
2015-12-02 10:00 ` Peter Ujfalusi
2015-12-02 15:00 ` Tony Lindgren
2015-12-02 15:00 ` Tony Lindgren
2015-12-02 15:00 ` Tony Lindgren
2015-11-30 13:45 ` [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 14:11 ` Arnd Bergmann
2015-11-30 14:11 ` Arnd Bergmann
2015-12-01 9:58 ` Peter Ujfalusi
2015-12-01 9:58 ` Peter Ujfalusi
2015-12-01 9:58 ` Peter Ujfalusi
2015-12-01 10:14 ` Arnd Bergmann
2015-12-01 10:14 ` Arnd Bergmann
2015-12-01 17:22 ` Vinod Koul
2015-12-01 17:22 ` Vinod Koul
2015-12-01 20:20 ` Arnd Bergmann
2015-12-01 20:20 ` Arnd Bergmann
2015-12-01 20:20 ` Arnd Bergmann
2015-12-02 4:37 ` Vinod Koul
2015-12-02 4:37 ` Vinod Koul
2015-12-02 4:37 ` Vinod Koul
2015-12-02 10:02 ` Peter Ujfalusi
2015-12-02 10:02 ` Peter Ujfalusi
2015-12-02 10:02 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 05/15] ARM: davinci: devices-da8xx: Add dma_filter_map to edma Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 06/15] ARM: davinci: dm355: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 07/15] ARM: davinci: dm365: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 08/15] ARM: davinci: dm644x: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 09/15] ARM: davinci: dm646x: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 10/15] mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 11/15] spi: davinci: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2016-05-02 11:04 ` Applied "spi: davinci: Use dma_request_chan() for requesting DMA channel" to the spi tree Mark Brown
2016-05-02 11:04 ` Mark Brown
2015-11-30 13:45 ` [RFC v02 12/15] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 13/15] ARM: davinci: devices: Remove DMA resources for MMC Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 14/15] ARM: davinci: dm355: Remove DMA resources for SPI Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` [RFC v02 15/15] ARM: davinci: dm365: " Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 13:45 ` Peter Ujfalusi
2015-11-30 14:18 ` [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann
2015-11-30 14:18 ` Arnd Bergmann
2015-12-01 10:12 ` Peter Ujfalusi
2015-12-01 10:12 ` Peter Ujfalusi
2015-12-01 10:12 ` Peter Ujfalusi
2015-12-01 10:12 ` Peter Ujfalusi
2015-12-01 10:15 ` Arnd Bergmann
2015-12-01 10:15 ` Arnd Bergmann
2015-12-01 10:15 ` Arnd Bergmann
2015-11-30 14:32 ` Andy Shevchenko
2015-11-30 14:32 ` Andy Shevchenko
2015-12-01 13:45 ` Peter Ujfalusi
2015-12-01 13:45 ` Peter Ujfalusi
2015-12-01 14:24 ` Arnd Bergmann
2015-12-01 14:24 ` Arnd Bergmann
2015-12-02 10:51 ` Peter Ujfalusi
2015-12-02 10:51 ` Peter Ujfalusi
2015-12-02 13:38 ` Arnd Bergmann
2015-12-02 13:38 ` Arnd Bergmann
2015-12-02 13:38 ` Arnd Bergmann
2015-12-01 16:59 ` Vinod Koul
2015-12-01 16:59 ` Vinod Koul
2015-12-01 16:59 ` Vinod Koul
2015-12-01 20:17 ` Arnd Bergmann
2015-12-01 20:17 ` Arnd Bergmann
2015-12-01 20:17 ` Arnd Bergmann
2015-12-02 4:52 ` Vinod Koul
2015-12-02 4:52 ` Vinod Koul
2015-12-02 8:23 ` Arnd Bergmann
2015-12-02 8:23 ` Arnd Bergmann
2015-12-02 12:29 ` Peter Ujfalusi [this message]
2015-12-02 12:29 ` Peter Ujfalusi
2015-12-02 12:29 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=565EE42D.2030705@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.