hw: Adds support for iDMA with configurable frontend(s) (desc64 and/or reg64)

[mineiwik]

This PR adds support for iDMA with configurable frontend(s). The supported frontends are:

• reg64: Frontend that can be configured through registers, either 1d and 2d frontend can be activated
• desc64: Frontend that can be configured through descriptors and thus is optimal for use with the Linux kernel through the DMA Engine API

Adapt cheshire_cfg_t

Added new configuration parameters to enable/disable frontends at one's liking. The new configuration options are:

• bit DmaConfFrontendDesc64: Enables the desc64 iDMA frontend when set
• bit DmaConfFrontendReg64: Enables the reg64 iDMA frontend when set
  • bit DmaConfFrontendReg64TwoD: Uses 2d frontend when set, otherwise 1d

Request arbiter

When we have multiple frontends instantiated, then we need some sort of arbiter that selects an iDMA request and forwards it to the backend. To do that, a new module has been added to the iDMA wrapper file called cheshire_idma_fe_arb.
Initially, the arbiter uses the rr_arb_tree (from common cell lib) arbiter module to select a valid frontend request. However, once a request from a frontend is selected, the arbiter forwards consecutive requests only from the selected frontend as long as the frontend keeps sending new requests before the iDMA backend responses to the latest request.

Testing

The implementation has been simulated and tested for both frontends. Furthermore, the desc64 frontend has been tested on Linux (Genesys2 hardware) using dmatest and an appropriate driver¹.

Footnotes

1. To include the iDMA Linux driver, a pull request has been opened in the CVA6-SDK repository, which should be merged before this PR, such that the submodule reference can be updated. ↩

[Jorgebrihu]

Hi,
I am using this pull request in order to use the descriptor-based frontend of the iDMA and its linux driver.
However, I am generating the linux image with the changes of the CVA6-SDK provided in this pr, but the idma driver does not seem to be built in the kernel.
When booting linux I can see a message saying:

bind node dma-controller@01000000 
   - attempt to match compatible string 'eth,idma-desc' 
No match for node 'dma-controller@01000000' 

The node is in the device tree, but there is not a driver compatible with it.
Looking at the file "configs/linux64_defconfig", looks like the driver should be built in the kernel.

I have generated the iis-idma.ko and loaded it, but lots of symbols are missing:

# insmod iis-idma.ko
[  603.623833] iis_idma: loading out-of-tree module taints kernel.
[  603.649257] iis_idma: Unknown symbol vchan_init (err -2)
[  603.664333] iis_idma: Unknown symbol of_dma_controller_free (err -2)
[  603.681227] iis_idma: Unknown symbol dma_async_device_unregister (err -2)
[  603.700652] iis_idma: Unknown symbol vchan_dma_desc_free_list (err -2)
[  603.718362] iis_idma: Unknown symbol of_dma_simple_xlate (err -2)
[  603.734438] iis_idma: Unknown symbol vchan_tx_desc_free (err -2)
[  603.751063] iis_idma: Unknown symbol of_dma_controller_register (err -2)
[  603.768620] iis_idma: Unknown symbol dma_async_device_register (err -2)
[  603.785654] iis_idma: Unknown symbol dma_async_tx_descriptor_init (err -2)
[  603.804404] iis_idma: Unknown symbol vchan_find_desc (err -2)
[  603.820063] iis_idma: Unknown symbol vchan_tx_submit (err -2)

Seems like nothing related to the idma driver has been built.
Did someone come across this issue and could provide me any hint?

Thanks

EDIT
iis-idma driver is loadable, but the symbols provided by of-dma.c, dmaengine.c and virt-dma.c should be already built in the kernel.
When checking if the symbols are in the generated vmlinux file by running for example:
nm -n vmlinux | grep vchan_init

I get the following output:

ffffffe000413dfe T vchan_init  
ffffffe000cfe8f0 r __ksymtab_vchan_init  
ffffffe000d0d08d r __kstrtab_vchan_init  
ffffffe000d1317e r __kstrtabns_vchan_init

So I think they are built in the kernel. However, when booting that image and executing:
cat /proc/kallsyms | grep vchan_init

I get no output. As far as I know, I should get the symbol just as I got it from the image. Am I right?

[Jorgebrihu]

I manage to insmod the iis-idma driver. I am not sure yet what was going on and why the symbols needed were missing. I will get back to that later.
However, could you provide a basic code or instructions about how to properly launch a simple transfer from userspace using the driver?

Thanks

[mineiwik]

Hi,
I apologize for the delayed reply. The referenced CVA6-SDK branch currently only contains the driver as a loadable kernel module. Some of the symbols you mentioned above were missing because the kernel does not export them and are only accessible to in-tree modules. To resolve that, I also extracted the header files (dmaengine.h & virt-dma.h) containing those symbols, such that the driver can be built and used/loaded out-of-tree.
Concerning the user-space program, there currently does not exist one, as I used the kernel internal DMA testing suite to issue DMA transfers from user-space using modifiable parameters. Nevertheless, I am planning to adapt the driver to have an ioctl interface and to also include a user-space example. Additionally, I will update the cva6-sdk branch to also include the driver in-tree through kernel patches.
The setup is that way because it made hardware and driver testing simpler.

[Jorgebrihu]

Hi,
thanks for the answer. I saw that the driver does not have an ioctl interface yet. For the project I am working on I need to be able to use the iDMA from the user-space. I have no experience in making linux drivers, but I will try to make a basic one to be able to move forward. I will definitely keep an eye on this pull request to see the driver you develop.
Thanks again

[mineiwik]

Hi @Jorgebrihu
The latest changes in the linked cva6-sdk repo introduced a proxy driver that has an IOCTL interface, which can be used from user-space to issue iDMA transfers. The transfers can be configured through a struct allowing three different modes which I will detail later on. I have also added three example applications that use different variants of src/dst buffers. By default, the two drivers: idma-engine (previously called iis-idma) and idma-proxy are compiled as loadable modules in the kernel, allowing to use newer versions easily. Note that the idma-engine driver should be loaded first, otherwise the proxy driver will not find any usable channels.

The three modes are:

• IDMA_KERNEL_BUFFER: (see example-kernel-buffer.c) the user can mmap a kernel buffer to user-space and read/write data to it. The iDMA transfer addresses are the physical addresses of the (physically contiguous) kernel buffers.
• IDMA_COPY_BUFFER: (see example-copy-buffer.c) Copy user-space buffers to temporarily allocated kernel-space buffers before/after the transfer. The iDMA transfer addresses are the physical addresses of the (physically contiguous) temporary kernel buffers. This has the benefit over the previous mode that the buffers can be larger than what is defined in the driver.
• IDMA_USER_DIRECT: (see example-user-direct.c) Use user-space mapping to get physical addresses of the buffers. The user has to guarantee that the buffers are physically contiguous.

The proxy driver and the example applications are located in drivers/idma-proxy and everything can be built out-of-tree by invoking make clean all deploy. The last target copies the binaries into the rootfs.

Concerning the missing symbols you mentioned above when loading the iis-idma aka idma-engine out-of-tree driver, I think I have found the root cause. For in-tree drivers (modules or built-in) the driver dependencies are automatically handled. However, for out-of-tree modules that are inserted with insmod they are not. You can see the dependencies for the drivers with modinfo idma-engine.ko. In my case, the dependencies are virt-dma and modprobe virt-dma loads the module in question and resolves the missing symbols.

I hope this helps

[Jorgebrihu]

Hi
Sorry for the late reply and thanks a lot for the quick response regarding the linux driver. I could not get to it before, until this week.
The case is that I want to read and write to an accelerator to specific memory addresses. For the moment, I have changed the ioctl and added new cases, so I can move data to and from it and that worked.
Thanks again for the work made