Hi remote-proc team， My name is Zichar Zhang, I come from China, And I'm working in a microchip company names ZEKU. Our first phone chip product was not yet announced. (Ao Zhang is my Chinese name) I am working on our subsystem drivers using remote-proc framework. The remote-proc framework works well. But if I enabled iommu, there are several problems comes. This email is ask for help if you have some ideas for these problems. I will list the problems and make them short. First is the background and requirement for our subsystem: 1. The "sram" in subsystem is too small and we have to load some datas from firmware file to DDR. 2. We use "vring & rpmsg" as the IPC tool to communicate with subsystem. I use "vring" sub-device mechanism in remote-proc. 3. There is an address offset between "linux" and subsystem in our "SOC". which means "linux" and subsystem read/write the same DDR memory through different address, there is a linear offset between them. I think it's a common case without architecture differences. The first problem is remote-proc use iommu api with a new allocated iommu domain when "vring & rpmsg" drivers using dma api. That makes the memory address separately and can not take effect at the same time. They are not sharing the same page table. So I do not use the "iommu" code in remote-proc framework, which means I can't use "carveout handle" inside the default "resource table" handle function. I bind iommu to our platform device and rewrite the "carveout handle" using dma api to allocate and map memory. But why not remote-proc framework use this solution just let users binding their iommu device if they need and use dma api as the same api "vring & rpmsg" use. The second problem is the "dev" parameter we passed to "vring & rpmsg" drivers. There are four level "device" in remote-rproc: platform device, rproc device, rvdev device and vdev device. Remote-proc pass the rvdev device as the "dev" parameter to "vring & rpmsg" drivers, witch also makes "separate page table" cause remote-proc uses platform device as "dev" parameter passed to dma api. Although they copy the "dma masks" and "dma ops" from platform device to rvdev Device, but that's not enough, and I tried to fix this but I failed. So I have to rewrite these codes and pass platform device to "vring & rpmsg" drivers. The last problem both exist whether if I enable iommu or not. We have a memory offset between "linux" and subsystem in our "SOC" as I mentioned before. And if I use "dma-ranges" attribute in devicetree, and dma api will correct the offset in allocating and mapping process. But it is not happened. In function "vring_map_one_sg", the dma operation was skipped!! (virtio_ring.c) Cause "vq->use_dma_api" flag was not set in the initialize function witch returned by function "vring_use_dma_api". (They said it should be "quirk" if dma api was used in vring. I don’t understand. And if users do need this function, I should set VIRTIO_F_ACCESS_PLATFORM flag which is 33bit in the virtio feature flags, But the feature flags in resource table is 32bit length!) I do not know how to handle this and this "offset" should be transparent for subsystem right? Cause the memory could be changed in the next generation of our "SOC". That is all the problem I've got in our project. Very appreciate if you have some comments for these. Best Zichar ZEKU 信息安全声明：本邮件包含信息归发件人所在组织ZEKU所有。 禁止任何人在未经授权的情况下以任何形式（包括但不限于全部或部分披露、复制或传播）使用包含的信息。若您错收了本邮件，请立即电话或邮件通知发件人，并删除本邮件及附件。 Information Security Notice: The information contained in this mail is solely property of the sender's organization ZEKU. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.
