From: Jani Nikula <jani.nikula@linux.intel.com>
To: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
mcanal@igalia.com, dri-devel@lists.freedesktop.org,
mwen@igalia.com, mairacanal@riseup.net, maxime@cerno.tech,
daniel.vetter@ffwll.ch, wambui.karugax@gmail.com
Subject: Re: [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex
Date: Fri, 17 Feb 2023 12:49:41 +0200 [thread overview]
Message-ID: <871qmozhve.fsf@intel.com> (raw)
In-Reply-To: <20230217103501.GC2862577@linux.intel.com>
On Fri, 17 Feb 2023, Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> wrote:
> On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
>> >
>> > But should not this the driver responsibility, call drm_debugfs_add_file()
>> > whenever you are ready to handle operations on added file ?
>>
>> In theory, yes, but in practice it's pretty hard for a non-trivial
>> driver to maintain that all the conditions are met.
>
> Hmmm...
>
>> In i915 we call debugfs register all over the place only after we've
>> called drm_dev_register(), because it's the only sane way. But it means
>> we need the init and register separated everywhere, instead of init
>> adding files to a list to be registered later.
>
> Isn't this done this way in i915 only because it was not possible
> (and still isn't) to call drm_debugfs_create_file() before registration ?
>
> I think it's should be ok by i915 subsystem to create it's debugfs
> files and allow to access to them just after that subsystem init.
>
> Or there are some complex dependencies between i915 subsystems,
> that reading registers from one subsystem will corrupt some
> other subsystem that did non finish initialization yet?
That's the point. It's really hard to figure it all out. Why bother?
BR,
Jani.
>
> Regards
> Stanislaw
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2023-02-17 10:50 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 8:18 Try to address the drm_debugfs issues Christian König
2023-02-09 8:18 ` [PATCH 1/3] drm/debugfs: separate debugfs creation into init and register Christian König
2023-02-14 11:56 ` Stanislaw Gruszka
2023-02-09 8:18 ` [PATCH 2/3] drm/debugfs: split registration into dev and minor Christian König
2023-02-09 11:12 ` Maíra Canal
2023-02-09 12:03 ` Christian König
2023-02-09 8:18 ` [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex Christian König
2023-02-14 12:19 ` Stanislaw Gruszka
2023-02-14 12:46 ` Stanislaw Gruszka
2023-02-16 11:33 ` Daniel Vetter
2023-02-16 11:37 ` Daniel Vetter
2023-02-16 16:00 ` Christian König
2023-02-16 16:46 ` Jani Nikula
2023-02-16 16:56 ` Christian König
2023-02-16 17:08 ` Jani Nikula
2023-02-16 19:54 ` Daniel Vetter
2023-02-17 9:22 ` Christian König
2023-02-17 10:01 ` Stanislaw Gruszka
2023-02-17 19:38 ` Daniel Vetter
2023-02-17 19:55 ` Christian König
2023-02-22 13:33 ` Stanislaw Gruszka
2023-02-16 16:37 ` Stanislaw Gruszka
2023-02-16 17:06 ` Jani Nikula
2023-02-16 19:56 ` Daniel Vetter
2023-02-17 10:35 ` Stanislaw Gruszka
2023-02-17 10:49 ` Jani Nikula [this message]
2023-02-17 11:36 ` Stanislaw Gruszka
2023-02-17 11:54 ` Christian König
2023-02-17 12:37 ` Jani Nikula
2023-02-17 15:55 ` Christian König
2023-02-17 19:42 ` Daniel Vetter
2023-02-17 19:49 ` Christian König
2023-02-09 11:23 ` Try to address the drm_debugfs issues Maíra Canal
2023-02-09 12:13 ` Christian König
2023-02-09 13:06 ` Maíra Canal
2023-02-09 14:06 ` Christian König
2023-02-09 14:19 ` Maxime Ripard
2023-02-09 15:52 ` Christian König
2023-02-09 18:48 ` Maxime Ripard
2023-02-10 12:07 ` Christian König
2023-02-10 12:18 ` Maxime Ripard
2023-02-10 13:10 ` Christian König
2023-02-16 11:34 ` Daniel Vetter
2023-02-16 16:31 ` Christian König
2023-02-16 19:57 ` Daniel Vetter
2023-02-13 18:16 ` Stanislaw Gruszka
2023-02-13 19:59 ` Christian König
2023-02-14 8:59 ` Stanislaw Gruszka
2023-02-14 9:28 ` Christian König
2023-02-14 11:46 ` Stanislaw Gruszka
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=871qmozhve.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=mairacanal@riseup.net \
--cc=maxime@cerno.tech \
--cc=mcanal@igalia.com \
--cc=mwen@igalia.com \
--cc=stanislaw.gruszka@linux.intel.com \
--cc=wambui.karugax@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 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.