The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/c24beb0995acea4202ae7f5fa70322710d37a0dd

commit c24beb0995acea4202ae7f5fa70322710d37a0dd
Author: Lev Rumyantsev <levarum@google.com>
Date: Thu Mar 29 16:56:31 2018

Move graphics_Idle.arc to bvt-perbuild

BUG= chromium:827188 
BUG=b:77241839
TEST=None

Change-Id: I2acafa83627c506ddcbcdb7ec01ae1fcab2e455f
Reviewed-on: https://chromium-review.googlesource.com/986501
Tested-by: Lev Rumyantsev <levarum@chromium.org>
Trybot-Ready: Lev Rumyantsev <levarum@chromium.org>
Reviewed-by: Tadashi G. Takaoka <takaoka@chromium.org>
Reviewed-by: Luis Hector Chavez <lhchavez@chromium.org>
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
Commit-Queue: Lev Rumyantsev <levarum@chromium.org>

[modify] https://crrev.com/c24beb0995acea4202ae7f5fa70322710d37a0dd/client/site_tests/graphics_Idle/control.arc

Gurchetan, unfortunately we need to bisect Chrome on Samus the graphics_Idle.arc test (Did not see PSR enabled.) with tot image in this range
https://chromium.googlesource.com/chromium/src/+log/67.0.3376.0..67.0.3381.0?n=10000

For details https://b.corp.google.com/issues/77241839#comment16

Failure history
https://stainless.corp.google.com/search?status=FAIL&status=ERROR&status=ABORT&test=%5Egraphics%5C_Idle%5C.arc%24&exclude_non_release=false&exclude_cts=true&view=list&first_date=2018-03-23&last_date=2018-03-29

Isn't this the job of the Chrome gardener to bisect this?

@afakhry, PTAL

I've already started bisecting, should be quick

[bisected]:

292706dad68802d7eb6402799586e036d97739d1 is the first bad commit
commit 292706dad68802d7eb6402799586e036d97739d1
Author: Kristian H. Kristensen <hoegsberg@chromium.org>
Date:   Fri Mar 23 17:26:01 2018 +0000

    Reland "ozone/drm: Render primary framebuffers as RGBA"
    
    This is a reland of 48d1ecafe170a41e0e1eee736370f0f56f9e3e93
    
    With CL:967415 and CL:964984, we've fixed the issues where RGBA
    framebuffers slipped through to KMS on devices without RGBA support.
    
    Original change's description:
    > ozone/drm: Render primary framebuffers as RGBA
    >
    > In preparation for hardware plane underlay support in ChromeOS, we
    > need to allow for RGBA primary framebuffers. When using an underlay,
    > we cut out a transparent rectangle in the primary framebuffer to allow
    > the underlay to show through, while still allowing for RGBA content on
    > top of the underlay (for example, video controls or annotations).
    > When not using an underlay, the primary framebuffer will be displayed
    > as RGBX (opaque) to avoid unnecessary blending in the display
    > controller.
    >
    > Bug: 789288
    > Change-Id: I2fc94e524e250ec9b7e11cd6801e1c8308046a10
    > Reviewed-on: https://chromium-review.googlesource.com/801974
    > Reviewed-by: Alex Sakhartchouk <alexst@chromium.org>
    > Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
    > Reviewed-by: David Reveman <reveman@chromium.org>
    > Reviewed-by: danakj <danakj@chromium.org>
    > Reviewed-by: Antoine Labour <piman@chromium.org>
    > Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
    > Commit-Queue: Kristian H. Kristensen <hoegsberg@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#542877}
    
    TBR: piman
    Bug: 789288
    Change-Id: Ie1032615d8970c6a74f354ad78c30679706e40ed
    Reviewed-on: https://chromium-review.googlesource.com/975782
    Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
    Reviewed-by: Alex Sakhartchouk <alexst@chromium.org>
    Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
    Reviewed-by: David Reveman <reveman@chromium.org>
    Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#545503}

:040000 040000 b280e5cfc64f43a9bf31b75566f33ee1452ef195 6acc65df61d22720fb799577c726aa0eee5848ec M	components
:040000 040000 4e18d98dbfc55d81583a221531a4c38a5c93a672 b7d714ef1441f52c7533b67bceca9c0486771b16 M	content
:040000 040000 342461a6b2726a8394519a797f128a28d12bd765 696d9d035f01c8d70a1b92038a653134d220c428 M	ui

The above change has been reverted and then was re-landed:

commit 11b329d73f13fd2a6a8c84015c44ad58e72773a2
Author: Kristian H. Kristensen <hoegsberg@chromium.org>
Date:   Fri Mar 30 23:35:11 2018 +0000

    Reland "Reland "ozone/drm: Render primary framebuffers as RGBA""
    
    This reverts commit 7c475ee71ef38604a435b9027dd47d8462337344.
    
    Reason for revert: We've fixed the issue where eglCreateImageKHR fails with ARGB+AFBC and reverted CL:985033 which enabled blending for the lowest order plane, which doesn't work everywhere.


So I can still reproduce this with a ToT Chrome build.  I verified reverting "Reland "Reland "ozone/drm: Render primary framebuffers as RGBA""" fixes the issue

hoegsberg@, can you investigate why this breaks PSR on Samus?  This is the command to run graphics idle (or test_that graphics_idle):

localhost ~ # /usr/local/autotest/bin/autotest /usr/local/autotest/tests/graphics_Idle/control

BTW, this happens on the normal graphics_Idle too, not just graphics_Idle.arc:

https://stainless.corp.google.com/search?test=%5Egraphics%5C_VTSwitch%24&exclude_non_release=false&exclude_cts=true&col=build&row=model&view=matrix&first_date=2018-03-24&last_date=2018-03-30

I am pushing a revert to the CQ https://chromium-review.googlesource.com/#/c/chromium/src/+/989076/

I am losing the point: was it reland of the the revert of reland, or was it revert of reland of revert of reland ?

Let's create new CL next time someone wants to land this functionality again ;)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc0ee6e2747366c3636bc85a35c3ec22b53c3570

commit cc0ee6e2747366c3636bc85a35c3ec22b53c3570
Author: Stéphane Marchesin <marcheu@chromium.org>
Date: Sat Mar 31 04:20:58 2018

Revert "Reland "Reland "ozone/drm: Render primary framebuffers as RGBA"""

This reverts commit 11b329d73f13fd2a6a8c84015c44ad58e72773a2.

This breaks samus

TBR=avi@chromium.org,marcheu@chromium.org,reveman@chromium.org,sky@chromium.org,danakj@chromium.org,alexst@chromium.org,dcastagna@chromium.org,piman@chromium.org,hoegsberg@chromium.org
BUG= chromium:827188 
TEST=revert fixes it

Change-Id: Ieca93d4bc1d8827edc07749971f23e52291051ae
Reviewed-on: https://chromium-review.googlesource.com/989076
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547374}
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/components/viz/service/display_embedder/buffer_queue_unittest.cc
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/content/browser/compositor/gpu_process_transport_factory.cc
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/ui/display/types/display_snapshot.cc
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/ui/gfx/linux/client_native_pixmap_factory_dmabuf.cc
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/ui/ozone/demo/surfaceless_skia_renderer.cc
[modify] https://crrev.com/cc0ee6e2747366c3636bc85a35c3ec22b53c3570/ui/ozone/platform/drm/gpu/gbm_surface.cc

Chrome did uprev, is this all fixed now?

Issue 830473 has been merged into this issue.

No, even with the Chrome uprev PSR is still broken on R67-10561.0.0:
https://stainless.corp.google.com/search?exclude_cts=false&exclude_non_release=false&board=%5Esamus%24&test=%5Egraphics%5C_Idle%24&view=matrix&col=build&row=model&first_date=2018-04-04&last_date=2018-04-10

Looks like the test is still failing, even with Chrome at 67.0.3390.0

https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICQutjF2QkM

Testing with samus locally, it boots to UI and login just fine. Chrome 67.0.3390.0, image 10563.0.0.

I checked on samus/tot@549617 and graphics_Idle failed with PSR (there is also an unrelated python crash which makes the test fail in addition).

I checked samus at 547318 (Kristian's reland) and PSR passes (python crash).

I guess I will bisect later, need to head out now.

I tried test_that graphics_Idle on 67.0.3390.0 (@548636) and it fails (but as mentioned above, UI does come up).

Looking at the PSR debug file on a static login screen (no blinking cursor or other animations):

localhost ~ # cat /sys/kernel/debug/dri/0/i915_edp_psr_status 
Sink_Support: yes
Source_OK: no
Enabled: no
Performance_Counter: 0

so PSR is really not enabling.

did you check the FB X-tiled? It's a requirement for PSR

I saw that in the code, but 3.14 doesn't have either the i915_display_info or state debugfs file, so I wasn't sure how to check.

i915_gem_gtt shows the tiling info

https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1008867

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/minigbm/+/9c3fb32dd4a8b9a3cf870c533d1e88dd542d7c16

commit 9c3fb32dd4a8b9a3cf870c533d1e88dd542d7c16
Author: Kristian H. Kristensen <hoegsberg@chromium.org>
Date: Thu Apr 12 22:22:34 2018

i915: Allow allocating ARGB buffers for scanout

CL:991261 changed our primary framebuffer format from XRGB to ARGB. We
still only scanout as XRGB where the display controller doesn't
support ARGB, but minigbm doesn't know that. As a result, when we try
to allocate an ARGB buffer with the SCANOUT useflag, we get a linear
buffer.  This breaks PSR and regresses performance and, in general,
just isn't what we want.

This CL enables SCANOUT for all ARGB formats where the corresponding
XRGB formats supports scanout. In the end, it's up to the caller to
make sure a format works for scanout anyway.

BUG= 827188 , 830969 
TEST=test_that graphics_Idle on samus

Change-Id: Iab428e5b21abedcac7cee86fccc8df50dab3f471
Reviewed-on: https://chromium-review.googlesource.com/1008867
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>

[modify] https://crrev.com/9c3fb32dd4a8b9a3cf870c533d1e88dd542d7c16/i915.c

Test back to passing, marking verified.