From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"tzimmermann@suse.de" <tzimmermann@suse.de>
Subject: Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
Date: Wed, 2 Feb 2022 12:07:17 -0500 [thread overview]
Message-ID: <Yfq6RdAWGwEtMkYH@intel.com> (raw)
In-Reply-To: <20220201174133.mxkwzofmocskoc5k@ldmartin-desk2>
On Tue, Feb 01, 2022 at 09:41:33AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote:
> > On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> > > Only x86 and in some cases PPC have support added in drm_cache.c for the
> > > clflush class of functions. However warning once is sufficient to taint
> > > the log instead of spamming it with "Architecture has no drm_cache.c
> > > support" every few millisecond. Switch to WARN_ONCE() so we still get
> > > the log message, but only once, together with the warning. E.g:
> > >
> > > ------------[ cut here ]------------
> > > Architecture has no drm_cache.c support
> > > WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 drm_clflush_sg+0x40/0x50 [drm]
> > > ...
> > >
> > > v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()
> >
> > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> >
> > But while at it, why not add a drm_device parameter to this function so we can use drm_WARN_ONCE()?
> > Anyways, it is better than before.
>
> I thought about that, but it didn't seem justifiable because:
>
> 1) drm_WARN_ONCE will basically add dev_driver_string() to the log.
> However the warning message here is basically helping the bootstrap of
> additional archs. They shouldn't be seen on anything properly supported.
>
> 2) This seems all to be a layer below drm anyway and could even be used
> in places outside easy access to a drm pointer.
>
> So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE
> doesn't justify the hassle of changing the callers, possibly adding
> additional back pointers to have access to the drm device pointer.
Initially I had same feeling as Jose, but good points raised here.
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> thanks
> Lucas De Marchi
WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "airlied@linux.ie" <airlied@linux.ie>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"tzimmermann@suse.de" <tzimmermann@suse.de>,
"Souza, Jose" <jose.souza@intel.com>
Subject: Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
Date: Wed, 2 Feb 2022 12:07:17 -0500 [thread overview]
Message-ID: <Yfq6RdAWGwEtMkYH@intel.com> (raw)
In-Reply-To: <20220201174133.mxkwzofmocskoc5k@ldmartin-desk2>
On Tue, Feb 01, 2022 at 09:41:33AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote:
> > On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> > > Only x86 and in some cases PPC have support added in drm_cache.c for the
> > > clflush class of functions. However warning once is sufficient to taint
> > > the log instead of spamming it with "Architecture has no drm_cache.c
> > > support" every few millisecond. Switch to WARN_ONCE() so we still get
> > > the log message, but only once, together with the warning. E.g:
> > >
> > > ------------[ cut here ]------------
> > > Architecture has no drm_cache.c support
> > > WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 drm_clflush_sg+0x40/0x50 [drm]
> > > ...
> > >
> > > v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err()
> >
> > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> >
> > But while at it, why not add a drm_device parameter to this function so we can use drm_WARN_ONCE()?
> > Anyways, it is better than before.
>
> I thought about that, but it didn't seem justifiable because:
>
> 1) drm_WARN_ONCE will basically add dev_driver_string() to the log.
> However the warning message here is basically helping the bootstrap of
> additional archs. They shouldn't be seen on anything properly supported.
>
> 2) This seems all to be a layer below drm anyway and could even be used
> in places outside easy access to a drm pointer.
>
> So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE
> doesn't justify the hassle of changing the callers, possibly adding
> additional back pointers to have access to the drm device pointer.
Initially I had same feeling as Jose, but good points raised here.
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> thanks
> Lucas De Marchi
next prev parent reply other threads:[~2022-02-02 17:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 16:59 [Intel-gfx] [PATCH v3 0/3] drm/i915: Fix header test and log spam on !x86 Lucas De Marchi
2022-01-31 16:59 ` Lucas De Marchi
2022-01-31 16:59 ` [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message Lucas De Marchi
2022-01-31 16:59 ` Lucas De Marchi
2022-02-01 17:12 ` [Intel-gfx] " Souza, Jose
2022-02-01 17:12 ` Souza, Jose
2022-02-01 17:41 ` [Intel-gfx] " Lucas De Marchi
2022-02-01 17:41 ` Lucas De Marchi
2022-02-02 17:07 ` Rodrigo Vivi [this message]
2022-02-02 17:07 ` [Intel-gfx] " Rodrigo Vivi
2022-01-31 16:59 ` [Intel-gfx] [PATCH v3 2/3] drm/i915: Fix header test for !CONFIG_X86 Lucas De Marchi
2022-01-31 16:59 ` Lucas De Marchi
2022-02-01 8:48 ` [Intel-gfx] " Siva Mullati
2022-02-01 8:48 ` Siva Mullati
2022-02-01 17:12 ` [Intel-gfx] " Souza, Jose
2022-02-01 17:12 ` Souza, Jose
2022-01-31 16:59 ` [Intel-gfx] [PATCH v3 3/3] drm/i915: Do not spam log with missing arch support Lucas De Marchi
2022-01-31 16:59 ` Lucas De Marchi
2022-02-01 17:15 ` [Intel-gfx] " Souza, Jose
2022-01-31 18:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix header test and log spam on !x86 (rev2) Patchwork
2022-01-31 19:38 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=Yfq6RdAWGwEtMkYH@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=tzimmermann@suse.de \
/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.