linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Kleinosowski <kevinko@arlut.utexas.edu>
To: linuxppc-embedded@ozlabs.org
Subject: Re: 440gx dma transfer with no data change at dest
Date: Fri, 10 Mar 2006 16:07:45 -0600 (CST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0603101535210.23667@mohave.arlut.utexas.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.0603071505110.21479@mohave.arlut.utexas.edu>


Maybe this is too much.  Has anyone successfully done a memory-to-memory 
DMA transfer with the 2.4.27 kernel routines in 
arch/ppc/kernel/ppc4xx_dma.c on any ppc embedded platform?  If you have, 
are you willing to share a bit of code example, or look at one?

   #define MEM_BUF_SIZE_ORDER 4
   #define MEM_BUF_SIZE_BYTES 65536UL
   #define EBC0_DMA_CHANNEL 1
   #define DMA_SR_CS_SET 0x80000000
   unsigned long interruptFlags;
   ppc_dma_ch_t channelSetup;
   int dmaStatus;
   u32 src, dst;

   src = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
   memset ((char *)src, 0xFF, MEM_BUF_SIZE_BYTES);
   dst = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
   memset ((char *)dst, 0x00, MEM_BUF_SIZE_BYTES);
   memset (&channelSetup, 0, sizeof (ppc_dma_ch_t));
   interruptFlags = claim_dma_lock ();
   ppc4xx_get_channel_config (EBC0_DMA_CHANNEL, &channelSetup);
   channelSetup.buffer_enable = 1;
   channelSetup.tce_enable = 1;
   channelSetup.etd_output = 1;
   channelSetup.pce = 0;
   channelSetup.pl = 1;
   channelSetup.pwidth = PW_32;
   channelSetup.sai = 1;
   channelSetup.dai = 1;
   channelSetup.psc = 0;
   channelSetup.pwc = 0;
   channelSetup.phc = 0;
   channelSetup.cp = PRIORITY_LOW;
   channelSetup.pf = PREFETCH_1;
   channelSetup.int_enable = 1;
   channelSetup.mode = DMA_MODE_MM;
   ppc4xx_init_dma_channel (EBC0_DMA_CHANNEL, &channelSetup);
   ppc4xx_enable_dma_interrupt (EBC0_DMA_CHANNEL);
   ppc4xx_disable_dma (EBC0_DMA_CHANNEL);
   ppc4xx_set_src_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)src));
   ppc4xx_set_dst_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)dst));
   ppc4xx_set_dma_count (EBC0_DMA_CHANNEL, MEM_BUF_SIZE_BYTES);
   ppc4xx_enable_dma (EBC0_DMA_CHANNEL);
   release_dma_lock (interruptFlags);

   dmaStatus = ppc4xx_get_dma_status ();
   while ((dmaStatus & (DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) != 
(DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) {
     printk ("DMA STATUS: 0x%8.8x\n", dmaStatus);
     set_current_state (TASK_INTERRUPTIBLE);
     schedule_timeout (HZ/4);
     dmaStatus = ppc4xx_get_dma_status ();
   }


The result dst was initialed to 0x00 but the transfer should have put 
it all to 0xff.  However most locations are 0xff, and some locations are 
0x00.  There seems to be no pattern to it.  Sometimes all locations of dst 
have 0xff.

Anyone see anything wrong?

Kevin


On Tue, 7 Mar 2006, Kevin Kleinosowski wrote:

>
> I am running a simple test with a software initiated DMA transfer from one 
> bigphysarea allocated buffer to another bigphysarea allocated buffer. The 
> destination buffer shows no data changes once the transfer is done.
>
> However, I perform the same simple test using __get_dma_pages() rather then 
> the bigphysarea_alloc_pages() and the destination does get the data transfer.
>
> Is there a reason this should fail for bigphysarea?  I understand the low 
> memory addresses needed for the DMA controller on some platforms, but I didnt 
> think that limitation existed on the PPC.  Besides that, the bigphysarea 
> returns low memory address anyway.  Anyone have an idea why? An old archive 
> email had someone with a similar problem, but there were no follow-ups to the 
> message.
>
> I have linux 2.4.27-pre3 patched, ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1 
> 3.3.3-9), U-Boot 1.1.2, and GMS 440gx board.
>
> thanks,
> Kevin
>
>

  reply	other threads:[~2006-03-10 22:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-07 21:16 440gx dma transfer with no data change at dest Kevin Kleinosowski
2006-03-10 22:07 ` Kevin Kleinosowski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-26 20:58 John Lange

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=Pine.LNX.4.64.0603101535210.23667@mohave.arlut.utexas.edu \
    --to=kevinko@arlut.utexas.edu \
    --cc=linuxppc-embedded@ozlabs.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).