Re: [PATCH] drm/i915: fix up readout of the lvds dither bit on gen2/3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 22, 2013 at 06:55:55AM +0200, Knut Petersen wrote:
> On 11.07.2013 19:22, Daniel Vetter wrote:
> >On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote:
> >>On 11.07.2013 13:49, Chris Wilson wrote:
> >>>On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote:
> >>>>It's in the PFIT_CONTROL register, but very much associated with the
> >>>>lvds encoder. So move the readout for it (in the case of an otherwise
> >>>>disabled pfit) from the pipe to the lvds encoder's get_config
> >>>>function.
> >>>>
> >>>>Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
> >>>>output and we've left the dither bit enabled behind us. This can
> >>>>happen if the BIOS has set the bit (some seem to unconditionally do
> >>>>that, even in the complete absence of an lvds port), but not enabled
> >>>>pipe B at boot-up. Then we won't clear the pfit control register since
> >>>>we can only touch that if the pfit is associated with our pipe in the
> >>>>crtc configuration - we could trample over the pfit state of the other
> >>>>pipe otherwise since it's shared. Once pipe B is enabled we notice
> >>>>that the 6to8 dither bit is set and complain about the mismatch.
> >>>>
> >>>>Note that testing indicates that we don't actually need to set this
> >>>>bit when the pfit is disabled, dithering on 18bpp panels seems to work
> >>>>regardless. But ripping that code out is not something for a bugfix
> >>>>meant for -rc kernels.
> >>>>
> >>>>v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
> >>>>comments from Chris on irc.
> >>>>
> >>>>v3: Use Chris suggestion to make the control flow in
> >>>>i9xx_get_pfit_config easier to understand.
> >>>>
> >>>>v4: Kill the extra line, spotted by Chris.
> >>>>
> >>>>Reported-by: Knut Petersen <Knut_Petersen@xxxxxxxxxxx>
> >>>>Cc: Knut Petersen <Knut_Petersen@xxxxxxxxxxx>
> >>>>Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >>>>References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html
> >>>>Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> >>>Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >>>-Chris
> >>>
> >>Tested-by: Knut Petersen <Knut_Petersen@xxxxxxxxxxx>
> >>
> >>Thanks, that patch cures both inital boot and suspend/resume problems.
> >>Attached find dmesg (inital boot) and dmesg2 (suspend/resume cycle).
> >Thanks for testing and reporting this issue, patch is merged into my
> >-fixes queue now.
> >
> >Thanks, Daniel
> We have -rc2, but this patch is still missing ...

I'm flushing out my current -fixes to with a pull request to Dave today.
I've had a bit a hold-up with other regressions unfortunately.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux