Bug 87662

*** This bug has been marked as a duplicate of bug 86548 ***

48404c1e53d4e15d7e3e77cd2c8f3f22973ef38e is the first bad commit
commit 48404c1e53d4e15d7e3e77cd2c8f3f22973ef38e
Author: Sonika Jindal <sonika.jindal@intel.com>
Date:   Fri Aug 22 14:06:04 2014 +0530

    drm/i915: Add 180 degree primary plane rotation support

    Primary planes support 180 degree rotation. Expose the feature
    through rotation drm property.

    v2: Calculating linear/tiled offsets based on pipe source width and
    height. Added 180 degree rotation support in ironlake_update_plane.

    v3: Checking if CRTC is active before issueing update_plane. Added
    wait for vblank to make sure we dont overtake page flips. Disabling
    FBC since it does not work with rotated planes.

    v4: Updated rotation checks for pending flips, fbc disable. Creating
    rotation property only for Gen4 onwards. Property resetting as part
    of lastclose.

    v5: Resetting property in i915_driver_lastclose properly for planes
    and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
    width in i9xx_update_plane and ironlake_update_plane. Removed tab
    based indentation and unnecessary braces in intel_crtc_set_property
    and intel_update_fbc. FBC and flip related checks should be done only
    for valid crtcs.

    v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
    and positioning the disable code in intel_update_fbc.

    v7: In case rotation property on inactive crtc is updated, we return
    successfully printing debug log as crtc is inactive and only property change
    is preserved.

    v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
    crtc->primary->fb  and return value of update_primary_plane is ignored.

    v9: added rotation property to primary plane instead of crtc. Removing reset
    of rotation property from lastclose. rotation_property is moved to
    drm_mode_config, so drm layer will take care of resetting. Adding updation of
    fbc when rotation is set to 0. Allowing rotation only if value is
    different than old one.

    v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
    set_property(Daniel).

    v11: Using same set_property function for both primary and sprite, Adding
    primary plane specific code in the same function (Matt).

    v12: Removing disabling/ enabling of fbc from set_property because it is done
    from intel_pipe_set_base. Other formatting

    v13: we need to call disable_fbc before changing the rotation to 180,
    disable_fbc from intel_pipe_set_base gets called very late, that will
    be used to re-enable fbc if rotation is set to 0 (Ville).

    Testcase: igt/kms_rotation_crc

    Signed-off-by: Uma Shankar <uma.shankar@intel.com>
    Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
    Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
    [danvet: Add FIXME to explain why we need the open-coded update_fbc
    hunk to disable fbc when rotated 180 degree. And make checkpatch
    happier.]
    Acked-by: Matt Roper <matthew.d.roper@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Created attachment 111913 [details] [review]
Possible fix for 3.18

In -nightly this issue is fixed by

commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Mon Dec 1 15:40:11 2014 -0800

    drm/i915: remove intel_pipe_set_base() (v4)

That seems a bit to big to backport, so I wrote the attached patch that should have the same effect of keeping the src and dst rects up to date when a legacy path changes the fb of a crtc.

This bug can be hit without changing the fb. If you write a test case to rotate the fbcon, for example.

(In reply to Ander Conselvan de Oliveira from comment #3)
> In -nightly this issue is fixed by
> 
> commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Date:   Mon Dec 1 15:40:11 2014 -0800
> 
>     drm/i915: remove intel_pipe_set_base() (v4)

Please retest with current nightly.

Sonika, can you take a look at this one?

(In reply to Jani Nikula from comment #5)
> (In reply to Ander Conselvan de Oliveira from comment #3)
> > In -nightly this issue is fixed by
> > 
> > commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > Date:   Mon Dec 1 15:40:11 2014 -0800
> > 
> >     drm/i915: remove intel_pipe_set_base() (v4)
> 
> Please retest with current nightly.

This bug is blocked by bug 89350, which blocked bi-weekly testing for BSW.
I tended to retest this so long as Mika's patch is applied.

Heng, please watch bug 89350,  then re-test this ASAP.

(In reply to Yi Sun from comment #7)
> (In reply to Jani Nikula from comment #5)
> > (In reply to Ander Conselvan de Oliveira from comment #3)
> > > In -nightly this issue is fixed by
> > > 
> > > commit 455a68086d1dfb801ad7c867d5ca0ed0e0f758b0
> > > Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > Date:   Mon Dec 1 15:40:11 2014 -0800
> > > 
> > >     drm/i915: remove intel_pipe_set_base() (v4)
> > 
> > Please retest with current nightly.
> 
> This bug is blocked by bug 89350, which blocked bi-weekly testing for BSW.
> I tended to retest this so long as Mika's patch is applied.
> 
> Heng, please watch bug 89350,  then re-test this ASAP.

This issue still exist if you run xinit and do inverted rotation immediately.

I tried with SKL with latest -nightly, and I don't see this issue.
I don't have an SNB system. But I'l try on VLV once and will get back.

Even on VLV, I am unable to reproduce this issue with ubuntu.
I tried: 
xrandr -o inverted
xrandr -o normal

Although I see that in both the cases the rotation is set to 0 and there is no setproperty ioctl getting called. But the screen rotates when inverted and back to normal when normal is set.
Attached are the logs from VLV with latest -nightly and ubuntu.
Looks like xserver is doing the rotation by itself in this case.

Created attachment 114433 [details]
xrandr on vlv

(In reply to Sonika from comment #11)
> Created attachment 114433 [details]
> xrandr on vlv

Have you double-checked this is indeed nightly? Because of the noise it's not possible to see that.

btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.

If you really, really want to know what's going on in the ddx side, compile xf86-video-intel with --enable-debug=full

(In reply to Daniel Vetter from comment #12)
> (In reply to Sonika from comment #11)
> > Created attachment 114433 [details]
> > xrandr on vlv
> 
> Have you double-checked this is indeed nightly? Because of the noise it's
> not possible to see that.
> 
> btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.

Yes, -nightly is what I built. But is it possible to find the branch from the logs somewhere?

I had retest this case on the same machine with the same monitor on latest nightly branch. The issue could not be reproduced. I also change the kernel to the older version (nightly branch 2015-03-05 and 2014-12-24) and with older X11(unstalbe 2015-03-05), seem this bug is not able to be reproduced, it is weird. Any suggestion for reproduce this issue?

If no one can reproduce this bug I tend to close it.
Any other finding, we'll file new one.

I reproduce this issue on a BDW. Reopen this bug.
A DP or HDMI minitor will also met this issue.

kernel: stable v3.19.2
X11R7: /X11R7_64_2015Q1
cat /proc/cmdline
BOOT_IMAGE=kernels//stable/v3.19.2/bzImage_x86_64 root=/dev/sda2 hostname=x-bdw09 modules_path=kernels//stable/v3.19.2/modules_x86_64/lib/modules/3.19.2_v3.19.2+ acpi_rsdp=0xac7e1014
The reproduce step is to run "xrandr --output eDP1 --rotation left --output DP1 --rotation inverted" immediately after xinit is run.

with nightly branch latest kernel 
60c5b7f582e8ced10dcd557db4ea66665e6a4dff(2015-03-26)

the issue is a little different.

Only command "xrandr -o inverted" will cause DP monitor fail to show anything.
xrandr --output eDP1 --rotation left --output DP1 --rotation inverted works well

Created attachment 114657 [details]
Xorg.0.log

Created attachment 114658 [details]
dmesg on stable v3.19.2

Created attachment 114659 [details]
dmesg on nightly20150326

This issue was found in at least BSW/BDW/BYT/HSW. The bisect point is right. I had tried on commit before the bisect commit, the issue will not appear.

(In reply to Sonika from comment #14)
> (In reply to Daniel Vetter from comment #12)
> > (In reply to Sonika from comment #11)
> > > Created attachment 114433 [details]
> > > xrandr on vlv
> > 
> > Have you double-checked this is indeed nightly? Because of the noise it's
> > not possible to see that.
> > 
> > btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.
> 
> Yes, -nightly is what I built. But is it possible to find the branch from
> the logs somewhere?

Kernel version is printed at the top of dmesg as the very first line, or can be printed with 

$ uname -r

If you enable CONFIG_LOCALVERSION_AUTO then this will even show your exact git version.

(In reply to Daniel Vetter from comment #22)
> (In reply to Sonika from comment #14)
> > (In reply to Daniel Vetter from comment #12)
> > > (In reply to Sonika from comment #11)
> > > > Created attachment 114433 [details]
> > > > xrandr on vlv
> > > 
> > > Have you double-checked this is indeed nightly? Because of the noise it's
> > > not possible to see that.
> > > 
> > > btw generally I only boot with drm.debug=0xe to avoid all the ioctll noise.
> > 
> > Yes, -nightly is what I built. But is it possible to find the branch from
> > the logs somewhere?
> 
> Kernel version is printed at the top of dmesg as the very first line, or can
> be printed with 
> 
> $ uname -r
> 
> If you enable CONFIG_LOCALVERSION_AUTO then this will even show your exact
> git version.

CONFIG_LOCALVERSION_AUTO sounds good. QA always specify version in makefile when building a kernel by the script. I'd like have a try. :p

Downgrade the priority to high based on 2015-03-27 test result:

with nightly branch latest kernel 
60c5b7f582e8ced10dcd557db4ea66665e6a4dff(2015-03-26)

the issue symptom is:

Only command "xrandr -o inverted" will cause DP monitor fail to show anything.
xrandr --output eDP1 --rotation left --output DP1 --rotation inverted works well

QA will report another bug against drm-intel-nightly bug behavior, to distinguish with this stable branch issue.

One year later: is this bug still present?

(In reply to Paulo Zanoni from comment #25)
> One year later: is this bug still present?

Timeout, presumed fixed. Please reopen if the problem persists with latest kernels.