Re: [RFC] clk: Make clk API return per-user struct clk instances

[Mike Turquette]

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?

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/