The i.MX8MN has an SPBA bus which covers much of the audio, but
there is a second SPBA bus which covers many of the serial interfaces
like SPI and UARTs currently missing from the device tree. The reference
manual calls the bus handling the audio peripherals SPBA2, and the bus
handling the serial peripherals is called SPBA1.
Rename the existing spba bus to spba2 and add spba1.
Signed-off-by: Adam Ford <[email protected]>
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 4dac4da38f4c..e961acd237a8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -255,7 +255,7 @@ aips1: bus@30000000 {
#size-cells = <1>;
ranges;
- spba: spba-bus@30000000 {
+ spba2: spba-bus@30000000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
@@ -681,80 +681,88 @@ aips3: bus@30800000 {
#size-cells = <1>;
ranges;
- ecspi1: spi@30820000 {
- compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+ spba1: spba-bus@30800000 {
+ compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
- #size-cells = <0>;
- reg = <0x30820000 0x10000>;
- interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
- <&clk IMX8MN_CLK_ECSPI1_ROOT>;
- clock-names = "ipg", "per";
- dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ #size-cells = <1>;
+ reg = <0x30800000 0x100000>;
+ ranges;
- ecspi2: spi@30830000 {
- compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x30830000 0x10000>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
- <&clk IMX8MN_CLK_ECSPI2_ROOT>;
- clock-names = "ipg", "per";
- dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ ecspi1: spi@30820000 {
+ compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x30820000 0x10000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
+ <&clk IMX8MN_CLK_ECSPI1_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- ecspi3: spi@30840000 {
- compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x30840000 0x10000>;
- interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
- <&clk IMX8MN_CLK_ECSPI3_ROOT>;
- clock-names = "ipg", "per";
- dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ ecspi2: spi@30830000 {
+ compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x30830000 0x10000>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
+ <&clk IMX8MN_CLK_ECSPI2_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- uart1: serial@30860000 {
- compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
- reg = <0x30860000 0x10000>;
- interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
- <&clk IMX8MN_CLK_UART1_ROOT>;
- clock-names = "ipg", "per";
- dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ ecspi3: spi@30840000 {
+ compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x30840000 0x10000>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
+ <&clk IMX8MN_CLK_ECSPI3_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- uart3: serial@30880000 {
- compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
- reg = <0x30880000 0x10000>;
- interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
- <&clk IMX8MN_CLK_UART3_ROOT>;
- clock-names = "ipg", "per";
- dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
- dma-names = "rx", "tx";
- status = "disabled";
- };
+ uart1: serial@30860000 {
+ compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+ reg = <0x30860000 0x10000>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
+ <&clk IMX8MN_CLK_UART1_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
- uart2: serial@30890000 {
- compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
- reg = <0x30890000 0x10000>;
- interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
- <&clk IMX8MN_CLK_UART2_ROOT>;
- clock-names = "ipg", "per";
- status = "disabled";
+ uart3: serial@30880000 {
+ compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+ reg = <0x30880000 0x10000>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
+ <&clk IMX8MN_CLK_UART3_ROOT>;
+ clock-names = "ipg", "per";
+ dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ uart2: serial@30890000 {
+ compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+ reg = <0x30890000 0x10000>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
+ <&clk IMX8MN_CLK_UART2_ROOT>;
+ clock-names = "ipg", "per";
+ status = "disabled";
+ };
};
crypto: crypto@30900000 {
--
2.25.1
On Mon, Apr 05, 2021 at 08:33:42PM -0500, Adam Ford wrote:
> The i.MX8MN has an SPBA bus which covers much of the audio, but
> there is a second SPBA bus which covers many of the serial interfaces
> like SPI and UARTs currently missing from the device tree. The reference
> manual calls the bus handling the audio peripherals SPBA2, and the bus
> handling the serial peripherals is called SPBA1.
>
> Rename the existing spba bus to spba2 and add spba1.
>
> Signed-off-by: Adam Ford <[email protected]>
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> index 4dac4da38f4c..e961acd237a8 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> @@ -255,7 +255,7 @@ aips1: bus@30000000 {
> #size-cells = <1>;
> ranges;
>
> - spba: spba-bus@30000000 {
> + spba2: spba-bus@30000000 {
> compatible = "fsl,spba-bus", "simple-bus";
Just noticed that "fsl,spba-bus" is undocumented, no?
Also may I ask if you have a real use case for this bus node?
Shawn
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -681,80 +681,88 @@ aips3: bus@30800000 {
> #size-cells = <1>;
> ranges;
>
> - ecspi1: spi@30820000 {
> - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> + spba1: spba-bus@30800000 {
> + compatible = "fsl,spba-bus", "simple-bus";
> #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x30820000 0x10000>;
> - interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
> - <&clk IMX8MN_CLK_ECSPI1_ROOT>;
> - clock-names = "ipg", "per";
> - dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + #size-cells = <1>;
> + reg = <0x30800000 0x100000>;
> + ranges;
>
> - ecspi2: spi@30830000 {
> - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x30830000 0x10000>;
> - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
> - <&clk IMX8MN_CLK_ECSPI2_ROOT>;
> - clock-names = "ipg", "per";
> - dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + ecspi1: spi@30820000 {
> + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x30820000 0x10000>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
> + <&clk IMX8MN_CLK_ECSPI1_ROOT>;
> + clock-names = "ipg", "per";
> + dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> - ecspi3: spi@30840000 {
> - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x30840000 0x10000>;
> - interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
> - <&clk IMX8MN_CLK_ECSPI3_ROOT>;
> - clock-names = "ipg", "per";
> - dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + ecspi2: spi@30830000 {
> + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x30830000 0x10000>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
> + <&clk IMX8MN_CLK_ECSPI2_ROOT>;
> + clock-names = "ipg", "per";
> + dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> - uart1: serial@30860000 {
> - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> - reg = <0x30860000 0x10000>;
> - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
> - <&clk IMX8MN_CLK_UART1_ROOT>;
> - clock-names = "ipg", "per";
> - dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + ecspi3: spi@30840000 {
> + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x30840000 0x10000>;
> + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
> + <&clk IMX8MN_CLK_ECSPI3_ROOT>;
> + clock-names = "ipg", "per";
> + dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> - uart3: serial@30880000 {
> - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> - reg = <0x30880000 0x10000>;
> - interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
> - <&clk IMX8MN_CLK_UART3_ROOT>;
> - clock-names = "ipg", "per";
> - dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
> - dma-names = "rx", "tx";
> - status = "disabled";
> - };
> + uart1: serial@30860000 {
> + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> + reg = <0x30860000 0x10000>;
> + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
> + <&clk IMX8MN_CLK_UART1_ROOT>;
> + clock-names = "ipg", "per";
> + dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
>
> - uart2: serial@30890000 {
> - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> - reg = <0x30890000 0x10000>;
> - interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
> - <&clk IMX8MN_CLK_UART2_ROOT>;
> - clock-names = "ipg", "per";
> - status = "disabled";
> + uart3: serial@30880000 {
> + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> + reg = <0x30880000 0x10000>;
> + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
> + <&clk IMX8MN_CLK_UART3_ROOT>;
> + clock-names = "ipg", "per";
> + dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
> + dma-names = "rx", "tx";
> + status = "disabled";
> + };
> +
> + uart2: serial@30890000 {
> + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> + reg = <0x30890000 0x10000>;
> + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
> + <&clk IMX8MN_CLK_UART2_ROOT>;
> + clock-names = "ipg", "per";
> + status = "disabled";
> + };
> };
>
> crypto: crypto@30900000 {
> --
> 2.25.1
>
On Mon, May 10, 2021 at 9:46 PM Shawn Guo <[email protected]> wrote:
>
> On Mon, Apr 05, 2021 at 08:33:42PM -0500, Adam Ford wrote:
> > The i.MX8MN has an SPBA bus which covers much of the audio, but
> > there is a second SPBA bus which covers many of the serial interfaces
> > like SPI and UARTs currently missing from the device tree. The reference
> > manual calls the bus handling the audio peripherals SPBA2, and the bus
> > handling the serial peripherals is called SPBA1.
> >
> > Rename the existing spba bus to spba2 and add spba1.
> >
> > Signed-off-by: Adam Ford <[email protected]>
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > index 4dac4da38f4c..e961acd237a8 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > @@ -255,7 +255,7 @@ aips1: bus@30000000 {
> > #size-cells = <1>;
> > ranges;
> >
> > - spba: spba-bus@30000000 {
> > + spba2: spba-bus@30000000 {
> > compatible = "fsl,spba-bus", "simple-bus";
>
> Just noticed that "fsl,spba-bus" is undocumented, no?
I attempted to push the bindings, and I was told it was applied, but
when I asked where the bindings were applied I never got a response -
[1].
Do you want me to resend the bindings?
>
> Also may I ask if you have a real use case for this bus node?
The reference manual shows the SPBA bus tells the DMA controller which
peripherals are associated with it. Nearly all the i.MX boards use
this. The boards I support have Bluetooth devices connected to a UART
running high speeds, and if the DMA driver isn't loaded, I can see a
performance change. In fact, if the DMA firmware isn't loaded, I
often get transfer errors.
adam
[1] - https://lore.kernel.org/linux-devicetree/CAHCN7x+om4W5jqnuAW4-nMkZLc5nrYu7NUsbM36r0wyFSYa4-g@mail.gmail.com/T/
>
> Shawn
>
> > #address-cells = <1>;
> > #size-cells = <1>;
> > @@ -681,80 +681,88 @@ aips3: bus@30800000 {
> > #size-cells = <1>;
> > ranges;
> >
> > - ecspi1: spi@30820000 {
> > - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > + spba1: spba-bus@30800000 {
> > + compatible = "fsl,spba-bus", "simple-bus";
> > #address-cells = <1>;
> > - #size-cells = <0>;
> > - reg = <0x30820000 0x10000>;
> > - interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
> > - <&clk IMX8MN_CLK_ECSPI1_ROOT>;
> > - clock-names = "ipg", "per";
> > - dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
> > - dma-names = "rx", "tx";
> > - status = "disabled";
> > - };
> > + #size-cells = <1>;
> > + reg = <0x30800000 0x100000>;
> > + ranges;
> >
> > - ecspi2: spi@30830000 {
> > - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - reg = <0x30830000 0x10000>;
> > - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
> > - <&clk IMX8MN_CLK_ECSPI2_ROOT>;
> > - clock-names = "ipg", "per";
> > - dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
> > - dma-names = "rx", "tx";
> > - status = "disabled";
> > - };
> > + ecspi1: spi@30820000 {
> > + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x30820000 0x10000>;
> > + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
> > + <&clk IMX8MN_CLK_ECSPI1_ROOT>;
> > + clock-names = "ipg", "per";
> > + dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
> > + dma-names = "rx", "tx";
> > + status = "disabled";
> > + };
> >
> > - ecspi3: spi@30840000 {
> > - compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - reg = <0x30840000 0x10000>;
> > - interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
> > - <&clk IMX8MN_CLK_ECSPI3_ROOT>;
> > - clock-names = "ipg", "per";
> > - dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
> > - dma-names = "rx", "tx";
> > - status = "disabled";
> > - };
> > + ecspi2: spi@30830000 {
> > + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x30830000 0x10000>;
> > + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
> > + <&clk IMX8MN_CLK_ECSPI2_ROOT>;
> > + clock-names = "ipg", "per";
> > + dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
> > + dma-names = "rx", "tx";
> > + status = "disabled";
> > + };
> >
> > - uart1: serial@30860000 {
> > - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > - reg = <0x30860000 0x10000>;
> > - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
> > - <&clk IMX8MN_CLK_UART1_ROOT>;
> > - clock-names = "ipg", "per";
> > - dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
> > - dma-names = "rx", "tx";
> > - status = "disabled";
> > - };
> > + ecspi3: spi@30840000 {
> > + compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x30840000 0x10000>;
> > + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
> > + <&clk IMX8MN_CLK_ECSPI3_ROOT>;
> > + clock-names = "ipg", "per";
> > + dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
> > + dma-names = "rx", "tx";
> > + status = "disabled";
> > + };
> >
> > - uart3: serial@30880000 {
> > - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > - reg = <0x30880000 0x10000>;
> > - interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
> > - <&clk IMX8MN_CLK_UART3_ROOT>;
> > - clock-names = "ipg", "per";
> > - dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
> > - dma-names = "rx", "tx";
> > - status = "disabled";
> > - };
> > + uart1: serial@30860000 {
> > + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > + reg = <0x30860000 0x10000>;
> > + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
> > + <&clk IMX8MN_CLK_UART1_ROOT>;
> > + clock-names = "ipg", "per";
> > + dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
> > + dma-names = "rx", "tx";
> > + status = "disabled";
> > + };
> >
> > - uart2: serial@30890000 {
> > - compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > - reg = <0x30890000 0x10000>;
> > - interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> > - clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
> > - <&clk IMX8MN_CLK_UART2_ROOT>;
> > - clock-names = "ipg", "per";
> > - status = "disabled";
> > + uart3: serial@30880000 {
> > + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > + reg = <0x30880000 0x10000>;
> > + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
> > + <&clk IMX8MN_CLK_UART3_ROOT>;
> > + clock-names = "ipg", "per";
> > + dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
> > + dma-names = "rx", "tx";
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@30890000 {
> > + compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
> > + reg = <0x30890000 0x10000>;
> > + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
> > + <&clk IMX8MN_CLK_UART2_ROOT>;
> > + clock-names = "ipg", "per";
> > + status = "disabled";
> > + };
> > };
> >
> > crypto: crypto@30900000 {
> > --
> > 2.25.1
> >
On 2021/05/11 18:45 Adam Ford <[email protected]> wrote:
> > Also may I ask if you have a real use case for this bus node?
>
> The reference manual shows the SPBA bus tells the DMA controller which
> peripherals are associated with it. Nearly all the i.MX boards use this. The
> boards I support have Bluetooth devices connected to a UART running high
> speeds, and if the DMA driver isn't loaded, I can see a performance change.
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.
On Tue, May 11, 2021 at 7:20 AM Robin Gong <[email protected]> wrote:
>
> On 2021/05/11 18:45 Adam Ford <[email protected]> wrote:
> > > Also may I ask if you have a real use case for this bus node?
> >
> > The reference manual shows the SPBA bus tells the DMA controller which
> > peripherals are associated with it. Nearly all the i.MX boards use this. The
> > boards I support have Bluetooth devices connected to a UART running high
> > speeds, and if the DMA driver isn't loaded, I can see a performance change.
> 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!
[ 10.594548] Bluetooth: HCI UART protocol Broadcom registered
[ 10.600108] imx-uart 30860000.serial: We cannot prepare for the RX slave dma!
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.
adam
>
>
>
>
On Tue, May 11, 2021 at 09:48:38AM -0500, Adam Ford wrote:
> On Tue, May 11, 2021 at 7:20 AM Robin Gong <[email protected]> wrote:
> >
> > On 2021/05/11 18:45 Adam Ford <[email protected]> wrote:
> > > > Also may I ask if you have a real use case for this bus node?
> > >
> > > The reference manual shows the SPBA bus tells the DMA controller which
> > > peripherals are associated with it. Nearly all the i.MX boards use this. The
> > > boards I support have Bluetooth devices connected to a UART running high
> > > speeds, and if the DMA driver isn't loaded, I can see a performance change.
> > 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!
> [ 10.594548] Bluetooth: HCI UART protocol Broadcom registered
> [ 10.600108] imx-uart 30860000.serial: We cannot prepare for the RX slave dma!
>
> 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.
Yeah, I can see how DMA firmware impacts your Bluetooth device, but do
not follow how this spba node change make a difference here.
Nevertheless, patches look good. Applied, thanks.
Shawn
On 5/11/21 22:49 Adam Ford <[email protected]> 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 <[email protected]>
Date: Fri Jul 10 17:08:16 2015 +0800
dmaengine: imx-sdma: Add device to device support
On Fri, May 14, 2021 at 9:57 AM Robin Gong <[email protected]> wrote:
>
> On 5/11/21 22:49 Adam Ford <[email protected]> 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 <[email protected]>
> Date: Fri Jul 10 17:08:16 2015 +0800
>
> dmaengine: imx-sdma: Add device to device support
>
>
>
>
>
On 5/14/21 Adam Ford <[email protected]> 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 :)