New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 736444 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

caroline goes into PSR mode when transitioning to dev mode

Project Member Reported by semenzato@chromium.org, Jun 23 2017

Issue description

During a transition to dev mode, caroline appears to hang i.e. the screen stops updating for long stretches (minutes) but once in a while it refreshes.  Switching to vt2 and back also refreshes the screen.

Doug mentioned we had a similar problem on kevin.

Copying some folks who may know how to direct this bug.
 
Cc: marc...@chromium.org hoegsberg@chromium.org
Owner: dbehr@chromium.org

Comment 2 by dbehr@chromium.org, Jul 12 2017

Probably need this in kernel 3.18?
commit 74b4ea1e4e8a5134b8a201e7fd6a3b529f7d0035
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Jul 14 16:29:14 2015 -0300

    drm/i915: special-case dirtyfb for frontbuffer tracking
    
    First, an introduction. We currently have two types of GTT mmaps: the
    "normal" old mmap, and the WC mmap. For frontbuffer-related features
    that have automatic hardware tracking, only the non-WC mmap writes are
    detected by the hardware. Since inside the Kernel both are treated as
    ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
    tracking are destined to fail.
    
    One of the special rules defined for the WC mmaps is that the user
    should call the dirtyfb IOCTL after he is done using the pointers, so
    that results in an intel_fb_obj_flush() call. The problem is that the
    dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
    though the hardware tracking is not detecing the WC mmap operations.
    So in order to fix that without having to give up the automatic
    hardware tracking for GTT mmaps we transform the flush operation from
    dirtyfb into a special operation: ORIGIN_DIRTYFB.
    
    This commit fixes all the kms_frontbuffer_tracking subtests that
    contain "fbc" and "mmap-wc" in their names and are currently failing
    (for a total of 16 subtests).
    
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 86e69f1ad3ee..994c411f095d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -894,6 +894,7 @@ enum fb_op_origin {
        ORIGIN_CPU,
        ORIGIN_CS,
        ORIGIN_FLIP,
+       ORIGIN_DIRTYFB,
 };
 
 struct i915_fbc {
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b25f3cac021a..f4ed4f13646c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14271,7 +14271,7 @@ static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
        struct drm_i915_gem_object *obj = intel_fb->obj;
 
        mutex_lock(&dev->struct_mutex);
-       intel_fb_obj_flush(obj, false, ORIGIN_GTT);
+       intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
        mutex_unlock(&dev->struct_mutex);
 
        return 0;

probably yes
Status: Assigned (was: Untriaged)

Sign in to add a comment