Re: [PATCH 2/2] drm/i915/dp: check eDP display control capability registers

[Thierry Reding <thierry.reding@gmail.com>]

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

On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> Debug print the capabilities, and flag an error if the panel does not
> support adjusting backlight through the BL_PWM_DIM pin, requiring
> backlight control through DPCD.
> 
> I haven't seen such panels yet, but it's a matter of time. Give
> ourselves a reminder when we need to fix this for real.
> 
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)

I have a few general comments below, but this patch itself look fine,
so:

Reviewed-by: Thierry Reding <treding@nvidia.com>

> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index cbf33be..ea4f3d1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2816,6 +2816,20 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  			dev_priv->psr.sink_support = true;
>  			DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
>  		}
> +
> +		if (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
> +		    DP_DPCD_DISPLAY_CONTROL_CAP) {
> +			u8 ctrl[4] = { 0 };
> +
> +			intel_dp_aux_native_read(intel_dp, DP_EDP_REV,
> +						 ctrl, sizeof(ctrl));
> +			DRM_DEBUG_KMS("eDP DPCD CTRL %02x %02x %02x %02x\n",
> +				      ctrl[0], ctrl[1], ctrl[2], ctrl[3]);
> +
> +			/* We don't support DPCD backlight control yet. */
> +			if (ctrl[0] && (ctrl[1] & 1) && !(ctrl[2] & 1))
> +				DRM_ERROR("eDP AUX backlight control only\n");
> +		}
>  	}
>  
>  	if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &

I think a lot of eDP utility code could be made reusable across drivers.
We could probably do that by having each driver expose a drm_edp object
of some sort.

Actually, the same would be true of DP in general. Accessing the DPCD is
something that's driver specific, but once you know how to do that a lot
of code can be made generic. I think a struct drm_dp could look like
this:

	struct drm_dp;

	struct drm_dpcd_ops {
		ssize_t (*read)(struct drm_dp *dp, unsigned int offset,
				void *buffer, size_t size);
		ssize_t (*write)(struct drm_dp *dp, unsigned int offset,
				 const void *buffer, size_t size);
	};

	struct drm_dp {
		const struct drm_dpcd_ops *dpcd;
	};

Perhaps that could even be extended with functionality to implement link
training in a generic way. There are already quite a few helpers to help
with that in drivers/gpu/drm/drm_dp_helper.c, but they assume that the
DPCD will be handed to them as a large buffer and therefore cannot write
DPCD registers.

I suppose one could argue that it would be introducing a mid-layer, but
that layer would be really thin in my opinion. And it would allow a lot
of the algorithms to be written only once instead of multiple times.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 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