From: Jani Nikula <jani.nikula@linux.intel.com>
To: Sam Ravnborg <sam@ravnborg.org>,
Thierry Reding <thierry.reding@gmail.com>
Cc: Stefan Mavrodiev <stefan@olimex.com>,
David Airlie <airlied@linux.ie>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*
Date: Fri, 01 Feb 2019 12:30:10 +0200 [thread overview]
Message-ID: <87tvhnyf65.fsf@intel.com> (raw)
In-Reply-To: <20190201092037.GA9251@ravnborg.org>
On Fri, 01 Feb 2019, Sam Ravnborg <sam@ravnborg.org> wrote:
> 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
Core and drivers are already pretty conflated:
http://patchwork.freedesktop.org/patch/msgid/20181227162310.13023-1-jani.nikula@intel.com
---
Side note, I'd like to switch i915 to dev based debugs, but I absolutely
hate the idea of changing:
DRM_DEBUG_KMS("...")
to:
DRM_DEV_DEBUG_KMS(dev_priv->drm.dev, "...")
I think the dev based macros are way too long, and would serve *most*
(though not all) drivers better by having struct drm_device * rather
than struct device * as the first param. In the above, just the
boilerplate consumes half the line.
Basically I'd like to see drm_ prefixed analogues to all the dev_ based
logging functions, e.g. drm_dbg that takes drm_device. But it's so much
churn that I'm contemplating just making i915 specific wrappers
instead. :(
BR,
Jani.
>
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2019-02-01 10:28 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
2019-02-01 10:30 ` Jani Nikula [this message]
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=87tvhnyf65.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.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