From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: omap_hwmod: Add a new state to handle hwmods left enabled at init
Date: Thu, 17 Nov 2011 17:23:28 +0530 [thread overview]
Message-ID: <4EC4F5B8.1070706@ti.com> (raw)
In-Reply-To: <4EC4E45B.5080106@ti.com>
On Thursday 17 November 2011 04:09 PM, Cousson, Benoit wrote:
> + Paul
>
> On 11/17/2011 11:11 AM, Rajendra Nayak wrote:
>> A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
>> enabled state by the hwmod framework post the initial setup.
>> Once a real user of the device (a driver) tries to enable it
>> at a later point, the hmwod framework throws a WARN() about
>
> typo: -------------------^
>
>> the device being already in enabled state.
>>
>> Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT'
>> to identify such devices/hwmods, so nothing but just a state
>> change to '_HWMOD_STATE_ENABLED' can be done when the device/hwmod
>> is requested to be enabled (the first time) by its driver/user.
>>
>> A good example of a such a device is an UART used as debug console.
>> The UART module needs to be kept enabled through the boot, until the
>> UART driver takes control of it, for debug prints to appear on
>> the console.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c | 16 ++++++++++++++--
>> arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
>> 2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index d7f4623..7d94cc3 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -1441,6 +1441,17 @@ static int _enable(struct omap_hwmod *oh)
>>
>> pr_debug("omap_hwmod: %s: enabling\n", oh->name);
>>
>> + /*
>> + * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left
>
> Is the ' needed here? But I'm not an expert in English grammar...
Me neither, lets ask Paul :)
>
>> + * in enabled state at init.
>> + * Now that someone is really trying to enable them,
>> + * just update the state.
>> + */
>> + if (oh->_state == _HWMOD_STATE_ENABLED_AT_INIT) {
>> + oh->_state = _HWMOD_STATE_ENABLED;
>> + return 0;
>> + }
>> +
>> if (oh->_state != _HWMOD_STATE_INITIALIZED&&
>> oh->_state != _HWMOD_STATE_IDLE&&
>> oh->_state != _HWMOD_STATE_DISABLED) {
>> @@ -1449,7 +1460,6 @@ static int _enable(struct omap_hwmod *oh)
>> return -EINVAL;
>> }
>>
>> -
>
> Not related to the patch changelog but that make senses to do it, so
> just update the changelog.
No, its just a stay change. I'll get rid of it.
>
>> /*
>> * If an IP contains only one HW reset line, then de-assert it in order
>> * to allow the module state transition. Otherwise the PRCM will return
>> @@ -1744,8 +1754,10 @@ static int _setup(struct omap_hwmod *oh, void
>> *data)
>> * it should be set by the core code as a runtime flag during startup
>> */
>> if ((oh->flags& HWMOD_INIT_NO_IDLE)&&
>> - (postsetup_state == _HWMOD_STATE_IDLE))
>> + (postsetup_state == _HWMOD_STATE_IDLE)) {
>> + oh->_state = _HWMOD_STATE_ENABLED_AT_INIT;
>> postsetup_state = _HWMOD_STATE_ENABLED;
>> + }
>>
>> if (postsetup_state == _HWMOD_STATE_IDLE)
>> _idle(oh);
>> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> index 1b81dfb..cd49d60 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> @@ -436,6 +436,7 @@ struct omap_hwmod_omap4_prcm {
>> #define _HWMOD_STATE_ENABLED 4
>> #define _HWMOD_STATE_IDLE 5
>> #define _HWMOD_STATE_DISABLED 6
>> +#define _HWMOD_STATE_ENABLED_AT_INIT 7
>
> You should update the comment before... yeah I know, the other states
> are not documented, but they are much more understandable than this new
> one.
Yeah, makes sense. Will add comments.
>
>> /**
>> * struct omap_hwmod_class - the type of an IP block
>
> +1 Looks good to me but someone else must approve...
> Oops, sorry its not Gerrit :-)
>
> Acked-by: Benoit Cousson <b-cousson@ti.com>
>
> Thanks,
> Benoit
next prev parent reply other threads:[~2011-11-17 11:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 10:11 [PATCH] ARM: omap_hwmod: Add a new state to handle hwmods left enabled at init Rajendra Nayak
2011-11-17 10:39 ` Cousson, Benoit
2011-11-17 11:53 ` Rajendra Nayak [this message]
2011-11-17 10:48 ` Govindraj
2011-11-17 19:35 ` Kevin Hilman
2011-11-18 6:44 ` Rajendra Nayak
2011-11-18 9:05 ` Cousson, Benoit
2011-11-18 17:55 ` Kevin Hilman
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=4EC4F5B8.1070706@ti.com \
--to=rnayak@ti.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).