Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
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)). This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
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. -Tero This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] ARM: OMAP: add external clock provider support
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. This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
