Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1270049 > unrolled thread

Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock Ulf Hansson <ulf.hansson@linaro.org> - 2015-11-16 13:00 +0100
    Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock Stephen Boyd <sboyd@codeaurora.org> - 2015-11-18 02:40 +0100
      Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock Ulf Hansson <ulf.hansson@linaro.org> - 2015-11-18 09:10 +0100

#1270049 — Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

[...]

>> Ahh, I see.
>>
>> It seems like a reasonable assumption that the controller can't cope
>> with a higher clock rate than 100 MHz as "input" clock. That would
>> then mean that there are different versions of the controller, as it
>> seems like for some version it's fine with 200MHz and for some 100MHz.
>>
>> According to the DT compatible strings, *one* version is currently
>> supported, "qcom,sdhci-msm-v4"...
>
> The same version of hardware is there 4 times. The difference is
> the maximum clock frequency supported by them is different. In
> downstream kernels we've handled this by trimming the frequency
> tables for the different controllers in the clock driver.
> Setting the clock to INT_MAX will make it run at 400MHz, which
> doesn't look to be supported by anything besides sdc1 on 8974ac.
>
>>
>> I see two viable solutions. One would be to limit the clock rate
>> depending on the version of the controller (new compatible strings
>> needs to be added). Another one would be to limit the clock rate by
>> using the existing DT binding for max-frequency, and thus do a
>> clk_set_rate(mmc->f_max) during probe.
>>
>
> I'd rather see that done via OPP tables in DT, but I suppose
> max-frequency is fine too. We'll need to use OPPs soon enough
> because there's a voltage associated with that frequency.

Okay, thanks for sharing the details.

>
> In case you're wondering, the max frequency for sdc1 on 8974ac is
> 400MHz. If it's just a plain 8974pro then the max frequency is
> 200MHz. Otherwise, sdc2 maxes out at 200Mhz and sdc3 and sdc4 max
> out at 100MHz.

When you say that sdc1 supports 400MHz, what does that mean? That it
actually can cope with that clock rate when communicating with the MMC
card?

This makes me wonder how you deal with power management (DVFS).

For example when you have the possibility to gate this clock (at
request inactivity) when the rate is set to 400 MHz and OPP is
increased, how will then that clock gating affect the OPP?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1271806

On 11/16, Ulf Hansson wrote:
> [...]
> 
> 
> >
> > In case you're wondering, the max frequency for sdc1 on 8974ac is
> > 400MHz. If it's just a plain 8974pro then the max frequency is
> > 200MHz. Otherwise, sdc2 maxes out at 200Mhz and sdc3 and sdc4 max
> > out at 100MHz.
> 
> When you say that sdc1 supports 400MHz, what does that mean? That it
> actually can cope with that clock rate when communicating with the MMC
> card?

I suspect there must be some internal divider in the sdc IP
itself so that it doesn't put out 400MHz on the bus, but I really
don't know. What I mean is that the clock going into the IP from
the clock controller is running at 400MHz, after it goes into the
IP it could be divided, etc. before exiting the SoC on some pin.

> 
> This makes me wonder how you deal with power management (DVFS).
> 
> For example when you have the possibility to gate this clock (at
> request inactivity) when the rate is set to 400 MHz and OPP is
> increased, how will then that clock gating affect the OPP?

Sorry I'm not really following the question here. The gate will
disable the clock in the clock controller, cutting the signal off
upstream of the sdc IP. When we do DVFS we'll stop considering
this clock as part of the overall power level for the voltage
associated with the frequency. When all other clocks that are
using the same voltage and are on and running at frequencies that
don't need that high of voltage we can reduce the voltage and
drop down to something lower.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1271907

On 18 November 2015 at 02:38, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 11/16, Ulf Hansson wrote:
>> [...]
>>
>>
>> >
>> > In case you're wondering, the max frequency for sdc1 on 8974ac is
>> > 400MHz. If it's just a plain 8974pro then the max frequency is
>> > 200MHz. Otherwise, sdc2 maxes out at 200Mhz and sdc3 and sdc4 max
>> > out at 100MHz.
>>
>> When you say that sdc1 supports 400MHz, what does that mean? That it
>> actually can cope with that clock rate when communicating with the MMC
>> card?
>
> I suspect there must be some internal divider in the sdc IP
> itself so that it doesn't put out 400MHz on the bus, but I really
> don't know. What I mean is that the clock going into the IP from
> the clock controller is running at 400MHz, after it goes into the
> IP it could be divided, etc. before exiting the SoC on some pin.

Okay, got it!

>
>>
>> This makes me wonder how you deal with power management (DVFS).
>>
>> For example when you have the possibility to gate this clock (at
>> request inactivity) when the rate is set to 400 MHz and OPP is
>> increased, how will then that clock gating affect the OPP?
>
> Sorry I'm not really following the question here. The gate will
> disable the clock in the clock controller, cutting the signal off
> upstream of the sdc IP. When we do DVFS we'll stop considering
> this clock as part of the overall power level for the voltage
> associated with the frequency. When all other clocks that are
> using the same voltage and are on and running at frequencies that
> don't need that high of voltage we can reduce the voltage and
> drop down to something lower.

Sorry for being a bit vague, but you kind of answered my question, thanks!

I haven't been following DVFS evolution lately, but one of my earlier
concern was the how to use clk rate change notifiers to deal with OPP
transitions.

As in this case the clock rate would be fixed, and thus we can't use
the clk rate change notifiers to trigger an OPP change. But I guess
there is a solution to that then?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web