public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vinod <vkoul@kernel.org>
To: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	devicetree@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/7] dmaengine: stm32-dma: Add DMA/MDMA chaining support
Date: Wed, 10 Oct 2018 09:33:43 +0530	[thread overview]
Message-ID: <20181010040343.GO2372@vkoul-mobl> (raw)
In-Reply-To: <e9cedfdd-ad90-9123-03bb-34a2e84059c5@st.com>

On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
> 
> 
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between peripherals and STM32 DMA.
> >> This intermediate transfer is triggered by SW for single M2D transfer and
> >> by STM32 DMA IP for all other modes (sg, cyclic) and direction (D2M).
> >>
> >> A generic SRAM allocator is used for this intermediate buffer
> >> Each DMA channel will be able to define its SRAM needs to achieve chaining
> >> feature : (2 ^ order) * PAGE_SIZE.
> >> For cyclic, SRAM buffer is derived from period length (rounded on
> >> PAGE_SIZE).
> > 
> > So IIUC, you chain two dma txns together and transfer data via an SRAM?
> 
> Correct. one DMA is DMAv2 (stm32-dma) and the other is MDMA(stm32-mdma).
> Intermediate transfer is between device and memory.
> This intermediate transfer is using SDRAM.

Ah so you use dma calls to setup mdma xtfers? I dont think that is a
good idea. How do you know you should use mdma for subsequent transfer?


> >>  drivers/dma/stm32-dma.c | 879 ++++++++++++++++++++++++++++++++++++++++++------
> > 
> > that is a lot of change for a driver, consider splitting it up
> > logically in smaller changes...
> > 
> 
> This feature is rather monolithic. Difficult to split up.
> All the code is required at once.

It can be enabled at last but split up logically. Intrusive changes to a
driver make it hard to review..

-- 
~Vinod

  reply	other threads:[~2018-10-10  4:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 13:01 [PATCH v3 0/7] Add-DMA-MDMA-chaining-support Pierre-Yves MORDRET
2018-09-28 13:01 ` [PATCH v3 1/7] dt-bindings: stm32-dma: Add DMA/MDMA chaining support bindings Pierre-Yves MORDRET
2018-10-07 14:57   ` Vinod
2018-10-09  7:18     ` Pierre Yves MORDRET
2018-10-09  8:57       ` Vinod
2018-10-09 13:46         ` Pierre Yves MORDRET
2018-10-12 14:42   ` Rob Herring
2018-09-28 13:01 ` [PATCH v3 2/7] dt-bindings: stm32-dmamux: Add one cell to support DMA/MDMA chain Pierre-Yves MORDRET
2018-10-07 14:58   ` Vinod
2018-10-09  7:22     ` Pierre Yves MORDRET
2018-10-12 14:46   ` Rob Herring
2018-09-28 13:01 ` [PATCH v3 3/7] dt-bindings: stm32-mdma: Add DMA/MDMA chaining support bindings Pierre-Yves MORDRET
2018-10-07 14:59   ` Vinod
2018-10-09  8:17     ` Pierre Yves MORDRET
2018-09-28 13:01 ` [PATCH v3 4/7] dmaengine: stm32-dma: Add DMA/MDMA chaining support Pierre-Yves MORDRET
2018-10-07 16:00   ` Vinod
2018-10-09  8:40     ` Pierre Yves MORDRET
2018-10-10  4:03       ` Vinod [this message]
2018-10-10  7:02         ` Pierre Yves MORDRET
2018-10-15 17:14           ` Vinod
2018-10-16  9:19             ` Pierre Yves MORDRET
2018-10-16 14:44               ` Vinod
2018-10-19  9:21                 ` Pierre Yves MORDRET
2018-09-28 13:01 ` [PATCH v3 5/7] dmaengine: stm32-mdma: " Pierre-Yves MORDRET
2018-09-28 13:01 ` [PATCH v3 6/7] dmaengine: stm32-dma: enable descriptor_reuse Pierre-Yves MORDRET
2018-09-28 13:01 ` [PATCH v3 7/7] dmaengine: stm32-mdma: " Pierre-Yves MORDRET

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=20181010040343.GO2372@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=pierre-yves.mordret@st.com \
    --cc=robh+dt@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