Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
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
Thread-Topic: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus
Thread-Index: AQHXKoTrm+1dEO4gCEi87d5cyZOFDqrdyocAgACF5YCAABIPoIAAMe4AgASmRGCAABuHgIADyZ8w
Date:   Mon, 17 May 2021 01:35:22 +0000
Message-ID: <VE1PR04MB66880A52479E192514239D94892D9@VE1PR04MB6688.eurprd04.prod.outlook.com>
References: <20210406013344.124255-1-aford173@gmail.com>
 <20210511024604.GE3425@dragon>
 <CAHCN7xLFpL=9BF9M5gUA6sMhc2ZZMNz+GP0OLmLfpJAWdD7W-w@mail.gmail.com>
 <VE1PR04MB6688CD4AA4826EEEBBA2651689539@VE1PR04MB6688.eurprd04.prod.outlook.com>
 <CAHCN7xJ5Hq6bRpEgE8Pi9VbQ_Kejy-sgKQsJ93pQEG3U_Wsu=Q@mail.gmail.com>
 <VE1PR04MB668860A19062925162C40F3C89509@VE1PR04MB6688.eurprd04.prod.outlook.com>
 <CAHCN7xJ0xPJJaxMrzpZSGKjgh46bSEGgtsECd9ZqnpHKSCH9EA@mail.gmail.com>
In-Reply-To: <CAHCN7xJ0xPJJaxMrzpZSGKjgh46bSEGgtsECd9ZqnpHKSCH9EA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 05f7c1b0-41b2-424a-204d-08d918d409ac
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2021 01:35:22.3694
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XSS9cUvWoL5rd59tR5fiEa5m5AQA1W/PEPF06NEozr1BP4aS9NvkoYNt6+BOnDHdaJ69pmOd7511VlP2K5hlPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7022
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/14/21 Adam Ford <aford173@gmail.com> wrote: =20
> 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 abo=
ve
> patch set)?
>=20
>=20
>=20
> > 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 d=
omain
> UART-> IMX_DMATYPE_UART->app_2_mcu:
> >
> > dmas =3D <&sdma1 22 4 0>, <&sdma1 23 4 0>;
>=20
> I didn't change the DMA references from the default, and I didn't check t=
o
> 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.

>=20
> >
> > >
> > > 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 inste=
ad
> 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.
>=20
> I don't pretend to understand the details of the dma driver, but I attemp=
ted 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 :)