* RE: Issues with i.MX SPI DMA transfers
From: Robin Gong @ 2019-04-09 3:26 UTC (permalink / raw)
To: Igor Plyatov, Uwe Kleine-König
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
In-Reply-To: <VI1PR04MB454305A56372466A38E9F81989560@VI1PR04MB4543.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 3911 bytes --]
Hi Igor,
Please have a try with the attached patches, and revert 25aaa75df1e6, ad0d92d7ba6a
, dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx thresh should be set to 0 ,
now no failure caught on ecspi5.
> -----Original Message-----
> From: Robin Gong
> Sent: 2019年4月2日 16:33
> To: 'Igor Plyatov' <plyatov@gmail.com>; Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> Subject: RE: Issues with i.MX SPI DMA transfers
>
> > -----Original Message-----
> > From: Igor Plyatov <plyatov@gmail.com>
> > Sent: 2019年4月2日 15:20
> > To: Robin Gong <yibin.gong@nxp.com>; Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de>
> > Cc: linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org;
> > linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio
> > Estevam <festevam@gmail.com>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Sascha Hauer <s.hauer@pengutronix.de>; Shawn
> > Guo <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> > dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> > <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> > <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> > Subject: Re: Issues with i.MX SPI DMA transfers
> >
> > Dear Robin Gong,
> >
> >
> > >> Sorry...below another sdma patch(ad0d92d7ba6a) need to be reverted,
> > >> because spi driver may dynamically change burst length.
> >
> >
> > now I have reverted patch ad0d92d7ba6a.
> >
> > Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
> > 0002-spi-spi-imx-fix-ERR009165.patch are applied.
> >
> >
> > Kernel log show messages
> >
> > [ 29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3 [
> > 29.238595] spi_imx 2008000.spi: probed [ 29.242802] spi_imx
> > 200c000.spi: probed [ 29.245217] spi_imx 2018000.spi: probed
> >
> > SPI DMA transfers still not work.
> >
> > If I test 32 byte transfers, then they work fine. But 64 byte
> > transfers fails always and I see error messages
> >
> > root@cr7:~# spidev_test -D /dev/spidev4.1 -s 1200000 -b 8 -S 64 -I 1
> > -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz) [
> > 423.686736] spi_master spi4: I/O Error in DMA RX [ 423.691392] spidev
> > spi4.1: SPI transfer failed: -110 [ 423.696382] spi_master spi4:
> > failed to transfer one message from queue can't send spi message:
> > Connection timed out Aborted (core dumped)
> >
> > I suppose, transfers shorter then 64 bytes made with help of PIO.
> >
> > Robin, is there any chance for you to find some time and look at this
> > issue again?
> I have quick test with spidev_test loopback, but didn't meet your error, Is your
> code the almost latest code in linux-next as mine?
>
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
> 48: 37 GPC 2 Level sdma
> -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 64 -I
> 1 -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz)
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
> 48: 43 GPC 2 Level sdma
> ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 512 -I 1 -l spi mode: 0x20 bits
> per word: 8 max speed: 1200000 Hz (1200 KHz)
> total: tx 0.5KB, rx 0.5KB
> >
> > Best wishes.
> > --
> > Igor Plyatov
[-- Attachment #2: 0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch --]
[-- Type: application/octet-stream, Size: 1369 bytes --]
From fbdf4153b4790a43a7396b5c78a848b4d0735f80 Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Thu, 28 Mar 2019 16:36:12 +0800
Subject: [PATCH 5/6] dma: engine: imx-sdma: add mcu_2_ecspi script
Add mcu_2_ecspi script to fix ecspi errata ERR009165.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 3 +++
include/linux/platform_data/dma-imx-sdma.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index adc82d9..0cc52db 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -907,6 +907,9 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
break;
case IMX_DMATYPE_CSPI:
+ per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+ break;
case IMX_DMATYPE_EXT:
case IMX_DMATYPE_SSI:
case IMX_DMATYPE_SAI:
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 6eaa53c..f794fee 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -51,6 +51,7 @@ struct sdma_script_start_addrs {
/* End of v2 array */
s32 zcanfd_2_mcu_addr;
s32 zqspi_2_mcu_addr;
+ s32 mcu_2_ecspi_addr;
/* End of v3 array */
};
--
2.7.4
[-- Attachment #3: 0006-spi-spi-imx-fix-ERR009165.patch --]
[-- Type: application/octet-stream, Size: 1635 bytes --]
From aa198c3265fb54d42715c5fa4c25d15a73ad934c Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Thu, 28 Mar 2019 16:38:13 +0800
Subject: [PATCH 6/6] spi: spi-imx: fix ERR009165
Change to XCH mode even in dma mode, please refer to below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1e..04af84d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
spi_imx->spi_bus_clk = clk;
+ /* ERR009165: work in XHC mode as PIO */
if (spi_imx->usedma)
- ctrl |= MX51_ECSPI_CTRL_SMC;
+ ctrl &= ~MX51_ECSPI_CTRL_SMC;
writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
@@ -617,7 +618,6 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
* and enable DMA request.
*/
writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
- MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1265,10 +1265,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
{
int ret;
- /* use pio mode for i.mx6dl chip TKT238285 */
- if (of_machine_is_compatible("fsl,imx6dl"))
- return 0;
-
spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
/* Prepare for TX DMA: */
--
2.7.4
^ permalink raw reply related
* RE: Issues with i.MX SPI DMA transfers
From: Robin Gong @ 2019-04-08 10:18 UTC (permalink / raw)
To: Igor Plyatov
Cc: Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
In-Reply-To: <fbb4850d-f63f-d384-1a85-1f4c5c077af6@gmail.com>
> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年4月3日 23:51
> To: Robin Gong <yibin.gong@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.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
^ permalink raw reply
* Issues with i.MX SPI DMA transfers
From: Robin Gong @ 2019-04-08 10:18 UTC (permalink / raw)
To: Igor Plyatov
Cc: Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年4月3日 23:51
> To: Robin Gong <yibin.gong@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.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
^ permalink raw reply
* [PATCH v2] mfd: intel-lpss: Set the device in reset state when init
From: Binbin Wu @ 2019-04-08 8:09 UTC (permalink / raw)
To: rjw, linux-pm, gregkh, lee.jones, mika.westerberg, linux-kernel,
dmaengine, andriy.shevchenko
Cc: binbin.wu
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
<IRQ>
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
handlers:
[<000000000d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Changelog v2:
- correct the subject line by adding "mfd: "
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
--
2.7.4
^ permalink raw reply related
* [v2] mfd: intel-lpss: Set the device in reset state when init
From: Binbin Wu @ 2019-04-08 8:09 UTC (permalink / raw)
To: rjw, linux-pm, gregkh, lee.jones, mika.westerberg, linux-kernel,
dmaengine, andriy.shevchenko
Cc: binbin.wu
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
<IRQ>
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
handlers:
[<000000000d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Changelog v2:
- correct the subject line by adding "mfd: "
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
^ permalink raw reply related
* RE: [PATCH] intel-lpss: Set the device in reset state when init
From: Wu, Binbin @ 2019-04-08 8:05 UTC (permalink / raw)
To: Mika Westerberg
Cc: rjw@rjwysocki.net, linux-pm@vger.kernel.org,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
andriy.shevchenko@linux.intel.com
In-Reply-To: <20190408074302.GD3622@lahna.fi.intel.com>
Hi Mika,
Will correct the title line in the next version.
Thanks.
--
Best wishes,
Binbin
> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> Sent: Monday, April 8, 2019 3:43 PM
> To: Wu, Binbin <binbin.wu@intel.com>
> Cc: rjw@rjwysocki.net; linux-pm@vger.kernel.org;
> gregkh@linuxfoundation.org; lee.jones@linaro.org; linux-
> kernel@vger.kernel.org; dmaengine@vger.kernel.org;
> andriy.shevchenko@linux.intel.com
> Subject: Re: [PATCH] intel-lpss: Set the device in reset state when init
>
> On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote:
> > In virtualized setup, when system reboots due to warm reset interrupt
> > storm is seen.
> >
> > Call Trace:
> > <IRQ>
> > dump_stack+0x70/0xa5
> > __report_bad_irq+0x2e/0xc0
> > note_interrupt+0x248/0x290
> > ? add_interrupt_randomness+0x30/0x220
> > handle_irq_event_percpu+0x54/0x80
> > handle_irq_event+0x39/0x60
> > handle_fasteoi_irq+0x91/0x150
> > handle_irq+0x108/0x180
> > do_IRQ+0x52/0xf0
> > common_interrupt+0xf/0xf
> > </IRQ>
> > RIP: 0033:0x76fc2cfabc1d
> > Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
> > 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48>
> > 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
> > 24
> > RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
> > RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
> > RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
> > RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
> > R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
> > R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
> > handlers:
> > [<000000000d3fa913>] idma64_irq
> > Disabling IRQ #27
> >
> > To avoid interrupt storm, set the device in reset state before
> > bringing out the device from reset state.
> >
> > Signed-off-by: Binbin Wu <binbin.wu@intel.com>
>
> I think the correct subject line should be:
>
> "mfd: intel-lpss: Set the device in reset state when init"
>
> Regardless of that,
>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* intel-lpss: Set the device in reset state when init
From: Binbin Wu @ 2019-04-08 8:05 UTC (permalink / raw)
To: Mika Westerberg
Cc: rjw@rjwysocki.net, linux-pm@vger.kernel.org,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
andriy.shevchenko@linux.intel.com
Hi Mika,
Will correct the title line in the next version.
Thanks.
---
Best wishes,
Binbin
> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> Sent: Monday, April 8, 2019 3:43 PM
> To: Wu, Binbin <binbin.wu@intel.com>
> Cc: rjw@rjwysocki.net; linux-pm@vger.kernel.org;
> gregkh@linuxfoundation.org; lee.jones@linaro.org; linux-
> kernel@vger.kernel.org; dmaengine@vger.kernel.org;
> andriy.shevchenko@linux.intel.com
> Subject: Re: [PATCH] intel-lpss: Set the device in reset state when init
>
> On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote:
> > In virtualized setup, when system reboots due to warm reset interrupt
> > storm is seen.
> >
> > Call Trace:
> > <IRQ>
> > dump_stack+0x70/0xa5
> > __report_bad_irq+0x2e/0xc0
> > note_interrupt+0x248/0x290
> > ? add_interrupt_randomness+0x30/0x220
> > handle_irq_event_percpu+0x54/0x80
> > handle_irq_event+0x39/0x60
> > handle_fasteoi_irq+0x91/0x150
> > handle_irq+0x108/0x180
> > do_IRQ+0x52/0xf0
> > common_interrupt+0xf/0xf
> > </IRQ>
> > RIP: 0033:0x76fc2cfabc1d
> > Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
> > 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48>
> > 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
> > 24
> > RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
> > RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
> > RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
> > RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
> > R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
> > R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
> > handlers:
> > [<000000000d3fa913>] idma64_irq
> > Disabling IRQ #27
> >
> > To avoid interrupt storm, set the device in reset state before
> > bringing out the device from reset state.
> >
> > Signed-off-by: Binbin Wu <binbin.wu@intel.com>
>
> I think the correct subject line should be:
>
> "mfd: intel-lpss: Set the device in reset state when init"
>
> Regardless of that,
>
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [PATCH] intel-lpss: Set the device in reset state when init
From: Mika Westerberg @ 2019-04-08 7:43 UTC (permalink / raw)
To: Binbin Wu
Cc: rjw, linux-pm, gregkh, lee.jones, linux-kernel, dmaengine,
andriy.shevchenko
In-Reply-To: <1554702118-20184-1-git-send-email-binbin.wu@intel.com>
On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote:
> In virtualized setup, when system reboots due to warm
> reset interrupt storm is seen.
>
> Call Trace:
> <IRQ>
> dump_stack+0x70/0xa5
> __report_bad_irq+0x2e/0xc0
> note_interrupt+0x248/0x290
> ? add_interrupt_randomness+0x30/0x220
> handle_irq_event_percpu+0x54/0x80
> handle_irq_event+0x39/0x60
> handle_fasteoi_irq+0x91/0x150
> handle_irq+0x108/0x180
> do_IRQ+0x52/0xf0
> common_interrupt+0xf/0xf
> </IRQ>
> RIP: 0033:0x76fc2cfabc1d
> Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
> 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
> <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
> 24
> RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
> RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
> RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
> RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
> R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
> R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
> handlers:
> [<000000000d3fa913>] idma64_irq
> Disabling IRQ #27
>
> To avoid interrupt storm, set the device in reset state
> before bringing out the device from reset state.
>
> Signed-off-by: Binbin Wu <binbin.wu@intel.com>
I think the correct subject line should be:
"mfd: intel-lpss: Set the device in reset state when init"
Regardless of that,
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* intel-lpss: Set the device in reset state when init
From: Mika Westerberg @ 2019-04-08 7:43 UTC (permalink / raw)
To: Binbin Wu
Cc: rjw, linux-pm, gregkh, lee.jones, linux-kernel, dmaengine,
andriy.shevchenko
On Mon, Apr 08, 2019 at 01:41:58PM +0800, Binbin Wu wrote:
> In virtualized setup, when system reboots due to warm
> reset interrupt storm is seen.
>
> Call Trace:
> <IRQ>
> dump_stack+0x70/0xa5
> __report_bad_irq+0x2e/0xc0
> note_interrupt+0x248/0x290
> ? add_interrupt_randomness+0x30/0x220
> handle_irq_event_percpu+0x54/0x80
> handle_irq_event+0x39/0x60
> handle_fasteoi_irq+0x91/0x150
> handle_irq+0x108/0x180
> do_IRQ+0x52/0xf0
> common_interrupt+0xf/0xf
> </IRQ>
> RIP: 0033:0x76fc2cfabc1d
> Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
> 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
> <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
> 24
> RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
> RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
> RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
> RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
> R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
> R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
> handlers:
> [<000000000d3fa913>] idma64_irq
> Disabling IRQ #27
>
> To avoid interrupt storm, set the device in reset state
> before bringing out the device from reset state.
>
> Signed-off-by: Binbin Wu <binbin.wu@intel.com>
I think the correct subject line should be:
"mfd: intel-lpss: Set the device in reset state when init"
Regardless of that,
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* [PATCH] intel-lpss: Set the device in reset state when init
From: Binbin Wu @ 2019-04-08 5:41 UTC (permalink / raw)
To: rjw, linux-pm, gregkh, lee.jones, mika.westerberg, linux-kernel,
dmaengine, andriy.shevchenko
Cc: binbin.wu
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
<IRQ>
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
handlers:
[<000000000d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
--
2.7.4
^ permalink raw reply related
* intel-lpss: Set the device in reset state when init
From: Binbin Wu @ 2019-04-08 5:41 UTC (permalink / raw)
To: rjw, linux-pm, gregkh, lee.jones, mika.westerberg, linux-kernel,
dmaengine, andriy.shevchenko
Cc: binbin.wu
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
<IRQ>
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
</IRQ>
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414
handlers:
[<000000000d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
^ permalink raw reply related
* dmaengine: bcm2835: Drop duplicate capability setting.
From: Stefan Wahren @ 2019-04-05 7:07 UTC (permalink / raw)
To: Michal Suchanek, bcm-kernel-feedback-list, dmaengine,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
Cc: Vinod Koul, Dan Williams, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Am 04.04.19 um 19:25 schrieb Michal Suchanek:
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Except of the point there is no commit log:
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/dma/bcm2835-dma.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index ec8a291d62ba..e38b19dd2895 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -891,7 +891,6 @@ static int bcm2835_dma_probe(struct platform_device *pdev)
> dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
> dma_cap_set(DMA_PRIVATE, od->ddev.cap_mask);
> dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask);
> - dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
> dma_cap_set(DMA_MEMCPY, od->ddev.cap_mask);
> od->ddev.device_alloc_chan_resources = bcm2835_dma_alloc_chan_resources;
> od->ddev.device_free_chan_resources = bcm2835_dma_free_chan_resources;
^ permalink raw reply
* dmaengine: bcm2835: Drop duplicate capability setting.
From: Michal Suchanek @ 2019-04-04 17:25 UTC (permalink / raw)
To: bcm-kernel-feedback-list, dmaengine, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
Cc: Michal Suchanek, Vinod Koul, Dan Williams, Eric Anholt,
Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
drivers/dma/bcm2835-dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index ec8a291d62ba..e38b19dd2895 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -891,7 +891,6 @@ static int bcm2835_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
dma_cap_set(DMA_PRIVATE, od->ddev.cap_mask);
dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask);
- dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
dma_cap_set(DMA_MEMCPY, od->ddev.cap_mask);
od->ddev.device_alloc_chan_resources = bcm2835_dma_alloc_chan_resources;
od->ddev.device_free_chan_resources = bcm2835_dma_free_chan_resources;
^ permalink raw reply related
* Issues with i.MX SPI DMA transfers
From: Igor Plyatov @ 2019-04-03 17:13 UTC (permalink / raw)
To: Robin Gong
Cc: Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
Dear Robin,
I have made additional tests on another exemplar of board with
absolutely same hardware.
The spidev_test failed on eCSPI2 and eCSPI5 interfaces, but works
successfully on eCSPI1 interface.
So, it looks, issue does not correspond to fixed interface number.
This is generic issue of i.MX6 SOC and hardly broken eCSPI interface
number can change from SOC chip to chip.
Do you have any idea how to improve situation with eCSPI in DMA mode?
Best wishes.
---
Igor Plyatov
^ permalink raw reply
* Issues with i.MX SPI DMA transfers
From: Igor Plyatov @ 2019-04-03 15:51 UTC (permalink / raw)
To: Robin Gong
Cc: Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org,
dl-linux-imx, Fabio Estevam, Pengutronix Kernel Team,
Sascha Hauer, Shawn Guo, Mark Brown, dmaengine@vger.kernel.org,
Vinod Koul, Dan Williams, Andy Duan, Han Xu, Clark Wang
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?
"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.
Test Conditions:
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
https://raw.githubusercontent.com/ssvb/cpuburn-arm/dd5c5ba58d2b0b23cfab4a286f9d3f5510000f20/cpuburn-a8.S
and https://hardwarebug.org/files/burn.S);
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
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?
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.
Best wishes.
---
Igor Plyatov
From 2aa277ff36998b805cec803b23d9c746a2a107b7 Mon Sep 17 00:00:00 2001
From: Igor Plyatov <plyatov@gmail.com>
Date: Wed, 3 Apr 2019 14:51:17 +0300
Subject: [PATCH] Bugfix for incorrect eCSPI SDMA numbers.
* This revert back commits df07101e1c4a29e820df02f9989a066988b160e6 and
dd4b487b32a3571fdcc66062e661e3a3e360e35b, because they lead to kernel
errors like
"spi_master spi4: I/O Error in DMA RX
spidev spi4.1: SPI transfer failed: -110."
Tested on i.MX6 Quad/DualLite SOC.
Signed-off-by: Igor Plyatov <plyatov@gmail.com>
---
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d038f4117024..7175898f854e 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -172,7 +172,7 @@
clocks = <&clks IMX6Q_CLK_ECSPI5>,
<&clks IMX6Q_CLK_ECSPI5>;
clock-names = "ipg", "per";
- dmas = <&sdma 11 8 1>, <&sdma 12 8 2>;
+ dmas = <&sdma 11 7 1>, <&sdma 12 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2eb4c779298b..36c48a18e39a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -338,7 +338,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI1>,
<&clks IMX6QDL_CLK_ECSPI1>;
clock-names = "ipg", "per";
- dmas = <&sdma 3 8 1>, <&sdma 4 8 2>;
+ dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -352,7 +352,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI2>,
<&clks IMX6QDL_CLK_ECSPI2>;
clock-names = "ipg", "per";
- dmas = <&sdma 5 8 1>, <&sdma 6 8 2>;
+ dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -366,7 +366,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI3>,
<&clks IMX6QDL_CLK_ECSPI3>;
clock-names = "ipg", "per";
- dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;
+ dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
@@ -380,7 +380,7 @@
clocks = <&clks IMX6QDL_CLK_ECSPI4>,
<&clks IMX6QDL_CLK_ECSPI4>;
clock-names = "ipg", "per";
- dmas = <&sdma 9 8 1>, <&sdma 10 8 2>;
+ dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
dma-names = "rx", "tx";
status = "disabled";
};
--
2.17.1
^ permalink raw reply related
* dmaengine: pl330: _stop: clear interrupt status
From: Sugar Zhang @ 2019-04-03 11:06 UTC (permalink / raw)
To: heiko, broonie
Cc: linux-rockchip, Sugar Zhang, Vinod Koul, Dan Williams, dmaengine,
linux-kernel
This patch kill instructs the DMAC to immediately terminate
execution of a thread. and then clear the interrupt status,
at last, stop generating interrupts for DMA_SEV. to guarantee
the next dma start is clean. otherwise, one interrupt maybe leave
to next start and make some mistake.
we can reporduce the problem as follows:
DMASEV: modify the event-interrupt resource, and if the INTEN sets
function as interrupt, the DMAC will set irq<event_num> HIGH to
generate interrupt. write INTCLR to clear interrupt.
DMA EXECUTING INSTRUCTS DMA TERMINATE
| |
| |
... _stop
| |
| spin_lock_irqsave
DMASEV |
| |
| mask INTEN
| |
| DMAKILL
| |
| spin_unlock_irqrestore
in above case, a interrupt was left, and if we unmask INTEN, the DMAC
will set irq<event_num> HIGH to generate interrupt.
to fix this, do as follows:
DMA EXECUTING INSTRUCTS DMA TERMINATE
| |
| |
... _stop
| |
| spin_lock_irqsave
DMASEV |
| |
| DMAKILL
| |
| clear INTCLR
| mask INTEN
| |
| spin_unlock_irqrestore
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
---
drivers/dma/pl330.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index eec79fd..56695ff 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -966,6 +966,7 @@ static void _stop(struct pl330_thread *thrd)
{
void __iomem *regs = thrd->dmac->base;
u8 insn[6] = {0, 0, 0, 0, 0, 0};
+ u32 inten = readl(regs + INTEN);
if (_state(thrd) == PL330_STATE_FAULT_COMPLETING)
UNTIL(thrd, PL330_STATE_FAULTING | PL330_STATE_KILLING);
@@ -978,10 +979,13 @@ static void _stop(struct pl330_thread *thrd)
_emit_KILL(0, insn);
- /* Stop generating interrupts for SEV */
- writel(readl(regs + INTEN) & ~(1 << thrd->ev), regs + INTEN);
-
_execute_DBGINSN(thrd, insn, is_manager(thrd));
+
+ /* clear the event */
+ if (inten & (1 << thrd->ev))
+ writel(1 << thrd->ev, regs + INTCLR);
+ /* Stop generating interrupts for SEV */
+ writel(inten & ~(1 << thrd->ev), regs + INTEN);
}
/* Start doing req 'idx' of thread 'thrd' */
^ permalink raw reply related
* [v2,3/3] arm64: dts: imx8mq: Change ahb clock for imx8mq
From: Shawn Guo @ 2019-04-03 11:00 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: angus.ainslie, Rob Herring, Mark Rutland, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Dan Williams, Vinod Koul, Lucas Stach, Carlo Caione,
Daniel Baluta, Guido Günther, devicetree, linux-arm-kernel,
linux-kernel, dmaengine
On Fri, Mar 29, 2019 at 08:21:30AM -0700, Angus Ainslie (Purism) wrote:
> Set ahb clock on sdma1 to get rid of "Timeout waiting for CH0"
> on the imx8mq.
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
Applied, thanks.
^ permalink raw reply
* [v2,1/3] arm64: dts: imx8mq: Fix the fsl,imx8mq-sdma compatible string
From: Shawn Guo @ 2019-04-03 10:59 UTC (permalink / raw)
To: Angus Ainslie (Purism)
Cc: angus.ainslie, Rob Herring, Mark Rutland, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Dan Williams, Vinod Koul, Lucas Stach, Carlo Caione,
Daniel Baluta, Guido Günther, devicetree, linux-arm-kernel,
linux-kernel, dmaengine
On Fri, Mar 29, 2019 at 08:21:28AM -0700, Angus Ainslie (Purism) wrote:
> Fix a typo in the compatible string
>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
Applied, thanks.
^ permalink raw reply
* [v3,3/3] dmaengine: at_xdmac: only monitor overflow errors for peripheral xfer
From: Nicolas Ferre @ 2019-04-03 10:23 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
The overflow error flag (ROI: Request Overflow Error) is only relevant
for the case when the channel handles a peripheral synchronized transfer.
Not in the case of memory to memory transfer where there is no hardware
request signal.
Remove the use of this interrupt source in such a case. It's based on
the first descriptor which holds the configuration for the whole
linked list transfer.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v3: no change
v2: added Ludovic's tag
drivers/dma/at_xdmac.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 1dd7edaefbdc..06cbe54e4c30 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -308,6 +308,11 @@ static inline int at_xdmac_csize(u32 maxburst)
return csize;
};
+static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
+{
+ return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
+}
+
static inline u8 at_xdmac_get_dwidth(u32 cfg)
{
return (cfg & AT_XDMAC_CC_DWIDTH_MASK) >> AT_XDMAC_CC_DWIDTH_OFFSET;
@@ -389,7 +394,13 @@ static void at_xdmac_start_xfer(struct at_xdmac_chan *atchan,
at_xdmac_chan_read(atchan, AT_XDMAC_CUBC));
at_xdmac_chan_write(atchan, AT_XDMAC_CID, 0xffffffff);
- reg = AT_XDMAC_CIE_RBEIE | AT_XDMAC_CIE_WBEIE | AT_XDMAC_CIE_ROIE;
+ reg = AT_XDMAC_CIE_RBEIE | AT_XDMAC_CIE_WBEIE;
+ /*
+ * Request Overflow Error is only for peripheral synchronized transfers
+ */
+ if (at_xdmac_chan_is_peripheral_xfer(first->lld.mbr_cfg))
+ reg |= AT_XDMAC_CIE_ROIE;
+
/*
* There is no end of list when doing cyclic dma, we need to get
* an interrupt after each periods.
^ permalink raw reply related
* [v3,2/3] dmaengine: at_xdmac: enhance channel errors handling in tasklet
From: Nicolas Ferre @ 2019-04-03 10:23 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
Complement the identification of errors with stopping the channel and
dumping the descriptor that led to the error case.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v3: Typo in commit message, alignment in multi-line dev_dbg()
v2: added Ludovic's tag
address Vinod's comments (typo, comment, empty line before logical blocks)
drivers/dma/at_xdmac.c | 48 ++++++++++++++++++++++++++++++++++++------
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 37a269420435..1dd7edaefbdc 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1575,6 +1575,46 @@ static void at_xdmac_handle_cyclic(struct at_xdmac_chan *atchan)
dmaengine_desc_get_callback_invoke(txd, NULL);
}
+static void at_xdmac_handle_error(struct at_xdmac_chan *atchan)
+{
+ struct at_xdmac *atxdmac = to_at_xdmac(atchan->chan.device);
+ struct at_xdmac_desc *bad_desc;
+
+ /*
+ * The descriptor currently at the head of the active list is
+ * broken. Since we don't have any way to report errors, we'll
+ * just have to scream loudly and try to continue with other
+ * descriptors queued (if any).
+ */
+ if (atchan->irq_status & AT_XDMAC_CIS_RBEIS)
+ dev_err(chan2dev(&atchan->chan), "read bus error!!!");
+ if (atchan->irq_status & AT_XDMAC_CIS_WBEIS)
+ dev_err(chan2dev(&atchan->chan), "write bus error!!!");
+ if (atchan->irq_status & AT_XDMAC_CIS_ROIS)
+ dev_err(chan2dev(&atchan->chan), "request overflow error!!!");
+
+ spin_lock_bh(&atchan->lock);
+
+ /* Channel must be disabled first as it's not done automatically */
+ at_xdmac_write(atxdmac, AT_XDMAC_GD, atchan->mask);
+ while (at_xdmac_read(atxdmac, AT_XDMAC_GS) & atchan->mask)
+ cpu_relax();
+
+ bad_desc = list_first_entry(&atchan->xfers_list,
+ struct at_xdmac_desc,
+ xfer_node);
+
+ spin_unlock_bh(&atchan->lock);
+
+ /* Print bad descriptor's details if needed */
+ dev_dbg(chan2dev(&atchan->chan),
+ "%s: lld: mbr_sa=%pad, mbr_da=%pad, mbr_ubc=0x%08x\n",
+ __func__, &bad_desc->lld.mbr_sa, &bad_desc->lld.mbr_da,
+ bad_desc->lld.mbr_ubc);
+
+ /* Then continue with usual descriptor management */
+}
+
static void at_xdmac_tasklet(unsigned long data)
{
struct at_xdmac_chan *atchan = (struct at_xdmac_chan *)data;
@@ -1594,12 +1634,8 @@ static void at_xdmac_tasklet(unsigned long data)
|| (atchan->irq_status & error_mask)) {
struct dma_async_tx_descriptor *txd;
- if (atchan->irq_status & AT_XDMAC_CIS_RBEIS)
- dev_err(chan2dev(&atchan->chan), "read bus error!!!");
- if (atchan->irq_status & AT_XDMAC_CIS_WBEIS)
- dev_err(chan2dev(&atchan->chan), "write bus error!!!");
- if (atchan->irq_status & AT_XDMAC_CIS_ROIS)
- dev_err(chan2dev(&atchan->chan), "request overflow error!!!");
+ if (atchan->irq_status & error_mask)
+ at_xdmac_handle_error(atchan);
spin_lock(&atchan->lock);
desc = list_first_entry(&atchan->xfers_list,
^ permalink raw reply related
* [v3,1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
From: Nicolas Ferre @ 2019-04-03 10:23 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
Even if this case shouldn't happen when controller is properly programmed,
it's still better to avoid dumping a kernel Oops for this.
As the sequence may happen only for debugging purposes, log the error and
just finish the tasklet call.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v3: no change
v2: added Ludovic's tag
drivers/dma/at_xdmac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index fe69dccfa0c0..37a269420435 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1606,7 +1606,11 @@ static void at_xdmac_tasklet(unsigned long data)
struct at_xdmac_desc,
xfer_node);
dev_vdbg(chan2dev(&atchan->chan), "%s: desc 0x%p\n", __func__, desc);
- BUG_ON(!desc->active_xfer);
+ if (!desc->active_xfer) {
+ dev_err(chan2dev(&atchan->chan), "Xfer not active: exiting");
+ spin_unlock_bh(&atchan->lock);
+ return;
+ }
txd = &desc->tx_dma_desc;
^ permalink raw reply related
* [v2,1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
From: Nicolas Ferre @ 2019-04-03 10:22 UTC (permalink / raw)
To: dmaengine, vkoul
Cc: Ludovic.Desroches, linux-arm-kernel, alexandre.belloni,
linux-kernel
Vinod,
Please disregard this series: I'm sending a v3 right now. Sorry for the
noise.
Best regards,
Nicolas
On 03/04/2019 at 12:09, Nicolas Ferre wrote:
> Even if this case shouldn't happen when controller is properly programmed,
> it's still better to avoid dumping a kernel Oops for this.
> As the sequence may happen only for debugging purposes, log the error and
> just finish the tasklet call.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> v2: added Ludovic's tag
>
> drivers/dma/at_xdmac.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index fe69dccfa0c0..37a269420435 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -1606,7 +1606,11 @@ static void at_xdmac_tasklet(unsigned long data)
> struct at_xdmac_desc,
> xfer_node);
> dev_vdbg(chan2dev(&atchan->chan), "%s: desc 0x%p\n", __func__, desc);
> - BUG_ON(!desc->active_xfer);
> + if (!desc->active_xfer) {
> + dev_err(chan2dev(&atchan->chan), "Xfer not active: exiting");
> + spin_unlock_bh(&atchan->lock);
> + return;
> + }
>
> txd = &desc->tx_dma_desc;
>
>
--
Nicolas Ferre
^ permalink raw reply
* [v2,3/3] dmaengine: at_xdmac: only monitor overflow errors for peripheral xfer
From: Nicolas Ferre @ 2019-04-03 10:09 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
The overflow error flag (ROI: Request Overflow Error) is only relevant
for the case when the channel handles a peripheral synchronized transfer.
Not in the case of memory to memory transfer where there is no hardware
request signal.
Remove the use of this interrupt source in such a case. It's based on
the first descriptor which holds the configuration for the whole
linked list transfer.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v2: added Ludovic's tag
drivers/dma/at_xdmac.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index b7117474a10d..cbe545ae4dfc 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -308,6 +308,11 @@ static inline int at_xdmac_csize(u32 maxburst)
return csize;
};
+static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
+{
+ return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
+}
+
static inline u8 at_xdmac_get_dwidth(u32 cfg)
{
return (cfg & AT_XDMAC_CC_DWIDTH_MASK) >> AT_XDMAC_CC_DWIDTH_OFFSET;
@@ -389,7 +394,13 @@ static void at_xdmac_start_xfer(struct at_xdmac_chan *atchan,
at_xdmac_chan_read(atchan, AT_XDMAC_CUBC));
at_xdmac_chan_write(atchan, AT_XDMAC_CID, 0xffffffff);
- reg = AT_XDMAC_CIE_RBEIE | AT_XDMAC_CIE_WBEIE | AT_XDMAC_CIE_ROIE;
+ reg = AT_XDMAC_CIE_RBEIE | AT_XDMAC_CIE_WBEIE;
+ /*
+ * Request Overflow Error is only for peripheral synchronized transfers
+ */
+ if (at_xdmac_chan_is_peripheral_xfer(first->lld.mbr_cfg))
+ reg |= AT_XDMAC_CIE_ROIE;
+
/*
* There is no end of list when doing cyclic dma, we need to get
* an interrupt after each periods.
^ permalink raw reply related
* [v2,2/3] dmaengine: at_xdmac: enhance channel errors handling in tasklet
From: Nicolas Ferre @ 2019-04-03 10:09 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
Complement the identification of errors with stoping the channel and
dumping the descriptor that led to the error case.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v2: added Ludovic's tag
address Vinod's comments (typo, comment, empty line before logical blocks)
drivers/dma/at_xdmac.c | 48 ++++++++++++++++++++++++++++++++++++------
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 37a269420435..b7117474a10d 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1575,6 +1575,46 @@ static void at_xdmac_handle_cyclic(struct at_xdmac_chan *atchan)
dmaengine_desc_get_callback_invoke(txd, NULL);
}
+static void at_xdmac_handle_error(struct at_xdmac_chan *atchan)
+{
+ struct at_xdmac *atxdmac = to_at_xdmac(atchan->chan.device);
+ struct at_xdmac_desc *bad_desc;
+
+ /*
+ * The descriptor currently at the head of the active list is
+ * broken. Since we don't have any way to report errors, we'll
+ * just have to scream loudly and try to continue with other
+ * descriptors queued (if any).
+ */
+ if (atchan->irq_status & AT_XDMAC_CIS_RBEIS)
+ dev_err(chan2dev(&atchan->chan), "read bus error!!!");
+ if (atchan->irq_status & AT_XDMAC_CIS_WBEIS)
+ dev_err(chan2dev(&atchan->chan), "write bus error!!!");
+ if (atchan->irq_status & AT_XDMAC_CIS_ROIS)
+ dev_err(chan2dev(&atchan->chan), "request overflow error!!!");
+
+ spin_lock_bh(&atchan->lock);
+
+ /* Channel must be disabled first as it's not done automatically */
+ at_xdmac_write(atxdmac, AT_XDMAC_GD, atchan->mask);
+ while (at_xdmac_read(atxdmac, AT_XDMAC_GS) & atchan->mask)
+ cpu_relax();
+
+ bad_desc = list_first_entry(&atchan->xfers_list,
+ struct at_xdmac_desc,
+ xfer_node);
+
+ spin_unlock_bh(&atchan->lock);
+
+ /* Print bad descriptor's details if needed */
+ dev_dbg(chan2dev(&atchan->chan),
+ "%s: lld: mbr_sa=%pad, mbr_da=%pad, mbr_ubc=0x%08x\n",
+ __func__, &bad_desc->lld.mbr_sa, &bad_desc->lld.mbr_da,
+ bad_desc->lld.mbr_ubc);
+
+ /* Then continue with usual descriptor management */
+}
+
static void at_xdmac_tasklet(unsigned long data)
{
struct at_xdmac_chan *atchan = (struct at_xdmac_chan *)data;
@@ -1594,12 +1634,8 @@ static void at_xdmac_tasklet(unsigned long data)
|| (atchan->irq_status & error_mask)) {
struct dma_async_tx_descriptor *txd;
- if (atchan->irq_status & AT_XDMAC_CIS_RBEIS)
- dev_err(chan2dev(&atchan->chan), "read bus error!!!");
- if (atchan->irq_status & AT_XDMAC_CIS_WBEIS)
- dev_err(chan2dev(&atchan->chan), "write bus error!!!");
- if (atchan->irq_status & AT_XDMAC_CIS_ROIS)
- dev_err(chan2dev(&atchan->chan), "request overflow error!!!");
+ if (atchan->irq_status & error_mask)
+ at_xdmac_handle_error(atchan);
spin_lock(&atchan->lock);
desc = list_first_entry(&atchan->xfers_list,
^ permalink raw reply related
* [v2,1/3] dmaengine: at_xdmac: remove BUG_ON macro in tasklet
From: Nicolas Ferre @ 2019-04-03 10:09 UTC (permalink / raw)
To: dmaengine, Vinod Koul
Cc: Ludovic Desroches, linux-arm-kernel, Alexandre Belloni,
linux-kernel, Nicolas Ferre
Even if this case shouldn't happen when controller is properly programmed,
it's still better to avoid dumping a kernel Oops for this.
As the sequence may happen only for debugging purposes, log the error and
just finish the tasklet call.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v2: added Ludovic's tag
drivers/dma/at_xdmac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index fe69dccfa0c0..37a269420435 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1606,7 +1606,11 @@ static void at_xdmac_tasklet(unsigned long data)
struct at_xdmac_desc,
xfer_node);
dev_vdbg(chan2dev(&atchan->chan), "%s: desc 0x%p\n", __func__, desc);
- BUG_ON(!desc->active_xfer);
+ if (!desc->active_xfer) {
+ dev_err(chan2dev(&atchan->chan), "Xfer not active: exiting");
+ spin_unlock_bh(&atchan->lock);
+ return;
+ }
txd = &desc->tx_dma_desc;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox