From: Richard Zhao <hidden> Date: 2011-11-11 01:10:15
Changes from V1:
- Add common helper functions clk_prepare_enable/clk_disable_unprepare
- serial/imx: move clk_disable_unprepare before clk_put
Thanks
Richard
@@ -60,9 +60,9 @@ static int imx_sata_init(struct device *dev, void __iomem *addr)dev_err(dev,"no sata clock.\n");returnPTR_ERR(sata_clk);}-ret=clk_enable(sata_clk);+ret=clk_prepare_enable(sata_clk);if(ret){-dev_err(dev,"can't enable sata clock.\n");+dev_err(dev,"can't prepare/enable sata clock.\n");gotoput_sata_clk;}
@@ -73,9 +73,9 @@ static int imx_sata_init(struct device *dev, void __iomem *addr)ret=PTR_ERR(sata_ref_clk);gotorelease_sata_clk;}-ret=clk_enable(sata_ref_clk);+ret=clk_prepare_enable(sata_ref_clk);if(ret){-dev_err(dev,"can't enable sata ref clock.\n");+dev_err(dev,"can't prepare/enable sata ref clock.\n");gotoput_sata_ref_clk;}
@@ -172,13 +172,13 @@ int mxc_audmux_v2_configure_port(unsigned int port, unsigned int ptcr,return-ENOSYS;if(audmux_clk)-clk_enable(audmux_clk);+clk_prepare_enable(audmux_clk);writel(ptcr,audmux_base+MXC_AUDMUX_V2_PTCR(port));writel(pdcr,audmux_base+MXC_AUDMUX_V2_PDCR(port));if(audmux_clk)-clk_disable(audmux_clk);+clk_disable_unprepare(audmux_clk);return0;}
Using 'else' here makes the code more readable IMO.
baruch
+ clk_unprepare(clk);
+
+ return ret;
+}
+
+static inline void clk_disable_unprepare(struct clk *clk)
+{
+ clk_disable(clk);
+ clk_unprepare(clk);
+}
+
/**
* clk_get_rate - obtain the current clock rate (in Hz) for a clock source.
* This is only valid once the clock source has been enabled.
--
1.7.5.4
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
As Baruch already pointed out this is hard to read. Also it contains a
bug. When clk_prepare fails clk_unprepare is called afterwards.
Hint: Kernel guys are not afraid of having multiple return statements
in a function, instead they like it when something is handled early
without having to read the rest of the function.
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 |
As Baruch already pointed out this is hard to read. Also it contains a
bug. When clk_prepare fails clk_unprepare is called afterwards.
Hint: Kernel guys are not afraid of having multiple return statements
in a function, instead they like it when something is handled early
without having to read the rest of the function.
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
Like above code? Thanks for review.
Richard
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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
As Baruch already pointed out this is hard to read. Also it contains a
bug. When clk_prepare fails clk_unprepare is called afterwards.
Hint: Kernel guys are not afraid of having multiple return statements
in a function, instead they like it when something is handled early
without having to read the rest of the function.
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
From: Russell King - ARM Linux <hidden> Date: 2011-11-11 10:27:27
On Fri, Nov 11, 2011 at 10:15:56AM +0100, Sascha Hauer wrote:
On Fri, Nov 11, 2011 at 05:05:47PM +0800, Richard Zhao wrote:
quoted
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
Yes, looks good.
While this looks like a nice easy solution for converting existing
drivers, I'd suggest thinking about this a little more...
I would suggest some thought is given to the placement of clk_enable()
and clk_disable() when adding clk_prepare(), especially if your existing
clk_enable() function can only be called from non-atomic contexts.
Obviously, the transition path needs to be along these lines:
1. add clk_prepare() to drivers
2. implement clk_prepare() and make clk_enable() callable from non-atomic
contexts
3. move clk_enable() in drivers to places it can be called from non-atomic
contexts to achieve greater power savings (maybe via the runtime pm)
and where a driver is shared between different sub-architectures which
have non-atomic clk_enable()s, (3) can only happen when all those sub-
architectures have been updated to step (2).
On Fri, Nov 11, 2011 at 10:27:27AM +0000, Russell King - ARM Linux wrote:
On Fri, Nov 11, 2011 at 10:15:56AM +0100, Sascha Hauer wrote:
quoted
On Fri, Nov 11, 2011 at 05:05:47PM +0800, Richard Zhao wrote:
quoted
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
Yes, looks good.
While this looks like a nice easy solution for converting existing
drivers, I'd suggest thinking about this a little more...
I would suggest some thought is given to the placement of clk_enable()
and clk_disable() when adding clk_prepare(), especially if your existing
clk_enable() function can only be called from non-atomic contexts.
Obviously, the transition path needs to be along these lines:
1. add clk_prepare() to drivers
2. implement clk_prepare() and make clk_enable() callable from non-atomic
contexts
3. move clk_enable() in drivers to places it can be called from non-atomic
contexts to achieve greater power savings (maybe via the runtime pm)
and where a driver is shared between different sub-architectures which
have non-atomic clk_enable()s, (3) can only happen when all those sub-
architectures have been updated to step (2).
The drivers changed here all do clk_prepare/enable in their probe
function. I agree that this clk_prepare_enable patch gives kind of
wrong motivation to just use this function and to forget about
potential power savings with proper integration of clk_prepare/enable.
I think though that it will take a long time until all drivers really
do this no matter if we have such a helper or not. I think that in the
meantime it's better to have a little helper than to clobber the probe
code with additional error handling.
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 |
From: Richard Zhao <hidden> Date: 2011-11-11 14:20:48
On Fri, Nov 11, 2011 at 12:56:44PM +0100, Sascha Hauer wrote:
On Fri, Nov 11, 2011 at 10:27:27AM +0000, Russell King - ARM Linux wrote:
quoted
On Fri, Nov 11, 2011 at 10:15:56AM +0100, Sascha Hauer wrote:
quoted
On Fri, Nov 11, 2011 at 05:05:47PM +0800, Richard Zhao wrote:
quoted
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
Yes, looks good.
While this looks like a nice easy solution for converting existing
drivers, I'd suggest thinking about this a little more...
I would suggest some thought is given to the placement of clk_enable()
and clk_disable() when adding clk_prepare(), especially if your existing
clk_enable() function can only be called from non-atomic contexts.
Obviously, the transition path needs to be along these lines:
1. add clk_prepare() to drivers
2. implement clk_prepare() and make clk_enable() callable from non-atomic
contexts
3. move clk_enable() in drivers to places it can be called from non-atomic
contexts to achieve greater power savings (maybe via the runtime pm)
Hi Russell,
There are use cases calling clk_enable in atomic context, but there are even more
cases caling in non-atomic context. The patch meant to help the latter cases.
Tuning of driver power savings can be left to other contributers. Is it ok
if I add below comments:
/* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
static inline int clk_prepare_enable(struct clk *clk)
...
/* clk_disable_unprepare helps cases using clk_disable in non-atomic context. */
static inline void clk_disable_unprepare(struct clk *clk)
...
Thanks
Richard
quoted
and where a driver is shared between different sub-architectures which
have non-atomic clk_enable()s, (3) can only happen when all those sub-
architectures have been updated to step (2).
The drivers changed here all do clk_prepare/enable in their probe
function. I agree that this clk_prepare_enable patch gives kind of
wrong motivation to just use this function and to forget about
potential power savings with proper integration of clk_prepare/enable.
I think though that it will take a long time until all drivers really
do this no matter if we have such a helper or not. I think that in the
meantime it's better to have a little helper than to clobber the probe
code with additional error handling.
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 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel