linux-kernel - Re: [PATCH v2 1/5] Documentation: dmaengine: pxa-dma design

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]

Message-ID: <20150512101201.GB5418@localhost>
Date:	Tue, 12 May 2015 15:42:01 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
Cc:	Jonathan Corbet <corbet@....net>, Daniel Mack <daniel@...que.org>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	dmaengine@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v2 1/5] Documentation: dmaengine: pxa-dma design

On Fri, May 08, 2015 at 02:52:46PM +0200, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul@...el.com> writes:
> 
> > On Sat, Apr 11, 2015 at 09:40:32PM +0200, Robert Jarzmik wrote:
> >> Document the new design of the pxa dma driver.
> >> +  a) Transfers hot queuing
> >> +     A driver submitting a transfer and issuing it should be granted the transfer
> >> +     is queued even on a running DMA channel.
> > this is bit confusing, esp latter part.. do you mean "A driver submitting a
> > transfer and issuing it should be granted the transfer queue even on a
> > running DMA channel" ??
> 
> Euh no, I meant that a transfer which is submitted and issued on a _phy_
> doesn't wait for a _phy_ to stop and restart, but is submitted on a "running
> channel". The other drivers, especially mmp_pdma waited for the phy to stop
> before relaunching a new transfer.
> 
> I don't have a clear idea on a better wording yet ...
Ah okay, with that explanation it helps, can you add that to
comments/documentation

> 
> >> +     This implies that the queuing doesn't wait for the previous transfer end,
> >> +     and that the descriptor chaining is not only done in the irq/tasklet code
> >> +     triggered by the end of the transfer.
> > how is it differenat than current dmaengine semantics where you say
> > issue_pending() is invoked when current transfer finished? Here is you have
> > to do descriptor chaining so bit it.
> Your sentence is a bit difficult for me to understand.
Sorry for typo, meant:
how is it different than current dmaengine semantics where you say
issue_pending() is invoked when current transfer finishes? Here you are
doing descriptor chaining, so be it.
Ideally dmaengine driver should keep submitting txns and opportunistically
based on HW optimize it. All this is transparent to clients, they submit and
wait for callback.

> >> +     granularity is still descriptor based.
> > This is not pxa specfic
> True. Do you want me to remove the (c) from the document ?
yes

> >> +  f) Transfer reusability
> >> +     An issued and finished transfer should be "reusable". The choice of
> >> +     "DMA_CTRL_ACK" should be left to the client, not the dma driver.
> > again how is this pxa specfic, if not documented we should move this to
> > dmaengine documentation
> 
> Yes, I agree. I should move this to dmaengine slave documentation, in
> Documentation/dmaengine/provider.txt (in the Misc notes section). Do you want me
> to submit a patch to change the "Undocumented feature" into a properly
> documented feature ?
That would be great

-- 
~Vinod

--
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/