Re: [PATCH] Add support for packet synchronised sDMA transfers.
I believe, packet mode is already supported in the current DMA driver. Both the FS and BS bits of the CCR are set when packet mode is selected. This is because, enum for OMAP_DMA_SYNC_PACKET is '0x03' (i.e OMAP_DMA_SYNC_FRAME | OMAP_DMA_SYNC_BLOCK). On Wed, Mar 3, 2010 at 4:20 AM, Fabrice Goucem f-gou...@ti.com wrote: System DMA packet synchronisation is currently not supported in the Linux Kernel. This patch provides necessary modifications to support packet synchronisation: Function omap_set_dma_transfer_params() handles value OMAP_DMA_SYNC_PACKET to program FS and BS bits of register CCR. Users can give the packet size to the DMA driver by using parameters src_fi / dst_fi in functions omap_set_dma_src_params() / omap_set_dma_dest_params(). Patch has been validated using OMAP's McSPI (on Zoom2, OMAP3430): McSPI is configured to use DMA transfer. FIFO are activated with a threshold of 16 bytes (i.e. DMA requests will be triggered as soon as more than 16 bytes are free in the FIFO). A frame of 132 elements (bytes) has been transfered, by packets of 16 elements. Resulting transfer was 8 packets of 16 elements plus a last packet of 4 elements. Modifications tested building on OMAP2, OMAP3 and OMAP4 configurations. Signed-off-by: Fabrice Goucem f-gou...@ti.com Acked-by: Venkatraman S svenk...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Shilpa Maddi s-ma...@ti.com --- arch/arm/plat-omap/dma.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 2ab224c..48f9355 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -293,12 +293,14 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count, val |= (dma_trigger ~0x1f) 14; val |= dma_trigger 0x1f; - if (sync_mode OMAP_DMA_SYNC_FRAME) + if ((sync_mode == OMAP_DMA_SYNC_FRAME) || + (sync_mode == OMAP_DMA_SYNC_PACKET)) val |= 1 5; else val = ~(1 5); - if (sync_mode OMAP_DMA_SYNC_BLOCK) + if ((sync_mode == OMAP_DMA_SYNC_BLOCK) || + (sync_mode == OMAP_DMA_SYNC_PACKET)) val |= 1 18; else val = ~(1 18); -- 1.6.0.4 -- 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 -- 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
[OMAP3] ALSA driver 'suspend/resume' handlers
Hi,
It appears OMAP ALSA driver does not seem to disable and idle the SDMA
channel on a 'suspend' call. The problem seems to be with the
'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in
'omap_pcm_trigger()'. ALSA audio driver uses self linking and the
function 'omap_stop_dma()', only unlinks the channels, but DOES NOT
disable an active channel for linked channels.
memset(dma_chan_link_map, 0, sizeof(dma_chan_link_map));
do {
/* The loop case: we've been here already */
if (dma_chan_link_map[cur_lch])
break;
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
disable_lnk(cur_lch);
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
return; ---
}
This means after a return from the 'omap_stop_dma()', there can still
be an active DMA transaction on the channel. Is this the intent Or a
bug? I can think of situations, where in, we may want to complete the
DMA transfer and then disable the channel. In such a case, we need to
wait until the channel is inactive.
The problem with the current implementation is that after the audio
platform trigger (suspend) is called, SOC core calls the CPU DAI
trigger (suspend) and this stops the McBSP. Depending on the current
DMA pointer, this may leave the DMA channel in active state, since DMA
is configured for DEST HW Synchronization and and the this never gets
asserted after the McBSP is stopped..
I see two ways to resolve this issue:
a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend)
until the DMA channel is inactive (i.e buffer transfer complete). But,
i believe 'trigger' is supposed to be an atomic operation, so we may
need to wait in a worker thread. And we need to flag the McBSP stop
based on DMA transfer completion.
b) Explicitly disable the DMA channel in 'omap_stop_dma().
Option 'b' above may mean losing some data on resume, if we hit 'OFF'
state during suspend. This may not be a big deal for audio (loss of
few secs audio), but for other drivers (ex: USB data file transfer?),
this may not be acceptable. 'Option 'a' means more rework in audio
driver, but no changes in DAM driver and no loss of data.
Current Audio driver also does not seem to support 'OFF' mode during
suspend. It seems to assume that all DMA and McBSP configurations are
retained in a suspend to resume transition.
Thanks
--
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: [OMAP3] ALSA driver 'suspend/resume' handlers
On Tue, Sep 22, 2009 at 10:20 PM, Pandita, Vikram vikram.pand...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of hari n
Sent: Tuesday, September 22, 2009 9:38 PM
To: linux-omap@vger.kernel.org
Subject: [OMAP3] ALSA driver 'suspend/resume' handlers
Hi,
It appears OMAP ALSA driver does not seem to disable and idle the SDMA
channel on a 'suspend' call. The problem seems to be with the
'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in
'omap_pcm_trigger()'. ALSA audio driver uses self linking and the
function 'omap_stop_dma()', only unlinks the channels, but DOES NOT
disable an active channel for linked channels.
memset(dma_chan_link_map, 0, sizeof(dma_chan_link_map));
do {
/* The loop case: we've been here already */
if (dma_chan_link_map[cur_lch])
break;
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
disable_lnk(cur_lch);
What if we introduce this code here?
/* Stop the Channel transmission */
l = dma_read(CCR(cur_lch));
l = ~(1 OMAP_DMA_CCR_EN);
dma_write(l, CCR(cur_lch));
This may result in disabling an active DMA channel.. Which can lead to
un-drained FIFOs, if we do not wait to check for 'RD_ACTIVE',
'WR_ACTIVE' bits (refer to 'Disabling a channel during transfer' and
'FIFO draining mechanism'. In addition, as i mentioned below we may
also lose data..
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
return; ---
}
This means after a return from the 'omap_stop_dma()', there can still
be an active DMA transaction on the channel. Is this the intent Or a
bug? I can think of situations, where in, we may want to complete the
DMA transfer and then disable the channel. In such a case, we need to
wait until the channel is inactive.
The problem with the current implementation is that after the audio
platform trigger (suspend) is called, SOC core calls the CPU DAI
trigger (suspend) and this stops the McBSP. Depending on the current
DMA pointer, this may leave the DMA channel in active state, since DMA
is configured for DEST HW Synchronization and and the this never gets
asserted after the McBSP is stopped..
If you check the chaining DMA api: omap_stop_dma_chain_transfers() has this
kind of code:
/* Stop the Channel transmission */
l = dma_read(CCR(channels[i]));
l = ~(1 7);
dma_write(l, CCR(channels[i]));
Should audio be using chaining api's?
Not sure how linking and chaining are related though.
Is self-linking a case of chaining with two same elements?
Here again, we have the same issue of disabling the channels, while
some data may be in the FIFO/flight..
I see two ways to resolve this issue:
a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend)
until the DMA channel is inactive (i.e buffer transfer complete). But,
i believe 'trigger' is supposed to be an atomic operation, so we may
need to wait in a worker thread. And we need to flag the McBSP stop
based on DMA transfer completion.
b) Explicitly disable the DMA channel in 'omap_stop_dma().
Option 'b' above may mean losing some data on resume, if we hit 'OFF'
state during suspend. This may not be a big deal for audio (loss of
few secs audio), but for other drivers (ex: USB data file transfer?),
this may not be acceptable. 'Option 'a' means more rework in audio
driver, but no changes in DAM driver and no loss of data.
Current Audio driver also does not seem to support 'OFF' mode during
suspend. It seems to assume that all DMA and McBSP configurations are
retained in a suspend to resume transition.
Thanks
--
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
--
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
Camera Flash driver
Hi, We are planning to develop a camera flash driver for OMAP3430. I briefly looked around and it appears there is none available for omap. We would like to take an existing Camera flash driver if available (any platform) and upgrade it for omap3. so, any pointers are highly appreciated. Thanks hari -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
