OMAP L-137 mmap DSP Memory in Linux

With a modification to the driver I'm able to map the "Shared Memory" between the ARM and the DSP at 0x8000 0000. I'm able to write to and read from the memory in userspace as well. I'm still not able to map for example the L2RAM with this modification. Can anyone tell me what I'm doing wrong?

I've added the altered code below, the bold part contains the change;

#define SHAREDRAM_ADDR    0x80000000
#define SHAREDRAM_SIZE    0x20000     // 128K

struct cdev *dev_sharedram;

// mmap memory
static int
dspcom_mmap(struct file * filp, struct vm_area_struct * vma)
{
  int retval;

  unsigned long physical  = 0;
  unsigned long psize     = 0;
  size_t        vsize     = vma->vm_end - vma->vm_start;

  switch( iminor( filp->f_dentry->d_inode ) )
  {
    case DSPCOM_MINOR_SHAREDRAM:
      physical  = SHAREDRAM_ADDR;
      psize     = SHAREDRAM_SIZE;
      break;
    default:
      return -ENOMEM;
  }

  if( vsize > psize )
  {
    printk( "DSPCom: vsize[%ld] > psize[%ld]\n", vsize, psize );
    return -ENOMEM;
  }

  retval = remap_pfn_range( vma, vma->vm_start,physical >> PAGE_SHIFT, vsize, vma->vm_page_prot );
  if( 0 != retval )
  {
    printk( "DSPCom: unable to remap_pfn_range: %d\n", retval );
  }
  return 0;
}

struct file_operations dspcom_sharedmem_fops =
{
  .owner = THIS_MODULE,
  .mmap  = dspcom_mmap,
};

static int __init
dspcom_init_module ( void )
{
  int retval = 0;

  dev_sharedram = cdev_alloc();

  // SHAREDRAM Memory
  dev_sharedram->ops = &dspcom_sharedmem_fops;
  dev_sharedram->dev = MKDEV( DSPCOM_MAJOR, DSPCOM_MINOR_SHAREDRAM );
  retval = cdev_add( dev_sharedram, MKDEV( DSPCOM_MAJOR, DSPCOM_MINOR_SHAREDRAM ), 1 );
  if( 0 != retval )
  {
    printk( "DSPCom: cdev_add sharedram error: %d\n", retval );
    retval = -EAGAIN;
    goto sharedram;
  }
  return 0;
}

Thanks for the code posting.  I'm writing my own driver as well to replace DSPLINK and only needed access to 0x80000000 for what I'm doing so my code was fine.  Where I am seeing a problem and don't know if you have yet is in the interrupt handler for the ARM/DSP communication registers.  For each time the DSP sets the CHIPSIG INT0/1 bits the handler on the Linux side gets called 3 times.  The first is the real call where the bits are cleared, CHIPSIG_CLR, the other two are from the low level handler.  /proc/interrupts only shows a single interrupt.  If I cheat and write the interrupt number to AINTC SICR and HIPIR2 I can get it down to 2 calls, the real one and a phantom one.  Can't really do this though as opens potential for race condition when the lower level Linux code acknowledges system interrupt again.

Only way around it thus far is to simply check the CHIPSIG register in the interrupt handler and if bit not set return IRQ_HANDLED, ignoring interrupt.  Note SA_INTERRUPT is set on request_irq call.  Works but wasted CPU cycles.  In the extra calls to the interrupt handler CHIPSIG INT0/1 bits are not set, were cleared by the handler during the first real interrupt and remain cleared until I use JTAG and poke the DSP register again.  Interrupts are set for edge trigger as well.  Anyways I'll look into it more when get some time but curious if you've seen anything.

Kev

I ran into exact the same problem! I had no clue where to look for the source of the problem. I first thought it was because I didn't set the interrupt type so it would trigger on rising edge, level and falling edge. Setting the interrupt type to rising did not solve the problem.

Have you already thought about how you want to program code into your DSP and start/stop it? I was thinking of using the DSP Link for this because it looks like a pretty advanced sequence. Down part of the DSP LInk driver is the overhead and its complexity.

Luke

Well at least I know now it wasn't just me ;-).  I figured it was set to level interrupts and I was getting recursion but verified no recursion & edge set, it is the Linux handler that is re-invoking us after each return.  The forced clearing of SICR/HIPIR2 reducing it by one is kind of strange, especially given /proc/interrupts only shows a single interrupt occured.  When I get a chance I'll look into doing a special kernel build with some debug information but my guess is there is a race condition in the kernel interrupt handler...  Both system interrupt 28 and 29 act identical.  Eventually I'll be moving to the OMAP-L138 and will worry about it then if still occurs.  Support for the L137 is not the best and figure TI focus will be more L138 with open source.  Besides I really need the extended address space on the L138 so I can get rid of using latches for upper memory access on EMIFA.  L138 should be available end of August/beginning of September, although not sure state of Linux at that point, although port should be easy from L137.

With regards to start/stop my world is fairly easy as I only have to start, DSP is more of the master and Linux is just providing communications and file access.  I modified the ARM ubl spi code to not reset the DSP when uboot is loaded thus DSP stays running and I can use JTAG or spin waiting for some event to occur (like Linux to boot).  Figure when I get to the real code I'll just have Linux load the file image to some known location for the DSP and then tell the initial DSP ubl code where to branch too once ready to run.  Much simpler.  Need both messaging and DSP/Linux to share common memory variable references so DSP not interrupted all the time and don't have to copy data.

Kev

Yeah I also removed the part from the ARM UBL that put the DSP in reset. I use Code Composer to load the DSP application during development. I have to be able to update the DSP image from within Linux, I also need to suspend the DSP when the device is in standby to save power.

The coff parsing involved with programming the DSP application was what looked difficult to me. Maybe it's possible to write a binary directly into the L1PRAM. I assume that start, stop and reset is just writing a sequence to some registers. I still have to get more information on that.