From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: oprofile and ARM A9 hardware counter
Date: Tue, 08 May 2012 14:22:22 -0700 [thread overview]
Message-ID: <87sjfal65t.fsf@ti.com> (raw)
In-Reply-To: <4FA9588E.9020906@ti.com> (Jon Hunter's message of "Tue, 8 May 2012 12:31:58 -0500")
Jon Hunter <jon-hunter@ti•com> writes:
> Hi Benoit,
>
> On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
>
> [...]
>
>>>>> P.S. Please note there is also already a different fix in mainline for
>>>>> the EMU clkdm data from Paul which adds the force wakeup flag and
>>>>> removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
>>>>> because the hardware is capable.)
>>>>
>>>> Hmmm ... yes saw this, and you will have to excuse me as I don't fully
>>>> follow the logic here. In fact, I am thinking we want the opposite ;-)
>>>>
>>>> From looking, into this it seems to me that when PMU is running we want
>>>> the EMU clock domain in software-wakeup state and when PMU is not
>>>> running we want in the hardware auto state.
>>>
>>> So far, I'm with you.
>>>
>>>> By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
>>>> domain it is put right back into the HW_AUTO state
>>>
>>> This is only because it was in the HWSUP state when _enable was called.
>>> If clkdm_deny_idle() is used, that behavior will change.
>>>
>>>> and hence PMU is
>>>> not working (see _enable() function in
>>>> arch/arm/mach-omap2/omap_hwmod.c)
>>>>
>>>> So really what I think we want is to remove the ENABLE_AUTO flag to keep
>>>> the clock domain in software wake-up and use the DISABLE_AUTO flag to
>>>> put the clock domain back in HW_AUTO (note this requires a patch to
>>>> perform this 2nd part).
>>>
>>> Well, Paul will have to comment here for the final word, but IIUC, the
>>> hwmod flags are supposed to indicate only what the HW is capable of. If
>>> we want to change the runtime behavior, we nee to use (or add) APIs to
>>> change the beahvior. In this case, clkdm_allow_idle(),
>>> clkdm_deny_idle() are probably what is needed here.
>>
>> Yes, indeed, we should not hack the flags to fix that kind of issue. The
>> flags describe what the HW is capable of, and the EMU CD can support
>> HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
>> only valid next power state is OFF, meaning that no retention mode is
>> supported. So any transition to idle will go to OFF and lead to a reset
>> upon wakeup.
>
> No hacking intended here, just getting the flags correct ;-)
>
> So let me start from the beginning ...
>
> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
> SW_WKUP.
>
> 2. When the EMU CD is active (due to something like PMU), we want to
> keep the CD in the SW_WKUP state, otherwise we can automatically
> transition to idle and reset the IP (at least for omap4430).
> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
> state because SW_SLEEP is NOT supported.
>
> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
> set then the omap_pm_clkdms_setup() function will place the CD into
> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
> hwmod _enable() is called it is in the HW_AUTO state and so it is
> allowed to idle. This is not what we want. Do you agree?
>
> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
> then I do not have the above problem.
>
> To be honest, with you the more I look and test the code, the more
> confused I am by the definition of the CLKDM_CAN_HWSUP ...
>
> #define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
>
> When I look at where these flags are used, I see that
> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
>
> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
>
> Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as "The automatic hardware-supervised mode is disabled"
What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
mode as supported by the EMU. It seems to me that if the IP supports
HW_AUTO, it should be able to be enabled *and* disabled.
Maybe Paul/Benoit can clarify.
Kevin
next prev parent reply other threads:[~2012-05-08 21:22 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAO=S0+L2Q1YZC-pfm2Lz8jPooTeHYOMaZbtRgHYFoL_m7rvhA@mail.gmail.com>
[not found] ` <4F0B182D.7060507@us.ibm.com>
2012-01-09 22:49 ` oprofile and ARM A9 hardware counter Will Deacon
2012-01-09 23:30 ` Ming Lei
2012-01-10 0:46 ` stephane eranian
2012-01-18 4:18 ` Ming Lei
2012-01-18 9:33 ` Ming Lei
2012-01-18 11:39 ` Shilimkar, Santosh
2012-01-18 12:24 ` Ming Lei
2012-01-18 12:33 ` Shilimkar, Santosh
2012-04-03 9:25 ` Will Deacon
2012-04-03 9:42 ` Shilimkar, Santosh
2012-04-03 9:47 ` Will Deacon
2012-04-03 10:01 ` Shilimkar, Santosh
2012-04-03 12:34 ` Will Deacon
2012-04-03 12:41 ` Shilimkar, Santosh
2012-04-03 14:27 ` Kevin Hilman
2012-04-03 16:07 ` Will Deacon
2012-04-03 23:14 ` Kevin Hilman
2012-04-03 23:29 ` Paul Walmsley
2012-04-04 3:42 ` Ming Lei
2012-04-04 11:15 ` Will Deacon
2012-04-26 18:07 ` Will Deacon
2012-04-30 22:25 ` Kevin Hilman
2012-05-07 17:27 ` Ming Lei
2012-05-04 22:17 ` Jon Hunter
2012-05-07 17:15 ` Kevin Hilman
2012-05-07 19:53 ` Jon Hunter
2012-05-07 23:28 ` Kevin Hilman
2012-05-08 11:01 ` Cousson, Benoit
2012-05-08 11:23 ` Jean Pihet
2012-05-08 12:37 ` Cousson, Benoit
2012-05-08 13:18 ` Jean Pihet
2012-05-08 14:00 ` Kevin Hilman
2012-05-08 14:03 ` Cousson, Benoit
2012-05-08 16:18 ` Kevin Hilman
2012-05-08 19:51 ` Jon Hunter
2012-05-08 21:28 ` Kevin Hilman
2012-05-08 22:20 ` Jon Hunter
2012-05-08 22:12 ` Ming Lei
2012-05-08 17:31 ` Jon Hunter
2012-05-08 21:22 ` Kevin Hilman [this message]
2012-05-08 23:59 ` Jon Hunter
2012-05-09 10:58 ` Cousson, Benoit
2012-05-09 18:04 ` Jon Hunter
2012-05-09 19:28 ` Jon Hunter
2012-05-09 21:45 ` Jon Hunter
2012-05-10 8:44 ` Will Deacon
2012-05-10 9:12 ` stephane eranian
2012-05-10 18:55 ` Jon Hunter
2012-05-11 12:25 ` Will Deacon
2012-05-11 13:47 ` Jon Hunter
2012-05-11 13:49 ` Will Deacon
2012-05-11 14:52 ` Jon Hunter
2012-05-11 15:02 ` Will Deacon
2012-05-11 16:31 ` Jon Hunter
2012-05-11 16:38 ` Will Deacon
2012-05-11 23:51 ` Jon Hunter
2012-05-15 13:52 ` Will Deacon
2012-05-10 14:12 ` Kevin Hilman
2012-05-10 19:05 ` Jon Hunter
2012-05-10 6:59 ` Santosh Shilimkar
2012-05-08 21:50 ` Paul Walmsley
2012-04-04 0:00 ` Paul Walmsley
2012-04-04 11:07 ` Will Deacon
2012-01-18 9:54 ` stephane eranian
2012-01-18 10:07 ` Ming Lei
2012-01-18 21:58 ` stephane eranian
2012-01-19 1:21 ` Ming Lei
2012-01-19 11:34 ` stephane eranian
2012-01-19 12:45 ` Ming Lei
2012-01-19 12:51 ` stephane eranian
2012-01-19 12:55 ` stephane eranian
2012-01-19 13:14 ` Ming Lei
2012-01-19 13:26 ` Ming Lei
2012-01-19 13:32 ` stephane eranian
2012-01-19 13:51 ` Ming Lei
2012-01-19 17:07 ` stephane eranian
2012-01-20 13:47 ` stephane eranian
2012-01-21 3:25 ` Ming Lei
2012-01-21 9:16 ` stephane eranian
2012-01-27 12:13 ` Will Deacon
2012-01-27 12:45 ` stephane eranian
2012-01-27 12:56 ` Måns Rullgård
2012-01-27 13:28 ` Will Deacon
2012-01-27 13:32 ` stephane eranian
2012-01-27 13:47 ` Måns Rullgård
2012-01-27 13:56 ` Will Deacon
2012-01-27 14:05 ` Måns Rullgård
2012-01-27 14:09 ` Ming Lei
2012-01-27 15:45 ` stephane eranian
2012-01-27 15:54 ` Will Deacon
2012-01-27 15:57 ` stephane eranian
2012-01-27 16:59 ` Will Deacon
2012-01-27 17:03 ` stephane eranian
2012-01-27 17:10 ` Will Deacon
2012-01-27 17:16 ` stephane eranian
2012-01-29 17:36 ` stephane eranian
2012-01-30 9:40 ` Ming Lei
2012-01-30 10:24 ` stephane eranian
2012-01-30 13:43 ` stephane eranian
2012-01-30 14:49 ` Ming Lei
2012-01-30 16:02 ` stephane eranian
2012-01-30 16:08 ` Måns Rullgård
2012-01-30 17:15 ` stephane eranian
2012-01-30 17:24 ` Will Deacon
2012-01-30 17:45 ` stephane eranian
2012-01-30 19:14 ` Will Deacon
2012-01-30 20:45 ` stephane eranian
2012-03-07 2:49 ` Ming Lei
2012-03-07 9:48 ` Will Deacon
2012-01-27 14:06 ` Ming Lei
2012-01-18 10:18 ` Russell King - ARM Linux
[not found] <1328578047.1724.17.camel@dave-Dell-System-XPS-L502X>
[not found] ` <CAMQu2gwfo5JXAqQaLUNs7C7J3TUhEO2zOcyD0Rk-D_O61Yrfag@mail.gmail.com>
[not found] ` <CAMsRxfLNBbQO5XF+EHJqNsnW+s=ay3mjSV5dh=sxdwzktUu03g@mail.gmail.com>
[not found] ` <CAMQu2gzfNAwtf1c6jrTZpfGMSqBgBrQKmFTeCFzbvMh9ESBDUg@mail.gmail.com>
[not found] ` <CAMsRxfKR1ODH56BtcUT5Dv6qOVEYGVheEcW9ugXsZmLKok==bg@mail.gmail.com>
2012-02-07 10:53 ` Shilimkar, Santosh
2012-02-07 11:09 ` Shilimkar, Santosh
2012-02-07 11:25 ` stephane eranian
2012-02-07 11:39 ` Shilimkar, Santosh
2012-02-07 11:59 ` stephane eranian
2012-02-07 15:30 ` Will Deacon
2012-02-08 2:24 ` Ming Lei
2012-02-15 16:38 ` Peter Zijlstra
2012-02-16 10:25 ` Ming Lei
2012-02-16 15:00 ` Will Deacon
2012-02-16 16:12 ` Ming Lei
2012-02-16 16:19 ` Peter Zijlstra
2012-02-16 16:37 ` Ming Lei
2012-02-16 18:08 ` Will Deacon
2012-02-17 5:24 ` Ming Lei
2012-02-17 10:26 ` Will Deacon
2012-02-20 3:19 ` Ming Lei
2012-02-20 9:44 ` Will Deacon
2012-02-13 13:15 ` Will Deacon
[not found] ` <1329508513.1858.15.camel@dave-Dell-System-XPS-L502X>
2012-02-18 4:31 ` Shilimkar, Santosh
2012-04-03 9:44 ` Will Deacon
2012-04-03 9:47 ` Shilimkar, Santosh
[not found] ` <CACVXFVN0E_deS2d50mfufO5QZSwh=34BppCL++oxtc3nfN_ugA@mail.gmail.com>
[not found] ` <1328664644.1678.15.camel@dave-Dell-System-XPS-L502X>
2012-02-09 20:05 ` David A. Long
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=87sjfal65t.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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