[RFC 0/2] clk: samsung: add composite clocks
Heiko Stübner
heiko at sntech.de
Tue May 21 04:54:48 EST 2013
Am Montag, 20. Mai 2013, 20:19:29 schrieb Rahul Sharma:
> On Mon, May 20, 2013 at 7:44 PM, Heiko Stübner <heiko at sntech.de> wrote:
> > Am Montag, 20. Mai 2013, 16:17:06 schrieb Rahul Sharma:
> >> This patch adds support for composite clocks for samsung SoCs.
> >> Many drivers need access to a common clock which support gating
> >> and/or muxing and/or rate control operations. For example hdmi
> >> which needs to switch between parents and call enable/disable for
> >> "sclk_hdmi".
> >>
> >> This patch set also adds composite clock for exyno5250 hdmi. Based
> >> on the review comment, I will extended this to other exynos SoCs
> >> clocks files.
> >
> > I think I remember reading somewhere that the target of the common clock
> > framework was to prevent every SoC from introducing their own special
> > clock types and instead create these structures from separate clocks
> > (mux clk + gate clk) and not to have every SoC create their own custom
> > clock types.
> >
> > The Samsung clock drivers at the moment follow this paradigm of combining
> > the existing "simple" clocks and only introduce new clock types for the
> > pll clocks, that really need special handling.
> >
> > So it would probably good to keep it this way and define your clocks from
> > their individual components, as all the other Samsung clocks currently
> > do.
>
> Thanks Heiko, I agree, but I am not trying to introduce a new type here,
> instead using the existing generic support for composite clocks for
> exynos as well.
>
> These have not been added for Samsung SoCs so far but I do not see any
> harm in using them also. With them, drivers do not need to get and
> configure each clock component separately. This ensures less and more
> reasonable changes in the drivers during migration to CCF.
>
> Please help me understand about the loss when using composite clocks.
hehe ... it seems I remembered something outdated ...
The last time (before march 12th) I looked at the ccf, it was "use simple
clocktypes". But it seems in the meantime the separate composite-clock you use
was introduced. And I didn't read your patch careful enough to see that you're
using the (now) existing composite clock.
So, sorry for the noise :-)
Heiko
More information about the devicetree-discuss
mailing list