[Intel-gfx] [PATCH v2 12/15] drm/i915: Stop frobbing with DDI encoder->type
Maarten Lankhorst
maarten.lankhorst at linux.intel.com
Tue Aug 23 10:16:32 UTC 2016
Op 22-06-16 om 20:57 schreef ville.syrjala at linux.intel.com:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> Now that we have the output_types bitmask in the crtc state, we
> can use it to indicate in which mode we want to drive the DDI
> encoders. For pre-DDI output_types will instead indicate what
> kind of cloning is being done, but as DDI platforms don't
> support cloning so we don't have to worry about mixing the two
> approaches.
>
> From here on out an encoder on DDI platforms can now have a
> type of DDI, EDP, ANALOG, or DP_MST. A DDI type encoder can be
> driven either in HDMI or DP SST mode. We maintain EDP as a
> seaparete type from DDI to keep is_edp() etc. working. ANALOG
> (ie. FDI) was already treated quite diffrently, so we'll stick
> to that. And MST encoders remain separate beasts as well.
>
> To achieve this neatly we'll add a new optional
> .compute_output_type() hook for encoders. Only encoders with
> multiple personalities will need to provide one. The hook can
> do whatever it needs to figure out what kind of signal should
> be output. Additionaly .get_config() will also need to read out
> the current type from the hardware somehow and fill that in.
> Note that in the name of consistency we'll populate the hook
> also for EDP encoders on DDI platforms even though the default
> fallback of using encoder->type would work just as well there.
>
> The reason for adding a new hook instead of letting
> .compute_config() do the work is to follow the rule that
> output_types will already be fully populated by the time
> .compute_config() is called for the first encoder (which
> simplifies things such as hdmi_12bpc_possible()).
>
> With output_types correctly populated, the biggest churn comes
> from changing various encoder->type checks to consult output_types
> instead.
>
> v2: Rebase, simplify intel_ddi_compute_config() output_types WARN
Ok connector state changes are finally upstream. Can you rebase?
More information about the Intel-gfx
mailing list