linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@nvidia.com>
To: Laxman Dewangan <ldewangan@nvidia.com>,
	"ccross@android.com" <ccross@android.com>,
	"olof@lixom.net" <olof@lixom.net>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V1] ARM: tegra: dma: Support variable transfer sizes
Date: Wed, 25 Jan 2012 09:03:16 -0800	[thread overview]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF178CB8202B@HQMAIL01.nvidia.com> (raw)
In-Reply-To: <1327490378-10904-1-git-send-email-ldewangan@nvidia.com>

Laxman Dewangan wrote at Wednesday, January 25, 2012 4:20 AM:
> Allow the transfer size to vary in each DMA request,
> rather than assuming all requests to be the same size
> as the first request made.
...
> diff --git a/arch/arm/mach-tegra/dma.c b/arch/arm/mach-tegra/dma.c
...
> @@ -434,6 +435,15 @@ static void tegra_dma_update_hw_partial(struct tegra_dma_channel *ch,
>  	writel(apb_ptr, ch->addr + APB_DMA_CHAN_APB_PTR);
>  	writel(ahb_ptr, ch->addr + APB_DMA_CHAN_AHB_PTR);
> 
> +	if (ch->mode & TEGRA_DMA_MODE_CONTINOUS)
> +		ch->req_transfer_count = (req->size >> 3) - 1;
> +	else
> +		ch->req_transfer_count = (req->size >> 2) - 1;

There are cases in the current continuous mode where HW is working on
one buffer and the next buffer is queued in HW. Once we've written the
new request to HW, we don't know exactly which buffer HW is operating
on. Hence, we don't know which buffer ch->req_transfer_count refers to.
If req->size changes, might this change cause the new req->size value
to be used when the old buffer's final completion interrupt goes off
and hence the old buffer's req->bytes_transferred be wrong?

Actually looking at the current continuous mode, I'm not convinced that
it correctly handles replacing an in-progress buffer with a new buffer;
I certainly see where handle_continuous_dma() checks for a second (SW)
queued buffer and tells the HW to use that buffer instead, but I don't
see where the (SW) queue management is done; where is the old req removed
from the head of ch->list and marked complete? I assume the "out of sync"
case is only intended to be an error condition and not part of the
buffer switch?

Perhaps for the current continuous mode, it'd be best to require the
client to dequeue any existing request before queuing another, i.e. to
fail tegra_dma_enqueue_req() if there's already something in ch->list
in continuous mode?

> +	csr = readl(ch->addr + APB_DMA_CHAN_CSR);
> +	csr &= ~CSR_WCOUNT_MASK;
> +	csr |= ch->req_transfer_count << CSR_WCOUNT_SHIFT;
> +	writel(csr, ch->addr + APB_DMA_CHAN_CSR);
> +
>  	req->status = TEGRA_DMA_REQ_INFLIGHT;
>  	return;
>  }

-- 
nvpublic


  reply	other threads:[~2012-01-25 17:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-25 11:19 [PATCH V1] ARM: tegra: dma: Support variable transfer sizes Laxman Dewangan
2012-01-25 17:03 ` Stephen Warren [this message]
2012-01-26  1:45   ` Laxman Dewangan
2012-01-26 16:53     ` Stephen Warren
2012-01-27 10:06       ` 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=74CDBE0F657A3D45AFBB94109FB122FF178CB8202B@HQMAIL01.nvidia.com \
    --to=swarren@nvidia.com \
    --cc=ccross@android.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    /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).