On Tue, Jan 3, 2023 at 9:09 AM Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On 03/01/2023 17:38, Jeffrey Hugo wrote: > > On Wed, Dec 28, 2022 at 6:33 AM Dmitry Baryshkov > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > >> > >> The test clock apparently it's not used by anyone upstream. Remove it. > > > > IMO, NACK, > > > > This is not a valid justification. > > > > The DT is supposed to describe the hardware, and should be complete in > > that regard. This clock exists in the hardware, so it should be > > described. > > Most of Qualcomm clock controllers can input clocks from > core_bi_pll_test_se. But we are listing them only for a small number of > them. And even on these platforms nobody provides this clock. IMO the Qcom bindings could use some more rigor, I just don't have the cycles to help there. The ones I've looked at appear to be written from the perspective of "what does the linux driver need" and not "what do we have in the schematic". Often "what does the linux driver need" changes over time, which means the binding needs to evolve, which breaks the interface. It's entirely valid to not use something in the Linux driver, especially as the platform implementation is probably minimal during early bringup, but such things are expected to be implemented eventually. There is a huge set of existing platforms where we probably can't go back and fix them since the binding is already defined, but going forward, new platforms can do better. > > Maybe you shed some light here, what is the source of this clock? Who > provides the clock, e.g. on msm8998 platform? It is an external input to the SoC, similar to CXO. On the laptops, TP88 (test point) on the main motherboard is routed to the SoC pin. I don't have schematics for every platform in the wild, so I can't say if that is the norm. -Jeff
