Hi Vidyas,
Thanks for the detailed explanation.
Our application requires 3 kinds of memory (PCIe, Kernel and Physical).
Since there is no IOMMU on the PC, the PCIe address is the same as the physical address.
Also, in TX2, because there was a problem with SMMU and it was disabled, we explicitly assigned PCIe address to Physical.
However, there is a mismatch in the write / read operation of the remote DMA, a performance / addressing problem is suspected, we plan to use an API to calculate the physical address instead of assigning PCIe address to it.
Here is the snippet of our user application for your reference:
// Allocate a physical memory block for the Ping-Pong communication
local.memSize = PINGPONG_DATA_SIZE;
status = sblib_AllocMemory( hDrv, local.memSize, &local.memPhysAdrs, &local.memBusAdrs );
if( status != SRLIB_NO_ERROR ){
printf("Physical Memory Allocation Failed!!!\n");
goto PP_ERROR;
}
// Map a physical memory block to virtual space
status = sblib_MapMemory( hDrv, local.memPhysAdrs, local.memSize, (PVOID*)&local.hSharedMemory, SREB_MM_NONCACHED );
if( status != SRLIB_NO_ERROR ){
printf("Virtual Memory Mapping Failed!!!\n");
goto PP_ERROR;
}
// DMA Write
status = sblib_SrioMemDmaWriteRaw( hDrv,
DMA_WAIT_COMPLETION,
partner.devId,
PINGPONG_DMA_CH_0,
local.memBusSrc,
partner.memBusAdrs,
local.memSize,
0);
Also, in order to use the custom driver and application instead of the tsi721_mport driver, we modified the configuration file as follows:
arch/arm64/configs/tegra18_defconfig
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_TSI721=n
Before modifying the config file, from the lsmod log, noticed that the rapidio driver was used by the tsi721_mport driver.
However, after these changes, the rapidio driver is not listed in the lsmod log.
I wonder if this will cause DMA write / read problems.
Do I need to link my custom driver to rapidio before building the kernel?
Thanks in advance !!