Message-ID: <VI1PR04MB4543694861C3452433C9D956892C0@VI1PR04MB4543.eurprd04.prod.outlook.com>
Date:   Mon, 8 Apr 2019 10:18:33 +0000
From:   Robin Gong <yibin.gong@....com>
To:     Igor Plyatov <plyatov@...il.com>
CC:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Fabio Estevam <festevam@...il.com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Mark Brown <broonie@...nel.org>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        Vinod Koul <vkoul@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Andy Duan <fugang.duan@....com>, Han Xu <han.xu@....com>,
        Clark Wang <xiaoning.wang@....com>
Subject: RE: Issues with i.MX SPI DMA transfers

> -----Original Message-----
> From: Igor Plyatov <plyatov@...il.com>
> Sent: 2019年4月3日 23:51
> To: Robin Gong <yibin.gong@....com>
> Cc: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>;
> linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> linux-spi@...r.kernel.org; dl-linux-imx <linux-imx@....com>; Fabio Estevam
> <festevam@...il.com>; Pengutronix Kernel Team <kernel@...gutronix.de>;
> Sascha Hauer <s.hauer@...gutronix.de>; Shawn Guo
> <shawnguo@...nel.org>; Mark Brown <broonie@...nel.org>;
> dmaengine@...r.kernel.org; Vinod Koul <vkoul@...nel.org>; Dan Williams
> <dan.j.williams@...el.com>; Andy Duan <fugang.duan@....com>; Han Xu
> <han.xu@....com>; Clark Wang <xiaoning.wang@....com>
> Subject: Re: Issues with i.MX SPI DMA transfers
> 
> Dear Robin,
> 
> 
> > Please apply the attached patch which is based on linux-next commit
> > 05d08e2995cbe6efdb993482ee0d38a77040861a.
> > 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?
Okay, now I can understand why it didn't not work in your side with sdma
from linux-firmware, because the workaround of ERR009165 is only fixed in 
AIPS ram script with simulating PIO in XCH mode instead of SMC mode, but not fixed
In SHP script which used by Sascha's rom patch dd4b487b32a3. 
Sorry, I'm not very clear about Sascha's patch which seems the same as ERR009165. But
at least, ecspi could work with app_2_mcu/mcu_2_app script, not 'must' be used with
shp_2_mcu/mcu_2_shp, because SPBA is also located in AIPS bus, please refer to the
below information from RM. So I am afraid Sascha's patch may not solid.
"A.3.1.6 app_2_mcu
This generic script is used to transfer data from a 8, 16, 24 or 32-bit peripheral connected
to the AIPS accessed through the Periphera DMA of SDMA, to memories accessed by
the BurstDMA (External memories)."


> 
> "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.
I could reproduce your issue as below whatever with my patches for ERR009165 or not, so
that's a new issue since it's only exist on ecspi5. Software is the same on all ecspi
port, so it's seems a hardware issue, I will involve design team to look into it. For now,
suggest you using other ecspi port if you can.

./spidev_test -D /dev/spidev4.0 -s 20000000 -b 8 -S 64 -I 100
spi mode: 0x20
bits per word: 8
max speed: 20000000 Hz (20000 KHz)


transfer error !
TX | E1 51 24 E9 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53 F6  |.Q$...<..Wb.pS.......zjFZ.0>..S.|
TX | 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE 71  |.w..T..[s.k.C`i!}..J........pl.q|
RX | E1 51 24 E9 F3 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53  |.Q$....<..Wb.pS.......zjFZ.0>..S|
RX | F6 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE  |..w..T..[s.k.C`i!}..J........pl.|
> 
> 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 IMX_DMATYPE_.. DMA_PRIO_..>;
> 
> 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 about
> this?
Yes, that's mean dma event ID, you could find in "Table 3-2. SDMA event mapping"
from RM.
> 
> Does second digit means "enum sdma_peripheral_type"?
> 
> Does third digit means "enum imx_dma_prio"?
Yes.
> 
> 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.
IMX_DMATYPE_CSPI use AIPS script, IMX_DMATYPE_CSPI_SP use SPBA script which 
SDMA could access peripherals on SPBA directly, AIPS script could be used by all peripherals
since only few peripherals on SPBA but SPBA script is more efficiency because of short path.

> 
> Best wishes.
> --
> Igor Plyatov

Powered by blists - more mailing lists