From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756402AbbI2Mbe (ORCPT ); Tue, 29 Sep 2015 08:31:34 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:59762 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753227AbbI2MbY (ORCPT ); Tue, 29 Sep 2015 08:31:24 -0400 From: Arnd Bergmann To: Peter Griffin Cc: linux-arm-kernel@lists.infradead.org, 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 14:30:46 +0200 Message-ID: <1842713.tkjrhSVazj@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150929121155.GA17986@griffinp-ThinkPad-X1-Carbon-2nd> References: <1441980871-24475-1-git-send-email-peter.griffin@linaro.org> <35211759.Jca4RWVLIS@wuerfel> <20150929121155.GA17986@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:sIwE6RANNuP8fRIShyBME47d8JSskik/yxcQnLupHuLnTcJOtV4 0Kk6qOJWsWW+uaFJjaJSHsnzjiUjl4b1Kz5wxTFI1qBBAzdUXlVTmkXGDR0o04sJRc9kgQw 3IX8B6W51um660oWnVHw6tWZik6fKHZ/4TRxwQNd91c7BwSnW84Da9CT9q5d6plP+c0KVDK oV2GKOX1phUkZjKMVOq1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:pAIW78PeOJ4=:CkxJFDNxfT2Pn0hP+EU/2L ojrr2rd70sCO2IPEfJDS7Jj81AVxeUj6Badtt7I55ci85IugJxzQtOzN4fTY/RMwsRlxv5bBz D0e4qHOhbfNgjdPCiR49zq80ClartZsONZoCpX4ITLz3C6U8mbot60zbaRWOVjbUAgxBuArGF 0GHDo2H/nwaAPQ9BcjXdG09CIACZLH44KoCJ75LKsAF6eD+4QdYml9P918xeL69te7lxgn75l wU+Ud8fZkpbIM42yRMlaWsLRUUIoeCSA7KblIoy0pp7G3iaCshP/zhKWHE3J8UBV1VgLJgf/0 okHyYBgXXHQAepH8CTa7sdP7Z/cYgs4eQw7Yzept4GXuwlHeqnOB1W98RuU6N2bi54wrnMz7A EaiXMR3J10rIXelL2viwacUnYX+UIaBHEUesC9pjOj2iTvTUkxfpSfwfk9V4JdhNgcDUH+tD8 qbD5WZmH2lTIjwEWrdplADGPzW2XixRrlgNGLXZYlCFgvXVTiSl3OnUu/gP32vyhQGRydb9tn VXg6KDWMtL+z1OYd4nZCM1APwwDImdQf4yRXkfN4YEbkt7hJ/0EXI32M7W3Gw67bDwWeQPtde 4H1rtvN9GJ5tyG+gsL+okx9nrez2qLOjgm4SynWg+drz9F/5BazIwwYF7R9+CI+4URinEHLTv ekQWCK5xihKpLaN9cTTfGrJWWs4GrQxIL+N8MGW3LS01WN2gj/cEAJmDIrNMtu74CHd0LmbcQ IpZXv85wePAd9sbX Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote: > Hi Arnd, > > On Tue, 29 Sep 2015, Arnd Bergmann wrote: > > > 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, > > Does it? I didn't think it did. > > Using the instance number as a DT property defers the decision over what firmware to > load to the driver, which can choose whatever firmware name it wishes. > > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain > unchanged, but the use of that fdma instance has changed. > > We currently only have one firmware for each instance with the "use" compiled into it. > If in the future we had two firmwares with different "uses" for the same instance some extra > logic would be required in the driver to make a decision on which firmware to load. Ok, I probably need some more background about what the firmware on this device does, and what it could do with a different firmware. Could you elaborate? > > 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. > > The code which makes this decision currently is the st_fdma.c driver. However it does > need to know which fdma controller it is operating on to make this decision correctly. > > Apart from passing the fdma instance number in DT, how else can we determine which > controller we are? > > I guess we could infer it by having a table in the driver containing the base addresses > of the controllers for a given SoC, and match that against what DT passes us in the > reg property. But that seems ugly, and is encoding the same information in two > different places. > > I'm open to suggestions if there is a better way to do this. Using the address would be the same thing, that doesn't change the fundamental logic. Can you explain why it matters which instance a firmware is used on for this driver? Arnd