public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* hwmod, postsetup_state, omap_device and !CONFIG_PM_RUNTIME
@ 2011-07-12 23:51 Kevin Hilman
  0 siblings, 0 replies; only message in thread
From: Kevin Hilman @ 2011-07-12 23:51 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: Tony Lindgren, linux-omap

With CONFIG_PM_RUNTIME disabled, we have a few problems due to the
current way of handling the postsetup_state of each hwmod.

The primary one is that the omap_hwmod internal startup state does not
match the omap_device internal state.  For example, with
!CONFIG_PM_RUNTIME, all the hwmods are left enabled (and the bootup
state is OMAP_HWMOD_STATE_ENABLED.)

However, omap_device doesn't know this, so the first call
omap_device_enable() will generate the noisy warnings:

omap_device_enable()
    /* Here, the omap_device default state is 0x0: UNKNOWN */
    deactivate_func -> omap_device_enable_hwmods()
        omap_hwmod_enable()
            /* WARN is hit since state is already enabled */           


A second one is where device init code is directly calling
omap_hwmod_enable()  (e.g. in omap_dm_timer_init_one()).  This code has
no way of knowing that the device was left enabled due to the
postsetup_state, so calls like this to omap_hwmod_* fail with the noisy
warnings from the hwmod core.

I haven't dug too much into how to handle this, but wanted to post this
to see if anyone has any good ideas about how to handle it.

Kevin


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2011-07-12 23:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-12 23:51 hwmod, postsetup_state, omap_device and !CONFIG_PM_RUNTIME Kevin Hilman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox