From: jon-hunter@ti•com (Jon Hunter)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
Date: Mon, 16 Jul 2012 13:27:35 -0500 [thread overview]
Message-ID: <50045D17.9050704@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207131418500.25585@utopia.booyaka.com>
Hi Paul,
On 07/13/2012 04:00 PM, Paul Walmsley wrote:
[...]
>> Unfortunately, although this works it does make the flags a bit less
>> clearer. The upside is the solution is simpler.
>
> Yeah, the problem is the clockdomain CLKDM_CAN_* flags are just intended
> to represent the available bits from the register bitfield, rather than a
> higher-level concept. Among other things, it allows the maintainers and
> users of this code to verify it by comparing it to the TRM. Changing the
> CLKDM_CAN_* flags in the kernel is not actually that simple since it
> involves overriding the hardware data for the EMU clockdomain for every
> applicable chip. In other words, it just moves the complexity
> elsewhere.
Yes I see that makes sense. However, patch #7 has already changed the
mapping of the flags. I had intended that patch #7 and #8 would be
applied together. However, I could see that patch #7 can be taken just
to eliminate using the SW_SLEEP state. So basically, what I am saying is
does patch #7 have any value without #8?
>> I am not sure if it is really a matter of the clock domain missing the
>> idle reporting, but more of a problem that the EMU power domain power
>> state is programmed in HW to OFF and cannot be changed by software. (see
>> POWER_STATE field of PM_EMU_PWRSTCTRL register description in the TRM).
>>
>> This means that when the EMU clock domain does idle, the EMU power
>> domain can transition to OFF and hence we loss the EMU logic context. So
>> we need to keep the EMU CLKDM on to keep the EMU PWRDM on, but it is
>> really the lack of control we have over the PWRDM that is the problem. I
>> would not say this is a HW bug but more of a design choice probably to
>> keep the design simpler at the expense of power.
>
> I really wonder how much more difficult it would have been to add the
> ON state to the EMU powerdomain next-power-state control bitfields...
True, probably a good area for us to provide some feedback to the
designers.
>> I believe that this problem would happen to all power domains if they
>> were programmed for the OFF power state when the clock domain idled. For
>> other power domains we avoid this by programming them to the ON state
>> when we are using them.
>
> Hmm. In the case of most other clockdomains, we have some way to indicate
> to the PRCM whether the IP block/clock is in use or not: functional clock
> control bits or modulemode control bits or CLKACTIVITY bits or (in the
> worst case) SIDLEMODE bits. We don't really have any of these control
> mechanisms for most of the EMU clockdomain IP blocks/clocks.
>
> From a theoretical perspective, assigning the problem solely to the
> powerdomain next-power-state bits might also ignore the impact on
> clockdomain dependencies. These take effect based on the clockdomain
> activity state, rather than powerdomain next-power-states. Although, for
> the specific case of the EMU clockdomains on OMAP3/4, it looks like this
> is not a practical problem according to the TRM.
Ok, yes I understand your point of view.
>> Thanks for the detailed suggestion! Adding a flag to prevent programming
>> the HW_AUTO while the CLKDM is active could definitely work (although I
>> may change the name/description of the flag a little).
>
> Sure, let me know what you think of the above reasoning.
I would say it is fair (with limited knowledge of the h/w design
decisions made here).
>> Another proposal I also thought of is re-working the flags to describe
>> the HW mode to be used when turning on the CLKDM, when the CLKDM is
>> active and when the CLKDM is shut down. So instead of saying what modes
>> the CLKDM supports, specify what modes should be used for pre-ON (i.e.
>> turn ON), ON and OFF. Right now software is trying to decide for us by
>> what is available (which is ideal) but makes working around such nuances
>> a little more painful.
>
> With the hardware data, it would be good to keep it something that can be
> generated with as little human intervention as possible, except in the
> case of bug workarounds or departures from standard practice. The idea is
> to reduce the amount of human interaction needed to generate data to
> support new chips, when everything works as it should. It also allows us
> software forks to explicitly mark unusual quirks or bugs that we'd like
> the hardware people to change for future revisions :-)
That's fine with me. We can always workaround such issues by adding flags.
I can give this a try this week and let you know how it goes.
I think that Benoit is out until the end of the month. I am not sure if
he will have any inputs.
Cheers
Jon
next prev parent reply other threads:[~2012-07-16 18:27 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 21:22 [PATCH V2 00/10] ARM: OMAP4: Add PMU Support Jon Hunter
2012-06-07 21:22 ` [PATCH V2 01/10] ARM: PMU: Add runtime PM Support Jon Hunter
2012-06-08 9:47 ` Will Deacon
2012-06-08 14:17 ` Jon Hunter
2012-06-08 15:24 ` Jon Hunter
2012-06-11 17:39 ` Will Deacon
2012-06-11 19:01 ` Jon Hunter
2012-06-12 9:28 ` Will Deacon
2012-06-12 21:17 ` Jon Hunter
2012-06-12 21:31 ` Will Deacon
2012-06-12 22:41 ` Jon Hunter
2012-07-02 9:55 ` Will Deacon
2012-07-02 16:50 ` Jon Hunter
2012-07-02 22:01 ` Will Deacon
2012-07-06 0:40 ` Jon Hunter
2012-07-26 0:41 ` Jon Hunter
2012-07-26 15:05 ` Will Deacon
2012-07-26 15:16 ` Jon Hunter
2012-07-31 15:14 ` Will Deacon
2012-07-31 23:07 ` Jon Hunter
2012-08-01 20:47 ` Will Deacon
2012-08-01 22:34 ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 02/10] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD Jon Hunter
2012-06-07 21:22 ` [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS Jon Hunter
2012-06-13 6:07 ` Pandita, Vikram
2012-06-13 6:13 ` Pandita, Vikram
2012-06-13 6:19 ` Shilimkar, Santosh
2012-06-07 21:22 ` [PATCH V2 04/10] ARM: OMAP4430: Create PMU device via HWMOD Jon Hunter
2012-06-07 21:22 ` [PATCH V2 05/10] ARM: OMAP2+: PMU: Add runtime PM support Jon Hunter
2012-06-07 21:22 ` [PATCH V2 06/10] ARM: OMAP4: Route PMU IRQs to CTI IRQs Jon Hunter
2012-06-07 21:22 ` [PATCH V2 07/10] ARM: OMAP4: CLKDM: Update supported transition modes Jon Hunter
2012-07-04 15:38 ` Paul Walmsley
2012-07-05 17:14 ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use Jon Hunter
2012-07-12 21:17 ` Paul Walmsley
2012-07-13 13:54 ` Jon Hunter
2012-07-13 14:00 ` Will Deacon
2012-07-13 14:07 ` Jon Hunter
2012-07-20 22:24 ` Jon Hunter
2012-07-13 21:00 ` Paul Walmsley
2012-07-16 18:27 ` Jon Hunter [this message]
2012-07-16 18:38 ` Paul Walmsley
2012-07-16 19:38 ` Jon Hunter
2012-07-20 22:24 ` Jon Hunter
2012-07-30 23:26 ` Jon Hunter
2012-07-31 4:36 ` Jon Hunter
2012-07-31 18:16 ` Jon Hunter
2012-08-01 0:20 ` Jon Hunter
2012-08-01 15:08 ` Paul Walmsley
2012-08-01 18:17 ` Jon Hunter
2012-08-01 15:36 ` Paul Walmsley
2012-08-01 19:41 ` Jon Hunter
2012-08-02 7:34 ` Shilimkar, Santosh
2012-10-08 22:24 ` Jon Hunter
2012-10-09 4:41 ` Paul Walmsley
2012-07-31 20:56 ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 09/10] ARM: OMAP4: Enable PMU for OMAP4460/70 Jon Hunter
2012-06-07 21:22 ` [PATCH V2 10/10] ARM: OMAP2+: PMU: Add QoS constraint Jon Hunter
2012-06-07 23:36 ` [PATCH V2 00/10] ARM: OMAP4: Add PMU Support Jon Hunter
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=50045D17.9050704@ti.com \
--to=jon-hunter@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