Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Tue, 15 Mar 2022 22:47:56 +0100
From:   Ansuel Smith <ansuelsmth@gmail.com>
To:     Stephen Boyd <sboyd@kernel.org>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Andy Gross <agross@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Peter De Schrijver <pdeschrijver@nvidia.com>,
        Prashant Gaikwad <pgaikwad@nvidia.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        Jonathan Hunter <jonathanh@nvidia.com>,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
        linux-tegra@vger.kernel.org
Subject: Re: [PATCH 12/16] clk: qcom: clk-krait: add 8064 errata workaround
Message-ID: <YjEJjB/Hwj/1Ncum@Ansuel-xps.localdomain>
References: <20220313190419.2207-1-ansuelsmth@gmail.com>
 <20220313190419.2207-13-ansuelsmth@gmail.com>
 <169795c1-607e-ee60-7ac7-538ed888bedf@linaro.org>
 <Yi84aNrJ7p+3jy2A@Ansuel-xps.localdomain>
 <20220315213431.DB6C4C340EE@smtp.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220315213431.DB6C4C340EE@smtp.kernel.org>
Precedence: bulk

On Tue, Mar 15, 2022 at 02:34:30PM -0700, Stephen Boyd wrote:
> Quoting Ansuel Smith (2022-03-14 05:43:20)
> > On Mon, Mar 14, 2022 at 11:20:21AM +0300, Dmitry Baryshkov wrote:
> > > On 13/03/2022 22:04, Ansuel Smith wrote:
> > > > Add 8064 errata workaround where the sec_src clock gating needs to be
> > > 
> > > Could you please be more specific whether the errata applies only to the
> > > ipq8064 or to the apq8064 too? 8064 is not specific enough.
> > >
> > 
> > That's a good question... Problem is that we really don't know the
> > answer. This errata comes from qsdk on an old sourcecode. I assume this
> > is specific to ipq8064 and apq8064 have different mux configuration.
> > 
> 
> I think it was some glitch that happened when the automatic clk gating
> was enabled during a switch. The automatic clk gating didn't know that
> software was running and switching the input so it killed the CPU and
> stopped the clk. That lead to hangs and super badness. I assume it was
> applicable to apq8064 as well because ipq8064 is basically apq8064 with
> the multimedia subsystem replaced by the networking subsystem. Also I
> wouldn't remember all these details because I worked on apq8064 but not
> so much on ipq8064 :)

Honest question. Do you remember other glitch present on the platform?
We are trying to bisect an instability problem and we still needs to
find the reason. We really can't understand if it's just a power
delivery problem or a scaling problem from muxes or other things.

The current problem is that after some time the device kernel panics
with a number of strange reason like invalid kernel paging and other
strange (or the device just freze and reboots, not even a crash log)
Many kernel panics reports the crash near the mux switch (like random
error right before the mux switch) So I suspect there is a problem
there. But due to the fact that is very random we have NO exact way to
repro it. I manage sometime, while playing with the code, to repo
similar kernel crash but still i'm not sure of the real cause.

I know it's OT but do you have any idea about it? If you remember
anything about it?
(To scale the freq i'm using a dedicated cpufreq driver that works this
way:
- We first scale the cache to the max freq across all core, we set the
  voltage
- We scale the cpu to the correct target.
This is all done under a lock. Do you see anything wrong in this logic?
To mee these random crash looks to be really related to something wrong
with the mux or with the cache set to a wrong state)

Thx for any suggestion about this.
(also I will update this commit and mention both apq and ipq in the
comments)

-- 
	Ansuel