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

[Tero Kristo <t-kristo@ti.com>]

On 09/03/2014 10:28 PM, Mike Turquette wrote:
> 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.

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
>
>>
>> -Tero
>>
>>>
>>>> This patch can be queued once someone has a use-case + patches that requires
>>>> usage of such clocks.
>>>>
>>>> -Tero
>>>>
>>>
>>>
>>