All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: Caleb Connolly <caleb.connolly@linaro.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Rob Clark <robdclark@chromium.org>, Sean Paul <sean@poorly.run>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Jordan Crouse <jordan@cosmicpenguin.net>,
	Jonathan Marek <jonathan@marek.ca>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Sharat Masetty <smasetty@codeaurora.org>,
	Akhil P Oommen <akhilpo@codeaurora.org>,
	open list <linux-kernel@vger.kernel.org>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH] drm/msm: Disable frequency clamping on a630
Date: Thu, 29 Jul 2021 13:53:17 -0700	[thread overview]
Message-ID: <CAF6AEGs11aYnkL30kp79pMqLTg3_4otFwG2Oc890Of2ndLbELw@mail.gmail.com> (raw)
In-Reply-To: <e2cebf65-012d-f818-8202-eb511c996e28@linaro.org>

On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
<caleb.connolly@linaro.org> wrote:
>
>
>
> On 29/07/2021 21:24, Rob Clark wrote:
> > On Thu, Jul 29, 2021 at 1:06 PM Caleb Connolly
> > <caleb.connolly@linaro.org> wrote:
> >>
> >> Hi Rob,
> >>
> >> I've done some more testing! It looks like before that patch ("drm/msm: Devfreq tuning") the GPU would never get above
> >> the second frequency in the OPP table (342MHz) (at least, not in glxgears). With the patch applied it would more
> >> aggressively jump up to the max frequency which seems to be unstable at the default regulator voltages.
> >
> > *ohh*, yeah, ok, that would explain it
> >
> >> Hacking the pm8005 s1 regulator (which provides VDD_GFX) up to 0.988v (instead of the stock 0.516v) makes the GPU stable
> >> at the higher frequencies.
> >>
> >> Applying this patch reverts the behaviour, and the GPU never goes above 342MHz in glxgears, losing ~30% performance in
> >> glxgear.
> >>
> >> I think (?) that enabling CPR support would be the proper solution to this - that would ensure that the regulators run
> >> at the voltage the hardware needs to be stable.
> >>
> >> Is hacking the voltage higher (although ideally not quite that high) an acceptable short term solution until we have
> >> CPR? Or would it be safer to just not make use of the higher frequencies on a630 for now?
> >>
> >
> > tbh, I'm not sure about the regulator stuff and CPR.. Bjorn is already
> > on CC and I added sboyd, maybe one of them knows better.
> >
> > In the short term, removing the higher problematic OPPs from dts might
> > be a better option than this patch (which I'm dropping), since there
> > is nothing stopping other workloads from hitting higher OPPs.
> Oh yeah that sounds like a more sensible workaround than mine .
> >
> > I'm slightly curious why I didn't have problems at higher OPPs on my
> > c630 laptop (sdm850)
> Perhaps you won the sillicon lottery - iirc sdm850 is binned for higher clocks as is out of the factory.
>
> Would it be best to drop the OPPs for all devices? Or just those affected? I guess it's possible another c630 might
> crash where yours doesn't?

I've not heard any reports of similar issues from the handful of other
folks with c630's on #aarch64-laptops.. but I can't really say if that
is luck or not.

Maybe just remove it for affected devices?  But I'll defer to Bjorn.

BR,
-R

WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com>
To: Caleb Connolly <caleb.connolly@linaro.org>
Cc: Rob Clark <robdclark@chromium.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
	Jonathan Marek <jonathan@marek.ca>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Sharat Masetty <smasetty@codeaurora.org>,
	Akhil P Oommen <akhilpo@codeaurora.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Jordan Crouse <jordan@cosmicpenguin.net>,
	Stephen Boyd <sboyd@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Sean Paul <sean@poorly.run>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/msm: Disable frequency clamping on a630
Date: Thu, 29 Jul 2021 13:53:17 -0700	[thread overview]
Message-ID: <CAF6AEGs11aYnkL30kp79pMqLTg3_4otFwG2Oc890Of2ndLbELw@mail.gmail.com> (raw)
In-Reply-To: <e2cebf65-012d-f818-8202-eb511c996e28@linaro.org>

On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
<caleb.connolly@linaro.org> wrote:
>
>
>
> On 29/07/2021 21:24, Rob Clark wrote:
> > On Thu, Jul 29, 2021 at 1:06 PM Caleb Connolly
> > <caleb.connolly@linaro.org> wrote:
> >>
> >> Hi Rob,
> >>
> >> I've done some more testing! It looks like before that patch ("drm/msm: Devfreq tuning") the GPU would never get above
> >> the second frequency in the OPP table (342MHz) (at least, not in glxgears). With the patch applied it would more
> >> aggressively jump up to the max frequency which seems to be unstable at the default regulator voltages.
> >
> > *ohh*, yeah, ok, that would explain it
> >
> >> Hacking the pm8005 s1 regulator (which provides VDD_GFX) up to 0.988v (instead of the stock 0.516v) makes the GPU stable
> >> at the higher frequencies.
> >>
> >> Applying this patch reverts the behaviour, and the GPU never goes above 342MHz in glxgears, losing ~30% performance in
> >> glxgear.
> >>
> >> I think (?) that enabling CPR support would be the proper solution to this - that would ensure that the regulators run
> >> at the voltage the hardware needs to be stable.
> >>
> >> Is hacking the voltage higher (although ideally not quite that high) an acceptable short term solution until we have
> >> CPR? Or would it be safer to just not make use of the higher frequencies on a630 for now?
> >>
> >
> > tbh, I'm not sure about the regulator stuff and CPR.. Bjorn is already
> > on CC and I added sboyd, maybe one of them knows better.
> >
> > In the short term, removing the higher problematic OPPs from dts might
> > be a better option than this patch (which I'm dropping), since there
> > is nothing stopping other workloads from hitting higher OPPs.
> Oh yeah that sounds like a more sensible workaround than mine .
> >
> > I'm slightly curious why I didn't have problems at higher OPPs on my
> > c630 laptop (sdm850)
> Perhaps you won the sillicon lottery - iirc sdm850 is binned for higher clocks as is out of the factory.
>
> Would it be best to drop the OPPs for all devices? Or just those affected? I guess it's possible another c630 might
> crash where yours doesn't?

I've not heard any reports of similar issues from the handful of other
folks with c630's on #aarch64-laptops.. but I can't really say if that
is luck or not.

Maybe just remove it for affected devices?  But I'll defer to Bjorn.

BR,
-R

  reply	other threads:[~2021-07-29 20:49 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 18:39 [PATCH] drm/msm: Disable frequency clamping on a630 Rob Clark
2021-07-29 18:39 ` Rob Clark
2021-07-29 20:06 ` Caleb Connolly
2021-07-29 20:06   ` Caleb Connolly
2021-07-29 20:24   ` Rob Clark
2021-07-29 20:24     ` Rob Clark
2021-07-29 20:28     ` Caleb Connolly
2021-07-29 20:28       ` Caleb Connolly
2021-07-29 20:53       ` Rob Clark [this message]
2021-07-29 20:53         ` Rob Clark
2021-08-07 19:21         ` Caleb Connolly
2021-08-07 20:04           ` Rob Clark
2021-08-07 20:04             ` Rob Clark
2021-08-08 14:32             ` Caleb Connolly
2021-08-08 16:52               ` Rob Clark
2021-08-08 16:52                 ` Rob Clark
2021-08-09 14:51                 ` Akhil P Oommen
2021-08-09 16:12                   ` Rob Clark
2021-08-09 16:12                     ` Rob Clark
2021-08-09 16:18                     ` Caleb Connolly
2021-08-09 17:26                       ` Akhil P Oommen
2021-08-09 17:58                         ` Rob Clark
2021-08-09 17:58                           ` Rob Clark
2021-08-09 20:35                           ` Caleb Connolly
2021-08-09 21:08                             ` Rob Clark
2021-08-09 21:08                               ` Rob Clark
2021-09-07 15:43                               ` Bjorn Andersson
2021-09-08  2:21                         ` Bjorn Andersson
2021-09-08 13:49                           ` Caleb Connolly
2021-09-09 12:17                           ` Amit Pundir
2021-09-09 12:17                             ` Amit Pundir
2021-09-09 16:12                             ` Amit Pundir
2021-09-09 16:12                               ` Amit Pundir
2021-09-09 19:49                               ` Akhil P Oommen
2021-09-09 20:54                                 ` Rob Clark
2021-09-09 20:54                                   ` Rob Clark
2021-09-10 17:22                                   ` Rob Clark
2021-09-10 17:22                                     ` Rob Clark
2021-09-10 17:18                           ` Rob Clark
2021-09-10 17:18                             ` Rob Clark
2021-09-10 17:34                             ` Caleb Connolly
2021-09-13  6:15                               ` Akhil P Oommen
2021-09-03 19:39         ` John Stultz
2021-09-03 19:39           ` John Stultz
2021-09-03 20:29           ` Rob Clark
2021-09-03 20:29             ` Rob Clark
2021-09-06  8:01             ` Amit Pundir
2021-09-06  8:01               ` Amit Pundir
2021-09-06 16:28               ` Rob Clark
2021-09-06 16:28                 ` Rob Clark
2021-09-06 19:58                 ` Amit Pundir
2021-09-06 19:58                   ` Amit Pundir
2021-09-06 20:50                   ` Rob Clark
2021-09-06 20:50                     ` Rob Clark
2021-09-06 21:27                     ` Rob Clark
2021-09-06 21:27                       ` Rob Clark
2021-09-07  8:18                       ` Amit Pundir
2021-09-07  8:18                         ` Amit Pundir
2021-09-07  1:45                   ` Rob Clark
2021-09-07  1:45                     ` Rob Clark
2021-09-07  8:25                     ` Amit Pundir
2021-09-07  8:25                       ` Amit Pundir
2021-09-07 14:25                       ` Rob Clark
2021-09-07 14:25                         ` Rob Clark

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=CAF6AEGs11aYnkL30kp79pMqLTg3_4otFwG2Oc890Of2ndLbELw@mail.gmail.com \
    --to=robdclark@gmail.com \
    --cc=airlied@linux.ie \
    --cc=akhilpo@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=caleb.connolly@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jonathan@marek.ca \
    --cc=jordan@cosmicpenguin.net \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=sean@poorly.run \
    --cc=smasetty@codeaurora.org \
    /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.