linux-kernel - Re: [PATCH v2 2/2] Documentation: dmaengine: Add a documentation for the dma controller API

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: <20141008121902.GU1638@intel.com>
Date:	Wed, 8 Oct 2014 17:49:02 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Russell King <linux@....linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	dmaengine@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Antoine Ténart <antoine@...e-electrons.com>,
	Thomas Petazzoni <thomas@...e-electrons.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Boris Brezillon <boris@...e-electrons.com>,
	Matt Porter <matt.porter@...aro.org>,
	Gregory Clement <gregory.clement@...e-electrons.com>
Subject: Re: [PATCH v2 2/2] Documentation: dmaengine: Add a documentation
 for the dma controller API

On Tue, Oct 07, 2014 at 06:05:15PM +0300, Laurent Pinchart wrote:
> > > 
> > > Beware, it can be confusing when mixing "descriptors" and "hardware
> > > descriptors". The ones used by the DMA controller itself to describe the
> > > chunks of data (hardware descriptors) and the ones that would represent
> > > them in the driver (tx descriptors). However, it's true that both must
> > > be prepared by this set of functions.
> > 
> > There's a few "hardware" missing indeed, but we can't really avoid the
> > confusion here, since it does rely also on a dma_async_tx_descriptor.
> 
> How about always specifying whether we refer to a "hardware descriptor" or a 
> "transaction descriptor" ?
> 
> > > >> +     - You'll also need to set two fields in this structure:
> > > >> +       + flags:
> > > >> +		TODO: Can it be modified by the driver itself, or
> > > >> +		should it be always the flags passed in the arguments
> > > >> +
> > > >> +       + tx_submit:	A pointer to a function you have to implement,
> > > >> +			that is supposed to push the current descriptor
> > > >> +			to a pending queue, waiting for issue_pending to
> > > >> +			be called.
> > > 
> > > The question remains: why wait when all the information is already
> > > prepared and available for the DMA controller to start the job?
> > > Actually, we don't wait in at_hdmac, just to be more efficient, but I
> > > known that we kind of break this "requirement"... But sorry, it is
> > > another discussion which should be lead elsewhere.
> 
> From my recollection of a discussion I've had with Russell King, I believe the 
> main reason to separate transaction submission (queueing) issue (start) is to 
> let DMA engine drivers issuing several queued requests in one go when hardware 
> supports chaining requests only when none of them are running. It's thus just 
> an optimization. Russell, could you confirm (or infirm) that ?
There are few reasons
- Allow the dmaengine driver to collect and issue all pending txns in shot
(which is not happening today with drivers)
- Allow clients to prepare the txns ahead of time and send them when ready

-- 
~Vinod


> 
> > It's just a guess, but maybe you might not be able to schedule the
> > transfer right away? Think about a very dumb 1-channel (or a more
> > realistic more-DRQ-than-channel) device. You might have all the
> > channels busy doing some other transfers, and it's not really part of
> > the client driver job to address that kind of contention: it just
> > wants to queue some work for a later transfer.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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