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@xxxxxxxxxxxxxxx>
>>>>>>>>> ---
>>>>>>>>> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
