| Message ID | 1371077699-30702-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jun 13, 2013 at 12:54:57AM +0200, Daniel Vetter wrote: > Dragging random garbage along from the BIOS isn't a good idea, since > we really only support exactly what we've set up. And hopefully we will get failures in the BIOS -> KMS transition making it much clearer what was missed. Rather than some random modeset in the future where we switch pipes or outputs or configuration or the weather changes. There were some bits that we don't set in pipeconf (mostly for frame offset and other esoteric features) that look like they might be used one day, but as above, we already have problems if they are needed. For the series, Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> However, I don't think I would be so bold as to tag this for stable. -Chris
On Thu, Jun 13, 2013 at 10:00:18AM +0100, Chris Wilson wrote: > On Thu, Jun 13, 2013 at 12:54:57AM +0200, Daniel Vetter wrote: > > Dragging random garbage along from the BIOS isn't a good idea, since > > we really only support exactly what we've set up. > > And hopefully we will get failures in the BIOS -> KMS transition making > it much clearer what was missed. Rather than some random modeset in the > future where we switch pipes or outputs or configuration or the weather > changes. > > There were some bits that we don't set in pipeconf (mostly for frame > offset and other esoteric features) that look like they might be used > one day, but as above, we already have problems if they are needed. > > For the series, > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks for the review, all merged to dinq. > However, I don't think I would be so bold as to tag this for stable. Well I wouldn't still be maintainer without the occasional mad case of stupid^Wbold ;-) But since I've decided to push the bugfix through -next we should have plenty of warning time in case it has a bad effect somewhere. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 85e023f..01f26b03 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5298,9 +5298,8 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc) int pipe = intel_crtc->pipe; uint32_t val; - val = I915_READ(PIPECONF(pipe)); + val = 0; - val &= ~PIPECONF_BPC_MASK; switch (intel_crtc->config.pipe_bpp) { case 18: val |= PIPECONF_6BPC; @@ -5319,11 +5318,9 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc) BUG(); } - val &= ~(PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_MASK); if (intel_crtc->config.dither) val |= (PIPECONF_DITHER_EN | PIPECONF_DITHER_TYPE_SP); - val &= ~PIPECONF_INTERLACE_MASK; if (intel_crtc->config.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE) val |= PIPECONF_INTERLACED_ILK; else @@ -5331,8 +5328,6 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc) if (intel_crtc->config.limited_color_range) val |= PIPECONF_COLOR_RANGE_SELECT; - else - val &= ~PIPECONF_COLOR_RANGE_SELECT; I915_WRITE(PIPECONF(pipe), val); POSTING_READ(PIPECONF(pipe));
Dragging random garbage along from the BIOS isn't a good idea, since we really only support exactly what we've set up. In the specific case for the bug reporter the BIOS used the 10bit gamma table, but since we only support an 8bit table the dark colors ended up all wrong and the light ones all unadjusted. Note that this has a nice implication for fastboot, it essentially means that we have quite a bit more state to check and compare before we can decide whether fastboot is possible. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65593 Reported-and-Tested-by: Thomas Hebb <tommyhebb@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_display.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)