On 29 January 2015 at 21:52, Rob Herring <robherring2@xxxxxxxxx> wrote:
> On Fri, Jan 23, 2015 at 4:44 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
>> - Getting clock sharing information between CPUs. Single shared clock vs
>> independent clock per core vs shared clock per cluster.
>
> I'd like to see acks from Qualcomm folks to make sure this works for them.
@Stephen: Can I have your inputs as well here?
>> + Required properties:
>> + - opp-khz: Frequency in kHz
>> + - opp-microvolt: voltage in micro Volts
>
> This can be optional as it is valid to have frequency scaling without
> voltage scaling. More so for bus scaling than cpu scaling.
Right.
>> + Optional properties:
>> + - opp-intermediate: Stable opp we *must* switch to, before switching to the
>> + target opp. Contains phandle of one of the opp-node present in opp-list.
>
> What about cases where perhaps you have a more complex sequencing
> arrangement? For example, what if you have to hit each step (to go
> from A -> D you have to go A -> B -> C -> D). Perhaps each OPP could
> have an opp-next property which lists other OPPs you can transition to
> (and no property means no restriction).
I haven't seen such examples yet but yeah that might be required
at some point of time.
> Do you have a specific user in mind? If not, I think we can defer this
> issue. I think the binding is flexible enough to accommodate this in
> the future.
Yeah, Tegra and Mediatek already need it. Even cpufreq core does
support it currently.
What about keeping it as is for now and extending to opp-next in case
it is required. Or maybe add opp-next right now. So, for the case of
single intermediate-freq, all OPPs except the intermediate one will have
opp-next set to intermediate opp. And intermediate opp doesn't fill this.
I will think about it a bit more though.
>> + cpu0_opp: opp0 {
>> + compatible = "linux,cpu-dvfs";
>
> As I said before, drop the linux part. I'm not sure about cpu-dvfs
> either. Nothing is specific to cpus and you are necessarily doing
> voltage scaling. You could want to find all cpu OPPs though. Perhaps:
> "cpu-operating-point", "operating-point";
What about "operating-point-v2", as that's the real version.
> It is not documented either.
Will do.
>> + cpu1_opp: opp1 {
>> + compatible = "linux,cpu-dvfs";
>> + opp-list = <&cpu0_opplist>;
>> + opp-intermediate = <&cpu0_intermediate>;
>> + };
>
> This doesn't add anything other than some indirection to imply
> independent OPPs. The only way I know the clocks are not shared is you
> told me so in the example. I'd still prefer to determine from the
Will document that clearly.
> clock api whether 2 clocks can be changed independently. That didn't
Mike Turquette has objected to that earlier and so we moved
to DT to find this out..
> seem to be agreed on, so you could simply add a "shared-opp" property
> to opp0 to mark an OPP as shared or not. Then you can remove the
> opp-list and these other cpuX_opp nodes.
Okay.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
