HostDMA/EMIFA basic driver

[vanasoft23]

I implemented a very bare bones IPC between CPU and DSP.

Key points:

• I wanted to make sure it works first, so I used HostDMA in stop mode, ofcourse, autobuffer mode is more preferable because the host wouldn't need to re-configure after each FIFO transfer.

• Took lot's of effort, but could not find / manage to trigger an IRQ host side for the HOST_ACK (also known as FRDY/HRDY) pin, so HostDMA runs in acknowledge mode. For sake of efficiency, this sucks. Would be great to verify in ghidra if E2 firmware runs HostDMA in acknowledge or interrupt mode.

• EMIFA timing has yet to be calculated and adjusted, but it may be best to pull the configuration straight from ghidra; see if it writes to 0x68000010 (EMIFAWaitTimingConfig, CE2CFG register).

• Would it be possible setting up a DMA channel on the host side aswell using the EDMA3 peripheral? That would bring us closer to the "shared memory illusion" you have talked about before. Currently, from the host side, the CPU still has to perform reads and writes in loops, in fact, the process is blocking!!! Maybe I'm a driver dev noob lol

• Next step in abstraction would be writing a device API layer on top of the peripheral code a command queue. Currently if the bus is busy, it just returns an error status.

• Code requires an even buffer size, since the FIFO can never transfer a single word in burst mode. My opinion is that the best solution is to have the future device API on top of this only accept 32-bit buffers, as this would avoid complicating the peripheral code.

• Without atomic MMR writes, I managed to add some prevention of bus contention, but more thorough testing is be needed to verify it's robustness

Learnt a lot from this ordeal but I am well aware that I probably made a lot of mistakes, but for what it is, it does seem to work properly. Pull the code and see for yourself --- look at per_emifa.c and per_hostdma.c

Cheers, 🔊Max꩜