From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs
Date: Wed, 11 Oct 2023 11:59:28 +0300 [thread overview]
Message-ID: <ZSZj8IDK66wowKol@intel.com> (raw)
In-Reply-To: <87r0m14k7x.fsf@intel.com>
On Wed, Oct 11, 2023 at 11:49:38AM +0300, Jani Nikula wrote:
> On Mon, 09 Oct 2023, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote:
> > For validation purposes, it might be useful to be able to
> > force Bigjoiner mode, even if current dotclock/resolution
> > do not require that.
> > Lets add such to option to debugfs.
> >
> > v2: - Apparently intel_dp_need_bigjoiner can't be used, when
> > debugfs entry is created so lets just check manually
> > the DISPLAY_VER.
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 71 +++++++++++++++++++
> > .../drm/i915/display/intel_display_types.h | 2 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> > 3 files changed, 78 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index f6d7c4d45fae..c806957cb902 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -1399,6 +1399,35 @@ out: drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > return ret;
> > }
> >
> > +static int i915_bigjoiner_enable_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
>
> struct intel_connector *connector, please. Yeah, this is copy-paste from
> other files, but they should be changed too.
>
> > + struct drm_device *dev = connector->dev;
>
> struct drm_i915_private *i915, please.
>
> > + struct drm_crtc *crtc;
> > + struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector));
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + int ret;
> > +
> > + if (!encoder)
> > + return -ENODEV;
> > +
> > + ret = drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
> > + if (ret)
> > + return ret;
>
> Why does show need locking but write doesn't?
>
> > +
> > + crtc = connector->state->crtc;
> > + if (connector->status != connector_status_connected || !crtc) {
> > + ret = -ENODEV;
> > + goto out;
> > + }
>
> I guess because of the above, but... do we need it? Or is this just
> copy-pasted from some other debugfs files, which copy-pasted from other
> debugfs files, which... ;)
Yeah, I would be honest here, had same question both for bool/int and crtc locking
however decided just to copy same approach, from other debugfs entries, assuming
that was done with some purpose :)
>
> > +
> > + seq_printf(m, "Bigjoiner enable: %d\n", intel_dp->force_bigjoiner_en);
> > +
> > +out: drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > +
> > + return ret;
> > +}
> > +
> > static ssize_t i915_dsc_output_format_write(struct file *file,
> > const char __user *ubuf,
> > size_t len, loff_t *offp)
> > @@ -1420,12 +1449,39 @@ static ssize_t i915_dsc_output_format_write(struct file *file,
> > return len;
> > }
> >
> > +static ssize_t i915_bigjoiner_enable_fops_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + struct drm_connector *connector =
> > + ((struct seq_file *)file->private_data)->private;
>
> I think this reads better with
>
> struct seq_file *m = file->private_data;
> struct intel_connector *connector = m->private;
>
> > + struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector));
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + int bigjoiner_en = 0;
> > + int ret;
> > +
> > + ret = kstrtoint_from_user(ubuf, len, 0, &bigjoiner_en);
> > + if (ret < 0)
> > + return ret;
>
> If it's a bool, why kstrtoint? Yeah, because copy-paste, but why keep
> percolating the same mistakes?
Yeah, as I said above..
>
> > +
> > + intel_dp->force_bigjoiner_en = bigjoiner_en;
> > + *offp += len;
> > +
> > + return len;
> > +}
> > +
> > static int i915_dsc_output_format_open(struct inode *inode,
> > struct file *file)
> > {
> > return single_open(file, i915_dsc_output_format_show, inode->i_private);
> > }
> >
> > +static int i915_bigjoiner_enable_open(struct inode *inode,
> > + struct file *file)
> > +{
> > + return single_open(file, i915_bigjoiner_enable_show, inode->i_private);
> > +}
> > +
> > static const struct file_operations i915_dsc_output_format_fops = {
> > .owner = THIS_MODULE,
> > .open = i915_dsc_output_format_open,
> > @@ -1435,6 +1491,15 @@ static const struct file_operations i915_dsc_output_format_fops = {
> > .write = i915_dsc_output_format_write
> > };
> >
> > +static const struct file_operations i915_bigjoiner_enable_fops = {
> > + .owner = THIS_MODULE,
> > + .open = i915_bigjoiner_enable_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > + .write = i915_bigjoiner_enable_fops_write
> > +};
> > +
> > /*
> > * Returns the Current CRTC's bpc.
> > * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> > @@ -1514,6 +1579,12 @@ void intel_connector_debugfs_add(struct intel_connector *intel_connector)
> > connector, &i915_dsc_output_format_fops);
> > }
> >
> > + if (DISPLAY_VER(dev_priv) >= 11 &&
> > + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> > + debugfs_create_file("i915_bigjoiner_force_enable", 0644, root,
> > + connector, &i915_bigjoiner_enable_fops);
>
> All of these should just pass struct intel_connector.
Do you mean intel_connector_debugfs_add? I think it does that already, will check.
>
> > + }
> > +
> > if (connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
> > connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> > connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 8d8b2f8d37a9..ecec8a25838e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1753,6 +1753,8 @@ struct intel_dp {
> > bool is_mst;
> > int active_mst_links;
> >
> > + bool force_bigjoiner_en;
>
> No need to try to shorten this, just spell out force_bigjoiner_enable.
Again just tried to match same things done before, but for me personally
doesn't really matter at all.
>
> > +
> > /* connector directly attached - won't be use for modeset in mst world */
> > struct intel_connector *attached_connector;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > index f0f43aeabd21..7e553cb7ecbb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1153,7 +1153,11 @@ bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > if (!intel_dp_can_bigjoiner(intel_dp))
> > return false;
> >
> > - return clock > i915->max_dotclk_freq || hdisplay > 5120;
> > + if (intel_dp->force_bigjoiner_en)
> > + drm_dbg_kms(&i915->drm, "Forcing bigjoiner mode");
>
> Missing \n.
Yes, will fix, thank you for comments!
Stan
>
> > +
> > + return clock > i915->max_dotclk_freq || hdisplay > 5120 ||
> > + intel_dp->force_bigjoiner_en;
> > }
> >
> > static enum drm_mode_status
>
> --
> Jani Nikula, Intel
next prev parent reply other threads:[~2023-10-11 8:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 13:30 [Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs Stanislav Lisovskiy
2023-10-09 22:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add bigjoiner force enable option to debugfs (rev2) Patchwork
2023-10-10 4:07 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-10-11 8:49 ` [Intel-gfx] [PATCH] drm/i915: Add bigjoiner force enable option to debugfs Jani Nikula
2023-10-11 8:59 ` Lisovskiy, Stanislav [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-16 10:37 Stanislav Lisovskiy
2023-11-16 13:48 ` Modem, Bhanuprakash
2023-10-18 13:24 Stanislav Lisovskiy
2023-10-25 12:59 ` Ville Syrjälä
2024-01-17 16:46 ` Sharma, Swati2
2024-01-17 18:01 ` Jani Nikula
2024-01-18 6:01 ` Sharma, Swati2
2023-10-12 12:34 Stanislav Lisovskiy
2023-10-12 14:59 ` Jani Nikula
2023-10-13 9:54 ` Lisovskiy, Stanislav
2023-10-17 9:49 ` kernel test robot
2023-10-06 14:15 Stanislav Lisovskiy
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=ZSZj8IDK66wowKol@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.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