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

[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.

-- 
Ville Syrjälä
Intel OTC