| Message ID | 1460133040-21304-1-git-send-email-lionel.g.landwerlin@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Ping? On 08/04/16 17:30, Lionel Landwerlin wrote: > We are currently missing the color management update condition to > commit planes on crtc. > > Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > --- > drivers/gpu/drm/i915/intel_display.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index feb7028..670b2ad 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13480,6 +13480,13 @@ static bool needs_vblank_wait(struct intel_crtc_state *crtc_state) > return false; > } > > +static bool needs_commit_planes_on_crtc(struct drm_crtc_state *crtc_state) > +{ > + return (crtc_state->planes_changed || > + crtc_state->color_mgmt_changed || > + to_intel_crtc_state(crtc_state)->update_pipe); > +} > + > /** > * intel_atomic_commit - commit validated state object > * @dev: DRM device > @@ -13583,7 +13590,6 @@ static int intel_atomic_commit(struct drm_device *dev, > bool modeset = needs_modeset(crtc->state); > struct intel_crtc_state *pipe_config = > to_intel_crtc_state(crtc->state); > - bool update_pipe = !modeset && pipe_config->update_pipe; > > if (modeset && crtc->state->active) { > update_scanline_offset(to_intel_crtc(crtc)); > @@ -13597,8 +13603,8 @@ static int intel_atomic_commit(struct drm_device *dev, > drm_atomic_get_existing_plane_state(state, crtc->primary)) > intel_fbc_enable(intel_crtc); > > - if (crtc->state->active && > - (crtc->state->planes_changed || update_pipe)) > + if (crtc->state->active && !modeset && > + needs_commit_planes_on_crtc(crtc->state)) > drm_atomic_helper_commit_planes_on_crtc(old_crtc_state); > > if (pipe_config->base.active && needs_vblank_wait(pipe_config))
Op 08-04-16 om 18:30 schreef Lionel Landwerlin: > We are currently missing the color management update condition to > commit planes on crtc. > > Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
On Fri, Apr 08, 2016 at 05:30:40PM +0100, Lionel Landwerlin wrote: > We are currently missing the color management update condition to > commit planes on crtc. On a related note, could you move the LUT stuff out from the critical section? It has no business being there since the registers aren't double buffered. I'm thinking this is the cause for the sporadic atomic update fails that I've seen. > Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Jani Nikula <jani.nikula@intel.com> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > --- > drivers/gpu/drm/i915/intel_display.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index feb7028..670b2ad 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13480,6 +13480,13 @@ static bool needs_vblank_wait(struct intel_crtc_state *crtc_state) > return false; > } > > +static bool needs_commit_planes_on_crtc(struct drm_crtc_state *crtc_state) > +{ > + return (crtc_state->planes_changed || > + crtc_state->color_mgmt_changed || > + to_intel_crtc_state(crtc_state)->update_pipe); > +} > + > /** > * intel_atomic_commit - commit validated state object > * @dev: DRM device > @@ -13583,7 +13590,6 @@ static int intel_atomic_commit(struct drm_device *dev, > bool modeset = needs_modeset(crtc->state); > struct intel_crtc_state *pipe_config = > to_intel_crtc_state(crtc->state); > - bool update_pipe = !modeset && pipe_config->update_pipe; > > if (modeset && crtc->state->active) { > update_scanline_offset(to_intel_crtc(crtc)); > @@ -13597,8 +13603,8 @@ static int intel_atomic_commit(struct drm_device *dev, > drm_atomic_get_existing_plane_state(state, crtc->primary)) > intel_fbc_enable(intel_crtc); > > - if (crtc->state->active && > - (crtc->state->planes_changed || update_pipe)) > + if (crtc->state->active && !modeset && > + needs_commit_planes_on_crtc(crtc->state)) > drm_atomic_helper_commit_planes_on_crtc(old_crtc_state); > > if (pipe_config->base.active && needs_vblank_wait(pipe_config)) > -- > 2.8.0.rc3 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hey, Op 18-04-16 om 13:05 schreef Lionel Landwerlin: > Ping? > Will commit, but looks like Ville made a comment about double buffering. Everything in intel_pipe_update_start depends on double buffering, so if the lut isn't then it probably has to be done either before or afterwards. Not sure which, either way would produce some flickering. :( ~Maarten
Op 09-04-16 om 08:26 schreef Patchwork: > == Series Details == > > Series: drm/i915: add missing condition for committing planes on crtc > URL : https://patchwork.freedesktop.org/series/5467/ > State : failure > > == Summary == > > Series 5467v1 drm/i915: add missing condition for committing planes on crtc > http://patchwork.freedesktop.org/api/1.0/series/5467/revisions/1/mbox/ > > Test drv_module_reload_basic: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Test gem_exec_basic: > Subgroup basic-bsd: > dmesg-warn -> PASS (bsw-nuc-2) > Test gem_exec_suspend: > Subgroup basic-s3: > dmesg-warn -> PASS (bsw-nuc-2) > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Test gem_sync: > Subgroup basic-bsd: > dmesg-warn -> PASS (bsw-nuc-2) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup basic-flip-vs-modeset: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup basic-flip-vs-wf_vblank: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup basic-plain-flip: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (skl-i7k-2) > pass -> DMESG-WARN (bdw-ultra) > Test kms_frontbuffer_tracking: > Subgroup basic: > pass -> FAIL (bsw-nuc-2) > pass -> FAIL (ivb-t430s) > pass -> DMESG-FAIL (bdw-ultra) > pass -> FAIL (skl-i7k-2) > pass -> FAIL (byt-nuc) > pass -> FAIL (snb-x220t) > pass -> FAIL (snb-dellxps) > pass -> FAIL (hsw-brixbox) > pass -> DMESG-FAIL (bdw-nuci7) > skip -> FAIL (ilk-hp8440p) > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-a: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup hang-read-crc-pipe-b: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup hang-read-crc-pipe-c: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-a: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-a-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-b: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-b-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-c: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup nonblocking-crc-pipe-c-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-a: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-a-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-b: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-b-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-c: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup read-crc-pipe-c-frame-sequence: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup suspend-read-crc-pipe-a: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup suspend-read-crc-pipe-b: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup suspend-read-crc-pipe-c: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Test kms_psr_sink_crc: > Subgroup psr_basic: > pass -> DMESG-WARN (bdw-ultra) > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Subgroup basic-rte: > dmesg-warn -> PASS (bsw-nuc-2) > pass -> DMESG-WARN (bdw-nuci7) > pass -> DMESG-WARN (bdw-ultra) > Please look at the CI results. ~Maarten
On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: > Hey, > > Op 18-04-16 om 13:05 schreef Lionel Landwerlin: > > Ping? > > > Will commit, but looks like Ville made a comment about double buffering. > > Everything in intel_pipe_update_start depends on double buffering, so if the lut isn't then it probably has to be done either before or afterwards. Not sure which, either way would produce some flickering. :( It should be done from a vblank worker. Unfortunately we still don't have those, so either before or after is fine, and it'll result in exactly the same amount of flickering as the current code.
On 21/04/16 14:57, Ville Syrjälä wrote: > On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: >> Hey, >> >> Op 18-04-16 om 13:05 schreef Lionel Landwerlin: >>> Ping? >>> >> Will commit, but looks like Ville made a comment about double buffering. >> >> Everything in intel_pipe_update_start depends on double buffering, so if the lut isn't then it probably has to be done either before or afterwards. Not sure which, either way would produce some flickering. :( > It should be done from a vblank worker. Unfortunately we still don't > have those, so either before or after is fine, and it'll result in > exactly the same amount of flickering as the current code. > Should I take from this that the patch is fine for now as we don't have vblank workers yet? I can resend another version with a TODO comment. Thanks, - Lionel
Op 04-05-16 om 12:25 schreef Lionel Landwerlin: > On 21/04/16 14:57, Ville Syrjälä wrote: >> On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: >>> Hey, >>> >>> Op 18-04-16 om 13:05 schreef Lionel Landwerlin: >>>> Ping? >>>> >>> Will commit, but looks like Ville made a comment about double buffering. >>> >>> Everything in intel_pipe_update_start depends on double buffering, so if the lut isn't then it probably has to be done either before or afterwards. Not sure which, either way would produce some flickering. :( >> It should be done from a vblank worker. Unfortunately we still don't >> have those, so either before or after is fine, and it'll result in >> exactly the same amount of flickering as the current code. >> > Should I take from this that the patch is fine for now as we don't have vblank workers yet? > I can resend another version with a TODO comment. Ok, but make sure all CI tests pass this time. :)
On Wed, May 04, 2016 at 11:25:12AM +0100, Lionel Landwerlin wrote: > On 21/04/16 14:57, Ville Syrjälä wrote: > > On Thu, Apr 21, 2016 at 03:30:09PM +0200, Maarten Lankhorst wrote: > >> Hey, > >> > >> Op 18-04-16 om 13:05 schreef Lionel Landwerlin: > >>> Ping? > >>> > >> Will commit, but looks like Ville made a comment about double buffering. > >> > >> Everything in intel_pipe_update_start depends on double buffering, so if the lut isn't then it probably has to be done either before or afterwards. Not sure which, either way would produce some flickering. :( > > It should be done from a vblank worker. Unfortunately we still don't > > have those, so either before or after is fine, and it'll result in > > exactly the same amount of flickering as the current code. > > > Should I take from this that the patch is fine for now as we don't have > vblank workers yet? It should be moved out regardless as having it in the critical section has only downsides, no upsides. We do want to keep the CSC in the critical section since it's double buffered (at least on PCH platforms, not so sure about VLV/CHV).
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index feb7028..670b2ad 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13480,6 +13480,13 @@ static bool needs_vblank_wait(struct intel_crtc_state *crtc_state) return false; } +static bool needs_commit_planes_on_crtc(struct drm_crtc_state *crtc_state) +{ + return (crtc_state->planes_changed || + crtc_state->color_mgmt_changed || + to_intel_crtc_state(crtc_state)->update_pipe); +} + /** * intel_atomic_commit - commit validated state object * @dev: DRM device @@ -13583,7 +13590,6 @@ static int intel_atomic_commit(struct drm_device *dev, bool modeset = needs_modeset(crtc->state); struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state); - bool update_pipe = !modeset && pipe_config->update_pipe; if (modeset && crtc->state->active) { update_scanline_offset(to_intel_crtc(crtc)); @@ -13597,8 +13603,8 @@ static int intel_atomic_commit(struct drm_device *dev, drm_atomic_get_existing_plane_state(state, crtc->primary)) intel_fbc_enable(intel_crtc); - if (crtc->state->active && - (crtc->state->planes_changed || update_pipe)) + if (crtc->state->active && !modeset && + needs_commit_planes_on_crtc(crtc->state)) drm_atomic_helper_commit_planes_on_crtc(old_crtc_state); if (pipe_config->base.active && needs_vblank_wait(pipe_config))
We are currently missing the color management update condition to commit planes on crtc. Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> --- drivers/gpu/drm/i915/intel_display.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)