linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: "spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org"
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] spi: tegra: slink: do not prepare dma transfer with DMA_CTRL_ACK flag
Date: Tue, 27 Nov 2012 04:30:30 +0530	[thread overview]
Message-ID: <50B3F48E.4040705@nvidia.com> (raw)
In-Reply-To: <50B3E72B.6020003-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>

On Tuesday 27 November 2012 03:33 AM, Stephen Warren wrote:
> On 11/23/2012 02:22 AM, Laxman Dewangan wrote:
>> Spi starts transfer using dma with DMA_CTRL_ACK which is not require
>> becasue spi driver does not use completed dma_desc after transfer
>> done and so it does not ack the dma descriptor. Removing the
>> DMA_CTRL_ACK flag to avoid memory leak in dma driver.
> I'm not quite sure, but isn't this the opposite of what's wanted. I
> think that setting this flag in prep() means that the SPI driver need
> not explicitly ack it later?
>
> At least, tegra_dma_desc_get() returns an allocated descriptor if one
> exists and async_tx_test_ack()==true for it, and it's true when the
> DMA_CTRL_ACK flag is set, which happens either due to calling
> async_tx_ack(), or because tegra_dma_prep_slave_sg() was called with
> DMA_CTRL_ACK in flags.

I think DMA_CTRL_ACK flag is require if we want to free/reuse desc only 
when client ack it.

Although some part of implementation is wrong in the tegra20-apb-dma.c.

static struct tegra_dma_desc *tegra_dma_desc_get(
                 struct tegra_dma_channel *tdc)
{
         struct tegra_dma_desc *dma_desc;
         unsigned long flags;

         spin_lock_irqsave(&tdc->lock, flags);

         /* Do not allocate if desc are waiting for ack */
         list_for_each_entry(dma_desc, &tdc->free_dma_desc, node) {
                 if (async_tx_test_ack(&dma_desc->txd)) {
                         list_del(&dma_desc->node);
:::::::::::::::

}

In above it should be if (!async_tx_test_ack())

And when client done with the desc, then it can say as async_tx_clear_ack().


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

  parent reply	other threads:[~2012-11-26 23:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-23  9:22 [PATCH] spi: tegra: slink: do not prepare dma transfer with DMA_CTRL_ACK flag Laxman Dewangan
     [not found] ` <1353662559-26515-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-11-26 22:03   ` Stephen Warren
     [not found]     ` <50B3E72B.6020003-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-26 23:00       ` Laxman Dewangan [this message]
2013-04-01 13:35   ` Mark Brown
     [not found]     ` <20130401133459.GS18636-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-04-03  9:31       ` Laxman Dewangan
     [not found]         ` <515BF6ED.2060904-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-04-03 17:36           ` Mark Brown
2013-04-03  9:31       ` Laxman Dewangan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B3F48E.4040705@nvidia.com \
    --to=ldewangan-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).