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

[Tero Kristo]

On 09/30/2014 09:16 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@xxxxxx> [140930 00:41]:
> > 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?
>
> Well things are looking good for device tree based booting for omap3
> in general. We just need to wait so people have enough time to update
> their boards and do the missing .dts files. I guess all we can say is
> we drop omap3 legacy booting when we can.
>
> Can we remove the depenency to the omap3 DT conversion for the clocks
> to remove the DT conversion dependency here?

Well, we can. But this basically requires converting the legacy clock 
data to some intermediate format, parsing this init time and registering 
the individual clocks.. something similar to what is done with DT clocks 
now. Kind of pointless exercise with data that is going to be removed 
eventually, no? I think converting the boards to DT files is easier and 
more fruitful also.

-Tero

--
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/