From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Subject: Re: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR Date: Tue, 20 Dec 2011 19:38:09 +0530 Message-ID: <4EF096C9.1070808@ti.com> References: <1324303533-17458-1-git-send-email-aneesh@ti.com> <4EEFC23A.30201@gmail.com> <20111219233559.GW6464@atomide.com> <4EF0671B.7090508@ti.com> <4EF0824A.9060208@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EF0824A.9060208@ti.com> Sender: linux-omap-owner@vger.kernel.org To: "Cousson, Benoit" Cc: Tony Lindgren , Rob Herring , devicetree-discuss@lists.ozlabs.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org Hi Benoit On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote: > Hi Aneesh, > >>>> In general, is it really feasible to parse the DTB before DDR is >>>> initialized? >>> >>> Changing timings is still needed for DVFS during runtime. >>> >>> But we can boot to userspace with bootloader set timings, so I'm >> >> As far as I understand, in the current out-of-tree DVFS implementation >> for OMAP, DVFS can start even before user-space. > > Maybe it is the case, but that does not mean it should. > We can potentially delay the DVFS init until the user-space is started. > This should not be considered as a big constraint. > >>> thinking that maybe these timings should be just set by loadable >>> modules. Just the configuration of which timings to select should >>> be passed via DT. Something in compatible like: >>> >>> .compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6"; >>> >>> And that should allow the SDRC driver to only accept timings for >>> "sdram-micron-mt46h32m32lf-6". >> >> Do you mean one module per memory device and have all timing data in >> the respective module? Wouldn't this clutter the kernel proper with all >> these tables. By having the timing data in DT, it can be eventually >> moved out of kernel eventually, right? > > Yes, that's the theory, but referring to Olof's point, this is not > necessarily the goal of DT to store all the information that are not > board dependent. > In this case, each DDR will have it sets of well known AC timings data > that will never depend of the board config. In this case, storing that > inside DT might not be the best solution. > > In fact we always had the same kind of discussion for the pinmux data > and for the clock data... > > The conclusion being that most of the static data does not have to be in > the DTS. > But since Linus was complaining about the huge amount of data inside the > kernel, it is not obvious what the best solution is:-) Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong. br, Aneesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: aneesh@ti.com (Aneesh V) Date: Tue, 20 Dec 2011 19:38:09 +0530 Subject: [RFC v2 PATCH 0/3] dt: device tree bindings and data for EMIF and DDR In-Reply-To: <4EF0824A.9060208@ti.com> References: <1324303533-17458-1-git-send-email-aneesh@ti.com> <4EEFC23A.30201@gmail.com> <20111219233559.GW6464@atomide.com> <4EF0671B.7090508@ti.com> <4EF0824A.9060208@ti.com> Message-ID: <4EF096C9.1070808@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Benoit On Tuesday 20 December 2011 06:10 PM, Cousson, Benoit wrote: > Hi Aneesh, > >>>> In general, is it really feasible to parse the DTB before DDR is >>>> initialized? >>> >>> Changing timings is still needed for DVFS during runtime. >>> >>> But we can boot to userspace with bootloader set timings, so I'm >> >> As far as I understand, in the current out-of-tree DVFS implementation >> for OMAP, DVFS can start even before user-space. > > Maybe it is the case, but that does not mean it should. > We can potentially delay the DVFS init until the user-space is started. > This should not be considered as a big constraint. > >>> thinking that maybe these timings should be just set by loadable >>> modules. Just the configuration of which timings to select should >>> be passed via DT. Something in compatible like: >>> >>> .compatible = "ti,omap3630", "sdram-micron-mt46h32m32lf-6"; >>> >>> And that should allow the SDRC driver to only accept timings for >>> "sdram-micron-mt46h32m32lf-6". >> >> Do you mean one module per memory device and have all timing data in >> the respective module? Wouldn't this clutter the kernel proper with all >> these tables. By having the timing data in DT, it can be eventually >> moved out of kernel eventually, right? > > Yes, that's the theory, but referring to Olof's point, this is not > necessarily the goal of DT to store all the information that are not > board dependent. > In this case, each DDR will have it sets of well known AC timings data > that will never depend of the board config. In this case, storing that > inside DT might not be the best solution. > > In fact we always had the same kind of discussion for the pinmux data > and for the clock data... > > The conclusion being that most of the static data does not have to be in > the DTS. > But since Linus was complaining about the huge amount of data inside the > kernel, it is not obvious what the best solution is:-) Hmm.. I get the point now. Linus' complaint is what I had in mind too. My humble opinion is to have such data in DTS but re-use it as much as possible. That is, we could have something like a "sdram-micron- mt46h32m32lf-6.dtsi"(as you suggested before) that can be included by board level DTS files. I think the fact that dts files are organized at arch level today is limiting such re-use. Please correct me if I am wrong. br, Aneesh