[PATCH] ARM: dts: i.MX25: define SSI FIFO depth

Lucas Stach l.stach at pengutronix.de
Fri Mar 9 01:27:12 PST 2018


Hi Lothar,

Am Freitag, den 09.03.2018, 09:37 +0100 schrieb Lothar Waßmann:
> Hi,
> 
> On Thu, 8 Mar 2018 16:38:32 +0100 Martin Kaiser wrote:
> > Hi Lothar,
> > 
> > > > Thus wrote Lothar Waßmann (LW at KARO-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.

With this logic we wouldn't be able to get most driver changes applied.
If it is matching the reference manual and has been tested on the
affected hardware it should be good to go.

If you know about any specific corner cases that might break with this
change, please speak up now. Don't reject patches based on the
overarching "it might break something" argument.

Regards,
Lucas



More information about the linux-arm-kernel mailing list