Re: Issues with i.MX SPI DMA transfers
From: Igor Plyatov
Date: Wed Apr 03 2019 - 11:51:35 EST
This is a multi-part message in MIME format.
Please apply the attached patch which is based on linux-next commit
Please notice it has already contained two sdma patches revert - "ad0d92d7ba6a" and "25aaa75df1e6"
1) Yours source code is same as mine with exception of SDMA description
for eCSPI in Device Tree.
I have changed Device Tree for i.MX6Q/DL as in attached patch and
finally SPI interfaces operate more or less.
My patch revert back patches df07101e1c4a29e820df02f9989a066988b160e6
and dd4b487b32a3571fdcc66062e661e3a3e360e35b. It is strange, because
they are merged into mainline while ago. Maybe they are valid for some
specific variant of i.MX SOC?
"More or less" means I have come to state described in first e-mail of
this e-mail thread. Byte duplication (ERR009165) happens very often for
eCSPI5 interface operating through DMA.
1.1. Interface under test is eCSPI1 or eCSPI5;
1.2. Four exemplars of "burn-neon" (CPU burn) executes in background to
have 100% load for all 4 CPU cores (source code taken from
1.3. PC has running "ping -f embedded_device" to have network activity
around 1 MiB/s Rx and Tx;
1.4. One exemplar of "spidev_test -D /dev/spidevX.0 -s FREQUENCY -b 8 -S
512 -I 1000000 -l" executes at different frequencies;
Test Results for eCSPI1:
21 MHzÂÂÂ - success;
20 MHzÂÂÂ - success;
16 MHzÂÂÂ - success;
Â8 MHzÂÂÂ - success;
Test Results for eCSPI5:
21 MHzÂÂÂ - failed;
20 MHzÂÂÂ - failed;
19 MHzÂÂÂ - failed;
12 MHzÂÂÂ - failed;
11 MHzÂÂÂ - failed;
10 MHzÂÂÂ - failed;
Â9 MHzÂÂÂ - failed;
Â8 MHzÂÂÂ - failed;
Â7 MHzÂÂÂ - failed;
Â6 MHzÂÂÂ - failed;
Â5 MHzÂÂÂ - failed;
Â4 MHzÂÂÂ - success.
Maybe it is worth to dump content of registers for eCSPI1 and eCSPI5 to
compare them? I can do this if you will describe how to make it.
Maybe I'm wrong, but I suppose incorrect clock source for eCSPI5. Looks
like it is worth to check correctness of driver "clk-imx6q.c" or
something else responsible for eCSPI5 clock.
2) I want to improve description and replace magic numbers by constants
in Device Tree for SDMA. I mean strings like "dmas = <&sdma 11 7 1>,
<&sdma 12 7 2>;"?
So, finally Device Tree will have strings like
dmas = <&sdma SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, <&sdma SOME_DEF_B
I think, this will stop black magic manipulations for SDMA in Device
Tree, by various developers.
Does first digit means "DMA request/event ID"? Where to find more info
Does second digit means "enum sdma_peripheral_type"?
Does third digit means "enum imx_dma_prio"?
Where can I find description of difference between IMX_DMATYPE_CSPI (MCU
domain CSPI) and IMX_DMATYPE_CSPI_SP (Shared CSPI)? Googling does not
help too much.