From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCHv2] ARM: socfpga: dts: Add support for SD/MMC Date: Fri, 09 Aug 2013 16:58:18 -0600 Message-ID: <5205740A.50206@wwwdotorg.org> References: <1375735392-6836-1-git-send-email-dinguyen@altera.com> <5203FC1A.3090903@wwwdotorg.org> <1375993920.22740.9.camel@linux-builds1> <5204017A.1040607@wwwdotorg.org> <1375995281.22740.16.camel@linux-builds1> <520409F2.1090906@wwwdotorg.org> <1376003457.22740.25.camel@linux-builds1> <52055867.9000602@wwwdotorg.org> <1376088088.14580.4.camel@linux-builds1> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from avon.wwwdotorg.org ([70.85.31.133]:35901 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031379Ab3HIW6X (ORCPT ); Fri, 9 Aug 2013 18:58:23 -0400 In-Reply-To: <1376088088.14580.4.camel@linux-builds1> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Dinh Nguyen Cc: cjb@laptop.org, dinh.linux@gmail.com, Jaehoon Chung , Seungwon Jeon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On 08/09/2013 04:41 PM, Dinh Nguyen wrote: > On Fri, 2013-08-09 at 15:00 -0600, Stephen Warren wrote: >> On 08/08/2013 05:10 PM, Dinh Nguyen wrote: >>> On Thu, 2013-08-08 at 15:13 -0600, Stephen Warren wrote: >> ... >>>> Why is there a need to directly represent the divider anywhere? The >>>> driver can find the rate of the input clock, and I assume it knows what >>>> rate it wants the clock to run at, so can't it calculate the divider >>>> based on those two pieces of information? >>> >>> CC: Chris Ball >>>> >>>> Or, does the driver really not know what rate it wants the clock to be >>>> after the internal divider? If not, then I think that *rate* should be >>>> recorded in DT, not the divider to obtain that rate. >>>> >>> >>> I believe that this is the case, that the driver does not know what rate >>> it will clock the SD card at. I think internally we did have a "bus_hz" >>> in DT a while back. I guess I don't really understand why it would be >>> better to have a *rate* DT entry instead of a fixed-divider entry? >> >> The value of the divider depends on two things: >> >> 1) Input clock rate. >> 2) Desired rate after applying the internal divider. >> >> The input clock rate may vary, either between SoCs the IP is integrated >> into, or even at run-time perhaps base on clk_set_rate() etc. >> >> If the MMC driver knows the clock rate it wants to run at, it can >> calculate the divider easily; it can automatically adjust to any input >> clock that its environment may provide. >> >> If the MMC driver is simply told "use this divider", that's encoding >> assumptions about the rate of the input clock which might not be valid;. >> Encoding the desire clock rate within the MMC HW block allows the >> divider to be calculated based on the actual environment. > > Thanks Stephen. That makes sense. > > Chris, Jaehoon, and Seungwon, do you have any inputs? If not I will go > down the path of have the "bus-hz" in the DTS node for the clock rate of > the CIU clock. Then I would also make the same change to dw_mmc-exynos > but would need your help on what the rate would be. > > For SOCFPGA, its 12.5 MHZ. I'm not sure "bus-hz" is the right name; it's not clear from that name that it refers to an internal clock inside the MMC controller rather than the SD bus out to the card itself. Perhaps "controller-clock-hz" or something like that?