New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers: dma: add dma_emul driver and test coverage #58375
drivers: dma: add dma_emul driver and test coverage #58375
Conversation
88c8907
to
95fb399
Compare
95fb399
to
ffcd5fb
Compare
|
ffcd5fb
to
5886891
Compare
|
I anticipate a few rounds to figure out any loose ends with the implementation. Additionally, I may have found a couple of gaps here and there with the current DMA API and testsuite that could be closed. |
2dcfaff
to
4d462aa
Compare
|
abfcc29
to
b1a01d8
Compare
|
b1a01d8
to
9ec357b
Compare
@teburd - thanks for taking another look.
Yes, exactly. There will be some flexibility in terms of backends and some customizable behaviour to an extent too.
That's a good question, and to be honest, not one that I've considered yet, but definitely agree that it varies wildly. It might be easiest to tackle specific peripherals / interconnects on a case-by-case basis. SPI is on the radar, but my MVP in the next while will be PCIe DMA (host to device, device to host, memory to memory), and I would be looking to emulate something close to the "edu" device in Qemu. It was touched upon in Zephyr here, with additional info here and here. The "edu" device mainly has a host-side specification, so there is some flexibility for device-side (where Zephyr would mainly be "running"). It will be a fair bit of work to get there, but we will have additional collaboration within the community (I added a bunch of AntMicro folks to review very deliberately 😁, cc @mgielda) |
I'll rebase this just to make sure it gets back into a mergeable state. We may be able to begin working on it in the near term again. |
|
c11652a
to
0865979
Compare
Needs a rebase |
0865979
to
c412e77
Compare
|
c412e77
to
f358a23
Compare
rebased again |
I think I've covered the topic of how the DMA API isn't necessarily meant to be a common behavioral abstraction but a union of functionality in the DMA API docs now, so approving |
Many driver APIs are opting to provide an `emul` driver implementation that can be used for a number of purposes. - providing an ideal / model driver for reference - configurable backends - seamless integration with device tree - support for native posix, qemu, and any other board - fast regression testing of app and library code Provide an initial set of bindings for `zephyr,dma-emul` devices. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
f358a23
to
768c9ec
Compare
@teburd - can you please re-ack? |
Add an emulated DMA driver. Emulation drivers are great to have for each driver API for multiple reasons: - providing an ideal / model driver for reference - potential for configurable backend support - seamless integration with device tree - multi-instance, etc, for all supported boards - fast regression testing of app and library code Since many other drivers and lbraries depend on DMA, this might help us to increase test coverage. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
Like other driver APIs, we can add an `emul` variant to `native_posix` and `native_posix_64` that should allow us to simplify applilcation and library development and to also increase test coverage in CI. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
Add support for testing the `dma_emul` driver which simply uses software emulation (i.e. asynchronous memcpy in a workqueue) for performing DMA operations. Signed-off-by: Christopher Friedt <cfriedt@meta.com>
768c9ec
to
ad012d3
Compare
|
4 commits (please see each commit message for details)
It's pretty basic right now, but the intention is to support interfaces other than simple
memcpy()
via a backend API. With that, we should be able to use e.g. TCP or UDP sockets, shared memory, etc.Additionally, some drivers (such as PCIe) often depend on DMA to be present, so this has the potential to open up ZTest to areas that have traditionally not been very testable. This could, for example, pair pretty well with the recent NVMe API.
Fixes #57129