All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Ansuel Smith <ansuelsmth@gmail.com>
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
Date: Tue, 15 Mar 2022 15:41:14 -0700	[thread overview]
Message-ID: <20220315224115.EA1F9C340E8@smtp.kernel.org> (raw)
In-Reply-To: <YjEJjB/Hwj/1Ncum@Ansuel-xps.localdomain>

Quoting Ansuel Smith (2022-03-15 14:47:56)
> 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?

I honestly don't remember much anymore about this. It's been a decade.
Scaling the cache used to be an independent clk and operation vs. the
CPU. Basically the clk domain and power domain for the cache was
separate from the CPU. There's also the fuse stuff that means you have
to read the fuse to know what OPP table to use. Otherwise you may be
overclocking the CPU or undervolting it. It may also be that cpuidle
can't happen during a frequency transition. Otherwise the clk gating
will be reenabled when the cpu startup code reinitializes all the cpu
registers? I'd have to look through some old vendor kernels to see if
anything jogs my memory.

> 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)

  reply	other threads:[~2022-03-15 22:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13 19:04 [PATCH 00/16] Modernize rest of the krait drivers Ansuel Smith
2022-03-13 19:04 ` [PATCH 01/16] clk: permit to define a custom parent for clk_hw_get_parent_index Ansuel Smith
2022-03-15 17:55   ` Stephen Boyd
2022-03-15 18:07     ` Ansuel Smith
2022-03-15 21:30       ` Stephen Boyd
2022-03-13 19:04 ` [PATCH 02/16] clk: qcom: gcc-ipq806x: skip pxo/cxo fixed clk if already present Ansuel Smith
2022-03-13 19:04 ` [PATCH 03/16] clk: qcom: gcc-ipq806x: add PXO_SRC in clk table Ansuel Smith
2022-03-13 19:04 ` [PATCH 04/16] clk: qcom: clk-hfpll: use poll_timeout macro Ansuel Smith
2022-03-13 19:04 ` [PATCH 05/16] clk: qcom: kpss-xcc: convert to parent data API Ansuel Smith
2022-03-13 19:04 ` [PATCH 06/16] clk: qcom: clk-krait: unlock spin after mux completion Ansuel Smith
2022-03-13 19:04 ` [PATCH 07/16] clk: qcom: clk-krait: add hw_parent check for div2_round_rate Ansuel Smith
2022-03-15 22:43   ` Stephen Boyd
2022-03-13 19:04 ` [PATCH 08/16] clk: qcom: krait-cc: convert to parent_data API Ansuel Smith
2022-03-13 19:04 ` [PATCH 09/16] clk: qcom: krait-cc: drop pr_info and register qsb only if needed Ansuel Smith
2022-03-15 22:45   ` Stephen Boyd
2022-03-13 19:04 ` [PATCH 10/16] clk: qcom: krait-cc: drop hardcoded safe_sel Ansuel Smith
2022-03-13 19:04 ` [PATCH 11/16] clk: qcom: krait-cc: force sec_mux to QSB Ansuel Smith
2022-03-15 22:47   ` Stephen Boyd
2022-03-13 19:04 ` [PATCH 12/16] clk: qcom: clk-krait: add 8064 errata workaround Ansuel Smith
2022-03-14  8:20   ` Dmitry Baryshkov
2022-03-14 12:43     ` Ansuel Smith
2022-03-15 21:34       ` Stephen Boyd
2022-03-15 21:47         ` Ansuel Smith
2022-03-15 22:41           ` Stephen Boyd [this message]
2022-03-16 15:46             ` Ansuel Smith
2022-03-17 19:34               ` Stephen Boyd
2022-03-13 19:04 ` [PATCH 13/16] clk: qcom: clk-krait: add enable disable ops Ansuel Smith
2022-03-13 19:04 ` [PATCH 14/16] dt-bindings: clock: Convert qcom,krait-cc to yaml Ansuel Smith
2022-03-13 19:04 ` [PATCH 15/16] dts: qcom-ipq8064: add missing krait-cc compatible and clocks Ansuel Smith
2022-03-13 19:04 ` [PATCH 16/16] dt-bindings: arm: msm: Convert kpss driver Documentation to yaml Ansuel Smith
2022-03-14 14:42   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220315224115.EA1F9C340E8@smtp.kernel.org \
    --to=sboyd@kernel.org \
    --cc=agross@kernel.org \
    --cc=ansuelsmth@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=pdeschrijver@nvidia.com \
    --cc=pgaikwad@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.