search

riscvarchive / riscv-linux

RISC-V Linux Port
606 stars 210 forks source link

Linux 4.1.y dma #30

Closed jameyhicks closed 8 years ago

jameyhicks commented 8 years ago

These changes add RISC-V support for dma-mapping, enabling use of device drivers depending on these capabilities.

a0u commented 8 years ago

Hi Jamey,

Thanks for submitting this pull request.

Would you mind explaining a little about how the DMA support is implemented and how you are using it? Since x86 is normally not the cleanest architecture to copy, I'm trying to distill the essence of these changes to see if we can simplify the code and prune the cruft, if any.

jameyhicks commented 8 years ago

Hi Albert,

In our own work, we generally develop user-mode drivers for hardware accelerators, but I want to be able to reuse hardware IP and associated device drivers with as few changes as possible, assuming they use standard Linux kernel interfaces.

I agree that x86 is not the cleanest architecture, but x86 Linux is pretty much the reference implementation. In these changes, I looked at asm-generic, x86, and arm and tried to copy the simplest implementation in order to get the pieces in place to use an existing device driver, e.g., for the Xilinx ethernet MAC and PHY.

I agree that we should minimize the cruft. I cut out some in the process of adapting these changes, e.g., removing ISA bus references.

Looking at the different Linux architectures, I focused on x86 and ARM because those are both very widely used and I have experience with them. I think for riscv it would be better if we could avoid the need for subarchitectures. Linux arch/x86 implements both 32-bit and 64-bit in one set of sources.

I think it would be a good idea to involve upstream maintainers as soon as possible, to get their feedback on the approach.

I am testing via spike attached to a vc707 implementing the peripherals: parallel NOR Flash, Xilinx AXI DMA, Xilinx AXI Ethernet Subsystem. To that end, I have another change to spike enabling the device extension to register a memory allocator. In this case, to enable DMA from the FPGA to be coherent with spike's simulated processor memory.

Cheers, Jamey

On Fri, Jan 22, 2016 at 2:29 AM Albert Ou notifications@github.com wrote:

Hi Jamey,

Thanks for submitting this pull request.

Would you mind explaining a little about how the DMA support is implemented and how you are using it? Since x86 is normally not the cleanest architecture to copy, I'm trying to distill the essence of these changes to see if we can simplify the code and prune the cruft, if any.

— Reply to this email directly or view it on GitHub https://github.com/riscv/riscv-linux/pull/30#issuecomment-173833473.

terpstra commented 8 years ago

I only just noticed this pull request... after I wastefully re-ported DMA for PCIe. That said, I do not think this patch incorporates DMA correctly. Please see commit https://github.com/riscv/riscv-linux/commit/133f8050925fbf5bf117714c73809c26c173e0a7 for how I think it should be done. There is no need to reimplement most of dma-mapping.h and dma-ops.c. Instead, we should use the generic "noops" version. Furthermore, this pull request mixes in IRQs with DMA... and those IRQs are pre-PLIC style IRQs. I propose to close this PR without merging it...

jameyhicks commented 8 years ago

It would make sense to split the IRQ changes from the DMA changes. At the time I submitted and updated this pull request, the PLIC spec was not yet available. Actually, even now the privileged 1.9 spec still does not provide a complete enough description of the PLIC for me to add kernel support for it.

Although I prefer cache-coherent DMA, the spec does not require DMA to be cache-coherent, so I am not sure that we can use the noops version of DMA. However, if the DMA mapping ops can be simpler I am all for it.