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.

Question regarding memcpy

Hi,

I have been looking into the sample code and I have seen that there is this rszCopy class, and I am assuming this class is there to work with the EDMA of the DM355.  Is there any documentation regarding how to design this, and what other things can be done with the EDMA.

Thanks in advance.

 

  • Please note that there is an EDMA Linux driver that can be used by other kernel drivers to use the traditional DMA channels as described in the EDMA users guide.  Look under Linux kernel tree under

    .../ti-davinci/arch/arm/mach-davinci

    The Video Processing Subsystem (VPSS) also has its own built-in EDMA that is always on; hence using any part of this hardware block such as resizer (which I assume rszCopy is related to) would also use DMA functionality.

  • Hi,

    Basically what I want to do is I currently have the frame that I recieved from the Video 4 Linux 2 Api, and I have maaped it to the user level, I want to copy this into the DDR Memory so that I can requeue my buffer back to the driver level.  And then I can grab the DDR memory from another thread to JPEG Compress it.  How do I go about doing this?  Do I have to go to the low levels to perform this?

  • Rather then copying v4l2 buffer (which is already in DDR2) to requeue, I would simply add another v4l2 buffer (double buffering, tripple buffering...) and avoid un-necessary copies of video buffers.  You should be able to do all of this from user space regardless of the method you implement, I just wanted to give you options.

  • I was looking at the example, and how they transfer a video frame to the encoding thread, and they do some stuff dealing with rszExecute.  This is in the encode example as well as the encodedecode example.  I want to take the buffer data and pass it through JPEG compression, and I was creating a pipe exactly like in the example to copy the data to the next thread.  So I dont have to do this?

  • I have not had a chance to take a look at the latest demos in detail, but can confirm the older demos made unnecessary copies of video buffers; I beleive using the resizer was supposed to get rid of un-necessary copies due to de-interlacing, but I am not sure if other demo areas are still doing un-necessary copies.  You can take a look at the demo source code yourself and look for all the places where video buffers are being copied and ask me if they make sense.

  • If its possible can you explain to me what the resizer does?

  • I am not sure I understand why you are asking this, but essentially resizer can take a video buffer, optionally resize it, and write it out to a separate video buffer in DDR2.

    If this does not answer your questions/concerns, please feel free to add more detail and I will be happy to address them.

  • There is also some additional description of the resizer in section 4.3.15 of SPRUF71a, it is meant for scaling/resizing your image as Juan mentions, but by performing this act it also acts like a DMA controller.