[PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420

Thomas Abraham ta.omasab at gmail.com
Tue Sep 2 21:26:32 PDT 2014


Hi Kevin,

On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman <khilman at kernel.org> wrote:
> HI Thomas,
>
> Thomas Abraham <ta.omasab at gmail.com> writes:
>
>> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman at kernel.org> wrote:
>>> Hi Thomas,
>>>
>>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab at gmail.com> wrote:
>>>> Hi Kevin,
>>>>
>>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman at linaro.org> wrote:
>>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman at linaro.org> wrote:
>>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander at samsung.com> wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>
>>>>>>>> Can you clarify how you're setting the voltages to ensure stability?
>>>>>>>
>>>>>>> below is the diff :  wip/exynos/integ
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at
>>>>>> 1500mV, but still when booting with cpuidle enabled (bL switcher
>>>>>> disabled), I'm seeing lockups with no kernel output.  With CPUidle
>>>>>> disabled, things are pretty stable.
>>>>>>
>>>>>> What tree are you using to test this out on 5420?  I'm using mainline
>>>>>> v3.17-rc1 + DT patch for CPUidle and this cpufreq series.  See my
>>>>>> wip/exynos/integ branch at
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git.
>>>>>
>>>>> I mis-stated this.  Actually my tree is based on the v3.17-rc1 branch
>>>>> of the exynos-reference tree[1] + the above mentioned patches for
>>>>> cpuidle and cpufreq.
>>>>>
>>>>> Also, I've narrowed down the instability a bit, and it's not related
>>>>> to CPUidle.  I can now trigger a boot hang even without CPUidle
>>>>> enabled.  Here's a quick way to cause a boot lockup. With the switcher
>>>>> disabled, I enable CPUfreq and set the default governor to
>>>>> performance.  As soon as cpufreq driver loads, it tries to use the top
>>>>> frequences for both clusters, and it hangs.
>>>>>
>>>>> Selectively disabling frequencies, I narrowed it down to the 1.3GHz
>>>>> and 1.2GHz frequencies of the little cluster.  With these commented
>>>>> out in the DT, it will fully boot with the performance governor
>>>>> enabled.
>>>>>
>>>>> So that leads to the question.  Are all of the operating points in
>>>>> exynos5420.dtsi valid for exynos5800, and have they been validated?
>>>>
>>>> I tried to recreate the boot lockup issue using the same steps you
>>>> listed above for the Exynos5800 peach-pi platform (Chromebook2), but I
>>>> do not see any issues. I can see both clusters with max clock speed
>>>> after boot (1.8GHz and 1.3GHz).
>>>>
>>>> I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support
>>>> patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7
>>>> voltage to 1.3V.
>>>
>>> Can you share your branch and temp hack(s) as well as your defconfig?
>>>
>>> I'm using the v3.17-rc1 branch from the exynos tree (which includes
>>> the max77802 series) but also has a bunch of other stuff which may be
>>> causing the issue.
>>>
>>> It would be good if I can reproduce your exact tree/branch and see if
>>> I still have the same problem.
>>
>> The branch with the patches that have been used to test cpufreq on
>> Exynos5800 is available at
>>
>> https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq
>>
>> Please let me know if this works or if there are any issues.
>
> Yes, your branch works fine, but it's because of the last (unposted)
> patch on your branch[1]:
> ARM: dts: remove all supplies sourced from tps65090 PMIC

I must have explicitly stated that I am using local changes to get
vdd_arm and vdd_kfc to required levels. I apologize for that. These
are local temporary changes which I did not want to post. I am working
on adding voltage scaling support in arm bL cpufreq driver with which
these local hacks would not be necessary.

>
> That patch had not been posted, so I hadn't seen it before, but based on
> the changelog, it's pretty clear you had the same problems that I had
> without it, so I'm not sure why it wasn't mentioned earlier in this
> thread.

At the time of posting, this patch series was only tested on
Exynos5420 based smdk5420 board. There was no regulator support for
peach-pit and peach-pi at that time and so I had not tested this
series on Exynos5800 Chromebook2. But the code was written to be fully
compatible for Exynos5800 as well. It was when you reported a problem
with Exynos5800 that I tested this series on Exynos5800 with the
regulator patches from Javier.

>
> I also noticed that the "force vdd_arm and vdd_kfc to max voltage" patch
> is not actually using the max voltage, which appears to be 1.5V from the
> DT, but actually using 1.35 V, however the changelog has no explanation
> for this.

This also is a temporary patch and by "max voltage" I actually meant
max voltage required to operate the cpus and not the max voltage that
the buck can supply.

>
> One other thing, your temp-cpufreq branch has conflicts with max77802
> stuff in the v3.17-rc1 branch of the exynos-reference tree (which I'm
> using for CPUidle dependencies, on the PMU series IIRC.)

I haven't checked but probably there is an older version of Javier's
regulator patches in the v3.17-rc1 branch.

>
> Are there any plans to update the main referece branch and include
> cpufreq?

Yes, a new branch with all the latest patches (cpufreq + regulator +
temp fixes) will be created. I will let you when that is ready.

Thanks,
Thomas.

>
> Kevin
>
> [1] https://github.com/exynos-reference/kernel/commit/f08be7e4296a3452ee5d1aae31e3de5bbff2cf1a



More information about the linux-arm-kernel mailing list