• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 156 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.

AM625: AM62x: Replacement of dma_buf_phys driver

Adwin Ong
Prodigy 10 points
Part Number: AM625

Tool/software:


SoC: AM62X SR1.0 HS-FS
Model: Texas Instruments K3 AM625 SoC

Hi TI supports,

We have been using the AM62x processor and have implemented a Remote IPC solution that utilizes the dma_buf_phys driver to obtain the physical address of a shared data buffer. This buffer is used for data exchange between the M4F core and the A53 core.

After upgrading our Linux platform to uses a later version of TI kernel (6.1 to 6.6), we noticed that the dma_buf_phys driver is no longer available. We would like to inquire about the following:

  1. Is there a replacement or alternative driver for dma_buf_phys in the new Linux platform?
  2. What steps can we take to achieve the same functionality (i.e., obtaining the physical address of a shared data buffer) with the new driver or any other recommended method?

Your guidance on this matter would be greatly appreciated.

Best regards,
Adwin Ong

  • +1
    TI__Guru** 100980 points

    Hello Adwin,

    what is the "Linux standard" way to expose remote processor memory up to Linux userspace? 

    At this point in time, the Linux community is still aligning on the "best" way to expose memory up to Linux userspace. That means that different methods of sharing memory are used in different Linux kernel versions. It also means that the method that TI supports on Linux kernels 6.6 and 6.12 may not be supported on later Linux kernels.

    We can use the zerocopy example as a starting point

    In Linux kernel 5.10 and 6.1, TI provided patches to dma_buf_phys to expose memory up to Linux userspace. For those kernel versions, please refer to the zerocopy example, branch ti-linux-6.1:
    https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

    TI engineers currently think that extending the remoteproc CDev driver is the "best" solution. So for Linux kernels 6.6 and 6.12, we support using the remoteproc CDev driver instead. Since the CDev changes have not been upstreamed, you will want to add some patches to Linux, similar to what was needed to enable the dma_buf_phys driver in previous Linux kernel versions. For more information, please refer to the zerocopy example, master branch, Linux README.md:
    https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/tree/linux/README.md

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 10 points

    Hi Nick,

    We have previously developed our product application using dma_buf_phys following the zerocopy example, so we would like to patch it back using this patch we found - git.ti.com. We have successfully done so and tested that it was working for us.

    But we want to understand if there are any known security risk or legal issue that might be associated with the patch if we were to ship products using it? Can you advise us on the risk?

    Best regards,
    Adwin Ong