omap4 and cpufreq

omap4 and cpufreq

[Joachim Eastwood]

Hi,

I am bringing up a OMAP4460 board on dt and I saw the following messages
in the kernel log from "cpufreq-cpu0".
[ 2.373352] cpufreq_cpu0: failed to get cpu0 regulator: -19
[ 2.379302] cpufreq_cpu0: failed to get cpu0 clock: -2
[ 2.384704] cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2

Failure to get the clock is because OMAP4 seems to be lacking a "cpu0" entry
in cclock44xx_data.c. Adding "CLK("cpu0", NULL, &dpll_mpu_ck)," to
"omap44xx_clks" seems to do the trick. This is what OMAP3 has anyways. Think
this failure was caused by commit 60c5fc86d which switched from
"omap-cpufreq" to "cpufreq-cpu0" driver on dt boot.

As far as I can see it makes cpufreq work again. I at least get the
cpufreq nodes in sysfs and can play around with them.

Should I submit a patch for cclock44xx_data.c adding "cpu0"?

Next up is the regulator. Since my board is a 4460 and it seems that
tps63261 support for 4460 never made it to mainline I guess I am out of
luck here?

But for all 4430 boards in mainline I guess it would be nice to add:
&twl {
    vdd1: regulator-vdd1 {
        compatible = "ti,twl6030-vdd1";
        regulator-min-microvolt = <1000000>;
        regulator-max-microvolt = <1400000>;
    };
};
cpus {
    cpu@0 {
        cpu0-supply = <&vdd1>;
    };
};

I assume this would work but I don't have a 4430 board to test it on.
Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
points for cpu in omap443xx.dtsi.

regards
Joachim Eastwood

Re: omap4 and cpufreq

[Nishanth Menon]

On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
> Hi,
> 
> I am bringing up a OMAP4460 board on dt and I saw the following messages
> in the kernel log from "cpufreq-cpu0".
> [ 2.373352] cpufreq_cpu0: failed to get cpu0 regulator: -19
> [ 2.379302] cpufreq_cpu0: failed to get cpu0 clock: -2
> [ 2.384704] cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2
> 
> Failure to get the clock is because OMAP4 seems to be lacking a "cpu0" entry
> in cclock44xx_data.c. Adding "CLK("cpu0", NULL, &dpll_mpu_ck)," to
> "omap44xx_clks" seems to do the trick. This is what OMAP3 has anyways. Think
> this failure was caused by commit 60c5fc86d which switched from
> "omap-cpufreq" to "cpufreq-cpu0" driver on dt boot.

This is part of the transition to device tree based clock nodes. See:
https://bugzilla.kernel.org/show_bug.cgi?id=58541

for details.
> 
> As far as I can see it makes cpufreq work again. I at least get the
> cpufreq nodes in sysfs and can play around with them.
> 
> Should I submit a patch for cclock44xx_data.c adding "cpu0"?
No. cclock44xx_data is on the way to be dead.

> 
> Next up is the regulator. Since my board is a 4460 and it seems that
> tps63261 support for 4460 never made it to mainline I guess I am out of
> luck here?
> 
> But for all 4430 boards in mainline I guess it would be nice to add:
> &twl {
>     vdd1: regulator-vdd1 {
>         compatible = "ti,twl6030-vdd1";
>         regulator-min-microvolt = <1000000>;
>         regulator-max-microvolt = <1400000>;
>     };
> };
> cpus {
>     cpu@0 {
>         cpu0-supply = <&vdd1>;
>     };
> };
> 
> I assume this would work but I don't have a 4430 board to test it on.
> Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
> points for cpu in omap443xx.dtsi.
This will not work. 6030 does not allow voltage to be set over i2c1,
needs voltage controller/processor to work.





-- 
Regards,
Nishanth Menon

Re: omap4 and cpufreq

[Joachim Eastwood]

On 6 January 2014 17:28, Nishanth Menon <nm@ti.com> wrote:
> On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
>> Hi,
>>
>> I am bringing up a OMAP4460 board on dt and I saw the following messages
>> in the kernel log from "cpufreq-cpu0".
>> [ 2.373352] cpufreq_cpu0: failed to get cpu0 regulator: -19
>> [ 2.379302] cpufreq_cpu0: failed to get cpu0 clock: -2
>> [ 2.384704] cpufreq-cpu0: probe of cpufreq-cpu0.0 failed with error -2
>>
>> Failure to get the clock is because OMAP4 seems to be lacking a "cpu0" entry
>> in cclock44xx_data.c. Adding "CLK("cpu0", NULL, &dpll_mpu_ck)," to
>> "omap44xx_clks" seems to do the trick. This is what OMAP3 has anyways. Think
>> this failure was caused by commit 60c5fc86d which switched from
>> "omap-cpufreq" to "cpufreq-cpu0" driver on dt boot.
>
> This is part of the transition to device tree based clock nodes. See:
> https://bugzilla.kernel.org/show_bug.cgi?id=58541
>
> for details.
>>
>> As far as I can see it makes cpufreq work again. I at least get the
>> cpufreq nodes in sysfs and can play around with them.
>>
>> Should I submit a patch for cclock44xx_data.c adding "cpu0"?
> No. cclock44xx_data is on the way to be dead.
>
>>
>> Next up is the regulator. Since my board is a 4460 and it seems that
>> tps63261 support for 4460 never made it to mainline I guess I am out of
>> luck here?
>>
>> But for all 4430 boards in mainline I guess it would be nice to add:
>> &twl {
>>     vdd1: regulator-vdd1 {
>>         compatible = "ti,twl6030-vdd1";
>>         regulator-min-microvolt = <1000000>;
>>         regulator-max-microvolt = <1400000>;
>>     };
>> };
>> cpus {
>>     cpu@0 {
>>         cpu0-supply = <&vdd1>;
>>     };
>> };
>>
>> I assume this would work but I don't have a 4430 board to test it on.
>> Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
>> points for cpu in omap443xx.dtsi.
> This will not work. 6030 does not allow voltage to be set over i2c1,
> needs voltage controller/processor to work.

Well, it allows the LDO regulators to be changed over i2c, but I guess
the SMPS regulators are different.



Anyways, thanks for the information and bugzilla link with links to
the patch postings on the mailing list.


regards
Joachim Eastwood

Re: omap4 and cpufreq

[Nishanth Menon]

On 01/06/2014 03:51 PM, Joachim Eastwood wrote:
> On 6 January 2014 17:28, Nishanth Menon <nm@ti.com> wrote:
>> On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
[...]
>>> I assume this would work but I don't have a 4430 board to test it on.
>>> Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
>>> points for cpu in omap443xx.dtsi.
>> This will not work. 6030 does not allow voltage to be set over i2c1,
>> needs voltage controller/processor to work.
> 
> Well, it allows the LDO regulators to be changed over i2c, but I guess
> the SMPS regulators are different.

yes, they are different control paths. To give a relative history:

(OMAP3)TWL5030 -> we can control SMPS from either i2c1 OR i2c_SR by
flipping a control bit - but only one path at a time.
(OMAP4)TWL6030 -> only i2c_SR control allowed for SMPS
(OMAP5)Palmas family -> we can control using i2c1 or i2c_SR -> so no
real need for using voltage controller for SMPS.

that said, it is necessary to use SR path to ensure that AVS also
functions. which requires on OMAP4,3 to use i2c_SR.

> 
> 
> 
> Anyways, thanks for the information and bugzilla link with links to
> the patch postings on the mailing list.

Glad to be of help.

-- 
Regards,
Nishanth Menon

Re: omap4 and cpufreq

[Joachim Eastwood]

On 6 January 2014 23:02, Nishanth Menon <nm@ti.com> wrote:
> On 01/06/2014 03:51 PM, Joachim Eastwood wrote:
>> On 6 January 2014 17:28, Nishanth Menon <nm@ti.com> wrote:
>>> On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
> [...]
>>>> I assume this would work but I don't have a 4430 board to test it on.
>>>> Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
>>>> points for cpu in omap443xx.dtsi.
>>> This will not work. 6030 does not allow voltage to be set over i2c1,
>>> needs voltage controller/processor to work.
>>
>> Well, it allows the LDO regulators to be changed over i2c, but I guess
>> the SMPS regulators are different.
>
> yes, they are different control paths. To give a relative history:
>
> (OMAP3)TWL5030 -> we can control SMPS from either i2c1 OR i2c_SR by
> flipping a control bit - but only one path at a time.
> (OMAP4)TWL6030 -> only i2c_SR control allowed for SMPS
> (OMAP5)Palmas family -> we can control using i2c1 or i2c_SR -> so no
> real need for using voltage controller for SMPS.
>
> that said, it is necessary to use SR path to ensure that AVS also
> functions. which requires on OMAP4,3 to use i2c_SR.

I see.

Just one question regarding the tps63261 on 4460.
What good is the gpio pin most boards have connected to the tps
regulator (vsel1) when it can be controlled with i2c_SR?

I have seen the pin being used in the u-boot code. So is it just for
initial boot or would Linux also use it as well?

>>
>> Anyways, thanks for the information and bugzilla link with links to
>> the patch postings on the mailing list.
>
> Glad to be of help.

Thanks a lot.

I'll go read up on all the patches you posted.

Good luck with the upstreaming effort :)

regards
Joachim Eastwood

Re: omap4 and cpufreq

[Nishanth Menon]

On 01/06/2014 04:24 PM, Joachim Eastwood wrote:
> On 6 January 2014 23:02, Nishanth Menon <nm@ti.com> wrote:
>> On 01/06/2014 03:51 PM, Joachim Eastwood wrote:
>>> On 6 January 2014 17:28, Nishanth Menon <nm@ti.com> wrote:
>>>> On 01/01/2014 04:37 PM, Joachim Eastwood wrote:
>> [...]
>>>>> I assume this would work but I don't have a 4430 board to test it on.
>>>>> Unsure about voltage range, but at least 1.0 to 1.4V covers the operation
>>>>> points for cpu in omap443xx.dtsi.
>>>> This will not work. 6030 does not allow voltage to be set over i2c1,
>>>> needs voltage controller/processor to work.
>>>
>>> Well, it allows the LDO regulators to be changed over i2c, but I guess
>>> the SMPS regulators are different.
>>
>> yes, they are different control paths. To give a relative history:
>>
>> (OMAP3)TWL5030 -> we can control SMPS from either i2c1 OR i2c_SR by
>> flipping a control bit - but only one path at a time.
>> (OMAP4)TWL6030 -> only i2c_SR control allowed for SMPS
>> (OMAP5)Palmas family -> we can control using i2c1 or i2c_SR -> so no
>> real need for using voltage controller for SMPS.
>>
>> that said, it is necessary to use SR path to ensure that AVS also
>> functions. which requires on OMAP4,3 to use i2c_SR.
> 
> I see.
> 
> Just one question regarding the tps63261 on 4460.
> What good is the gpio pin most boards have connected to the tps
> regulator (vsel1) when it can be controlled with i2c_SR?


TPS63261 has two registers that could be used for voltage selection -
VSEL0, VSEL1. the reason for using GPIO to force select VSEL1 and do
dvfs using that register is as follows:
* MPU supports OPP50 which uses voltage lower than necessary for
booting the device up.
* boot voltage for vdd_mpu is hardcoded by default into VSEL0.
* if we were to use VSEL0 register for DVFS and then do a reboot OR
have a watchdog trigger at OPP50, the device will not boot up since
the voltage will be at OPP50 voltage.
* if we were to use VSEL1 register selected by GPIO for DVFS and then
do a reboot OR have a watchdog trigger at OPP50, GPIO is reset back to
selecting VSEL0 on TPS and the device will boot up since the voltage
will be at OPP_BOOT voltage.

Now, with additional discrete circuitry, it is possible to ensure that
TPS is also reset on a warm_reset trigger, but the additional cost for
discretes were not... umm... attractive for customer board designs.
(yet another instance of "if you can do it in software, why add
hardware cost?)..


> 
> I have seen the pin being used in the u-boot code. So is it just for
> initial boot or would Linux also use it as well?

eventually, yes - our product kernels have these ofcourse for reason
mentioned above - and when we get this code eventually in upstream, it
will have to support VSEL1 based operation.

-- 
Regards,
Nishanth Menon