On 12/19, Tero Kristo wrote: > On 17/12/16 03:46, Stephen Boyd wrote: > >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? > > In the above plan, the ABI breakage is because we get rid of the > existing clock nodes and replace everything with a single (or few) > clock provider nodes. Thanks for confirming. > > >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. > > Keeping both around for a while should be okay, the design for this > series was done with that in mind. I didn't address the scrapping of > old clock data yet though, but that would be a step taken in the > future. > > First thing to do here would be to implement the hwmod genpds, rest > can follow later, but we need an agreement if this is the way we > want to go. Ok. I guess we're just waiting on Tony then? -- 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
