Re: [PATCH 2/2] ARM64: mt8173: dts Add MT8173 cpufreq driver support
From: Pi-Cheng Chen
Date: Fri Apr 24 2015 - 03:09:30 EST
Hi Mark,
Thanks for reviewing.
On Thu, Apr 23, 2015 at 8:53 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> On Mon, Apr 20, 2015 at 10:27:27AM +0100, pi-cheng.chen wrote:
>> This patch adds voltage supplies and clocks used by MT8173 cpufreq driver.
>>
>> Signed-off-by: pi-cheng.chen <pi-cheng.chen@xxxxxxxxxx>
>
> This series has no bindings for these properties.
Will add documents for these.
>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 9 +++++++++
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index 96e141c..7a00cfe 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -330,3 +330,12 @@
>> status = "okay";
>> clock-frequency = <100000>;
>> };
>> +
>> +&cpu0 {
>> + proc-supply = <&mt6397_vpca15_reg>;
>> +};
>> +
>> +&cpu2 {
>> + proc-supply = <&da9211_vcpu_reg>;
>> + sram-supply = <&mt6397_vsramca7_reg>;
>> +};
>
>
> Why do only two CPUs have these properties, and why does one need an
> sram-supply?
For better description of hardware, I think putting these properties in all CPUs
share the same supplies is logical.
For each cluster of MT8173, we have both PROC and SRAM supplies. But only
on one cluster (cpu2 and cpu3) we need to control both voltage supplies. The
SRAM supply on cpu0 cluster is controlled by hardware automatically. Therefore
I put sram-supply only on cpu2. For better description of hardware, it
might be a
good idea to put the SRAM supply in cpu0 also though we don't use it in the
driver, right?
>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d9cc84e..b8a5454 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -51,6 +51,9 @@
>> device_type = "cpu";
>> compatible = "arm,cortex-a53";
>> reg = <0x000>;
>> + clocks = <&infracfg INFRA_CA53SEL>,
>> + <&apmixedsys APMIXED_MAINPLL>;
>> + clock-names = "cpu", "intermediate";
>> };
>>
>> cpu1: cpu@1 {
>> @@ -65,6 +68,9 @@
>> compatible = "arm,cortex-a57";
>> reg = <0x100>;
>> enable-method = "psci";
>> + clocks = <&infracfg INFRA_CA57SEL>,
>> + <&apmixedsys APMIXED_MAINPLL>;
>> + clock-names = "cpu", "intermediate";
>> };
>
> We should really describe this information per-cpu rather than assuming
> that it's the same for siblings. Arbitrarily making one CPU in each
> cluster (or other arbitrary grouping) special for the binding is silly.
Yes, I agree with you and same above. I did these because most of the
platforms in kernel did these. So should I do it the way you suggest?
Thanks.
Best Regards,
Pi-Cheng
>
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/