From: Maxime Ripard <hidden> Date: 2016-02-02 08:47:09
Hi everyone,
Here is an attempt at making the whole clk-sunxi code register the
clocks without creating any orphans by relying on CLK_OF_DECLARE.
This also has the net benefit of not having to add the SoC compatible
to the list of compatibles that trigger the clock registration, which
has started to be a pain.
I tested this on an A13 (R8 actually), everything seems to be working
just fine. I also tested it both with and without Heiko's patch to
defer clk_get if the clock is orphan, and previously broke everything.
Let me know what you think,
Maxime
Maxime Ripard (5):
clk: sunxi: Make clocks setup functions return their clock
clk: sunxi: Make clocks setup functions take const pointer
clk: sunxi: convert current clocks registration to CLK_OF_DECLARE
clk: sunxi: Remove old probe and protection code
clk: sunxi: Remove clk_register_clkdev calls
drivers/clk/sunxi/clk-a10-hosc.c | 3 +-
drivers/clk/sunxi/clk-a20-gmac.c | 2 -
drivers/clk/sunxi/clk-factors.c | 7 -
drivers/clk/sunxi/clk-factors.h | 1 -
drivers/clk/sunxi/clk-mod0.c | 1 +
drivers/clk/sunxi/clk-sun6i-apb0-gates.c | 2 -
drivers/clk/sunxi/clk-sun9i-core.c | 1 +
drivers/clk/sunxi/clk-sunxi.c | 263 ++++++++++++++++---------------
8 files changed, 135 insertions(+), 145 deletions(-)
--
2.6.4
From: Maxime Ripard <hidden> Date: 2016-02-02 08:47:10
The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.
Make them return it so that we can start using it.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/clk/sunxi/clk-sunxi.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
[off-list ref] wrote:
The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.
Make them return it so that we can start using it.
Should they return error codes as well? So the CLK_OF_DECLARE setup functions
can report errors. Or make these helper functions report errors directly?
ChenYu
From: Andre Przywara <andre.przywara@arm.com> Date: 2016-02-02 11:32:29
Hi Maxime,
On 02/02/16 10:35, Chen-Yu Tsai wrote:
On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
[off-list ref] wrote:
quoted
The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.
Make them return it so that we can start using it.
Should they return error codes as well? So the CLK_OF_DECLARE setup functions
can report errors. Or make these helper functions report errors directly?
Yeah, I was about the reply the same.
It looks like we can use the ERR_PTR facility to achieve this, as it's
already used in other parts of the clk framework.
For instance ...
... here we have two functions that could fail and actually return an
error code.
This whole clock tree is quite complex already, so having clock
initialisations fail without any error message is not really helping.
Doing: "if (ret) {pr_warn(...); return ERR_PTR(ret);}" should be doable,
I think. Or we do it in the upper layers, when we have the error reason.
Otherwise I like the approach!
Cheers,
Andre.
quoted
}
+
+ return clk;
}
@@ -722,7 +724,6 @@ static void __init sunxi_divider_clk_setup(struct device_node *node, }- /** * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks */
From: Maxime Ripard <hidden> Date: 2016-02-02 13:27:18
Hi,
On Tue, Feb 02, 2016 at 06:35:29PM +0800, Chen-Yu Tsai wrote:
On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
[off-list ref] wrote:
quoted
The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.
Make them return it so that we can start using it.
Should they return error codes as well? So the CLK_OF_DECLARE setup functions
can report errors. Or make these helper functions report errors directly?
CLK_OF_DECLARE doesn't handle any kind of error, as the setup function
must return void, and the error printing should rather be in the
common functions in order to avoid duplicating it everywhere, so I'm
not sure. Or did you had something else in mind?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/9af172d6/attachment.sig>
From: Maxime Ripard <hidden> Date: 2016-02-04 12:07:38
On Tue, Feb 02, 2016 at 09:47:10AM +0100, Maxime Ripard wrote:
The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.
Make them return it so that we can start using it.
Signed-off-by: Maxime Ripard <redacted>
After discussing it with Chen-Yu on IRC, the error logging will be
done as a subsequent patch.
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/72a9f1ac/attachment.sig>
From: Maxime Ripard <hidden> Date: 2016-02-02 08:47:11
All the data structure that we pass to the clocks setup functions are
declared const, while our setup functions expects a regular pointer. This
was hidden by the fact that we cast a void * pointer back to these
structures, which made it go unnoticed.
Fix the functions prototype.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/clk/sunxi/clk-sunxi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
[off-list ref] wrote:
All the data structure that we pass to the clocks setup functions are
declared const, while our setup functions expects a regular pointer. This
was hidden by the fact that we cast a void * pointer back to these
structures, which made it go unnoticed.
Fix the functions prototype.
Signed-off-by: Maxime Ripard <redacted>
From: Andre Przywara <andre.przywara@arm.com> Date: 2016-02-02 12:11:36
On 02/02/16 08:47, Maxime Ripard wrote:
All the data structure that we pass to the clocks setup functions are
declared const, while our setup functions expects a regular pointer. This
was hidden by the fact that we cast a void * pointer back to these
structures, which made it go unnoticed.
Fix the functions prototype.
Signed-off-by: Maxime Ripard <redacted>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
From: Maxime Ripard <hidden> Date: 2016-02-04 12:08:17
On Tue, Feb 02, 2016 at 09:47:11AM +0100, Maxime Ripard wrote:
All the data structure that we pass to the clocks setup functions are
declared const, while our setup functions expects a regular pointer. This
was hidden by the fact that we cast a void * pointer back to these
structures, which made it go unnoticed.
Fix the functions prototype.
Signed-off-by: Maxime Ripard <redacted>
From: Maxime Ripard <hidden> Date: 2016-02-02 08:47:12
The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.
The protection code also relies on clkdev, which we don't really use but
for this particular case.
Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/clk/sunxi/clk-sunxi.c | 150 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 133 insertions(+), 17 deletions(-)
From: Andre Przywara <andre.przywara@arm.com> Date: 2016-02-02 14:16:54
Hi Maxime,
On 02/02/16 08:47, Maxime Ripard wrote:
The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.
The protection code also relies on clkdev, which we don't really use but
for this particular case.
Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.
I very much appreciate this cleanup and like the idea. Any chance we can
have this rather quickly, so that I can rebase the A64 support series on it?
One issue below, though:
...
I don't find this clock in my tree (which is mripard/sunxi/for-next).
Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
But as you remove this clock below from the old code and instead
instantiate this new clock here, this looks somehow wrong to me. Can you
confirm this or am I utterly confused?
Apart from that I checked each and every clock mentioned in this patch
and can confirm that the transformation is correct. So if you fix this,
I can send a Reviewed-by.
Cheers,
Andre.
From: Maxime Ripard <hidden> Date: 2016-02-02 17:00:37
Hi,
On Tue, Feb 02, 2016 at 02:16:54PM +0000, Andre Przywara wrote:
Hi Maxime,
On 02/02/16 08:47, Maxime Ripard wrote:
quoted
The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.
The protection code also relies on clkdev, which we don't really use but
for this particular case.
Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.
I very much appreciate this cleanup and like the idea. Any chance we can
have this rather quickly, so that I can rebase the A64 support series on it?
I actually count on that :)
I wasn't really happy about your allwinner,sunxi compatible, so I just
gave you an easier way out ;)
I don't find this clock in my tree (which is mripard/sunxi/for-next).
Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
But as you remove this clock below from the old code and instead
instantiate this new clock here, this looks somehow wrong to me. Can you
confirm this or am I utterly confused?
Damn, you're right, it's just a silly copy-paste issue, I'll fix it.
Apart from that I checked each and every clock mentioned in this patch
and can confirm that the transformation is correct. So if you fix this,
I can send a Reviewed-by.
From: Andre Przywara <andre.przywara@arm.com> Date: 2016-02-02 17:04:02
Hi,
On 02/02/16 17:00, Maxime Ripard wrote:
Hi,
On Tue, Feb 02, 2016 at 02:16:54PM +0000, Andre Przywara wrote:
quoted
Hi Maxime,
On 02/02/16 08:47, Maxime Ripard wrote:
quoted
The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.
The protection code also relies on clkdev, which we don't really use but
for this particular case.
Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.
I very much appreciate this cleanup and like the idea. Any chance we can
have this rather quickly, so that I can rebase the A64 support series on it?
I actually count on that :)
Great!
I wasn't really happy about your allwinner,sunxi compatible,
Me neither, honestly, but I didn't dare to touch clk-sunxi.c even more ;-)
I don't find this clock in my tree (which is mripard/sunxi/for-next).
Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
But as you remove this clock below from the old code and instead
instantiate this new clock here, this looks somehow wrong to me. Can you
confirm this or am I utterly confused?
Damn, you're right, it's just a silly copy-paste issue, I'll fix it.
I am sure you left it in to see if somebody actually checks it ;-)
Merci!
Andre
quoted
Apart from that I checked each and every clock mentioned in this patch
and can confirm that the transformation is correct. So if you fix this,
I can send a Reviewed-by.
From: Maxime Ripard <hidden> Date: 2016-02-04 12:13:48
On Tue, Feb 02, 2016 at 09:47:12AM +0100, Maxime Ripard wrote:
The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.
The protection code also relies on clkdev, which we don't really use but
for this particular case.
Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.
Signed-off-by: Maxime Ripard <redacted>
From: Maxime Ripard <hidden> Date: 2016-02-02 08:47:13
Now that we don't have any user left for the old registration code, we can
remove it.
Signed-off-by: Maxime Ripard <redacted>
---
drivers/clk/sunxi/clk-sunxi.c | 114 ------------------------------------------
1 file changed, 114 deletions(-)
@@ -258,14 +258,8 @@ struct clk *sunxi_factors_register(struct device_node *node,if(ret)gotoerr_provider;-ret=clk_register_clkdev(clk,clk_name,NULL);-if(ret)-gotoerr_clkdev;-returnclk;-err_clkdev:-of_clk_del_provider(node);err_provider:/* TODO: The composite clock stuff will leak a bit here. */clk_unregister(clk);
@@ -291,7 +285,6 @@ void sunxi_factors_unregister(struct device_node *node, struct clk *clk)factors=to_clk_factors(hw);name=clk_hw_get_name(hw);-/* No unregister call for clkdev_* */of_clk_del_provider(node);/* TODO: The composite clock stuff will leak a bit here. */clk_unregister(clk);
@@ -1020,7 +1018,6 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,clkflags);WARN_ON(IS_ERR(clk_data->clks[i]));-clk_register_clkdev(clks[i],clk_name,NULL);}/* Adjust to the real max */
Because this driver uses __clk_get, that it was previously included in
clk-factors.h and is not anymore, and that otherwise it won't compile,
obviously.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/bfdb411e/attachment.sig>
From: Maxime Ripard <hidden> Date: 2016-02-04 12:17:13
On Tue, Feb 02, 2016 at 09:47:14AM +0100, Maxime Ripard wrote:
Now that our protection code doesn't use the global name lookup anymore, we
can remove the clkdev registrations.
Signed-off-by: Maxime Ripard <redacted>