All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Simon Richter <Simon.Richter@hogyros.de>,
	<karthik.poosa@intel.com>, Zongyao Bai <zongyao.bai@intel.com>,
	<anshuman.gupta@intel.com>
Cc: "Constantinos Chalkias" <cch@e-psn.eu>,
	"Bata Roland Krisztián" <batarolandkrisztian@gmail.com>,
	intel-xe@lists.freedesktop.org, matthew.brost@intel.com,
	thomas.hellstrom@linux.intel.com, airlied@gmail.com,
	simona@ffwll.ch, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake
Date: Thu, 15 Oct 2026 08:47:00 -0400	[thread overview]
Message-ID: <atDLRDvuDES7u00Q@intel.com> (raw)
In-Reply-To: <55cba965-208a-44cd-a644-e664410af8a5@hogyros.de>

On Thu, Oct 15, 2026 at 11:29:37AM +0900, Simon Richter wrote:
> Hi,
> 
> On 10/15/26 5:12 AM, Rodrigo Vivi wrote:
> 
> > If the consensus is that we need this forcewake, let's do it.
> It feels like we haven't really understood the problem yet, we just know
> something that appears to work.

Cc: karthik.poosa@intel.com
Cc: anshuman.gupta@intel.com

Do we have a gitlab issue filed on this already? It should be good to
consolidate all the view there. Furthermore, perhaps we can get some internal
help from FW teams to assist in here.

> 
> If I run
> 
>     while true; do sleep 5 >forcewake_all; sleep 5; done & watch sensors
> 
> then the temperature sensors *do* update, but several of the VRAM channels
> take over a minute, so the long forcewake does not solve the problem. If
> shorter ones do, then I'd really like to understand why; my theory is that
> it's not the forcewake itself that does the job, but the fact that it's
> toggling, and possibly generating some events in some microcontroller. It
> may be sufficient to send some no-op commands instead of playing with the
> power rails.

I wonder if some forcewake histeresis might help on this case as well...

Cc: Zongyao Bai <zongyao.bai@intel.com>
https://lore.kernel.org/intel-xe/20260601213804.707256-1-zongyao.bai@intel.com/

> 
> Starting the loop above with pretty much everything at a nice toasty
> equilibrium temperature of 82 degrees (which is way too much IMO for a card
> that has no client connected and is just displaying a console login), the
> fans immediately come on, and apparently every ten seconds one of the VRAM
> channels updates to a lower temperature, so one forcewake event pretty much
> exactly corresponds to one sensor update.
> 
> That would explain why the patch works -- it generates the same number of
> forcewake events as sensor reads, and the delay makes sure they are
> registered as separate events. However, there is no correspondence between
> the event and the sensor, so if I do my normal telemetry recording (every
> sensor once every ten seconds) I can still get data that is ten seconds old,
> and I also wake up the GPU once every ten seconds even if there is nothing
> to do.
> 
> That is an improvement over the status quo, but my concern is that it will
> push us over into "good enough" territory where the actual problem is never
> addressed.
> 
>    Simon

  reply	other threads:[~2026-10-15 12:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 10:42 [PATCH] drm/xe/hwmon: refresh Battlemage thermal telemetry under force-wake Constantinos Chalkias
2026-10-12 10:59 ` sashiko-bot
2026-10-12 11:11   ` Constantinos Chalkias
2026-10-12 15:15 ` Simon Richter
2026-10-13  3:50   ` Simon.Richter
2026-10-12 18:50 ` ✗ LGCI.VerificationFailed: failure for " Patchwork
2026-10-14 20:12 ` [PATCH] " Rodrigo Vivi
2026-10-15  0:37   ` Constantinos Chalkias
2026-10-15  2:29   ` Simon Richter
2026-10-15 12:47     ` Rodrigo Vivi [this message]
2026-10-15 13:09       ` Simon Richter
  -- strict thread matches above, loose matches on Subject: below --
2026-10-13  5:39 Constantinos Chalkias
2026-10-13 10:25 ` Simon Richter

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=atDLRDvuDES7u00Q@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=Simon.Richter@hogyros.de \
    --cc=airlied@gmail.com \
    --cc=anshuman.gupta@intel.com \
    --cc=batarolandkrisztian@gmail.com \
    --cc=cch@e-psn.eu \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=karthik.poosa@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=simona@ffwll.ch \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=zongyao.bai@intel.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.