From: Sam Ravnborg <sam@ravnborg.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Sean Paul <sean@poorly.run>,
dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@linux.ie>,
Linus Walleij <linus.walleij@linaro.org>,
Stefan Mavrodiev <stefan@olimex.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*
Date: Fri, 1 Feb 2019 10:20:37 +0100 [thread overview]
Message-ID: <20190201092037.GA9251@ravnborg.org> (raw)
In-Reply-To: <20190131215417.GA13156@mithrandir>
Hi Thierry.
>
> I personally like the DRM_DEV_* variants better because of the
> additional information that they provide. That can be useful when
> grepping logs etc.
>
> I'm slightly on the fence about this patch. The unwritten, and
> admittedly fuzzy, rules that I've been using so far are that dev_*() are
> used or messages that have to do with the panel device itself, whereas
> DRM_* variants are used for things that are actually related to DRM. So
> typically this would mean that roughly everything in ->probe() or
> ->remove() would be dev_*(), while the rest would be DRM_DEV_*().
For a rookie like me it is much simpler if one can use the same
logging primitives all over or at least the rules when to use what is simple.
It is simple to say that everything that exists below drivers/gpu/drm/
relates to drm.
Suggested set of rules to follow:
- If in drm core, use DRM_XXX where XXX represent the core functionality
- If in a driver use DRM_DEV* if a struct device is available
- If in a driver and no struct device, use plain DRM_ERROR/INFO
If there is a need to distingush before/after one has a drm_device,
the best way would be to have a set of logging primitives that
take a drm_device. So we could extend the rule set:
- If in a driver use DRM_DRM* if a struct drm_device is available
(This rule would take precedence over a struct device)
DRM_DRM*, or DRM_DDEV* or ... But you get the idea.
But this is not where we are today.
Shall I redo the patch-set so we go back to dev_*() in probe() / remove()?
Sam
next prev parent reply other threads:[~2019-02-01 9:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 19:26 [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV* Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 01/19] drm/panel: drop drmP.h usage Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 02/19] drm/panel: panel-innolux: drop unused variable Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 03/19] drm/panel: samsung: use DRM_DEV* Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 04/19] drm/panel: arm-versatile: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 05/19] drm/panel: truly: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 06/19] drm/panel: sitronix: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 07/19] drm/panel: ilitek: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 08/19] drm/panel: innolux: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 09/19] drm/panel: jdi: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 10/19] drm/panel: lg: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 11/19] drm/panel: lvds: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 12/19] drm/panel: olimex: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 13/19] drm/panel: orisetech: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 14/19] drm/panel: panasonic: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 15/19] drm/panel: raspberrypi: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 16/19] drm/panel: raydium: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 17/19] drm/panel: seiko: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 18/19] drm/panel: sharp: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 19/19] drm/panel: simple: " Sam Ravnborg
2019-01-31 19:33 ` [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV* Sam Ravnborg
2019-01-31 20:07 ` Sean Paul
2019-01-31 21:03 ` Sam Ravnborg
2019-01-31 21:54 ` Thierry Reding
2019-02-01 9:20 ` Sam Ravnborg [this message]
2019-02-01 10:30 ` Jani Nikula
2019-02-01 10:52 ` Andrzej Hajda
2019-02-01 11:13 ` Jani Nikula
2019-02-01 13:37 ` Sam Ravnborg
2019-02-02 1:31 ` Joe Perches
2019-02-04 18:42 ` Sam Ravnborg
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=20190201092037.GA9251@ravnborg.org \
--to=sam@ravnborg.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sean@poorly.run \
--cc=stefan@olimex.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox