dmaengine Archive on lore.kernel.org
 help / color / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: <vkoul@kernel.org>
Cc: <dan.j.williams@intel.com>, <dmaengine@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <grygorii.strashko@ti.com>,
	<t-kristo@ti.com>, <tony@atomide.com>, <vigneshr@ti.com>
Subject: [PATCH 0/3] dmaengine: ti: k3-udma: Fixes against v6 series
Date: Mon, 2 Dec 2019 22:31:25 +0200
Message-ID: <20191202203128.14348-1-peter.ujfalusi@ti.com> (raw)
In-Reply-To: <0191128105945.13071-1-peter.ujfalusi@ti.com>

Hi Vinod,

When I thought that all corner cases are handled I got report of a failure on a
miss-configured setup:
UART without lines connected
Enable HW flow control (nothing is connected)
Do a small tx like "dd if=/dev/urandom of=/dev/ttyS1 bs=128 count=1"

The result is an interrupt flood caused by constant TDCM reception.

The explanation comes from the DMA split design and explained in patch 3:

"If the peripheral is disabled (or it is not able to send out data) the
UDMAP will complete a 'short' transfer. In other words: if the amount of
data can fit into PSI-L and PDMA (and peripheral FIFO) then UDMAP will
send out the data and return as the transfer is completed, however the
peripheral did not actually received all the data.

It was wrong to issue a normal teardown on the channel for several reasons:
UDMAP is not processing any packet so it will just return the TDCM and if
the peripheral is not consuming data from PDMA then we will have constant
flood of TDCMs (interrupts).
After the teardown the channel will be in reset state and we would need to
reset the rings as well, but it can not be done in interrupt context.
If the peripheral is just slow to consume data or even there is a delay
between starting the DMA then we will have again issues detecting the
state.

We could set force teardown, but that will make PDMA to discard the data
which is not correct in case of slow or delayed transfer start on the
peripheral.

The only solution is to use a work and check the progress in there after
the descriptor is returned and the UDMA and PDMA counters are not showing
the same number of bytes processed."

I'll squash these to v7, but I thought that this change is better to be visible
alone as it is kind of a big one on handling the early TX completion.

Regards,
Peter
---
Peter Ujfalusi (3):
  dmaengine: ti: k3-udma: Correct completed descriptor's residue value
  dmaengine: ti: k3-udma: Workaround for stale transfers
  dmaengine: ti: k3-udma: Fix early TX completion against PDMAs

 drivers/dma/ti/k3-udma.c | 89 +++++++++++++++++++++++++++++-----------
 1 file changed, 66 insertions(+), 23 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


       reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0191128105945.13071-1-peter.ujfalusi@ti.com>
2019-12-02 20:31 ` Peter Ujfalusi [this message]
2019-12-02 20:31   ` [PATCH 1/3] dmaengine: ti: k3-udma: Correct completed descriptor's residue value Peter Ujfalusi
2019-12-02 20:31   ` [PATCH 2/3] dmaengine: ti: k3-udma: Workaround for stale transfers Peter Ujfalusi
2019-12-02 20:31   ` [PATCH 3/3] dmaengine: ti: k3-udma: Fix early TX completion against PDMAs Peter Ujfalusi

Reply instructions:

You may reply publically 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=20191202203128.14348-1-peter.ujfalusi@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.com \
    --cc=vkoul@kernel.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

dmaengine Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dmaengine/0 dmaengine/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dmaengine dmaengine/ https://lore.kernel.org/dmaengine \
		dmaengine@vger.kernel.org
	public-inbox-index dmaengine

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dmaengine


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git