Quoting Marijn Suijten (2021-12-15 12:11:53)
> On 2021-12-15 22:37:04, Dmitry Baryshkov wrote:
> > The "xo" fixed_factor clock is a leftover/hack from a time when we
> > couldn't make rpmhcc the root of all clocks. It is going to be removed
> > once all users of this clock are converted to use clocks specified
> > through the DTS. Replace internal usage of the xo clock with the cxo
> > (RPM_SMD_BB_CLK1) parent, specifying xo_board as a fallback.
>
> Nit: as mentioned in another reply I don't think rpmhcc is the sole
> problem why "xo" exists (xo_board exists to subustitute it for now).
> Rather, "xo" seems to be a remnant from an era where clock dependencies
> were not (fully) specified in DT but instead relied on fixed, well known
> global names for these inter-driver (inter-clock) dependencies. Maybe
> this alias was needed to streamline the use of xo_board until rpmcc
> could be used though?
A long time ago, in a company far, far away... oh wait that's not it.
I was trying to get by without the rpm clk driver. The idea to express
relationships between clk controllers in DT didn't really take off for
another few years.
Registering the xo_board clk from the GCC driver eased these problems by
letting us set the parent of the gcc clks to an intermediary "xo" that
we could replace with the rpm version of that whenever the rpm clk
driver existed. It was also supposed to be a drop in replacement for
when rpm wasn't enabled, but nobody does that so that idea sort of fell
away. See commit a085f877a882 ("clk: qcom: Move cxo/pxo/xo into dt
files") and how the parent is ee15faffef11 ("clk: qcom: common: Add API
to register board clocks backwards compatibly").
