On Wed, 17 Dec 2014, Lucas Stach wrote: > Maybe I'm thinking about this too lightly, but I think we already have > the right abstractions in place. > > The clock tree in Linux is always modeled along the flow of reference > clocks. So typically the root of the tree is something like an > oscillator and everything spreads out from this in a parent/child > relation. So clearly the reference clock of a PLL is the PLLs parent. If > the PLL is running in open-loop mode (isn't this rather direct frequency > synthesis?) is has no parent and is the root of a tree itself. > > If a PLL needs a functional clock to drive some internal logic, that > doesn't directly influence the clock synthesis from reference to > resulting clock, that clock would be no parent to the PLL. The PLL is > merely a consumer of this clock just like every other device in the > system. I suspect we're using different terminology. >From my point of view, a reference clock is an input clock signal that is used by another clock generator IP block or clock measurement IP block. The use is to measure and (optionally) discipline another oscillator. Thus the clock generator/measurement IP block generally does not electrically propagate the reference clock outside of the block. (Although some of the reference clock's characteristics, like phase noise or frequency stability, may be propagated indirectly.) Only a small number of clock tree entities makes use of reference clocks. By contrast, we could use the term "source clock" in the SoC context to mean a clock signal that directly drives a downstream IP block, in an electrical sense. These clocks are directly propagated through dividers and muxes. If you're willing to play along with this terminology, then a PLL's "source clock" would be its internal VCO/DCO, which thus would be the root clock of the PLL. Flipping over from hardware to software, in the Linux clock tree, there's usually not much point to modeling the VCO/DCO directly because it tends not to be under the direct control of the OS, and it is usually tightly integrated into the PLLs from a hardware point of view. But unlike most of the Linux clock tree nodes that are downstream from clock sources, which use clocks that are electrically driven by the clock source, the clock signal that PLLs and PLL-like clocks generate is not directly driven by the reference clock. So why is a reference clock listed as a Linux parent clock of an OMAP PLL? At least for OMAP, it was sort of shoehorned in to represent a gating dependency. It was a way of stating that the reference clock had to be enabled for the PLL to generate an output clock. (The off-chip crystal oscillator that drives most of the PLL reference clocks could be disabled when all of its users were idle, to save energy.) But this type of gating dependency is equally true for, say, a separate functional clock that the clock source requires in order to operate. (OMAP PLLs didn't have a separate functional clock, at least not that I was aware of; but that's not true for some similar clock sources used in other SoCs.) The clock framework wasn't re-entrant back then, and we wanted to avoid implementing re-entrancy because we were worried that it could turn into a mess. So we just wound up listing the reference clock as the PLL's Linux parent clock. My original comment was just intended to be a reflection on what it means to be a "parent clock" in the Linux clock tree sense. If it's intended to represent "source clocks" as they are defined above, then PLLs and PLL-like clocks should be root nodes, except for the few cases where it's useful to add a node for the underlying source oscillator directly (for example, if open-loop mode is supported). This might be the right way forward for the time being, and I like the idea of stating that Linux parent clocks should represent electrical "source clock" relationships. That raises the question of what to do about the additional gating relationships. At the moment, the clock type code needs to be responsible for calling clk_enable() etc. on all of the reference and functional clocks that need to be ungated for the clock source to work. But it has always seemed preferable to me to represent fundamental hardware structural constraints in data. If the data structures are well-defined, then the data should be relatively easy to analyze, reason about, generate, validate, share across platforms, and operate upon iteratively; unlike custom per-clocktype code, which often isn't. - Paul -- 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
