On Wed, Mar 04, 2015 at 03:05:11PM -0800, Rodrigo Vivi wrote: > On Wed, Mar 4, 2015 at 6:30 AM, Daniel Vetter <daniel@xxxxxxxx> 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. I know, but I want the stacktrace for that point in time. The easiest way to get that is a WARN_ON. If this would be userspace you could just use the gdb backtrace command. -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
