• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1459 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.

u-boot bootargs and driver parameter questions.

John Anderson
Genius 5240 points

I'm using dvsdk 4 on a dm368 board and question some of the bootargs.  It's my understanding (please correct me if I'm wrong) that a parameter such as "vpfe_capture.cont_bufsize=6291456" means that a module_param called "cont_bufsize" in the module vpfe_capture will be set on the kernel init to the specified value.  However the name of the module is "vpfe-capture" and not "vpfe_capture".  Is this a bug in the settings?  Or an I overlooking something?

Also I have a parameter in the bootargs specified as "davinci_display.cont2_bufsize=6291456".  However I can't find any module in the kernel called "davinci_display".  Can anyone tell me what this parameter is for?

Thanks, John A

  • 0
    Genius 5240 points

    I'm still dealing with this question because of memory allocation issues.  Disregarding the first question, which no one seems to know, do these parameters in the bootargs mean the capture and display drivers are each allocating about 6MB of memory?

    In my decoder application I am calling the DMAI Display_create and supplying an allocated buftab.  Does this mean the 6MB davinci_display.cont2_bufsize is wasted?  The same with the capture driver.  My encoder calls DMAI Capture_create with an allocated buftab.  Does this mean the 6MB vpfe_capture.cont_bufsize is wasted?

    Does anyone know where the allocated memory comes from?  Looking at the drivers they each appear to be allocated right after the end of the kernel memory.  But that's where the CMEM is instructed to create memory.  I really need to find more memory space.  My board has 128MB and I've given the kernel 60MB.  I'm running both encode and decode simulaneously.

    Any help would be appreciated.

    John A

  • 0 in reply to John Anderson
    TI__Expert 5680 points

    John,

    IIRC, i've put some explation about the memory location in DVSDK 4.01 loadmodule and setup script to explain the default DVSDK boot args settings. Let me explain it here too:

    1) If your display application  is using "user allocated" buffers then you don't need to pass "davinci_display.cont2_bufsize=6291456" in kernel command line. Actually this word in command line tell Linux Display driver to reseve 6MB of memory during bootime. And this memory is used when application uses driver allocated buffer (i.e mmap). And if you are using user allocated buffer all the time then technically you are wasting 6MB - which you should give to Linux

    2) Similar to above, "vpfe_capture.cont_bufoffset=6291456  vpfe_capture.cont_bufsize=6291456" tells V4l2 capture driver to reserve 6MB of buffer and this get used during mmap calls. So if your capture application is using user allocated buffer then you are wasting this 6MB of memory - which you should give to Linux.

    In summary, if both your display and capture is using user allocated buffer then i you should consider removing these bootargs and give more memory to Linux (i.e you can easy use mem=60M ).

    During DVSDK 4.0 release, Gstreamer was the only application which uses the Driver allocated buffer for both display and capture - whereas in DVSDK 4.01 release we have update Gstreamer display sink to work with user allocated buffer hence you will notice the mem option changes. But we are still using mmap buffer on Gstreamer capture source element side.

    HTH.

    Thanks

    Brijesh

       

     

  • 0 in reply to Brijesh Singh
    Genius 5240 points

    Thanks Brijesh,

    Right after starting this thread I tried removing those command from the bootargs and everything worked.  Nice to free up 12MB.

    So the memory came from the 60MB kernel space.  That's good to know.

    John A