Re: [PATCH 0/1] ARM: OMAP: add external clock provider support

[Mike Turquette <mturquette@linaro.org>]

Quoting Tero Kristo (2014-08-04 05:36:19)
> On 08/04/2014 02:37 PM, Peter Ujfalusi wrote:
> > On 08/01/2014 04:15 PM, Tero Kristo wrote:
> >> Hi,
> >>
> >> This patch adds possibility to register external clocks (outside the main
> >> SoC) on TI boards through device tree. Clock sources as such include for
> >> example twl-6030 / twl-6040 chips and variants which can be used to clock
> >> for example audio / WLAN chips.
> >
> > Just one question to Mike and Tero:
> > would it be possible to have generic binding for such an external clocks?
> > We have the palmas clock driver already upstream which handles the 32K clocks
> > from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?)
> > platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible
> > PMIC and some nVidia platform also uses this class of devices (and they all
> > need to have control over the 32K clock(s)).
> 
> Other platforms initialize their clocks in different manner, they can 
> use generic of_clk_init I believe. If they can't use that for some 
> reason, then they need to implement something similar to this.

Right. To answer Peter's question, we do have a generic binding, it is
the clock binding ;-)

Even the idea of having a "TI clock provider" isn't really a good way to
do things. IP blocks that generate clocks are clock providers, not
companies. As such if Palmas or Gaia or whatever generate clocks then we
don't need any new infrastructure in the clock core to accomodate this.
Those drivers simply need to include clk-provider.h and register their
clocks with the framework.

Some good examples of this are the omap3-isp.c driver, and qcom's hdmi
phy driver (sorry, don't have the path handy) which both consume clocks
generated by other clock providers, and they provide their own clocks
which are generated within their own IP/module.

A big part of the design of the ccf (and later, the DT bindings) is that
we do not need a centralized place to store every piece of clock
generation knowledge and clock routing knowledge.

Regards,
Mike

> 
> -Tero
> 
> >
> >> This patch can be queued once someone has a use-case + patches that requires
> >> usage of such clocks.
> >>
> >> -Tero
> >>
> >
> >
>