• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 783 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FBDev buffers to DSP

Glenn Wainwright
Expert 1605 points
Other Parts Discussed in Thread: OMAP3530

Could some one help give me an example of how I might pass a buffer created by an fbdev device to a Codec Engine-based VISA algorithm running on a DSP?  I assume any buffers sent to the DSP need to be created with CMEM, but fbdev does not support user-allocated buffers.  Is there an alternate way of registering memory with CMEM that would allow me to pass that data to the DSP?

Thank you,
Glenn Wainwright 

  • 0
    TI__Mastermind 18260 points

    It's not so much that the VISA algorithm buffers (or any DSP buffers) need to come from CMEM, but more that they must be physically contiguous since they will be accessed by sequential physical address on the DSP.  CMEM guarantees a physically contiguous buffer, and if the fbdev delivers physically contiguous buffers then those buffer's virtual address can be passed to the codec through the VISA interface (which will translate the virtual address to its physical form when passing them to the DSP).

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    Hm, okay.  Then I guess I assumed wrong, and perhaps there's a different reason I get the following error when I pass a pointer to the Graphics layer fbdev buffer:

    DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0x806b6000].

    What else could be causing this?

  • 0 in reply to Glenn Wainwright
    TI__Genius 17205 points

    You'll have to explicitly map the fbdev buffers into the DSP's MMU so the DSP can access them.

    http://processors.wiki.ti.com/index.php/OMAP3_DSP_MMU_Configuration

    Chris

  • 0 in reply to Glenn Wainwright
    TI__Mastermind 18260 points

    I assume that you're getting the MMU fault because the fbdev buffer that you passed to the DSP has not been mapped in the DSP's address space.

    With Codec Engine (CE), when using a part that has a DSP MMU, CE will add CMEM to DSPLink's DSP memory configuration tables, which causes DSPLink to map the CMEM physical block (it's just a "null" mapping that has the same virtual address as the physical address, but a mapping nonetheless).  In order to access the fbdev buffer from the DSP you will need to somehow create a "null" 1-to-1 DSP MMU entry, but I don't know how to do this since DSPLink does it for CE as part of the PROC_setup() call (to which we pass a DSPLink configuration with memory tables that are generated from the DSP's codec server memory map).  I would imagine DSPLink has ARM-side APIs available to add a DSP MMU entry.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    So I'm following the steps here http://processors.wiki.ti.com/index.php/OMAP3_DSP_MMU_Configuration to try to set up the DSP MMU link that you describe.  I'm calling:

    ProcMemMapInfo mapInfo;
    mapInfo.dspAddr = (Uint32)myBufferPhysicalAddress;
    mapInfo.size = myBufferSize;
    PROC_control(0, PROC_CTRL_CMD_MMU_ADD_ENTRY, &mapInfo);

    ... and I'm getting an error back: 0x80008002, which appears to be DSP_EATTACHED ("The GPP process is not attached to the specific processor.")  Does that error make any sense to you?

    Thanks for the help so far,
    Glenn 

  • 0 in reply to Glenn Wainwright
    TI__Mastermind 18260 points

    It sounds like you're making that PROC_control() call before calling Engine_open(), which does the PROC_setup()/PROC_attach()/PROC_load()/PROC_start() calls.  If so, please try that code after your Engine_open().  If not, respond back here and we'll think harder.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Expert 1605 points

    Alright, one step closer.  So, ensuring that Engine_open is called first does allow it to proceed.

    However, the MMU TLB registration apparently requires not just a specific size of buffer, but also a specific alignment in order to not fill up the TLB with numerous entries for one single registration.  So, for example, if I want to allocate 4 MB of vram and only use 4 TLB entries, I'd need to ensure that the pointer is aligned to 1MB (this is, if I'm reading omap3530_hal_mmu.c correctly).

    How would I set up the vram to ensure its alignment?

  • 0 in reply to Glenn Wainwright
    TI__Mastermind 18260 points

    I don't know anything about fbdev and vram, so I can't help with that.

    However, is it possible that you could simply map more than is needed for just the buffer, by rounding down the address to, say, the next lowest 1 MB boundary (and possibly rounding up the size)?

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    I thought about that, and I was worried about what that might do to that chunk of memory that I'm not allocating... but it's worth a shot at least.

  • 0 in reply to Glenn Wainwright
    TI__Mastermind 18260 points

    I hesitated to even suggest that, but considered that when the DSP MMU is used in this 1-to-1 "null" mapping way the DSP becomes similar to ones without MMUs, where access to any memory is allowed and the DSP can easily crash Linux (or whatever is running on the ARM).  In other words, if your DSP program is "correct" then there will be no problem, but if some stray pointer just happens to fall in this mapped-but-unowned regoin then bad things could happen.  And if it's just vram, then a bad access by the DSP will probably not crash anything.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    Woo-hoo!  It's working, and the DSP codec is fine with it.  Cross your heart and promise to never go outside the array bounds - EVER - but it works.  Thank you to much for all your help digging down into this.

    Glenn