Hi, On Fri, 09 Mar 2018 10:27:12 +0100 Lucas Stach wrote: > 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@xxxxxxxxxxxxxxxxxxx): > > > > > > > > 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. > I didn't reject anything, I just wanted to make sure, that the implications of this patch were sufficiently considered. Lothar Waßmann -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
