linux-kernel - Re: [PATCH] dmaengine: Add API documentation for slave dma usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 May 2011 11:47:45 +0200
From:	Per Forlin <per.forlin@...aro.org>
To:	"Koul, Vinod" <vinod.koul@...el.com>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dmaengine: Add API documentation for slave dma usage

On 25 May 2011 10:26, Koul, Vinod <vinod.koul@...el.com> wrote:
> On Wed, 2011-05-25 at 09:47 +0200, Per Forlin wrote:
>> On 24 May 2011 23:03, Dan Williams <dan.j.williams@...el.com> wrote:
>
>> >>> Does submit really start the transfer as well? My interpretation of
>> >>> submit is that is only adds desc to a pending queue. When calling
>> >>> issue_pending all these descs will be schedule for DMA transfer. Calls
>> >>> to submit after this point will added to the pending queue again and
>> >>> not be issued until calling issue_pending once more.
>> >> For slave dma devices, submit() is used to start the transaction if the
>> >> channel is idle. If its already doing a transaction then it will queue
>> >> it up and submit once cureent excuting one is completed. It is not
>> >> required to call issue_pending once more.
>> >> I am not sure if this is true for non slave usage, Dan would that be
>> >> correct for you as well?
>> >
>> > No, ->submit() is just an "add this descriptor to the chain"
>> > operation, and ->issue_pending() is always required to make sure the
>> > everything submitted previously is actively executing.  This was a
>> > holdover from the very first dmaengine implementation where, for
>> > efficiency reasons, it could save mmio writes by batching the issuing
>> > of requests.
>> Thanks Dan for clarifying.
>> Vinod, I propose that the submit and issue_pending works the same for
>> SLAVE and none SLAVE channels. The API should have the same definition
>> independent of DMA_CAP. Please enlighten me if there are things I have
>> foreseen on this matter.
> I am okay with making this same for the slave devices as well.
>
> That would also require to change few drivers which start the txn in
> submit()
Yes,
The trivial part is to move enable from submit to issue_pending. I had
a quick look and it looks like the following drivers need to be
changed.
mpc512x_dma.c
imx-dma.c
imx-sdma.c
mxs-dma.c

The other part is more complex. To make submit only add descs to a
queue that will be pushed down to the DMA only after issue_pending. It
is not as trivial to identify which of the drivers support this or
not.
I still think it make sense to fix the documentation first and then
fix the drivers. Keep a list inside the dmaengine.txt of drivers that
need to be fixed in order to comply with the API. Over time drivers
will be fixed and removed from the list. When we have agreed upon the
API (we may not be there yet) I am willingly to make a draft of such a
list.

/Per
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/