Re: [PATCH 07/19] drm/i915: add port power domains

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Feb 18, 2014 at 12:02:08AM +0200, Imre Deak wrote:
> Parts that poke port specific HW blocks like the encoder HW state
> readout or connector hotplug detect code need a way to check whether
> required power domains are on or enable/disable these. For this purpose
> add a set of power domains that refer to the port HW blocks. Get the
> proper port power domains during modeset.
> 
> For now when requesting the power domain for a DDI port get it for a 4
> lane configuration. This can be optimized later to request only the 2
> lane power domain, when proper support is added on the VLV PHY side for
> this. Atm, the PHY setup code assumes a 4 lane config in all cases.
> 
> Signed-off-by: Imre Deak <imre.deak@intel.com>

[snip]

> +enum intel_display_power_domain
> +intel_display_port_power_domain(struct intel_encoder *intel_encoder)
>  {
> +	struct drm_device *dev = intel_encoder->base.dev;
> +	struct intel_digital_port *intel_dig_port;
> +
> +	switch (intel_encoder->type) {
> +	case INTEL_OUTPUT_UNKNOWN:
> +		/* Only DDI platforms should ever use this output type */
> +		WARN_ON_ONCE(!HAS_DDI(dev));
> +	case INTEL_OUTPUT_DISPLAYPORT:
> +	case INTEL_OUTPUT_HDMI:
> +	case INTEL_OUTPUT_EDP:
> +		intel_dig_port = enc_to_dig_port(&intel_encoder->base);
> +		switch (intel_dig_port->port) {
> +		case PORT_A:
> +			return POWER_DOMAIN_PORT_DDI_A_4_LANES;
> +		case PORT_B:
> +			return POWER_DOMAIN_PORT_DDI_B_4_LANES;
> +		case PORT_C:
> +			return POWER_DOMAIN_PORT_DDI_C_4_LANES;
> +		case PORT_D:
> +			return POWER_DOMAIN_PORT_DDI_D_4_LANES;
> +		default:
> +			WARN_ON_ONCE(1);
> +			return POWER_DOMAIN_PORT_OTHER;
> +		}
> +	case INTEL_OUTPUT_ANALOG:
> +		return POWER_DOMAIN_PORT_CRT;
> +	case INTEL_OUTPUT_DSI:
> +		return POWER_DOMAIN_PORT_DSI;
> +	default:
> +		return POWER_DOMAIN_PORT_OTHER;
> +	}
> +}

This creeps me out a bit tbh ... I guess eventually this will grow out of
bounds and we should just track all the required power domains for an
output configuration in the pipe config structure. Then crtc, encoders and
everything else can or in bits as they see fit.

Also, we need to fix the ddi code to finally keep track of it's own state
and rid us of all that OUTPUT_UNKNOWN nonsense. Iirc Damien is on the hook
for that.

All stuff for follow-ups though.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch