From: Sam Ravnborg <sam@ravnborg.org> To: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org, sudeep.dutt@intel.com, dri-devel@lists.freedesktop.org, pankaj.laxminaryan.bharadiya@freedesktop.org, David Airlie <airlied@linux.ie> Subject: Re: [Intel-gfx] [PATCH 1/6] drm/print: introduce new struct drm_device based WARN* macros Date: Mon, 13 Jan 2020 19:54:56 +0100 [thread overview] Message-ID: <20200113185456.GA32145@ravnborg.org> (raw) In-Reply-To: <20200113115557.32713-2-pankaj.laxminarayan.bharadiya@intel.com> Hi Pankaj. On Mon, Jan 13, 2020 at 05:25:52PM +0530, Pankaj Bharadiya wrote: > Add new struct drm_device based WARN* macros. These are modeled after > the core kernel device based WARN* macros. These would be preferred > over the regular WARN* macros, where possible. > > These macros include device information in the backtrace, so we know > what device the warnings originate from. > > Knowing the device specific information in the backtrace would be > helpful in development all around. > > Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> > --- > include/drm/drm_print.h | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index 8f99d389792d..61a7224e697d 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -553,4 +553,34 @@ void __drm_err(const char *format, ...); > #define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...) \ > DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__) > > +/* > + * struct drm_device based WARNs > + * > + * > + * drm_WARN*() acts like WARN*(), but with the key difference of > + * using device specific information so that we know from which device > + * warning is originating from. > + * > + * Prefer drm_device based dev_WARN* over regular WARN* > + */ ... > + drm_WARN_ONCE((drm), (x), "%s", \ > + "drm_WARN_ON_ONCE(" __stringify(x) ")") > + > #endif /* DRM_PRINT_H_ */ As this is the now recommend way to use WARN() and friends, can we have this moved upward in this file. So we at some not-so-distant-future can have all the legacy logging in the bottom of the file, and all the shiny new stuff at the top. So people browsing the file see the new stuff before the legacy stuff. Not a big deal - we can always move it later if we are inclined to do so. Very good that you follow-up with some actual usage. This is a good way to verify that you got it right. Sam _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org> To: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, pankaj.laxminaryan.bharadiya@freedesktop.org, David Airlie <airlied@linux.ie>, Maxime Ripard <mripard@kernel.org> Subject: Re: [Intel-gfx] [PATCH 1/6] drm/print: introduce new struct drm_device based WARN* macros Date: Mon, 13 Jan 2020 19:54:56 +0100 [thread overview] Message-ID: <20200113185456.GA32145@ravnborg.org> (raw) In-Reply-To: <20200113115557.32713-2-pankaj.laxminarayan.bharadiya@intel.com> Hi Pankaj. On Mon, Jan 13, 2020 at 05:25:52PM +0530, Pankaj Bharadiya wrote: > Add new struct drm_device based WARN* macros. These are modeled after > the core kernel device based WARN* macros. These would be preferred > over the regular WARN* macros, where possible. > > These macros include device information in the backtrace, so we know > what device the warnings originate from. > > Knowing the device specific information in the backtrace would be > helpful in development all around. > > Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> > --- > include/drm/drm_print.h | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index 8f99d389792d..61a7224e697d 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -553,4 +553,34 @@ void __drm_err(const char *format, ...); > #define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...) \ > DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__) > > +/* > + * struct drm_device based WARNs > + * > + * > + * drm_WARN*() acts like WARN*(), but with the key difference of > + * using device specific information so that we know from which device > + * warning is originating from. > + * > + * Prefer drm_device based dev_WARN* over regular WARN* > + */ ... > + drm_WARN_ONCE((drm), (x), "%s", \ > + "drm_WARN_ON_ONCE(" __stringify(x) ")") > + > #endif /* DRM_PRINT_H_ */ As this is the now recommend way to use WARN() and friends, can we have this moved upward in this file. So we at some not-so-distant-future can have all the legacy logging in the bottom of the file, and all the shiny new stuff at the top. So people browsing the file see the new stuff before the legacy stuff. Not a big deal - we can always move it later if we are inclined to do so. Very good that you follow-up with some actual usage. This is a good way to verify that you got it right. Sam _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-01-13 18:55 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-13 11:55 [Intel-gfx] [PATCH 0/6]: drm: Introduce struct drm_device based WARN* and use them in i915 Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 11:55 ` [Intel-gfx] [PATCH 1/6] drm/print: introduce new struct drm_device based WARN* macros Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 12:30 ` Jani Nikula 2020-01-13 12:30 ` Jani Nikula 2020-01-13 18:54 ` Sam Ravnborg [this message] 2020-01-13 18:54 ` Sam Ravnborg 2020-01-13 11:55 ` [Intel-gfx] [PATCH 2/6] drm/i915: add helper functions to get device ptr Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 12:14 ` Jani Nikula 2020-01-13 12:14 ` Jani Nikula 2020-01-13 18:31 ` Bharadiya,Pankaj 2020-01-13 18:31 ` Bharadiya,Pankaj 2020-01-14 7:51 ` Jani Nikula 2020-01-14 7:51 ` Jani Nikula 2020-01-13 11:55 ` [Intel-gfx] [PATCH 3/6] drm/i915: Make WARN* drm specific where drm_device ptr available Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 11:55 ` [Intel-gfx] [PATCH 4/6] drm/i915: Make WARN* drm specific where drm_priv ptr is available Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 11:55 ` [Intel-gfx] [PATCH 5/6] drm/i915: Make WARN* drm specific where dev_priv can be extracted Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 11:55 ` [Intel-gfx] [PATCH 6/6] drm/i915: Make WARN* drm specific for various cases Pankaj Bharadiya 2020-01-13 11:55 ` Pankaj Bharadiya 2020-01-13 12:33 ` [Intel-gfx] [PATCH 0/6]: drm: Introduce struct drm_device based WARN* and use them in i915 Jani Nikula 2020-01-13 12:33 ` Jani Nikula 2020-01-13 18:34 ` Bharadiya,Pankaj 2020-01-13 18:34 ` Bharadiya,Pankaj 2020-01-13 15:08 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for : " 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=20200113185456.GA32145@ravnborg.org \ --to=sam@ravnborg.org \ --cc=airlied@linux.ie \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@intel.com \ --cc=pankaj.laxminarayan.bharadiya@intel.com \ --cc=pankaj.laxminaryan.bharadiya@freedesktop.org \ --cc=sudeep.dutt@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: linkBe 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.