| Message ID | 20200128160952.1628146-1-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | radeon: insert 10ms sleep in dce5_crtc_load_lut | expand |
On Tue, Jan 28, 2020 at 11:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > Per at least one tester this is enough magic to recover the regression > introduced for some people (but not all) in > > commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 > Author: Peter Rosin <peda@axentia.se> > Date: Tue Jul 4 12:36:57 2017 +0200 > > drm/fb-helper: factor out pseudo-palette > > which for radeon had the side-effect of refactoring out a seemingly > redudant writing of the color palette. > > 10ms in a fairly slow modeset path feels like an acceptable form of > duct-tape, so maybe worth a shot and see what sticks. > > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: Michel Dänzer <michel.daenzer@amd.com> > References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Works for me. Applied. Thanks! Alex > --- > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c > index 354756e00fe1..d07c7db0c815 100644 > --- a/drivers/gpu/drm/radeon/radeon_display.c > +++ b/drivers/gpu/drm/radeon/radeon_display.c > @@ -127,6 +127,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc) > > DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id); > > + msleep(10); > + > WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset, > (NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) | > NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS))); > -- > 2.24.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jan 28, 2020 at 4:21 PM Alex Deucher <alexdeucher@gmail.com> wrote: > > On Tue, Jan 28, 2020 at 11:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > Per at least one tester this is enough magic to recover the regression > > introduced for some people (but not all) in > > > > commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 > > Author: Peter Rosin <peda@axentia.se> > > Date: Tue Jul 4 12:36:57 2017 +0200 > > > > drm/fb-helper: factor out pseudo-palette > > > > which for radeon had the side-effect of refactoring out a seemingly > > redudant writing of the color palette. > > > > 10ms in a fairly slow modeset path feels like an acceptable form of > > duct-tape, so maybe worth a shot and see what sticks. > > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > Cc: Michel Dänzer <michel.daenzer@amd.com> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > Works for me. Applied. Thanks! Actually, thinking about this more, I wonder if this will have adverse affects on stuff that messes with the LUT like various fade effects in compositors. I guess we can cross that bridge when we get to it. Alex > > Alex > > > > --- > > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c > > index 354756e00fe1..d07c7db0c815 100644 > > --- a/drivers/gpu/drm/radeon/radeon_display.c > > +++ b/drivers/gpu/drm/radeon/radeon_display.c > > @@ -127,6 +127,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc) > > > > DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id); > > > > + msleep(10); > > + > > WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset, > > (NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) | > > NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS))); > > -- > > 2.24.1 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jan 28, 2020 at 04:24:19PM -0500, Alex Deucher wrote: > On Tue, Jan 28, 2020 at 4:21 PM Alex Deucher <alexdeucher@gmail.com> wrote: > > > > On Tue, Jan 28, 2020 at 11:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > > > > > Per at least one tester this is enough magic to recover the regression > > > introduced for some people (but not all) in > > > > > > commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 > > > Author: Peter Rosin <peda@axentia.se> > > > Date: Tue Jul 4 12:36:57 2017 +0200 > > > > > > drm/fb-helper: factor out pseudo-palette > > > > > > which for radeon had the side-effect of refactoring out a seemingly > > > redudant writing of the color palette. > > > > > > 10ms in a fairly slow modeset path feels like an acceptable form of > > > duct-tape, so maybe worth a shot and see what sticks. > > > > > > Cc: Alex Deucher <alexander.deucher@amd.com> > > > Cc: Michel Dänzer <michel.daenzer@amd.com> > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > > > > Works for me. Applied. Thanks! > > Actually, thinking about this more, I wonder if this will have adverse > affects on stuff that messes with the LUT like various fade effects in > compositors. I guess we can cross that bridge when we get to it. With atomic and the new color manager stuff the legacy gamma table things go through a full atomic commit for at least some drivers already. So ratelimited to vblank. So for the overall ecosystem I think we crossed that bridge already, but yeah good point might be someone with an older stack on radeon being upset. -Daniel > > Alex > > > > > > Alex > > > > > > > --- > > > drivers/gpu/drm/radeon/radeon_display.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c > > > index 354756e00fe1..d07c7db0c815 100644 > > > --- a/drivers/gpu/drm/radeon/radeon_display.c > > > +++ b/drivers/gpu/drm/radeon/radeon_display.c > > > @@ -127,6 +127,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc) > > > > > > DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id); > > > > > > + msleep(10); > > > + > > > WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset, > > > (NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) | > > > NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS))); > > > -- > > > 2.24.1 > > > > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 354756e00fe1..d07c7db0c815 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -127,6 +127,8 @@ static void dce5_crtc_load_lut(struct drm_crtc *crtc) DRM_DEBUG_KMS("%d\n", radeon_crtc->crtc_id); + msleep(10); + WREG32(NI_INPUT_CSC_CONTROL + radeon_crtc->crtc_offset, (NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) | NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS)));
Per at least one tester this is enough magic to recover the regression introduced for some people (but not all) in commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 Author: Peter Rosin <peda@axentia.se> Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette which for radeon had the side-effect of refactoring out a seemingly redudant writing of the color palette. 10ms in a fairly slow modeset path feels like an acceptable form of duct-tape, so maybe worth a shot and see what sticks. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=198123 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- drivers/gpu/drm/radeon/radeon_display.c | 2 ++ 1 file changed, 2 insertions(+)