linux-kernel - Re: [PATCH 1/2] clk: qcom: gcc-msm8996: Fix parent for CLKREF clocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20191227013528.A445B2080D@mail.kernel.org>
Date:   Thu, 26 Dec 2019 17:35:27 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Gross <agross@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Paolo Pisati <p.pisati@...il.com>
Subject: Re: [PATCH 1/2] clk: qcom: gcc-msm8996: Fix parent for CLKREF clocks

Quoting Bjorn Andersson (2019-12-26 14:41:56)
> 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"...

Ok. This is another topic so not important to this patch right now.

> 
> > > 
> > > > 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".

Yes I'd like to merge for now but the binding needs to be adjusted.
Please resend.