[Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Maarten Lankhorst]

Op 24-10-16 om 13:41 schreef Ville Syrjälä:
> On Mon, Oct 24, 2016 at 12:47:21PM +0200, Maarten Lankhorst wrote:
>> Op 24-10-16 om 12:17 schreef Ville Syrjälä:
>>> On Mon, Oct 24, 2016 at 12:12:59PM +0200, Maarten Lankhorst wrote:
>>>> Op 24-10-16 om 12:04 schreef Ville Syrjälä:
>>>>> On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
>>>>>> Op 21-10-16 om 16:16 schreef Ville Syrjälä:
>>>>>>> On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
>>>>>>>> On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
>>>>>>>>> drm_select_eld requires mode_config.mutex and connection_mutex
>>>>>>>>> because it looks at the connector list and at the legacy encoders.
>>>>>>>>>
>>>>>>>>> This is not required, because when we call audio_codec_enable we know
>>>>>>>>> which connector it was called for, so pass the state.
>>>>>>>>>
>>>>>>>>> This also removes having to look at crtc->config.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>>>>>>>> ---
>>>>>>>>>  drivers/gpu/drm/i915/intel_audio.c | 17 ++++++++++-------
>>>>>>>>>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
>>>>>>>>>  drivers/gpu/drm/i915/intel_dp.c    | 11 ++++++-----
>>>>>>>>>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
>>>>>>>>>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
>>>>>>>>>  5 files changed, 21 insertions(+), 15 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
>>>>>>>>> index 7093cfbb62b1..63ef25893c7e 100644
>>>>>>>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>>>>>>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>>>>>>>> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct drm_connector *connector,
>>>>>>>>>  /**
>>>>>>>>>   * intel_audio_codec_enable - Enable the audio codec for HD audio
>>>>>>>>>   * @intel_encoder: encoder on which to enable audio
>>>>>>>>> + * @crtc_state: pointer to the current crtc state.
>>>>>>>>> + * @conn_state: pointer to the current connector state.
>>>>>>>>>   *
>>>>>>>>>   * The enable sequences may only be performed after enabling the transcoder and
>>>>>>>>>   * port, and after completed link training.
>>>>>>>>>   */
>>>>>>>>> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
>>>>>>>>> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
>>>>>>>>> +			      const struct intel_crtc_state *crtc_state,
>>>>>>>>> +			      const struct drm_connector_state *conn_state)
>>>>>>>>>  {
>>>>>>>>>  	struct drm_encoder *encoder = &intel_encoder->base;
>>>>>>>>> -	struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>>>>>>>>> -	const struct drm_display_mode *adjusted_mode = &crtc->config->base.adjusted_mode;
>>>>>>>>> +	const struct drm_display_mode *adjusted_mode = &crtc_state->base.adjusted_mode;
>>>>>>>>>  	struct drm_connector *connector;
>>>>>>>>>  	struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>>>>>>>>>  	struct i915_audio_component *acomp = dev_priv->audio_component;
>>>>>>>>>  	enum port port = intel_encoder->port;
>>>>>>>>> -	enum pipe pipe = crtc->pipe;
>>>>>>>>> +	enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
>>>>>>>> While we may require that to be true, I'm not sure I like this use.
>>>>>>> I should say that otherwise I like this.
>>>>>> What do you mean with this comment?
>>>>> That the rest of the patch makes sense.
>>>>>
>>>> Sorry, I meant the first comment you wrote.
>>> I mean that 'enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);'
>>> is not something that's done anywhere else. So it looks totally foreign.
>>>
>> Not directly I guess. Some places already assume that drm_crtc_index == pipe.
>> But it's ok when I change it to to_intel_crtc(crtc)->pipe?
> Yes.
>
> If we wanted to, I guess we could just do
>
> static inline enum pipe intel_crtc_pipe(crtc)
> {
> 	return drm_crtc_index(&crtc->base);
> }
>
> and just nuke crtc->pipe entirely.
>
> And then we get to hope that the hw people aren't going to allow fusing
> off pipes in some random order (eg. just fuse off pipe B on a three pipe
> platform). That would obviously break this scheme.
>
That would already cause subtle bugs right now. Lets hope it never happens. :)

~Maarten