On 09/03/2014 10:28 PM, Mike Turquette wrote:

Quoting Tero Kristo (2014-08-04 05:36:19)

quoted

On 08/04/2014 02:37 PM, Peter Ujfalusi wrote:

quoted

On 08/01/2014 04:15 PM, Tero Kristo wrote:

quoted

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.

This patch is obsolete now, I posted the patch which changes the TI 
clock driver to use generic of_clk_init instead of a custom one. This 
now initializes all the external clocks also without any issues.

The patch itself can potentially cause some problems with DPLL clocks 
though (as they use the retry init mechanism and this is overlooked in 
v1), so I am working on v2 atm.

-Tero

Regards,
Mike

quoted

-Tero

quoted

quoted

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

-Tero