Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1279891 > unrolled thread

[RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

Started byPeter Ujfalusi <peter.ujfalusi@ti.com>
First post2015-11-30 15:00 +0100
Last post2015-12-02 13:40 +0100
Articles 14 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-11-30 15:00 +0100
    Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-11-30 15:20 +0100
      Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-01 11:20 +0100
      Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-01 11:20 +0100
    Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Andy Shevchenko <andy.shevchenko@gmail.com> - 2015-11-30 15:40 +0100
      Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-01 14:50 +0100
        Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-01 15:30 +0100
          Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-02 12:00 +0100
            Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-02 14:40 +0100
    Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Vinod Koul <vinod.koul@intel.com> - 2015-12-01 18:00 +0100
      Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-01 21:20 +0100
        Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Vinod Koul <vinod.koul@intel.com> - 2015-12-02 05:50 +0100
          Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel Arnd Bergmann <arnd@arndb.de> - 2015-12-02 09:30 +0100
        Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting  channel Peter Ujfalusi <peter.ujfalusi@ti.com> - 2015-12-02 13:40 +0100

#1279891 — [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-11-30 15:00 +0100
Subject[RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qAx05-4hY-3@gated-at.bofh.it>
Hi,

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

TODO: Documentation update ;)

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

Andy: I did looked at the unified device properties, but I decided to not to use
it as I don't see it to fit well and most of the legacy board files are using
resources to specify at least their memory regions so adding the DMA resource
to them would be more inline with the rest of the code.

The ARM, mmc and spi patches are converting daVinci drivers board files to use
the new method of requesting DMA channel.

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan() will try to find the
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.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static struct dma_filter_map da830_edma_map[] = {
	DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
	DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
	DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
	DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
	DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
	DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
	DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
	DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
	DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
	DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
	DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
	DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.filter_map = da830_edma_map;
da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to convigure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->filter_map) {
	ecc->dma_slave.filter_map.map = info->filter_map;
	ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
	ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_filter_map to get the channel with the dma_get_channel() internal
function.

Regards,
Peter
---
Peter Ujfalusi (15):
  dmaengine: core: Allow NULL mask pointer in
    __dma_device_satisfies_mask()
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Introduce new, universal API to request a channel
  dmaengine: edma: Add support for DMA filter mapping to slave devices
  ARM: davinci: devices-da8xx: Add dma_filter_map to edma
  ARM: davinci: dm355: Add dma_filter_map to edma
  ARM: davinci: dm365: Add dma_filter_map to edma
  ARM: davinci: dm644x: Add dma_filter_map to edma
  ARM: davinci: dm646x: Add dma_filter_map to edma
  mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel
  spi: davinci: Use dma_request_chan() to requesting DMA channel
  ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
  ARM: davinci: devices: Remove DMA resources for MMC
  ARM: davinci: dm355: Remove DMA resources for SPI
  ARM: davinci: dm365: Remove DMA resources for SPI

 arch/arm/mach-davinci/devices-da8xx.c |  95 ++++++++++----------
 arch/arm/mach-davinci/devices.c       |  19 ----
 arch/arm/mach-davinci/dm355.c         |  28 ++++--
 arch/arm/mach-davinci/dm365.c         |  30 +++++--
 arch/arm/mach-davinci/dm644x.c        |  12 +++
 arch/arm/mach-davinci/dm646x.c        |  11 +++
 drivers/dma/dmaengine.c               | 160 +++++++++++++++++++++++++---------
 drivers/dma/edma.c                    |  24 +++++
 drivers/mmc/host/davinci_mmc.c        |  52 +++--------
 drivers/spi/spi-davinci.c             |  76 +++++-----------
 include/linux/dmaengine.h             |  31 +++++++
 include/linux/platform_data/edma.h    |   5 ++
 12 files changed, 330 insertions(+), 213 deletions(-)

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1279923

FromArnd Bergmann <arnd@arndb.de>
Date2015-11-30 15:20 +0100
Message-ID<qAxt9-4HX-47@gated-at.bofh.it>
In reply to#1279891
On Monday 30 November 2015 15:45:30 Peter Ujfalusi wrote:
> Changes since RFC v01:
>- dma_request_chan(); lost the mask parameter
>- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>  will be used to provide the needed information to the filter function in
>  legacy mode
>- Extended the example patches to convert most of daVinci to use the new API to
>  request the DMA channels.

Very nice overall. Just a few minor comments.

> static struct dma_filter_map da830_edma_map[] = {
>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };

I wonder if we should mandate that the lookup table is 'const'.

We could also drop the DMA_FILTER_ENTRY() macro above, and open-code the
table like

static struct dma_filter_map da830_edma_map[] = {
         { "davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)},
         { "davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)},
         { "davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)},
	 ...
};

which is a little more compact and more obvious, but loses the
named initializers.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280725

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-01 11:20 +0100
Message-ID<qAQcq-8ix-3@gated-at.bofh.it>
In reply to#1279923
On Tuesday 01 December 2015 12:12:47 Peter Ujfalusi wrote:
> 
> We would need:
>         { "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) },
>         { "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) },
> 
> as we need to cast the param.
> It is still compact, but having to add the (void*) casting makes it a bit ugly.

Right, I forgot that, but the cast could also be part of EDMA_CTLR_CHAN(),
and with the version I just posted in my other reply that part is solved
as well.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280730 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-01 11:20 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qAQcq-8ix-5@gated-at.bofh.it>
In reply to#1279923
On 11/30/2015 04:18 PM, Arnd Bergmann wrote:
> On Monday 30 November 2015 15:45:30 Peter Ujfalusi wrote:
>> Changes since RFC v01:
>> - dma_request_chan(); lost the mask parameter
>> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>>  will be used to provide the needed information to the filter function in
>>  legacy mode
>> - Extended the example patches to convert most of daVinci to use the new API to
>>  request the DMA channels.
> 
> Very nice overall. Just a few minor comments.
> 
>> static struct dma_filter_map da830_edma_map[] = {
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
>> };
> 
> I wonder if we should mandate that the lookup table is 'const'.

I had been wondering the same, I'll make it const for the next round.

> We could also drop the DMA_FILTER_ENTRY() macro above, and open-code the
> table like
> 
> static struct dma_filter_map da830_edma_map[] = {
>          { "davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)},
>          { "davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)},
>          { "davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)},
> 	 ...
> };
> 
> which is a little more compact and more obvious, but loses the
> named initializers.

We would need:
	{ "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) },
	{ "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) },

as we need to cast the param.
It is still compact, but having to add the (void*) casting makes it a bit ugly.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1279943

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2015-11-30 15:40 +0100
Message-ID<qAxMu-4Or-17@gated-at.bofh.it>
In reply to#1279891
On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> Hi,
>
> Changes since RFC v01:
> - dma_request_chan(); lost the mask parameter
> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>   will be used to provide the needed information to the filter function in
>   legacy mode
> - Extended the example patches to convert most of daVinci to use the new API to
>   request the DMA channels.
>
> TODO: Documentation update ;)
>
> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
>
> Andy: I did looked at the unified device properties, but I decided to not to use
> it as I don't see it to fit well and most of the legacy board files are using
> resources to specify at least their memory regions so adding the DMA resource
> to them would be more inline with the rest of the code.

We could return back to this in the future, still we have to amend
built-in device properties (there is a patch series already in the
wild).

>
> The ARM, mmc and spi patches are converting daVinci drivers board files to use
> the new method of requesting DMA channel.
>
> With this series I have taken a path which would result two new API, which can
> be used to convert most of the current users already and with some work all
> users might be able to move to this set.
> With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
> longer needed to be exported to client drivers since the selection of the
> correct filter_fn will be done in the core.
>
> So, the first proposal is to have:
>
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>
> The dma_request_chan_by_mask() is to request any channel matching with the
> requested capabilities, can be used to request channel for memcpy, memset, xor,
> etc where no hardware synchronization is needed.
>
> The dma_request_chan() is to request a slave channel. The dma_request_chan() will try to find the
> 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.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:
>
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
>
> static struct dma_filter_map da830_edma_map[] = {
>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),

Does this ".2" and so prevent driver to use auto ID for platform devices?

> };
>
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
>
> da8xx_edma0_pdata.filter_map = da830_edma_map;
> da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);
>
> The DMA driver then needs to convigure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
>
> if (info->filter_map) {
>         ecc->dma_slave.filter_map.map = info->filter_map;
>         ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
>         ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
> }
>
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_filter_map to get the channel with the dma_get_channel() internal
> function.
>
> Regards,
> Peter
> ---
> Peter Ujfalusi (15):
>   dmaengine: core: Allow NULL mask pointer in
>     __dma_device_satisfies_mask()
>   dmaengine: core: Move and merge the code paths using private_candidate
>   dmaengine: core: Introduce new, universal API to request a channel
>   dmaengine: edma: Add support for DMA filter mapping to slave devices
>   ARM: davinci: devices-da8xx: Add dma_filter_map to edma
>   ARM: davinci: dm355: Add dma_filter_map to edma
>   ARM: davinci: dm365: Add dma_filter_map to edma
>   ARM: davinci: dm644x: Add dma_filter_map to edma
>   ARM: davinci: dm646x: Add dma_filter_map to edma
>   mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel
>   spi: davinci: Use dma_request_chan() to requesting DMA channel
>   ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
>   ARM: davinci: devices: Remove DMA resources for MMC
>   ARM: davinci: dm355: Remove DMA resources for SPI
>   ARM: davinci: dm365: Remove DMA resources for SPI
>
>  arch/arm/mach-davinci/devices-da8xx.c |  95 ++++++++++----------
>  arch/arm/mach-davinci/devices.c       |  19 ----
>  arch/arm/mach-davinci/dm355.c         |  28 ++++--
>  arch/arm/mach-davinci/dm365.c         |  30 +++++--
>  arch/arm/mach-davinci/dm644x.c        |  12 +++
>  arch/arm/mach-davinci/dm646x.c        |  11 +++
>  drivers/dma/dmaengine.c               | 160 +++++++++++++++++++++++++---------
>  drivers/dma/edma.c                    |  24 +++++
>  drivers/mmc/host/davinci_mmc.c        |  52 +++--------
>  drivers/spi/spi-davinci.c             |  76 +++++-----------
>  include/linux/dmaengine.h             |  31 +++++++
>  include/linux/platform_data/edma.h    |   5 ++
>  12 files changed, 330 insertions(+), 213 deletions(-)
>
> --
> 2.6.3
>



-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280878 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-01 14:50 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qATtD-1Sb-13@gated-at.bofh.it>
In reply to#1279943
On 11/30/2015 04:32 PM, Andy Shevchenko wrote:
>> Andy: I did looked at the unified device properties, but I decided to not to use
>> it as I don't see it to fit well and most of the legacy board files are using
>> resources to specify at least their memory regions so adding the DMA resource
>> to them would be more inline with the rest of the code.
> 
> We could return back to this in the future, still we have to amend
> built-in device properties (there is a patch series already in the
> wild).

I believe we could have similar dmaengine 'infra' for the built-in device
properties as we have now for DT and ACPI. I need to dig deeper to get full
understanding on the device properties, but from a quick view it looks to me
that it could replace the direct OF and ACPI property handing in a unified
API. I might be totally mistaken here ;)

>> static struct dma_filter_map da830_edma_map[] = {
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> 
> Does this ".2" and so prevent driver to use auto ID for platform devices?

Yes, as all the infra around the traditional board files with platform_device
creation does. Ideally we could have 'phandle' pointing from this table to the
device in question (or other way around), but I'm not aware of anything we can
use.
Auto ID did not really worked for us since the driver does need to know their
ID in some cases, or we need to be able to be sure that for example McASP1 is
handled as davinci-mcasp.1
We have clocks and other dependencies where the device name or device ID need
to be predictable.
It is different in DT cases, but we are talking about legacy things.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280904

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-01 15:30 +0100
Message-ID<qAU6m-2l1-21@gated-at.bofh.it>
In reply to#1280878
On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >> static struct dma_filter_map da830_edma_map[] = {
> >>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> >>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> >>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> >>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> >>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> >>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> >>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> >>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> >>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> >>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> >>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> >>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> > 
> > Does this ".2" and so prevent driver to use auto ID for platform devices?
> 
> Yes, as all the infra around the traditional board files with platform_device
> creation does. Ideally we could have 'phandle' pointing from this table to the
> device in question (or other way around), but I'm not aware of anything we can
> use.

I was thinking that we could use a pointer to the device structure, but
if you have that, you can also just read the name from it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281624 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-02 12:00 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qBdiG-64Q-7@gated-at.bofh.it>
In reply to#1280904
On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
>>>> static struct dma_filter_map da830_edma_map[] = {
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>>>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>>>>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>>>>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>>>>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>>>>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>>>>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>>>>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
>>>
>>> Does this ".2" and so prevent driver to use auto ID for platform devices?
>>
>> Yes, as all the infra around the traditional board files with platform_device
>> creation does. Ideally we could have 'phandle' pointing from this table to the
>> device in question (or other way around), but I'm not aware of anything we can
>> use.
> 
> I was thinking that we could use a pointer to the device structure, but
> if you have that, you can also just read the name from it.

Hrm to have pdev pointer instead of the devname string? In the core we could
get the pdev from the caller's device with to_platform_device(dev) and simply
compare the pointers...

One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
are scattered around in the c files so gathering the pointers to a place where
we can see them to be able to use it in the dma_filter_map is not going to be
light weight task.
Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
and resources from the omap_hwmod data structures so getting out the DMA event
numbers there is not going to be easy either...

I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
with the devname strings here.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281783

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 14:40 +0100
Message-ID<qBfNv-7MJ-7@gated-at.bofh.it>
In reply to#1281624
On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote:
> On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >>>> static struct dma_filter_map da830_edma_map[] = {
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> >>>>         DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> >>>>         DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> >>>>         DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> >>>>         DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> >>>>         DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> >>>>         DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> >>>>         DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> >>>
> >>> Does this ".2" and so prevent driver to use auto ID for platform devices?
> >>
> >> Yes, as all the infra around the traditional board files with platform_device
> >> creation does. Ideally we could have 'phandle' pointing from this table to the
> >> device in question (or other way around), but I'm not aware of anything we can
> >> use.
> > 
> > I was thinking that we could use a pointer to the device structure, but
> > if you have that, you can also just read the name from it.
> 
> Hrm to have pdev pointer instead of the devname string? In the core we could
> get the pdev from the caller's device with to_platform_device(dev) and simply
> compare the pointers...
> 
> One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
> are scattered around in the c files so gathering the pointers to a place where
> we can see them to be able to use it in the dma_filter_map is not going to be
> light weight task.
> Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
> and resources from the omap_hwmod data structures so getting out the DMA event
> numbers there is not going to be easy either...
> 
> I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
> with the devname strings here.

Sorry, what I meant to say above is that I had already concluded that using
device pointers was a bad idea and we should stay with names.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281048 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromVinod Koul <vinod.koul@intel.com>
Date2015-12-01 18:00 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qAWrx-3Jy-25@gated-at.bofh.it>
In reply to#1279891
On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since RFC v01:
> - dma_request_chan(); lost the mask parameter
> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>   will be used to provide the needed information to the filter function in
>   legacy mode
> - Extended the example patches to convert most of daVinci to use the new API to
>   request the DMA channels.

Hi Peter,

Thanks a bunch for fixing this up!

I think overall I am happy with the proposal and aligning with 2 APIs really
_helps_.

> 
> TODO: Documentation update ;)
>
> 
> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
> 
> Andy: I did looked at the unified device properties, but I decided to not to use
> it as I don't see it to fit well and most of the legacy board files are using
> resources to specify at least their memory regions so adding the DMA resource
> to them would be more inline with the rest of the code.

I think that is okay for now, we can align on that eventually. I think this
doesn't impact the API design though..

> 
> The ARM, mmc and spi patches are converting daVinci drivers board files to use
> the new method of requesting DMA channel.
> 
> With this series I have taken a path which would result two new API, which can
> be used to convert most of the current users already and with some work all
> users might be able to move to this set.
> With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
> longer needed to be exported to client drivers since the selection of the
> correct filter_fn will be done in the core.
> 
> So, the first proposal is to have:
> 
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> 
> The dma_request_chan_by_mask() is to request any channel matching with the
> requested capabilities, can be used to request channel for memcpy, memset, xor,
> etc where no hardware synchronization is needed.
> 
> The dma_request_chan() is to request a slave channel. The dma_request_chan() will try to find the
> 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?

> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:

Are you marking the current APIs as dericated in the end of this series

> 
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
> 
> static struct dma_filter_map da830_edma_map[] = {
> 	DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> 	DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> 	DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> 	DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> 	DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> 	DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> 	DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> 	DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };
> 
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
> 
> da8xx_edma0_pdata.filter_map = da830_edma_map;
> da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);
> 
> The DMA driver then needs to convigure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
> 
> if (info->filter_map) {
> 	ecc->dma_slave.filter_map.map = info->filter_map;
> 	ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
> 	ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
> }
> 
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_filter_map to get the channel with the dma_get_channel() internal
> function.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (15):
>   dmaengine: core: Allow NULL mask pointer in
>     __dma_device_satisfies_mask()
>   dmaengine: core: Move and merge the code paths using private_candidate
>   dmaengine: core: Introduce new, universal API to request a channel
>   dmaengine: edma: Add support for DMA filter mapping to slave devices
>   ARM: davinci: devices-da8xx: Add dma_filter_map to edma
>   ARM: davinci: dm355: Add dma_filter_map to edma
>   ARM: davinci: dm365: Add dma_filter_map to edma
>   ARM: davinci: dm644x: Add dma_filter_map to edma
>   ARM: davinci: dm646x: Add dma_filter_map to edma
>   mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel
>   spi: davinci: Use dma_request_chan() to requesting DMA channel
>   ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI
>   ARM: davinci: devices: Remove DMA resources for MMC
>   ARM: davinci: dm355: Remove DMA resources for SPI
>   ARM: davinci: dm365: Remove DMA resources for SPI
> 
>  arch/arm/mach-davinci/devices-da8xx.c |  95 ++++++++++----------
>  arch/arm/mach-davinci/devices.c       |  19 ----
>  arch/arm/mach-davinci/dm355.c         |  28 ++++--
>  arch/arm/mach-davinci/dm365.c         |  30 +++++--
>  arch/arm/mach-davinci/dm644x.c        |  12 +++
>  arch/arm/mach-davinci/dm646x.c        |  11 +++
>  drivers/dma/dmaengine.c               | 160 +++++++++++++++++++++++++---------
>  drivers/dma/edma.c                    |  24 +++++
>  drivers/mmc/host/davinci_mmc.c        |  52 +++--------
>  drivers/spi/spi-davinci.c             |  76 +++++-----------
>  include/linux/dmaengine.h             |  31 +++++++
>  include/linux/platform_data/edma.h    |   5 ++
>  12 files changed, 330 insertions(+), 213 deletions(-)
> 
> -- 
> 2.6.3
> 

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281168

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-01 21:20 +0100
Message-ID<qAZz4-5UF-5@gated-at.bofh.it>
In reply to#1281048
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.

> > This legacy mode needs changes in platform code, in dmaengine drivers and
> > finally the dmaengine user drivers can be converted:
> 
> Are you marking the current APIs as dericated in the end of this series

I think we practically stopped marking things as deprecated in general.
Per Linus decree, whenever we want to get rid of something, we should
instead change all users in tree and then remove the API, expecting
driver maintainers to do something just because you marked it as deprecated
often doesn't work.

I can help out converting a few platforms, maybe one interface at a time.
This is what I see:

arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason dma_request_slave_channel dma_request_slave_channel_compat dma_request_channel  ; do echo `git grep -wl $i drivers/  | grep -v drivers/dma | wc -l`\      $i ; done
14      dma_request_slave_channel_reason
27      dma_request_slave_channel
25      dma_request_slave_channel_compat
34      dma_request_channel

I would probably leave the users of dma_request_channel() while converting
the others, as that is still used by all the platforms that don't use any DT
support.

Changing dma_request_slave_channel_reason and dma_request_slave_channel is
trivial, we can probably use coccinelle for that, as it does not require
any platform changes. That brings us to the users of
dma_request_slave_channel_compat, which currently includes these files:

$ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c
drivers/crypto/atmel-aes.c
drivers/crypto/atmel-sha.c
drivers/crypto/atmel-tdes.c
drivers/crypto/omap-aes.c
drivers/crypto/omap-des.c
drivers/crypto/omap-sham.c
drivers/media/platform/omap3isp/isphist.c
drivers/mmc/host/davinci_mmc.c
drivers/mmc/host/omap.c
drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/pxamci.c
drivers/mmc/host/s3cmci.c
drivers/mmc/host/tmio_mmc_dma.c
drivers/mtd/nand/pxa3xx_nand.c
drivers/net/ethernet/smsc/smc91x.c
drivers/net/irda/pxaficp_ir.c
drivers/spi/spi-omap2-mcspi.c
drivers/spi/spi-pxa2xx-dma.c
drivers/spi/spi-rspi.c
drivers/spi/spi-s3c64xx.c
drivers/spi/spi-sh-msiof.c
drivers/tty/serial/8250/8250_dma.c
drivers/tty/serial/samsung.c
drivers/tty/serial/sh-sci.c
include/linux/dmaengine.h

In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, and s3c
in terms of ARM platforms.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281443 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromVinod Koul <vinod.koul@intel.com>
Date2015-12-02 05:50 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qB7wC-2om-11@gated-at.bofh.it>
In reply to#1281168
On Tue, Dec 01, 2015 at 09:17:06PM +0100, 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.

I agree that this makes sense, not just for DT cases but ACPI as well

> 
> > > This legacy mode needs changes in platform code, in dmaengine drivers and
> > > finally the dmaengine user drivers can be converted:
> > 
> > Are you marking the current APIs as dericated in the end of this series
> 
> I think we practically stopped marking things as deprecated in general.
> Per Linus decree, whenever we want to get rid of something, we should
> instead change all users in tree and then remove the API, expecting
> driver maintainers to do something just because you marked it as deprecated
> often doesn't work.

Yes but while we do conversion we don't know if new users get added which use
old API..

> 
> I can help out converting a few platforms, maybe one interface at a time.

Great yes we all will have to chip in and start removing these, i will try
doing few after new year

Am sure Andy can chip in as well :)

> This is what I see:
> 
> arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason dma_request_slave_channel dma_request_slave_channel_compat dma_request_channel  ; do echo `git grep -wl $i drivers/  | grep -v drivers/dma | wc -l`\      $i ; done
> 14      dma_request_slave_channel_reason
> 27      dma_request_slave_channel
> 25      dma_request_slave_channel_compat
> 34      dma_request_channel
> 
> I would probably leave the users of dma_request_channel() while converting
> the others, as that is still used by all the platforms that don't use any DT
> support.
> 
> Changing dma_request_slave_channel_reason and dma_request_slave_channel is
> trivial, we can probably use coccinelle for that, as it does not require
> any platform changes. That brings us to the users of
> dma_request_slave_channel_compat, which currently includes these files:
> 
> $ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c
> drivers/crypto/atmel-aes.c
> drivers/crypto/atmel-sha.c
> drivers/crypto/atmel-tdes.c
> drivers/crypto/omap-aes.c
> drivers/crypto/omap-des.c
> drivers/crypto/omap-sham.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/mmc/host/davinci_mmc.c
> drivers/mmc/host/omap.c
> drivers/mmc/host/omap_hsmmc.c
> drivers/mmc/host/pxamci.c
> drivers/mmc/host/s3cmci.c
> drivers/mmc/host/tmio_mmc_dma.c
> drivers/mtd/nand/pxa3xx_nand.c
> drivers/net/ethernet/smsc/smc91x.c
> drivers/net/irda/pxaficp_ir.c
> drivers/spi/spi-omap2-mcspi.c
> drivers/spi/spi-pxa2xx-dma.c
> drivers/spi/spi-rspi.c
> drivers/spi/spi-s3c64xx.c
> drivers/spi/spi-sh-msiof.c
> drivers/tty/serial/8250/8250_dma.c
> drivers/tty/serial/samsung.c
> drivers/tty/serial/sh-sci.c
> include/linux/dmaengine.h
> 
> In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, and s3c
> in terms of ARM platforms.
> 
> 	Arnd

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281517

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 09:30 +0100
Message-ID<qBaXv-4EG-3@gated-at.bofh.it>
In reply to#1281443
On Wednesday 02 December 2015 10:22:09 Vinod Koul wrote:
> > 
> > > > This legacy mode needs changes in platform code, in dmaengine drivers and
> > > > finally the dmaengine user drivers can be converted:
> > > 
> > > Are you marking the current APIs as dericated in the end of this series
> > 
> > I think we practically stopped marking things as deprecated in general.
> > Per Linus decree, whenever we want to get rid of something, we should
> > instead change all users in tree and then remove the API, expecting
> > driver maintainers to do something just because you marked it as deprecated
> > often doesn't work.
> 
> Yes but while we do conversion we don't know if new users get added which use
> old API..

We probably don't need to worry about new users of dma_request_channel(),
as we don't add new ARM platforms without DT, and other architectures
don't add a lot of new platforms. Similarly, I don't expect a whole lot
of dma_request_slave_channel_compat() users, because the conversion from
board files to DT based booting has slowed down a lot after most of the
actively maintained platforms are done with it.

If you do a one-line patch to add dma_request_chan() as an alias for
dma_request_slave_channel_reason() now, we can probably convert most
users of dma_request_slave_channel() and dma_request_slave_channel_reason()
to dma_request_chan() in the next merge window and do a patch to
replace the few remaining ones and remove the API one merge window later.

If wewant to stage out the conversion of the
dma_request_slave_channel_compat() and dma_request_channel() similarly,
it would be good to have all the interface changes for the dmaengine
core basically in place, so we can start to convert the platforms
independently for the 4.5 merge window without having a dependency on
dmaengine patches. It's probably best to not convert a slave driver
away from dma_request_channel() until the dma map has been created
for all platforms using that driver, again to avoid having too many
dependencies.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281740 — Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

FromPeter Ujfalusi <peter.ujfalusi@ti.com>
Date2015-12-02 13:40 +0100
SubjectRe: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel
Message-ID<qBeRr-79R-1@gated-at.bofh.it>
In reply to#1281168
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web