[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180309092539.GA5798@botnar.kaiser.cx>
Date: Fri, 9 Mar 2018 10:25:39 +0100
From: Martin Kaiser <martin@...ser.cx>
To: Lothar Waßmann <LW@...O-electronics.de>
Cc: Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
Fabio Estevam <fabio.estevam@....com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: i.MX25: define SSI FIFO depth
Hi Lothar,
Thus wrote Lothar Waßmann (LW@...O-electronics.de):
> On Thu, 8 Mar 2018 16:38:32 +0100 Martin Kaiser wrote:
> > Hi Lothar,
> > Thus wrote Lothar Waßmann (LW@...O-electronics.de):
> > > > diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> > > > index 9725705..cf70df2 100644
> > > > --- a/arch/arm/boot/dts/imx25.dtsi
> > > > +++ b/arch/arm/boot/dts/imx25.dtsi
> > > > @@ -269,6 +269,7 @@
> > > > dmas = <&sdma 24 1 0>,
> > > > <&sdma 25 1 0>;
> > > > dma-names = "rx", "tx";
> > > > + fsl,fifo-depth = <15>;
> > > > status = "disabled";
> > > > };
> > > > @@ -329,6 +330,7 @@
> > > > dmas = <&sdma 28 1 0>,
> > > > <&sdma 29 1 0>;
> > > > dma-names = "rx", "tx";
> > > > + fsl,fifo-depth = <15>;
> > > > status = "disabled";
> > > > };
> > > You are changing the global .dtsi file. Did you test this change with
> > > all devices that are affected by it?
> > I changed the hardware description of the imx25 SSI to match the
> > reference manual.
> > I did test this change on an imx25 board with audio playback. This uses
> > the SSI description I modified. I verified that the driver is actually
> > taking the modified setting into account and that this causes no
> > problems.
> > As of today, this setting is used by the fsl_ssi driver to set the fifo
> > water level for dma requests.
> > Of course, I don't have access to the enitre range of supported imx25
> > boards and I don't think this is required for submitting patches.
> > Do you have any indication why this patch should not be merged?
> Usually patches should not willy-nilly change the behaviour of existing
> configurations unless they fix any real life bugs.
We both made our points, let the maintainer decide what to do with the
patch.
Thanks & Best regards,
Martin
Powered by blists - more mailing lists