linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ta.omasab@gmail.com (Thomas Abraham)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Date: Wed, 3 Sep 2014 09:56:32 +0530	[thread overview]
Message-ID: <CAJuA9ahe=9gdTaGcRb69syvRfwkkGMgDiiNfOMA9TBo42cWVZw@mail.gmail.com> (raw)
In-Reply-To: <7hmwah6cop.fsf@paris.lan>

Hi Kevin,

On Wed, Sep 3, 2014 at 1:02 AM, Kevin Hilman <khilman@kernel.org> wrote:
> HI Thomas,
>
> Thomas Abraham <ta.omasab@gmail.com> writes:
>
>> On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman <khilman@kernel.org> wrote:
>>> Hi Thomas,
>>>
>>> On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>>>> Hi Kevin,
>>>>
>>>> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap <k.chander@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

  reply	other threads:[~2014-09-03  4:26 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30  8:07 [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Thomas Abraham
2014-07-30  8:07 ` [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks Thomas Abraham
2014-09-01 22:29   ` Mike Turquette
2014-09-02 13:53     ` Thomas Abraham
2014-07-30  8:07 ` [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock Thomas Abraham
2014-09-01 22:29   ` Mike Turquette
2014-07-30  8:07 ` [PATCH v9 3/6] ARM: dts: Exynos: add CPU OPP and regulator supply property Thomas Abraham
2014-07-30 11:28   ` Andreas Färber
2014-07-31  2:55     ` Thomas Abraham
2014-07-31  0:37   ` Doug Anderson
2014-07-31  3:21     ` Thomas Abraham
2014-07-31  3:53       ` Doug Anderson
2014-07-31  4:06         ` Thomas Abraham
2014-07-31  4:08           ` Doug Anderson
2014-07-31  4:18             ` Thomas Abraham
2014-08-02  3:49   ` Javier Martinez Canillas
2014-08-04  3:00     ` Thomas Abraham
2014-07-30  8:07 ` [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420 Thomas Abraham
2014-07-31 18:32   ` Kukjin Kim
2014-07-31 18:40     ` Tomasz Figa
2014-07-31 18:54       ` Tomasz Figa
2014-07-31 19:25         ` Thomas Abraham
2014-07-31 19:30           ` Tomasz Figa
2014-08-04  3:24             ` Thomas Abraham
2014-08-22 23:54       ` Kevin Hilman
2014-08-23  0:02         ` Tomasz Figa
2014-08-25  6:53           ` Lukasz Majewski
2014-08-25 12:15           ` Chander Kashyap
2014-08-25 15:32             ` Kevin Hilman
2014-08-25 15:56               ` Tomasz Figa
2014-08-26  4:54                 ` Viresh Kumar
2014-08-26  5:25               ` Chander Kashyap
2014-08-26 15:15                 ` Kevin Hilman
2014-08-26 22:25                   ` Kevin Hilman
2014-08-29 12:52                     ` Thomas Abraham
2014-08-29 15:03                       ` Kevin Hilman
2014-09-01  8:47                         ` Thomas Abraham
2014-09-02 19:32                           ` Kevin Hilman
2014-09-03  4:26                             ` Thomas Abraham [this message]
2014-09-03 13:18                               ` Thomas Abraham
2014-09-03 23:15                                 ` Kevin Hilman
2014-09-04 10:22                                   ` Thomas Abraham
2014-09-04 13:30                                     ` Kevin Hilman
2014-09-05 13:41                                       ` Thomas Abraham
2014-08-25  8:11         ` Sjoerd Simons
2014-07-30  8:07 ` [PATCH v9 5/6] cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support Thomas Abraham
2014-07-30  8:07 ` [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags Thomas Abraham
2014-07-31 14:13   ` Tomasz Figa
2014-07-31 18:24     ` Thomas Abraham
2014-07-31 18:35       ` Tomasz Figa
2014-07-31 18:41         ` Thomas Abraham
2014-07-31 18:46           ` Tomasz Figa
2014-07-31 18:49             ` Thomas Abraham
2014-09-01 22:31   ` Mike Turquette
2014-07-31  6:20 ` [PATCH v9 0/6] cpufreq: use generic cpufreq drivers for exynos platforms Chander M. Kashyap
2014-07-31 10:59   ` Thomas Abraham
2014-07-31 12:24     ` Chander M. Kashyap
2014-07-31 14:15 ` Tomasz Figa
2014-07-31 18:25   ` Thomas Abraham
2014-07-31 18:34     ` Thomas Abraham
2014-08-01  9:42       ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJuA9ahe=9gdTaGcRb69syvRfwkkGMgDiiNfOMA9TBo42cWVZw@mail.gmail.com' \
    --to=ta.omasab@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).