From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Prashant Gaikwad <pgaikwad@nvidia.com>,
<linux-clk@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"
Date: Fri, 27 May 2016 13:46:37 +0100 [thread overview]
Message-ID: <574841AD.8090601@nvidia.com> (raw)
In-Reply-To: <6bfd97bc-7e09-973d-e3c3-7e86b08a4550@gmail.com>
On 26/05/16 18:01, Dmitry Osipenko wrote:
> On 26.05.2016 18:27, Jon Hunter wrote:
>> On 26/05/16 15:57, Dmitry Osipenko wrote:
...
>>> That's how I see it:
>>>
>>> +----------------------------------------------+
>>> | CPU 0 |
>>> +-------------------+--------------------------+
>>> | Idle thread | Interactive gov. thread |
>>> +----------------------------------------------+
>>> | inactive | |
>>> | | |
>>> | | CPU freq. change |
>>> | | |
>>> | | clk_set_rate() |
>>> | | |
>>> | ... | clk_prepare_lock() |
>>> | | |
>>> | | PRE rate notifier call |
>>> | | |
>>> | | schedule |
>>
>> What is this notifier doing? Is there some sort of hardware activity
>> that it is waiting for to complete?
>>
>
> It changes regulator voltage if required. So at least I2C would cause
> scheduling on wait_for_completion_timeout().
Yes, of course that would make sense. What is interesting/odd in this
case is that the frequency is increasing (voltage scaled pre frequency
change) but yet you are entering LP2. May be that is possible? I guess
this problem may also occur on reducing frequency as well?
What are you using in the v3.18 kernel for exit_latency and
target_residency? The current mainline has 5000us and 10000us,
respectively.
It does seem that this could be triggered in the right circumstances and
I have to say I don't like the fact that this could be fragile as it is
today. Have you thought about adding a post clock notifier for pclk in
the PMC driver as an alternative to the change you are suggesting?
Cheers
Jon
--
nvpublic
WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Prashant Gaikwad <pgaikwad@nvidia.com>,
linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"
Date: Fri, 27 May 2016 13:46:37 +0100 [thread overview]
Message-ID: <574841AD.8090601@nvidia.com> (raw)
In-Reply-To: <6bfd97bc-7e09-973d-e3c3-7e86b08a4550@gmail.com>
On 26/05/16 18:01, Dmitry Osipenko wrote:
> On 26.05.2016 18:27, Jon Hunter wrote:
>> On 26/05/16 15:57, Dmitry Osipenko wrote:
...
>>> That's how I see it:
>>>
>>> +----------------------------------------------+
>>> | CPU 0 |
>>> +-------------------+--------------------------+
>>> | Idle thread | Interactive gov. thread |
>>> +----------------------------------------------+
>>> | inactive | |
>>> | | |
>>> | | CPU freq. change |
>>> | | |
>>> | | clk_set_rate() |
>>> | | |
>>> | ... | clk_prepare_lock() |
>>> | | |
>>> | | PRE rate notifier call |
>>> | | |
>>> | | schedule |
>>
>> What is this notifier doing? Is there some sort of hardware activity
>> that it is waiting for to complete?
>>
>
> It changes regulator voltage if required. So at least I2C would cause
> scheduling on wait_for_completion_timeout().
Yes, of course that would make sense. What is interesting/odd in this
case is that the frequency is increasing (voltage scaled pre frequency
change) but yet you are entering LP2. May be that is possible? I guess
this problem may also occur on reducing frequency as well?
What are you using in the v3.18 kernel for exit_latency and
target_residency? The current mainline has 5000us and 10000us,
respectively.
It does seem that this could be triggered in the right circumstances and
I have to say I don't like the fact that this could be fragile as it is
today. Have you thought about adding a post clock notifier for pclk in
the PMC driver as an alternative to the change you are suggesting?
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2016-05-27 12:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-17 13:34 [PATCH] soc/tegra: pmc: Fix "scheduling while atomic" Dmitry Osipenko
2016-05-05 11:45 ` Dmitry Osipenko
2016-05-05 11:45 ` Dmitry Osipenko
2016-05-05 13:17 ` Jon Hunter
2016-05-05 13:17 ` Jon Hunter
2016-05-05 14:24 ` Dmitry Osipenko
2016-05-25 15:09 ` Jon Hunter
2016-05-25 15:09 ` Jon Hunter
2016-05-25 18:51 ` Dmitry Osipenko
2016-05-25 18:51 ` Dmitry Osipenko
2016-05-26 8:42 ` Jon Hunter
2016-05-26 8:42 ` Jon Hunter
2016-05-26 11:42 ` Dmitry Osipenko
2016-05-26 14:32 ` Jon Hunter
2016-05-26 14:32 ` Jon Hunter
2016-05-26 14:57 ` Dmitry Osipenko
2016-05-26 15:27 ` Jon Hunter
2016-05-26 15:27 ` Jon Hunter
2016-05-26 17:01 ` Dmitry Osipenko
2016-05-27 12:46 ` Jon Hunter [this message]
2016-05-27 12:46 ` Jon Hunter
2016-05-27 14:43 ` Dmitry Osipenko
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=574841AD.8090601@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=digetx@gmail.com \
--cc=gnurou@gmail.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--cc=pgaikwad@nvidia.com \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.