Re: [PATCHv4 00/15] clk: ti: add support for hwmod clocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/13, Tero Kristo wrote:
> On 13/12/16 06:40, Michael Turquette wrote:
> >>>On 12/12, Michael Turquette wrote:
> >
> >Is the goal to describe this hardware topology in DT? Is that right
> >thing to do? I think it's cool to have this modeled *somehow* in Linux,
> >but I'm not sure DT is the right place to model the interconnect and
> >every device hanging off of it.
> >
> >I don't want to put words in Stephen's mouth, but I think the issue over
> >whether clockdomains are CCF clock providers or some genpd thing is
> >probably less important to him than the fact that the DT bindings are
> >super detailed to inner workings of the SoC.
> 
> Ok, so your preference would be to reduce the data under DT, and the
> ideal approach would be a single prcm node. I think we still need to
> keep the prm / cm1 / cm2 as separate nodes, as they are pretty
> individual from hardware point of view, provide quite different
> features, and they reside in some cases in quite different address
> spaces also. Anyway, here's what I gather we should probably have in
> DT:
> 
> - reset provider
>   * example: resets = <&prm OMAP4_IVA2_RESET>;
>   * only from 'prm' node
> 
> - genpd provider (for the hwmods, clockdomains, powerdomains,
> voltage domains)
>   * examples: power-domains = <&cm2 OMAP4_DSS_CORE_MOD>;
> 		power-domains = <&cm2 OMAP4_DSS_CLKDM>;
> 		power-domains = <&prm OMAP4_DSS_PWRDM>;
> 		power-domains = <&prm OMAP4_CORE_VOLTDM>;
>   * from all 'prm', 'cm1' and 'cm2' nodes, though 'prm' would be the
> only one providing _CLKDM, _PWRDM, _VOLTDM genpds.
> 
> - clock provider (for anything that requires clocks)
>   * example: clocks = <&cm1 OMAP4_DPLL_MPU_CK>;
>   * from all 'prm', 'cm1' and 'cm2' nodes
> 
> This would eventually cause an ABI breakage for the clock handles,
> if we transfer the existing clocks to this format, and remove the
> existing clock handles from DT. Otherwise, I think we could just
> transition the existing hwmod data to this new format only, and add
> the clockdomain / powerdomain / voltagedomain support a bit later.
> 

This sounds about right. Is the ABI break because we get rid of
clock nodes and just have a few big nodes? I thought we had
already broken DT ABI here but if we didn't then that isn't
great. Perhaps to make things keep working we can detect the old
style one node per clock design and register a bunch of providers
individually from the single driver probe? It would have to match
up the registers with a clk_hw pointer somewhere, but it should
be possible. Alternatively, we keep both designs around for some
time and have different compatibles and different driver entry
points.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux