From: Robin Gong <yibin.gong@nxp.com> To: Adam Ford <aford173@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org>, arm-soc <linux-arm-kernel@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, dl-linux-imx <linux-imx@nxp.com>, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: RE: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus Date: Fri, 14 May 2021 14:57:24 +0000 [thread overview] Message-ID: <VE1PR04MB668860A19062925162C40F3C89509@VE1PR04MB6688.eurprd04.prod.outlook.com> (raw) In-Reply-To: <CAHCN7xJ5Hq6bRpEgE8Pi9VbQ_Kejy-sgKQsJ93pQEG3U_Wsu=Q@mail.gmail.com> On 5/11/21 22:49 Adam Ford <aford173@gmail.com> wrote: > > Compare PIO with DMA on UART, but not w/o this 'spba bus node ' patch? > > > > > In fact, if the DMA firmware isn't loaded, I often get transfer errors. > > UART use SDMA ROM firmware instead of RAM firmware, so it should work > > even without sdma RAM firmware loaded. Still curious what really > > happen in your board without this patch. > > What I am seeing is that at times, the HCI UART loading before the DMA > firmware is loaded. > > [ 10.582037] Bluetooth: HCI UART driver ver 2.3 > [ 10.586867] Bluetooth: HCI UART protocol H4 registered > [ 10.593566] imx-sdma 30bd0000.dma-controller: sdma firmware not > ready! Seems you apply my patch set ' add ecspi ERR009165 for i.mx6/7 soc family' https://www.spinics.net/lists/linux-spi/msg26728.html where 'sdma firmware not ready' added? > [ 10.594548] Bluetooth: HCI UART protocol Broadcom registered > [ 10.600108] imx-uart 30860000.serial: We cannot prepare for the RX slave > dma! Why not use ROM script for UART as mailine linux-next did (even the above patch set)? If so, I don't think you could such issue on your board. What script(peripheral types) you set in uart dts such as below is 4-- MCU domain UART-> IMX_DMATYPE_UART->app_2_mcu: dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>; > > When I get the above message, the bluetooth chip I have throws timeouts and > does not function. > > [ 10.615090] imx-sdma 302c0000.dma-controller: loaded firmware 4.5 > > Once the firmware is loaded, I can unload the HCI Uart driver and re-load > Bluetooth works again. > > Based on that, I've been having my system delay the loading of the Bluetooth > modules until after the firmware is loaded, but this tells me there is a > relationship between the DMA and UART. If you use ram script, of course you should use it after firmware loaded. Actually Spba bus in dts is only used for per_2_per script judging if the peripheral address could be accessed directly by SDMA over SPBA, if yes, set SDMA_WATERMARK_LEVEL_SP to let per_2_per script access peripheral over SPBA, otherwise, access peripheral by AIPS instead like ARM side did. Please check with below commit for more. Besides, per_2_per script is used for audio data sample rate convert between ASRC and various audio input. So audio peripherals include ASRC should be in register scope of 'spba-bus' . But with your patch, there are two 'spba-bus' device node in dts, so the first Spba-bus should contain audio peripheral, otherwise, 'of_find_compatible_node (NULL, NULL, "fsl,spba-bus")' may find the wrong one so that SDMA_WATERMARK_LEVEL_SP Never be set. BTW, do you mean the above firmware load issue you met is gone if this patch applied? If yes, that really surprised me... commit 8391ecf465ec5c8ccef547267df6d40beb8999a4 Author: Shengjiu Wang <shengjiu.wang@freescale.com> Date: Fri Jul 10 17:08:16 2015 +0800 dmaengine: imx-sdma: Add device to device support
WARNING: multiple messages have this Message-ID (diff)
From: Robin Gong <yibin.gong@nxp.com> To: Adam Ford <aford173@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org>, arm-soc <linux-arm-kernel@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, dl-linux-imx <linux-imx@nxp.com>, devicetree <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: RE: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus Date: Fri, 14 May 2021 14:57:24 +0000 [thread overview] Message-ID: <VE1PR04MB668860A19062925162C40F3C89509@VE1PR04MB6688.eurprd04.prod.outlook.com> (raw) In-Reply-To: <CAHCN7xJ5Hq6bRpEgE8Pi9VbQ_Kejy-sgKQsJ93pQEG3U_Wsu=Q@mail.gmail.com> On 5/11/21 22:49 Adam Ford <aford173@gmail.com> wrote: > > Compare PIO with DMA on UART, but not w/o this 'spba bus node ' patch? > > > > > In fact, if the DMA firmware isn't loaded, I often get transfer errors. > > UART use SDMA ROM firmware instead of RAM firmware, so it should work > > even without sdma RAM firmware loaded. Still curious what really > > happen in your board without this patch. > > What I am seeing is that at times, the HCI UART loading before the DMA > firmware is loaded. > > [ 10.582037] Bluetooth: HCI UART driver ver 2.3 > [ 10.586867] Bluetooth: HCI UART protocol H4 registered > [ 10.593566] imx-sdma 30bd0000.dma-controller: sdma firmware not > ready! Seems you apply my patch set ' add ecspi ERR009165 for i.mx6/7 soc family' https://www.spinics.net/lists/linux-spi/msg26728.html where 'sdma firmware not ready' added? > [ 10.594548] Bluetooth: HCI UART protocol Broadcom registered > [ 10.600108] imx-uart 30860000.serial: We cannot prepare for the RX slave > dma! Why not use ROM script for UART as mailine linux-next did (even the above patch set)? If so, I don't think you could such issue on your board. What script(peripheral types) you set in uart dts such as below is 4-- MCU domain UART-> IMX_DMATYPE_UART->app_2_mcu: dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>; > > When I get the above message, the bluetooth chip I have throws timeouts and > does not function. > > [ 10.615090] imx-sdma 302c0000.dma-controller: loaded firmware 4.5 > > Once the firmware is loaded, I can unload the HCI Uart driver and re-load > Bluetooth works again. > > Based on that, I've been having my system delay the loading of the Bluetooth > modules until after the firmware is loaded, but this tells me there is a > relationship between the DMA and UART. If you use ram script, of course you should use it after firmware loaded. Actually Spba bus in dts is only used for per_2_per script judging if the peripheral address could be accessed directly by SDMA over SPBA, if yes, set SDMA_WATERMARK_LEVEL_SP to let per_2_per script access peripheral over SPBA, otherwise, access peripheral by AIPS instead like ARM side did. Please check with below commit for more. Besides, per_2_per script is used for audio data sample rate convert between ASRC and various audio input. So audio peripherals include ASRC should be in register scope of 'spba-bus' . But with your patch, there are two 'spba-bus' device node in dts, so the first Spba-bus should contain audio peripheral, otherwise, 'of_find_compatible_node (NULL, NULL, "fsl,spba-bus")' may find the wrong one so that SDMA_WATERMARK_LEVEL_SP Never be set. BTW, do you mean the above firmware load issue you met is gone if this patch applied? If yes, that really surprised me... commit 8391ecf465ec5c8ccef547267df6d40beb8999a4 Author: Shengjiu Wang <shengjiu.wang@freescale.com> Date: Fri Jul 10 17:08:16 2015 +0800 dmaengine: imx-sdma: Add device to device support _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-14 14:57 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-06 1:33 [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus Adam Ford 2021-04-06 1:33 ` Adam Ford 2021-04-06 1:33 ` [PATCH 2/2] arm64: dts: imx8mm: Add spba1 and spba2 buses Adam Ford 2021-04-06 1:33 ` Adam Ford 2021-05-11 2:46 ` [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus Shawn Guo 2021-05-11 2:46 ` Shawn Guo 2021-05-11 10:45 ` Adam Ford 2021-05-11 10:45 ` Adam Ford 2021-05-11 12:20 ` Robin Gong 2021-05-11 12:20 ` Robin Gong 2021-05-11 14:48 ` Adam Ford 2021-05-11 14:48 ` Adam Ford 2021-05-13 2:09 ` Shawn Guo 2021-05-13 2:09 ` Shawn Guo 2021-05-14 14:57 ` Robin Gong [this message] 2021-05-14 14:57 ` Robin Gong 2021-05-14 15:27 ` Adam Ford 2021-05-14 15:27 ` Adam Ford 2021-05-17 1:35 ` Robin Gong 2021-05-17 1:35 ` Robin Gong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=VE1PR04MB668860A19062925162C40F3C89509@VE1PR04MB6688.eurprd04.prod.outlook.com \ --to=yibin.gong@nxp.com \ --cc=aford173@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.