Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

[Jani Nikula <jani.nikula@linux.intel.com>]

On Mon, 05 Jul 2021, venkata.sai.patnana@intel.com wrote:
> From: Patnana Venkata Sai <venkata.sai.patnana@intel.com>
>
> [What]:
> This patch creates a per connector debugfs node to expose
> the Input and Compressed BPP.
>
> The same node can be used from userspace to force
> DSC to a certain BPP(all accepted values).
>
> [Why]:
> Useful to verify all supported/requested compression bpp's
> through IGT
>
> v2: Remove unnecessary logic (Jani)
> v3: Drop pipe bpp in debugfs node (Vandita)
> v4: Minor cleanups (Vandita)
> v5: Fix NULL pointer dereference
> v6: Fix dim tool checkpatch errors
>     Release the lock before return (Vandita)

This is difficult to review because there is so much that should be
fixed in intel_display_debugfs.c in general and in this patch
specifically.

I think the first thing here is... have you actually tried this and
verified it works?

Just by reading the code, I don't think it is usable.

>
> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
> Cc: Navare Manasi D <manasi.d.navare@intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
> Signed-off-by: Patnana Venkata Sai <venkata.sai.patnana@intel.com>
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 106 +++++++++++++++++-
>  .../drm/i915/display/intel_display_types.h    |   1 +
>  2 files changed, 106 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 af9e58619667d..daa4018224b83 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2389,6 +2389,103 @@ static const struct file_operations i915_dsc_fec_support_fops = {
>  	.write = i915_dsc_fec_support_write
>  };
>  
> +static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
> +{
> +	struct drm_connector *connector = m->private;

General: I don't understand why we keep passing drm_connector instead of
intel_connector as private data.

> +	struct drm_device *dev = connector->dev;
> +	struct drm_crtc *crtc;
> +	struct intel_crtc_state *crtc_state = NULL;

Unnecessary initialization.

> +	struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector));
> +	int ret = 0;

Unnecessary initialization.

> +
> +	if (!encoder)
> +		return -ENODEV;
> +
> +	ret = drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
> +	if (ret)
> +		return ret;
> +
> +	crtc = connector->state->crtc;
> +	if (connector->status != connector_status_connected || !crtc) {
> +		drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +		return -ENODEV;

In general we use

	ret = -ENODEV;
        goto out;

with the unlock and other cleanup at the end, same unlock for both
success and fail paths. It's the prevalent style in kernel. Same all
over.

> +	}
> +
> +	crtc_state = to_intel_crtc_state(crtc->state);
> +	seq_printf(m, "Compressed_BPP: %d\n", crtc_state->dsc.compressed_bpp);
> +
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	return ret;
> +}
> +
> +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> +					  const char __user *ubuf,
> +					  size_t len, loff_t *offp)
> +{
> +	int dsc_bpp = 0;
> +	int ret;

Usually the more "context" style variables go first.

> +	struct drm_connector *connector =
> +		((struct seq_file *)file->private_data)->private;
> +	struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector));
> +	struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +	struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +	struct drm_crtc *crtc;
> +	struct intel_crtc_state *crtc_state = NULL;

Unnecessary initialization.

> +
> +	if (len == 0)
> +		return 0;

Should be unnecessary.

> +
> +	ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = drm_modeset_lock_single_interruptible(&i915->drm.mode_config.connection_mutex);
> +	if (ret)
> +		return ret;
> +
> +	crtc = connector->state->crtc;
> +	if (connector->status != connector_status_connected || !crtc) {
> +		drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
> +		return -ENODEV;

Ditto here about failure path.

> +	}
> +
> +	crtc_state = to_intel_crtc_state(crtc->state);
> +
> +	if (dsc_bpp <= 8 || dsc_bpp >= crtc_state->pipe_bpp) {

This is odd. In order to have crtc_state->pipe_bpp, or crtc state, you
must have done a modeset. That modeset must have been done without the
force_dsc_bpp. So in order to use this code, the test needs to:

- do a modeset
- set the force bpp
- do another modeset for the change to take effect

I don't think it makes sense to make that a requirement. Maybe we
shouldn't even require connector_status_connected. Just find intel_dp
and set ->force_dsc_bpp. Next modeset will use it. Have the value check
there.

This code also prevents you from resetting the force_dsc_bpp. If you set
it once, you can't set it back to 0 afterwards.

> +		drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
> +		drm_dbg(&i915->drm, "Compressed_BPP should be with in the limits\n");
> +
> +		return -EINVAL;
> +	}
> +
> +	drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
> +
> +	drm_dbg(&i915->drm,
> +		"Copied %zu bytes from user to force BPP\n", len);

This is a completely useless debug message.

> +
> +	intel_dp->force_dsc_bpp = dsc_bpp;
> +	*offp += len;
> +
> +	return len;
> +}
> +
> +static int i915_dsc_bpp_support_open(struct inode *inode,
> +				     struct file *file)
> +{
> +	return single_open(file, i915_dsc_bpp_support_show,
> +			   inode->i_private);
> +}
> +
> +static const struct file_operations i915_dsc_bpp_support_fops = {
> +	.owner = THIS_MODULE,
> +	.open = i915_dsc_bpp_support_open,
> +	.read = seq_read,
> +	.llseek = seq_lseek,
> +	.release = single_release,
> +	.write = i915_dsc_bpp_support_write
> +};

Maybe this should use DEFINE_SEQ_ATTRIBUTE() to avoid some boilerplate.

> +
>  /**
>   * intel_connector_debugfs_add - add i915 specific connector debugfs files
>   * @connector: pointer to a registered drm_connector
> @@ -2427,9 +2524,16 @@ int intel_connector_debugfs_add(struct drm_connector *connector)
>  				    connector, &i915_hdcp_sink_capability_fops);
>  	}
>  
> -	if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && !to_intel_connector(connector)->mst_port) || connector->connector_type == DRM_MODE_CONNECTOR_eDP))
> +	if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
> +	    ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
> +	      !to_intel_connector(connector)->mst_port) ||
> +	     connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
>  		debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
>  				    connector, &i915_dsc_fec_support_fops);
> +		debugfs_create_file("i915_dsc_bpp_support", 0444,
> +				    root, connector,
> +				    &i915_dsc_bpp_support_fops);
> +	}

I don't understand how either i915_dsc_fec_support or
i915_dsc_bpp_support (which is an odd name for something to set an
integer value to!) can work if their mode is read-only 0444.

Has either been tested?

BR,
Jani.

>  
>  	/* Legacy panels doesn't lpsp on any platform */
>  	if ((DISPLAY_VER(dev_priv) >= 9 || IS_HASWELL(dev_priv) ||
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index d94f361b548b7..19d8d3eefbc27 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1612,6 +1612,7 @@ struct intel_dp {
>  
>  	/* Display stream compression testing */
>  	bool force_dsc_en;
> +	int force_dsc_bpp;
>  
>  	bool hobl_failed;
>  	bool hobl_active;

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx