RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
-Original Message- From: Shilimkar, Santosh Sent: Monday, August 31, 2009 11:41 PM To: S, Venkatraman; linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature Venkat, Few comments other wise patch looks fine to me. I am sending a new version with the changes. Can you please Ack ? Thanks, Venkat.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
- Original Message - From: S, Venkatraman svenk...@ti.com To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh santosh.shilim...@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-omapm=125012097403050w=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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Santosh,
-Original Message-
From: Shilimkar, Santosh
Sent: Monday, August 31, 2009 11:41 PM
To: S, Venkatraman; linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor
autoloading feature
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.
Would it be good if we move this description just above those
APIs. Even though this information is good to be here but
later once merged, this would go in commit history.
Somebody reading code also would benefit from this info. I
leave that decision to you.
Agreed partly. Consistent with rest of the source tree,
I don't like to fit a complete user guide in here.
But I'll repost the patch with some brief API comments.
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.
This information too should be in source code somewhere.
Ditto
+int omap_request_dma_sglist(int dev_id, const char *dev_name,
+ void (*callback) (int channel_id, u16 ch_status, void *data),
+ int *listid, int nelem, struct omap_dma_sglist_node **elems) {
+ struct omap_dma_list_config_params *lcfg;
+ struct omap_dma_sglist_node *desc;
+ int dma_lch;
+ int rc, i;
+
+ if (unlikely((dma_caps0_status
DMA_CAPS_SGLIST_SUPPORT) == 0)) {
+ printk(KERN_ERR omap DMA: sglist feature not
supported\n);
+ return -EPERM;
+ }
Don't you need this check in all exported Descriptor API's ?
Just adds clutter. The request_* API is the first one to be called,
and the driver above has to respect the error code and not make
further configuration requests.
If not, it is equally likely on OMAP4 and the check would pass, but create
havoc.
Short answer: Can't defend against poor programming.
Perhaps a omap_dma_is_sg_capable() API is needed ? That doesn't scale for
all the drivers capabilities. Please comment.
+ if (unlikely(nelem = 2)) {
+ printk(KERN_ERR omap DMA: Need 2 elements in
the list\n);
+ return -EINVAL;
+ }
+ rc = omap_request_dma(dev_id, dev_name,
+ callback, NULL, dma_lch);
+ if (rc 0) {
+ printk(KERN_ERR omap_dma_list: Request failed
%d\n, rc);
+ return rc;
+ }
+ *listid = dma_lch;
+ dma_chan[dma_lch].state = DMA_CH_NOTSTARTED;
You have updated channel status here but below allocations
can still fail.
Safer is to update this once all allocation and variable
population done.
It doesn't matter. It's the earliest possible state, that seems to apply to
a unconfigured channel as well.
extern void omap_set_dma_priority(int lch, int dst_port, int
priority); extern int omap_request_dma(int dev_id, const char
*dev_name, @@ -656,6 +739,21 @@ extern int
omap_modify_dma_chain_params(int chain_id, extern int
omap_dma_chain_status(int chain_id); #endif
+extern int omap_request_dma_sglist(int dev_id, const char *dev_name,
+ void (*callback) (int channel_id, u16 ch_status, void *data),
+ int *listid, int nelem, struct omap_dma_sglist_node **elems);
With this code callback after fewer nodes is not supported right ?
I suppose you mean the interrupt callback.
The controller the interrupt management are clever enough to call back when
you have set a pause in the middle.
A fine grained control is available if the DMA user provides a TYPE 1
descriptor.
Not usually needed - it beats the purpose of providing a list.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading feature
Venkat,
Few comments other wise patch looks fine to me.
-Original Message-
From: S, Venkatraman
Sent: Thursday, August 27, 2009 4:42 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh
Subject: [PATCH v2][RFC] OMAP4: sDMA driver: descriptor autoloading
feature
(Updated version of previous patch: http://marc.info/?l=linux-
omapm=125012097403050w=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.
Would it be good if we move this description just above those APIs. Even though
this information is good to be here but later once merged, this would go in
commit history.
Somebody reading code also would benefit from this info. I leave that decision
to you.
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.
This information too should be in source code somewhere.
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.
Summary:
OMAP sDMA driver changes for descriptor autoloading feature.
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/plat-omap/dma.c | 303
+
arch/arm/plat-omap/include/mach/dma.h | 98 +++
2 files changed, 401 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 7677a4a..3a75272 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -29,6 +29,7 @@
#include linux/interrupt.h
#include linux/irq.h
#include linux/io.h
+#include linux/dma-mapping.h
#include asm/system.h
#include mach/hardware.h
@@ -46,13 +47,42 @@ enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE,
DMA_CH_STARTED,
enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
#endif
+/* CDP Register bitmaps */
+#define DMA_LIST_CDP_DST_VALID (BIT(0))
+#define DMA_LIST_CDP_SRC_VALID (BIT(2))
+#define DMA_LIST_CDP_TYPE1 (BIT(4))
+#define DMA_LIST_CDP_TYPE2 (BIT(5))
+#define DMA_LIST_CDP_TYPE3 (BIT(4) | BIT(5))
+#define DMA_LIST_CDP_PAUSEMODE (BIT(7))
+#define DMA_LIST_CDP_LISTMODE(BIT(8))
+#define DMA_LIST_CDP_FASTMODE(BIT(10))
+/* CAPS register bitmaps */
+#define DMA_CAPS_SGLIST_SUPPORT (BIT(20))
+
+#define DMA_LIST_DESC_PAUSE (BIT(0))
+#define DMA_LIST_DESC_SRC_VALID (BIT(24))
+#define DMA_LIST_DESC_DST_VALID (BIT(26))
+#define DMA_LIST_DESC_BLK_END(BIT(28))
+
#define OMAP_DMA_ACTIVE 0x01
#define OMAP_DMA_CCR_EN (1 7)
#define OMAP2_DMA_CSR_CLEAR_MASK 0xffe
#define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
+#define OMAP_DMA_INVALID_FRAME_COUNT (0x)
+#define OMAP_DMA_INVALID_ELEM_COUNT (0xff)
+#define OMAP_DMA_INVALID_DESCRIPTOR_POINTER (0xfffc)
static int enable_1510_mode;
+static int
