From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915/debugfs: New debugfs for display clock frequencies
Date: Tue, 18 Apr 2023 12:15:33 +0300 [thread overview]
Message-ID: <87jzy91rgq.fsf@intel.com> (raw)
In-Reply-To: <gi54slbykiwpc4elze5rt2fb2dsevbjs4l5en5r2iguysxuut3@zgx7gksjvq3a>
On Fri, 14 Apr 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Wed, Apr 12, 2023 at 12:22:51PM +0300, Jani Nikula wrote:
>>On Wed, 12 Apr 2023, Bhanuprakash Modem <bhanuprakash.modem@intel.com> wrote:
>>> +
>>> static ssize_t i915_displayport_test_active_write(struct file *file,
>>> const char __user *ubuf,
>>> size_t len, loff_t *offp)
>>> @@ -1065,6 +1080,7 @@ static const struct drm_info_list intel_display_debugfs_list[] = {
>>> {"i915_dp_mst_info", i915_dp_mst_info, 0},
>>> {"i915_ddb_info", i915_ddb_info, 0},
>>> {"i915_lpsp_status", i915_lpsp_status, 0},
>>> + {"i915_disply_clock_info", i915_display_clock_info, 0},
>>
>>Maybe "i915_cdclk_info"? (Also, disply has a typo there.)
>
> hijacking this a little bit since I saw the new version of this commit
> applied without the display_ part. Should we consider moving all the
> display-related debugfs files to display/ directory? I think that would
> make it clearer for the xe integration while also cleaning up a little
> bit the various files on i915. Downside would be synchronizing this with
> the tools reading those files. I guess it's only igt and CI that care about
> them?
While I agree in principle, I see potential for inflicting a lot of
paper cuts here.
We've moved individual files in the past, and it's generally been
fine. The pain is manageable. But seems like moving tons of files needs
to have some transition period with symlinks in kernel or igt checking
both places or something. Imagine bisecting a kernel bug using an igt
test, and needing two different igt builds depending on where the file
is.
On the other hand, maybe display/ directory is something that should be
reserved for drm to create. Anythin driver specific should be
prefixed. So either you'd have files named i915_display/* or
display/i915_*. Needs consideration.
I'm just leaning towards avoiding trouble at this time.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2023-04-18 9:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 9:09 [Intel-gfx] [PATCH 0/1] drm/i915/debugfs: New debugfs for display clock frequencies Bhanuprakash Modem
2023-04-12 9:09 ` [Intel-gfx] [PATCH 1/1] " Bhanuprakash Modem
2023-04-12 9:22 ` Jani Nikula
2023-04-12 10:49 ` Modem, Bhanuprakash
2023-04-14 15:51 ` Lucas De Marchi
2023-04-18 9:15 ` Jani Nikula [this message]
2023-04-12 12:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-04-12 20:07 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=87jzy91rgq.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@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: 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