Re: [PATCH 5/7] drm/i915: Make sure we invalidate frontbuffer on fbcon.

From: Rodrigo Vivi <rodrigo.vivi@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 5/7] drm/i915: Make sure we invalidate frontbuffer on fbcon.
Date: Wed, 4 Mar 2015 15:05:11 -0800	[thread overview]
Message-ID: <CABVU7+vrop30ew9=SV31njmX0dcaA9_dcA5zUU97XB9--=8z-Q@mail.gmail.com> (raw)
In-Reply-To: <20150304143051.GT18775@phenom.ffwll.local>

On Wed, Mar 4, 2015 at 6:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Mar 03, 2015 at 08:03:13PM +0000, Vivi, Rodrigo wrote:
>> On Tue, 2015-03-03 at 09:28 +0100, Daniel Vetter wrote:
>> > On Mon, Mar 02, 2015 at 06:35:26PM +0000, Vivi, Rodrigo wrote:
>> > > On Mon, 2015-03-02 at 18:59 +0100, Daniel Vetter wrote:
>> > > > On Fri, Feb 27, 2015 at 08:26:05PM -0500, Rodrigo Vivi wrote:
>> > > > > There are some cases like suspend/resume or dpms off/on sequences
>> > > > > that can flush frontbuffer bits. In these cases features that relies
>> > > > > on frontbuffer tracking can start working and user can stop getting
>> > > > > screen updates on fbcon having impression the system is frozen.
>> > > > >
>> > > > > So, let's make sure on fbcon write operation we also invalidate
>> > > > > frontbuffer bits so we will be on the safest side with fbcon.
>> > > >
>> > > > This is just a bandaid since you can always just directly access the
>> > > > fbdev framebuffer. We really need to figure out why we have frontbuffer
>> > > > bit flushes after we've invalidated them for fbcon and catch them all.
>> > >
>> > > yeah, an ugly bandaid... Just to make PSR a bit more reliable without
>> > > breaking fbcon environment when it gets enabled by default.
>> > >
>> > > The issue is that on the logs I see:
>> > >
>> > > 1.fbdev_blank dpms off
>> > > 2. disable planes
>> > > 3. flush frontbuffer bits
>> > > --- blank stage ---
>> > > 4. fbdev_blank dpms on
>> >
>> > so fbdev_blank returns _before_ the below enable_planes/frontbuf_flush?
>> > Can you please attach full backtraces for steps 5&6?
>>
>> [  156.665517] [drm:intel_fbdev_set_par] PSR FBDEV modeset
>> [  759.232969] [drm:intel_fbdev_blank] PSR FBDEV blank normal
>> [  759.232987] [drm:intel_crtc_disable_planes] PSR FBDEV crtc disable
>> planes flush fb bits
>> [  897.313095] [drm:intel_fbdev_blank] PSR FBDEV unblank
>> [  897.313112] [drm:intel_crtc_control] PSR FBDEV crtc enable planes
>> [  897.527818] [drm:haswell_crtc_enable] PSR FBDEV crtc enable planes
>> [  897.542925] [drm:intel_crtc_enable_planes] PSR FBDEV crtc enable
>> planes flush fb bits
>
> I didn't mean the drm.debug log but the full backtrace for every time we
> flush psr fb bits. I want to know who's the top-level function which
> eventualy leads to the fb flush. I.e. something like
>
>         WARN_ON(frontbuffer_bits);
>
> in intel_psr_flush (after we've filtered out any already set bits and
> other stuff that doesn't apply ofc).

I'm not sure if I understood your request...
This [  897.542925] [drm:intel_crtc_enable_planes] PSR FBDEV crtc
enable planes flush fb bits
is the point where frontbuffer bits will be flushed calling psr_flush
and psr gets back to life after the fbdev unblank.

>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx