From mboxrd@z Thu Jan 1 00:00:00 1970 From: rnayak@ti.com (Rajendra Nayak) Date: Fri, 16 Dec 2011 16:33:08 +0530 Subject: [PATCH v3] ARM: OMAP2+: hwmod: Add a new state to handle hwmods left enabled at init In-Reply-To: References: <1321877570-4333-1-git-send-email-rnayak@ti.com> Message-ID: <4EEB256C.6030306@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Paul, On Friday 16 December 2011 04:07 PM, Paul Walmsley wrote: > On Mon, 21 Nov 2011, Rajendra Nayak wrote: > >> > An 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 hwmod framework throws a WARN() about >> > the device being already in enabled state. >> > >> > Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT' >> > to identify such devices/hwmods. When the device/hwmod >> > is requested to be enabled (the first time) by its driver/user, >> > nothing except the mux-enable and a state change to '_HWMOD_STATE_ENABLED' >> > is needed. The mux data is board specific and is unavailable during >> > initial enable() of the device, done by the framework as part of >> > setup(). >> > >> > 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. >> > >> > Acked-by: Kevin Hilman >> > Acked-by: Benoit Cousson >> > Signed-off-by: Rajendra Nayak > I've tweaked this patch a little bit, mostly to avoid adding a new state, > which increases the complexity of the rest of the code that handles the > hwmod state machine. The modified patch below just uses an internal flag. > Please let me know if you have any comments. Looks good to me. thanks, Rajendra