Re: [PATCH] dmaengine: edma: Add probe callback to edma_tptc_driver

[Vinod Koul]

On Wed, Dec 16, 2015 at 03:19:05PM +0200, Peter Ujfalusi wrote:
> Due to changes in device and platform code drivers w/o probe will fail to
> load. This means that the devices for eDMA TPTCs are goign to be without
> driver and omap hwmod code will turn them off after the kernel finished
> loading:
> [3.015900] platform 4980.tptc: omap_device_late_idle: enabled but no 
> driver.  Idling
> [3.024671] platform 49a0.tptc: omap_device_late_idle: enabled but no 
> driver.  Idling
> 
> This will prevent eDMA to work since the TPTCs are not enabled.

Applied, thanks

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

Re: [PATCH V03 0/5] dmaengine: New 'universal' API for requesting channel

[Vinod Koul]

On Mon, Dec 14, 2015 at 10:47:37PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
> 
> 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.

Applied now,

Thanks for this rework, much appreciated :-)

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

Re: [PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings

[Vinod Koul]

On Thu, Dec 17, 2015 at 09:48:44AM -0800, Tony Lindgren wrote:
> * Peter Ujfalusi  [151217 05:33]:
> > Hi,
> > 
> > Changes since v1:
> > - Updated to use the non 16bit arrays [1]
> > - send the two patch as a series
> > 
> > [1]
> > As it has been discussed earlier:
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> > 
> > the DT bindings has been changes compared to what we had in 4.4-rc1: the 
> > arrays
> > now don't have the 16bit type.
> > The changes are now merged to mainline and Vinod provided us a branch:
> > 
> > git://git.infradead.org/users/vkoul/slave-dma.git fix/edma
> > 
> > Which is based on 4.4-rc1 and only contains the two patch for changing the 
> > eDMA
> > bindings.
> 
> Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply
> your two patches.

FWIW, fix/edma is in Linu's tree now and should be in -rc6

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Vinod Koul]

On Wed, Dec 09, 2015 at 12:12:27PM -0800, Tony Lindgren wrote:
> * Peter Ujfalusi  [151209 00:19]:
> > Hi,
> > 
> > Based on the discussion regarding to (convert am33xx to use the new eDMA
> > bindings):
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> > 
> > This two patch will convert the new eDMA binding to not use 16bit arrays for
> > memcpy channel selection and for marking slots reserved.
> > The '/bits/ 16' seams to be causing confusion so it is probably better to 
> > just
> > use standard type for the arrays.
> > 
> > The new bindings for the eDMA is introduced for 4.4 and we do not have 
> > users of
> > it, which means that we can still change it w/o the risk of breaking 
> > anything
> > and we do not need to maintain the compatibility with 16bit arrays.
> > 
> > The changes in the eDMA driver is local to the DT parsing and should not
> > conflict with other changes (like the filter function mapping support). Hrm,
> > there might be trivial conflict in the include/linux/platform_data/edma.h 
> > with
> > the "dmaengine 'universal' API".
> > 
> > Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> > are
> > going to be handled? I would like to send the updated am33xx/am437x 
> > conversion
> > for 4.5 based on these changes.
> 
> Yes this should go into v4.4 as discussed, otherwise it will be a mess.
> For both, please feel free to add:
> 
> Acked-by: Tony Lindgren 
> 
> I suggest Vinod sets up an immutable branch against v4.4-rc1 with just these
> two patches. Then it can get merged into whichever branch needs it, I
> certainly will need it as most of my v4.5 branches are v4.4-rc1 or -rc2
> based.
> 
> Then the immutable branch can be merged into v4.4 by Vinod or Arnd.

Applied to fix/edma. This is based on -rc1 and will not rebase.

I am merging this to my fixes and will send to Linus in couple of days

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] dmaengine: omap-dma: transfer start and short memcpy improvement

[Vinod Koul]

On Wed, Nov 11, 2015 at 12:37:54PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> The first two patch is trivial fix.
> The third (remove the tasklet use for starting the transfer):
> I had been wondering about this for a while and now I was able to spend some
> time to look at this in more detail.
> In 'normal' operation I have never seen the tasklet to start more then one
> transfer even when pushing I/O based workloads on the board. However when I 
> run
> the DMAtest module I can see that the tasklet executes about 15 transfers.
> When the tasklet use has been removed, everything worked as well as before but
> the throughput of MMC/SD and memcpy increased slightly:
> 
> dd if=/dev/mmcblk0 of=/dev/null bs=64k count=24000
> ~16.5 MB/s -> ~16.6 MB/s
> 
> echo 6553 > /sys/module/dmatest/parameters/test_buf_size
> echo 2000 > /sys/module/dmatest/parameters/timeout
> echo 5000 > /sys/module/dmatest/parameters/iterations
> ~585 KB/s -> ~638 KB/s
> 
> It worth mentioning that _with_ the tasklet starting the transfers I managed 
> to
> hit a situation once when for some reason the memcpy tests were started to 
> time
> out. This happend with memcpy, iozone, dd and grep -R blabla /usr/ running at
> the same time.
> 
> The last patch is to correct the behaviour of omap-dma when short memcpy is 
> used
> by a client and the client is not using completion, but polling for the end of
> the transfer.

Applied, thanks

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

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

[Vinod Koul]

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 

Re: [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

[Vinod Koul]

On Tue, Dec 01, 2015 at 02:58:35PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 1, 2015 at 11:47 AM, Peter Ujfalusi  wrote:
> > On 11/30/2015 04:35 PM, Andy Shevchenko wrote:
> >> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi  
> >> wrote:
> >>> Treat as true condition the case when the mask is NULL.
> >>
> >> What do you think about setting some default (all "on") mask when mask
> >> is not supplied?
> >
> > Probably rephrasing the commit message to say that when the mask is NULL it
> > means that the caller does not care about the capabilities of the dma device
> > thus return with true in such a case.
> >
> > We could also drop this patch and in private_candidate() :
> >
> > -   if (!__dma_device_satisfies_mask(dev, mask)) {
> > +   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
> > pr_debug("%s: wrong capabilities\n", __func__);
> > return NULL;
> > }
> 
> Between patch and above proposal I would choose the latter one.

Sounds better to me as well

> 
> >> I don't know for sure but there might be cases when you don't want
> >> literally *any* channel to satisfy.
> >
> > Or set DMA_SLAVE only in dma_request_chan()? What happens if we have cases
> > when we are able to request channel for memcpy via dma_request_chan()
> > (dedicated memcpy channel/DMA engine?) in that case we will have the SLAVE
> > set, but not MEMCPY, or any other variation we do not know yet?
> 
> Frankly, have no idea.

In slave cases I know that some controllers support memcpy but they are not
generic memcpy as they cannot be used for system memcpy but for 'special'
memcpy. So this can be used for memcpy as well

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

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Vinod Koul]

On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> Add support for providing device to filter_fn mapping so client drivers
> can switch to use the dma_request_chan() API.

Any reason why we dont want to go with DT based only for edma here?

> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/dma/edma.c | 24 
>  include/linux/platform_data/edma.h |  5 +
>  2 files changed, 29 insertions(+)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 0675e268d577..386f8c9bd606 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2098,6 +2098,8 @@ static struct dma_chan *of_edma_xlate(struct 
> of_phandle_args *dma_spec,
>  }
>  #endif
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param);
> +
>  static int edma_probe(struct platform_device *pdev)
>  {
>   struct edma_soc_info*info = pdev->dev.platform_data;
> @@ -2297,6 +2299,12 @@ static int edma_probe(struct platform_device *pdev)
>   edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
>   }
>  
> + 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;
> + }
> +
>   ret = dma_async_device_register(>dma_slave);
>   if (ret) {
>   dev_err(dev, "slave ddev registration failed (%d)\n", ret);
> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param)
>  }
>  EXPORT_SYMBOL(edma_filter_fn);
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> +{
> + bool match = false;
> +
> + if (chan->device->dev->driver == _driver.driver) {
> + struct edma_chan *echan = to_edma_chan(chan);
> + unsigned ch_req = (unsigned)param;
> + if (ch_req == echan->ch_num) {
> + /* The channel is going to be used as HW synchronized */
> + echan->hw_triggered = true;
> + match = true;
> + }
> + }
> + return match;
> +}
> +
>  static int edma_init(void)
>  {
>   int ret;
> diff --git a/include/linux/platform_data/edma.h 
> b/include/linux/platform_data/edma.h
> index e2878baeb90e..117a36d63840 100644
> --- a/include/linux/platform_data/edma.h
> +++ b/include/linux/platform_data/edma.h
> @@ -59,6 +59,8 @@ struct edma_rsv_info {
>   const s16   (*rsv_slots)[2];
>  };
>  
> +struct dma_filter_map;
> +
>  /* platform_data for EDMA driver */
>  struct edma_soc_info {
>   /*
> @@ -76,6 +78,9 @@ struct edma_soc_info {
>  
>   s8  (*queue_priority_mapping)[2];
>   const s16   (*xbar_chans)[2];
> +
> + struct dma_filter_map *filter_map;
> + int filtercnt;
>  };
>  
>  #endif
> -- 
> 2.6.3
> 

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

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Vinod Koul]

On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
> > On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> > > Add support for providing device to filter_fn mapping so client drivers
> > > can switch to use the dma_request_chan() API.
> > 
> > Any reason why we dont want to go with DT based only for edma here?
> 
> I think the OMAP2 based platforms using edma are all DT-only, but mach-davinci
> would need a lot of work for that.

Okay sound fine then

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

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

[Vinod Koul]

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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tpcc support

[Vinod Koul]

On Fri, Oct 30, 2015 at 10:00:35AM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - Fixed issue introduced by the bitops patch: wrong error check, also switch 
> to
>   use find_first_zero_bit() instead of find_next_zero_bit()
> 
> Cover letter:
> 
> This series depends on the eDMA work I have done, which has been now applied:
> https://lkml.org/lkml/2015/10/16/64
> 
> DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used
> becasue the old driver stack for eDMA did not allowed integration w/o hacks.
> 
> Due to the nature of eDMA the crossbar needs to know which eDMA events it can
> use to map incoming events towards the eDMA. In eDMA a channel is wired to be
> used with one specific event. For example eDMA event 14 can only be handled by
> eDMA channel 14.
> The eDMA itself can be shared by different processors in the system (ARM, DSP,
> etc) and since ARM/Linux is the master we need to know which channels are used
> by other cores. Also we need to mask out channels used for memcpy from the
> events we use for HW triggers.

Applied, thanks

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

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

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 see. In that case I guess it also shouldn't call
> dmaengine_slave_config(), right? I don't think that's valid
> on a MEMCPY channel.

Yes it is not valid. In this case the dma driver should invoke a generic memcpy
and not need slave parameters, knowing the hw and reason for this (firmware
download to DSP memory), this doesn't qualify for slave case.
In fact filter function doesn't need a channel, any channel in this
controller will be good

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

Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

[Vinod Koul]

On Tue, Nov 03, 2015 at 03:00:57PM +0100, Arnd Bergmann wrote:
> During the edma rework, a build error was introduced for the
> case that CONFIG_OF is disabled:
> 
> drivers/built-in.o: In function `edma_tc_set_pm_state':
> :(.text+0x43bf0): undefined reference to `of_find_device_by_node'
> 
> As the edma_tc_set_pm_state() function does nothing in case
> we are running without OF, this adds an IS_ENABLED() check
> that turns the function into an empty stub then and avoids the
> link error.

Applied, thanks

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

Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

[Vinod Koul]

On Wed, Nov 04, 2015 at 10:33:27AM -0600, Felipe Balbi wrote:
> Peter Ujfalusi  writes:
> 
> > The eDMA3 TPTC does not need any software configuration, but it is a
> > separate IP block in the SoC. In order the omap hwmod core to be able to
> > handle the TPTC resources correctly in regards of PM we need to have a
> > driver loaded for it.
> > This patch will add a dummy driver skeleton without probe or remove
> > callbacks provided.
> >
> > Signed-off-by: Peter Ujfalusi 
> > Reported-by: Olof Johansson 
> 
> This fixes the problem I also reported on linux-omap [1]
> 
> Tested-by: Felipe Balbi 
> 
> [1] http://marc.info/?l=linux-omap=144665429032014=2

Great, I was about to point you to this series, I will push this in -next
now

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Vinod Koul]

On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote:
> > Okay I have reverted the two and applied the edma patch sent, can you please
> > verify topic/edma_fix before I merge it and send my PULL request.
> 
> The branch looks good. Thank you!
> It would have been great if the DTS changes for am335x/am437x would have been
> in 4.4, but I will send them for 4.5 after rc1 is out.

Any confirmation that this fixes the reported issue before I send pull
request?

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

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Vinod Koul]

On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote:
> Vinod,
> 
> On 11/02/2015 12:04 PM, Vinod Koul wrote:
> > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote:
> >> Hi,
> >>
> >> 1) This seems to have broken BBB in -next for me, bisected down to this 
> >> patch.
> >>
> >> For bootlog:
> >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
> >>
> >> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> >> at least without an ack from the platform maintainer. It can be a a
> >> huge mess if they end up causing conflicts, so we always ask to merge
> >> the DT changes through the platform maintainer (Tony in this case) by
> >> default.
> > 
> > I did warn when applying that I am doing so without ACK on ARM code, noone
> > said a thing!
> > 
> > I knew Tony was following the work by Peter so assumed he must have been 
> > okay
> > with it otherwise would have spoken for ~couple of weeks these were in
> > review
> > 
> > Anyway now that we have a regression, I can revert this patch if that fixes,
> > please confirm, but might break edma... peter?
> 
> Can you revert or drop the last two DTS patches?
> 
> I think I will try a different route to get the split of the tpcc and tptc.
> Without the DT patches the driver will fall back to the legacy mode so things
> will work in a same way they did before.
> Or I can send a followup patch for edma.c, with that there is no need to add
> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better.
> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod
> code will not shut it down but we will keep the possibility to manage the
> power state still.

Okay I have reverted the two and applied the edma patch sent, can you please
verify topic/edma_fix before I merge it and send my PULL request.

Would appreciate any tested-by

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Vinod Koul]

On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote:
> Hi,
> 
> 1) This seems to have broken BBB in -next for me, bisected down to this patch.
> 
> For bootlog:
> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
> 
> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> at least without an ack from the platform maintainer. It can be a a
> huge mess if they end up causing conflicts, so we always ask to merge
> the DT changes through the platform maintainer (Tony in this case) by
> default.

I did warn when applying that I am doing so without ACK on ARM code, noone
said a thing!

I knew Tony was following the work by Peter so assumed he must have been okay
with it otherwise would have spoken for ~couple of weeks these were in
review

Anyway now that we have a regression, I can revert this patch if that fixes,
please confirm, but might break edma... peter?

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

Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc

[Vinod Koul]

On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote:
> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
> do any configuration within TPTC for the eDMA3 to be operational. All
> configuration is via the TPCC.
> To prevent the omap_device_late_idle() to disable the TPTCs when they are
> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
> added.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Vinod, Olof,
> 
> This patch somehow got lost in my working branch. It was mixed within the 
> patches
> I will have for 4.5 while it should have been within the new eDMA3 binding
> series..

Does this fix the issue reported by Olof? Also ACK pls for this

-- 
~Vinod
> 
> Regards,
> Peter
> 
>  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> index 907a452b78ea..3c7106a09801 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> @@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
>   .name   = "tptc0",
>   .class  = _tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> @@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
>   .name   = "tptc1",
>   .class  = _tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> @@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
>   .name   = "tptc2",
>   .class  = _tptc_hwmod_class,
>   .clkdm_name = "l3_clkdm",
> - .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
>   .main_clk   = "l3_gclk",
>   .prcm   = {
>   .omap4  = {
> -- 
> 2.6.1
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/14] dmaenigne: edma/ti-crossbar: fixes, new bindings

[Vinod Koul]

On Fri, Oct 16, 2015 at 10:17:58AM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - Comments in the memcpy optimization patch extended
> - The crossbar patch has been improved:
>  - debug prints changed
>  - fallback xbar parameters now type specific as the fallback values for DRA7
>are not valid for AM33xx crossbar.
> - New patch for Kconfig to select the crossbar in case the eDMA is used on 
> OMAP
>   platforms
> 
I am applying this series and Please note that this has ARM patches which i
have not heard any objections so applying :)

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

Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
> DRA7x family.
> Instead of a single event crossbar it has 64 identical mux attached to each
> eDMA event line. When the 0 event mux is selected, the default mapped event
> is going to be routed to the corresponding eDMA event line. If different
> mux is selected, then the selected event is going to be routed to the given
> eDMA event.

Why is crossbar patch in edma series?

> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
> +{
> + struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
> + struct ti_am335x_xbar_map *map = route_data;
> +
> + dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
> + map->mux_val, map->dma_line);

Err ?

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

Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_memcpy(
>   struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>   size_t len, unsigned long tx_flags)
>  {
> - int ret;
> + int ret, nslots;
>   struct edma_desc *edesc;
>   struct device *dev = chan->device->dev;
>   struct edma_chan *echan = to_edma_chan(chan);
> - unsigned int width;
> + unsigned int width, pset_len;
>  
>   if (unlikely(!echan || !len))
>   return NULL;
>  
> - edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> + if (len < SZ_64K) {
> + /*
> +  * Transfer size less than 64K can be handled with one paRAM
> +  * slot. ACNT = length
> +  */
> + width = len;
> + pset_len = len;
> + nslots = 1;
> + } else {
> + /*
> +  * Transfer size bigger than 64K will be handled with maximum of
> +  * two paRAM slots.
> +  * slot1: ACNT = 32767, length1: (length / 32767)
> +  * slot2: the remaining amount of data.
> +  */
> + width = SZ_32K - 1;
> + pset_len = rounddown(len, width);
> + /* One slot is enough for lengths multiple of (SZ_32K -1) */

Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
slot and 12K in second slot ?

Is there a limit on 'blocks' of 64K we can do here?

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

Re: [PATCH v5 00/24] dmaengine/ARM: Merge the edma drivers into one

[Vinod Koul]

On Wed, Oct 14, 2015 at 02:42:42PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Cover letter:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places
> 
> This change will also help us to do bigger changes in the eDMA driver since,
> since now we have only one driver to work with.

I have applied this now. I got a conlfict on 3rd one while applying and also
I got conflict while merging to next

Pls verify all is well!

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

Re: [PATCH v4 20/25] dmaengine: edma: Simplify the interrupt handling

[Vinod Koul]

On Thu, Sep 24, 2015 at 01:02:07PM +0300, Peter Ujfalusi wrote:

> + if (edesc->cyclic) {
> + vchan_cyclic_callback(>vdesc);
> + spin_unlock(>vchan.lock);
> + return;
> + } else if (edesc->processed == edesc->pset_nr) {
> + dev_dbg(dev, "Transfer completed on channel %d\n",
> + echan->ch_num);

perhaps not a great choice for a print, we would ideally want to complete
the cookie and then print

> + sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 0);
> + if (!sh_ipr) {
> + sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 1);
> + if (!sh_ipr)
> + return IRQ_NONE;
> + sh_ier = edma_shadow0_read_array(ecc, SH_IER, 1);
> + bank = 1;
> + } else {
> + sh_ier = edma_shadow0_read_array(ecc, SH_IER, 0);
> + bank = 0;
> + }
> +
> + do {
> + u32 slot;
> + u32 channel;
> +
> + dev_dbg(ecc->dev, "IPR%d %08x\n", bank, sh_ipr);

Too much debug prints...

> + edma_read_slot(ecc, echan->slot[0], );
> + /*
> +  * Issue later based on missed flag which will be sure
> +  * to happen as:
> +  * (1) we finished transmitting an intermediate slot and
> +  * edma_execute is coming up.
> +  * (2) or we finished current transfer and issue will
> +  * call edma_execute.
> +  *
> +  * Important note: issuing can be dangerous here and
> +  * lead to some nasty recursion when we are in a NULL
> +  * slot. So we avoid doing so and set the missed flag.
> +  */
> + if (p.a_b_cnt == 0 && p.ccnt == 0) {
> + dev_dbg(dev, "Error on null slot, setting miss\n");

Shouldn't this be err ?

> + } else if (edma_read(ecc, EDMA_QEMR)) {
> + dev_dbg(ecc->dev, "QEMR %02x\n",
> + edma_read(ecc, EDMA_QEMR));
> + for (i = 0; i < 8; i++) {
> + if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
> + /* Clear the corresponding IPR bits */
> + edma_write(ecc, EDMA_QEMCR, BIT(i));
> + edma_shadow0_write(ecc, SH_QSECR,
> +BIT(i));
> +
> + /* NOTE:  not reported!! */

what does this mean?

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

Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Vinod Koul]

On Thu, Sep 24, 2015 at 01:01:47PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Cover letter:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places

One question though, after this move and merge are we still left with edma
in arm/ ?

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation

[Vinod Koul]

On Wed, Oct 14, 2015 at 06:02:18PM +0300, Peter Ujfalusi wrote:
> On 10/14/2015 05:41 PM, Vinod Koul wrote:
> > On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> >> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
> >> *edma_prep_dma_memcpy(
> >>struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> >>size_t len, unsigned long tx_flags)
> >>  {
> >> -  int ret;
> >> +  int ret, nslots;
> >>struct edma_desc *edesc;
> >>struct device *dev = chan->device->dev;
> >>struct edma_chan *echan = to_edma_chan(chan);
> >> -  unsigned int width;
> >> +  unsigned int width, pset_len;
> >>  
> >>if (unlikely(!echan || !len))
> >>return NULL;
> >>  
> >> -  edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> >> +  if (len < SZ_64K) {
> >> +  /*
> >> +   * Transfer size less than 64K can be handled with one paRAM
> >> +   * slot. ACNT = length
> >> +   */
> >> +  width = len;
> >> +  pset_len = len;
> >> +  nslots = 1;
> >> +  } else {
> >> +  /*
> >> +   * Transfer size bigger than 64K will be handled with maximum of
> >> +   * two paRAM slots.
> >> +   * slot1: ACNT = 32767, length1: (length / 32767)
> >> +   * slot2: the remaining amount of data.
> >> +   */
> >> +  width = SZ_32K - 1;
> >> +  pset_len = rounddown(len, width);
> >> +  /* One slot is enough for lengths multiple of (SZ_32K -1) */
> > 
> > Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> > slot and 12K in second slot ?
> 
> Not exactly. If the size is less than 64K it can be done with one 'burst' but
> if it is bigger we need to have two sets of transfer:
> 1. 32K blocks
> 2. the remaining data
> 
> so in case of 140K:
> 4 x 32K followed by 12K

Okay this part wasn't very clear to me, can you please add some comment
explaining this bit

> 
> > 
> > Is there a limit on 'blocks' of 64K we can do here?
> 
> 32767 32K blocks is the limit.
> 
> The 64K burst is only possible if the whole transfer is less less than 64K.
> With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
> we need to use the BCNT counter and for that to work the the distance between
> the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
> this is the reason why we have 32K 'blocks' to transfer first followed by the
> remaining.

Okay IIUC, we have option to single burst if its less that 64K using one
slot, otherwise split to 32K chunk with 2 slots, or would it be N in that
case

Really need more documentation here :)
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/25] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

[Vinod Koul]

On Thu, Sep 24, 2015 at 01:01:58PM +0300, Peter Ujfalusi wrote:
> Move the code out from arch/arm/common and merge it inside of the dmaengine
> driver.
> This change is done with as minimal change to the code as possible to avoid
> any possibilities to introducing regression.

Is this a pure move patch or code has been modified, if latter am
disappointed that existing code style issue have not been fixed


> +static inline void edma_write(struct edma_cc *ecc, int offset, int val)
> +{
> + __raw_writel(val, ecc->base + offset);
> +}
> +static inline void edma_modify(struct edma_cc *ecc, int offset, unsigned and,
> +unsigned or)

This looks bad on my 80 char screen, and few more places below

> +{
> + unsigned val = edma_read(ecc, offset);

checkpatch should have asked you to add empty line here, many places below
too

> + val &= and;
> + val |= or;
> + edma_write(ecc, offset, val);
> +}

empty line here and few more places

More later :)

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

Re: [PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers

[Vinod Koul]

On Mon, Sep 14, 2015 at 03:31:05PM +0300, Peter Ujfalusi wrote:
> From: Misael Lopez Cruz 
> 
> The L3 throughput can be higher than expected when packed access
> is not enabled.  The ratio depends on the number of bytes in a
> transaction and the EMIF interface width.
> 
> The throughput was measured for the following settings/cases:
> 
> * Case 1: Burst size of 64 bytes, packed access disabled
> * Case 2: Burst size of 64 bytes, packed access enabled
> * Case 3: Burst disabled, packed access disabled
> 
> Throughput measurements were done during McASP-based audio
> playback on the Jacinto6 EVM using the omapconf tool [1]:
> $ omapconf trace bw -m sdma_rd
> 
>  -
>   Throughput (MB/s)
>   Audio parametersCase 1Case 2Case 3
>  -
>   44.1kHz, 16-bits, stereo  1.41  0.18  1.41
>   44.1kHz, 32-bits, stereo  1.41  0.35  1.41
>   44.1kHz, 16-bits, 4-chan  2.82  0.35  2.82
>   44.1kHz, 16-bits, 6-chan  4.23  0.53  4.23
>   44.1kHz, 16-bits, 8-chan  5.64  0.71  5.64
>  -
> 
> From above measurements, case 2 is the only one that delivers
> the expected throughput for the given audio parameters.  For
> that reason, the packed accesses are now enabled.
> 
> It's worth to mention that packed accesses cannot be enabled
> for all addressing modes. In cyclic transfers, it can be
> enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
> as they use post-increment mode which supports packed accesses.
> 
> Peter Ujfalusi:
> From the TRM regarding to this:
> "NOTE: Except in the constant addressing mode, the source or
> destination must be specified as packed for burst transactions
> to occur."
> 
> So w/o the packed setting the burst on the MEM side was not
> enabled, this explains the numbers.
> 
> [1] https://github.com/omapconf/omapconf
> 

Applied, thanks

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

Re: [PATCH 2/3] dma: add __must_check annotation for dmaengine_pause()

[Vinod Koul]

On Tue, Aug 11, 2015 at 02:34:29PM +0200, Sebastian Andrzej Siewior wrote:
 On 08/11/2015 12:06 PM, Russell King - ARM Linux wrote:
  I think what people need to learn is that an API in the kernel which
  returns an int _can_ fail - it returns an int so it _can_ return an
  error code.  If it _can_ return an error code, there _will_ be
  implementations which _do_.
  
  If you don't check the return code, either your code doesn't care whether
  the function was successful or not, or you're playing with fire.  This is
  a prime example of playing with fire.
  
  Let's leave the crappy userspace laziness with regard to error checking
  to userspace, and keep it out of the kernel.
  
  Yes, the DMA engine capabilities may not be sufficient to describe every
  detail of DMA engines, but that's absolutely no reason to skimp on error
  checking.  Had there been some kind of error checking at the site, this
  problem would have been spotted before the 8250-omap driver was merged.
 
 Let me disable RX-DMA in 8250-omap code and push that stable. Then we
 won't need a special annotation for pause support because it remains
 off and is currently about one user. I browsed each driver in
 drivers/dma each one which does support pause supports it and all of
 them implement it unconditionally (ipu_idmac grabs a mutex first but
 this is another story).
 Adding error checking to 8250-omap like I have it in #1 and disabling
 RX-DMA in case pause fails looks be reasonable since there is nothing
 else that can be done I guess.
 Once we have the missing piece in omap-dma the RX-DMA can be enabled in
 8250-omap.
 Does this sound like a plan we can agree on?

Yes sounds good to me..

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] tty: serial: 8250_omap: do not use RX DMA if pause is not supported

[Vinod Koul]

On Sat, Aug 08, 2015 at 10:03:43AM +0100, Russell King - ARM Linux wrote:
 On Fri, Aug 07, 2015 at 08:28:57PM -0400, Peter Hurley wrote:
  Even dma_get_slave_caps() returns _true_ for cmd_pause support; ok, that
  interface is pointless.
 
 How about reporting that as a bug then, because if you look back in the
 git history, as you are fully capable of, you will find that the slave
 capability stuff went in _after_ omap-dma, and *many* DMA engine drivers
 have not been updated.  Here, let me do _your_ work for you:
 
 commit cb8cea513c80db1dfe2dce468d2d0772005bb9a1
 Author: Maxime Ripard maxime.rip...@free-electrons.com
 Date:   Mon Nov 17 14:42:04 2014 +0100
 
 dmaengine: Create a generic dma_slave_caps callback
 
 commit 2dcdf570936168d488acf90be9b04a3d32dafce7
 Author: Peter Ujfalusi peter.ujfal...@ti.com
 Date:   Fri Sep 14 15:05:45 2012 +0300
 
 dmaengine: omap: Add support for pause/resume in cyclic dma mode
 
 Oh look, omap-dma pre-dates the creation of dma_slave_caps by over two
 years!
 
 However, it's *not* as trivial as you think: the dma_slave_caps() call
 has no knowledge whether a channel will be used in cyclic mode or not,
 or which direction it will be used.  So, it really _can't_ report
 whether pause mode is supported or not.  So actually, this is something
 that can't be fixed trivially, and was a detail missed when the slave
 caps was reviewed (I probably missed the review or missed the point.)

The API queries the capabilities for a channel. So a channel has been
allocated. BUT it would not imply the direction as that is descriptor based,
so should we query the capabilities for a descriptor and use those in
clients ?

Also the current dma_slave_caps() has been moved to framework and reports
based on driver callbacks.
Now we have a hardware which supports pause for one direction only so we
should model it bit differently

Thoughts... ??

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dma: add __must_check annotation for dmaengine_pause()

[Vinod Koul]

On Fri, Aug 07, 2015 at 10:00:18PM +0200, Sebastian Andrzej Siewior wrote:
 In 8250-omap I learned it the hard way that ignoring the return code
 of dmaengine_pause() might be bad because the underlying DMA driver
 might not support the function at all and so not doing what one is
 expecting.
 This patch adds the __must_check annotation as suggested by Russell King.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  include/linux/dmaengine.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
 index 8ad9a4e839f6..4eac4716bded 100644
 --- a/include/linux/dmaengine.h
 +++ b/include/linux/dmaengine.h
 @@ -825,7 +825,7 @@ static inline int dmaengine_terminate_all(struct dma_chan 
 *chan)
   return -ENOSYS;
  }
  
 -static inline int dmaengine_pause(struct dma_chan *chan)
 +static inline int __must_check dmaengine_pause(struct dma_chan *chan)
  {
   if (chan-device-device_pause)
   return chan-device-device_pause(chan);

Give that there are bunch of users of this call which may or maynot be using
this, I think putting this check is too stringent

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] dmaengine: ti-dma-crossbar: Support for eDMA

[Vinod Koul]

On Wed, Jul 22, 2015 at 11:48:08AM +0300, Peter Ujfalusi wrote:
 Hi Vinod,
 
 Strange, for me the v2 series applied cleanly on top of rc1, but to be safe I
 have generated this series on top of 4.2-rc3

Applied now, thanks

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] dmaengine: ti-dma-crossbar: Support for eDMA

[Vinod Koul]

On Fri, Jul 03, 2015 at 05:10:46PM +0300, Peter Ujfalusi wrote:
 On 07/02/2015 06:56 PM, Vinod Koul wrote:
  On Wed, Jul 01, 2015 at 03:41:26PM +0300, Peter Ujfalusi wrote:
  Hi,
 
  On 06/08/2015 04:22 PM, Peter Ujfalusi wrote:
  Hi,
 
  Changes since v01:
  - Drop change in compatible for the crossbar driver and do the 
  configuration
based on the DT structure.
 
  The ti-dma-crossbar driver in it's current form can work when it is used 
  with
  sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA 
  available.
  The sDMA driver expects to get the DMA request line with offset 1. The 
  eDMA
  stack does not need the offset.
  The crosbbar itself is identical for sDMA and eDMA.
  At probe time the driver will do a match to figure out which dma engine 
  it is
  connected to and based on that information it will configure the offset 
  needed
  by the DMA driver.
 
  Gentle ping, it has been almost a month ago this series has been sent.
  Sorry I seem to have missed this series. I relooked at this and it looks
  fine. I will apply it once rc1 is out. If it needs rebase please resend
 
 No problem,
 the patch still applies cleanly.
No luck, I tried on -rc1 an 1st fails, can you please rebase and resend

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] dmaengine: ti-dma-crossbar: Support for eDMA

[Vinod Koul]

On Wed, Jul 01, 2015 at 03:41:26PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 On 06/08/2015 04:22 PM, Peter Ujfalusi wrote:
  Hi,
  
  Changes since v01:
  - Drop change in compatible for the crossbar driver and do the configuration
based on the DT structure.
  
  The ti-dma-crossbar driver in it's current form can work when it is used 
  with
  sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA 
  available.
  The sDMA driver expects to get the DMA request line with offset 1. The eDMA
  stack does not need the offset.
  The crosbbar itself is identical for sDMA and eDMA.
  At probe time the driver will do a match to figure out which dma engine it 
  is
  connected to and based on that information it will configure the offset 
  needed
  by the DMA driver.
 
 Gentle ping, it has been almost a month ago this series has been sent.
Sorry I seem to have missed this series. I relooked at this and it looks
fine. I will apply it once rc1 is out. If it needs rebase please resend

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Mon, Jun 22, 2015 at 02:31:00PM +0300, Peter Ujfalusi wrote:
 On 06/12/2015 03:58 PM, Vinod Koul wrote:
  Sorry this slipped thru
 
 I was away for a week anyways ;)
 
  Thinking about it again, I think we should coverge to two APIs and mark the
  legacy depracuated and look to convert folks and phase that out
 
 Currently, w/o this series we have these APIs:
 /* to be used with DT/ACPI */
 dma_request_slave_channel(dev, name)  /* NULL on failure */
 dma_request_slave_channel_reason(dev, name)   /* error code on failure */
 
 /* Legacy mode only - no DT/ACPI lookup */
 dma_request_channel(mask, fn, fn_param) /* NULL on failure */
 
 /* to be used with DT/ACPI or legacy boot */
 dma_request_slave_channel_compat(mask, fn, fn_param, dev, name)   /* NULL 
 on
 failure */
 
 To request _any_ channel to be used for memcpy one has to use
 dma_request_channel(mask, NULL, NULL);
 
 If I did not missed something.
I dont think so :)

 As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI
 lookup) and the good API names are already taken, we might need to settle:
 
 /* to be used with DT/ACPI */
 dma_request_slave_channel(dev, name) /* error code on failure */
 - Convert users to check IS_ERR_OR_NULL() instead against NULL
 - Mark dma_request_slave_channel_reason() deprecated and convert the current 
 users
 
 /* to be used with DT/ACPI or legacy boot */
 dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code
 on failure */
 - Convert users to check IS_ERR_OR_NULL() instead against NULL
 - Do not try legacy mode if either OF or ACPI failed because of real error
Should we keep the filter fn and an API for this, I am still not too sure
about that part. Anyway users should be on DT/ACPI. if someone wants filter
then let them use dma_request_channel()

 
 /* Legacy mode only - no DT/ACPI lookup */
 dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */
 - convert users of dma_request_channel()
 - mark dma_request_channel() deprecated
Why should we create a new API, how about marking dma_request_channel() as
legacy and generic memcpy API and let other users be migrated?
 
 /* to be used to get a channel for memcpy for example */
 dma_request_any_channel(mask) /* error code on failure */
 - Convert current dma_request_channel(mask, NULL, NULL) users
 I know, any of the other function could be prepared to handle this when
 parameters are missing, but it is a bit cleaner to have separate API for this.
Though it has merits but adds another API. We cna have internal
_dma_request_xxx API where parameters are missing and clean but to users
single API might be a better idea
 
 It would be nice to find another name for the
 dma_request_slave_channel_compat() so with the new name we could have chance
 to rearrange the parameters: (dev, name, mask, fn, fn_param)
 
 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, fn_param);
 dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
 dma_request_any_channel(mask);
This is good idea but still we end up with 4 APIs. Why not just converge to
two API, one legacy + memcpy + filer fn and one untimate API for slave?

Internally we may have 4 APIs for cleaner handling...

Thoughts... ??

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote:
 Vinod,
 
 On 06/02/2015 03:55 PM, Vinod Koul wrote:
  On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
  On 05/29/2015 01:18 PM, Vinod Koul wrote:
  On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
  On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com 
  wrote:
  On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
  dma_request_slave_channel_compat() 'eats' up the returned error codes 
  which
  prevents drivers using the compat call to be able to do deferred 
  probing.
 
  The new wrapper is identical in functionality but it will return with 
  error
  code in case of failure and will pass the -EPROBE_DEFER to the caller 
  in
  case dma_request_slave_channel_reason() returned with it.
  This is okay but am worried about one more warpper, how about fixing
  dma_request_slave_channel_compat()
 
  Then all callers of dma_request_slave_channel_compat() have to be
  modified to handle ERR_PTR first.
 
  The same is true for (the existing) dma_request_slave_channel_reason()
  vs. dma_request_slave_channel().
  Good point, looking again, I think we should rather fix
  dma_request_slave_channel_reason() as it was expected to return err code 
  and
  add new users. Anyway users of this API do expect the reason...
 
  Hrm, they are for different use.dma_request_slave_channel()/_reason() is 
  for
  drivers only working via DT or ACPI while
  dma_request_slave_channel_compat()/_reason() is for drivers expected to 
  run in
  DT/ACPI or legacy mode as well.
 
  I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci
  drivers are using this to request channels - they need to support DT and
  legacy mode.
  I think we should hide these things behind the API and do this behind the
  hood for ACPI/DT systems.
  
  Also it makes sense to use right API and mark rest as depricated
 
 So to convert the dma_request_slave_channel_compat() and not to create _reason
 variant?
 
 Or to have single API to request channel? The problem with that is that we
 need different parameters for legacy and DT for example.
Sorry this slipped thru

Thinking about it again, I think we should coverge to two APIs and mark the
legacy depracuated and look to convert folks and phase that out


-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
 On 05/29/2015 01:18 PM, Vinod Koul wrote:
  On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
  On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
  dma_request_slave_channel_compat() 'eats' up the returned error codes 
  which
  prevents drivers using the compat call to be able to do deferred probing.
 
  The new wrapper is identical in functionality but it will return with 
  error
  code in case of failure and will pass the -EPROBE_DEFER to the caller in
  case dma_request_slave_channel_reason() returned with it.
  This is okay but am worried about one more warpper, how about fixing
  dma_request_slave_channel_compat()
 
  Then all callers of dma_request_slave_channel_compat() have to be
  modified to handle ERR_PTR first.
 
  The same is true for (the existing) dma_request_slave_channel_reason()
  vs. dma_request_slave_channel().
  Good point, looking again, I think we should rather fix
  dma_request_slave_channel_reason() as it was expected to return err code and
  add new users. Anyway users of this API do expect the reason...
 
 Hrm, they are for different use.dma_request_slave_channel()/_reason() is for
 drivers only working via DT or ACPI while
 dma_request_slave_channel_compat()/_reason() is for drivers expected to run in
 DT/ACPI or legacy mode as well.
 
 I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci
 drivers are using this to request channels - they need to support DT and
 legacy mode.
I think we should hide these things behind the API and do this behind the
hood for ACPI/DT systems.

Also it makes sense to use right API and mark rest as depricated
 
 But it is doable to do this for both the non _compat and _compat version:
 1. change all users to check IS_ERR_OR_NULL(chan)
  return the PTR_ERR if not NULL, or do whatever the driver was doing in case
 of chan == NULL.
 2. change the non _compat and _compat versions to do the same as the _reason
 variants, #define the _reason ones to the non _reason names
 3. Rename the _reason use to non _reason function in drivers
 4. Remove the #defines for the _reason functions
 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers
 The result:
 Both dma_request_slave_channel() and dma_request_slave_channel_compat() will
 return ERR_PTR in case of failure or in success they will return the pinter to
 chan.
 
 Is this what you were asking?
 It is a bit broader than what this series was doing: taking care of
 OMAP/daVinci drivers for deferred probing regarding to dmaengine ;)
Yes but it would make sense right? I know it is a larger work but then we
wouldn't want another dma_request_slave_xxx API, at some point we have stop
it exapnding, perhpas now :)

Yes I am all ears to stage this work and not do transition gardually..

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
 dma_request_slave_channel_compat() 'eats' up the returned error codes which
 prevents drivers using the compat call to be able to do deferred probing.
 
 The new wrapper is identical in functionality but it will return with error
 code in case of failure and will pass the -EPROBE_DEFER to the caller in
 case dma_request_slave_channel_reason() returned with it.
This is okay but am worried about one more warpper, how about fixing
dma_request_slave_channel_compat()


-- 
~Vinod
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  include/linux/dmaengine.h | 22 ++
  1 file changed, 22 insertions(+)
 
 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
 index abf63ceabef9..6c777394835c 100644
 --- a/include/linux/dmaengine.h
 +++ b/include/linux/dmaengine.h
 @@ -1120,4 +1120,26 @@ static inline struct dma_chan
  
   return __dma_request_channel(mask, fn, fn_param);
  }
 +
 +#define dma_request_slave_channel_compat_reason(mask, x, y, dev, name) \
 + __dma_request_slave_channel_compat_reason((mask), x, y, dev, name)
 +
 +static inline struct dma_chan
 +*__dma_request_slave_channel_compat_reason(const dma_cap_mask_t *mask,
 +   dma_filter_fn fn, void *fn_param,
 +   struct device *dev, char *name)
 +{
 + struct dma_chan *chan;
 +
 + chan = dma_request_slave_channel_reason(dev, name);
 + /* Try via legacy API if not requesting for deferred probing */
 + if (IS_ERR(chan)  PTR_ERR(chan) != -EPROBE_DEFER)
 + chan = __dma_request_channel(mask, fn, fn_param);
 +
 + if (!chan)
 + chan = ERR_PTR(-ENODEV);
 +
 + return chan;
 +}
 +
  #endif /* DMAENGINE_H */
 -- 
 2.3.5
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
 On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
  dma_request_slave_channel_compat() 'eats' up the returned error codes which
  prevents drivers using the compat call to be able to do deferred probing.
 
  The new wrapper is identical in functionality but it will return with error
  code in case of failure and will pass the -EPROBE_DEFER to the caller in
  case dma_request_slave_channel_reason() returned with it.
  This is okay but am worried about one more warpper, how about fixing
  dma_request_slave_channel_compat()
 
 Then all callers of dma_request_slave_channel_compat() have to be
 modified to handle ERR_PTR first.
 
 The same is true for (the existing) dma_request_slave_channel_reason()
 vs. dma_request_slave_channel().
Good point, looking again, I think we should rather fix
dma_request_slave_channel_reason() as it was expected to return err code and
add new users. Anyway users of this API do expect the reason...

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] EDMA: TI: fixed wrongly initialized data parameter to the edma callback

[Vinod Koul]

On Mon, Mar 23, 2015 at 09:35:01PM +0100, Petr Kulhavy wrote:
 The data parameter passed indirectly to the edma_callback() should be
 edma_chan and not the dma_chan.
 
 This bug was so far harmless since the offset of struct dma_chan within struct
 edma_chan is 0. However as soon as someone changes struct edma_chan this would
 cause troubles.
Applied now, but do ensure you are using right subsystem anmes for patches.
I have fixed up now

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] dmaengine: omap-dma: Fix memory leak when terminating running transfer

[Vinod Koul]

On Fri, Mar 27, 2015 at 01:35:52PM +0200, Peter Ujfalusi wrote:
 In omap_dma_start_desc the vdesc-node is removed from the virt-dma
 framework managed lists (to be precise from the desc_issued list).
 If a terminate_all comes before the transfer finishes the omap_desc will
 not be freed up because it is not in any of the lists and we stopped the
 DMA channel so the transfer will not going to complete.
 There is no special sequence for leaking memory when using cyclic (audio)
 transfer: with every start and stop of a cyclic transfer the driver leaks
 struct omap_desc worth of memory.
 
 Free up the allocated memory directly in omap_dma_terminate_all() since the
 framework will not going to do that for us.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: sta...@vger.kernel.org
 CC: linux-omap@vger.kernel.org
Applied, thanks

-- 
~Vinod

 ---
  drivers/dma/omap-dma.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
 index 1e646d6c8230..6a4c378ee432 100644
 --- a/drivers/dma/omap-dma.c
 +++ b/drivers/dma/omap-dma.c
 @@ -1002,6 +1002,7 @@ static int omap_dma_terminate_all(struct dma_chan *chan)
* c-desc is NULL and exit.)
*/
   if (c-desc) {
 + omap_dma_desc_free(c-desc-vd);
   c-desc = NULL;
   /* Avoid stopping the dma twice */
   if (!c-paused)
 -- 
 2.3.3
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] dmaengine: edma: fix memory leak when terminating running transfers

[Vinod Koul]

On Fri, Mar 27, 2015 at 01:35:51PM +0200, Peter Ujfalusi wrote:
 From: Petr Kulhavy p...@barix.com
 
 If edma_terminate_all() was called while a transfer was running (i.e. after
 edma_execute() but before edma_callback()) the echan-edesc was not freed.
 
 This was due to the fact that a running transfer is on none of the
 vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
 removes it from the desc_issued list), so the vchan_dma_desc_free_list()
 called at the end of edma_terminate_all() didn't find it and didn't free it.
 
 This bug was found on an AM1808 based hardware (very similar to da850evm,
 however using the second MMC/SD controller), where intense operations on the 
 SD
 card wasted the device 128MB RAM within a couple of days.
 
 Peter Ujfalusi:
 The issue is even more severe since it affects cyclic (audio) transfers as
 well. In this case starting/stopping audio will results memory leak.
 
 Signed-off-by: Petr Kulhavy p...@barix.com
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 CC: sta...@vger.kernel.org
 CC: linux-omap@vger.kernel.org
Applied, thanks

-- 
~Vinod

 ---
  drivers/dma/edma.c | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 741baa68365c..984c2b12dae3 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -268,6 +268,13 @@ static int edma_terminate_all(struct dma_chan *chan)
*/
   if (echan-edesc) {
   int cyclic = echan-edesc-cyclic;
 +
 + /*
 +  * free the running request descriptor
 +  * since it is not in any of the vdesc lists
 +  */
 + edma_desc_free(echan-edesc-vdesc);
 +
   echan-edesc = NULL;
   edma_stop(echan-ch_num);
   /* Move the cyclic channel back to default queue */
 -- 
 2.3.3
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers

[Vinod Koul]

On Fri, Mar 27, 2015 at 02:25:29PM +0200, Peter Ujfalusi wrote:
 On 03/26/2015 05:32 PM, Vinod Koul wrote:
  I have added the DT binding document since this series adds support for
  routers for platforms booting with DT:
 
  Documentation/devicetree/bindings/dma/dma.txt | 28 
  I meant the update to Documnetation/dmanegine/ for routers :)
 
 I see. In what form you think we should have the documentation? Is it adequate
 to lift and adjust the text from the DT binding document here? Should we have
 a separate file for the router description?
 My concern was and this is why I did not wrote anything under here is that the
 code I add is only covers the DT boot case and I'm not planning to add legacy
 support. The ACPI binding can be done in a similar fashion as the DT so you
 would have a translator driver with ACPI API.
Not the binding part but more of a guideline on how to go about solving the
DMA router design for drivers

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers

[Vinod Koul]

On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
 DMA routers are transparent devices used to mux DMA requests from
 peripherals to DMA controllers. They are used when the SoC integrates more
 devices with DMA requests then their controller can handle.
 DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
 lines, but in SoC level it has 205 DMA requests.
 
 The of_dma_router will be registered as of_dma_controller with special
 xlate function and additional parameters and the code will translate and
 requests a DMA channel from the real DMA controller.
 This way the router can be transparent for the system while remaining generic
 enough to be used in different environments.
 
Looks fine, was expecting a Documentation updates as well, but that can come
as follow up patch too

-- 
~Vinod

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  Documentation/devicetree/bindings/dma/dma.txt | 28 
  drivers/dma/dmaengine.c   |  7 ++
  drivers/dma/of-dma.c  | 92 
 +++
  include/linux/dmaengine.h | 17 +
  include/linux/of_dma.h| 21 ++
  5 files changed, 165 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
 b/Documentation/devicetree/bindings/dma/dma.txt
 index 82104271e754..f728b978178e 100644
 --- a/Documentation/devicetree/bindings/dma/dma.txt
 +++ b/Documentation/devicetree/bindings/dma/dma.txt
 @@ -31,6 +31,34 @@ Example:
   dma-requests = 127;
   };
  
 +* DMA router
 +
 +DMA routers are transparent IP blocks used to route DMA request lines from
 +devices to the DMA controller. Some SoCs (like TI DRA7x) have more 
 peripherals
 +integrated with DMA requests than what the DMA controller can handle 
 directly.
 +
 +Required property:
 +- dma-device:phandle of the DMA controller. The router is 
 modifying
 + the DMA requests for this controller.
 +- #dma-cells:Must be at least 1. Used to provide DMA router 
 specific
 + information. See DMA client binding below for more
 + details.
 +
 +Optional properties:
 +- dma-requests:  Number of incoming request lines the router can handle.
 +- dma-device
 + - dma-requests: The router driver might need to look for this in order
 + to configure the routing.
 +
 +Example:
 + sdma_xbar: dma-router@4a002b78 {
 + compatible = ti,dra7-dma-crossbar;
 + reg = 0x4a002b78 0xfc;
 + #dma-cells = 1;
 + dma-requests = 205;
 + ti,dma-safe-map = 0;
 + dma-device = sdma;
 + };
  
  * DMA client
  
 diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
 index 344b0ac6d985..1bb67dae5880 100644
 --- a/drivers/dma/dmaengine.c
 +++ b/drivers/dma/dmaengine.c
 @@ -271,6 +271,13 @@ static void dma_chan_put(struct dma_chan *chan)
   /* This channel is not in use anymore, free it */
   if (!chan-client_count  chan-device-device_free_chan_resources)
   chan-device-device_free_chan_resources(chan);
 +
 + /* If the channel is used via a DMA request router, free the mapping */
 + if (chan-router  chan-router-route_free) {
 + chan-router-route_free(chan-router-dev, chan-route_data);
 + chan-router = NULL;
 + chan-route_data = NULL;
 + }
  }
  
  enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
 diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
 index ca31f1b45366..c86f8823da0d 100644
 --- a/drivers/dma/of-dma.c
 +++ b/drivers/dma/of-dma.c
 @@ -45,6 +45,53 @@ static struct of_dma *of_dma_find_controller(struct 
 of_phandle_args *dma_spec)
  }
  
  /**
 + * of_dma_router_xlate - translation function for router devices
 + * @dma_spec:pointer to DMA specifier as found in the device tree
 + * @of_dma:  pointer to DMA controller data (router information)
 + *
 + * The function creates new dma_spec to be passed to the router driver's
 + * of_dma_route_allocate() function to prepare a dma_spec which will be used
 + * to request channel from the real DMA controller.
 + */
 +static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
 + struct of_dma *ofdma)
 +{
 + struct dma_chan *chan;
 + struct of_dma   *ofdma_target;
 + struct device_node  *dma_target;
 + struct of_phandle_args  dma_spec_target;
 + void*route_data;
 +
 + dma_target = of_parse_phandle(dma_spec-np, dma-device, 0);
 + if (!dma_target) {
 + pr_err(%s: Can't get target DMA\n, __func__);
 + return NULL;
 + }
 +
 + /* translate the request for the real DMA controller */
 + memcpy(dma_spec_target, dma_spec, sizeof(dma_spec_target));
 + dma_spec_target.np = 

Re: [PATCH v2 4/7] dmaengine: omap-dma: Use defines for dma channels and request count

[Vinod Koul]

On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote:
 Instead of magic numbers in the code, use define for number of logical DMA
 channels and DMA requests.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/omap-dma.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
 index 7dd6dd121681..56c33e93dd24 100644
 --- a/drivers/dma/omap-dma.c
 +++ b/drivers/dma/omap-dma.c
 @@ -22,6 +22,9 @@
  
  #include virt-dma.h
  
 +#define OMAP_SDMA_REQUESTS   127
 +#define OMAP_SDMA_CHANNELS   32
Again why dont we put these things in DT ?

-- 
~Vinod
 +
  struct omap_dmadev {
   struct dma_device ddev;
   spinlock_t lock;
 @@ -33,7 +36,7 @@ struct omap_dmadev {
   bool legacy;
   spinlock_t irq_lock;
   uint32_t irq_enable_mask;
 - struct omap_chan *lch_map[32];
 + struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
  };
  
  struct omap_chan {
 @@ -1115,7 +1118,7 @@ static int omap_dma_probe(struct platform_device *pdev)
  
   tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
  
 - for (i = 0; i  127; i++) {
 + for (i = 0; i  OMAP_SDMA_REQUESTS; i++) {
   rc = omap_dma_chan_init(od, i);
   if (rc) {
   omap_dma_free(od);
 -- 
 2.3.0
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x

[Vinod Koul]

On Wed, Mar 11, 2015 at 03:23:26PM +0200, Peter Ujfalusi wrote:
 The DRA7x has more peripherals with DMA requests than the sDMA can handle:
 205 vs 127. All DMA requests are routed through the DMA crossbar, which can
 be configured to route selected incoming DMA requests to specific sDMA
 request.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/Kconfig   |   4 +
  drivers/dma/Makefile  |   1 +
  drivers/dma/ti-dma-crossbar.c | 190 
 ++
  3 files changed, 195 insertions(+)
  create mode 100644 drivers/dma/ti-dma-crossbar.c
 
 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index 074ffad334a7..519657a37ca1 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -247,6 +247,9 @@ config TI_EDMA
 Enable support for the TI EDMA controller. This DMA
 engine is found on TI DaVinci and AM33xx parts.
  
 +config TI_DMA_CROSSBAR
 + bool
 +
  config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
   bool
  
 @@ -332,6 +335,7 @@ config DMA_OMAP
   depends on ARCH_OMAP
   select DMA_ENGINE
   select DMA_VIRTUAL_CHANNELS
 + select TI_DMA_CROSSBAR if SOC_DRA7XX
  
  config DMA_BCM2835
   tristate BCM2835 DMA engine support
 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index bf4485800c60..6ec7af6a416c 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -39,6 +39,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
  obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
  obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
  obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 +obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
  obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
  obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
  obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
 diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
 new file mode 100644
 index ..591307bd4370
 --- /dev/null
 +++ b/drivers/dma/ti-dma-crossbar.c
 @@ -0,0 +1,190 @@
 +/*
 + *  Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
 + *  Author: Peter Ujfalusi peter.ujfal...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + */
 +#include linux/slab.h
 +#include linux/err.h
 +#include linux/init.h
 +#include linux/list.h
 +#include linux/io.h
 +#include linux/regmap.h
 +#include linux/idr.h
 +#include linux/of_address.h
 +#include linux/of_device.h
 +#include linux/of_dma.h
 +
 +#define TI_XBAR_OUTPUTS  127
 +#define TI_XBAR_INPUTS   256
Ideally this should be moved to DT. Will next revision of this chip always
support these output and inputs?

 +
 +static DEFINE_IDR(map_idr);
 +
 +struct ti_dma_xbar_data {
 + struct dma_router dmarouter;
 + struct regmap *regmap;
 +
 + uint safe_val; /* Value to rest the crossbar lines */
 + uint xbar_requests; /* number of DMA requests connected to XBAR */
 + uint dma_requests; /* number of DMA requests forwarded to DMA */
 +
 + void __iomem *iomem;
 +};
 +
 +struct ti_dma_xbar_map {
 + int xbar_in;
 + int xbar_out;
 +};
 +
 +static void ti_dma_xbar_free(struct device *dev, void *route_data)
 +{
 + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
 + struct ti_dma_xbar_map *map = route_data;
 +
 + dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
 + map-xbar_in, map-xbar_out);
 +
 + regmap_write(xbar-regmap, map-xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)

 +static int ti_dma_xbar_probe(struct platform_device *pdev)
 +{
 + struct device_node *node = pdev-dev.of_node;
 + struct device_node *dma_node;
 + struct ti_dma_xbar_data *xbar;
 + struct resource *res;
 + void __iomem *iomem;
 + int i, ret;
 +
 + if (!node)
 + return -ENODEV;
 +
 + dma_node = of_parse_phandle(node, dma-device, 0);
 + if (!dma_node) {
 + dev_err(pdev-dev, Can't get target DMA node\n);
 + return -ENODEV;
 + }
 +
 + xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
 + if (!xbar)
 + return -ENOMEM;
 +
 + if (of_property_read_u32(dma_node, dma-requests,
 +  xbar-dma_requests)) {
 + dev_info(pdev-dev,
 +  Missing XBAR output information, using %u.\n,
 +  TI_XBAR_OUTPUTS);
 + xbar-dma_requests = TI_XBAR_OUTPUTS;
 + }
 + of_node_put(dma_node);
_put here?

 +int omap_dmaxbar_init(void)
 +{
 + return platform_driver_register(ti_dma_xbar_driver);
 +}
 +arch_initcall(omap_dmaxbar_init);
why arch_initcall?

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers

[Vinod Koul]

On Thu, Mar 26, 2015 at 02:11:38PM +0200, Peter Ujfalusi wrote:
 On 03/26/2015 12:50 PM, Vinod Koul wrote:
  On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
  DMA routers are transparent devices used to mux DMA requests from
  peripherals to DMA controllers. They are used when the SoC integrates more
  devices with DMA requests then their controller can handle.
  DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
  lines, but in SoC level it has 205 DMA requests.
 
  The of_dma_router will be registered as of_dma_controller with special
  xlate function and additional parameters and the code will translate and
  requests a DMA channel from the real DMA controller.
  This way the router can be transparent for the system while remaining 
  generic
  enough to be used in different environments.
 
  Looks fine, was expecting a Documentation updates as well, but that can come
  as follow up patch too
 
 I have added the DT binding document since this series adds support for
 routers for platforms booting with DT:
 
 Documentation/devicetree/bindings/dma/dma.txt | 28 
I meant the update to Documnetation/dmanegine/ for routers :)

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x

[Vinod Koul]

On Thu, Mar 26, 2015 at 02:31:30PM +0200, Peter Ujfalusi wrote:
 On 03/26/2015 12:56 PM, Vinod Koul wrote:
  +#define TI_XBAR_OUTPUTS   127
  +#define TI_XBAR_INPUTS256
  Ideally this should be moved to DT. Will next revision of this chip always
  support these output and inputs?
 
 They are coming from DT. I'm using these as fall back values in case we can
 not get this from DT and a warning will be printed in case if this unlikely
 event happens.
Oops missed, that. Looks fine then

 
  +
  +static DEFINE_IDR(map_idr);
  +
  +struct ti_dma_xbar_data {
  +  struct dma_router dmarouter;
  +  struct regmap *regmap;
  +
  +  uint safe_val; /* Value to rest the crossbar lines */
  +  uint xbar_requests; /* number of DMA requests connected to XBAR */
  +  uint dma_requests; /* number of DMA requests forwarded to DMA */
  +
  +  void __iomem *iomem;
  +};
  +
  +struct ti_dma_xbar_map {
  +  int xbar_in;
  +  int xbar_out;
  +};
  +
  +static void ti_dma_xbar_free(struct device *dev, void *route_data)
  +{
  +  struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
  +  struct ti_dma_xbar_map *map = route_data;
  +
  +  dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
  +  map-xbar_in, map-xbar_out);
  +
  +  regmap_write(xbar-regmap, map-xbar_out * 2, 0);
  just out of curiosity how much do you save using regmap :)
 
 good point, not much I guess. I had it implemented w/o regmap as well, but
 thought why not use regmap if it is available.
Yes but there is overhead involved in setting it up. I though you have some
latency issues. It is okay to have it :)
Cache is anyways fastest :)

  +static int ti_dma_xbar_probe(struct platform_device *pdev)
  +{
  +  struct device_node *node = pdev-dev.of_node;
  +  struct device_node *dma_node;
  +  struct ti_dma_xbar_data *xbar;
  +  struct resource *res;
  +  void __iomem *iomem;
  +  int i, ret;
  +
  +  if (!node)
  +  return -ENODEV;
  +
  +  dma_node = of_parse_phandle(node, dma-device, 0);
  +  if (!dma_node) {
  +  dev_err(pdev-dev, Can't get target DMA node\n);
  +  return -ENODEV;
  +  }
  +
  +  xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
  +  if (!xbar)
  +  return -ENOMEM;
  +
  +  if (of_property_read_u32(dma_node, dma-requests,
  +   xbar-dma_requests)) {
  +  dev_info(pdev-dev,
  +   Missing XBAR output information, using %u.\n,
  +   TI_XBAR_OUTPUTS);
  +  xbar-dma_requests = TI_XBAR_OUTPUTS;
  +  }
  +  of_node_put(dma_node);
  _put here?
 
 The code takes the real dma controller's node and it should be put back after
 I have got the information I needed from it (number of DMA requests).
 
  
  +int omap_dmaxbar_init(void)
  +{
  +  return platform_driver_register(ti_dma_xbar_driver);
  +}
  +arch_initcall(omap_dmaxbar_init);
  why arch_initcall?
 
 It should be on the same init level as the real DMA controller. omap-dma at
 the moment, but in some platforms this can work with the edma as well.
 Since all device in the system (well most of them anyway) uses DMA it is
 better to not delay their probe with deferring because the crossbar driver is
 still not loaded
Deferring if resources not available is the right thing and helps you get rid
of init level ordering magic...

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma: cppi41: add missing directions bitfield

[Vinod Koul]

On Wed, Feb 25, 2015 at 04:54:02PM -0600, Felipe Balbi wrote:
 Without those we will see a kernel WARN()
 when loading musb on am335x devices.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/dma/cppi41.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 512cb8e2805e..4e9cc8e8100c 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -926,6 +926,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
   cdd-ddev.device_issue_pending = cppi41_dma_issue_pending;
   cdd-ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg;
   cdd-ddev.device_terminate_all = cppi41_stop_chan;
 + cdd-ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
   cdd-ddev.dev = dev;
   INIT_LIST_HEAD(cdd-ddev.channels);
   cpp41_dma_info.dma_cap = cdd-ddev.cap_mask;
Along with this please set src/dstn_addr_widths and residue_granularity
please

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file

[Vinod Koul]

On Thu, Nov 27, 2014 at 12:41:31PM +0200, Peter Ujfalusi wrote:
 include/linux/platform_data/ is not a correct place to keep the API
 definitions for edma, it is meant to be only for the pdata for the device.
 Clean up this by moving the API to include/linux/edma.h
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  arch/arm/common/edma.c |   3 +-
  arch/arm/mach-davinci/devices.c|   1 +
  arch/arm/mach-davinci/include/mach/da8xx.h |   1 +
  drivers/dma/edma.c |   2 +-
  include/linux/edma.h   | 153 
 +
  include/linux/platform_data/edma.h | 148 ++--
  sound/soc/davinci/davinci-pcm.h|   1 +
  7 files changed, 165 insertions(+), 144 deletions(-)
  create mode 100644 include/linux/edma.h
I was hoping that this will have delete for platform_data/edma.h, do we
still need that and why shouldn't we get rid of this :)

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] dmaengine: edma: check for echan-edesc = NULL in edma_dma_pause()

[Vinod Koul]

On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
 I added book keeping of whether or not the 8250-dma driver has an RX
 transfer pending or not so we don't BUG here if it calls
 dmaengine_pause() on a channel which has not a pending transfer. Guess
 what, this is not enough.
 The following can be triggered with a busy RX channel and hackbench in
 background:
 - DMA transfer completes. The callback is delayed via
   vchan_cookie_complete() into a tasklet so it das not happen asap.
 - hackbench keeps the system busy so the tasklet does not run soon.
 - the UART collected enough data and generates an timeout-interrupt.
   Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
   cancel it via invoking dmaengine_pause() first. This causes the segfault
   because echan-edesc is NULL now that the transfer completed (however
   the callback did not run yet).
 
 With this patch we don't BUG in the scenario described.

Applied thanks

-- 
~Vinod
 
 Cc: vinod.k...@intel.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/dma/edma.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 7b65633f495e..123f578d6dd3 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
  static int edma_dma_pause(struct edma_chan *echan)
  {
   /* Pause/Resume only allowed with cyclic mode */
 - if (!echan-edesc-cyclic)
 + if (!echan-edesc || !echan-edesc-cyclic)
   return -EINVAL;
  
   edma_pause(echan-ch_num);
 -- 
 2.1.0
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] dmaengine: edma: check for echan-edesc = NULL in edma_dma_pause()

[Vinod Koul]

On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
 I added book keeping of whether or not the 8250-dma driver has an RX
 transfer pending or not so we don't BUG here if it calls
 dmaengine_pause() on a channel which has not a pending transfer. Guess
 what, this is not enough.
 The following can be triggered with a busy RX channel and hackbench in
 background:
 - DMA transfer completes. The callback is delayed via
   vchan_cookie_complete() into a tasklet so it das not happen asap.
 - hackbench keeps the system busy so the tasklet does not run soon.
 - the UART collected enough data and generates an timeout-interrupt.
   Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
   cancel it via invoking dmaengine_pause() first. This causes the segfault
   because echan-edesc is NULL now that the transfer completed (however
   the callback did not run yet).
 
 With this patch we don't BUG in the scenario described.

Applied, thanks

-- 
~Vinod

 
 Cc: vinod.k...@intel.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/dma/edma.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 7b65633f495e..123f578d6dd3 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
  static int edma_dma_pause(struct edma_chan *echan)
  {
   /* Pause/Resume only allowed with cyclic mode */
 - if (!echan-edesc-cyclic)
 + if (!echan-edesc || !echan-edesc-cyclic)
   return -EINVAL;
  
   edma_pause(echan-ch_num);
 -- 
 2.1.0
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
 
 OK, I guess this is as good as it gets.
 
 What tree would you like it go through?

Since rest of the patches are dependent upon 1st patch which should go thru
your tree, we should merge this thru your tree

Thanks
-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend()
which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
sequentially. Then we do a tree wide update of current patterns which are
present. As evident from log below this pattern is frequent in the
kernel.

This series can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git
topic/pm_runtime_last_busy_and_autosuspend

Fengguang's kbuild has tested it so it shouldn't break things for anyone.
Barring one patch (explictyly mentioned in its changelog) rest are simple
replacements.

If all are okay, this should be merged thru PM tree as it depends on macro
addition.

Subhransu S. Prusty (1):
  PM: Add helper pm_runtime_last_busy_and_autosuspend()

Vinod Koul (26):
  dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper
  extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper
  drm/i915: use pm_runtime_last_busy_and_autosuspend helper
  drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper
  drm/radeon: use pm_runtime_last_busy_and_autosuspend helper
  vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper
  i2c: designware: use pm_runtime_last_busy_and_autosuspend helper
  i2c: omap: use pm_runtime_last_busy_and_autosuspend helper
  i2c: qup: use pm_runtime_last_busy_and_autosuspend helper
  mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper
  mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper
  mei: use pm_runtime_last_busy_and_autosuspend helper
  mmc: use pm_runtime_last_busy_and_autosuspend helper
  mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper
  mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper
  mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper
  mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper
  NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper
  pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper
  spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper
  spi: orion: use pm_runtime_last_busy_and_autosuspend helper
  spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper
  spi: core: use pm_runtime_last_busy_and_autosuspend helper
  tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper
  usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper
  video: fbdev: use pm_runtime_last_busy_and_autosuspend helper

 Documentation/power/runtime_pm.txt  |4 ++
 drivers/dma/ste_dma40.c |   30 -
 drivers/extcon/extcon-arizona.c |6 +--
 drivers/gpu/drm/i915/intel_pm.c |3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |3 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |9 +---
 drivers/gpu/drm/radeon/radeon_connectors.c  |   15 ++
 drivers/gpu/drm/radeon/radeon_drv.c |5 +-
 drivers/gpu/drm/radeon/radeon_kms.c |6 +--
 drivers/gpu/vga/vga_switcheroo.c|7 +--
 drivers/i2c/busses/i2c-designware-core.c|3 +-
 drivers/i2c/busses/i2c-omap.c   |6 +--
 drivers/i2c/busses/i2c-qup.c|3 +-
 drivers/mfd/ab8500-gpadc.c  |6 +--
 drivers/mfd/arizona-irq.c   |3 +-
 drivers/misc/mei/client.c   |   12 ++
 drivers/mmc/core/core.c |3 +-
 drivers/mmc/host/mmci.c |   12 ++
 drivers/mmc/host/omap_hsmmc.c   |   19 ++---
 drivers/mmc/host/sdhci-pxav3.c  |6 +--
 drivers/mmc/host/sdhci.c|3 +-
 drivers/nfc/trf7970a.c  |3 +-
 drivers/power/pm2301_charger.c  |3 +-
 drivers/spi/spi-omap2-mcspi.c   |9 +---
 drivers/spi/spi-orion.c |3 +-
 drivers/spi/spi-ti-qspi.c   |5 +-
 drivers/spi/spi.c   |6 +--
 drivers/tty/serial/omap-serial.c|   60 +--
 drivers/usb/musb/omap2430.c |6 +--
 drivers/video/fbdev/auo_k190x.c |9 +---
 include/linux/pm_runtime.h  |6 +++
 31 files changed, 97 insertions(+), 177 deletions(-)


Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/27] i2c: omap: use pm_runtime_last_busy_and_autosuspend helper

[Vinod Koul]

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code

Signed-off-by: Vinod Koul vinod.k...@intel.com
---
 drivers/i2c/busses/i2c-omap.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0dffb0e..8a7de50 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -661,8 +661,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
dev-set_mpu_wkup_lat(dev-dev, -1);
 
 out:
-   pm_runtime_mark_last_busy(dev-dev);
-   pm_runtime_put_autosuspend(dev-dev);
+   pm_runtime_last_busy_and_autosuspend(dev-dev);
return r;
 }
 
@@ -1253,8 +1252,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev-dev, bus %d rev%d.%d at %d kHz\n, adap-nr,
 major, minor, dev-speed);
 
-   pm_runtime_mark_last_busy(dev-dev);
-   pm_runtime_put_autosuspend(dev-dev);
+   pm_runtime_last_busy_and_autosuspend(dev-dev);
 
return 0;
 
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 26/27] usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper

[Vinod Koul]

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code

Signed-off-by: Vinod Koul vinod.k...@intel.com
---
 drivers/usb/musb/omap2430.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d369bf1..17c6c49 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -293,8 +293,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_NONE;
if (musb-gadget_driver) {
omap2430_musb_set_vbus(musb, 0);
-   pm_runtime_mark_last_busy(dev);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_last_busy_and_autosuspend(dev);
}
 
if (data-interface_type == MUSB_INTERFACE_UTMI)
@@ -321,8 +320,7 @@ static void omap_musb_mailbox_work(struct work_struct 
*mailbox_work)
 
pm_runtime_get_sync(dev);
omap_musb_set_mailbox(glue);
-   pm_runtime_mark_last_busy(dev);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_last_busy_and_autosuspend(dev);
 }
 
 static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/27] mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper

[Vinod Koul]

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
This patch also changes return value from macro rather than 0 always!

Signed-off-by: Vinod Koul vinod.k...@intel.com
---
 drivers/mmc/host/omap_hsmmc.c |   19 ---
 1 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9656726..2a2affc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1823,10 +1823,7 @@ static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
 {
struct omap_hsmmc_host *host = mmc_priv(mmc);
 
-   pm_runtime_mark_last_busy(host-dev);
-   pm_runtime_put_autosuspend(host-dev);
-
-   return 0;
+   return pm_runtime_last_busy_and_autosuspend(host-dev);
 }
 
 static const struct mmc_host_ops omap_hsmmc_ops = {
@@ -1877,10 +1874,7 @@ static int omap_hsmmc_regs_show(struct seq_file *s, void 
*data)
seq_printf(s, CAPA:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CAPA));
 
-   pm_runtime_mark_last_busy(host-dev);
-   pm_runtime_put_autosuspend(host-dev);
-
-   return 0;
+   return pm_runtime_last_busy_and_autosuspend(host-dev);
 }
 
 static int omap_hsmmc_regs_open(struct inode *inode, struct file *file)
@@ -2258,10 +2252,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
}
 
omap_hsmmc_debugfs(mmc);
-   pm_runtime_mark_last_busy(host-dev);
-   pm_runtime_put_autosuspend(host-dev);
-
-   return 0;
+   return pm_runtime_last_busy_and_autosuspend(host-dev);
 
 err_slot_name:
mmc_remove_host(mmc);
@@ -2386,9 +2377,7 @@ static int omap_hsmmc_resume(struct device *dev)
!(host-mmc-pm_flags  MMC_PM_WAKE_SDIO_IRQ))
enable_irq(host-wake_irq);
 
-   pm_runtime_mark_last_busy(host-dev);
-   pm_runtime_put_autosuspend(host-dev);
-   return 0;
+   return pm_runtime_last_busy_and_autosuspend(host-dev);
 }
 
 #else
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume

[Vinod Koul]

On Tue, Sep 16, 2014 at 10:45:55PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 Changes since v2:
 - fix typo in patch two
 - Acked-by added from Russell
 
 When the audio is paused/resumed (application paused the sream or board 
 suspend)
 the audio was only playing back one period worth of data and then stops 
 because
 the omap_dam_stop() clears the link configuration and it is not restored in
 start.
 
 Also add memory barrier call to resume path since this could happen right 
 after
 coming out from suspend.

Applied, thanks

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user

[Vinod Koul]

On Thu, Aug 21, 2014 at 03:09:12PM +0200, Sebastian Andrzej Siewior wrote:
 On 08/19/2014 05:12 PM, Vinod Koul wrote:
 
  desc = dmaengine_prep_slave_single(rxchan, …);
  rx_cookie = dmaengine_submit(desc);
  dma_async_issue_pending(rxchan);
 
  ssleep(2);
  /* Now assume that the transfer did not start */
  st = dmaengine_tx_status(rxchan, rx_cookie, NULL);
  /* st is now DMA_IN_PROGRESS as expected */
 
  dmaengine_terminate_all(rxchan);
  st = dmaengine_tx_status(rxchan, rx_cookie, NULL);
  and here is the culprit. You have terminated the channel. This means that
  dmaengine driver is free to clean up all the allocated descriptors on the
  channels and do whatever it decides to do with them.
 
 descriptors, yes.
and by that logic when you query the driver would have freed up!

  You have already terminated the channel so what is the point in querying the
  status of the cookie, which you shouldn't use anyway after invoking
  terminate_all() as its result is not correct.
 
 The point is to check (later, after terminate_all()) if there is an
 outstanding DMA transfer or not _and_ how much data was really
 transfered. Looking at edma it does not really support the latter if
 the transfer is already completed. On the plus side the HW does not
 support partly transfers :)
well that can be achieved properly and differently!
Why don't we pause the channel, get the residue, status and then
terminate.

 But where is it written that the life time of the cookie is limited?
 Looking at the cooking check code there is no such thing. It is
 simply compare of completed vs passed number but okay, this is an
 implementation detail.
 From [0] it says under 4. Submit the transaction:
 
 | This returns a cookie can be used to check the progress of DMA engine
 | activity via other DMA engine calls not covered in this document.
 
 no life time limit mentioned here. Which brings to the question: Why is
 it okay to use the cookie after the transaction terminated normally
 but not if it has been canceled?
Due to the special nature of terminate. The point here is that you don't
terminate a transaction but channel operation

 And from [0] the API explanation  4. … dma_async_is_tx_complete():


 
 |Note:
 |Not all DMA engine drivers can return reliable information for
 |a running DMA channel.  It is recommended that DMA engine users
 |pause or stop (via dmaengine_terminate_all) the channel before
 |using this API.
 
 So the documentation says to use the cookie with
 dma_async_is_tx_complete() and before doing so it is recommended that
 the transfer should be paused or stopped. _Exactly_ what is done here.
 
  /* st is still DMA_IN_PROGRESS but _I_ expect DMA_COMPLETE because
   * it has been terminated / canceled
   */
 
  Both dma driver clean up all / terminate all descriptors as required but
  _none_ of them completes the cookie. As a result dma_cookie_status()
  still thinks that the transfer is in progress.
  
  Btw how does it matter in the driver here if the transaction completed or
  not after terminate_all() was invoked. What is the purpose of querying
  status.
 
 In the RX interrupt (of the 8250 unit), the code checks if the transfer
 has been already started or not via querying the status. So if it
 returns DMA_COMPLETE then a new transfer will be started. If it returns
 DMA_IN_PROGRESS then the code returns doing nothing because the DMA
 engine should start moving data anytime now so the RX interrupt goes
 away.
 
 That means: If the transfer is canceled then it won't be started again.
 
 Btw: the current (probably only) dma driver that is used by 8250-dma is
 dw/core.c. That one does cookie complete on terminate:
  dwc_control(DMA_TERMINATE_ALL) - dwc_descriptor_complete() -
  dma_cookie_complete().
Yes but would above flow work for you :)

-- 
~Vinod

 
 That is why it works for them…
 
 [0] Documentation/dmaengine.txt
 
  
  Thanks
  
 
 Sebastian

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user

[Vinod Koul]

On Fri, Aug 08, 2014 at 06:29:50PM +0200, Sebastian Andrzej Siewior wrote:
 * Vinod Koul | 2014-07-31 17:47:02 [+0530]:
 
 On Tue, Jul 29, 2014 at 08:58:58PM +0200, Sebastian Andrzej Siewior wrote:
  The rx path of the 8250_dma user in the RX-timeout case:
  - it starts the RX transfer
  - if the rx-timeout interrupt occures, it dmaengine_pause() the transfer
  - step two is dmaengine_terminate_all() on this channel.
 Okay after this whole channel needs to be reset, which means all the
 descriptors are discared.
 
  To make the upper case work better, this patch adds dma_cookie_complete()
  to complete the cookie. Also it adds is an additional check for 
  echan-edesc
  in case the channel has no descriptor assigned.
 I think we are fixing the behvaiour rather than cause. terminate_all(()
 needs to do a proper cleanup of the channel
 
 In case you are not ignoring me but $reason here is an example that does
 not work (with both drivers);
Sorry This seems to have slipped thru, wasn't intentional!
 
 desc = dmaengine_prep_slave_single(rxchan, …);
 rx_cookie = dmaengine_submit(desc);
 dma_async_issue_pending(rxchan);
 
 ssleep(2);
 /* Now assume that the transfer did not start */
 st = dmaengine_tx_status(rxchan, rx_cookie, NULL);
 /* st is now DMA_IN_PROGRESS as expected */
 
 dmaengine_terminate_all(rxchan);
 st = dmaengine_tx_status(rxchan, rx_cookie, NULL);
and here is the culprit. You have terminated the channel. This means that
dmaengine driver is free to clean up all the allocated descriptors on the
channels and do whatever it decides to do with them.

You have already terminated the channel so what is the point in querying the
status of the cookie, which you shouldn't use anyway after invoking
terminate_all() as its result is not correct.

 /* st is still DMA_IN_PROGRESS but _I_ expect DMA_COMPLETE because
  * it has been terminated / canceled
  */
 
 Both dma driver clean up all / terminate all descriptors as required but
 _none_ of them completes the cookie. As a result dma_cookie_status()
 still thinks that the transfer is in progress.

Btw how does it matter in the driver here if the transaction completed or
not after terminate_all() was invoked. What is the purpose of querying
status.

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dmaengine: edma: Do not change the error code returned from edma_alloc_slot

[Vinod Koul]

On Thu, Jul 31, 2014 at 01:12:37PM +0300, Peter Ujfalusi wrote:
 In case of edma_alloc_slot() failure during probe we should return the error
 unchanged to make debugging easier.

Applied both

Thanks

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user

[Vinod Koul]

On Tue, Jul 29, 2014 at 08:58:58PM +0200, Sebastian Andrzej Siewior wrote:
 The rx path of the 8250_dma user in the RX-timeout case:
 - it starts the RX transfer
 - if the rx-timeout interrupt occures, it dmaengine_pause() the transfer
 - step two is dmaengine_terminate_all() on this channel.
Okay after this whole channel needs to be reset, which means all the
descriptors are discared.
 - based on dmaengine_tx_status() it learns the number of transfered
   bytes.
 - the rx interrupt occures,
why, channel is terminated, so existing txn needs to be aborted too

   it does not start the RX-transfer because
   according to dmaengine_tx_status() the status of the current transfer
   is still DMA_IN_PROGRESS because the earlier dmaengine_terminate_all()
   did not reset this.
there is no current transfer anymore

 - on rx-timeout it invokes dmaengine_pause() again. This time, it
   segfaults because the channel has no descriptor yet.
 
 To make the upper case work better, this patch adds dma_cookie_complete()
 to complete the cookie. Also it adds is an additional check for echan-edesc
 in case the channel has no descriptor assigned.
I think we are fixing the behvaiour rather than cause. terminate_all(()
needs to do a proper cleanup of the channel

And this looks a series, without cover letter sent to all. Which makes it a
bit hard to see what is getting done

-- 
~Vinod
 
 Cc: Joel Fernandes jo...@ti.com
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams dan.j.willi...@intel.com
 Cc: dmaeng...@vger.kernel.org
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  drivers/dma/edma.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index d08c4de..ff05dd4 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -256,6 +256,7 @@ static int edma_terminate_all(struct edma_chan *echan)
* echan-edesc is NULL and exit.)
*/
   if (echan-edesc) {
 + dma_cookie_complete(echan-edesc-vdesc.tx);
   echan-edesc = NULL;
   edma_stop(echan-ch_num);
   }
 @@ -282,7 +283,7 @@ static int edma_slave_config(struct edma_chan *echan,
  static int edma_dma_pause(struct edma_chan *echan)
  {
   /* Pause/Resume only allowed with cyclic mode */
 - if (!echan-edesc-cyclic)
 + if (!echan-edesc || !echan-edesc-cyclic)
   return -EINVAL;
  
   edma_pause(echan-ch_num);
 -- 
 2.0.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] dma: edma: Allow to disable eDMA IRQ during cyclic transfer

[Vinod Koul]

On Wed, Jul 16, 2014 at 03:29:19PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 After this series clients can ask to not receive notifications after each 
 period.
 In this case we can disable the completion interrupt since the position 
 reporting
 does not rely on it for cyclic mode.
 Patchset for ASoC part has been sent which allows users space to take 
 adventage
 of SNDRV_PCM_INFO_NO_PERIOD_WAKEUP:
 [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/078993.html

Applied, thanks

Please use right subsystem name for patches, i have fixed that while
applying

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] ARM/dma: edma: Serve cyclic clients via high priority queue

[Vinod Koul]

On Tue, Jul 08, 2014 at 01:46:35PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 It is preferred that audio is served with the highest priority queue in order 
 to
 avoid delays in data transfer between memory and audio IP.
 
 The following series will add an API to arch code to assign a channel to a 
 given
 queue.
 The default queue is changed from 0 (highest priority) to lowest priority.
 In the dmaengine driver we move the cyclic channel to queue0 (highest 
 priority)
 and move it back to default queue when the channel is terminated.

Applied, thanks

-- 
~Vinod

 
 Regards,
 Peter
 ---
 Peter Ujfalusi (3):
   ARM: edma: Set default queue to lowest priority
   ARM: edma: Add edma_assign_channel_eventq() to move channel to a give
 queue
   dma: edma: Serve cyclic (audio) channels with high priority queue
 
  arch/arm/common/edma.c | 31 ++-
  drivers/dma/edma.c |  8 
  include/linux/platform_data/edma.h |  2 ++
  3 files changed, 40 insertions(+), 1 deletion(-)
 
 -- 
 2.0.0
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/13] ARM/DT: edma: IP configuration from hardware and cleanups

[Vinod Koul]

On Tue, May 20, 2014 at 04:26:09PM +0530, Sekhar Nori wrote:
 On Monday 19 May 2014 10:23 PM, Peter Ujfalusi wrote:
  On 05/19/2014 04:06 PM, Sekhar Nori wrote:
  On Friday 16 May 2014 05:47 PM, Peter Ujfalusi wrote:
  Hi,
 
  Changes since v2:
  - Comments from Sekhar and Arnd has been addressed best as I could.
  - Use the CCCFG information in all cases instead of pdata provided 
  information
  - To achieve this I needed to do a bit more cleanup in this series
  - In the documentation patch, retrain the old properties for reference
  - Cleanups in the old davinci board files and removing edma_soc_info 
  members
 
  Changes sicne v1:
  - added missing patch to remove the memset from edma_of_parse_dt()
 
  We are requesting redundant information via DT for the driver since the 
  very same
  data is available in the HW: by reading and decoding the content of CCCFG
  register we can get:
  Number of channels: NUM_DMACH
  Number of regions: NUM_REGN
  Number of slots (PaRAM sets): NUM_PAENTRY
  Number of TC/EQ: NUM_EVQUE
 
  So these does not need to be provided by the DT binding.
 
  The driver will no longer look for these properties from DT and they can 
  be
  removed from the binding documentation and from the dtsi files as well.
  The change will not introduce regression when new kernel is booted using 
  older
  DTB (since we just ignore the mentioned properties).
 
  Applied all patches and pushed to branch v3.16/edma of:
 
  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
 
  Since the patches did not apply cleanly, please verify. I tested on
  DA850 EVM using MMC/SD as EDMA user.
  
  The patches in this series looks OK in your branch.
  However I can not find the following commits in there, which I have in 
  linux-next:
  c689a7b79c28 Merge remote-tracking branch 'slave-dma/next'
  cdae05a0f0f7 dmaengine: edma: Make reading the position of active channels 
  work
  cf7eb979116c ARM: common: edma: Fix xbar mapping
  232b223d8281 dmaengine: edma: Set DMA_CYCLIC capability flag
  7cf2af90cd51 arm: common: edma: Save the number of event queues/TCs
  
  They might come via different route...
 
 Vinod,
 
 Do you have an immutable branch based on which I can send this patch
 series to ARM-SoC? Some of the patches in the series depend on code that
 went through your tree.
yup, pls pull my topic/edma for these change. This branch will not be rebased.

 Or if you are comfortable taking this series through your tree, thats
 okay by me too. We are still waiting for acks from DT maintainers on the
 binding change patches.
Since these patchs are for ARM, I think they are best suited thru arm tree. If
you run into issues with that I cna merge this but with right ACKs...

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] dmaengine: edma: Add channel number to debug prints

[Vinod Koul]

On Thu, Apr 24, 2014 at 10:29:50AM +0300, Peter Ujfalusi wrote:
 It helps to identify issues if we have some information regarding to the
 channel which the event is associated.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 Acked-by: Joel Fernandes jo...@ti.com
Applied, thanks

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch V2 0/6] dma: edma: Provide granular residue accounting

[Vinod Koul]

On Mon, Apr 28, 2014 at 03:47:37PM -0500, Joel Fernandes wrote:
 On 04/28/2014 05:49 AM, Thomas Gleixner wrote:
  A simpler version to provide granular residue accounting and readout
  for EDMA.
  
  Delta to V1:
  
- Removed the double read of the address in PaRAM
  
- Simplified the stats update in the interrupt callback for
  intermediate transfers
  
  Thanks,
  
  tglx
  
 
 Thanks for the series. I went over all the patches and it looks great.
 Acked-by: Joel Fernandes jo...@ti.com
 
 The patches however didn't apply and had some conflicts with my dma
 memcpy series and peter's cyclic series so I resolved conflicts and
 created a single branch based on Vinod's slave-dma next branch (commit
 406efb1a745c1dc512dc9c3c859e302e7b7f907e) that Vinod can pull.
 
 I also renamed subject line of patches in Thomas's series to be
 dmaengine: edma and documented some of the variables used.
 
 https://github.com/joelagnel/linux-kernel.git (for-vinod branch)
 
 Vinod, could you pull if it looks OK?

The patches look good.

But,
commit 770f0f3a20188b7e17db2790803b9da925dc0b94
Author: Thomas Gleixner t...@linutronix.de
Date:   Mon Apr 28 10:49:43 2014 +

dmaengine: edma: Make reading the position of active channels work

As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
the parameter ram. That's not synchronized with the internal update as
it does a byte by byte copy. We need to do a 32bit read to get a
consistent value.

Further reading destination and source is pointless. In DEV_TO_MEM
transfers we are only interested in the destination, in MEM_TO_DEV we
care about the source. In MEM_TO_MEM it really does not matter which
one you read.

Simple solution: Remove the pointers, select dest/source via a bool
and return the read value.

Remove the export of this function while at it. The only potential
user is the dmaengine and that's always builtin.

Signed-off-by: Thomas Gleixner t...@linutronix.de

You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo
this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
already fetched your branch

Either way is fine with me...

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch V2 0/6] dma: edma: Provide granular residue accounting

[Vinod Koul]

On Tue, Apr 29, 2014 at 11:25:02PM -0500, Joel Fernandes wrote:
 On 04/29/2014 03:46 AM, Vinod Koul wrote:
 [..]
  commit 770f0f3a20188b7e17db2790803b9da925dc0b94
  Author: Thomas Gleixner t...@linutronix.de
  Date:   Mon Apr 28 10:49:43 2014 +
  
  dmaengine: edma: Make reading the position of active channels work
  
  As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
  the parameter ram. That's not synchronized with the internal update as
  it does a byte by byte copy. We need to do a 32bit read to get a
  consistent value.
  
  Further reading destination and source is pointless. In DEV_TO_MEM
  transfers we are only interested in the destination, in MEM_TO_DEV we
  care about the source. In MEM_TO_MEM it really does not matter which
  one you read.
  
  Simple solution: Remove the pointers, select dest/source via a bool
  and return the read value.
  
  Remove the export of this function while at it. The only potential
  user is the dmaengine and that's always builtin.
  
  Signed-off-by: Thomas Gleixner t...@linutronix.de
  
  You s-o-b missing in this one, also ack from Sekhar missing. Do you want to 
  redo
  this or prefer me to cherry-pick patches adding acks and your s-o-b, since I
  already fetched your branch
  
  Either way is fine with me...
  
 
 If its Ok with you, it would great if you could add my Ack and Sob.
 Thanks a lot. Let me know if you'd want me to do anything else here.
Done, The changes are getting pushed, pls do verify

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: edma: No need save/restore interrupt flags during spin_lock in IRQ

[Vinod Koul]

On Thu, Apr 17, 2014 at 12:58:33AM -0500, Joel Fernandes wrote:
 The vchan lock in edma_callback is acquired in hard interrupt context. As
 interrupts are already disabled, there's no point in save/restoring interrupt
 mask bit or cpsr flags.
 
 Get rid of flags local variable and use spin_lock instead of 
 spin_lock_irqsave.

Applied, thanks

-- 
~Vinod

 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  drivers/dma/edma.c |9 -
  1 file changed, 4 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 91849aa..25a75e2 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -638,7 +638,6 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
 void *data)
   struct edma_chan *echan = data;
   struct device *dev = echan-vchan.chan.device-dev;
   struct edma_desc *edesc;
 - unsigned long flags;
   struct edmacc_param p;
  
   edesc = echan-edesc;
 @@ -649,7 +648,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
 void *data)
  
   switch (ch_status) {
   case EDMA_DMA_COMPLETE:
 - spin_lock_irqsave(echan-vchan.lock, flags);
 + spin_lock(echan-vchan.lock);
  
   if (edesc) {
   if (edesc-cyclic) {
 @@ -665,11 +664,11 @@ static void edma_callback(unsigned ch_num, u16 
 ch_status, void *data)
   }
   }
  
 - spin_unlock_irqrestore(echan-vchan.lock, flags);
 + spin_unlock(echan-vchan.lock);
  
   break;
   case EDMA_DMA_CC_ERROR:
 - spin_lock_irqsave(echan-vchan.lock, flags);
 + spin_lock(echan-vchan.lock);
  
   edma_read_slot(EDMA_CHAN_SLOT(echan-slot[0]), p);
  
 @@ -700,7 +699,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
 void *data)
   edma_trigger_channel(echan-ch_num);
   }
  
 - spin_unlock_irqrestore(echan-vchan.lock, flags);
 + spin_unlock(echan-vchan.lock);
  
   break;
   default:
 -- 
 1.7.9.5
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/10] dma: edma: Fixes for cyclic (audio) operation

[Vinod Koul]

On Mon, Apr 14, 2014 at 02:41:55PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 Changes since v2:
 - Dropped patch 10 from v2 (simplify direction configuration...)
 - Dropped the channel priority related patches since we are going to go via
   different route for configuring the priority.
 - Added ACK from Joel for the patches since they are not changed since v2
 
 Changes since v1:
 - ASoC patches removed
 - Comments from Andriy Shevchenko addressed
 - patch added to fix cases when src/dst_maxburst is set to 0
 
 The series contains now only:
 Support for DMA pause/resume in cyclic mode
 device_slave_caps callback and DMA_CYCLIC flag correction.
 While debugging the edma to get things sorted out I noticed that the debug was
 too verbose and the important information was hidden even when the we did not
 asked for verbose dmaengine debug.
 I have included some debug cleanups for the edma dmaengine driver also.
 
Applied all, expect 9th one!

-- 
~Vinod

 Regards,
 Peter
 ---
 Peter Ujfalusi (10):
   platform_data: edma: Be precise with the paRAM struct
   arm: common: edma: Save the number of event queues/TCs
   dmaengine: edma: Correct the handling of src/dst_maxburst == 0
   dmaengine: edma: Add support for DMA_PAUSE/RESUME operation
   dmaengine: edma: Set DMA_CYCLIC capability flag
   dmaengine: edma: Implement device_slave_caps callback
   dmaengine: edma: Reduce debug print verbosity for non verbose
 debugging
   dmaengine: edma: Prefix debug prints where the text were identical in
 prep callbacks
   dmaengine: edma: Add channel number to debug prints
   dmaengine: edma: Print the direction value as well when it is not
 supported
 
  arch/arm/common/edma.c |  4 ++
  drivers/dma/edma.c | 87 
 ++
  include/linux/platform_data/edma.h | 18 
  3 files changed, 83 insertions(+), 26 deletions(-)
 
 -- 
 1.9.2
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: edma: Add DMA memcpy support

[Vinod Koul]

On Fri, Apr 18, 2014 at 09:50:33PM -0500, Joel Fernandes wrote:
 We add DMA memcpy support to EDMA driver. Successful tests performed using
 dmatest kernel module. Copy alignment is set to DMA_SLAVE_BUSWIDTH_4_BYTES and
 users must ensure length is aligned so that copy is performed fully.

Applied, thanks

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [FIX] dmaengine: virt-dma: Free descriptor after callback

[Vinod Koul]

On Fri, Apr 18, 2014 at 11:34:50AM -0500, Joel Fernandes wrote:
 On 04/18/2014 03:50 AM, Russell King - ARM Linux wrote:
  On Thu, Apr 17, 2014 at 07:56:50PM -0500, Joel Fernandes wrote:
  Free the vd (virt descriptor) after the callback is called.  In EDMA driver
  atleast which uses virt-dma, we make use of the desc during the callback 
  and if
  its dangerously freed before the callback is called. I also noticed this in
  omap-dma dmaengine driver.
  
  You've missed the vital bit of information: why do you make use of the
  descriptor afterwards?  You shouldn't.  omap-dma doesn't either.
  
  Once clients submit their request to DMA engine, they must not hold any
  kind of reference to the descriptor other than the cookie.
  
 
 Sorry, I confused edma/omap-dma callbacks for virt dma callbacks.
 
 Anyway, I think there is still a chance in edma that we refer to the
 echan-edesc pointer later on after virt-dma calls the free (in
 edma_execute), so I'll just NULL that out to be safe and submit a patch.

Yes, that would be the right way :)

While looking at this, I see it is not called out specfically in documentation, 
will update
that as well

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] dma: edma: fix incorrect SG list handling

[Vinod Koul]

On Mon, Apr 14, 2014 at 02:01:11PM +0530, Sekhar Nori wrote:
 Vinod,
 
 On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote:
  The code to handle any length SG lists calls edma_resume()
  even before edma_start() is called. This is incorrect
  because edma_resume() enables edma events on the channel
  after which CPU (in edma_start) cannot clear posted
  events by writing to ECR (per the EDMA user's guide).
  
  Because of this EDMA transfers fail to start if due
  to some reason there is a pending EDMA event registered
  even before EDMA transfers are started. This can happen if
  an EDMA event is a byproduct of device initialization.
  
  Fix this by calling edma_resume() only if it is not the
  first batch of MAX_NR_SG elements.
  
  Without this patch, MMC/SD fails to function on DA850 EVM
  with DMA. The behaviour is triggered by specific IP and
  this can explain why the issue was not reported before
  (example with MMC/SD on AM335x).
  
  Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.
  
  Cc: sta...@vger.kernel.org # v3.12.x+
  Cc: Joel Fernandes jo...@ti.com
  Acked-by: Joel Fernandes jo...@ti.com
  Tested-by: Jon Ringle jrin...@gridpoint.com
  Tested-by: Alexander Holler hol...@ahsoftware.de
  Reported-by: Jon Ringle jrin...@gridpoint.com
  Signed-off-by: Sekhar Nori nsek...@ti.com
 
 Looks like this patch is not in mainline still?

Sorry looks like I have missed sending the email. I had applied it last week and
today rebased after rc1. It would be part of rc2...

-- 
~Vinod
 
 Thanks,
 Sekhar

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

[Vinod Koul]

On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote:
 On 04/11/2014 11:56 AM, Sekhar Nori wrote:
  On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
  On 04/11/2014 11:17 AM, Sekhar Nori wrote:
  On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
  Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
  priority channels, like audio.
 
  Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 
  Acked-by: Sekhar Nori nsek...@ti.com
 
  ---
   arch/arm/common/edma.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
  index 86a8b263278f..19520e2519d9 100644
  --- a/arch/arm/common/edma.c
  +++ b/arch/arm/common/edma.c
  @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev,
   
   pdata-queue_priority_mapping = queue_priority_map;
   
  -pdata-default_queue = 0;
  +/* select queue 1 as default */
 
  It will be nice to expand the comment with explanation of why this is
  being chosen as default (lower priority queue by default for typical
  bulk data transfer).
 
  Yes, extended comment is a good idea.
 
  For the next version I think I'm going to change the code around default
  TC/Queue and the non default queue selection, mostly based on Joel's 
  comment:
 
  EVENTQ_1 as default queue.
  Set the EVENTQ_1 priority to 7
  EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2
 
  Add new member to struct edma, like high_pri_queue.
  When we set the queue priorities in edma_probe() we look for the highest
  priority queue and save the number in high_pri_queue.
 
  I will rename the edma_request_non_default_queue() to
  edma_request_high_pri_queue() and it will assign the channel to the high
  priority queue.
 
  I think this way it is going to be more explicit and IMHO a bit more safer 
  in
  a sense the we are going to get high priority when we ask for it.
  
  Sounds much better. I had posted some ideas about adding support for
  channel priority in the core code but we can leave that for Vinod and
  Dan to say if they really see a need for that.
Is it part of this series?

 If we do it via the dmaengine core I think it would be better to have a new
 flag to be passed to dmaengine_prep_dma_*().
 We could have for example:
 DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is
 possible.
 We can watch for this flag in the edma driver and act accordingly.
 ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally
 since audio should be treated in this way if the DMA IP can do this.
Will the priority be different for each descriptor or would be based on channel
usage. If not then we can add this in dma_slave_config ?

I can forsee its usage on slave controllers, so yes its useful :)

-- 
~Vinod

 
 Not sure what to do with eDMA's 8 priority level. With that we could have high
 priority; low priority; low, but not the lowest priority; about in the middle
 priority; etc.
 
 We could have also new callback in the dma_device struct with needed wrappers
 to set priority level, but where to draw the range? High, Mid and Low? Range
 of 0 - 10?
 
 -- 
 Péter

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

[Vinod Koul]

On Fri, Apr 11, 2014 at 02:32:28PM +0300, Peter Ujfalusi wrote:
 Hi Vinod,
 
 On 04/11/2014 12:42 PM, Vinod Koul wrote:
  On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote:
  On 04/11/2014 11:56 AM, Sekhar Nori wrote:
  On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
  On 04/11/2014 11:17 AM, Sekhar Nori wrote:
  On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
  Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
  priority channels, like audio.
 
  Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 
  Acked-by: Sekhar Nori nsek...@ti.com
 
  ---
   arch/arm/common/edma.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
 
  diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
  index 86a8b263278f..19520e2519d9 100644
  --- a/arch/arm/common/edma.c
  +++ b/arch/arm/common/edma.c
  @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev,
   
 pdata-queue_priority_mapping = queue_priority_map;
   
  -  pdata-default_queue = 0;
  +  /* select queue 1 as default */
 
  It will be nice to expand the comment with explanation of why this is
  being chosen as default (lower priority queue by default for typical
  bulk data transfer).
 
  Yes, extended comment is a good idea.
 
  For the next version I think I'm going to change the code around default
  TC/Queue and the non default queue selection, mostly based on Joel's 
  comment:
 
  EVENTQ_1 as default queue.
  Set the EVENTQ_1 priority to 7
  EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2
 
  Add new member to struct edma, like high_pri_queue.
  When we set the queue priorities in edma_probe() we look for the highest
  priority queue and save the number in high_pri_queue.
 
  I will rename the edma_request_non_default_queue() to
  edma_request_high_pri_queue() and it will assign the channel to the high
  priority queue.
 
  I think this way it is going to be more explicit and IMHO a bit more 
  safer in
  a sense the we are going to get high priority when we ask for it.
 
  Sounds much better. I had posted some ideas about adding support for
  channel priority in the core code but we can leave that for Vinod and
  Dan to say if they really see a need for that.
  Is it part of this series?
 
 No, it is not. The original series tackled the DMA queue selection within the
 edma driver stack. It was selecting high priority channel for cyclic (audio)
 use only, all other DMA channels were executed on a lower priority queue.
 
  If we do it via the dmaengine core I think it would be better to have a new
  flag to be passed to dmaengine_prep_dma_*().
  We could have for example:
  DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it 
  is
  possible.
  We can watch for this flag in the edma driver and act accordingly.
  ALSA's dmaengine_pcm_prepare_and_submit() could set this flag 
  unconditionally
  since audio should be treated in this way if the DMA IP can do this.
 
  Will the priority be different for each descriptor or would be based on 
  channel
  usage.
 
 I would say that it is channel based config. I don't see the reason why would
 one mix different priorities on a configured channel between descriptors.
 
  If not then we can add this in dma_slave_config ?
 
 So adding to the struct for example:
 bool high_priority;

In designware controller, we can have channel priorties from 0 to 7 which IIRC 7
being highest. So bool wont work. unsigned int/u8 would be good. How about your
controller, is it binary?

-- 
~Vinod

 
 I'm not sure if it helps if we have let's say three priority level like, low,
 normal and high.
 I don't think that any client would ask for low priority instead using the
 normal priority.
 
  I can forsee its usage on slave controllers, so yes its useful :)
 
 True I'm sure it is going to be used as soon as it is available if the HW
 supports priorities.
 
 -- 
 Péter

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

[Vinod Koul]

On Fri, Apr 11, 2014 at 03:23:54PM +0300, Peter Ujfalusi wrote:
 On 04/11/2014 02:31 PM, Vinod Koul wrote:
 
  I would say that it is channel based config. I don't see the reason why 
  would
  one mix different priorities on a configured channel between descriptors.
 
  If not then we can add this in dma_slave_config ?
 
  So adding to the struct for example:
  bool high_priority;
  
  In designware controller, we can have channel priorties from 0 to 7 which 
  IIRC 7
  being highest. So bool wont work. unsigned int/u8 would be good.
 
 I see. But from a generic code what number should one pass if we want to get
 the highest priority? With eDMA3 we essentially have three levels (see later)
 so if we receive 7 as priority what shall we do? Just treat as highest? But if
 we receive 4, which is somewhere in the middle for designware it is still
 means highest for us.
 
 I see this too small step partitioning in common code a bit problematic when
 it comes to how to interpret the 'magic numbers'.
 Also how all the driver in the system will decide the priority number? I'm
 sure they will pick something conveniently average for themselves and I
 imagine audio would try to pick something which is bigger than the numbers
 others have taken...
 
  How about your controller, is it binary?
 
 We also have priority from 0 to 7, 0 being the highest priority. We have 3
 Transfer Controllers/Event Queues and we can set the priority for the TC/EQ
 and assign the given channel to the desired TC/EQ.
 So in reality we have 3 priorities to choose from in my view since we only
 have 3 TC/EQ in eDMA3 (of AM335x/AM447x) on other SoCs we can have different
 number of TC/EQ.

I think the number shouldn't be viewed in absolute terms. If we decide that 
(lets
say) 0-7, then any controller should map 0 to lowest and 7 to highest.

For your case you can do this and then intermediate numbers would be medium
priority. Such a system might work well...

Also how would a client driver know which priority to use? Would it come from
DT?

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/14] dma: edma: Add support for DMA_PAUSE/RESUME operation

[Vinod Koul]

On Tue, Apr 01, 2014 at 04:06:04PM +0300, Peter Ujfalusi wrote:
 Pause/Resume can be used by the audio stack when the stream is paused/resumed
 The edma platform code has support for this and the legacy audio stack used
 this.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 28 
  1 file changed, 28 insertions(+)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 2742867fd1e6..7891378a03f0 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
   return 0;
  }
  
 +static int edma_dma_pause(struct edma_chan *echan)
 +{
 + /* Pause/Resume only allowed with cyclic mode */
 + if (!echan-edesc-cyclic)
 + return -EINVAL;
why this artificial restriction? The driver can do pause even for non cyclic
cases too? Yes the usage is in cyclic context but why should we limit any future
work on this?

-- 
~Vinod
 +
 + edma_pause(echan-ch_num);
 + return 0;
 +}
 +
 +static int edma_dma_resume(struct edma_chan *echan)
 +{
 + /* Pause/Resume only allowed with cyclic mode */
 + if (!echan-edesc-cyclic)
 + return -EINVAL;
 +
 + edma_resume(echan-ch_num);
 + return 0;
 +}
 +
  static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
   unsigned long arg)
  {
 @@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum 
 dma_ctrl_cmd cmd,
   config = (struct dma_slave_config *)arg;
   ret = edma_slave_config(echan, config);
   break;
 + case DMA_PAUSE:
 + ret = edma_dma_pause(echan);
 + break;
 +
 + case DMA_RESUME:
 + ret = edma_dma_resume(echan);
 + break;
 +
   default:
   ret = -ENOSYS;
   }
 -- 
 1.9.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 08/14] DMA: edma: Use different eventq for cyclic channels

[Vinod Koul]

On Thu, Apr 10, 2014 at 11:36:30AM -0500, Joel Fernandes wrote:
 On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
  To improve latency with cyclic DMA operation it is preferred to
  use different eventq/tc than the default which is used by all
  other drivers (mmc, spi, i2c, etc).
  When preparing the cyclic dma ask for non default queue for the
  channel which is going to be used with cyclic mode.
  
  Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
  ---
   drivers/dma/edma.c | 3 +++
   1 file changed, 3 insertions(+)
  
  diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
  index 1dd9e8806975..10048b40fac8 100644
  --- a/drivers/dma/edma.c
  +++ b/drivers/dma/edma.c
  @@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor 
  *edma_prep_dma_cyclic(
  edesc-pset[i].opt |= TCINTEN;
  }
   
  +   /* Use different eventq/tc for cyclic DMA to reduce latency */
  +   edma_request_non_default_queue(echan-ch_num);
  +
  return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags);
   }
   
  
 
 Is there any way to guarantee that the non-default queue is of the
 highest priority, or in other words default queue is of lowest priority.
well as we are discussing in other thread, it would make sense to pass the
required priority (i am using audio so pls give me highest one)

-- 
~Vinod
 I know you set queue 1 as default because by default 0 is higher
 priority. And then assigning non-default queue.
 
 When assigning default to Queue 1, it would be good to also call
 assign_priority_to_queue and set QUEPRI to 7 for Queue 1. Since 0, 2 and
 4 are all non-defaults.
 
 Thanks,
 -Joel

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/14] dma: edma: Fixes for cyclic (audio) operation

[Vinod Koul]

On Tue, Apr 01, 2014 at 04:06:01PM +0300, Peter Ujfalusi wrote:
 Hi,
 
 This is basically a resend of the previous series:
 https://lkml.org/lkml/2014/3/13/119
 with removed ASoC patches (most of them are applied already).
 
 Changes since v1:
 - ASoC patches removed
 - Comments from Andriy Shevchenko addressed
 - patch added to fix cases when src/dst_maxburst is set to 0
 
 Adding support for DMA pause/resume
 Possibility to select non default event queue/TC for cyclic (audio) dma
 channels: all devices using the eDMA via dmaengine was assigned to the default
 EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system
 performance point of view since sharing the same EQ/TC can cause latency 
 spikes
 for cyclic channels (long DMA transfers for MMC for example).
 
 While debugging the edma to get things sorted out I noticed that the debug was
 too verbose and the important information was hidden even when the we did not
 asked for verbose dmaengine debug.
 I have included some debug cleanups for the edma dmaengine driver also.
 
 Regards,
 Peter
 ---
 Peter Ujfalusi (14):
   platform_data: edma: Be precise with the paRAM struct
   dma: edma: Correct the handling of src/dst_maxburst == 0
   dma: edma: Add support for DMA_PAUSE/RESUME operation
   dma: edma: Set DMA_CYCLIC capability flag
   arm: common: edma: Select event queue 1 as default when booted with DT
   arm: common: edma: Save the number of event queues/TCs
   arm: common: edma: API to request non default queue for a channel
   DMA: edma: Use different eventq for cyclic channels
   dma: edma: Implement device_slave_caps callback
   dma: edma: Simplify direction configuration in edma_config_pset()
   dma: edma: Reduce debug print verbosity for non verbose debugging
   dma: edma: Prefix debug prints where the text were identical in prep
 callbacks
   dma: edma: Add channel number to debug prints
   dma: edma: Print the direction value as well when it is not supported

Okay I have noticed lots of folks are using dma: which IMO isn't right here,
would prefer folks to use the right subsystem name, so dmaengine:  would be
right subject line :)

-- 
~Vinod
 
  arch/arm/common/edma.c | 34 +-
  drivers/dma/edma.c | 96 
 +-
  include/linux/platform_data/edma.h | 20 
  3 files changed, 119 insertions(+), 31 deletions(-)
 
 -- 
 1.9.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/26] OMAP dma engine rework

[Vinod Koul]

On Sat, Mar 29, 2014 at 06:13:06PM +, Russell King - ARM Linux wrote:
 On Tue, Mar 18, 2014 at 09:18:45PM +0530, Vinod Koul wrote:
  On Mon, Feb 10, 2014 at 09:25:31PM +0530, Russell King - ARM Linux wrote:
   This is the current set of patches for the OMAP DMA engine rework,
   which should now work correctly on OMAP1 platforms thanks to Tony's
   testing.
   
   It would be good to get this validated by others across a range of
   OMAP platforms, and queued up for the next merge window, so it can
   be built upon.
   
   Acks appreciated, and once sufficient have been added, I'll send a
   pull request for this to Vinod.
  So is this series finalized. I havent seen the pull request for this or did 
  i
  miss it!
 
 Gah, missed this.
 
 As nothing has changed with it since 18th February, which was to add
 Tony's ack to the set.  I think it's as good as it's going to get for
 the time being.  It's also been in linux-next all this time, and no
 one has reported any problems.  I'll need to sort out a proper pull
 request for it ASAP... or something.  An alternate solution would be
 your blessing for this set.
Okay in that case pls send with my ACK.

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma: omap-dma: Implement device_slave_caps callback

[Vinod Koul]

On Fri, Mar 07, 2014 at 03:36:44PM +0200, Peter Ujfalusi wrote:
 With the callback implemented omap-dma can provide information to client
 drivers regarding to supported address widths, directions, residue
 granularity, etc.


Applied, thanks

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/26] OMAP dma engine rework

[Vinod Koul]

On Mon, Feb 10, 2014 at 09:25:31PM +0530, Russell King - ARM Linux wrote:
 This is the current set of patches for the OMAP DMA engine rework,
 which should now work correctly on OMAP1 platforms thanks to Tony's
 testing.
 
 It would be good to get this validated by others across a range of
 OMAP platforms, and queued up for the next merge window, so it can
 be built upon.
 
 Acks appreciated, and once sufficient have been added, I'll send a
 pull request for this to Vinod.
So is this series finalized. I havent seen the pull request for this or did i
miss it!

-- 
~Vinod
 
  arch/arm/mach-omap1/dma.c | 191 ++
  arch/arm/mach-omap2/dma.c | 183 ++---
  arch/arm/plat-omap/dma.c  |  17 +-
  drivers/dma/omap-dma.c| 659 
 +-
  include/linux/omap-dma.h  |  25 +-
  5 files changed, 784 insertions(+), 291 deletions(-)
 
 -- 
 FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
 in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
 Estimate before purchase was up to 13.2Mbit.

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine

[Vinod Koul]

On Thu, Jan 02, 2014 at 03:08:36PM +, Russell King - ARM Linux wrote:
 The following patch series moves code to setup the DMA hardware and
 service interrupts from the hardware to the DMA engine driver.  This
 reduces the dependency on the legacy DMA implementation.
Didnt the code getting removed from legacy, are there any users still of
the legacy driver in mainline?

--
~Vinod
 
 This series does not remove the channel allocation/freeing hooks which
 are used to manage the allocation of physical channels - this is the
 next step in the evolution.
 
 The patches which move the interrupt handling are currently less than
 perfect since they're writing to ENABLE_L0 under a different spinlock,
 and hence RFC only at the moment.
 
  arch/arm/mach-omap1/dma.c |  183 +
  arch/arm/mach-omap2/dma.c |  183 ++
  arch/arm/plat-omap/dma.c  |   17 +-
  drivers/dma/omap-dma.c|  653 
 -
  include/linux/omap-dma.h  |   25 ++-
  5 files changed, 774 insertions(+), 287 deletions(-)
 
 -- 
 FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
 in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
 Estimate before purchase was up to 13.2Mbit.

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cppi41: pending patches

[Vinod Koul]

On Tue, Oct 22, 2013 at 12:14:02PM +0200, Sebastian Andrzej Siewior wrote:
 Hi Vinod,
 
 this series contains patches which are floating on the mainling list so
 I hope it is easier to collect them. It contains two of Daniel's which
 were not yet applied and two of mine.
 The patch redo descriptor collection in abort case was posted earlier
 and tested by Daniel, in this version here I removed an unused variable.
 
 The patches are also available in a git tree based on your next tree prior
 the the dma_complete merge because DMA_COMPLETE  DMA_SUCCESS contain a
 diferent value.
Applied, thanks

--
~Vinod
 
 The following changes since commit cc94dac27e15df9211394467e13fdfa2366e3593:
 
   Merge branch 'for-linus' into next (2013-10-21 12:57:31 +0530)
 
 are available in the git repository at:
 
 
   git://breakpoint.cc/bigeasy/linux tags/cppi41-next
 
 for you to fetch changes up to e389973c52dbea967a9254798600c35c8f94b2c3:
 
   dma: cppi41: return code  0 of pm_runtime_get_sync() is not an error 
 (2013-10-22 12:00:45 +0200)
 
 
 A handfull of cppi41 patches including pm support by Daniel Mack.
 
 
 Daniel Mack (2):
   dma: cppi41: restore more registers
   dma: cppi41: use cppi41_pop_desc() where possible
 
 Sebastian Andrzej Siewior (2):
   dma: cppi41: redo descriptor collection in abort case
   dma: cppi41: return code  0 of pm_runtime_get_sync() is not an error
 
  drivers/dma/cppi41.c | 82 
 +++-
  1 file changed, 43 insertions(+), 39 deletions(-)
 
 Sebastian

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] dma: edma: Add support for Cyclic DMA

[Vinod Koul]

On Thu, Oct 31, 2013 at 04:31:23PM -0500, Joel Fernandes wrote:
 Using the PaRAM configuration function that we split for reuse by the
 different DMA types, we implement Cyclic DMA support.
 For the cyclic case, we pass different configuration parameters to this
 function, and handle all the Cyclic-specific functionality separately.
 
 Callbacks to the DMA users are handled using vchan_cyclic_callback in
 the virt-dma layer. Linking is handled the same way as the slave SG case
 except for the last slot where we link it back to the first one in a
 cyclic fashion.
 
 For continuity, we check for cases where no.of periods is great than the
 MAX number of slots the driver can allocate for a particular descriptor
 and error out on such cases.
Applied, thanks

~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dma: edma: Add support for Cyclic DMA

[Vinod Koul]

On Thu, Oct 24, 2013 at 12:57:02PM -0500, Joel Fernandes wrote:
 Rebased on slave-dma/next branch and reapplied:
Looks like your MUA caused lines to get wrapped and patch is corrupt, can you
pls resend again using git-send email. I tried even the patch from
patchworks but that too failed!
 
 8---
 From: Joel Fernandes jo...@ti.com
 Subject: [PATCH v2] dma: edma: Add support for Cyclic DMA
 
 Using the PaRAM configuration function that we split for reuse by the
 different DMA types, we implement Cyclic DMA support.
 For the cyclic case, we pass different configuration parameters to this
 function, and handle all the Cyclic-specific functionality separately.
 
 Callbacks to the DMA users are handled using vchan_cyclic_callback in
 the virt-dma layer. Linking is handled the same way as the slave SG case
 except for the last slot where we link it back to the first one in a
 cyclic fashion.
 
 For continuity, we check for cases where no.of periods is great than the
 MAX number of slots the driver can allocate for a particular descriptor
 and error out on such cases.
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  drivers/dma/edma.c | 159 
 ++---
  1 file changed, 151 insertions(+), 8 deletions(-)
 

   struct edma_chan *echan = data;
 @@ -464,24 +602,28 @@ static void edma_callback(unsigned ch_num, u16 
 ch_status,
 void *data)
This seems bad
   unsigned long flags;
   struct edmacc_param p;
 
 - /* Pause the channel */
 - edma_pause(echan-ch_num);
 + edesc = echan-edesc;
 +
 + /* Pause the channel for non-cyclic */
 + if (!edesc || (edesc  !edesc-cyclic))
 + edma_pause(echan-ch_num);
 
   switch (ch_status) {
   case DMA_COMPLETE:
   spin_lock_irqsave(echan-vchan.lock, flags);
 
 - edesc = echan-edesc;
   if (edesc) {
 - if (edesc-processed == edesc-pset_nr) {
 + if (edesc-cyclic) {
 + vchan_cyclic_callback(edesc-vdesc);
 + } else if (edesc-processed == edesc-pset_nr) {
   dev_dbg(dev, Transfer complete, stopping 
 channel %d\n, ch_num);
   edma_stop(echan-ch_num);
   vchan_cookie_complete(edesc-vdesc);
 + edma_execute(echan);
   } else {
   dev_dbg(dev, Intermediate transfer complete on 
 channel %d\n, ch_num);
 + edma_execute(echan);
   }
 -
 - edma_execute(echan);
   }
 
   spin_unlock_irqrestore(echan-vchan.lock, flags);
 @@ -677,6 +819,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
 dma_device *dma,
ditto and few other which checkpatch was not happy about!
 struct device *dev)
  {
   dma-device_prep_slave_sg = edma_prep_slave_sg;
 + dma-device_prep_dma_cyclic = edma_prep_dma_cyclic;
   dma-device_alloc_chan_resources = edma_alloc_chan_resources;
   dma-device_free_chan_resources = edma_free_chan_resources;
   dma-device_issue_pending = edma_issue_pending;
 -- 
 1.8.1.2
 

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dma: edma: Add support for Cyclic DMA

[Vinod Koul]

On Tue, Oct 22, 2013 at 10:30:43AM -0500, Joel Fernandes wrote:
 On 10/21/2013 01:53 AM, Vinod Koul wrote:
  On Mon, Sep 23, 2013 at 06:05:14PM -0500, Joel Fernandes wrote:
  +  nr_periods = (buf_len / period_len) + 1;
  ?
  
  consider the case of buf = period_len, above makes nr_period = 2.
  
  Or buf len 100, period len 50, makes nr_period = 3
  
  Both doesnt seem right to me?
 
 I guess that variable name is misleading.
 
 nr_periods is actually the total no.of slots needed to process the request. 
 Its
 value is 1 greater than the total number of periods.
Okay sounds good to me. I tried applying below but looks like it fails as I have
already applied, 1  3. Can you pls rebase this resend

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dma: edma: Add support for Cyclic DMA

[Vinod Koul]

On Mon, Sep 23, 2013 at 06:05:14PM -0500, Joel Fernandes wrote:
 
 @@ -449,6 +455,138 @@ static struct dma_async_tx_descriptor 
 *edma_prep_slave_sg(
   return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags);
  }
  
 +static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
 + struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
 + size_t period_len, enum dma_transfer_direction direction,
 + unsigned long tx_flags, void *context)
 +{
 + struct edma_chan *echan = to_edma_chan(chan);
 + struct device *dev = chan-device-dev;
 + struct edma_desc *edesc;
 + dma_addr_t src_addr, dst_addr;
 + enum dma_slave_buswidth dev_width;
 + u32 burst;
 + int i, ret, nr_periods;
 +
 + if (unlikely(!echan || !buf_len || !period_len))
 + return NULL;
 +
 + if (direction == DMA_DEV_TO_MEM) {
 + src_addr = echan-cfg.src_addr;
 + dst_addr = buf_addr;
 + dev_width = echan-cfg.src_addr_width;
 + burst = echan-cfg.src_maxburst;
 + } else if (direction == DMA_MEM_TO_DEV) {
 + src_addr = buf_addr;
 + dst_addr = echan-cfg.dst_addr;
 + dev_width = echan-cfg.dst_addr_width;
 + burst = echan-cfg.dst_maxburst;
 + } else {
 + dev_err(dev, %s: bad direction?\n, __func__);
 + return NULL;
 + }
 +
 + if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
 + dev_err(dev, Undefined slave buswidth\n);
 + return NULL;
 + }
 +
 + if (unlikely(buf_len % period_len)) {
 + dev_err(dev, Period should be multiple of Buffer length\n);
 + return NULL;
 + }
 +
 + nr_periods = (buf_len / period_len) + 1;
?

consider the case of buf = period_len, above makes nr_period = 2.

Or buf len 100, period len 50, makes nr_period = 3

Both doesnt seem right to me?

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dma: edma: Split out PaRAM set calculations into its own function

[Vinod Koul]

On Mon, Sep 23, 2013 at 06:05:13PM -0500, Joel Fernandes wrote:
 PaRAM set calculation is abstracted into its own function to
 enable better reuse for other DMA cases such as cyclic. We adapt
 the Slave SG case to use the new function.
 
 This provides a much cleaner abstraction to the internals of the
 PaRAM set. However, any PaRAM attributes that are not common to
 all DMA types must be set separately such as setting of interrupts.
 This function takes care of the most-common attributes.
 
 Also added comments clarifying A-sync case calculations.
Applied, thanks

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] dma: edma: Increase maximum SG limit to 20

[Vinod Koul]

On Mon, Sep 23, 2013 at 06:05:15PM -0500, Joel Fernandes wrote:
 davinci-pcm uses 16 as the no.of periods. With this, in EDMA we have to
 allocate atleast 17 slots: 1 slot for channel, and 16 slots the periods.
 
 Due to this, the MAX_NR_SG limitation causes problems, set it to 20 to make
 cyclic DMA work when davinci-pcm is converted to use DMA Engine. Also add
 a comment clarifying this.

Applied, thanks

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Mon, Sep 23, 2013 at 07:53:11AM +0200, Daniel Mack wrote:
 On 23.09.2013 06:09, Vinod Koul wrote:
  On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 
  +#ifdef CONFIG_PM_SLEEP
  a
  
  +static int cppi41_suspend(struct device *dev)
  +{
  +  struct cppi41_dd *cdd = dev_get_drvdata(dev);
  +
  +  cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
  +  disable_sched(cdd);
  +
  +  return 0;
  +}
  +
  +static int cppi41_resume(struct device *dev)
  +{
  +  struct cppi41_dd *cdd = dev_get_drvdata(dev);
  +  int i;
  +
  +  for (i = 0; i  DESCS_AREAS; i++)
  +  cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
  +
  +  init_sched(cdd);
  +  cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
  +
  +  return 0;
  +}
  +#endif
  +
  +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
  Here is the macro in pm.h
 
 [...]
 
  Now since you are using the macro there should be no need to wrap ifdef 
  around
  your code, the macro will take care of it.
 
 Well yes, which is why I put the macro itself *outside* of the #ifdef
 block. Without that #ifdef, however, and with CONFIG_PM_SLEEP unset, I get:
 
 drivers/dma/cppi41.c:1043:12: warning: ‘cppi41_suspend’ defined but not
 used [-Wunused-function]
  static int cppi41_suspend(struct device *dev)
 ^
 drivers/dma/cppi41.c:1053:12: warning: ‘cppi41_resume’ defined but not
 used [-Wunused-function]
  static int cppi41_resume(struct device *dev)
 ^
 
 ... which doesn't surprise me much. Or do I still not get your point?
And this is what i had expected... I was thinking we should ignore this, but
this is better too, so I will try to apply this now

~Vinod

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 This patch adds support for suspend/resume functionality to the cppi41
 DMA driver. The steps necessary to make the system resume properly were
 figured out by trial-and-error. The code as it stands now is the
 minimum that has to be done to put the musb host system on an AM33xx
 system into an operable state after resume.
Applied, thanks

~Vinod
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/dma/cppi41.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 3347321..89decc9 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -1040,12 +1040,41 @@ static int cppi41_dma_remove(struct platform_device 
 *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_PM_SLEEP
 +static int cppi41_suspend(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 +
 + cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
 + disable_sched(cdd);
 +
 + return 0;
 +}
 +
 +static int cppi41_resume(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 + int i;
 +
 + for (i = 0; i  DESCS_AREAS; i++)
 + cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
 +
 + init_sched(cdd);
 + cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
 +
 + return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
 +
  static struct platform_driver cpp41_dma_driver = {
   .probe  = cppi41_dma_probe,
   .remove = cppi41_dma_remove,
   .driver = {
   .name = cppi41-dma-engine,
   .owner = THIS_MODULE,
 + .pm = cppi41_pm_ops,
   .of_match_table = of_match_ptr(cppi41_dma_ids),
   },
  };
 -- 
 1.8.3.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call

[Vinod Koul]

On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
 The DMA API requires drivers to call the appropriate dma_set_mask()
 functions before doing any DMA mapping.  Add this required call to
 the AMBA PL08x driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod
 ---
  drivers/dma/amba-pl08x.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
 index fce46c5..e51a983 100644
 --- a/drivers/dma/amba-pl08x.c
 +++ b/drivers/dma/amba-pl08x.c
 @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const 
 struct amba_id *id)
   if (ret)
   return ret;
  
 + /* Ensure that we can do DMA */
 + ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
 + if (ret)
 + goto out_no_pl08x;
 +
   /* Create the driver state holder */
   pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
   if (!pl08x) {
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

[Vinod Koul]

On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
 register_platform_device_full() can setup the DMA mask provided the
 appropriate member is set in struct platform_device_info.  So lets
 make that be the case.  This avoids a direct reference to the DMA
 masks by this driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?

~Vinod

 ---
  drivers/dma/edma.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index ff50ff4..7f9fe30 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
  static const struct platform_device_info edma_dev_info0 = {
   .name = edma-dma-engine,
   .id = 0,
 + .dma_mask = DMA_BIT_MASK(32),
  };
  
  static const struct platform_device_info edma_dev_info1 = {
   .name = edma-dma-engine,
   .id = 1,
 + .dma_mask = DMA_BIT_MASK(32),
  };


  
  static int edma_init(void)
 @@ -720,8 +722,6 @@ static int edma_init(void)
   ret = PTR_ERR(pdev0);
   goto out;
   }
 - pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
 - pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
   if (EDMA_CTLRS == 2) {
 @@ -731,8 +731,6 @@ static int edma_init(void)
   platform_device_unregister(pdev0);
   ret = PTR_ERR(pdev1);
   }
 - pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
 - pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
  out:
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

[Vinod Koul]

On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
 On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
  Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
   The DMA API requires drivers to call the appropriate dma_set_mask()
   functions before doing any DMA mapping.  Add this required call to
   the AMBA PL08x driver.
  ^--- copy and paste error - should of course be PL330
 
 Fixed, thanks.
with fixed changelog...

Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once

[Vinod Koul]

On Mon, Sep 23, 2013 at 04:51:06PM +0200, Sebastian Andrzej Siewior wrote:
 On 09/23/2013 06:17 AM, Vinod Koul wrote:
  Looks fine, Sebastian cna you test it pls
 
 Just noticed that you already applied some of them. I just got back
 after a few weeks of. Will review  test as soon as I get to it.
Yes, the first three were trvial, 5th one looked fine to me !

~Vinod
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 This patch adds support for suspend/resume functionality to the cppi41
 DMA driver. The steps necessary to make the system resume properly were
 figured out by trial-and-error. The code as it stands now is the
 minimum that has to be done to put the musb host system on an AM33xx
 system into an operable state after resume.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/dma/cppi41.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 3347321..89decc9 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -1040,12 +1040,41 @@ static int cppi41_dma_remove(struct platform_device 
 *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_PM_SLEEP
a

 +static int cppi41_suspend(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 +
 + cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
 + disable_sched(cdd);
 +
 + return 0;
 +}
 +
 +static int cppi41_resume(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 + int i;
 +
 + for (i = 0; i  DESCS_AREAS; i++)
 + cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
 +
 + init_sched(cdd);
 + cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
 +
 + return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
Here is the macro in pm.h

#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif

/*
 * Use this if you want to use the same suspend and resume callbacks for suspend
 * to RAM and hibernation.
 */
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \

Now since you are using the macro there should be no need to wrap ifdef around
your code, the macro will take care of it. 

~Vinod

 +
  static struct platform_driver cpp41_dma_driver = {
   .probe  = cppi41_dma_probe,
   .remove = cppi41_dma_remove,
   .driver = {
   .name = cppi41-dma-engine,
   .owner = THIS_MODULE,
 + .pm = cppi41_pm_ops,
   .of_match_table = of_match_ptr(cppi41_dma_ids),
   },
  };
 -- 
 1.8.3.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] dma: cppi41: s/deinit_cpii41/deinit_cppi41/

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:01PM +0200, Daniel Mack wrote:
 Fix a misspelled function name.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
Applied, thanks

~Vinod
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] dma: cppi41: pass around device instead of platform_device

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:00PM +0200, Daniel Mack wrote:
 Instead of passing around struct plafform_device, use struct device and
 save one level of dereferencing. This affects the following functions:
 
  * cppi41_add_chans
  * purge_descs
  * deinit_cpii41
  * init_descs
  * init_cppi41
  * cppi_glue_infos
 
 It's just a cosmetic cleanup that makes the code more readable.
Applied, thanks

~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] dma: cppi41: add shortcut to pdev-dev in cppi41_dma_probe()

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:02PM +0200, Daniel Mack wrote:
 Makes the code more readable and compact. No functional change.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
Applied, thanks

~Vinod
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:03PM +0200, Daniel Mack wrote:
 cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
 init_descs() and freed as often from purge_descs(). This leads to both
 memory leaks and double-frees.
 
 Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
 loops.
 
 While at it, remove the intermediate variable mem_decs (I guess it was
 only there to make the code comply to the 80-chars CodingSytle rule).

Looks fine, Sebastian cna you test it pls

~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html