On 5/14/21 Adam Ford <aford173@xxxxxxxxx> wrote: > I did this on the 5.13-rc1 which appears to have this series applied. Sorry, I didn't see it on 5.13-rc2 even.... > > 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>; > > I didn't change the DMA references from the default, and I didn't check to > verify whether they are right or not. If so, I don't think you could see the above firmware load error since UART use ROM firmware by default instead. > > > > > > > > > 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. > > I don't pretend to understand the details of the dma driver, but I attempted to > make the patch match the address range of both spba busses from the > technical reference manual,so there should be an spba bus for the audio > peripherals and an spba bus for the serial peripherals like UART and SPI. I > only named them spba1 and spba2 based on the memory ranges defined in > the ref manual. Table 2-5 shows > SBPA1 is 3080_0000 and table 2-3 shows SPBA2 starts at 3000_0000 which is > what I believe I did in this patch. Okay, I'm not saying your patch is not wrong, just curious about your UART issue you mentioned :)
