On Mon 23 Dec 18:20 PST 2019, Stephen Boyd wrote: > Quoting Bjorn Andersson (2019-12-19 18:34:27) > > On Wed 18 Dec 22:37 PST 2019, Stephen Boyd wrote: > > > > > Quoting Bjorn Andersson (2019-12-07 12:36:02) > > > > The CLKREF clocks are all fed by the clock signal on the CXO2 pad on the > > > > SoC. Update the definition of these clocks to allow this to be wired up > > > > to the appropriate clock source. > > > > > > > > Retain "xo" as the global named parent to make the change a nop in the > > > > event that DT doesn't carry the necessary clocks definition. > > > > > > Something seems wrong still. > > > > > > I wonder if we need to add the XO "active only" clk to the rpm clk > > > driver(s) and mark it as CLK_IS_CRITICAL. In theory that is really the > > > truth for most of the SoCs out there because it's the only crystal that > > > needs to be on all the time when the CPU is active. The "normal" XO clk > > > will then be on all the time unless deep idle is entered and nobody has > > > turned that on via some clk_prepare() call. That's because we root all > > > other clks through the "normal" XO clk that will be on in deep > > > idle/suspend if someone needs it to be. > > > > > > > The patch doesn't attempt to address the fact that our representation of > > XO is incomplete, only the fact that CXO2 isn't properly described. > > > > Looking at the clock distribution, we do have RPM_SMD_BB_CLK1_A which > > presumably is the clock you're referring to here - i.e. the clock > > resource connected to CXO. > > I don't mean the buffer clks, but the XO resource specifically. It's the > representation to the RPM that deep sleep/deep idle should or shouldn't > turn off XO and achieve "XO shutdown". Basically it can never be off > when the CPU is active because then the CPU itself wouldn't be clocked, > but when the CPU isn't active we may want to turn it off if nothing is > using it during sleep to clock some sort of wakeup logic or device that > is active when the CPU is idle. > I see. So we're missing the representation of the "raw" CXO in clk-smd-rpm.c, and I'm lacking some understanding of how these pieces should be tied together for us to realize the "XO shutdown"... > > > > > Did the downstream code explicitly enable this ln_bb_clk in the phy > > > drivers? I think it may have? > > > > > > > Yes, afaict all downstream drivers consuming a CLKREF also consumes > > LN_BB and ensures that this is enabled. So we've been relying on UFS to > > either not have probed yet or that UFS probed successfully for PCIe and > > USB to be functional. > > > > So either we need this patch to ensure that the requests propagates > > down, or I need to patch up the PHY drivers to ensure that they also > > vote for the PMIC clock - and I do prefer this patch. > > Cool. Yeah seems better to just indicate that the reference clks are > clocked by something else and fix that problem now. > Let me know if I shouldn't interpret this sentence as "let's merge this for now". Regards, Bjorn
