linux-kernel - Re: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHCN7xJ0xPJJaxMrzpZSGKjgh46bSEGgtsECd9ZqnpHKSCH9EA@mail.gmail.com>
Date:   Fri, 14 May 2021 10:27:17 -0500
From:   Adam Ford <aford173@...il.com>
To:     Robin Gong <yibin.gong@....com>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus

On Fri, May 14, 2021 at 9:57 AM Robin Gong <yibin.gong@....com> wrote:
>
> On 5/11/21 22:49 Adam Ford <aford173@...il.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

I did this on the 5.13-rc1 which appears to have this series applied.

> 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.

>
> >
> > 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.

>
> BTW, do you mean the above firmware load issue you met is gone if this patch applied?
> If yes, that really surprised me...

I wasn't trying to imply that adding the spba-bus fixes my Bluetooth
issue.  I was just stating there is some relationship between the DMA
and the UART and if the UART throws a DMA error, the Bluetooth will
fail too.  What I have been doing to ensure the order of operations is
to make the imx_sdma and the Bluetooth system as modules.  I tell my
sysfs to load the imx_sdma module first, then load the Bluetooth
modules.  When done in that order, I never see the DMA errors. With
UART baud rates at 3Mbps+, I wanted to make sure the DMA was
operational to help potentially reduce the A53 workload.

adam
>
> commit 8391ecf465ec5c8ccef547267df6d40beb8999a4
> Author: Shengjiu Wang <shengjiu.wang@...escale.com>
> Date:   Fri Jul 10 17:08:16 2015 +0800
>
>     dmaengine: imx-sdma: Add device to device support
>
>
>
>
>