[PATCH 1/3] ARM: omap_device: handle first time activation of console device
b-cousson at ti.com
Thu Nov 17 04:52:44 EST 2011
On 11/17/2011 8:19 AM, Rajendra Nayak wrote:
>>> +static int omap_console_hwmod_enable(struct omap_device *od)
>>> + console_lock();
>>> + /*
>>> + * For early console we prevented hwmod reset and idle
>> A period is missing. Or maybe it should a comma with not capital letter.
>>> + * So before we enable the uart clocks idle the console
>>> + * uart clocks, then enable back the console uart hwmod.
>>> + */
>>> + omap_hwmod_idle(od->hwmods);
>>> + omap_hwmod_enable(od->hwmods);
>> Why do we have to idle -> enable? The module is already enabled, isn't
>> The comment is not super clear for me :-)
>> Is the goal is to reset the IP?
> Yes, now that I read it, it does sound confusing. I should have at-least
> read it once before I picked it from serial.c
> But anyway, here's what the problem is.
> I feel its partly to do with the inability of hwmod to handle some
> modules which are left enabled post a setup, due to the
> 'HWMOD_INIT_NO_IDLE' flag set.
> Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post
> a setup. Now when a driver for such devices/modules tries to enable the
> module the first time, hwmod throws up a big WARN stating the hwmod is
> already in an enabled state.
OK, now, that makes sense :-)
We have hwmod in ENABLE state whereas the omap_device is still in IDLE
or even DISABLE.
> [uart used as console is one such module, which cannot be idled post a
> setup by hwmod]
> If hwmod could be made in some way intelligent enough to know that the
> module is in enabled state because of the 'HWMOD_INIT_NO_IDLE' itself,
> a lot of this hackery might not be needed at all.
Fully agree, the fmwk should handle that.
> Simplest way to do it could be to just add another intermediate state,
> something like '_HWMOD_STATE_ENABLED_AT_INIT'.
> I will post a patch for this, see if you like it being handled that way.
That seems to be good. I'm just wondering if we need to introduce a new
state for that or use a dedicated flag.
My concern is just that we will have two flavors of HWMOD_STATE_ENABLED
that we will have to check in various places in the hwmod core code.
Maybe that's not such a big deal. Go ahead, and we will see how it looks
> The other part of the problem is also with the inability to hook up
> 'custom' omap_device_pm_latency for omap devices created from DT.
> Maybe a lot of such cases which need custom activate/deactivate
> functions might have to be handled in some way in the framework
> itself like the one above.
For the moment, it looks like only the serial is requiring such custom
stuff, but anyway, we should have a mechanism to allow that...
More information about the linux-arm-kernel