From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964798AbbI2LSM (ORCPT ); Tue, 29 Sep 2015 07:18:12 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:49899 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934720AbbI2LSG (ORCPT ); Tue, 29 Sep 2015 07:18:06 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Peter Griffin , Lee Jones , devicetree@vger.kernel.org, vinod.koul@intel.com, srinivas.kandagatla@gmail.com, patrice.chotard@st.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Ludovic Barre , dmaengine@vger.kernel.org, maxime.coquelin@st.com Subject: Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation Date: Tue, 29 Sep 2015 13:17:20 +0200 Message-ID: <35211759.Jca4RWVLIS@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150929100440.GC16955@griffinp-ThinkPad-X1-Carbon-2nd> References: <1441980871-24475-1-git-send-email-peter.griffin@linaro.org> <20150914081937.GF27591@x1> <20150929100440.GC16955@griffinp-ThinkPad-X1-Carbon-2nd> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:MtJCG3ZolcDePawAq/7PnyNerO89jZUqEjPRea0NtkWXElypLmS seAnoG64NV/F0ztn12Qj1PrZSYmPOntBW+FDK5n2KW3puTlKbxYoKsHO/TBjEwXWNgA+c2b 2Yb4TN6JzlDCVcWeGDxYhDxUgXAghrPM7fDytI+pSMcbCvHxZI+m807qrTDuMj0PIWoYCG9 PVlyFKJGMNNkT6q0OqnyA== X-UI-Out-Filterresults: notjunk:1;V01:K0:i1fKfzp6lYc=:t5IOrucuoL0FxxOa/VPHKN 1EwyNoml5yeYKQDXFtzVNnQGkcqqT+fX2McgwagJROAw+rV9GdW6G83Et4ExJTDkedRBGSoRG KH2Em/raQJWEsFwkYUCFthkqPl1S9MVDYPAB7gL2HFxVHehlwbcJc1B3W4dgd9ZABPnY0tsvB RRAgOxPpnM9QWqpEh+Oyf+aAbtSB1CbnNy48SHZhXB9P9RNDqtC1zYRGMvh9wjP1Of6iq9qgc UDNs6rodqQebf5XPdwrRb2jYiCDpBe2cM+13O2uv71JkjWnGBBd0UZvTORtU7MsMPdj+yWthM pJmSYEGA63r9BugiV/WV4Yfa434Kx5MwBF+c6r8kxBqmoqsihQ1zI3MVWG6//gaWBP2rlITL9 CUzmN+IA8wTgc6fXlF/1K9eyHpsTGWT7+y7JA1J1btjO/D4loGEOKPxALf0TP5eu2DrbjAyu6 NfPdSRQGVBYPrVxebfIfVxUNxTsroKwBH5VgL4ultRt55tdH7xa2QfKIxTbP0wTQPCJBKA+V8 9qGi/GX4TtnC6zoQVi+EPPSatqoXGY8vgbdZCPvlS7EdjVZXeXbYy1+7tNhE6v20VXLtnGC7b ZDd8fh5TuPaf+ZQM6DaT26mVb6RJqZIQbUIjsmME4XWXOdtJKum7LWEqAP1nwJY0vWqydbjuy M6DVMKvOvKYLZRKlAnpUwQPwUXp98JQFfoNxxcevSDYYwR4VlyWWfEadd/rANPlf5dcPlzgX9 2Qr/fm/k6cE6iH+F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote: > > "The hardware is identical, and different firmware is used to apply > it in different ways." > > Which is the case with fdma. By encoding the "way you wish to apply it" into the > compatible string, it causes problems if you want to change for example fdma0 > to do some other function other than audio. > > You then require a DT update, (when the hardware hasn't changed, just the > firmware) which is the same problem as using the filename directly in DT. > > Therefore I believe it is important that the DT binding does *not* encode the > way the hardware is to be applied into the binding in *any* way, and defers this > decision to the driver. > That is the rationale / reasoning behind choosing the fdma instance number. > > Assuming you agree with my arguments above, then the choice becomes between > having a fdma instance DT property, or having lots of compatibles where the only > difference is the appending of the instance number. I think out of the two I prefer > my original approach. > > Any thoughts from the DT folks? To me both approaches sound wrong: basing the firmware name on the instance number requires that each instance is always used in the same way, which is not guaranteed to be the case, and you correctly describe the problem with using the compatible string for the firmware name if the driver for the FDMA does not actually care what firmware is being used here. Whatever code makes the decision as to how the FDMA is used should also decide on the name of the firmware file. You can have a mapping in the driver that contains the file names that are used by ST's distro, possibly with a fallback mechanism that tries more meaningful names first. Arnd