All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <treding@nvidia.com>
To: sonika.jindal@intel.com
Cc: alexdeucher@gmail.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, daniel.vetter@ffwll.ch
Subject: Re: [RFC] drm: Add utility function to check for edp1.4
Date: Wed, 29 Oct 2014 14:42:29 +0100	[thread overview]
Message-ID: <20141029134227.GA17727@ulmo.nvidia.com> (raw)
In-Reply-To: <1413958523-32742-1-git-send-email-sonika.jindal@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 2944 bytes --]

On Wed, Oct 22, 2014 at 11:45:23AM +0530, sonika.jindal@intel.com wrote:
> From: Sonika Jindal <sonika.jindal@intel.com>
> 
> v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set (Satheesh)
> 
> v3: Moving the utility function to drm_dp_helper (Daniel)
> 
> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
> ---
>  drivers/gpu/drm/drm_dp_helper.c |   15 +++++++++++++++
>  include/drm/drm_dp_helper.h     |    2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 08e33b8..a54a760 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -768,3 +768,18 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux)
>  	i2c_del_adapter(&aux->ddc);
>  }
>  EXPORT_SYMBOL(drm_dp_aux_unregister);
> +
> +bool drm_dp_is_edp_v1_4(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE])

I'd prefer if this didn't take a dpcd argument but rather directly
accessed the DP_EDP_CONFIGURATION_CAP register so that it can be used
directly rather than rely on the driver to have read a dpcd block in the
appropriate format.

> +{
> +	uint8_t reg;
> +
> +	if (dpcd[DP_EDP_CONFIGURATION_CAP] &
> +		 DP_DPCD_DISPLAY_CONTROL_CAPABLE) {
> +
> +		if (drm_dp_dpcd_read(aux, DP_EDP_REV, &reg, 1))
> +			if (reg == 0x03)
> +				return true;
> +	}
> +	return false;
> +}
> +EXPORT_SYMBOL(drm_dp_is_edp_v1_4);

Does it make sense to have a function that checks for a specific
version? Why not add one that returns the revision so that it can be
compared, something like:

	u8 value;

	drm_dp_dpcd_read(aux, DP_EDP_REV, &value, 1);

	return value;

Then we can do something like:

	#define DP_EDP_REV_1_1 0x00
	#define DP_EDP_REV_1_2 0x01
	#define DP_EDP_REV_1_3 0x02
	#define DP_EDP_REV_1_4 0x03

And code can simply compare against that:

	drm_dp_get_edp_revision(aux, &rev);

	if (rev >= DP_EDP_REV_1_4) {
		...
	}

The check in your variant will only match v1.4 exactly, but presumably
v1.5 will be backwards compatible. Having a direct check on the revision
code will allow code to continue to work with future, backwards-
compatible revisions.

> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8edeed0..b017e1e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -102,6 +102,8 @@
>  
>  #define DP_EDP_CONFIGURATION_CAP            0x00d   /* XXX 1.2? */
>  #define DP_TRAINING_AUX_RD_INTERVAL         0x00e   /* XXX 1.2? */
> +#define DP_DPCD_DISPLAY_CONTROL_CAPABLE     (1 << 3)

This seems to be a field in the DP_EDP_CONFIGURATION_CAP register, so it
should be sorted below that register, not DP_TRAINING_AUX_RD_INTERVAL.

> +#define DP_EDP_REV                          0x700

And this belongs further down, so it properly sorts into the list of
registers.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-10-29 13:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22  6:15 [RFC] drm: Add utility function to check for edp1.4 sonika.jindal
2014-10-29 13:42 ` Thierry Reding [this message]
2014-10-30  4:14   ` sonika
2014-10-31 16:06   ` Daniel Vetter
2014-11-03  8:25     ` Thierry Reding
2014-11-03  8:28       ` Daniel Vetter
2014-11-04  5:55         ` sonika

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=20141029134227.GA17727@ulmo.nvidia.com \
    --to=treding@nvidia.com \
    --cc=alexdeucher@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sonika.jindal@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 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.