From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758508AbbJHUlE (ORCPT <rfc822;w@1wt.eu>);
	Thu, 8 Oct 2015 16:41:04 -0400
Received: from mout.kundenserver.de ([212.227.17.10]:63680 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758483AbbJHUlA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 8 Oct 2015 16:41:00 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: "M'boumba Cedric Madianga" <cedric.madianga@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>, robh+dt@kernel.org,
        pawel.moll@arm.com, mark.rutland@arm.com,
        ijc+devicetree@hellion.org.uk, Kumar Gala <galak@codeaurora.org>,
        linux@arm.linux.org.uk, vinod.koul@intel.com,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        dmaengine@vger.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings
Date: Thu, 08 Oct 2015 22:40:19 +0200
Message-ID: <11583587.xphxbMQ7TN@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <CAOAejn0x68GaEEfTZbsi5VSJt+Um-bV2Mcmc2pxUwh5QjD=ZYw@mail.gmail.com>
References: <1444317612-818-1-git-send-email-cedric.madianga@gmail.com> <15651913.U8kb3JZ9vO@wuerfel> <CAOAejn0x68GaEEfTZbsi5VSJt+Um-bV2Mcmc2pxUwh5QjD=ZYw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:pe8eGWOpFix6iTd34Od2hCyqFcOOwCbXi6UEG7CH28kfznR0mOT
 paHEiNjSAhCoQGbCHsU76ry4kon2DZMO7LuTtDE9xJTTUK0/Jn0DgsX7KQYgAGTkTfMqR8z
 2u/Gypd3g70rC8LSRUnWfU4I0vlcybIZ87sLS52LzhGYGAG9VXLqthYBXe9UURndEH2Zb9e
 DUcOEgtoE9nuliaSp7L0A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:p6O/7g/FB4c=:kF8hxokVUyRZaeRIhUpt8K
 bntiL0e0y94kcirm8C/OWQd92Jb94/+6c+c2s0f+X4DwRui41xnmDU1v/aeZR5mHm+BgDGnuB
 p/G6vLvj9ULGrsHaVBeSwV0uJe8wNIPUUhzAkVPDED80ngu3HRJtzZAYEXZC6BAXcj7u1gdSW
 +fP5yl8ECIRIk5tzKE8n/uyf/grvYIxAGp7GU1behkkP6n4XKjC7KewR46o0hhwl1dm95Finl
 UEIkNMWnOPHx/Zlhjds/fguVEOqs7eh81U1w2dN6sQ9chbnLF3H+16vS3tiUx03t/0WdJQPQF
 ORXaJQ2RDWCNGnq6027n7X9Gb+lnrcgRPfo1r8yO4xFIQneXHWJetYF7qziyFVNZj/DS4gnIc
 quRSsGewUtUbnJR8gbB/iQIAqakJ3cT4L2K3xXQ2HWkLyQJL5FnM4qA9WFDQBjO+xB/Z3MyUM
 sVyG+ESBGmkYK/0VRPRWkb4T9nkUBjqjRpr/Aysly6rGUQkLS4pC1h8K9t9OFNlX7PP2RS4cH
 LfbnN4sWkxAOoEt2mlMUZ3ZKvRV8gS1m2gcnpelczB/IpiG4Ykun90viXBaW6X3dQilUT2+jv
 sbOF9zTYhzDOrhTWdxndYFXcSysIImRw00SLm02jtDMlcwxpDosPbG/R120rVSarqOjceUye8
 xDuT6Z4Pg8VrykGCXxy2Y9ov7ghtG+G180pJSMxzxIrU8y+krc9Dbmi9V61uRiZnD6CRoqGzj
 Gs9Vf+OsGOto89jW
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday 08 October 2015 22:25:50 M'boumba Cedric Madianga wrote:
> >
> > How do you know which channels are available for memory-to-memory
> > transfers?
> For memory-to-memory transfer we don't need any channel/request combination.
> We look for any available channel in the channel list to execute our transfer.
> So, as often as possible, we expect that a peripheral release his
> channel after transfering data.
> In that way, we always should have at least one channel available for
> that kind of transfer.
> 

Ah, got it. So the use of virtual channels in this driver makes MEM2MEM
transfers work, but is otherwise not required.

Thanks for the clarification.

	Arnd