All of lore.kernel.org
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Documentation: dmaengine: Add a documentation for the dma controller API
Date: Tue, 5 Aug 2014 21:55:45 +0530	[thread overview]
Message-ID: <20140805162545.GX8181@intel.com> (raw)
In-Reply-To: <20140802144925.GJ3952@lukather>

On Sat, Aug 02, 2014 at 04:49:25PM +0200, Maxime Ripard wrote:
> > - residue callculation, though situation is much better now but still lots
> >   of driver do it worng and folks do get it wrong
> 
> What mistake in often made regarding the residue calculation?
- residue is for the descriptor asked
- not for the current active one
- we can store the size locally and return that when not processing
- arg txstate can be null

> Another extra questions arose during starting this.
> 
> In the case of the call to device_control, especially in the
> DMA_SLAVE_CONFIG case, but that also applies to pause/resume, are the
> changes supposed to be immediates or can they happen later?
> 
> I actually have in mind the case where we would use a vchan, that
> might or might not be actually mapped to a physical channel at the
> moment where the DMA_SLAVE_CONFIG call is made. In the case where it's
> not mapped and not transfering anything, it's pretty trivial, to
> handle, but in the case where it's actually mapped to a physical
> channel, should we push the new configuration to the physical channel
> right away, or can it wait until the transfer ends ?
Ah no. The model doesn't assume the config will be written runtime. So the
descriptor which are already prepared doesn't change with DMA_SLAVE_CONFIG
call. Only new descriptors will take those values

But yes the pause/resume would be syncronous

HTH
-- 
~Vinod

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140805/b070ba77/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: "Dan Williams" <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	"Russell King" <linux@arm.linux.org.uk>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Antoine Ténart" <antoine@free-electrons.com>,
	"Thomas Petazzoni" <thomas@free-electrons.com>,
	"Alexandre Belloni" <alexandre.belloni@free-electrons.com>,
	"Boris Brezillon" <boris@free-electrons.com>,
	"Matt Porter" <matt.porter@linaro.org>,
	laurent.pinchart@ideasonboard.com, ludovic.desroches@atmel.com,
	"Gregory Clement" <gregory.clement@free-electrons.com>,
	"Nicolas Ferre" <nicolas.ferre@atmel.com>
Subject: Re: [PATCH] Documentation: dmaengine: Add a documentation for the dma controller API
Date: Tue, 5 Aug 2014 21:55:45 +0530	[thread overview]
Message-ID: <20140805162545.GX8181@intel.com> (raw)
In-Reply-To: <20140802144925.GJ3952@lukather>

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Sat, Aug 02, 2014 at 04:49:25PM +0200, Maxime Ripard wrote:
> > - residue callculation, though situation is much better now but still lots
> >   of driver do it worng and folks do get it wrong
> 
> What mistake in often made regarding the residue calculation?
- residue is for the descriptor asked
- not for the current active one
- we can store the size locally and return that when not processing
- arg txstate can be null

> Another extra questions arose during starting this.
> 
> In the case of the call to device_control, especially in the
> DMA_SLAVE_CONFIG case, but that also applies to pause/resume, are the
> changes supposed to be immediates or can they happen later?
> 
> I actually have in mind the case where we would use a vchan, that
> might or might not be actually mapped to a physical channel at the
> moment where the DMA_SLAVE_CONFIG call is made. In the case where it's
> not mapped and not transfering anything, it's pretty trivial, to
> handle, but in the case where it's actually mapped to a physical
> channel, should we push the new configuration to the physical channel
> right away, or can it wait until the transfer ends ?
Ah no. The model doesn't assume the config will be written runtime. So the
descriptor which are already prepared doesn't change with DMA_SLAVE_CONFIG
call. Only new descriptors will take those values

But yes the pause/resume would be syncronous

HTH
-- 
~Vinod


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2014-08-05 16:25 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30 16:03 [PATCH] Documentation: dmaengine: Add a documentation for the dma controller API Maxime Ripard
2014-07-30 16:03 ` Maxime Ripard
2014-07-30 16:06 ` Vinod Koul
2014-07-30 16:06   ` Vinod Koul
2014-07-31  7:44   ` Maxime Ripard
2014-07-31  7:44     ` Maxime Ripard
2014-07-31 11:56     ` Vinod Koul
2014-07-31 11:56       ` Vinod Koul
2014-07-31 16:23       ` Maxime Ripard
2014-07-31 16:23         ` Maxime Ripard
2014-08-01 17:13         ` Vinod Koul
2014-08-01 17:13           ` Vinod Koul
2014-08-02 14:49           ` Maxime Ripard
2014-08-02 14:49             ` Maxime Ripard
2014-08-02 15:17             ` Russell King - ARM Linux
2014-08-02 15:17               ` Russell King - ARM Linux
2014-08-02 19:06               ` Maxime Ripard
2014-08-02 19:06                 ` Maxime Ripard
2014-08-05 16:25             ` Vinod Koul [this message]
2014-08-05 16:25               ` Vinod Koul
2014-07-31 12:44     ` Lars-Peter Clausen
2014-07-31 12:44       ` Lars-Peter Clausen
2014-07-31 16:13       ` Maxime Ripard
2014-07-31 16:13         ` Maxime Ripard
2014-07-31 16:54         ` Lars-Peter Clausen
2014-07-31 16:54           ` Lars-Peter Clausen
2014-07-31 17:37           ` Maxime Ripard
2014-07-31 17:37             ` Maxime Ripard
2014-08-01  8:00             ` Lars-Peter Clausen
2014-08-01  8:00               ` Lars-Peter Clausen
2014-08-01  8:57               ` Maxime Ripard
2014-08-01  8:57                 ` Maxime Ripard
2014-08-01 17:15                 ` Vinod Koul
2014-08-01 17:15                   ` Vinod Koul
2014-08-01 18:09                   ` Lars-Peter Clausen
2014-08-01 18:09                     ` Lars-Peter Clausen
2014-08-02 15:13                     ` Maxime Ripard
2014-08-02 15:13                       ` Maxime Ripard
2014-08-04  7:16                       ` Lars-Peter Clausen
2014-08-04  7:16                         ` Lars-Peter Clausen
2014-07-31 13:22     ` Russell King - ARM Linux
2014-07-31 13:22       ` Russell King - ARM Linux
2014-07-31 16:41       ` Maxime Ripard
2014-07-31 16:41         ` Maxime Ripard
2014-08-01 14:53         ` Russell King - ARM Linux
2014-08-01 14:53           ` Russell King - ARM Linux
2014-08-02 15:11           ` Maxime Ripard
2014-08-02 15:11             ` Maxime Ripard
2014-08-02 15:29             ` Russell King - ARM Linux
2014-08-02 15:29               ` Russell King - ARM Linux
2014-08-02 19:05               ` Maxime Ripard
2014-08-02 19:05                 ` Maxime Ripard
2014-08-01 17:22       ` Vinod Koul
2014-08-01 17:22         ` Vinod Koul
2014-08-05  8:16 ` Geert Uytterhoeven
2014-08-05  8:16   ` Geert Uytterhoeven
2014-08-14  8:53 ` Ludovic Desroches
2014-08-14  8:53   ` Ludovic Desroches
2014-08-14  8:57   ` Russell King - ARM Linux
2014-08-14  8:57     ` Russell King - ARM Linux
2014-08-19 13:45     ` Vinod Koul
2014-08-19 13:45       ` Vinod Koul
2014-08-19 14:44       ` Russell King - ARM Linux
2014-08-19 14:44         ` Russell King - ARM Linux
2014-08-19 14:57         ` Vinod Koul
2014-08-19 14:57           ` Vinod Koul

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=20140805162545.GX8181@intel.com \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.