From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/15] drm/i915: Pass crtc_state and connector_state to encoder functions
Date: Tue, 23 Aug 2016 10:33:48 +0200 [thread overview]
Message-ID: <20160823083348.GA10980@phenom.ffwll.local> (raw)
In-Reply-To: <a03baca0-de9c-8260-0e11-85aed652a713@linux.intel.com>
On Tue, Aug 23, 2016 at 10:18:08AM +0200, Maarten Lankhorst wrote:
> Op 22-08-16 om 16:32 schreef Daniel Vetter:
> > On Mon, Aug 22, 2016 at 10:06:22AM +0200, Maarten Lankhorst wrote:
> >> Op 18-08-16 om 15:30 schreef Daniel Vetter:
> >>> On Tue, Aug 09, 2016 at 05:04:04PM +0200, Maarten Lankhorst wrote:
> >>>> This is mostly code churn, with exception of a few places:
> >>>> - intel_display.c has changes in intel_sanitize_encoder
> >>>> - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable,
> >>>> and required a function change. Also affects intel_display.c
> >>>> - intel_dp_mst.c passes a NULL crtc_state and conn_state to
> >>>> intel_ddi_post_disable for shutting down the real encoder.
> >>> I didn't find this NULL callsite. Outdated commit message?
> >> intel_dp_mst.c:
> >>
> >> + intel_dig_port->base.post_disable(&intel_dig_port->base,
> >> + old_crtc_state, NULL);
> >>
> >> Though it seems I accidentally pass old_crtc_state, that one should be NULL too.
> > Indeed I somehow missed that one. Still, why do we need to pass NULL
> > there? We should be able to wire up the state passing completely.
> In MST mode we have to do some enabling of the port regardless of crtc/MST connector.
>
> If we would pass conn_state, then conn_state->connector !=
> intel_dig_port->connector and conn_state->best_encoder !=
> to_intel_encoder(intel_dig_port). Why even bother passing conn_state at
> that point?
>
> We also shouldn't pass crtc_state, because in that case the disabling
> sequence may potentially be different depending on which crtc is
> disabled last. Nice source of bugs. :)
Ok, makes sense. Otoh I think we should just make sure that dp port
relevant parts of the crtc all match between all the mst streams.
But yeah passing the connector state doesn't make sense I guess.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-08-23 8:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 15:03 [PATCH 00/15] drm/i915: Use connector atomic state in encoders Maarten Lankhorst
2016-08-09 15:04 ` [PATCH 01/15] drm/i915: handle DP_MST correctly in bxt_get_dpll Maarten Lankhorst
2016-08-18 13:17 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 02/15] drm/i915: Pass atomic state to crtc enable/disable functions Maarten Lankhorst
2016-08-18 13:19 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 03/15] drm/i915: Remove unused mode_set hook from encoder Maarten Lankhorst
2016-08-18 13:20 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 04/15] drm/i915: Walk over encoders in crtc enable/disable using atomic state Maarten Lankhorst
2016-08-22 14:28 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 05/15] drm/i915: Pass crtc_state and connector_state to encoder functions Maarten Lankhorst
2016-08-18 13:30 ` Daniel Vetter
2016-08-22 8:06 ` Maarten Lankhorst
2016-08-22 14:32 ` Daniel Vetter
2016-08-23 8:18 ` Maarten Lankhorst
2016-08-23 8:33 ` Daniel Vetter [this message]
2016-08-23 11:48 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 06/15] drm/i915: Make encoder->compute_config take the connector state Maarten Lankhorst
2016-08-18 13:31 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 07/15] drm/i915: Remove unused loop from intel_dp_mst_compute_config Maarten Lankhorst
2016-08-18 13:34 ` Daniel Vetter
2016-08-22 12:43 ` Maarten Lankhorst
2016-08-22 14:33 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 08/15] drm/i915: Convert intel_crt to use atomic state Maarten Lankhorst
2016-08-18 13:35 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 09/15] drm/i915: Convert intel_dvo " Maarten Lankhorst
2016-08-18 13:36 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 10/15] drm/i915: Convert intel_dsi " Maarten Lankhorst
2016-08-18 13:43 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 11/15] drm/i915: Convert intel_sdvo " Maarten Lankhorst
2016-08-18 13:44 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 12/15] drm/i915: Convert intel_lvds " Maarten Lankhorst
2016-08-18 13:47 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 13/15] drm/i915: Convert intel_dp_mst " Maarten Lankhorst
2016-08-18 13:54 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 14/15] drm/i915: Convert intel_dp " Maarten Lankhorst
2016-08-18 14:01 ` Daniel Vetter
2016-08-09 15:04 ` [PATCH 15/15] drm/i915: Use more atomic state in intel_color.c Maarten Lankhorst
2016-08-18 14:02 ` Daniel Vetter
2016-08-09 15:55 ` ✗ Ro.CI.BAT: failure for drm/i915: Use connector atomic state in encoders Patchwork
2016-08-10 7:53 ` Patchwork
2016-08-18 14:04 ` [PATCH 00/15] " Daniel Vetter
2016-08-22 8:12 ` Maarten Lankhorst
-- strict thread matches above, loose matches on Subject: below --
2016-07-07 11:55 [PATCH 01/15] drm/i915: handle DP_MST correctly in bxt_get_dpll Maarten Lankhorst
2016-07-07 11:55 ` [PATCH 05/15] drm/i915: Pass crtc_state and connector_state to encoder functions Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160823083348.GA10980@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox