Re: [RFC] clk: Make clk API return per-user struct clk instances
From: Tero Kristo
Date: Tue Sep 30 2014 - 03:40:35 EST
On 09/30/2014 09:54 AM, Mike Turquette wrote:
Quoting Stephen Boyd (2014-09-29 18:40:23)
On 09/29/14 11:17, Tomeu Vizoso wrote:
Also moves clock state to struct clk_core, but takes care to change as little
API as possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx>
---
Hello,
I'm sending this alternate implementation of the switch to per-user clocks,
with the added goal of not requiring any substantial changes to existing users
of the API.
This is pretty much RFC-quality right now, having only tested that it builds on
tegra_defconfig.
My main question right now is what do we want to do with those drivers that
statically declare clocks. State is now in struct clk_core, so updating the
drivers accordingly will amount to a substantial amount of lines changed, which
we are now trying to avoid.
Who's actually using the static clocks? Isn't it just omap2? It looks
like all of those are behind the DEFINE_CLK define so changing it in
clk-private.h should "just work". I'm lost as to why static clocks are
being used there though. If it was a problem with allocating memory too
early it doesn't seem to be the case given that sometimes the .parents
field isn't set for a mux and __clk_init() will go and allocate an array
of pointers. Maybe I missed something though.
Yeah, the old omap2+ static clocks were due to very very early init of
things which required clocks
If memory serves, that isn't a problem any more. I've talked to Tony and
Tero about my desire to remove clk-private.h and the need to get rid of
its use in the omap clock code.
Tero, what is the status of DT conversion for OMAP2/OMAP3? Can we get
get away with only defining clock data in DT for those platforms? Can we
finally kill off clk-private.h?
Clock data has been converted for all SoCs. The problem is currently
that we are missing some OMAP3 based DT board definitions and still
require legacy boot => thus requiring legacy clock data also => omap3
legacy clock data can't be removed yet.
Tony, whats the latest status with these missing omap3 boards? How many
board->dt conversions are still needed? Is there anything someone can do
on this front?
-Tero
Regards,
Mike
Thanks,
Tomeu
---
drivers/clk/clk-composite.c | 12 +-
drivers/clk/clk.c | 573 +++++++++++++++++++++++++++----------------
drivers/clk/clk.h | 5 +
drivers/clk/clkdev.c | 20 +-
drivers/clk/tegra/clk.c | 2 +-
include/linux/clk-private.h | 20 +-
include/linux/clk-provider.h | 22 +-
include/linux/clkdev.h | 2 +-
8 files changed, 410 insertions(+), 246 deletions(-)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index b9355da..cb4a09d 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -57,14 +57,14 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw,
static long clk_composite_determine_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate,
- struct clk **best_parent_p)
+ struct clk_core **best_parent_p)
We should avoid exposing clk_core to anything besides clk.c or users of
clk-private.h (the latter which should go away once we remove all static
clocks).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/