On 5/11/21 22:49 Adam Ford <aford173@xxxxxxxxx> 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@xxxxxxxxxxxxx> Date: Fri Jul 10 17:08:16 2015 +0800 dmaengine: imx-sdma: Add device to device support
