[Letux-kernel] DMA driver (was Re: [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel)

[H. Nikolaus Schaller]

Hi Paul,

> Am 16.01.2021 um 19:10 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Friday, 15 January 2021 22:23:52 CET Dr. H. Nikolaus Schaller wrote:
>> Would  you have or know some sample Code?
> 
> Sorry not to reply to this before now, but I did look around for some 
> convenient ways of initiating memory-to-memory DMA transfers from user space 
> in Linux, but it doesn't seem like something that can be easily done (and when 
> people have asked, they get the usual treatment of being asked in response 
> about what they "really want to do").

Well, my idea is not to trigger it from user-space by existing or new /sys or /dev
interfaces. But have some very simple drivers/misc/debug-dma.c that does in its probe()
function:

* allocate some private memory and make it accessible to DMA
* fill it randomly
* request the DMA subsystem through kernel-API to copy first half to second
* verify that both are the same or report issues
* release everything
* fail (e.g. with -EINVAL)
* no automatic load of the kernel module

If we modprobe this driver it will run (and fail) and allow to analyse what
happens by adding printk() into the jz4780 dma driver or by using devemem2
to inspect the registers of the controller.

Maybe it can be done by this API:

https://elixir.bootlin.com/linux/v5.11-rc3/source/Documentation/core-api/dma-api-howto.rst
https://elixir.bootlin.com/linux/v5.11-rc3/source/Documentation/core-api/dma-api.rst

But I understood that it mainly describes how a driver can map DMA but I have
no idea how to trigger DMA by software. Maybe it works only by hardware trigger?

> 
> I guess that some kind of driver exposing the mechanism as a device could be 
> feasible, but it may be more useful for me to review the code again and look 
> for other obvious faults. Of course, the MMC driver doesn't rely on working 
> DMA, so there is no immediate need for it to work.

Yes and MMC speed is not extremely slow.

What limits speed dramatically is our scheduling clock. I have tried to
run the sysbench also for the jz4730. It starts but is not yet finished
after half an hour. This is much slower than the slowest ARM in the comparison.
And way slower than the jz4780 (139 / 69 seconds). I would have accepted
5 minutes...

So process and thread scheduling is slow.

The serial console echoes characters back and the heartbeat LED is 
blinking as well as the cursor on LCD.

All this corresponds to quite slow boot.

BR,
Nikolaus