From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritesh Harjani Subject: Re: [PATCH v5 03/12] mmc: sdhci-msm: add pltfm_data support to get clk-rates from DT Date: Mon, 7 Nov 2016 16:51:18 +0530 Message-ID: <552c5d3e-6b9b-abd1-4a56-0630288aa050@codeaurora.org> References: <1475678440-3525-1-git-send-email-riteshh@codeaurora.org> <1475678440-3525-4-git-send-email-riteshh@codeaurora.org> <20161010125738.GA26940@rob-hp-laptop> <1a7f9c09-70a6-da2a-ca84-78a0331e3b4d@codeaurora.org> <9db96ae7-9a5e-1494-2371-e5b346a08155@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org To: Rob Herring Cc: Ulf Hansson , "linux-mmc@vger.kernel.org" , Adrian Hunter , Shawn Lin , David Brown , Andy Gross , "devicetree@vger.kernel.org" , linux-arm-msm , georgi.djakov@linaro.org, alex.lemberg@sandisk.com, mateusz.nowak@intel.com, Yuliy.Izrailov@sandisk.com, asutoshd@codeaurora.org, David Griego , Sahitya Tummala , venkatg@codeaurora.org, Stephen Boyd , Bjorn Andersson , pramod.gurav@linaro.org, Rajendra Nayak List-Id: devicetree@vger.kernel.org Hi Rob, On 10/11/2016 6:01 PM, Rob Herring wrote: > On Tue, Oct 11, 2016 at 4:06 AM, Ritesh Harjani wrote: >> Hi Rob >> >> >> On 10/11/2016 12:59 AM, Rob Herring wrote: >>> >>> On Mon, Oct 10, 2016 at 11:07 AM, Ritesh Harjani >>> wrote: >>>> >>>> Hi Rob, >>>> >>>> Thanks for review. >>>> >>>> On 10/10/2016 6:27 PM, Rob Herring wrote: >>>>> >>>>> >>>>> On Wed, Oct 05, 2016 at 08:10:31PM +0530, Ritesh Harjani wrote: >>>>>> >>>>>> >>>>>> This adds support for sdhc-msm controllers to get supported >>>>>> clk-rates from DT. sdhci-msm would need it's own set_clock >>>>>> ops to be implemented. For this, supported clk-rates needs >>>>>> to be populated in sdhci_msm_pltfm_data. >>>>>> >>>>>> Signed-off-by: Ritesh Harjani >>>>>> --- >>>>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + >>>>>> drivers/mmc/host/sdhci-msm.c | 48 >>>>>> ++++++++++++++++++++++ >>>>>> 2 files changed, 49 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>>> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>>> index 485483a..6a83b38 100644 >>>>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>>> @@ -17,6 +17,7 @@ Required properties: >>>>>> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) >>>>>> (required) >>>>>> "core" - SDC MMC clock (MCLK) (required) >>>>>> "bus" - SDCC bus voter clock (optional) >>>>>> +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units >>>>>> - >>>>>> Hz. >>>>> >>>>> >>>>> >>>>> Why can't some combination of assigned-clock-rates and querying the >>>>> clock provider for rates be used here? >>>> >>>> >>>> From what I understood, assigned-clock-rates would only work for setting >>>> some default clock rates for certain clocks by calling >>>> of_clk_set_defaults. >>>> >>>> Whereas the requirement here is - >>>> That since SDHC msm directly controls the clk(core clock) at source, it's >>>> sdhci-msm driver needs to know the supported clk-rates by the underlying >>>> platform to configure the nearest floor value supported on this platform >>>> (when the request arrives from the core layer to switch the clock). >>> >>> >>> Why does clk_round_rate not work for you? That will round down to the >>> nearest frequency supported. >> >> clk_round_rate will round off to nearest supported "ceil" frequency. >> But we require nearest rounded off "floor" frequency. > > Then fix the clk framework to do what you want. This doesn't need to be in DT. Sure. Discussed with clk driver. Will make the required changes in qcom clk driver to fix this. Will soon publish the new series. > > Rob > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project