Re: [PATCH] Add support for packet synchronised sDMA transfers.

2010-03-03 Thread hari n
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

2009-09-22 Thread hari n
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

2009-09-22 Thread hari n
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

2008-10-23 Thread hari n
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