[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110111112240.GQ12078@pengutronix.de>
Date: Tue, 11 Jan 2011 12:22:40 +0100
From: Sascha Hauer <s.hauer@...gutronix.de>
To: Jeremy Kerr <jeremy.kerr@...onical.com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Ben Herrenchmidt <benh@...nel.crashing.org>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH 1/2] Add a common struct clk
On Tue, Jan 11, 2011 at 06:27:11PM +0800, Jeremy Kerr wrote:
> Hi Sascha,
>
> > The i.MX clk implementation disables the old parent if clk is enabled
> > and enables the new parent if clk is enabled (modulo bugs). Shouldn't
> > we do this here aswell?
>
> Sounds reasonable, yes.
>
> > I thought about returning -EBUSY if clk_set_parent is called for an
> > enabled clk, but this way we could never reparent the cpu clock which I
> > think is done in the Freescale BSP for power saving.
>
> I think that the possibility for changing the parent really depends on the
> implementation; in some cases we may want to disallow it, in others it might
> be fine.
>
> Related: do we really need globally-accessible clk_{get,set}_parent in the clk
> API? For cases where we need to set the parent, we probably need details about
> the platform clock configuration (eg, which clocks are possible parents). In
> this case, we could just call into the clock driver directly.
I agree that drivers have no business calling clk_{get,set}_parent, this
is purely platform specific.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists