From: Daniel Vetter <daniel@ffwll.ch>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
Date: Tue, 18 Jun 2019 23:46:56 +0200 [thread overview]
Message-ID: <20190618214656.GH12905@phenom.ffwll.local> (raw)
In-Reply-To: <20190618180113.GA26105@kroah.com>
On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > > these drivers, which would solve this issue, but in a more "non-drm"
> > > > way. Is it worth to just do that instead of overthinking the whole
> > > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> > >
> > > An example of "open coding" this is the patch below for the sor.c
> > > driver.
> >
> > I think open-coding is the way to go here. One of the todos is to
> > extend debugfs support for crtc/connectors, but looking at the
> > open-coded version we really don't need a drm-flavoured midlayer here.
>
> There already is debugfs support in the code for crtc/connectors, these
> files are "hanging" off of those locations already. I'll keep that, but
> indent it one more directory so that there's no namespace collisions.
The todo was to have some drm wrappers here for the boilerplate, but after
looking at your version that's not a good idea. So not just making sure
crtcs/connectors have a debugfs directory made for them, but more.
Wrt adding a new directory: debugfs isnt uapi, but there's usually a
massive pile of script relying on them, so it's not nice to shuffle paths
around. Plus the lifetimes match anyway (at least if you don't hotplug
connectors, which tegra doesn't do).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-18 21:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190614203615.12639-1-daniel.vetter@ffwll.ch>
[not found] ` <20190614203615.12639-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-06-14 20:35 ` [PATCH 06/59] drm/prime: Actually remove DRIVER_PRIME everywhere Daniel Vetter
[not found] ` <20190614203615.12639-7-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-06-14 21:36 ` Sam Ravnborg
2019-06-17 15:39 ` [PATCH] " Daniel Vetter
2019-06-17 17:56 ` [PATCH 06/59] " Emil Velikov
2019-06-14 20:35 ` [PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export Daniel Vetter
[not found] ` <20190614203615.12639-10-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2019-06-17 9:32 ` Koenig, Christian
2019-06-17 9:53 ` Thierry Reding
2019-06-21 10:37 ` Daniel Vetter
[not found] ` <20190614203615.12639-59-daniel.vetter@ffwll.ch>
2019-06-18 15:19 ` drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo) Greg Kroah-Hartman
2019-06-18 15:25 ` Greg Kroah-Hartman
2019-06-18 17:32 ` Daniel Vetter
2019-06-18 18:01 ` Greg Kroah-Hartman
2019-06-18 21:46 ` Daniel Vetter [this message]
2019-06-20 14:50 ` Thierry Reding
2019-06-20 15:11 ` Thierry Reding
2019-06-18 15:37 ` Jon Hunter
2019-06-20 15:16 ` Thierry Reding
2019-06-20 14:57 ` Thierry Reding
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=20190618214656.GH12905@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathanh@nvidia.com \
--cc=linux-tegra@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).