linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Amelie Delaunay <amelie.delaunay@foss.st.com>
To: Vinod Koul <vkoul@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: <dmaengine@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	Amelie Delaunay <amelie.delaunay@foss.st.com>
Subject: [PATCH v3 1/9] dt-bindings: dma: stm32-dma3: prevent packing/unpacking mode
Date: Wed, 16 Oct 2024 14:39:53 +0200	[thread overview]
Message-ID: <20241016-dma3-mp25-updates-v3-1-8311fe6f228d@foss.st.com> (raw)
In-Reply-To: <20241016-dma3-mp25-updates-v3-0-8311fe6f228d@foss.st.com>

When source data width/burst and destination data width/burst are
different, data are packed or unpacked in DMA3 channel FIFO.
Data are pushed out from DMA3 channel FIFO when the destination burst
length (= data width * burst) is reached.
If the channel is stopped before the transfer end, and if some bytes are
packed/unpacked in the DMA3 channel FIFO, these bytes are lost.
Indeed, DMA3 channel FIFO has no flush capability, only reset.
To avoid potential bytes lost, pack/unpack must be prevented by setting
memory data width/burst equal to peripheral data width/burst.
Memory accesses will be penalized. But it is the only way to avoid bytes
lost.

Some devices (e.g. cyclic RX like UART) need this, so add the possibility
to prevent pack/unpack feature, by setting bit 16 of the 'DMA transfer
requirements' bit mask.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
---
 Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
index 7fdc44b2e6467928622a5bb25d9e0c74bb1790ae..5484848735f8ac3d2050104bbab1d986e82ba6a7 100644
--- a/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
+++ b/Documentation/devicetree/bindings/dma/stm32/st,stm32-dma3.yaml
@@ -96,6 +96,9 @@ properties:
                including the update of the LLI if any
           0x3: at channel level, the transfer complete event is generated at the
                end of the last LLI
+        -bit 16: Prevent packing/unpacking mode
+          0x0: pack/unpack enabled when source data width/burst != destination data width/burst
+          0x1: memory data width/burst forced to peripheral data width/burst to prevent pack/unpack
 
 required:
   - compatible

-- 
2.25.1



  reply	other threads:[~2024-10-16 12:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-16 12:39 [PATCH v3 0/9] STM32 DMA3 updates for STM32MP25 Amelie Delaunay
2024-10-16 12:39 ` Amelie Delaunay [this message]
2024-10-16 12:39 ` [PATCH v3 2/9] dmaengine: stm32-dma3: prevent pack/unpack thanks to DT configuration Amelie Delaunay
2024-10-16 12:39 ` [PATCH v3 3/9] dmaengine: stm32-dma3: refactor HW linked-list to optimize memory accesses Amelie Delaunay
2024-10-16 12:39 ` [PATCH v3 4/9] dt-bindings: dma: stm32-dma3: prevent additional transfers Amelie Delaunay
2024-10-16 17:33   ` Rob Herring (Arm)
2024-10-16 12:39 ` [PATCH v3 5/9] dmaengine: stm32-dma3: prevent LL refactoring thanks to DT configuration Amelie Delaunay
2024-10-16 12:39 ` [PATCH v3 6/9] dmaengine: stm32-dma3: clamp AXI burst using match data Amelie Delaunay
2024-10-16 12:39 ` [PATCH v3 7/9] arm64: dts: st: add DMA support on U(S)ART instances of stm32mp25 Amelie Delaunay
2024-10-16 12:40 ` [PATCH v3 8/9] arm64: dts: st: add DMA support on I2C " Amelie Delaunay
2024-10-16 12:40 ` [PATCH v3 9/9] arm64: dts: st: add DMA support on SPI " Amelie Delaunay
2024-10-22  5:32 ` (subset) [PATCH v3 0/9] STM32 DMA3 updates for STM32MP25 Vinod Koul
2024-10-29 16:09 ` Alexandre TORGUE

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=20241016-dma3-mp25-updates-v3-1-8311fe6f228d@foss.st.com \
    --to=amelie.delaunay@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh@kernel.org \
    --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
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).