linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hemanthv@ti.com (Hemanth V)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Date: Tue, 1 Sep 2009 15:17:47 +0530	[thread overview]
Message-ID: <04ab01ca2ae9$445220a0$LocalHost@wipultra793> (raw)
In-Reply-To: 0680EC522D0CC943BC586913CF3768C0037CE47C07@dbde02.ent.ti.com

----- Original Message ----- 
From: "S, Venkatraman" <svenkatr@ti.com>
To: <linux-omap@vger.kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>; "Shilimkar, Santosh" 
<santosh.shilimkar@ti.com>
Sent: Thursday, August 27, 2009 4:41 PM
Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature


> (Updated version of previous patch: 
> http://marc.info/?l=linux-omap&m=125012097403050&w=2)
> Add sDMA driver support for descriptor autoloading feature.
> Descriptor autoloading is OMAP4 sDMA hardware capability that can be 
> exploited for scatter gather scenarios.
>
> The feature works as described below
> 1) A sDMA channel is programmed to be in 'linked list' mode
> 2) The client (sDMA user) provides a list of descriptors in a linked list 
> format
> 3) Each of the 'descriptor' (element in the linked list) contains an 
> updated set of DMA configuration register values
> 4) Client starts DMA transfer
> 5) sDMA controller loads the first element to its register configuration 
> memory and executes the transfer
> 6) After completion, loads the next element (in linked list) to 
> configuration memory and executes the transfer, without MCU intervention.
> 7) Interrupt is generated after all transfers are completed; this can be 
> configured to be done differently.
>
> Configurations and additional features
> 1) Fast mode & non-fast mode
>       Fast mode/non-fast decides on how the first transfer begins. In 
> non-fast mode, the first element in the linked list is loaded only after 
> completing the transfer according to the configurations already in the 
> sDMA channel registers. In fast mode, the loading of the first element 
> precedes the transfer.
>
> 2) Pause / resume of transfers
>       A transfer can be paused after a descriptor set has been loaded, 
> provided the 'pause bit' is set in the linked list element.
> An ongoing transfer cannot be paused. If the 'pause bit' is set, transfer 
> is not started after loading the register set from memory.
> Such a transfer can be resumed later.
>
> 3) Descriptor types
>       3 possible configurations of descriptors (initialized as linked list 
> elements) are possible. Type 1 provides the maximum flexibility, which 
> contains most register definitions of a DMA logical channel. Fewer options 
> are present in type 2. Type 3 can just modify source/destinations address 
> of transfers. In all transfers, unmodified registers settings are 
> maintained for the next transfer.
>
> Patch provides options / API for
> 1) Setting up a descriptor loading for DMA channel for sg type transfers
> 2) configuration with linked list elements
> 3) Starting / pause and resume of the said transfers, query state
> 4) Closing/Releasing the DMA channel
>
> The patches are generated against kernel 2.6.31-rc1, tested on OMAP4 
> simulator platform.

It might be easier to understand the APIs if you could provide an example. 
Could you take example of a contiguous/non-contiguous buffer and explain how 
the desciptor based DMA could be used on this. 

      parent reply	other threads:[~2009-09-01  9:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27 11:11 [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature S, Venkatraman
2009-08-31 18:10 ` Shilimkar, Santosh
2009-09-01 13:00   ` S, Venkatraman
2009-09-03 18:24   ` S, Venkatraman
2009-09-01  9:47 ` Hemanth V [this message]

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='04ab01ca2ae9$445220a0$LocalHost@wipultra793' \
    --to=hemanthv@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).