[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Deprecate I915_SET_COLORKEY_NONE

[Patchwork]

== Series Details ==

Series: drm/i915: Deprecate I915_SET_COLORKEY_NONE
URL   : https://patchwork.freedesktop.org/series/37584/
State : warning

== Summary ==

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
fail   -> PASS   (shard-hsw) fdo#102670 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_draw_crc:
Subgroup fill-fb:
pass   -> SKIP   (shard-snb)
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-snb) fdo#104058

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-apltotal:2836 pass:1751 dwarn:1   dfail:0   fail:20  skip:1064 
time:12360s
shard-hswtotal:2836 pass:1732 dwarn:1   dfail:0   fail:12  skip:1090 
time:11597s
shard-snbtotal:2836 pass:1327 dwarn:1   dfail:0   fail:10  skip:1498 
time:6377s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7871/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: nuke pch type :o

[Patchwork]

== Series Details ==

Series: drm/i915: nuke pch type :o
URL   : https://patchwork.freedesktop.org/series/37581/
State : success

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7869/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/vblank: Data type fixes for 64-bit 
vblank sequences.
URL   : https://patchwork.freedesktop.org/series/37598/
State : success

== Summary ==

Series 37598v1 series starting with [01/10] drm/vblank: Data type fixes for 
64-bit vblank sequences.
https://patchwork.freedesktop.org/api/1.0/series/37598/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:417s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:275s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:576s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:480s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
9df046e9e2ed drm/i915: Estimate and update missed vblanks.
5aa5a89ed404 drm/vblank: Restoring vblank counts after device PM events.
6d4184e530db drm/vblank: Do not update vblank count if interrupts are already 
disabled.
b038ce8dd537 drm/atomic: Handle 64-bit return from drm_crtc_vblank_count()
5a06910d4f70 drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()
7235dbb2bfa1 drm/radeon: Handle 64-bit return from drm_crtc_vblank_count()
f9941350553f drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()
aca673b55435 drm/i915: Handle 64-bit return from drm_crtc_vblank_count()
bf166c93 drm/i915/vblank: Make the vblank counter u64 -> u32 typecast 
explicit
92c3f30a31da drm/vblank: Data type fixes for 64-bit vblank sequences.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7875/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Flush old resets between engines

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Flush old resets between engines
URL   : https://patchwork.freedesktop.org/series/37591/
State : success

== Summary ==

Series 37591v1 drm/i915/selftests: Flush old resets between engines
https://patchwork.freedesktop.org/api/1.0/series/37591/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:523s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
4ba412a42cb1 drm/i915/selftests: Flush old resets between engines

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7874/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Adhering to HDCP1.4 Compliance Test Spec (rev3)

[Patchwork]

== Series Details ==

Series: Adhering to HDCP1.4 Compliance Test Spec (rev3)
URL   : https://patchwork.freedesktop.org/series/37539/
State : success

== Summary ==

Series 37539v3 Adhering to HDCP1.4 Compliance Test Spec
https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/3/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:477s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:577s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:524s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s
fi-elk-e7500 failed to collect. IGT log at Patchwork_7873/fi-elk-e7500/igt.log

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
0ed58f166dc0 drm/i915: fix misalignment in HDCP register def
939cb861b65c drm/i915: Reauthenticate HDCP on failure
7676c63c0468 drm/i915: Detect panel's hdcp capability
1e24cd5335c4 drm/i915: Optimize HDCP key load
ad2ca3a62efa drm/i915: Retry HDCP bksv read
9e27a2ec3c29 drm/i915: Connector info in HDCP debug msgs
887fd7b77ba6 drm/i915: Stop encryption for repeater with no sink
cba5ad4517c2 drm/i915: Handle failure from 2nd stage HDCP auth

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7873/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Pandiyan, Dhinakaran]

On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> > On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> > wrote:
> >> Quoting Andy Lutomirski (2018-02-01 21:04:30)
> >>> I got this after a recent suspend/resume:
> >>>
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
> >>> dirs
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >>> scanning /sys/bus
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >>> scanning /sys/class
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
> >>> configuration file '/etc/systemd/sleep.conf': No such file or
> >>> directory
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >>> sender=n/a destination=n/a object=/org/freedesktop/login1
> >>> interface=org.freedesktop.login1.Manager member=PrepareForSleep
> >>> cookie=570 reply
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
> >>> type=method_call sender=:1.46 destination=:1.1
> >>> object=/org/freedesktop/login1/session/_32
> >>> interface=org.freedesktop.login1.Session member=ReleaseDevice
> >>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >>> sender=n/a destination=:1.46
> >>> object=/org/freedesktop/login1/session/_32
> >>> interface=org.freedesktop.login1.Session member=PauseDevice cookie
> >>> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
> >>> transform 0: Permission denied
> >>> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
> >>> with (Permission denied), drawing cursor with OpenGL from now on
> >>>
> >>> But I don't see the word "cursor" in my system logs before the first
> >>> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
> >>> Wayland session, but it hasn't been reinstalled in some time, so it's
> >>> possible that there are some weird settings sitting around.  But I did
> >>> check and I have no weird i915 parameters.
> >>
> >> You are using gnome-shell as the display server. From that it appears to
> >> have started off with a HW cursor and switched to a SW cursor after
> >> suspend. Did you notice a change in behaviour? After rebooting or just
> >> restarting gnome-shell?
> >
> > I think it's less consistently bad after a reboot before suspending.
> >
> >>
> >>> Also, are these things potentially related:
> >>>
> >>> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
> >>> atomic update failure on pipe A
> >>
> >> They are just "missed the immediate vblank for the screen update"
> >> messages. Should not be related to PSR, but may cause jitter by delaying
> >> the odd screen update.
> >
> > I just got this one, and the timestamp is at least reasonably close to
> > a giant latency spike:
> >
> > [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> > update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
> > 1079, scanline start 1087, end 1088
> >
> >>
> >>> As I'm typing this, I've seen a couple instances of what seems like a
> >>> full *second* of cursor latency, but I've only gotten the potential
> >>> atomic update failure once.
> >>>
> >>> And is there any straightforward tracing to do to distinguish between
> >>> PSR exit latency and other potential sources of latency?
> >>
> >> It looks plausible that we could at least report how long it takes the
> >> registers to reflect the change in state (but we don't). The best source
> >> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
> >
> > Hmm.
> >
> > I went and looked at the code, and I noticed what could be bugs or
> > could (more likely) be my confusion since I don't know this code at
> > all:
> >
> > intel_single_frame_update() does something inscrutable to me, but I
> > imagine it does something that causes the next page flip to get
> > noticed by the panel even with PSR on.  But how does the code that
> > calls it know that anything happened?  (Looking at the commit history,
> > maybe this is something special that's only needed on some platforms
> > but doesn't replace the normal PSR exit sequence.)
> >
> > Perhaps more interestingly, intel_psr_flush() does this:
> >
> > /* By definition flush = invalidate + flush */
> > if (frontbuffer_bits)
> > intel_psr_exit(dev_priv);
> >
> > if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> > if (!work_busy(_priv->psr.work.work))
> > schedule_delayed_work(_priv->psr.work,
> >   msecs_to_jiffies(100));
> >
> > I'm guessing that the idea is that we're turning off PSR because we
> > want the panel to update and we expect that, in 100ms, the update will
> > have hit the panel and we'll have been idle long enough for it to 

[Intel-gfx] [PATCH 10/10] drm/i915: Estimate and update missed vblanks.

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

The frame counter may have got reset between disabling and enabling vblank
interrupts due to DMC putting the hardware to DC5/6 states if PSR was
active. The frame counter could also have stalled if PSR was active in case
there was no DMC. The frame counter resetting has a user visible impact
of screen freezes.

Make use of drm_vblank_restore() to compute missed vblanks for the duration
in which vblank interrupts were disabled and update the vblank counter with
this value as diff. There's no need to check if PSR was actually active in
the interrupt disabled duration, so simplify the check to a feature check.

Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it
from going back again as long as the there are pending interrupts. So, we
don't have to explicity disallow DC5/6 after enabling vblank interrupts to
keep the counter running.

This change is not applicable to CHV, as enabling interrupts does not
prevent the hardware from activating PSR.

v2: Added comments(Rodrigo) and rewrote commit message.

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 252feff2892d..e86c645b6b07 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2968,6 +2968,12 @@ static int ironlake_enable_vblank(struct drm_device 
*dev, unsigned int pipe)
ilk_enable_display_irq(dev_priv, bit);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 
+   /* Even though there is no DMC, frame counter can get stuck when
+* PSR is active as no frames are generated.
+*/
+   if (HAS_PSR(dev_priv))
+   drm_vblank_restore(dev, pipe);
+
return 0;
 }
 
@@ -2980,6 +2986,12 @@ static int gen8_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 
+   /* Even if there is no DMC, frame counter can get stuck when
+* PSR is active as no frames are generated, so check only for PSR.
+*/
+   if (HAS_PSR(dev_priv))
+   drm_vblank_restore(dev, pipe);
+
return 0;
 }
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/10] drm/atomic: Handle 64-bit return from drm_crtc_vblank_count()

[Dhinakaran Pandiyan]

570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64.

The flip ioctl receives a 32-bit target sequence from user space and is
compared against the current sequence from drm_crtc_vblank_count(). So,
typecast return from drm_crtc_vblank_count() explicitly to add clarity.

__drm_crtcs_state.last_vblank_count however only ever stores the value from
drm_crtc_vblank_count() and can be upgraded to u64.

Cc: Keith Packard 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_plane.c | 2 +-
 include/drm/drm_atomic.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 22b54663b6e7..09de6ecb3968 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -948,7 +948,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (r)
return r;
 
-   current_vblank = drm_crtc_vblank_count(crtc);
+   current_vblank = (u32)drm_crtc_vblank_count(crtc);
 
switch (page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET) {
case DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE:
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index cf13842a6dbd..2c711a24c80c 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -154,7 +154,7 @@ struct __drm_crtcs_state {
struct drm_crtc *ptr;
struct drm_crtc_state *state, *old_state, *new_state;
s32 __user *out_fence_ptr;
-   unsigned last_vblank_count;
+   u64 last_vblank_count;
 };
 
 struct __drm_connnectors_state {
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/10] drm/vblank: Do not update vblank count if interrupts are already disabled.

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

Updating vblank counts requires register reads and these reads may not
return meaningful values if the device was in a low power state after
vblank interrupts were last disabled. So, update the count only if vblank
interrupts are enabled. Secondly, this means the registers should be read
before disabling vblank interrupts.

v2: Don't check vblank->enabled outside it's lock (Chris)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f0d3ed5f2528..913954765d9e 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -347,23 +347,25 @@ void drm_vblank_disable_and_save(struct drm_device *dev, 
unsigned int pipe)
spin_lock_irqsave(>vblank_time_lock, irqflags);
 
/*
-* Only disable vblank interrupts if they're enabled. This avoids
-* calling the ->disable_vblank() operation in atomic context with the
-* hardware potentially runtime suspended.
+* Update vblank count and disable vblank interrupts only if the
+* interrupts were enabled. This avoids calling the ->disable_vblank()
+* operation in atomic context with the hardware potentially runtime
+* suspended.
 */
-   if (vblank->enabled) {
-   __disable_vblank(dev, pipe);
-   vblank->enabled = false;
-   }
+   if (!vblank->enabled)
+   goto out;
 
/*
-* Always update the count and timestamp to maintain the
+* Update the count and timestamp to maintain the
 * appearance that the counter has been ticking all along until
 * this time. This makes the count account for the entire time
 * between drm_crtc_vblank_on() and drm_crtc_vblank_off().
 */
drm_update_vblank_count(dev, pipe, false);
+   __disable_vblank(dev, pipe);
+   vblank->enabled = false;
 
+out:
spin_unlock_irqrestore(>vblank_time_lock, irqflags);
 }
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/10] drm/vblank: Restoring vblank counts after device PM events.

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

The HW frame counter can get reset if device enters a low power state after
vblank interrupts were disabled. This messes up any following vblank count
update as a negative diff (huge unsigned diff) is calculated from the HW
frame counter change. We cannot ignore negative diffs altogther as there
could be legitimate wrap arounds. So, allow drivers to update vblank->count
with missed vblanks for the time interrupts were disabled. This is similar
to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
end as this function is expected to be called from the driver
_enable_vblank() vfunc.

v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
Add docs and sprinkle some asserts.

Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Michel Dänzer 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 59 
 include/drm/drm_vblank.h |  2 ++
 2 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 913954765d9e..c781cb426bf1 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1237,6 +1237,65 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_vblank_on);
 
+/**
+ * drm_vblank_restore - estimated vblanks using timestamps and update it.
+ *
+ * Power manamement features can cause frame counter resets between vblank
+ * disable and enable. Drivers can then use this function in their
+ * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
+ * the last _crtc_funcs.disable_vblank.
+ *
+ * This function is the legacy version of drm_crtc_vblank_restore().
+ */
+void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
+{
+   ktime_t t_vblank;
+   struct drm_vblank_crtc *vblank;
+   int framedur_ns;
+   u64 diff_ns;
+   u32 cur_vblank, diff = 1;
+   int count = DRM_TIMESTAMP_MAXRETRIES;
+
+   if (WARN_ON(pipe >= dev->num_crtcs))
+   return;
+
+   assert_spin_locked(>vbl_lock);
+   assert_spin_locked(>vblank_time_lock);
+
+   vblank = >vblank[pipe];
+   WARN_ONCE((drm_debug & DRM_UT_VBL) && !vblank->framedur_ns,
+ "Cannot compute missed vblanks without frame duration\n");
+   framedur_ns = vblank->framedur_ns;
+
+   do {
+   cur_vblank = __get_vblank_counter(dev, pipe);
+   drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
+   } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
+
+   diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
+   if (framedur_ns)
+   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
+
+
+   DRM_DEBUG_VBL("missed %d vblanks in %lld ns, frame duration=%d ns, 
hw_diff=%d\n",
+ diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
+   store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
+}
+EXPORT_SYMBOL(drm_vblank_restore);
+
+/**
+ * drm_crtc_vblank_restore - estimate vblanks using timestamps and update it.
+ * Power manamement features can cause frame counter resets between vblank
+ * disable and enable. Drivers can then use this function in their
+ * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
+ * the last _crtc_funcs.disable_vblank.
+ */
+void drm_crtc_vblank_restore(struct drm_crtc *crtc)
+{
+   drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_restore);
+
 static void drm_legacy_vblank_pre_modeset(struct drm_device *dev,
  unsigned int pipe)
 {
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index a4c3b0a0a197..16d46e2a6854 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -180,6 +180,8 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
 u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
+void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
+void drm_crtc_vblank_restore(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Dhinakaran Pandiyan]

570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes a potential problem or serves to add clarity in case
the typecasting was implicitly done.

Cc: Keith Packard 
Cc: Alex Deucher 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 38d47559f098..c2fa5d55f04e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
amdgpu_bo_unreserve(new_abo);
 
work->base = base;
-   work->target_vblank = target - drm_crtc_vblank_count(crtc) +
+   work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
 
/* we borrow the event spin lock for protecting flip_wrok */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1ce4c98385e3..b7254a29b34a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
 
 
/* Prepare wait for target vblank early - before the fence-waits */
-   target_vblank = target - drm_crtc_vblank_count(crtc) +
+   target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
amdgpu_get_vblank_counter_kms(crtc->dev, 
acrtc->crtc_id);
 
/* TODO This might fail and hence better not used, wait
@@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
amdgpu_dm_do_flip(
crtc,
fb,
-   drm_crtc_vblank_count(crtc) + *wait_for_vblank,
+   (uint32_t)drm_crtc_vblank_count(crtc) + 
*wait_for_vblank,
dm_state->context);
}
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Dhinakaran Pandiyan]

570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this
down to u32 either fixes a potential problem or serves to add clarity in
case the implicit typecasting was already correct.

Cc: Keith Packard 
Cc: Thierry Reding 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/tegra/dc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b8403ed48285..49df2db2ad46 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1359,7 +1359,7 @@ static u32 tegra_dc_get_vblank_counter(struct drm_crtc 
*crtc)
return host1x_syncpt_read(dc->syncpt);
 
/* fallback to software emulated VBLANK counter */
-   return drm_crtc_vblank_count(>base);
+   return (u32)drm_crtc_vblank_count(>base);
 }
 
 static int tegra_dc_enable_vblank(struct drm_crtc *crtc)
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/10] drm/i915/vblank: Make the vblank counter u64 -> u32 typecast explicit

[Dhinakaran Pandiyan]

Core returns a u64 vblank count and intel_crtc_get_vblank_counter()
expects a 32-bit value. Make the typecast explicit to add clarity.

Cc: Keith Packard 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ad8d9c6c40e4..f6b450de653c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12075,7 +12075,7 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc 
*crtc)
struct drm_device *dev = crtc->base.dev;
 
if (!dev->max_vblank_count)
-   return drm_crtc_accurate_vblank_count(>base);
+   return (u32)drm_crtc_accurate_vblank_count(>base);
 
return dev->driver->get_vblank_counter(dev, crtc->pipe);
 }
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
space requested vblank sequence using this clipped 32-bit count(when the
value is >= 2^32) as reference, the requested sequence remains a 32-bit
value and gets queued like that. However, the code that checks if the
requested sequence has passed compares this against the 64-bit vblank
count.

With drm_vblank_count() returning all bits of the vblank count, update
drm_crtc_accurate_vblank_count() so that drm_crtc_arm_vblank_event() queues
the correct sequence. Otherwise, this leads to prolonged waits for a vblank
sequence when the current count is >=2^32.

Finally, fix drm_wait_one_vblank() too.

v2: Commit message fix (Keith)
Squash commits (Rodrigo)

Fixes: 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]")
Cc: Keith Packard 
Cc: Michel Dänzer 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 8 
 include/drm/drm_vblank.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 32d9bcf5be7f..f0d3ed5f2528 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
 }
 
-static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
+static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
@@ -292,11 +292,11 @@ static u32 drm_vblank_count(struct drm_device *dev, 
unsigned int pipe)
  * This is mostly useful for hardware that can obtain the scanout position, but
  * doesn't have a hardware frame counter.
  */
-u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
+u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
-   u32 vblank;
+   u64 vblank;
unsigned long flags;
 
WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
@@ -1055,7 +1055,7 @@ void drm_wait_one_vblank(struct drm_device *dev, unsigned 
int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
int ret;
-   u32 last;
+   u64 last;
 
if (WARN_ON(pipe >= dev->num_crtcs))
return;
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 848b463a0af5..a4c3b0a0a197 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -179,7 +179,7 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
 void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
-u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
+u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
   unsigned int pipe, int *max_error,
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/10] drm/radeon: Handle 64-bit return from drm_crtc_vblank_count()

[Dhinakaran Pandiyan]

570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64. This could cause
potential problems if the return value is used in arithmetic operations
with a 32-bit reference HW vblank count. Explicitly typecasting this down
to u32 either fixes a potential problem or serves to add clarity in case
the implicit typecasting was already correct.

Cc: Keith Packard 
Cc: Alex Deucher 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/radeon/radeon_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index dfda5e0ed166..26129b2b082d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -570,7 +570,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc 
*crtc,
base &= ~7;
}
work->base = base;
-   work->target_vblank = target - drm_crtc_vblank_count(crtc) +
+   work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
dev->driver->get_vblank_counter(dev, work->crtc_id);
 
/* We borrow the event spin lock for protecting flip_work */
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/10] drm/i915: Handle 64-bit return from drm_crtc_vblank_count()

[Dhinakaran Pandiyan]

570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
return type for drm_crtc_vblank_count() to u64, store all the bits
without truncating. There is no need to type cast this value down to
32-bits.

Cc: Keith Packard 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..4b9da04c1d4a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1599,7 +1599,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
seq_printf(m, "FBC disabled: %s\n", fbc->no_fbc_reason);
 
if (fbc->work.scheduled)
-   seq_printf(m, "FBC worker scheduled on vblank %u, now %llu\n",
+   seq_printf(m, "FBC worker scheduled on vblank %llu, now %llu\n",
   fbc->work.scheduled_vblank,
   drm_crtc_vblank_count(>crtc->base));
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c676269ed843..d22677494499 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -717,7 +717,7 @@ struct intel_fbc {
 
struct intel_fbc_work {
bool scheduled;
-   u32 scheduled_vblank;
+   u64 scheduled_vblank;
struct work_struct work;
} work;
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: Flush old resets between engines

[Chris Wilson]

When injecting rapid resets, we must be careful to at least wait for the
previous reset to have taken effect and the engine restarted. If we
perform a second reset before that has happened, we will notice that the
engine hasn't recovered and declare it lost, wedging the device and
failing. In practice, since we wait for each hanging batch to start
before injecting the reset, this too-fast-reset condition can only be
triggered when moving onto the next engine in the test, so we need only
wait for the existing reset to complete before switching engines.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index d1f91a533afa..1e57fda6e1be 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -487,6 +487,7 @@ static int __igt_reset_engine(struct drm_i915_private 
*i915, bool active)
if (err)
break;
 
+   i915_gem_wait_for_idle(i915, 0);
cond_resched();
}
 
@@ -726,6 +727,7 @@ static int __igt_reset_engine_others(struct 
drm_i915_private *i915,
if (err)
break;
 
+   i915_gem_wait_for_idle(i915, 0);
cond_resched();
}
 
@@ -952,6 +954,9 @@ static int igt_reset_queue(void *arg)
i915_gem_chipset_flush(i915);
 
i915_gem_request_put(prev);
+
+   i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED);
+   cond_resched();
}
 
 fini:
-- 
2.15.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: CustomEDID fix

[Chris Wilson]

Quoting Jani Nikula (2018-02-02 19:13:53)
> On Fri, 02 Feb 2018, dom.const...@free.fr wrote:
> > For my HTPC setup, I'm using the option "CustomEDID".
> > With this option, output attaching and destroying events leads to crashes.
> >
> > The following sequence leads to a crash:
> > - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
> 
> I know nothing about xorg customedid stuff.
> 
> But there's drm.edid_firmware=HDMI-2:/etc/my_edid.bin (or
> drm_kms_helper.edid_firmware on older kernels) module parameter for the
> kernel that does this transparently across the stack.

There's also the difference in that Xorg only uses the custom EDID to
conveniently load a set of modelines, but the kernel EDID override
describes the sink completely (e.g. audio modes, link protocols, pixel
formats etc).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with disable-gem-trace (rev3)

[Patchwork]

== Series Details ==

Series: series starting with disable-gem-trace (rev3)
URL   : https://patchwork.freedesktop.org/series/37473/
State : success

== Summary ==

Series 37473v3 series starting with disable-gem-trace
https://patchwork.freedesktop.org/api/1.0/series/37473/revisions/3/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:296s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:531s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:408s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:471s
fi-bwr-2160 failed to collect. IGT log at Patchwork_7872/fi-bwr-2160/igt.log

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
25d414c74bd7 drm/i915: Skip post-reset request emission if the engine is not 
idle
03b14d2c280c drm/i915/execlists: Move the reset bits to a more natural home
81fdace9c2e7 drm/i915/selftests: Use a sacrificial context for hang testing
2241e68ceb73 drm/i915: Remove unbannable context spam from reset
fb158dd8dd7f drm/i915/execlists: Remove the startup spam
d93e5bc10876 disable-gem-trace

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7872/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 3/3] drm/i915: obliterate PCH types in favour of direct PCH id use

[Chris Wilson]

Quoting Jani Nikula (2018-02-02 20:01:00)
> The PCH type is an unnecessary level of abstraction that's an extra
> maintenance burden. Switch to using PCH ids directly. This also
> simplifies the virtual PCH detection.

But you are still using the PCH type, just computing it from the id
inside the conditionals. Not sure if that's a good idea, remember the
long chains of devid == X || devid == Y || ... we used to have?

I guess a convincing argument that the abstraction is ill-conceived
would be when it bloats the code, as that shows the abstraction's
semantics do not match and are a hindrance to use. Maybe there's another
transformation that improves usage?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 7/8] drm/i915: Reauthenticate HDCP on failure

[Ramalingam C]

Incase of HDCP authentication failure, HDCP spec expects
reauthentication. Hence this patch adds the reauthentications
to be compliance with spec.

v2:
  do-while to for loop for simplicity. [Seanpaul]

v3:
  positioning the logs effectively. [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 7ae8d83760ed..8f0cf476962f 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -578,7 +578,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 static int _intel_hdcp_enable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
-   int i, ret;
+   int i, ret, tries = 3;
 
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
@@ -599,17 +599,21 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
return ret;
}
 
-   ret = intel_hdcp_auth(conn_to_dig_port(connector),
- connector->hdcp_shim);
-   if (ret) {
-   DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
+   /* Incase of authentication failures, HDCP spec expects reauth. */
+   for (i = 0; i < tries; i++) {
+   ret = intel_hdcp_auth(conn_to_dig_port(connector),
+ connector->hdcp_shim);
+   if (!ret)
+   return 0;
+
+   DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
 
/* Ensuring HDCP encryption and signalling are stopped. */
_intel_hdcp_disable(connector);
-   return ret;
}
 
-   return 0;
+   DRM_ERROR("HDCP authentication failed (%d tries/%d)\n", tries, ret);
+   return ret;
 }
 
 static void intel_hdcp_check_work(struct work_struct *work)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 6/8] drm/i915: Detect panel's hdcp capability

[Ramalingam C]

DP HDCP1.4 spec mandates that An can be written to panel only after
detecting the panel's hdcp capability.

For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
For HDMI valid BKSV indicates the panel's hdcp capability.

For HDMI it is optional to detect the panel's hdcp capability before
An Write.

v2:
  Added comments explaining the need for action [Seanpaul].
  Made panel's hdcp capability detection optional for hdmi [Seanpaul].
  Defined a func for reading bcaps for DP [Seanpaul].

v3:
  Removed the NULL initialization [Seanpaul].

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_dp.c   | 39 +++
 drivers/gpu/drm/i915/intel_drv.h  |  4 
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
 3 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03d86ff9b805..5fa6bb7dbb7a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5107,17 +5107,32 @@ static int intel_dp_hdcp_read_bstatus(struct 
intel_digital_port *intel_dig_port,
 }
 
 static
-int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
-  bool *repeater_present)
+int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
+u8 *bcaps)
 {
ssize_t ret;
-   u8 bcaps;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BCAPS,
-  , 1);
+  bcaps, 1);
if (ret != 1) {
DRM_ERROR("Read bcaps from DP/AUX failed (%zd)\n", ret);
return ret >= 0 ? -EIO : ret;
}
+
+   return 0;
+}
+
+static
+int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
+  bool *repeater_present)
+{
+   ssize_t ret;
+   u8 bcaps;
+
+   ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
+   if (ret)
+   return ret;
+
*repeater_present = bcaps & DP_BCAPS_REPEATER_PRESENT;
return 0;
 }
@@ -5218,6 +5233,21 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port 
*intel_dig_port)
return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
 }
 
+static
+int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
+ bool *hdcp_capable)
+{
+   ssize_t ret;
+   u8 bcaps;
+
+   ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
+   if (ret)
+   return ret;
+
+   *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
+   return 0;
+}
+
 static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -5229,6 +5259,7 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
.toggle_signalling = intel_dp_hdcp_toggle_signalling,
.check_link = intel_dp_hdcp_check_link,
+   .hdcp_capable = intel_dp_hdcp_capable,
 };
 
 static void intel_edp_panel_vdd_sanitize(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d6a808374dfb..468ec1e90e16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -369,6 +369,10 @@ struct intel_hdcp_shim {
 
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *intel_dig_port);
+
+   /* Detects panel's hdcp capability. This is optional for HDMI. */
+   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
+   bool *hdcp_capable);
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 65bdb95c0ad7..7ae8d83760ed 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -414,12 +414,28 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
u32 reg;
u8 shim[DRM_HDCP_RI_LEN];
} ri;
-   bool repeater_present;
+   bool repeater_present, hdcp_capable;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
port = intel_dig_port->base.port;
 
+   /*
+* Detects whether the display is HDCP capable. Although we check for
+* valid Bksv below, the HDCP over DP spec requires that we check
+* whether the display supports HDCP before we write An. For HDMI
+* displays, this is not necessary.
+*/
+   if (shim->hdcp_capable) {
+   ret = shim->hdcp_capable(intel_dig_port, _capable);
+   if (ret)
+   return ret;
+   if (!hdcp_capable) {
+   DRM_ERROR("Panel is not HDCP 

[Intel-gfx] [PATCH v3 8/8] drm/i915: fix misalignment in HDCP register def

[Ramalingam C]

This patch aligns all definitions of hdcp registers and their bits.

v2:
  No changes. Added reviewed-by tag.

v3:
 No change.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h | 58 -
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65ba10ad1fe5..e9c79b560823 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8483,34 +8483,34 @@ enum skl_power_gate {
 #define   CNL_AUX_ANAOVRD1_LDO_BYPASS  (1<<23)
 
 /* HDCP Key Registers */
-#define HDCP_KEY_CONF  _MMIO(0x66c00)
+#define HDCP_KEY_CONF  _MMIO(0x66c00)
 #define  HDCP_AKSV_SEND_TRIGGERBIT(31)
 #define  HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
 #define  HDCP_KEY_LOAD_TRIGGER BIT(8)
-#define HDCP_KEY_STATUS_MMIO(0x66c04)
-#define  HDCP_FUSE_IN_PROGRESS BIT(7)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  HDCP_FUSE_IN_PROGRESS BIT(7)
 #define  HDCP_FUSE_ERROR   BIT(6)
-#define  HDCP_FUSE_DONEBIT(5)
-#define  HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  HDCP_FUSE_DONEBIT(5)
+#define  HDCP_KEY_LOAD_STATUS  BIT(1)
 #define  HDCP_KEY_LOAD_DONEBIT(0)
-#define HDCP_AKSV_LO   _MMIO(0x66c10)
-#define HDCP_AKSV_HI   _MMIO(0x66c14)
+#define HDCP_AKSV_LO   _MMIO(0x66c10)
+#define HDCP_AKSV_HI   _MMIO(0x66c14)
 
 /* HDCP Repeater Registers */
-#define HDCP_REP_CTL   _MMIO(0x66d00)
-#define  HDCP_DDIB_REP_PRESENT BIT(30)
-#define  HDCP_DDIA_REP_PRESENT BIT(29)
-#define  HDCP_DDIC_REP_PRESENT BIT(28)
-#define  HDCP_DDID_REP_PRESENT BIT(27)
-#define  HDCP_DDIF_REP_PRESENT BIT(26)
-#define  HDCP_DDIE_REP_PRESENT BIT(25)
+#define HDCP_REP_CTL   _MMIO(0x66d00)
+#define  HDCP_DDIB_REP_PRESENT BIT(30)
+#define  HDCP_DDIA_REP_PRESENT BIT(29)
+#define  HDCP_DDIC_REP_PRESENT BIT(28)
+#define  HDCP_DDID_REP_PRESENT BIT(27)
+#define  HDCP_DDIF_REP_PRESENT BIT(26)
+#define  HDCP_DDIE_REP_PRESENT BIT(25)
 #define  HDCP_DDIB_SHA1_M0 (1 << 20)
 #define  HDCP_DDIA_SHA1_M0 (2 << 20)
 #define  HDCP_DDIC_SHA1_M0 (3 << 20)
 #define  HDCP_DDID_SHA1_M0 (4 << 20)
 #define  HDCP_DDIF_SHA1_M0 (5 << 20)
 #define  HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
-#define  HDCP_SHA1_BUSYBIT(16)
+#define  HDCP_SHA1_BUSYBIT(16)
 #define  HDCP_SHA1_READY   BIT(17)
 #define  HDCP_SHA1_COMPLETEBIT(18)
 #define  HDCP_SHA1_V_MATCH BIT(19)
@@ -8526,7 +8526,7 @@ enum skl_power_gate {
 #define HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
 #define HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
 #define HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
-#define HDCP_SHA_TEXT  _MMIO(0x66d18)
+#define HDCP_SHA_TEXT  _MMIO(0x66d18)
 
 /* HDCP Auth Registers */
 #define _PORTA_HDCP_AUTHENC0x66800
@@ -8542,25 +8542,25 @@ enum skl_power_gate {
  _PORTD_HDCP_AUTHENC, \
  _PORTE_HDCP_AUTHENC, \
  _PORTF_HDCP_AUTHENC) + x)
-#define PORT_HDCP_CONF(port)   _PORT_HDCP_AUTHENC(port, 0x0)
-#define  HDCP_CONF_CAPTURE_AN  BIT(0)
-#define  HDCP_CONF_AUTH_AND_ENC(BIT(1) | BIT(0))
-#define PORT_HDCP_ANINIT(port) _PORT_HDCP_AUTHENC(port, 0x4)
-#define PORT_HDCP_ANLO(port)   _PORT_HDCP_AUTHENC(port, 0x8)
-#define PORT_HDCP_ANHI(port)   _PORT_HDCP_AUTHENC(port, 0xC)
-#define PORT_HDCP_BKSVLO(port) _PORT_HDCP_AUTHENC(port, 0x10)
-#define PORT_HDCP_BKSVHI(port) _PORT_HDCP_AUTHENC(port, 0x14)
-#define PORT_HDCP_RPRIME(port) _PORT_HDCP_AUTHENC(port, 0x18)
-#define PORT_HDCP_STATUS(port) _PORT_HDCP_AUTHENC(port, 0x1C)
+#define PORT_HDCP_CONF(port)   _PORT_HDCP_AUTHENC(port, 0x0)
+#define  HDCP_CONF_CAPTURE_AN  BIT(0)
+#define  HDCP_CONF_AUTH_AND_ENC(BIT(1) | BIT(0))
+#define PORT_HDCP_ANINIT(port) _PORT_HDCP_AUTHENC(port, 0x4)
+#define PORT_HDCP_ANLO(port)   _PORT_HDCP_AUTHENC(port, 0x8)
+#define PORT_HDCP_ANHI(port)   _PORT_HDCP_AUTHENC(port, 0xC)
+#define PORT_HDCP_BKSVLO(port) _PORT_HDCP_AUTHENC(port, 0x10)
+#define PORT_HDCP_BKSVHI(port) _PORT_HDCP_AUTHENC(port, 0x14)
+#define PORT_HDCP_RPRIME(port) _PORT_HDCP_AUTHENC(port, 0x18)
+#define PORT_HDCP_STATUS(port) _PORT_HDCP_AUTHENC(port, 0x1C)
 #define  HDCP_STATUS_STREAM_A_ENC  BIT(31)
 #define  HDCP_STATUS_STREAM_B_ENC  BIT(30)
 #define  HDCP_STATUS_STREAM_C_ENC  BIT(29)
 #define  HDCP_STATUS_STREAM_D_ENC  BIT(28)
 #define  HDCP_STATUS_AUTH  

[Intel-gfx] [PATCH v3 4/8] drm/i915: Retry HDCP bksv read

[Ramalingam C]

HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.

This patch adds the above mentioned re-read for bksv.

v2:
  Rephrased the commit msg [Seanpaul]

v3:
  do-while to for-loop [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cfd13ee8c534..b1047dbf3393 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
-   int ret, i;
+   int ret, i, tries = 2;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -438,11 +438,22 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
r0_prime_gen_start = jiffies;
 
memset(, 0, sizeof(bksv));
-   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+
+   /* When bksv is invalid, HDCP spec expects a re-read for bksv */
+   for (i = 0; i < tries; i++) {
+   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+   if (!ret) {
+   if (intel_hdcp_is_ksv_valid(bksv.shim)) {
+   break;
+   } else {
+   DRM_ERROR("Invalid BKSV\n");
+   ret = -ENODEV;
+   }
+   }
+   }
+
if (ret)
return ret;
-   else if (!intel_hdcp_is_ksv_valid(bksv.shim))
-   return -ENODEV;
 
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 5/8] drm/i915: Optimize HDCP key load

[Ramalingam C]

HDCP key need not be cleared on each hdcp disable. And HDCP key Load
is skipped if key is already loaded.

v2:
  No change. Added Reviewed-by tag.

v3:
  No change.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b1047dbf3393..65bdb95c0ad7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -49,6 +49,10 @@ static int intel_hdcp_load_keys(struct drm_i915_private 
*dev_priv)
int ret;
u32 val;
 
+   val = I915_READ(HDCP_KEY_STATUS);
+   if ((val & HDCP_KEY_LOAD_DONE) && (val & HDCP_KEY_LOAD_STATUS))
+   return 0;
+
/*
 * On HSW and BDW HW loads the HDCP1.4 Key when Display comes
 * out of reset. So if Key is not already loaded, its an error state.
@@ -545,8 +549,6 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
-   intel_hdcp_clear_keys(dev_priv);
-
ret = connector->hdcp_shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 3/8] drm/i915: Connector info in HDCP debug msgs

[Ramalingam C]

When HDCP authentication is triggered on multiple connector, having
connector name and ID in debug message will be more informative.

v2:
  Added logs with connector info at the start of en/disable [Seanpaul]
  Added the connector info into Check link failure msgs too.

v3:
  No Changes. Added Reviewed-by tag.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0a1ef82c77a2..cfd13ee8c534 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -524,6 +524,9 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
enum port port = intel_dig_port->base.port;
int ret;
 
+   DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
+ connector->base.name, connector->base.base.id);
+
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
20)) {
@@ -548,6 +551,9 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
int i, ret;
 
+   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
+ connector->base.name, connector->base.base.id);
+
if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
DRM_ERROR("PG1 is disabled, cannot load keys\n");
return -ENXIO;
@@ -727,8 +733,9 @@ int intel_hdcp_check_link(struct intel_connector *connector)
goto out;
 
if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-   DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
-  I915_READ(PORT_HDCP_STATUS(port)));
+   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
ret = -ENXIO;
connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
schedule_work(>hdcp_prop_work);
@@ -745,7 +752,8 @@ int intel_hdcp_check_link(struct intel_connector *connector)
goto out;
}
 
-   DRM_DEBUG_KMS("HDCP link failed, retrying authentication\n");
+   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
 
ret = _intel_hdcp_disable(connector);
if (ret) {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/8] Adhering to HDCP1.4 Compliance Test Spec

[Ramalingam C]

This series is developed to address the expectations from HDCP compliance
test specification.

6/8 patches are for fixing failures in one or more compliance test cases
2 patches are Good to have kind. Not related to compliance.

Thanks to Seanpaul for immediate review comments on v1 and v2.

Ramalingam C (8):
  drm/i915: Handle failure from 2nd stage HDCP auth
  drm/i915: Stop encryption for repeater with no sink
  drm/i915: Connector info in HDCP debug msgs
  drm/i915: Retry HDCP bksv read
  drm/i915: Optimize HDCP key load
  drm/i915: Detect panel's hdcp capability
  drm/i915: Reauthenticate HDCP on failure
  drm/i915: fix misalignment in HDCP register def

 drivers/gpu/drm/i915/i915_reg.h   | 58 +-
 drivers/gpu/drm/i915/intel_dp.c   | 39 +++--
 drivers/gpu/drm/i915/intel_drv.h  |  4 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 88 ++-
 4 files changed, 137 insertions(+), 52 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/8] drm/i915: Stop encryption for repeater with no sink

[Ramalingam C]

If a HDCP repeater is detected with zero downstream devices,
HDCP spec approves either of below actions:

1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
   on success, continue encryption.

Since disable encryption is agreed, repeater is not expected to have its
own display. So there is no consumption of the display content in such
setup.

Hence, incase of repeater with zero device count, this patch fails the
HDCP authentication and stops the HDCP encryption.

v2:
  Rephrased commit msg and added comments in code [Seanpaul]

v3:
  No changes. Added Reviewed-by tag.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index de9a925c122d..0a1ef82c77a2 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -166,10 +166,16 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return -EPERM;
}
 
-   /* If there are no downstream devices, we're all done. */
+   /*
+* When repeater reports 0 device count, HDCP1.4 spec allows disabling
+* the HDCP encryption. That implies that repeater can't have its own
+* display. As there is no consumption of encrypted content in the
+* repeater with 0 downstream devices, we are failing the
+* authentication.
+*/
num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
if (num_downstream == 0)
-   return 0;
+   return -EINVAL;
 
ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
if (!ksv_fifo)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Ramalingam C]

We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.

This patch ensures that, when hdcp authentication fails, HDCP encryption
and signalling is turned off.

v2:
  Dropped connector ref passing to auth [Seanpaul]
  Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul]

v3:
  No Changes. Added the Reveiwed-by tag.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b97184eccd9c..de9a925c122d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -562,6 +562,9 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
  connector->hdcp_shim);
if (ret) {
DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
+
+   /* Ensuring HDCP encryption and signalling are stopped. */
+   _intel_hdcp_disable(connector);
return ret;
}
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

[James Ausmus]

On Fri, Feb 02, 2018 at 05:57:02PM -0200, Paulo Zanoni wrote:
> This commit adds the basic CDCLK functions, but it's still missing
> pieces of the display initialization sequence.
> 
> v2:
>  - Implement the voltage levels.
>  - Rebase.
> v3:
>  - Adjust to the new "bypass" clock (Imre).
>  - Call intel_dump_cdclk_state() too.
>  - Rename a variable to avoid confusion.
>  - Simplify the DVFS part.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  10 +-
>  drivers/gpu/drm/i915/intel_cdclk.c | 235 
> -
>  drivers/gpu/drm/i915/intel_drv.h   |   2 +
>  3 files changed, 243 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f6e1677e8211..856e88c6ee97 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7182,8 +7182,12 @@ enum {
>  #define SKL_DFSM_PIPE_B_DISABLE  (1 << 21)
>  #define SKL_DFSM_PIPE_C_DISABLE  (1 << 28)
>  
> -#define SKL_DSSM _MMIO(0x51004)
> -#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define SKL_DSSM _MMIO(0x51004)
> +#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz  (1 << 31)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK   (7 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz  (0 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz(1 << 29)
> +#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz(2 << 29)
>  
>  #define GEN7_FF_SLICE_CS_CHICKEN1_MMIO(0x20e0)
>  #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL  (1<<14)
> @@ -8831,6 +8835,8 @@ enum skl_power_gate {
>  #define  BXT_CDCLK_CD2X_PIPE_NONEBXT_CDCLK_CD2X_PIPE(3)
>  #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE  (1<<16)
>  #define  CDCLK_FREQ_DECIMAL_MASK (0x7ff)
> +#define  ICL_CDCLK_CD2X_PIPE(pipe)   ((pipe) << 19)

This is still wrong :)

> +#define  ICL_CDCLK_CD2X_PIPE_NONEICL_CDCLK_CD2X_PIPE(7)
>  
>  /* LCPLL_CTL */
>  #define LCPLL1_CTL   _MMIO(0x46010)
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index ee788d5be5e3..52a15d0eaae9 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1778,6 +1778,197 @@ static void cnl_sanitize_cdclk(struct 
> drm_i915_private *dev_priv)
>   dev_priv->cdclk.hw.vco = -1;
>  }
>  
> +static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
> +{
> + int ranges_24[] = { 312000, 552000, 648000 };
> + int ranges_19_38[] = { 307200, 556800, 652800 };
> + int *ranges;
> +
> + switch (ref) {
> + default:
> + MISSING_CASE(ref);
> + case 24000:
> + ranges = ranges_24;
> + break;
> + case 19200:
> + case 38400:
> + ranges = ranges_19_38;
> + break;
> + }
> +
> + if (min_cdclk > ranges[1])
> + return ranges[2];
> + else if (min_cdclk > ranges[0])
> + return ranges[1];
> + else
> + return ranges[0];
> +}
> +
> +static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int 
> cdclk)
> +{
> + int ratio;
> +
> + if (cdclk == dev_priv->cdclk.hw.bypass)
> + return 0;
> +
> + switch (cdclk) {
> + default:
> + MISSING_CASE(cdclk);
> + case 307200:
> + case 556800:
> + case 652800:
> + WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
> + dev_priv->cdclk.hw.ref != 38400);
> + break;
> + case 312000:
> + case 552000:
> + case 648000:
> + WARN_ON(dev_priv->cdclk.hw.ref != 24000);
> + }
> +
> + ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
> +
> + return dev_priv->cdclk.hw.ref * ratio;
> +}
> +
> +static void icl_set_cdclk(struct drm_i915_private *dev_priv,
> +   const struct intel_cdclk_state *cdclk_state)
> +{
> + unsigned int cdclk = cdclk_state->cdclk;
> + unsigned int vco = cdclk_state->vco;
> + int ret;
> +
> + mutex_lock(_priv->pcu_lock);
> + ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE, 3);
> + mutex_unlock(_priv->pcu_lock);
> + if (ret) {
> + DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
> +   ret);
> + return;
> + }
> +
> + if (dev_priv->cdclk.hw.vco != 0 &&
> + dev_priv->cdclk.hw.vco != vco)
> + cnl_cdclk_pll_disable(dev_priv);
> +
> + if (dev_priv->cdclk.hw.vco != vco)
> + cnl_cdclk_pll_enable(dev_priv, vco);
> +
> + I915_WRITE(CDCLK_CTL, ICL_CDCLK_CD2X_PIPE_NONE |
> +   skl_cdclk_decimal(cdclk));
> +
> + mutex_lock(_priv->pcu_lock);
> + /* 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Chris Wilson]

Quoting Andy Lutomirski (2018-02-02 19:23:33)
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> >> Anyway, this is all on a 4.14 kernel.  I should update to 4.16 and see
> >> what happens.
> >
> > I updated to 4.15, and the situation is much worse.  With
> > enable_psr=1, the system survives for several seconds and then the
> > screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> > get to the Fedora login screen and then the system dies.  If I set
> > enable_psr=1 using sysfs, it does a bit after the next resume.  It
> > seems like it also sometimes hangs even worse a bit after the screen
> > stops updating, but it's hard to tell.
> >
> > I see this in my logs:
> >
> > [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR*
> > [CRTC:37:pipe A] flip_done timed out
> >
> > Sometimes I see this a bit later:
> >
> > [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR*
> > [CRTC:37:pipe A] flip_done timed out
> 
> I filed:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=104918

Thank you. To be frank the only PSR system we have in CI isn't currently
doing PSR (due to the test not taking panel restrictions into account).
Not that I think we have any test looking for lag, but it should at
least have told us that PSR was snafu.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-02 18:38:16)
> From: Tvrtko Ursulin 
> 
> Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
> inside for busy-stats") added a tasklet_disable call in busy stats
> enabling, but we failed to understand that the PMU enable callback runs
> as an hard IRQ (IPI).
> 
> Consequence of this is that the PMU enable callback can interrupt the
> execlists tasklet, and will then deadlock when it calls
> intel_engine_stats_enable->tasklet_disable.
> 
> To fix this, I realized it is possible to move the engine stats enablement
> and disablement to PMU event init and destroy hooks. This allows for much
> simpler implementation since those hooks run in normal context (can
> sleep).
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking 
> inside for busy-stats")
> Testcase: igt/perf_pmu/enable-race-*
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: intel-gfx@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 95 
> +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 14 -
>  2 files changed, 31 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index ecb0198bfb7a..e97860b44004 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -287,7 +287,24 @@ static u64 count_interrupts(struct drm_i915_private 
> *i915)
>  
>  static void i915_pmu_event_destroy(struct perf_event *event)
>  {
> +   struct drm_i915_private *i915 =
> +   container_of(event->pmu, typeof(*i915), pmu.base);
> +   struct intel_engine_cs *engine;
> +
> WARN_ON(event->parent);
> +
> +   if (!is_engine_event(event))
> +   return;

I think engine_event_destroy() for symmetry with engine_event_init() ?

> +
> +   engine = intel_engine_lookup_user(i915,
> + engine_event_class(event),
> + engine_event_instance(event));
> +   if (WARN_ON_ONCE(!engine))
> +   return;
> +
> +   if ((engine_event_sample(event) == I915_SAMPLE_BUSY) &&

Rogue ()

> +   intel_engine_supports_stats(engine))
> +   intel_disable_engine_stats(engine);
>  }
>  
>  static int
> @@ -340,13 +357,23 @@ static int engine_event_init(struct perf_event *event)
> struct drm_i915_private *i915 =
> container_of(event->pmu, typeof(*i915), pmu.base);
> struct intel_engine_cs *engine;
> +   u8 sample;
> +   int ret;
>  
> engine = intel_engine_lookup_user(i915, engine_event_class(event),
>   engine_event_instance(event));
> if (!engine)
> return -ENODEV;
>  
> -   return engine_event_status(engine, engine_event_sample(event));
> +   sample = engine_event_sample(event);
> +   ret = engine_event_status(engine, sample);
> +   if (ret)
> +   return ret;
> +
> +   if ((sample == I915_SAMPLE_BUSY) && 
> intel_engine_supports_stats(engine))
> +   ret = intel_enable_engine_stats(engine);
> +
> +   return ret;
>  }

Yeah, that is disgustingly simpler. On a second look nothing springs to
mind why this shouldn't work. Will sleep on it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race
URL   : https://patchwork.freedesktop.org/series/37575/
State : success

== Summary ==

Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> INCOMPLETE (shard-snb) fdo#103880
incomplete -> PASS   (shard-hsw) fdo#103540
Test perf_pmu:
Subgroup busy-double-start-vcs0:
incomplete -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-shrfb-fliptrack:
pass   -> FAIL   (shard-apl) fdo#103167
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Subgroup 2x-plain-flip-ts-check:
fail   -> PASS   (shard-hsw)
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2836 pass:1749 dwarn:1   dfail:0   fail:21  skip:1064 
time:12388s
shard-hswtotal:2836 pass:1732 dwarn:1   dfail:0   fail:12  skip:1090 
time:11553s
shard-snbtotal:2800 pass:1309 dwarn:1   dfail:0   fail:10  skip:1479 
time:6086s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7867/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Deprecate I915_SET_COLORKEY_NONE

[Patchwork]

== Series Details ==

Series: drm/i915: Deprecate I915_SET_COLORKEY_NONE
URL   : https://patchwork.freedesktop.org/series/37584/
State : success

== Summary ==

Series 37584v1 drm/i915: Deprecate I915_SET_COLORKEY_NONE
https://patchwork.freedesktop.org/api/1.0/series/37584/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:411s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:276s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:573s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
5d1c9edf2c98 drm/i915: Deprecate I915_SET_COLORKEY_NONE

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7871/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: CustomEDID fix

[Chris Wilson]

Quoting dom.const...@free.fr (2018-02-02 18:37:12)
> Hello, 
> 
> For my HTPC setup, I'm using the option "CustomEDID".
> With this option, output attaching and destroying events leads to crashes.
> 
> The following sequence leads to a crash:
> - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
> - Starting Xorg
> - Connect HDMI2
> - Disconnect HDMI2
> - Reconnect HDMI2
>   -> Crash
> 
> 
> The crash happens in xf86OutputSetEDID 
> (xorg/xserver/hw/xfree86/modes/xf86Crtc.c) 
> at "free(output->MonInfo)". MonInfo is assigned with 
> sna_output->fake_edid_mon 
> which is allocated by intel driver in sna_output_load_fake_edid 
> (src/sna/sna_display.c). 

Ho hum, looks like I never tested it more than a quick start of Xorg.
Sorry about that :(
 
> Sequence details:
> - Starting Xorg
>-> fake_edid_mon is initialized
> 
> - Connect HDMI2
>-> xf86OutputSetEDID is called: 
>- MonInfo is NULL
>- MonInfo is assigned with fake_edid_mon pointer
>- MonInfo is read by Xorg
> 
> - Disconnect HDMI2
> 
> - Reconnect HDMI2
>-> xf86OutputSetEDID is called:
>- MonInfo is freed thus also fake_edid_mon
>- MonInfo is assigned with fake_edid_mon
>- MonInfo is read but it was freed -> CRASH
> 
> 
> The fix consists of a new instance of xf86MonPtr for each calls of 
> xf86OutputSetEDID. 
> This instance is initialized with fake_edid_raw which render fake_edid_mon 
> useless. 
> With this proposal, the behaviour of an EDID override is similar to a "real" 
> EDID. 
> 
> Regards,
> 
> 
> Signed-off-by: Dominique Constant 
> To: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for Adhering to HDCP1.4 Compliance Test Spec (rev2)

[Patchwork]

== Series Details ==

Series: Adhering to HDCP1.4 Compliance Test Spec (rev2)
URL   : https://patchwork.freedesktop.org/series/37539/
State : warning

== Summary ==

Series 37539v2 Adhering to HDCP1.4 Compliance Test Spec
https://patchwork.freedesktop.org/api/1.0/series/37539/revisions/2/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-kbl-r)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:410s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:498s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:571s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:464s

2e76a2952923eba64c4f9baf461613bc42ee997a drm-tip: 2018y-02m-02d-20h-33m-12s UTC 
integration manifest
f59e25b3bcf1 drm/i915: fix misalignment in HDCP register def
a7d2d95a6d4c drm/i915: Reauthenticate HDCP on failure
cc97a0bd0632 drm/i915: Detect panel's hdcp capability
3a341f86d9ff drm/i915: Optimize HDCP key load
305d2e473304 drm/i915: Retry HDCP bksv read
8e90c38454d8 drm/i915: Connector info in HDCP debug msgs
9c11e3f71d69 drm/i915: Stop encryption for repeater with no sink
045ac0c60193 drm/i915: Handle failure from 2nd stage HDCP auth

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7870/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Deprecate I915_SET_COLORKEY_NONE

[Chris Wilson]

Quoting Ville Syrjala (2018-02-02 20:42:31)
> From: Ville Syrjälä 
> 
> Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
> way to disable colorkey is to just set flags to 0, which is
> exactly what the intel ddx has been doing all along.

I can confirm that I never realised the flag existed. Just not setting
either the dst or src flags made sense to me.
 
> Currently when userspace sets the flags to 0, we end up in a
> funny state where colorkey is disabled, but various colorkey
> vs. scaling checks still consider colorkey to be enabled, and
> thus we don't allow plane scaling to kick in.
> 
> In case there is some other userspace out there that actually
> uses this flag (unlikely as this is an i915 specific uapi)
> we'll keep on accepting it.
> 
> Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH xf86-video-intel] sna/video: Try to use hw scaling with SKL+ sprites

[Chris Wilson]

Quoting Ville Syrjala (2018-02-02 20:42:52)
> From: Ville Syrjälä 
> 
> SKL reintroduced plane scaling once more. Let's try to make use of it.
> 
> The one annoying caveat is that you can't do colorkeying and scaling at
> the same time :(  For now we'll leave the choice of colorkey vs.
> scaling to the user via that XV_ALWAYS_ON_TOP attribute.

Fair enough, that attribute is fairly magic to force the plane to act as
an overlay plane and keep X's grubby hands off. Having it autoscale
would be fun :)
 
> One possible idea for improving the situation would be to add support
> for autopaint colorkey, and automatically disable the colorkey whenever
> the window is not obscured by anything and autopaint colorkey is enabled.

Ok, the way you've written it, it should allow us to extend support as
desired. Lgtm, thanks.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset

[Chris Wilson]

Quoting Patchwork (2018-02-02 20:25:31)
> == Series Details ==
> 
> Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
> URL   : https://patchwork.freedesktop.org/series/37552/
> State : success
> 
> == Summary ==
> 
> Test perf:
> Subgroup blocking:
> fail   -> PASS   (shard-hsw) fdo#102252
> Subgroup enable-disable:
> fail   -> PASS   (shard-apl) fdo#103715
> Test perf_pmu:
> Subgroup busy-double-start-vcs0:
> incomplete -> PASS   (shard-apl)
> Test kms_flip:
> Subgroup 2x-plain-flip-ts-check:
> fail   -> PASS   (shard-hsw)
> Subgroup plain-flip-ts-check:
> fail   -> PASS   (shard-hsw) fdo#100368
> 
> fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
> fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> 
> shard-apltotal:2836 pass:1751 dwarn:1   dfail:0   fail:20  skip:1064 
> time:12305s
> shard-hswtotal:2800 pass:1710 dwarn:1   dfail:0   fail:11  skip:1076 
> time:10834s
> shard-snbtotal:2836 pass:1328 dwarn:1   dfail:0   fail:10  skip:1497 
> time:6378s

As thankfully it doesn't appear to upset the shards, and it should just
be a bit of paranoia fluff that just happens to make my bxt that little
bit more stable, I've pushed it. If only to have that GEM_BUG_ON() that
the GTIIR isn't set at reset_irq()!

Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Stop encryption for repeater with no sink

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:30AM +0530, Ramalingam C wrote:
> If a HDCP repeater is detected with zero downstream devices,
> HDCP spec approves either of below actions:
> 
> 1. Dont continue on second stage authentication. Disable encryption.
> 2. Continue with second stage authentication excluding the KSV list and
>on success, continue encryption.
> 
> Since disable encryption is agreed, repeater is not expected to have its
> own display. So there is no consumption of the display content in such
> setup.
> 
> Hence, incase of repeater with zero device count, this patch fails the
> HDCP authentication and stops the HDCP encryption.
> 
> v2:
>   Rephrased commit msg and added comments in code [Seanpaul]
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index de9a925c122d..0a1ef82c77a2 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -166,10 +166,16 @@ int intel_hdcp_auth_downstream(struct 
> intel_digital_port *intel_dig_port,
>   return -EPERM;
>   }
>  
> - /* If there are no downstream devices, we're all done. */
> + /*
> +  * When repeater reports 0 device count, HDCP1.4 spec allows disabling
> +  * the HDCP encryption. That implies that repeater can't have its own
> +  * display. As there is no consumption of encrypted content in the
> +  * repeater with 0 downstream devices, we are failing the
> +  * authentication.
> +  */
>   num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
>   if (num_downstream == 0)
> - return 0;
> + return -EINVAL;
>  
>   ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
>   if (!ksv_fifo)
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Connector info in HDCP debug msgs

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:31AM +0530, Ramalingam C wrote:
> When HDCP authentication is triggered on multiple connector, having
> connector name and ID in debug message will be more informative.
> 
> v2:
>   Added logs with connector info at the start of en/disable [Seanpaul]
>   Added the connector info into Check link failure msgs too.
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 0a1ef82c77a2..cfd13ee8c534 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -524,6 +524,9 @@ static int _intel_hdcp_disable(struct intel_connector 
> *connector)
>   enum port port = intel_dig_port->base.port;
>   int ret;
>  
> + DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
> +   connector->base.name, connector->base.base.id);
> +
>   I915_WRITE(PORT_HDCP_CONF(port), 0);
>   if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
>   20)) {
> @@ -548,6 +551,9 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
>   int i, ret;
>  
> + DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> +   connector->base.name, connector->base.base.id);
> +
>   if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
>   DRM_ERROR("PG1 is disabled, cannot load keys\n");
>   return -ENXIO;
> @@ -727,8 +733,9 @@ int intel_hdcp_check_link(struct intel_connector 
> *connector)
>   goto out;
>  
>   if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
> - DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
> -I915_READ(PORT_HDCP_STATUS(port)));
> + DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
> +   connector->base.name, connector->base.base.id,
> +   I915_READ(PORT_HDCP_STATUS(port)));
>   ret = -ENXIO;
>   connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
>   schedule_work(>hdcp_prop_work);
> @@ -745,7 +752,8 @@ int intel_hdcp_check_link(struct intel_connector 
> *connector)
>   goto out;
>   }
>  
> - DRM_DEBUG_KMS("HDCP link failed, retrying authentication\n");
> + DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
> +   connector->base.name, connector->base.base.id);
>  
>   ret = _intel_hdcp_disable(connector);
>   if (ret) {
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:29AM +0530, Ramalingam C wrote:
> We enable the HDCP encryption as a part of first stage authentication.
> So when second stage authentication fails, we need to disable the HDCP
> encryption and signalling.
> 
> This patch ensures that, when hdcp authentication fails, HDCP encryption
> and signalling is turned off.
> 
> v2:
>   Dropped connector ref passing to auth [Seanpaul]
>   Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul]
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index b97184eccd9c..de9a925c122d 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -562,6 +562,9 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
> connector->hdcp_shim);
>   if (ret) {
>   DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
> +
> + /* Ensuring HDCP encryption and signalling are stopped. */
> + _intel_hdcp_disable(connector);
>   return ret;
>   }
>  
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Reauthenticate HDCP on failure

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:35AM +0530, Ramalingam C wrote:
> Incase of HDCP authentication failure, HDCP spec expects
> reauthentication. Hence this patch adds the reauthentications
> to be compliance with spec.
> 
> v2:
>   do-while to for loop for simplicity. [Seanpaul].
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 4b2821feb4b4..4a3db5de229e 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -572,7 +572,7 @@ static int _intel_hdcp_disable(struct intel_connector 
> *connector)
>  static int _intel_hdcp_enable(struct intel_connector *connector)
>  {
>   struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
> - int i, ret;
> + int i, ret, tries = 3;
>  
>   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> connector->base.name, connector->base.base.id);
> @@ -593,17 +593,26 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   return ret;
>   }
>  
> - ret = intel_hdcp_auth(conn_to_dig_port(connector),
> -   connector->hdcp_shim);
> - if (ret) {
> - DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
> + /* Incase of authentication failures, HDCP spec expects reauth. */
> + for (i = 0; i < tries; i++) {
> + if (i)
> + DRM_DEBUG_KMS("[%s:%d] HDCP Reauth...\n",
> +   connector->base.name,
> +   connector->base.base.id);
> +
> + ret = intel_hdcp_auth(conn_to_dig_port(connector),
> +   connector->hdcp_shim);
> + if (!ret)
> + return 0;
> +
> + DRM_ERROR("[%s:%d] Failed to authenticate HDCP (%d)\n",
> +   connector->base.name, connector->base.base.id, ret);

This wasn't quite what I had laid out. This code should be outside the loop
(it only runs if the number of tries is exceeded). Also, I intentionally did not
check i for the debug message since it's a debug message and we can assume it's
free. So that can go back below the if (!ret) return statement without the
conditional.

Further, let's try to be consistent with where we print the connector name/id.
Since you are now printing it at the start of the function, it's not needed in
any of these statements. I had also changed the wording of the retry message, so
it would be nice if you brought that forth (minus the connector info, ofc)

Sean

>  
>   /* Ensuring HDCP encryption and signalling are stopped. */
>   _intel_hdcp_disable(connector);
> - return ret;
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  static void intel_hdcp_check_work(struct work_struct *work)
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Detect panel's hdcp capability

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:34AM +0530, Ramalingam C wrote:
> DP HDCP1.4 spec mandates that An can be written to panel only after
> detecting the panel's hdcp capability.
> 
> For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
> For HDMI valid BKSV indicates the panel's hdcp capability.
> 
> For HDMI it is optional to detect the panel's hdcp capability before
> An Write.
> 
> v2:
>   Added comments explaining the need for action [Seanpaul].
>   Made panel's hdcp capability detection optional for hdmi [Seanpaul].
>   Defined a func for reading bcaps for DP [Seanpaul].
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 39 
> +++
>  drivers/gpu/drm/i915/intel_drv.h  |  4 
>  drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  1 +
>  4 files changed, 57 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 03d86ff9b805..5fa6bb7dbb7a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5107,17 +5107,32 @@ static int intel_dp_hdcp_read_bstatus(struct 
> intel_digital_port *intel_dig_port,
>  }
>  
>  static
> -int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
> -bool *repeater_present)
> +int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
> +  u8 *bcaps)
>  {
>   ssize_t ret;
> - u8 bcaps;
> +
>   ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BCAPS,
> -, 1);
> +bcaps, 1);
>   if (ret != 1) {
>   DRM_ERROR("Read bcaps from DP/AUX failed (%zd)\n", ret);
>   return ret >= 0 ? -EIO : ret;
>   }
> +
> + return 0;
> +}
> +
> +static
> +int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
> +bool *repeater_present)
> +{
> + ssize_t ret;
> + u8 bcaps;
> +
> + ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
> + if (ret)
> + return ret;
> +
>   *repeater_present = bcaps & DP_BCAPS_REPEATER_PRESENT;
>   return 0;
>  }
> @@ -5218,6 +5233,21 @@ bool intel_dp_hdcp_check_link(struct 
> intel_digital_port *intel_dig_port)
>   return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
>  }
>  
> +static
> +int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
> +   bool *hdcp_capable)
> +{
> + ssize_t ret;
> + u8 bcaps;
> +
> + ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
> + if (ret)
> + return ret;
> +
> + *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
> + return 0;
> +}
> +
>  static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
>   .write_an_aksv = intel_dp_hdcp_write_an_aksv,
>   .read_bksv = intel_dp_hdcp_read_bksv,
> @@ -5229,6 +5259,7 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim 
> = {
>   .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
>   .toggle_signalling = intel_dp_hdcp_toggle_signalling,
>   .check_link = intel_dp_hdcp_check_link,
> + .hdcp_capable = intel_dp_hdcp_capable,
>  };
>  
>  static void intel_edp_panel_vdd_sanitize(struct intel_dp *intel_dp)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index d6a808374dfb..468ec1e90e16 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -369,6 +369,10 @@ struct intel_hdcp_shim {
>  
>   /* Ensures the link is still protected */
>   bool (*check_link)(struct intel_digital_port *intel_dig_port);
> +
> + /* Detects panel's hdcp capability. This is optional for HDMI. */
> + int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> + bool *hdcp_capable);
>  };
>  
>  struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 0cee79c86d7e..4b2821feb4b4 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -414,12 +414,28 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   u32 reg;
>   u8 shim[DRM_HDCP_RI_LEN];
>   } ri;
> - bool repeater_present;
> + bool repeater_present, hdcp_capable;
>  
>   dev_priv = intel_dig_port->base.base.dev->dev_private;
>  
>   port = intel_dig_port->base.port;
>  
> + /*
> +  * Detects whether the display is HDCP capable. Although we check for
> +  * valid Bksv below, the HDCP over DP spec requires that we check
> +  * whether the display supports HDCP before we write An. For HDMI
> +  * displays, this is not necessary.
> +  */
> + if (shim->hdcp_capable) {
> + ret = 

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Retry HDCP bksv read

[Sean Paul]

On Sat, Feb 03, 2018 at 01:41:32AM +0530, Ramalingam C wrote:
> HDCP specification says that when bksv is identified as invalid
> (not with 20 1s), bksv should be re-read and verified.
> 
> This patch adds the above mentioned re-read for bksv.
> 
> v2:
>   Rephrased the commit msg [Seanpaul]
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index cfd13ee8c534..40d0c5e73cc6 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   struct drm_i915_private *dev_priv;
>   enum port port;
>   unsigned long r0_prime_gen_start;
> - int ret, i;
> + int ret, i, retry = 1;
>   union {
>   u32 reg[2];
>   u8 shim[DRM_HDCP_AN_LEN];
> @@ -438,11 +438,16 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   r0_prime_gen_start = jiffies;
>  
>   memset(, 0, sizeof(bksv));
> - ret = shim->read_bksv(intel_dig_port, bksv.shim);
> +
> + do {
> + ret = shim->read_bksv(intel_dig_port, bksv.shim);
> + if (!ret)
> + if (!intel_hdcp_is_ksv_valid(bksv.shim))
> + ret = -ENODEV;
> + } while (ret && retry--);

I think you missed the second part of my review. I'd really like to clean this
part up as well to make it a bit more straightforward.

Sean

> +
>   if (ret)
>   return ret;
> - else if (!intel_hdcp_is_ksv_valid(bksv.shim))
> - return -ENODEV;
>  
>   I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
>   I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH xf86-video-intel] sna/video: Try to use hw scaling with SKL+ sprites

[Ville Syrjala]

From: Ville Syrjälä 

SKL reintroduced plane scaling once more. Let's try to make use of it.

The one annoying caveat is that you can't do colorkeying and scaling at
the same time :(  For now we'll leave the choice of colorkey vs.
scaling to the user via that XV_ALWAYS_ON_TOP attribute.

One possible idea for improving the situation would be to add support
for autopaint colorkey, and automatically disable the colorkey whenever
the window is not obscured by anything and autopaint colorkey is enabled.

Signed-off-by: Ville Syrjälä 
---
 src/sna/sna_video_sprite.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index 69bfdfd21b29..44898a748e1c 100644
--- a/src/sna/sna_video_sprite.c
+++ b/src/sna/sna_video_sprite.c
@@ -47,7 +47,9 @@
 #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /* [31:0] 
Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
 #define DRM_FORMAT_UYVY fourcc_code('U', 'Y', 'V', 'Y') /* [31:0] 
Y1:Cr0:Y0:Cb0 8:8:8:8 little endian */
 
-#define has_hw_scaling(sna) ((sna)->kgem.gen < 071)
+#define has_hw_scaling(sna, video) ((sna)->kgem.gen < 071 || \
+   ((sna)->kgem.gen >= 0110 && 
(video)->AlwaysOnTop))
+
 
 #define LOCAL_IOCTL_MODE_SETPLANE  DRM_IOWR(0xB7, struct 
local_mode_set_plane)
 struct local_mode_set_plane {
@@ -153,7 +155,7 @@ static int sna_video_sprite_best_size(ddQueryBestSize_ARGS)
struct sna_video *video = port->devPriv.ptr;
struct sna *sna = video->sna;
 
-   if (!has_hw_scaling(sna) && !sna->render.video) {
+   if (!has_hw_scaling(sna, video) && !sna->render.video) {
*p_w = vid_w;
*p_h = vid_h;
} else {
@@ -524,7 +526,7 @@ off:
cache_bo = true;
}
 
-   if (!has_hw_scaling(sna) && sna->render.video &&
+   if (!has_hw_scaling(sna, video) && sna->render.video &&
!((frame.src.x2 - frame.src.x1) == (dst.x2 - dst.x1) &&
  (frame.src.y2 - frame.src.y1) == (dst.y2 - dst.y1))) {
ScreenPtr screen = to_screen_from_sna(sna);
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Deprecate I915_SET_COLORKEY_NONE

[Ville Syrjala]

From: Ville Syrjälä 

Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious
way to disable colorkey is to just set flags to 0, which is
exactly what the intel ddx has been doing all along.

Currently when userspace sets the flags to 0, we end up in a
funny state where colorkey is disabled, but various colorkey
vs. scaling checks still consider colorkey to be enabled, and
thus we don't allow plane scaling to kick in.

In case there is some other userspace out there that actually
uses this flag (unlikely as this is an i915 specific uapi)
we'll keep on accepting it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 1 -
 drivers/gpu/drm/i915/intel_display.c  | 4 ++--
 drivers/gpu/drm/i915/intel_sprite.c   | 5 -
 include/uapi/drm/i915_drm.h   | 4 +++-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index c7984a80706e..0ee32275994a 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -56,7 +56,6 @@ intel_create_plane_state(struct drm_plane *plane)
 
state->base.plane = plane;
state->base.rotation = DRM_MODE_ROTATE_0;
-   state->ckey.flags = I915_SET_COLORKEY_NONE;
 
return state;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ad8d9c6c40e4..60ba5bb3f34c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4787,7 +4787,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
return ret;
 
/* check colorkey */
-   if (plane_state->ckey.flags != I915_SET_COLORKEY_NONE) {
+   if (plane_state->ckey.flags) {
DRM_DEBUG_KMS("[PLANE:%d:%s] scaling with color key not 
allowed",
  intel_plane->base.base.id,
  intel_plane->base.name);
@@ -12803,7 +12803,7 @@ intel_check_primary_plane(struct intel_plane *plane,
 
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
-   if (state->ckey.flags == I915_SET_COLORKEY_NONE) {
+   if (!state->ckey.flags) {
min_scale = 1;
max_scale = skl_max_scale(to_intel_crtc(crtc), 
crtc_state);
}
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aea21a9abf6c..3be22c0fcfb5 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -894,7 +894,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
/* setup can_scale, min_scale, max_scale */
if (INTEL_GEN(dev_priv) >= 9) {
/* use scaler when colorkey is not required */
-   if (state->ckey.flags == I915_SET_COLORKEY_NONE) {
+   if (!state->ckey.flags) {
can_scale = 1;
min_scale = 1;
max_scale = skl_max_scale(crtc, crtc_state);
@@ -1074,6 +1074,9 @@ int intel_sprite_set_colorkey(struct drm_device *dev, 
void *data,
struct drm_modeset_acquire_ctx ctx;
int ret = 0;
 
+   /* ignore the pointless "none" flag */
+   set->flags &= ~I915_SET_COLORKEY_NONE;
+
/* Make sure we don't try to enable both src & dest simultaneously */
if ((set->flags & (I915_SET_COLORKEY_DESTINATION | 
I915_SET_COLORKEY_SOURCE)) == (I915_SET_COLORKEY_DESTINATION | 
I915_SET_COLORKEY_SOURCE))
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 536ee4febd74..29fa48e4755d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1358,7 +1358,9 @@ struct drm_intel_overlay_attrs {
  * active on a given plane.
  */
 
-#define I915_SET_COLORKEY_NONE (1<<0) /* disable color key matching */
+#define I915_SET_COLORKEY_NONE (1<<0) /* Deprecated. Instead set
+   * flags==0 to disable 
colorkeying.
+   */
 #define I915_SET_COLORKEY_DESTINATION  (1<<1)
 #define I915_SET_COLORKEY_SOURCE   (1<<2)
 struct drm_intel_sprite_colorkey {
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: nuke pch type :o

[Patchwork]

== Series Details ==

Series: drm/i915: nuke pch type :o
URL   : https://patchwork.freedesktop.org/series/37581/
State : success

== Summary ==

Series 37581v1 drm/i915: nuke pch type :o
https://patchwork.freedesktop.org/api/1.0/series/37581/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
fail   -> PASS   (fi-skl-guc) fdo#103191

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:109  pass:105  dwarn:0   dfail:0   fail:0   skip:3  
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

c051d09ed8f4b307b8d00076380e657759bd8eb5 drm-tip: 2018y-02m-02d-19h-34m-35s UTC 
integration manifest
c9640917d438 drm/i915: obliterate PCH types in favour of direct PCH id use
a42e9060d5a8 drm/i915/debugfs: print PCH id instead of PCH type in i915 
capabilities
9d855e64b20d drm/i915: introduce INTEL_PCH_ID() and use it

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7869/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-02 17:44:58)
> On Fri, Feb 02, 2018 at 05:31:57PM +, Chris Wilson wrote:
> > I think we're okay with just using the master IIR for IRQ_NONE /
> > IRQ_HANDLED as that is the interrupt generator aiui. If the child
> > sources disagree that's another issue, but as far as the kernel is
> > concerned i915 did generate and handle an interrupt.
> 
> I think that might be the usual way it goes. I guess the IIR clearing is
> racing with the MASTER_IRQ read as AFAIK the MASTER_IRQ status bits aren't
> latched or anything (since we don't have to clear them). So I believe this
> still leaves open a small window where even the MASTER_IRQ has cleared
> itself by the time the irq handler gets around to reading it. So that
> would look like a genuine spurious interrupt even though the GPU did
> raise it for a reason.

I've committed ourselves (for the time being at least) to always
returning IRQ_HANDLED if the master IIR reports an interrupt. Hopefully
I won't regret it :)

Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Patchwork]

== Series Details ==

Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL   : https://patchwork.freedesktop.org/series/37558/
State : warning

== Summary ==

Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail   -> PASS   (shard-hsw)
Subgroup plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
pass   -> SKIP   (shard-snb) fdo#101623
Test kms_chv_cursor_fail:
Subgroup pipe-a-64x64-left-edge:
pass   -> SKIP   (shard-snb)
Test kms_cursor_legacy:
Subgroup nonblocking-modeset-vs-cursor-atomic:
pass   -> SKIP   (shard-snb)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-apltotal:2795 pass:1725 dwarn:1   dfail:0   fail:19  skip:1049 
time:12012s
shard-hswtotal:2800 pass:1710 dwarn:1   dfail:0   fail:11  skip:1076 
time:10873s
shard-snbtotal:2836 pass:1325 dwarn:1   dfail:0   fail:10  skip:1500 
time:6402s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7864/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
URL   : https://patchwork.freedesktop.org/series/37552/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test perf_pmu:
Subgroup busy-double-start-vcs0:
incomplete -> PASS   (shard-apl)
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
fail   -> PASS   (shard-hsw)
Subgroup plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:2836 pass:1751 dwarn:1   dfail:0   fail:20  skip:1064 
time:12305s
shard-hswtotal:2800 pass:1710 dwarn:1   dfail:0   fail:11  skip:1076 
time:10834s
shard-snbtotal:2836 pass:1328 dwarn:1   dfail:0   fail:10  skip:1497 
time:6378s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7863/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev5)

[Patchwork]

== Series Details ==

Series: ICL display initialization and some plane bits (rev5)
URL   : https://patchwork.freedesktop.org/series/36993/
State : failure

== Summary ==

Series 36993v5 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/5/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq) fdo#101144 +2
pass   -> FAIL   (fi-skl-6700k2) fdo#103191 +3
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2)
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2) k.org#197971 +1
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6260u) fdo#104108 +4
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
k.org#197971 https://bugzilla.kernel.org/show_bug.cgi?id=197971
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:369s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:255  dwarn:0   dfail:0   fail:3   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-s2total:288  pass:259  dwarn:0   dfail:0   fail:3   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:279s
fi-glk-1 total:288  pass:257  dwarn:0   dfail:0   fail:3   skip:28  
time:518s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:387s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:260  dwarn:1   dfail:0   fail:3   skip:24  
time:460s
fi-kbl-7560u total:288  pass:266  dwarn:0   dfail:0   fail:3   skip:19  
time:505s
fi-kbl-7567u total:288  pass:265  dwarn:0   dfail:0   fail:3   skip:20  
time:452s
fi-kbl-r total:288  pass:258  dwarn:0   dfail:0   fail:3   skip:27  
time:512s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:568s
fi-skl-6260u total:288  pass:265  dwarn:0   dfail:0   fail:3   skip:20  
time:425s
fi-skl-6600u total:288  pass:258  dwarn:0   dfail:0   fail:3   skip:27  

[Intel-gfx] [PATCH v2 6/8] drm/i915: Detect panel's hdcp capability

[Ramalingam C]

DP HDCP1.4 spec mandates that An can be written to panel only after
detecting the panel's hdcp capability.

For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
For HDMI valid BKSV indicates the panel's hdcp capability.

For HDMI it is optional to detect the panel's hdcp capability before
An Write.

v2:
  Added comments explaining the need for action [Seanpaul].
  Made panel's hdcp capability detection optional for hdmi [Seanpaul].
  Defined a func for reading bcaps for DP [Seanpaul].

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_dp.c   | 39 +++
 drivers/gpu/drm/i915/intel_drv.h  |  4 
 drivers/gpu/drm/i915/intel_hdcp.c | 18 +-
 drivers/gpu/drm/i915/intel_hdmi.c |  1 +
 4 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03d86ff9b805..5fa6bb7dbb7a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5107,17 +5107,32 @@ static int intel_dp_hdcp_read_bstatus(struct 
intel_digital_port *intel_dig_port,
 }
 
 static
-int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
-  bool *repeater_present)
+int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
+u8 *bcaps)
 {
ssize_t ret;
-   u8 bcaps;
+
ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BCAPS,
-  , 1);
+  bcaps, 1);
if (ret != 1) {
DRM_ERROR("Read bcaps from DP/AUX failed (%zd)\n", ret);
return ret >= 0 ? -EIO : ret;
}
+
+   return 0;
+}
+
+static
+int intel_dp_hdcp_repeater_present(struct intel_digital_port *intel_dig_port,
+  bool *repeater_present)
+{
+   ssize_t ret;
+   u8 bcaps;
+
+   ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
+   if (ret)
+   return ret;
+
*repeater_present = bcaps & DP_BCAPS_REPEATER_PRESENT;
return 0;
 }
@@ -5218,6 +5233,21 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port 
*intel_dig_port)
return !(bstatus & (DP_BSTATUS_LINK_FAILURE | DP_BSTATUS_REAUTH_REQ));
 }
 
+static
+int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
+ bool *hdcp_capable)
+{
+   ssize_t ret;
+   u8 bcaps;
+
+   ret = intel_dp_hdcp_read_bcaps(intel_dig_port, );
+   if (ret)
+   return ret;
+
+   *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
+   return 0;
+}
+
 static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -5229,6 +5259,7 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
.toggle_signalling = intel_dp_hdcp_toggle_signalling,
.check_link = intel_dp_hdcp_check_link,
+   .hdcp_capable = intel_dp_hdcp_capable,
 };
 
 static void intel_edp_panel_vdd_sanitize(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d6a808374dfb..468ec1e90e16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -369,6 +369,10 @@ struct intel_hdcp_shim {
 
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *intel_dig_port);
+
+   /* Detects panel's hdcp capability. This is optional for HDMI. */
+   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
+   bool *hdcp_capable);
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0cee79c86d7e..4b2821feb4b4 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -414,12 +414,28 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
u32 reg;
u8 shim[DRM_HDCP_RI_LEN];
} ri;
-   bool repeater_present;
+   bool repeater_present, hdcp_capable;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
port = intel_dig_port->base.port;
 
+   /*
+* Detects whether the display is HDCP capable. Although we check for
+* valid Bksv below, the HDCP over DP spec requires that we check
+* whether the display supports HDCP before we write An. For HDMI
+* displays, this is not necessary.
+*/
+   if (shim->hdcp_capable) {
+   ret = shim->hdcp_capable(intel_dig_port, _capable);
+   if (ret)
+   return ret;
+   if (!hdcp_capable) {
+   DRM_ERROR("Panel is not HDCP capable\n");
+   return -EINVAL;
+ 

[Intel-gfx] [PATCH v2 7/8] drm/i915: Reauthenticate HDCP on failure

[Ramalingam C]

Incase of HDCP authentication failure, HDCP spec expects
reauthentication. Hence this patch adds the reauthentications
to be compliance with spec.

v2:
  do-while to for loop for simplicity. [Seanpaul].

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 4b2821feb4b4..4a3db5de229e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -572,7 +572,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 static int _intel_hdcp_enable(struct intel_connector *connector)
 {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
-   int i, ret;
+   int i, ret, tries = 3;
 
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
@@ -593,17 +593,26 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
return ret;
}
 
-   ret = intel_hdcp_auth(conn_to_dig_port(connector),
- connector->hdcp_shim);
-   if (ret) {
-   DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
+   /* Incase of authentication failures, HDCP spec expects reauth. */
+   for (i = 0; i < tries; i++) {
+   if (i)
+   DRM_DEBUG_KMS("[%s:%d] HDCP Reauth...\n",
+ connector->base.name,
+ connector->base.base.id);
+
+   ret = intel_hdcp_auth(conn_to_dig_port(connector),
+ connector->hdcp_shim);
+   if (!ret)
+   return 0;
+
+   DRM_ERROR("[%s:%d] Failed to authenticate HDCP (%d)\n",
+ connector->base.name, connector->base.base.id, ret);
 
/* Ensuring HDCP encryption and signalling are stopped. */
_intel_hdcp_disable(connector);
-   return ret;
}
 
-   return 0;
+   return ret;
 }
 
 static void intel_hdcp_check_work(struct work_struct *work)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 8/8] drm/i915: fix misalignment in HDCP register def

[Ramalingam C]

This patch aligns all definitions of hdcp registers and their bits.

v2:
  No changes. Added reviewed-by tag.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h | 58 -
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65ba10ad1fe5..e9c79b560823 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8483,34 +8483,34 @@ enum skl_power_gate {
 #define   CNL_AUX_ANAOVRD1_LDO_BYPASS  (1<<23)
 
 /* HDCP Key Registers */
-#define HDCP_KEY_CONF  _MMIO(0x66c00)
+#define HDCP_KEY_CONF  _MMIO(0x66c00)
 #define  HDCP_AKSV_SEND_TRIGGERBIT(31)
 #define  HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
 #define  HDCP_KEY_LOAD_TRIGGER BIT(8)
-#define HDCP_KEY_STATUS_MMIO(0x66c04)
-#define  HDCP_FUSE_IN_PROGRESS BIT(7)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  HDCP_FUSE_IN_PROGRESS BIT(7)
 #define  HDCP_FUSE_ERROR   BIT(6)
-#define  HDCP_FUSE_DONEBIT(5)
-#define  HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  HDCP_FUSE_DONEBIT(5)
+#define  HDCP_KEY_LOAD_STATUS  BIT(1)
 #define  HDCP_KEY_LOAD_DONEBIT(0)
-#define HDCP_AKSV_LO   _MMIO(0x66c10)
-#define HDCP_AKSV_HI   _MMIO(0x66c14)
+#define HDCP_AKSV_LO   _MMIO(0x66c10)
+#define HDCP_AKSV_HI   _MMIO(0x66c14)
 
 /* HDCP Repeater Registers */
-#define HDCP_REP_CTL   _MMIO(0x66d00)
-#define  HDCP_DDIB_REP_PRESENT BIT(30)
-#define  HDCP_DDIA_REP_PRESENT BIT(29)
-#define  HDCP_DDIC_REP_PRESENT BIT(28)
-#define  HDCP_DDID_REP_PRESENT BIT(27)
-#define  HDCP_DDIF_REP_PRESENT BIT(26)
-#define  HDCP_DDIE_REP_PRESENT BIT(25)
+#define HDCP_REP_CTL   _MMIO(0x66d00)
+#define  HDCP_DDIB_REP_PRESENT BIT(30)
+#define  HDCP_DDIA_REP_PRESENT BIT(29)
+#define  HDCP_DDIC_REP_PRESENT BIT(28)
+#define  HDCP_DDID_REP_PRESENT BIT(27)
+#define  HDCP_DDIF_REP_PRESENT BIT(26)
+#define  HDCP_DDIE_REP_PRESENT BIT(25)
 #define  HDCP_DDIB_SHA1_M0 (1 << 20)
 #define  HDCP_DDIA_SHA1_M0 (2 << 20)
 #define  HDCP_DDIC_SHA1_M0 (3 << 20)
 #define  HDCP_DDID_SHA1_M0 (4 << 20)
 #define  HDCP_DDIF_SHA1_M0 (5 << 20)
 #define  HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
-#define  HDCP_SHA1_BUSYBIT(16)
+#define  HDCP_SHA1_BUSYBIT(16)
 #define  HDCP_SHA1_READY   BIT(17)
 #define  HDCP_SHA1_COMPLETEBIT(18)
 #define  HDCP_SHA1_V_MATCH BIT(19)
@@ -8526,7 +8526,7 @@ enum skl_power_gate {
 #define HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
 #define HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
 #define HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
-#define HDCP_SHA_TEXT  _MMIO(0x66d18)
+#define HDCP_SHA_TEXT  _MMIO(0x66d18)
 
 /* HDCP Auth Registers */
 #define _PORTA_HDCP_AUTHENC0x66800
@@ -8542,25 +8542,25 @@ enum skl_power_gate {
  _PORTD_HDCP_AUTHENC, \
  _PORTE_HDCP_AUTHENC, \
  _PORTF_HDCP_AUTHENC) + x)
-#define PORT_HDCP_CONF(port)   _PORT_HDCP_AUTHENC(port, 0x0)
-#define  HDCP_CONF_CAPTURE_AN  BIT(0)
-#define  HDCP_CONF_AUTH_AND_ENC(BIT(1) | BIT(0))
-#define PORT_HDCP_ANINIT(port) _PORT_HDCP_AUTHENC(port, 0x4)
-#define PORT_HDCP_ANLO(port)   _PORT_HDCP_AUTHENC(port, 0x8)
-#define PORT_HDCP_ANHI(port)   _PORT_HDCP_AUTHENC(port, 0xC)
-#define PORT_HDCP_BKSVLO(port) _PORT_HDCP_AUTHENC(port, 0x10)
-#define PORT_HDCP_BKSVHI(port) _PORT_HDCP_AUTHENC(port, 0x14)
-#define PORT_HDCP_RPRIME(port) _PORT_HDCP_AUTHENC(port, 0x18)
-#define PORT_HDCP_STATUS(port) _PORT_HDCP_AUTHENC(port, 0x1C)
+#define PORT_HDCP_CONF(port)   _PORT_HDCP_AUTHENC(port, 0x0)
+#define  HDCP_CONF_CAPTURE_AN  BIT(0)
+#define  HDCP_CONF_AUTH_AND_ENC(BIT(1) | BIT(0))
+#define PORT_HDCP_ANINIT(port) _PORT_HDCP_AUTHENC(port, 0x4)
+#define PORT_HDCP_ANLO(port)   _PORT_HDCP_AUTHENC(port, 0x8)
+#define PORT_HDCP_ANHI(port)   _PORT_HDCP_AUTHENC(port, 0xC)
+#define PORT_HDCP_BKSVLO(port) _PORT_HDCP_AUTHENC(port, 0x10)
+#define PORT_HDCP_BKSVHI(port) _PORT_HDCP_AUTHENC(port, 0x14)
+#define PORT_HDCP_RPRIME(port) _PORT_HDCP_AUTHENC(port, 0x18)
+#define PORT_HDCP_STATUS(port) _PORT_HDCP_AUTHENC(port, 0x1C)
 #define  HDCP_STATUS_STREAM_A_ENC  BIT(31)
 #define  HDCP_STATUS_STREAM_B_ENC  BIT(30)
 #define  HDCP_STATUS_STREAM_C_ENC  BIT(29)
 #define  HDCP_STATUS_STREAM_D_ENC  BIT(28)
 #define  HDCP_STATUS_AUTH  BIT(21)
 

[Intel-gfx] [PATCH v2 5/8] drm/i915: Optimize HDCP key load

[Ramalingam C]

HDCP key need not be cleared on each hdcp disable. And HDCP key Load
is skipped if key is already loaded.

v2:
  No change. Added Reviewed-by tag.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 40d0c5e73cc6..0cee79c86d7e 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -49,6 +49,10 @@ static int intel_hdcp_load_keys(struct drm_i915_private 
*dev_priv)
int ret;
u32 val;
 
+   val = I915_READ(HDCP_KEY_STATUS);
+   if ((val & HDCP_KEY_LOAD_DONE) && (val & HDCP_KEY_LOAD_STATUS))
+   return 0;
+
/*
 * On HSW and BDW HW loads the HDCP1.4 Key when Display comes
 * out of reset. So if Key is not already loaded, its an error state.
@@ -539,8 +543,6 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
-   intel_hdcp_clear_keys(dev_priv);
-
ret = connector->hdcp_shim->toggle_signalling(intel_dig_port, false);
if (ret) {
DRM_ERROR("Failed to disable HDCP signalling\n");
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/8] drm/i915: Connector info in HDCP debug msgs

[Ramalingam C]

When HDCP authentication is triggered on multiple connector, having
connector name and ID in debug message will be more informative.

v2:
  Added logs with connector info at the start of en/disable [Seanpaul]
  Added the connector info into Check link failure msgs too.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0a1ef82c77a2..cfd13ee8c534 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -524,6 +524,9 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
enum port port = intel_dig_port->base.port;
int ret;
 
+   DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
+ connector->base.name, connector->base.base.id);
+
I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
20)) {
@@ -548,6 +551,9 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
int i, ret;
 
+   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
+ connector->base.name, connector->base.base.id);
+
if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
DRM_ERROR("PG1 is disabled, cannot load keys\n");
return -ENXIO;
@@ -727,8 +733,9 @@ int intel_hdcp_check_link(struct intel_connector *connector)
goto out;
 
if (!(I915_READ(PORT_HDCP_STATUS(port)) & HDCP_STATUS_ENC)) {
-   DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
-  I915_READ(PORT_HDCP_STATUS(port)));
+   DRM_ERROR("%s:%d HDCP check failed: link is not encrypted,%x\n",
+ connector->base.name, connector->base.base.id,
+ I915_READ(PORT_HDCP_STATUS(port)));
ret = -ENXIO;
connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
schedule_work(>hdcp_prop_work);
@@ -745,7 +752,8 @@ int intel_hdcp_check_link(struct intel_connector *connector)
goto out;
}
 
-   DRM_DEBUG_KMS("HDCP link failed, retrying authentication\n");
+   DRM_DEBUG_KMS("[%s:%d] HDCP link failed, retrying authentication\n",
+ connector->base.name, connector->base.base.id);
 
ret = _intel_hdcp_disable(connector);
if (ret) {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/8] drm/i915: Retry HDCP bksv read

[Ramalingam C]

HDCP specification says that when bksv is identified as invalid
(not with 20 1s), bksv should be re-read and verified.

This patch adds the above mentioned re-read for bksv.

v2:
  Rephrased the commit msg [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index cfd13ee8c534..40d0c5e73cc6 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -397,7 +397,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
-   int ret, i;
+   int ret, i, retry = 1;
union {
u32 reg[2];
u8 shim[DRM_HDCP_AN_LEN];
@@ -438,11 +438,16 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
r0_prime_gen_start = jiffies;
 
memset(, 0, sizeof(bksv));
-   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+
+   do {
+   ret = shim->read_bksv(intel_dig_port, bksv.shim);
+   if (!ret)
+   if (!intel_hdcp_is_ksv_valid(bksv.shim))
+   ret = -ENODEV;
+   } while (ret && retry--);
+
if (ret)
return ret;
-   else if (!intel_hdcp_is_ksv_valid(bksv.shim))
-   return -ENODEV;
 
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/8] drm/i915: Stop encryption for repeater with no sink

[Ramalingam C]

If a HDCP repeater is detected with zero downstream devices,
HDCP spec approves either of below actions:

1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
   on success, continue encryption.

Since disable encryption is agreed, repeater is not expected to have its
own display. So there is no consumption of the display content in such
setup.

Hence, incase of repeater with zero device count, this patch fails the
HDCP authentication and stops the HDCP encryption.

v2:
  Rephrased commit msg and added comments in code [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index de9a925c122d..0a1ef82c77a2 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -166,10 +166,16 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return -EPERM;
}
 
-   /* If there are no downstream devices, we're all done. */
+   /*
+* When repeater reports 0 device count, HDCP1.4 spec allows disabling
+* the HDCP encryption. That implies that repeater can't have its own
+* display. As there is no consumption of encrypted content in the
+* repeater with 0 downstream devices, we are failing the
+* authentication.
+*/
num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
if (num_downstream == 0)
-   return 0;
+   return -EINVAL;
 
ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
if (!ksv_fifo)
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 0/8] Adhering to HDCP1.4 Compliance Test Spec

[Ramalingam C]

This series is developed to address the expectations from HDCP compliance
test specification.

6/8 patches are for fixing failures in one or more compliance test cases
2 patches are Good to have kind. Not related to compliance.

Thanks to Seanpaul for immediate review comments on v1.

Ramalingam C (8):
  drm/i915: Handle failure from 2nd stage HDCP auth
  drm/i915: Stop encryption for repeater with no sink
  drm/i915: Connector info in HDCP debug msgs
  drm/i915: Retry HDCP bksv read
  drm/i915: Optimize HDCP key load
  drm/i915: Detect panel's hdcp capability
  drm/i915: Reauthenticate HDCP on failure
  drm/i915: fix misalignment in HDCP register def

 drivers/gpu/drm/i915/i915_reg.h   | 58 +-
 drivers/gpu/drm/i915/intel_dp.c   | 39 --
 drivers/gpu/drm/i915/intel_drv.h  |  4 ++
 drivers/gpu/drm/i915/intel_hdcp.c | 87 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  1 +
 5 files changed, 137 insertions(+), 52 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Ramalingam C]

We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.

This patch ensures that, when hdcp authentication fails, HDCP encryption
and signalling is turned off.

v2:
  Dropped connector ref passing to auth [Seanpaul]
  Moved the call to disable_hdcp() to enable_hdcp() [Seanpaul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b97184eccd9c..de9a925c122d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -562,6 +562,9 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
  connector->hdcp_shim);
if (ret) {
DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
+
+   /* Ensuring HDCP encryption and signalling are stopped. */
+   _intel_hdcp_disable(connector);
return ret;
}
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 1/3] drm/i915: introduce INTEL_PCH_ID() and use it

[Jani Nikula]

Prepare for more widespread use of PCH id. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e158aab36d6..a1454045629a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2861,19 +2861,20 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
 #define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_CNP_LP(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
 #define HAS_PCH_LPT_LP(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
-(dev_priv)->pch_id == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE || \
+INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_LPT_H(dev_priv) \
-   ((dev_priv)->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
-(dev_priv)->pch_id == INTEL_PCH_WPT_DEVICE_ID_TYPE)
+   (INTEL_PCH_ID(dev_priv) == INTEL_PCH_LPT_DEVICE_ID_TYPE || \
+INTEL_PCH_ID(dev_priv) == INTEL_PCH_WPT_DEVICE_ID_TYPE)
 #define HAS_PCH_CPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CPT)
 #define HAS_PCH_IBX(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_IBX)
 #define HAS_PCH_NOP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_NOP)
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 0/3] drm/i915: nuke pch type :o

[Jani Nikula]

I was wondering how to clean up intel_virt_detect_pch(), also in a more future
compatible manner, and came up with this idea.

Is the text size increase in patch 3/3 too bad, that is the question.

BR,
Jani.


Jani Nikula (3):
  drm/i915: introduce INTEL_PCH_ID() and use it
  drm/i915/debugfs: print PCH id instead of PCH type in i915
capabilities
  drm/i915: obliterate PCH types in favour of direct PCH id use

 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.c | 46 +++
 drivers/gpu/drm/i915/i915_drv.h | 73 +
 3 files changed, 57 insertions(+), 64 deletions(-)

-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 3/3] drm/i915: obliterate PCH types in favour of direct PCH id use

[Jani Nikula]

The PCH type is an unnecessary level of abstraction that's an extra
maintenance burden. Switch to using PCH ids directly. This also
simplifies the virtual PCH detection.

The downside is code size increase for conditions that match several PCH
ids:

text   data bss dec hex filename
-1709581  689004612 1783093  1b3535 drivers/gpu/drm/i915/i915.ko
+1710634  689004612 1784146  1b3952 drivers/gpu/drm/i915/i915.ko

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.c | 46 +---
 drivers/gpu/drm/i915/i915_drv.h | 68 +++--
 2 files changed, 53 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9f1daf258fe..a027d753fb6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -123,9 +123,9 @@ static bool i915_error_injected(struct drm_i915_private 
*dev_priv)
  fmt, ##__VA_ARGS__)
 
 
-static enum intel_pch intel_virt_detect_pch(struct drm_i915_private *dev_priv)
+static unsigned int intel_virt_detect_pch(struct drm_i915_private *dev_priv)
 {
-   enum intel_pch ret = PCH_NOP;
+   unsigned int id = INTEL_PCH_NOP;
 
/*
 * In a virtualized passthrough environment we can be in a
@@ -135,27 +135,26 @@ static enum intel_pch intel_virt_detect_pch(struct 
drm_i915_private *dev_priv)
 */
 
if (IS_GEN5(dev_priv)) {
-   ret = PCH_IBX;
+   id = INTEL_PCH_IBX_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
} else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
-   ret = PCH_CPT;
+   id = INTEL_PCH_CPT_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming CougarPoint PCH\n");
+   } else if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv)) {
+   id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+   DRM_DEBUG_KMS("Assuming LynxPoint LP PCH\n");
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
-   ret = PCH_LPT;
-   if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
-   dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
-   else
-   dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
+   id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
} else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   ret = PCH_SPT;
+   id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
} else if (IS_COFFEELAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   ret = PCH_CNP;
+   id = INTEL_PCH_CNP_DEVICE_ID_TYPE;
DRM_DEBUG_KMS("Assuming CannonPoint PCH\n");
}
 
-   return ret;
+   return id;
 }
 
 static void intel_detect_pch(struct drm_i915_private *dev_priv)
@@ -166,7 +165,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 * (which really amounts to a PCH but no South Display).
 */
if (INTEL_INFO(dev_priv)->num_pipes == 0) {
-   dev_priv->pch_type = PCH_NOP;
+   dev_priv->pch_id = INTEL_PCH_NOP;
return;
}
 
@@ -189,81 +188,63 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
 
id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 
-   dev_priv->pch_id = id;
-
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_IBX;
DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
WARN_ON(!IS_GEN5(dev_priv));
} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_CPT;
DRM_DEBUG_KMS("Found CougarPoint PCH\n");
WARN_ON(!IS_GEN6(dev_priv) &&
!IS_IVYBRIDGE(dev_priv));
} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
-   /* PantherPoint is CPT compatible */
-   dev_priv->pch_type = PCH_CPT;
DRM_DEBUG_KMS("Found PantherPoint PCH\n");
WARN_ON(!IS_GEN6(dev_priv) &&
!IS_IVYBRIDGE(dev_priv));
} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_LPT;
DRM_DEBUG_KMS("Found LynxPoint PCH\n");
WARN_ON(!IS_HASWELL(dev_priv) &&
!IS_BROADWELL(dev_priv));
WARN_ON(IS_HSW_ULT(dev_priv) ||
IS_BDW_ULT(dev_priv));
} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
-   dev_priv->pch_type = PCH_LPT;
 

[Intel-gfx] [RFC 2/3] drm/i915/debugfs: print PCH id instead of PCH type in i915 capabilities

[Jani Nikula]

Preparation for future patches. Split this out to highlight the debugfs
change.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..1bc7d9db0ddf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -45,7 +45,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
 
seq_printf(m, "gen: %d\n", INTEL_GEN(dev_priv));
seq_printf(m, "platform: %s\n", intel_platform_name(info->platform));
-   seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
+   seq_printf(m, "pch: %04x\n", INTEL_PCH_ID(dev_priv));
 
intel_device_info_dump_flags(info, );
intel_device_info_dump_runtime(info, );
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/17] drm/i915/icl: add the main CDCLK functions

[Paulo Zanoni]

This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.

v2:
 - Implement the voltage levels.
 - Rebase.
v3:
 - Adjust to the new "bypass" clock (Imre).
 - Call intel_dump_cdclk_state() too.
 - Rename a variable to avoid confusion.
 - Simplify the DVFS part.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h|  10 +-
 drivers/gpu/drm/i915/intel_cdclk.c | 235 -
 drivers/gpu/drm/i915/intel_drv.h   |   2 +
 3 files changed, 243 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6e1677e8211..856e88c6ee97 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7182,8 +7182,12 @@ enum {
 #define SKL_DFSM_PIPE_B_DISABLE(1 << 21)
 #define SKL_DFSM_PIPE_C_DISABLE(1 << 28)
 
-#define SKL_DSSM   _MMIO(0x51004)
-#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz(1 << 31)
+#define SKL_DSSM   _MMIO(0x51004)
+#define CNL_DSSM_CDCLK_PLL_REFCLK_24MHz(1 << 31)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_MASK (7 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_24MHz(0 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz  (1 << 29)
+#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz  (2 << 29)
 
 #define GEN7_FF_SLICE_CS_CHICKEN1  _MMIO(0x20e0)
 #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL(1<<14)
@@ -8831,6 +8835,8 @@ enum skl_power_gate {
 #define  BXT_CDCLK_CD2X_PIPE_NONE  BXT_CDCLK_CD2X_PIPE(3)
 #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE(1<<16)
 #define  CDCLK_FREQ_DECIMAL_MASK   (0x7ff)
+#define  ICL_CDCLK_CD2X_PIPE(pipe) ((pipe) << 19)
+#define  ICL_CDCLK_CD2X_PIPE_NONE  ICL_CDCLK_CD2X_PIPE(7)
 
 /* LCPLL_CTL */
 #define LCPLL1_CTL _MMIO(0x46010)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index ee788d5be5e3..52a15d0eaae9 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1778,6 +1778,197 @@ static void cnl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
dev_priv->cdclk.hw.vco = -1;
 }
 
+static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
+{
+   int ranges_24[] = { 312000, 552000, 648000 };
+   int ranges_19_38[] = { 307200, 556800, 652800 };
+   int *ranges;
+
+   switch (ref) {
+   default:
+   MISSING_CASE(ref);
+   case 24000:
+   ranges = ranges_24;
+   break;
+   case 19200:
+   case 38400:
+   ranges = ranges_19_38;
+   break;
+   }
+
+   if (min_cdclk > ranges[1])
+   return ranges[2];
+   else if (min_cdclk > ranges[0])
+   return ranges[1];
+   else
+   return ranges[0];
+}
+
+static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
+{
+   int ratio;
+
+   if (cdclk == dev_priv->cdclk.hw.bypass)
+   return 0;
+
+   switch (cdclk) {
+   default:
+   MISSING_CASE(cdclk);
+   case 307200:
+   case 556800:
+   case 652800:
+   WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
+   dev_priv->cdclk.hw.ref != 38400);
+   break;
+   case 312000:
+   case 552000:
+   case 648000:
+   WARN_ON(dev_priv->cdclk.hw.ref != 24000);
+   }
+
+   ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
+
+   return dev_priv->cdclk.hw.ref * ratio;
+}
+
+static void icl_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_state *cdclk_state)
+{
+   unsigned int cdclk = cdclk_state->cdclk;
+   unsigned int vco = cdclk_state->vco;
+   int ret;
+
+   mutex_lock(_priv->pcu_lock);
+   ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+   SKL_CDCLK_PREPARE_FOR_CHANGE,
+   SKL_CDCLK_READY_FOR_CHANGE,
+   SKL_CDCLK_READY_FOR_CHANGE, 3);
+   mutex_unlock(_priv->pcu_lock);
+   if (ret) {
+   DRM_ERROR("Failed to inform PCU about cdclk change (%d)\n",
+ ret);
+   return;
+   }
+
+   if (dev_priv->cdclk.hw.vco != 0 &&
+   dev_priv->cdclk.hw.vco != vco)
+   cnl_cdclk_pll_disable(dev_priv);
+
+   if (dev_priv->cdclk.hw.vco != vco)
+   cnl_cdclk_pll_enable(dev_priv, vco);
+
+   I915_WRITE(CDCLK_CTL, ICL_CDCLK_CD2X_PIPE_NONE |
+ skl_cdclk_decimal(cdclk));
+
+   mutex_lock(_priv->pcu_lock);
+   /* TODO: add proper DVFS support. */
+   sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, 2);
+   mutex_unlock(_priv->pcu_lock);
+
+   intel_update_cdclk(dev_priv);
+}
+
+static void icl_get_cdclk(struct 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
 I got this after a recent suspend/resume:

 Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
 Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
 dirs
 Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
 scanning /sys/bus
 Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
 scanning /sys/class
 Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
 configuration file '/etc/systemd/sleep.conf': No such file or
 directory
 Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
 Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
 sender=n/a destination=n/a object=/org/freedesktop/login1
 interface=org.freedesktop.login1.Manager member=PrepareForSleep
 cookie=570 reply
 Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
 type=method_call sender=:1.46 destination=:1.1
 object=/org/freedesktop/login1/session/_32
 interface=org.freedesktop.login1.Session member=ReleaseDevice
 Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
 sender=n/a destination=:1.46
 object=/org/freedesktop/login1/session/_32
 interface=org.freedesktop.login1.Session member=PauseDevice cookie
 Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
 transform 0: Permission denied
 Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
 with (Permission denied), drawing cursor with OpenGL from now on

 But I don't see the word "cursor" in my system logs before the first
 suspend.  What am I looking for?  This is Fedora 27 running a Gnome
 Wayland session, but it hasn't been reinstalled in some time, so it's
 possible that there are some weird settings sitting around.  But I did
 check and I have no weird i915 parameters.
>>>
>>> You are using gnome-shell as the display server. From that it appears to
>>> have started off with a HW cursor and switched to a SW cursor after
>>> suspend. Did you notice a change in behaviour? After rebooting or just
>>> restarting gnome-shell?
>>
>> I think it's less consistently bad after a reboot before suspending.
>>
>>>
 Also, are these things potentially related:

 [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
 atomic update failure on pipe A
>>>
>>> They are just "missed the immediate vblank for the screen update"
>>> messages. Should not be related to PSR, but may cause jitter by delaying
>>> the odd screen update.
>>
>> I just got this one, and the timestamp is at least reasonably close to
>> a giant latency spike:
>>
>> [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
>> 1079, scanline start 1087, end 1088
>>
>>>
 As I'm typing this, I've seen a couple instances of what seems like a
 full *second* of cursor latency, but I've only gotten the potential
 atomic update failure once.

 And is there any straightforward tracing to do to distinguish between
 PSR exit latency and other potential sources of latency?
>>>
>>> It looks plausible that we could at least report how long it takes the
>>> registers to reflect the change in state (but we don't). The best source
>>> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
>>
>> Hmm.
>>
>> I went and looked at the code, and I noticed what could be bugs or
>> could (more likely) be my confusion since I don't know this code at
>> all:
>>
>> intel_single_frame_update() does something inscrutable to me, but I
>> imagine it does something that causes the next page flip to get
>> noticed by the panel even with PSR on.  But how does the code that
>> calls it know that anything happened?  (Looking at the commit history,
>> maybe this is something special that's only needed on some platforms
>> but doesn't replace the normal PSR exit sequence.)
>>
>> Perhaps more interestingly, intel_psr_flush() does this:
>>
>> /* By definition flush = invalidate + flush */
>> if (frontbuffer_bits)
>> intel_psr_exit(dev_priv);
>>
>> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
>> if (!work_busy(_priv->psr.work.work))
>> schedule_delayed_work(_priv->psr.work,
>>   msecs_to_jiffies(100));
>>
>> I'm guessing that the idea is that we're turning off PSR because we
>> want the panel to update and we expect that, in 100ms, the update will
>> have hit the panel and we'll have been idle long enough for it to make
>> sense to re-enter PSR.  IOW, the code wants PSR to be off for at least
>> 100ms 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  wrote:
>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>> I got this after a recent suspend/resume:
>>>
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
>>> dirs
>>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>>> scanning /sys/bus
>>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>>> scanning /sys/class
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
>>> configuration file '/etc/systemd/sleep.conf': No such file or
>>> directory
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>>> sender=n/a destination=n/a object=/org/freedesktop/login1
>>> interface=org.freedesktop.login1.Manager member=PrepareForSleep
>>> cookie=570 reply
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
>>> type=method_call sender=:1.46 destination=:1.1
>>> object=/org/freedesktop/login1/session/_32
>>> interface=org.freedesktop.login1.Session member=ReleaseDevice
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>>> sender=n/a destination=:1.46
>>> object=/org/freedesktop/login1/session/_32
>>> interface=org.freedesktop.login1.Session member=PauseDevice cookie
>>> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
>>> transform 0: Permission denied
>>> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
>>> with (Permission denied), drawing cursor with OpenGL from now on
>>>
>>> But I don't see the word "cursor" in my system logs before the first
>>> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
>>> Wayland session, but it hasn't been reinstalled in some time, so it's
>>> possible that there are some weird settings sitting around.  But I did
>>> check and I have no weird i915 parameters.
>>
>> You are using gnome-shell as the display server. From that it appears to
>> have started off with a HW cursor and switched to a SW cursor after
>> suspend. Did you notice a change in behaviour? After rebooting or just
>> restarting gnome-shell?
>
> I think it's less consistently bad after a reboot before suspending.
>
>>
>>> Also, are these things potentially related:
>>>
>>> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
>>> atomic update failure on pipe A
>>
>> They are just "missed the immediate vblank for the screen update"
>> messages. Should not be related to PSR, but may cause jitter by delaying
>> the odd screen update.
>
> I just got this one, and the timestamp is at least reasonably close to
> a giant latency spike:
>
> [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
> 1079, scanline start 1087, end 1088
>
>>
>>> As I'm typing this, I've seen a couple instances of what seems like a
>>> full *second* of cursor latency, but I've only gotten the potential
>>> atomic update failure once.
>>>
>>> And is there any straightforward tracing to do to distinguish between
>>> PSR exit latency and other potential sources of latency?
>>
>> It looks plausible that we could at least report how long it takes the
>> registers to reflect the change in state (but we don't). The best source
>> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
>
> Hmm.
>
> I went and looked at the code, and I noticed what could be bugs or
> could (more likely) be my confusion since I don't know this code at
> all:
>
> intel_single_frame_update() does something inscrutable to me, but I
> imagine it does something that causes the next page flip to get
> noticed by the panel even with PSR on.  But how does the code that
> calls it know that anything happened?  (Looking at the commit history,
> maybe this is something special that's only needed on some platforms
> but doesn't replace the normal PSR exit sequence.)
>
> Perhaps more interestingly, intel_psr_flush() does this:
>
> /* By definition flush = invalidate + flush */
> if (frontbuffer_bits)
> intel_psr_exit(dev_priv);
>
> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> if (!work_busy(_priv->psr.work.work))
> schedule_delayed_work(_priv->psr.work,
>   msecs_to_jiffies(100));
>
> I'm guessing that the idea is that we're turning off PSR because we
> want the panel to update and we expect that, in 100ms, the update will
> have hit the panel and we'll have been idle long enough for it to make
> sense to re-enter PSR.  IOW, the code wants PSR to be off for at least
> 100ms and then to turn back on.  But this code actually says "turn PSR
> back on in at *most* 100ms".  What happens if there are two screen
> updates 99ms apart?  The first one should 

Re: [Intel-gfx] [PATCH] sna: CustomEDID fix

[Jani Nikula]

On Fri, 02 Feb 2018, dom.const...@free.fr wrote:
> For my HTPC setup, I'm using the option "CustomEDID".
> With this option, output attaching and destroying events leads to crashes.
>
> The following sequence leads to a crash:
> - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"

I know nothing about xorg customedid stuff.

But there's drm.edid_firmware=HDMI-2:/etc/my_edid.bin (or
drm_kms_helper.edid_firmware on older kernels) module parameter for the
kernel that does this transparently across the stack.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Fix PMU enable vs execlists tasklet race
URL   : https://patchwork.freedesktop.org/series/37575/
State : success

== Summary ==

Series 37575v1 drm/i915/pmu: Fix PMU enable vs execlists tasklet race
https://patchwork.freedesktop.org/api/1.0/series/37575/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162

fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:455s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:516s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

bde4e003ce549b8225142843e0d5aee19dd37d13 drm-tip: 2018y-02m-02d-15h-03m-15s UTC 
integration manifest
0056845d822a drm/i915/pmu: Fix PMU enable vs execlists tasklet race

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7867/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

[Jani Nikula]

On Fri, 02 Feb 2018, Ville Syrjälä  wrote:
> On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
>> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
>> index = 3, one of which has been kindly provided to me by Jan Brummer,
>> where not working with the i915 driver, giving a black screen on the
>> first modeset.
>> 
>> The problem with at least these Dells is that their VBT defines a MIPI
>> ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
>> reset in their INIT_OTP sequence, but the deassert must be done before
>> calling intel_dsi_device_ready(), so that is too late.
>> 
>> Simply doing the INIT_OTP sequence earlier is not enough to fix this,
>> because the INIT_OTP sequence also sends various MIPI packets to the
>> panel, which can only happen after calling intel_dsi_device_ready().
>> 
>> This commit fixes this by splitting the INIT_OTP sequence into everything
>> before the first DSI packet and everything else, including the first DSI
>> packet. The first part (everything before the first DSI packet) is then
>> used as deassert sequence.
>> 
>> Changed in v2:
>> -Split the init OTP sequence into a deassert reset and the actual init
>>  OTP sequence, instead of calling it earlier and then having the first
>>  mipi_exec_send_packet() call call intel_dsi_device_ready().
>> 
>> Changes in v3:
>> -Move the whole shebang to intel_bios.c
>> 
>> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880
>
> Bugzilla:
>
>> Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205
>
> References:
>
>> Cc: Jan-Michael Brummer 
>> Reported-by: Jan-Michael Brummer 
>> Tested-by: Hans de Goede 
>> Signed-off-by: Hans de Goede 
>
> This one seems good to me, and Jani hasn't complained about anything so
> Reviewed-by: Ville Syrjälä 

Thanks for hiding this in one place.

Acked-by: Jani Nikula 


>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_bios.c | 83 
>> +++
>>  2 files changed, 84 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 081190da0818..1f346266956b 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1349,6 +1349,7 @@ struct intel_vbt_data {
>>  u32 size;
>>  u8 *data;
>>  const u8 *sequence[MIPI_SEQ_MAX];
>> +u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
>>  } dsi;
>>  
>>  int crt_ddc_pin;
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 64a0d55df28e..cca620f8deb6 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -947,6 +947,86 @@ static int goto_next_sequence_v3(const u8 *data, int 
>> index, int total)
>>  return 0;
>>  }
>>  
>> +/*
>> + * Get len of pre-fixed deassert fragment from a v1 init OTP sequence,
>> + * skip all delay + gpio operands and stop at the first DSI packet op.
>> + */
>> +static int get_init_otp_deassert_fragment_len(struct drm_i915_private 
>> *dev_priv)
>> +{
>> +const u8 *data = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
>> +int index, len;
>> +
>> +if (WARN_ON(!data || dev_priv->vbt.dsi.seq_version != 1))
>> +return 0;
>> +
>> +/* index = 1 to skip sequence byte */
>> +for (index = 1; data[index] != MIPI_SEQ_ELEM_END; index += len) {
>> +switch (data[index]) {
>> +case MIPI_SEQ_ELEM_SEND_PKT:
>> +return index == 1 ? 0 : index;
>> +case MIPI_SEQ_ELEM_DELAY:
>> +len = 5; /* 1 byte for operand + uint32 */
>> +break;
>> +case MIPI_SEQ_ELEM_GPIO:
>> +len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
>> +break;
>> +default:
>> +return 0;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/*
>> + * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
>> + * The deassert must be done before calling intel_dsi_device_ready, so for
>> + * these devices we split the init OTP sequence into a deassert sequence and
>> + * the actual init OTP part.
>> + */
>> +static void fixup_mipi_sequences(struct drm_i915_private *dev_priv)
>> +{
>> +u8 *init_otp;
>> +int len;
>> +
>> +/* Limit this to VLV for now. */
>> +if (!IS_VALLEYVIEW(dev_priv))
>> +return;
>> +
>> +/* Limit this to v1 vid-mode sequences */
>> +if (dev_priv->vbt.dsi.config->is_cmd_mode ||
>> +dev_priv->vbt.dsi.seq_version != 1)
>> +return;
>> +
>> +/* Only do this if there are otp and assert seqs and no deassert seq */
>> +if 

[Intel-gfx] [PATCH] drm/i915/pmu: Fix PMU enable vs execlists tasklet race

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Commit 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking
inside for busy-stats") added a tasklet_disable call in busy stats
enabling, but we failed to understand that the PMU enable callback runs
as an hard IRQ (IPI).

Consequence of this is that the PMU enable callback can interrupt the
execlists tasklet, and will then deadlock when it calls
intel_engine_stats_enable->tasklet_disable.

To fix this, I realized it is possible to move the engine stats enablement
and disablement to PMU event init and destroy hooks. This allows for much
simpler implementation since those hooks run in normal context (can
sleep).

Signed-off-by: Tvrtko Ursulin 
Fixes: 99e48bf98dd0 ("drm/i915: Lock out execlist tasklet while peeking inside 
for busy-stats")
Testcase: igt/perf_pmu/enable-race-*
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_pmu.c | 95 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 14 -
 2 files changed, 31 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index ecb0198bfb7a..e97860b44004 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -287,7 +287,24 @@ static u64 count_interrupts(struct drm_i915_private *i915)
 
 static void i915_pmu_event_destroy(struct perf_event *event)
 {
+   struct drm_i915_private *i915 =
+   container_of(event->pmu, typeof(*i915), pmu.base);
+   struct intel_engine_cs *engine;
+
WARN_ON(event->parent);
+
+   if (!is_engine_event(event))
+   return;
+
+   engine = intel_engine_lookup_user(i915,
+ engine_event_class(event),
+ engine_event_instance(event));
+   if (WARN_ON_ONCE(!engine))
+   return;
+
+   if ((engine_event_sample(event) == I915_SAMPLE_BUSY) &&
+   intel_engine_supports_stats(engine))
+   intel_disable_engine_stats(engine);
 }
 
 static int
@@ -340,13 +357,23 @@ static int engine_event_init(struct perf_event *event)
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
struct intel_engine_cs *engine;
+   u8 sample;
+   int ret;
 
engine = intel_engine_lookup_user(i915, engine_event_class(event),
  engine_event_instance(event));
if (!engine)
return -ENODEV;
 
-   return engine_event_status(engine, engine_event_sample(event));
+   sample = engine_event_sample(event);
+   ret = engine_event_status(engine, sample);
+   if (ret)
+   return ret;
+
+   if ((sample == I915_SAMPLE_BUSY) && intel_engine_supports_stats(engine))
+   ret = intel_enable_engine_stats(engine);
+
+   return ret;
 }
 
 static int i915_pmu_event_init(struct perf_event *event)
@@ -402,7 +429,7 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
if (WARN_ON_ONCE(!engine)) {
/* Do nothing */
} else if (sample == I915_SAMPLE_BUSY &&
-  engine->pmu.busy_stats) {
+  intel_engine_supports_stats(engine)) {
val = ktime_to_ns(intel_engine_get_busy_time(engine));
} else {
val = engine->pmu.sample[sample].cur;
@@ -457,12 +484,6 @@ static void i915_pmu_event_read(struct perf_event *event)
local64_add(new - prev, >count);
 }
 
-static bool engine_needs_busy_stats(struct intel_engine_cs *engine)
-{
-   return intel_engine_supports_stats(engine) &&
-  (engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
-}
-
 static void i915_pmu_enable(struct perf_event *event)
 {
struct drm_i915_private *i915 =
@@ -502,21 +523,7 @@ static void i915_pmu_enable(struct perf_event *event)
 
GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
-   if (engine->pmu.enable_count[sample]++ == 0) {
-   /*
-* Enable engine busy stats tracking if needed or
-* alternatively cancel the scheduled disable.
-*
-* If the delayed disable was pending, cancel it and
-* in this case do not enable since it already is.
-*/
-   if (engine_needs_busy_stats(engine) &&
-   !engine->pmu.busy_stats) {
-   engine->pmu.busy_stats = 

[Intel-gfx] [PATCH] sna: CustomEDID fix

[dom . constant]

Hello, 

For my HTPC setup, I'm using the option "CustomEDID".
With this option, output attaching and destroying events leads to crashes.

The following sequence leads to a crash:
- In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
- Starting Xorg
- Connect HDMI2
- Disconnect HDMI2
- Reconnect HDMI2
  -> Crash


The crash happens in xf86OutputSetEDID 
(xorg/xserver/hw/xfree86/modes/xf86Crtc.c) 
at "free(output->MonInfo)". MonInfo is assigned with sna_output->fake_edid_mon 
which is allocated by intel driver in sna_output_load_fake_edid 
(src/sna/sna_display.c). 


Sequence details:
- Starting Xorg
   -> fake_edid_mon is initialized

- Connect HDMI2
   -> xf86OutputSetEDID is called: 
   - MonInfo is NULL
   - MonInfo is assigned with fake_edid_mon pointer
   - MonInfo is read by Xorg

- Disconnect HDMI2

- Reconnect HDMI2
   -> xf86OutputSetEDID is called:
   - MonInfo is freed thus also fake_edid_mon
   - MonInfo is assigned with fake_edid_mon
   - MonInfo is read but it was freed -> CRASH


The fix consists of a new instance of xf86MonPtr for each calls of 
xf86OutputSetEDID. 
This instance is initialized with fake_edid_raw which render fake_edid_mon 
useless. 
With this proposal, the behaviour of an EDID override is similar to a "real" 
EDID. 

Regards,


Signed-off-by: Dominique Constant 
To: Chris Wilson 

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index ea2f148d..ad805c2f 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -263,7 +263,6 @@ struct sna_output {
 uint32_t edid_blob_id;
 uint32_t edid_len;
 void *edid_raw;
-xf86MonPtr fake_edid_mon;
 void *fake_edid_raw;
 
 bool has_panel_limits;
@@ -4102,13 +4101,21 @@ static DisplayModePtr
 sna_output_override_edid(xf86OutputPtr output)
 {
 struct sna_output *sna_output = output->driver_private;
+xf86MonPtr mon = NULL;
+
+if (sna_output->fake_edid_raw == NULL)
+return NULL;
 
-if (sna_output->fake_edid_mon == NULL)
+mon = xf86InterpretEDID(output->scrn->scrnIndex, 
sna_output->fake_edid_raw);
+if (mon == NULL) {
 return NULL;
+}
+
+mon->flags |= MONITOR_EDID_COMPLETE_RAWDATA;
+
+xf86OutputSetEDID(output, mon);
 
-xf86OutputSetEDID(output, sna_output->fake_edid_mon);
-return xf86DDCGetModes(output->scrn->scrnIndex,
-       sna_output->fake_edid_mon);
+return xf86DDCGetModes(output->scrn->scrnIndex, mon);
 }
 
 static DisplayModePtr
@@ -4896,7 +4903,6 @@ sna_output_load_fake_edid(xf86OutputPtr output)
 FILE *file;
 void *raw;
 int size;
-xf86MonPtr mon;
 
 filename = fake_edid_name(output);
 if (filename == NULL)
@@ -4928,16 +4934,6 @@ sna_output_load_fake_edid(xf86OutputPtr output)
 }
 fclose(file);
 
-mon = xf86InterpretEDID(output->scrn->scrnIndex, raw);
-if (mon == NULL) {
-free(raw);
-goto err;
-}
-
-if (mon && size > 128)
-mon->flags |= MONITOR_EDID_COMPLETE_RAWDATA;
-
-sna_output->fake_edid_mon = mon;
 sna_output->fake_edid_raw = raw;
 
 xf86DrvMsg(output->scrn->scrnIndex, X_CONFIG,

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[James Ausmus]

On Fri, Feb 02, 2018 at 02:23:04PM -0200, Paulo Zanoni wrote:
> On ICL we have two sets of registers: one for port A and another for
> port B. The set of port A registers is the same as the CNL registers.
> 
> Since the procmon table on ICL is the same we want to reuse the CNL
> function. To do that we add a port argument and make CNL always call
> the function passing port A. This way, we'll be able to easily reuse
> the function on ICL when we add icl_display_core_init().
> 
> v2: Don't use _PICK() when you can use a ternary operator.
> v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
> Add an extra comment about why we're passing PORT_A (James).
> 
> Signed-off-by: Paulo Zanoni 

Reviewed-by: James Ausmus 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 22 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
>  2 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 65ba10ad1fe5..f6e1677e8211 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2104,6 +2104,28 @@ enum i915_power_well_id {
>  #define CNL_PORT_COMP_DW9_MMIO(0x162124)
>  #define CNL_PORT_COMP_DW10   _MMIO(0x162128)
>  
> +#define _ICL_PORT_COMP_DW0_A 0x162100
> +#define _ICL_PORT_COMP_DW0_B 0x6C100
> +#define ICL_PORT_COMP_DW0(port)  _MMIO_PORT(port, 
> _ICL_PORT_COMP_DW0_A, \
> +  _ICL_PORT_COMP_DW0_B)
> +#define _ICL_PORT_COMP_DW1_A 0x162104
> +#define _ICL_PORT_COMP_DW1_B 0x6C104
> +#define ICL_PORT_COMP_DW1(port)  _MMIO_PORT(port, 
> _ICL_PORT_COMP_DW1_A, \
> +  _ICL_PORT_COMP_DW1_B)
> +#define _ICL_PORT_COMP_DW3_A 0x16210C
> +#define _ICL_PORT_COMP_DW3_B 0x6C10C
> +#define ICL_PORT_COMP_DW3(port)  _MMIO_PORT(port, 
> _ICL_PORT_COMP_DW3_A, \
> +  _ICL_PORT_COMP_DW3_B)
> +#define _ICL_PORT_COMP_DW9_A 0x162124
> +#define _ICL_PORT_COMP_DW9_B 0x6C124
> +#define ICL_PORT_COMP_DW9(port)  _MMIO_PORT(port, 
> _ICL_PORT_COMP_DW9_A, \
> +  _ICL_PORT_COMP_DW9_B)
> +#define _ICL_PORT_COMP_DW10_A0x162128
> +#define _ICL_PORT_COMP_DW10_B0x6C128
> +#define ICL_PORT_COMP_DW10(port) _MMIO_PORT(port, \
> +_ICL_PORT_COMP_DW10_A, \
> +_ICL_PORT_COMP_DW10_B)
> +
>  /* BXT PHY Ref registers */
>  #define _PORT_REF_DW3_A  0x16218C
>  #define _PORT_REF_DW3_BC 0x6C18C
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 70e659772a7a..b4ef7875f055 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2794,12 +2794,19 @@ static const struct cnl_procmon {
>   { .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
>  };
>  
> -static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
> +/*
> + * CNL has just one set of registers, while ICL has two sets: one for port A 
> and
> + * the other for port B. The CNL registers are equivalent to the ICL port A
> + * registers, that's why we call the ICL macros even though the function has 
> CNL
> + * on its name.
> + */
> +static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv,
> +enum port port)
>  {
>   const struct cnl_procmon *procmon;
>   u32 val;
>  
> - val = I915_READ(CNL_PORT_COMP_DW3);
> + val = I915_READ(ICL_PORT_COMP_DW3(port));
>   switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
>   default:
>   MISSING_CASE(val);
> @@ -2820,13 +2827,13 @@ static void cnl_set_procmon_ref_values(struct 
> drm_i915_private *dev_priv)
>   break;
>   }
>  
> - val = I915_READ(CNL_PORT_COMP_DW1);
> + val = I915_READ(ICL_PORT_COMP_DW1(port));
>   val &= ~((0xff << 16) | 0xff);
>   val |= procmon->dw1;
> - I915_WRITE(CNL_PORT_COMP_DW1, val);
> + I915_WRITE(ICL_PORT_COMP_DW1(port), val);
>  
> - I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
> - I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
> + I915_WRITE(ICL_PORT_COMP_DW9(port), procmon->dw9);
> + I915_WRITE(ICL_PORT_COMP_DW10(port), procmon->dw10);
>  }
>  
>  static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
> resume)
> @@ -2847,7 +2854,8 @@ static void cnl_display_core_init(struct 
> drm_i915_private *dev_priv, bool resume
>   val &= ~CNL_COMP_PWR_DOWN;
>   I915_WRITE(CHICKEN_MISC_2, val);
>  
> - 

Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.

[Srivatsa, Anusha]

>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Tuesday, January 30, 2018 1:06 AM
>To: Vivi, Rodrigo 
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove Firmware URL.
>
>Quoting Rodrigo Vivi (2018-01-29 21:40:27)
>> On Mon, Jan 29, 2018 at 08:45:24PM +, Chris Wilson wrote:
>> > Quoting Srivatsa, Anusha (2018-01-29 20:17:25)
>> > >
>> > >
>> > > >-Original Message-
>> > > >From: Vivi, Rodrigo
>> > > >Sent: Friday, January 26, 2018 10:22 AM
>> > > >To: intel-gfx@lists.freedesktop.org
>> > > >Cc: Vivi, Rodrigo ; Srivatsa, Anusha
>> > > >
>> > > >Subject: [PATCH] drm/i915: Remove Firmware URL.
>> > > >
>> > > >The right place for the firmware is linux-firmware.git.
>> > > >We shouldn't advertise anywhere to users to start downloading
>> > > >firmware blobs manually.
>> > > >
>> > > >Also it seems that 01.org page is outdated and it doesn't contain
>> > > >DMC 1.27 for SKL, for instance. Probably other firmware releases
>> > > >are missing there, while they are part of the official 
>> > > >linux-firmware.git.
>> >
>> > Then get them onto 01.org. If Intel cannot be relied on to provide
>> > their own firmwares, the alternative is to stop shipping blobs entirely.
>>
>> I understand your point. But the goal is to have only one place and
>> this place is linux-firmware.git.
>
>If a user sees this message, then linux-firmware has failed them...
>
>> The web-page will still have the information about the firmware and a
>> text explaining the linux-firmware repository.
>>
>> But what I want is to avoid any users with the impression they have to
>> manually go there and install anything.
>
>Since we tie firmware to kernel version, I think it behooves us to carry a 
>complete
>history; and redundancy is never a bad idea. Fwiw, the local storage should be 
>a
>linux-firmware.git branch so that files are tracked universally.

Rodrigo, instead of removing the URL of 01.org, it will be a good idea to add 
the drm-firmware git repo which is Intel's repo of all firmwares. I understand 
users should not be encouraged to manually download the firmware. But maybe 
pointing out the location where we maintain all firmwares would be good.

Anusha
>-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Ville Syrjälä]

On Fri, Feb 02, 2018 at 05:31:57PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-02-02 16:03:36)
> > On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> > > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > > is possible for the master IIR to indicate a pending IRQ for which we
> > > have already cleared from the GTIIR. In this case, the DRM_ERROR are
> > > intended and should not be flagged as an error.
> > 
> > I guess an alternative would be to not clear IIR and use
> > sychronize_irq() instead as needed. But I suppose that doesn't
> > really provide any real benefits.
> > 
> > One concern is that we will now claim that all interrupts are handled,
> > and thus couldn't detect spurious interrupts. But one might hope that
> > MSI and whanot has made those a thing of the past.
> 
> We only say handled if the master IIR holds an interrupt, so not
> entirely lost. At present, we say IRQ_NONE even though the master IIR
> did raise the interrupt which seems wrong.
> 
> > I never checked what the kernel's threshold was for disabling the
> > interrupt line on spurious interrupts. I have occasionally thought about
> > it though as I too have realized that the IIR clearing could result in
> > the interrupt handler having nothing to do.
> > 
> > So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
> > only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
> > always for all MSI capable platforms?
> 
> I think we're okay with just using the master IIR for IRQ_NONE /
> IRQ_HANDLED as that is the interrupt generator aiui. If the child
> sources disagree that's another issue, but as far as the kernel is
> concerned i915 did generate and handle an interrupt.

I think that might be the usual way it goes. I guess the IIR clearing is
racing with the MASTER_IRQ read as AFAIK the MASTER_IRQ status bits aren't
latched or anything (since we don't have to clear them). So I believe this
still leaves open a small window where even the MASTER_IRQ has cleared
itself by the time the irq handler gets around to reading it. So that
would look like a genuine spurious interrupt even though the GPU did
raise it for a reason.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset

[Chris Wilson]

Quoting Michel Thierry (2018-02-02 16:49:49)
> On 2/2/2018 6:54 AM, Chris Wilson wrote:
> > Be paranoid and flush the GTIIR after clearing the CS interrupt to be
> > sure it has taken before we re-enable the interrupt handler. We still
> > see early interrupts following reset, the tasklet handling the mmio read
> > before it has been written by the CS. This hopefully reduces the
> > frequency to 0...
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104262
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Michel Thierry 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 13 +
> >   1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 40dbeaee9dfa..deeedfc9fe44 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1527,6 +1527,7 @@ static int gen9_init_render_ring(struct 
> > intel_engine_cs *engine)
> >   static void reset_irq(struct intel_engine_cs *engine)
> >   {
> >   struct drm_i915_private *dev_priv = engine->i915;
> > + int i;
> >   
> >   /*
> >* Clear any pending interrupt state.
> > @@ -1535,10 +1536,14 @@ static void reset_irq(struct intel_engine_cs 
> > *engine)
> >* buffered, and if we only reset it once there may still be
> >* an interrupt pending.
> >*/
> > - I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > -GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
> > - I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > -GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
> > + for (i = 0; i < 2; i++) {
> > + I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
> > +GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
> > + POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
> > + }
> > + GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
> > +(GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift));
> > +
> >   clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >   }
> >   
> > 
> 
> Acked-by: Michel Thierry 

Ta. Afaict, it's a timing issue and this is helping paper over it. Not a
fix, but maybe an indicator for someone to find the real problem?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Chris Wilson]

Quoting Ville Syrjälä (2018-02-02 16:03:36)
> On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> > As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> > is possible for the master IIR to indicate a pending IRQ for which we
> > have already cleared from the GTIIR. In this case, the DRM_ERROR are
> > intended and should not be flagged as an error.
> 
> I guess an alternative would be to not clear IIR and use
> sychronize_irq() instead as needed. But I suppose that doesn't
> really provide any real benefits.
> 
> One concern is that we will now claim that all interrupts are handled,
> and thus couldn't detect spurious interrupts. But one might hope that
> MSI and whanot has made those a thing of the past.

We only say handled if the master IIR holds an interrupt, so not
entirely lost. At present, we say IRQ_NONE even though the master IIR
did raise the interrupt which seems wrong.

> I never checked what the kernel's threshold was for disabling the
> interrupt line on spurious interrupts. I have occasionally thought about
> it though as I too have realized that the IIR clearing could result in
> the interrupt handler having nothing to do.
> 
> So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
> only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
> always for all MSI capable platforms?

I think we're okay with just using the master IIR for IRQ_NONE /
IRQ_HANDLED as that is the interrupt generator aiui. If the child
sources disagree that's another issue, but as far as the kernel is
concerned i915 did generate and handle an interrupt.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev4)

[Patchwork]

== Series Details ==

Series: ICL display initialization and some plane bits (rev4)
URL   : https://patchwork.freedesktop.org/series/36993/
State : failure

== Summary ==

Series 36993v4 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/4/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq) fdo#101144 +2
pass   -> FAIL   (fi-skl-6700k2) fdo#103191 +4
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2)
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2) k.org#197971 +1
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6260u) fdo#104108 +4
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
k.org#197971 https://bugzilla.kernel.org/show_bug.cgi?id=197971
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:429s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:479s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:255  dwarn:0   dfail:0   fail:3   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:259  dwarn:0   dfail:0   fail:3   skip:26  
time:576s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:257  dwarn:0   dfail:0   fail:3   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:260  dwarn:1   dfail:0   fail:3   skip:24  
time:455s
fi-kbl-7560u total:288  pass:266  dwarn:0   dfail:0   fail:3   skip:19  
time:507s
fi-kbl-7567u total:288  pass:265  dwarn:0   dfail:0   fail:3   skip:20  
time:451s
fi-kbl-r total:288  pass:258  dwarn:0   dfail:0   fail:3   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL display initialization and some plane bits (rev4)

[Patchwork]

== Series Details ==

Series: ICL display initialization and some plane bits (rev4)
URL   : https://patchwork.freedesktop.org/series/36993/
State : failure

== Summary ==

Series 36993v4 ICL display initialization and some plane bits
https://patchwork.freedesktop.org/api/1.0/series/36993/revisions/4/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6700k2) fdo#103191 +5
Subgroup suspend-read-crc-pipe-a:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6700hq) fdo#101144 +2
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2)
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6260u)
pass   -> FAIL   (fi-skl-6600u)
pass   -> FAIL   (fi-skl-6770hq)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)
pass   -> FAIL   (fi-cfl-s2) k.org#197971 +1
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6260u) fdo#104108 +4
pass   -> FAIL   (fi-bxt-dsi)
pass   -> FAIL   (fi-bxt-j4205)
pass   -> FAIL   (fi-kbl-7500u)
pass   -> FAIL   (fi-kbl-7560u)
pass   -> FAIL   (fi-kbl-7567u)
pass   -> FAIL   (fi-kbl-r)
pass   -> FAIL   (fi-glk-1)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144
k.org#197971 https://bugzilla.kernel.org/show_bug.cgi?id=197971
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:255  dwarn:0   dfail:0   fail:3   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:259  dwarn:0   dfail:0   fail:3   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:278s
fi-glk-1 total:288  pass:257  dwarn:0   dfail:0   fail:3   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:260  dwarn:1   dfail:0   fail:3   skip:24  
time:450s
fi-kbl-7560u total:288  pass:266  dwarn:0   dfail:0   fail:3   skip:19  
time:512s
fi-kbl-7567u   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Patchwork]

== Series Details ==

Series: drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
URL   : https://patchwork.freedesktop.org/series/37558/
State : success

== Summary ==

Series 37558v1 drm/i915: Remove spurious DRM_ERROR for cancelled interrupts
https://patchwork.freedesktop.org/api/1.0/series/37558/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:450s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:453s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:503s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

bde4e003ce549b8225142843e0d5aee19dd37d13 drm-tip: 2018y-02m-02d-15h-03m-15s UTC 
integration manifest
eb952eea6b1e drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7864/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset

[Michel Thierry]

On 2/2/2018 6:54 AM, Chris Wilson wrote:

Be paranoid and flush the GTIIR after clearing the CS interrupt to be
sure it has taken before we re-enable the interrupt handler. We still
see early interrupts following reset, the tasklet handling the mmio read
before it has been written by the CS. This hopefully reduces the
frequency to 0...

References: https://bugs.freedesktop.org/show_bug.cgi?id=104262
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 40dbeaee9dfa..deeedfc9fe44 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1527,6 +1527,7 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
  static void reset_irq(struct intel_engine_cs *engine)
  {
struct drm_i915_private *dev_priv = engine->i915;
+   int i;
  
  	/*

 * Clear any pending interrupt state.
@@ -1535,10 +1536,14 @@ static void reset_irq(struct intel_engine_cs *engine)
 * buffered, and if we only reset it once there may still be
 * an interrupt pending.
 */
-   I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
-  GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
-   I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
-  GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
+   for (i = 0; i < 2; i++) {
+   I915_WRITE(GEN8_GT_IIR(gtiir[engine->id]),
+  GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift);
+   POSTING_READ(GEN8_GT_IIR(gtiir[engine->id]));
+   }
+   GEM_BUG_ON(I915_READ(GEN8_GT_IIR(gtiir[engine->id])) &
+  (GT_CONTEXT_SWITCH_INTERRUPT << engine->irq_shift));
+
clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
  }
  



Acked-by: Michel Thierry 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for tools/intel_reg: Fix segfault in intel_reg dump (rev2)

[Patchwork]

== Series Details ==

Series: tools/intel_reg: Fix segfault in intel_reg dump (rev2)
URL   : https://patchwork.freedesktop.org/series/37537/
State : warning

== Summary ==

Test kms_flip_tiling:
Subgroup flip-changes-tiling-yf:
pass   -> FAIL   (shard-apl) fdo#103822
Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb)
Test kms_atomic_transition:
Subgroup plane-all-transition:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Test tools_test:
Subgroup tools_test:
fail   -> PASS   (shard-apl) fdo#104895
Test testdisplay:
pass   -> DMESG-WARN (shard-apl) fdo#104727
Test kms_frontbuffer_tracking:
Subgroup fbc-modesetfrombusy:
pass   -> FAIL   (shard-apl) fdo#103167
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-hsw) fdo#104783
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup in-flight:
fail   -> PASS   (shard-hsw) fdo#104676

fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104895 https://bugs.freedesktop.org/show_bug.cgi?id=104895
fdo#104727 https://bugs.freedesktop.org/show_bug.cgi?id=104727
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#104783 https://bugs.freedesktop.org/show_bug.cgi?id=104783
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676

shard-apltotal:2836 pass:1748 dwarn:2   dfail:0   fail:22  skip:1064 
time:12420s
shard-hswtotal:2836 pass:1733 dwarn:1   dfail:0   fail:11  skip:1090 
time:11766s
shard-snbtotal:2836 pass:1327 dwarn:1   dfail:0   fail:10  skip:1498 
time:6513s
Blacklisted hosts:
shard-kbltotal:2819 pass:1855 dwarn:1   dfail:0   fail:23  skip:939 
time:9284s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_857/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Flush GTIIR on clearing CS interrupts during reset
URL   : https://patchwork.freedesktop.org/series/37552/
State : success

== Summary ==

Series 37552v1 drm/i915/execlists: Flush GTIIR on clearing CS interrupts during 
reset
https://patchwork.freedesktop.org/api/1.0/series/37552/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-guc) fdo#103191

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:574s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:259  dwarn:0   dfail:0   fail:1   skip:28  
time:417s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

bde4e003ce549b8225142843e0d5aee19dd37d13 drm-tip: 2018y-02m-02d-15h-03m-15s UTC 
integration manifest
8f0272654e6b drm/i915/execlists: Flush GTIIR on clearing CS interrupts during 
reset

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7863/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/17] drm/i915/icl: add ICL support to cnl_set_procmon_ref_values

[Paulo Zanoni]

On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.

Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing port A. This way, we'll be able to easily reuse
the function on ICL when we add icl_display_core_init().

v2: Don't use _PICK() when you can use a ternary operator.
v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
Add an extra comment about why we're passing PORT_A (James).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h | 22 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65ba10ad1fe5..f6e1677e8211 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2104,6 +2104,28 @@ enum i915_power_well_id {
 #define CNL_PORT_COMP_DW9  _MMIO(0x162124)
 #define CNL_PORT_COMP_DW10 _MMIO(0x162128)
 
+#define _ICL_PORT_COMP_DW0_A   0x162100
+#define _ICL_PORT_COMP_DW0_B   0x6C100
+#define ICL_PORT_COMP_DW0(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW0_A, \
+_ICL_PORT_COMP_DW0_B)
+#define _ICL_PORT_COMP_DW1_A   0x162104
+#define _ICL_PORT_COMP_DW1_B   0x6C104
+#define ICL_PORT_COMP_DW1(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW1_A, \
+_ICL_PORT_COMP_DW1_B)
+#define _ICL_PORT_COMP_DW3_A   0x16210C
+#define _ICL_PORT_COMP_DW3_B   0x6C10C
+#define ICL_PORT_COMP_DW3(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW3_A, \
+_ICL_PORT_COMP_DW3_B)
+#define _ICL_PORT_COMP_DW9_A   0x162124
+#define _ICL_PORT_COMP_DW9_B   0x6C124
+#define ICL_PORT_COMP_DW9(port)_MMIO_PORT(port, 
_ICL_PORT_COMP_DW9_A, \
+_ICL_PORT_COMP_DW9_B)
+#define _ICL_PORT_COMP_DW10_A  0x162128
+#define _ICL_PORT_COMP_DW10_B  0x6C128
+#define ICL_PORT_COMP_DW10(port)   _MMIO_PORT(port, \
+  _ICL_PORT_COMP_DW10_A, \
+  _ICL_PORT_COMP_DW10_B)
+
 /* BXT PHY Ref registers */
 #define _PORT_REF_DW3_A0x16218C
 #define _PORT_REF_DW3_BC   0x6C18C
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 70e659772a7a..b4ef7875f055 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2794,12 +2794,19 @@ static const struct cnl_procmon {
{ .dw1 = 0x0044, .dw9 = 0x9A00AB25, .dw10 = 0x8AE38FF1, },
 };
 
-static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv)
+/*
+ * CNL has just one set of registers, while ICL has two sets: one for port A 
and
+ * the other for port B. The CNL registers are equivalent to the ICL port A
+ * registers, that's why we call the ICL macros even though the function has 
CNL
+ * on its name.
+ */
+static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv,
+  enum port port)
 {
const struct cnl_procmon *procmon;
u32 val;
 
-   val = I915_READ(CNL_PORT_COMP_DW3);
+   val = I915_READ(ICL_PORT_COMP_DW3(port));
switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) {
default:
MISSING_CASE(val);
@@ -2820,13 +2827,13 @@ static void cnl_set_procmon_ref_values(struct 
drm_i915_private *dev_priv)
break;
}
 
-   val = I915_READ(CNL_PORT_COMP_DW1);
+   val = I915_READ(ICL_PORT_COMP_DW1(port));
val &= ~((0xff << 16) | 0xff);
val |= procmon->dw1;
-   I915_WRITE(CNL_PORT_COMP_DW1, val);
+   I915_WRITE(ICL_PORT_COMP_DW1(port), val);
 
-   I915_WRITE(CNL_PORT_COMP_DW9, procmon->dw9);
-   I915_WRITE(CNL_PORT_COMP_DW10, procmon->dw10);
+   I915_WRITE(ICL_PORT_COMP_DW9(port), procmon->dw9);
+   I915_WRITE(ICL_PORT_COMP_DW10(port), procmon->dw10);
 }
 
 static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool 
resume)
@@ -2847,7 +2854,8 @@ static void cnl_display_core_init(struct drm_i915_private 
*dev_priv, bool resume
val &= ~CNL_COMP_PWR_DOWN;
I915_WRITE(CHICKEN_MISC_2, val);
 
-   cnl_set_procmon_ref_values(dev_priv);
+   /* Dummy PORT_A to get the correct CNL register from the ICL macro */
+   cnl_set_procmon_ref_values(dev_priv, PORT_A);
 
val = I915_READ(CNL_PORT_COMP_DW0);
val |= COMP_INIT;
-- 
2.14.3

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

[Ville Syrjälä]

On Mon, Jan 29, 2018 at 03:47:35PM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
> 
> The problem with at least these Dells is that their VBT defines a MIPI
> ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
> reset in their INIT_OTP sequence, but the deassert must be done before
> calling intel_dsi_device_ready(), so that is too late.
> 
> Simply doing the INIT_OTP sequence earlier is not enough to fix this,
> because the INIT_OTP sequence also sends various MIPI packets to the
> panel, which can only happen after calling intel_dsi_device_ready().
> 
> This commit fixes this by splitting the INIT_OTP sequence into everything
> before the first DSI packet and everything else, including the first DSI
> packet. The first part (everything before the first DSI packet) is then
> used as deassert sequence.
> 
> Changed in v2:
> -Split the init OTP sequence into a deassert reset and the actual init
>  OTP sequence, instead of calling it earlier and then having the first
>  mipi_exec_send_packet() call call intel_dsi_device_ready().
> 
> Changes in v3:
> -Move the whole shebang to intel_bios.c
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880

Bugzilla:

> Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205

References:

> Cc: Jan-Michael Brummer 
> Reported-by: Jan-Michael Brummer 
> Tested-by: Hans de Goede 
> Signed-off-by: Hans de Goede 

This one seems good to me, and Jani hasn't complained about anything so
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 83 
> +++
>  2 files changed, 84 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 081190da0818..1f346266956b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1349,6 +1349,7 @@ struct intel_vbt_data {
>   u32 size;
>   u8 *data;
>   const u8 *sequence[MIPI_SEQ_MAX];
> + u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
>   } dsi;
>  
>   int crt_ddc_pin;
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 64a0d55df28e..cca620f8deb6 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -947,6 +947,86 @@ static int goto_next_sequence_v3(const u8 *data, int 
> index, int total)
>   return 0;
>  }
>  
> +/*
> + * Get len of pre-fixed deassert fragment from a v1 init OTP sequence,
> + * skip all delay + gpio operands and stop at the first DSI packet op.
> + */
> +static int get_init_otp_deassert_fragment_len(struct drm_i915_private 
> *dev_priv)
> +{
> + const u8 *data = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
> + int index, len;
> +
> + if (WARN_ON(!data || dev_priv->vbt.dsi.seq_version != 1))
> + return 0;
> +
> + /* index = 1 to skip sequence byte */
> + for (index = 1; data[index] != MIPI_SEQ_ELEM_END; index += len) {
> + switch (data[index]) {
> + case MIPI_SEQ_ELEM_SEND_PKT:
> + return index == 1 ? 0 : index;
> + case MIPI_SEQ_ELEM_DELAY:
> + len = 5; /* 1 byte for operand + uint32 */
> + break;
> + case MIPI_SEQ_ELEM_GPIO:
> + len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
> + break;
> + default:
> + return 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
> + * The deassert must be done before calling intel_dsi_device_ready, so for
> + * these devices we split the init OTP sequence into a deassert sequence and
> + * the actual init OTP part.
> + */
> +static void fixup_mipi_sequences(struct drm_i915_private *dev_priv)
> +{
> + u8 *init_otp;
> + int len;
> +
> + /* Limit this to VLV for now. */
> + if (!IS_VALLEYVIEW(dev_priv))
> + return;
> +
> + /* Limit this to v1 vid-mode sequences */
> + if (dev_priv->vbt.dsi.config->is_cmd_mode ||
> + dev_priv->vbt.dsi.seq_version != 1)
> + return;
> +
> + /* Only do this if there are otp and assert seqs and no deassert seq */
> + if (!dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP] ||
> + !dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] ||
> + dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET])
> + return;
> +
> + /* The deassert-sequence ends at the first DSI packet */
> + len 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/crc: Add support for polling on the data fd.

[Patchwork]

== Series Details ==

Series: drm/crc: Add support for polling on the data fd.
URL   : https://patchwork.freedesktop.org/series/37550/
State : warning

== Summary ==

Series 37550v1 drm/crc: Add support for polling on the data fd.
https://patchwork.freedesktop.org/api/1.0/series/37550/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-guc)
Subgroup basic-s4-devices:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:464s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:570s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:412s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

bde4e003ce549b8225142843e0d5aee19dd37d13 drm-tip: 2018y-02m-02d-15h-03m-15s UTC 
integration manifest
507e2c4c0b73 drm/crc: Add support for polling on the data fd.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7862/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Free memdup-ed bios data structures on driver_unload

[Ville Syrjälä]

On Mon, Jan 29, 2018 at 03:47:34PM +0100, Hans de Goede wrote:
> Add a new intel_bios_cleanup function to free memdup-ed bios data
> structures and call it from i915_driver_unload().
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  2 ++
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 11 +++
>  3 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1ec12add34b2..4ecf41724183 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1437,6 +1437,8 @@ void i915_driver_unload(struct drm_device *dev)
>  
>   intel_modeset_cleanup(dev);
>  
> + intel_bios_cleanup(dev_priv);
> +
>   /*
>* free the memory space allocated for the child device
>* config parsed from VBT

Looks like there's already a bunch of VBT related cleanup just below.
Maybe that should be sucked into the new cleanup function as well?

> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 454d8f937fae..081190da0818 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3663,6 +3663,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
> *dev_priv);
>  
>  /* intel_bios.c */
>  void intel_bios_init(struct drm_i915_private *dev_priv);
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
>  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 95f0b310d656..64a0d55df28e 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1588,6 +1588,17 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
>   pci_unmap_rom(pdev, bios);
>  }
>  
> +/**
> + * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
> + * @dev_priv: i915 device instance
> + */
> +void intel_bios_cleanup(struct drm_i915_private *dev_priv)
> +{
> + kfree(dev_priv->vbt.dsi.data);
> + kfree(dev_priv->vbt.dsi.pps);
> + kfree(dev_priv->vbt.dsi.config);
> +}
> +
>  /**
>   * intel_bios_is_tv_present - is integrated TV present in VBT
>   * @dev_priv:i915 device instance
> -- 
> 2.14.3

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with disable-gem-trace (rev3)

[Patchwork]

== Series Details ==

Series: series starting with disable-gem-trace (rev3)
URL   : https://patchwork.freedesktop.org/series/37473/
State : failure

== Summary ==

Test kms_flip:
Subgroup 2x-flip-vs-blocking-wf-vblank:
pass   -> FAIL   (shard-hsw)
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test perf_pmu:
Subgroup interrupts-sync:
pass   -> FAIL   (shard-apl) fdo#104485
Test kms_vblank:
Subgroup pipe-a-ts-continuation-suspend:
fail   -> PASS   (shard-hsw) fdo#104783
Test kms_atomic_transition:
Subgroup plane-all-transition:
skip   -> PASS   (shard-snb)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#104485 https://bugs.freedesktop.org/show_bug.cgi?id=104485
fdo#104783 https://bugs.freedesktop.org/show_bug.cgi?id=104783

shard-apltotal:2836 pass:1749 dwarn:1   dfail:0   fail:22  skip:1064 
time:12388s
shard-hswtotal:2836 pass:1731 dwarn:1   dfail:0   fail:13  skip:1090 
time:11642s
shard-snbtotal:2836 pass:1328 dwarn:1   dfail:0   fail:10  skip:1497 
time:6456s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7861/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Ville Syrjälä]

On Fri, Feb 02, 2018 at 03:34:48PM +, Chris Wilson wrote:
> As we ourselves cancel interrupts during reset by clearing the GTIIR, it
> is possible for the master IIR to indicate a pending IRQ for which we
> have already cleared from the GTIIR. In this case, the DRM_ERROR are
> intended and should not be flagged as an error.

I guess an alternative would be to not clear IIR and use
sychronize_irq() instead as needed. But I suppose that doesn't
really provide any real benefits.

One concern is that we will now claim that all interrupts are handled,
and thus couldn't detect spurious interrupts. But one might hope that
MSI and whanot has made those a thing of the past.

I never checked what the kernel's threshold was for disabling the
interrupt line on spurious interrupts. I have occasionally thought about
it though as I too have realized that the IIR clearing could result in
the interrupt handler having nothing to do.

So yeah, not quite sure which is best, always claiming IRQ_HANDLED or
only when we had some IIR bits to clear. Maybe just return IRQ_HANDLED
always for all MSI capable platforms?

Ramblings aside, I think this should be safe enough:
Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 
> Cc: Ville Syrjälä 
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 35 +--
>  1 file changed, 9 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 252feff2892d..b886bd459acc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1413,37 +1413,25 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, 
> u32 iir, int test_shift)
>   tasklet_hi_schedule(>tasklet);
>  }
>  
> -static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> -u32 master_ctl,
> -u32 gt_iir[4])
> +static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
> + u32 master_ctl, u32 gt_iir[4])
>  {
> - irqreturn_t ret = IRQ_NONE;
> -
>   if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
>   gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0));
> - if (gt_iir[0]) {
> + if (gt_iir[0])
>   I915_WRITE_FW(GEN8_GT_IIR(0), gt_iir[0]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT0)!\n");
>   }
>  
>   if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
>   gt_iir[1] = I915_READ_FW(GEN8_GT_IIR(1));
> - if (gt_iir[1]) {
> + if (gt_iir[1])
>   I915_WRITE_FW(GEN8_GT_IIR(1), gt_iir[1]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT1)!\n");
>   }
>  
>   if (master_ctl & GEN8_GT_VECS_IRQ) {
>   gt_iir[3] = I915_READ_FW(GEN8_GT_IIR(3));
> - if (gt_iir[3]) {
> + if (gt_iir[3])
>   I915_WRITE_FW(GEN8_GT_IIR(3), gt_iir[3]);
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (GT3)!\n");
>   }
>  
>   if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
> @@ -1453,12 +1441,8 @@ static irqreturn_t gen8_gt_irq_ack(struct 
> drm_i915_private *dev_priv,
>   I915_WRITE_FW(GEN8_GT_IIR(2),
> gt_iir[2] & (dev_priv->pm_rps_events |
>  dev_priv->pm_guc_events));
> - ret = IRQ_HANDLED;
> - } else
> - DRM_ERROR("The master control interrupt lied (PM)!\n");
> + }
>   }
> -
> - return ret;
>  }
>  
>  static void gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
> @@ -2695,7 +2679,6 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   u32 master_ctl;
>   u32 gt_iir[4] = {};
> - irqreturn_t ret;
>  
>   if (!intel_irqs_enabled(dev_priv))
>   return IRQ_NONE;
> @@ -2711,16 +2694,16 @@ static irqreturn_t gen8_irq_handler(int irq, void 
> *arg)
>   disable_rpm_wakeref_asserts(dev_priv);
>  
>   /* Find, clear, then process each source of interrupt */
> - ret = gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
> + gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
>   gen8_gt_irq_handler(dev_priv, gt_iir);
> - ret |= gen8_de_irq_handler(dev_priv, master_ctl);
> + gen8_de_irq_handler(dev_priv, master_ctl);
>  
>   

Re: [Intel-gfx] clang warning: implicit conversion in intel_ddi.c:1481

[Greg KH]

On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> On Fri, 02 Feb 2018, Greg KH  wrote:
> > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> >> 
> >> +Knut, Fengguang
> >> 
> >> On Fri, 02 Feb 2018, Greg KH  wrote:
> >> >  - If clang now builds the kernel "cleanly", yes, I want to take
> >> >warning fixes in the stable tree.  And even better yet, if you
> >> >keep working to ensure the tree is "clean", that would be
> >> >wonderful.
> >> 
> >> So we can run sparse using 'make C=1' and friends, or other static
> >> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> >> line params work. There was work by Knut to extend this make checker
> >> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> >> like a bad idea, I wonder how hard it would be to make clang work like
> >> this:
> >> 
> >> $ make CHECK=clang C=1
> >> 
> >> Or using Knut's wrapper. Feels like that could increase the use of clang
> >> for static analysis of patches.
> >
> > Why not just build with clang itself:
> > make CC=clang
> 
> Same as HOSTCC, mixing different CC's in a single build dir seems like a
> bad idea. Sure, everyone can setup a separate build dir for clang, but
> IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.

"O=some_output_dir" is your friend.  If you aren't doing that already
for your test builds, you don't know what you are missing :)

thanks,

greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Detect panel's hdcp capability

[Sean Paul]

On Fri, Feb 02, 2018 at 08:08:44PM +0530, Ramalingam C wrote:
> 
> 
> On Friday 02 February 2018 07:54 PM, Sean Paul wrote:
> > On Fri, Feb 02, 2018 at 04:15:18PM +0530, Ramalingam C wrote:
> > > As a first step of HDCP authentication detects the panel's HDCP
> > > capability. This is mandated for DP HDCP1.4.
> > > 
> > > For DP 0th Bit of Bcaps register indicates the panel's hdcp capability
> > > For HDMI valid BKSV indicates the panel's hdcp capability.
> > We're already checking valid bksv, so there's no need to expose that 
> > function and
> > call it twice for the HDMI case, hdcp_capable should just always be true.
> we can make the hdmi's hdcp_capable as dummy. As hdcp1.4 spec for hdmi says
> panel's capability is determined by valid bksv.
> Which we are already doing it. no sequence mandated.
> > 
> > For DP, we read and check the bksv , so what do non-capable displays return 
> > for
> > the bksv?
> But for DP HDCP1.4 spec mandates that An write should entertained only after
> verifying the 0th bit(hdcp_capable) of BCSPS register.
> Else all DP compliance tests will fail :(
> 
> We are not addressing any functional issue but deviation from the HDCP1.4
> spec for DP.

Hmm, that's lame. Could you please add this to the commit message so that it's
clear that BCAPS must be checked before An is written?

> 
> --Ram
> > 
> > Sean
> > 
> > > Signed-off-by: Ramalingam C 
> > > ---
> > >   drivers/gpu/drm/i915/intel_dp.c   | 19 +++
> > >   drivers/gpu/drm/i915/intel_drv.h  |  5 +
> > >   drivers/gpu/drm/i915/intel_hdcp.c | 10 --
> > >   drivers/gpu/drm/i915/intel_hdmi.c | 17 +
> > >   4 files changed, 49 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 03d86ff9b805..2623b2beda1a 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5218,6 +5218,24 @@ bool intel_dp_hdcp_check_link(struct 
> > > intel_digital_port *intel_dig_port)
> > >   return !(bstatus & (DP_BSTATUS_LINK_FAILURE | 
> > > DP_BSTATUS_REAUTH_REQ));
> > >   }
> > > +static
> > > +int intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
> > > +   bool *hdcp_capable)
> > > +{
> > > + ssize_t ret;
> > > + u8 bcaps;
> > > +
> > > + ret = drm_dp_dpcd_read(_dig_port->dp.aux, DP_AUX_HDCP_BCAPS,
> > > +, 1);
> > > + if (ret != 1) {
> > > + DRM_ERROR("Read bcaps from DP/AUX failed (%zd)\n", ret);
> > > + return ret >= 0 ? -EIO : ret;
> > > + }

This is duplicated in repeater_present. Please pull it out into a helper
function.


> > > +
> > > + *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
> > > + return 0;
> > > +}
> > > +
> > >   static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> > >   .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> > >   .read_bksv = intel_dp_hdcp_read_bksv,
> > > @@ -5229,6 +5247,7 @@ static const struct intel_hdcp_shim 
> > > intel_dp_hdcp_shim = {
> > >   .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> > >   .toggle_signalling = intel_dp_hdcp_toggle_signalling,
> > >   .check_link = intel_dp_hdcp_check_link,
> > > + .hdcp_capable = intel_dp_hdcp_capable,
> > >   };
> > >   static void intel_edp_panel_vdd_sanitize(struct intel_dp *intel_dp)
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index d6a808374dfb..409aee9010ba 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -369,6 +369,10 @@ struct intel_hdcp_shim {
> > >   /* Ensures the link is still protected */
> > >   bool (*check_link)(struct intel_digital_port *intel_dig_port);
> > > +
> > > + /* Detects panel's hdcp capablility */

s/capablility/capability/

Also mention that this is optional for HDMI.


> > > + int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> > > + bool *hdcp_capable);
> > >   };
> > >   struct intel_connector {
> > > @@ -1848,6 +1852,7 @@ int intel_hdcp_enable(struct intel_connector 
> > > *connector);
> > >   int intel_hdcp_disable(struct intel_connector *connector);
> > >   int intel_hdcp_check_link(struct intel_connector *connector);
> > >   bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port 
> > > port);
> > > +bool intel_hdcp_is_ksv_valid(u8 *ksv);
> > >   /* intel_psr.c */
> > >   #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && 
> > > dev_priv->psr.sink_support)
> > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > index 5de9afd275b2..a3463557f0f6 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > @@ -132,7 +132,6 @@ u32 intel_hdcp_get_repeater_ctl(struct 
> > > intel_digital_port *intel_dig_port)
> > >   return -EINVAL;
> > >   }

[Intel-gfx] [PATCH] drm/i915: Remove spurious DRM_ERROR for cancelled interrupts

[Chris Wilson]

As we ourselves cancel interrupts during reset by clearing the GTIIR, it
is possible for the master IIR to indicate a pending IRQ for which we
have already cleared from the GTIIR. In this case, the DRM_ERROR are
intended and should not be flagged as an error.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_irq.c | 35 +--
 1 file changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 252feff2892d..b886bd459acc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1413,37 +1413,25 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
tasklet_hi_schedule(>tasklet);
 }
 
-static irqreturn_t gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
-  u32 master_ctl,
-  u32 gt_iir[4])
+static void gen8_gt_irq_ack(struct drm_i915_private *dev_priv,
+   u32 master_ctl, u32 gt_iir[4])
 {
-   irqreturn_t ret = IRQ_NONE;
-
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0));
-   if (gt_iir[0]) {
+   if (gt_iir[0])
I915_WRITE_FW(GEN8_GT_IIR(0), gt_iir[0]);
-   ret = IRQ_HANDLED;
-   } else
-   DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
 
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
gt_iir[1] = I915_READ_FW(GEN8_GT_IIR(1));
-   if (gt_iir[1]) {
+   if (gt_iir[1])
I915_WRITE_FW(GEN8_GT_IIR(1), gt_iir[1]);
-   ret = IRQ_HANDLED;
-   } else
-   DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
 
if (master_ctl & GEN8_GT_VECS_IRQ) {
gt_iir[3] = I915_READ_FW(GEN8_GT_IIR(3));
-   if (gt_iir[3]) {
+   if (gt_iir[3])
I915_WRITE_FW(GEN8_GT_IIR(3), gt_iir[3]);
-   ret = IRQ_HANDLED;
-   } else
-   DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
 
if (master_ctl & (GEN8_GT_PM_IRQ | GEN8_GT_GUC_IRQ)) {
@@ -1453,12 +1441,8 @@ static irqreturn_t gen8_gt_irq_ack(struct 
drm_i915_private *dev_priv,
I915_WRITE_FW(GEN8_GT_IIR(2),
  gt_iir[2] & (dev_priv->pm_rps_events |
   dev_priv->pm_guc_events));
-   ret = IRQ_HANDLED;
-   } else
-   DRM_ERROR("The master control interrupt lied (PM)!\n");
+   }
}
-
-   return ret;
 }
 
 static void gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
@@ -2695,7 +2679,6 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
struct drm_i915_private *dev_priv = to_i915(dev);
u32 master_ctl;
u32 gt_iir[4] = {};
-   irqreturn_t ret;
 
if (!intel_irqs_enabled(dev_priv))
return IRQ_NONE;
@@ -2711,16 +2694,16 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
disable_rpm_wakeref_asserts(dev_priv);
 
/* Find, clear, then process each source of interrupt */
-   ret = gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
+   gen8_gt_irq_ack(dev_priv, master_ctl, gt_iir);
gen8_gt_irq_handler(dev_priv, gt_iir);
-   ret |= gen8_de_irq_handler(dev_priv, master_ctl);
+   gen8_de_irq_handler(dev_priv, master_ctl);
 
I915_WRITE_FW(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
POSTING_READ_FW(GEN8_MASTER_IRQ);
 
enable_rpm_wakeref_asserts(dev_priv);
 
-   return ret;
+   return IRQ_HANDLED;
 }
 
 struct wedge_me {
-- 
2.15.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Ramalingam C]

On Friday 02 February 2018 08:52 PM, Sean Paul wrote:

On Fri, Feb 2, 2018 at 9:51 AM, Ramalingam C  wrote:


On Friday 02 February 2018 08:15 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:


On Friday 02 February 2018 07:39 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 04:15:13PM +0530, Ramalingam C wrote:

We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.

This patch handles above requirement.

For reusing the _intel_hdcp_disable from generic authentication flow,
this patch retain the reference to connector till the generic hdcp
flow.
This will be handy to provide the connector details in HDCP enable
debug info.

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/intel_hdcp.c | 41
+++
1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b97184eccd9c..0021511ae4d7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -16,6 +16,8 @@
#define KEY_LOAD_TRIES   5
+static int _intel_hdcp_disable(struct intel_connector *connector);
+
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
*intel_dig_port,
 const struct intel_hdcp_shim *shim)
{
@@ -138,17 +140,24 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
 return true;
}
+static
+struct intel_digital_port *conn_to_dig_port(struct intel_connector
*connector)
+{
+   return enc_to_dig_port(>encoder->base);
+}
+
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
{
 struct drm_i915_private *dev_priv;
 u32 vprime, sha_text, sha_leftovers, rep_ctl;
 u8 bstatus[2], num_downstream, *ksv_fifo;
 int ret, i, j, sha_idx;
+   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
+   struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
-   dev_priv = intel_dig_port->base.base.dev->dev_private;
+   dev_priv = to_i915(connector->base.dev);
 ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
 if (ret) {
@@ -385,8 +394,7 @@ int intel_hdcp_auth_downstream(struct
intel_digital_port *intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
 struct drm_i915_private *dev_priv;
 enum port port;
@@ -405,9 +413,10 @@ static int intel_hdcp_auth(struct
intel_digital_port *intel_dig_port,
 u8 shim[DRM_HDCP_RI_LEN];
 } ri;
 bool repeater_present;
+   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
+   struct intel_digital_port *intel_dig_port =
conn_to_dig_port(connector);
-   dev_priv = intel_dig_port->base.base.dev->dev_private;
-
+   dev_priv = to_i915(connector->base.dev);
 port = intel_dig_port->base.port;
 /* Initialize An with 2 random values and acquire it */
@@ -498,19 +507,18 @@ static int intel_hdcp_auth(struct
intel_digital_port *intel_dig_port,
  * on those as well.
  */
-   if (repeater_present)
-   return intel_hdcp_auth_downstream(intel_dig_port,
shim);
+   if (repeater_present) {
+   ret = intel_hdcp_auth_downstream(connector);
+   if (ret) {
+   _intel_hdcp_disable(connector);

If you just call this from _intel_hdcp_enable when intel_hdcp_auth()
fails, you
can avoid all of this code, it'd just be one line.

Yes. Thought about that option too. Actually I would prefer having the
reference of intel_connector untill generic hdcp auth implementation.
we can pass the intel digital port for encoder specific shims.

This will help me with
  providing the connector details for state transitions as in next
patches
  next steps like SRM passing in for revocation and downstream
topology
gathering (perhaps will start with availability of complementing user
space)

At this point if we dont want this code, I will disable hdcp from enable
functions.

Yes please. Let's not try to predict the future and keep things as simple
as
possible.

Sean

but patch 3(adding connector info into hdcp state transition debug logs)
still needs conenctor ref at auth.
Do we still want to drop the connector ref passing? If so we will lose patch
3 too.

I was thinking about this further, and it doesn't really make sense to
change some of the 

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Optimize HDCP key load

[Sean Paul]

On Fri, Feb 2, 2018 at 9:33 AM, Ramalingam C  wrote:
>
>
> On Friday 02 February 2018 07:48 PM, Sean Paul wrote:
>>
>> On Fri, Feb 02, 2018 at 04:15:17PM +0530, Ramalingam C wrote:
>>>
>>> HDCP key need not be cleared on each hdcp disable. And HDCP key Load
>>> is skipped if key is already loaded.
>>>
>> I had previously encountered issues without clearing the key in my
>> testing.
>> IIRC, without clearing the keys things acted differently. How much time
>> are we
>> saving by optimizing this?
>>
>> Sean
>
> Time profiling is not done. As per the Bspec, Once Keys are loaded, they
> will be cleared only when PG1/PG0 is off.
> So on Resume we need to load the keys. Since we have the status register for
> key load state, I feel we could rely on them.
>
> Now with our code state, I am not seeing the need for reloading the keys. I
> have tested on KBL.
> I think this is worth an attempt as no failures are observed.
>

Alright, sounds good to me, thanks for explaining!

Reviewed-by: Sean Paul 



> --Ram
>
>>
>>
>>> Signed-off-by: Ramalingam C 
>>> ---
>>>   drivers/gpu/drm/i915/intel_hdcp.c | 6 --
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>>> b/drivers/gpu/drm/i915/intel_hdcp.c
>>> index fa2e7c727d00..5de9afd275b2 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdcp.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
>>> @@ -51,6 +51,10 @@ static int intel_hdcp_load_keys(struct
>>> drm_i915_private *dev_priv)
>>> int ret;
>>> u32 val;
>>>   + val = I915_READ(HDCP_KEY_STATUS);
>>> +   if ((val & HDCP_KEY_LOAD_DONE) && (val & HDCP_KEY_LOAD_STATUS))
>>> +   return 0;
>>> +
>>> /*
>>>  * On HSW and BDW HW loads the HDCP1.4 Key when Display comes
>>>  * out of reset. So if Key is not already loaded, its an error
>>> state.
>>> @@ -542,8 +546,6 @@ static int _intel_hdcp_disable(struct intel_connector
>>> *connector)
>>> return -ETIMEDOUT;
>>> }
>>>   - intel_hdcp_clear_keys(dev_priv);
>>> -
>>> ret = connector->hdcp_shim->toggle_signalling(intel_dig_port,
>>> false);
>>> if (ret) {
>>> DRM_ERROR("Failed to disable HDCP signalling\n");
>>> --
>>> 2.7.4
>>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Sean Paul]

On Fri, Feb 2, 2018 at 9:51 AM, Ramalingam C  wrote:
>
>
> On Friday 02 February 2018 08:15 PM, Sean Paul wrote:
>>
>> On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:
>>>
>>>
>>> On Friday 02 February 2018 07:39 PM, Sean Paul wrote:

 On Fri, Feb 02, 2018 at 04:15:13PM +0530, Ramalingam C wrote:
>
> We enable the HDCP encryption as a part of first stage authentication.
> So when second stage authentication fails, we need to disable the HDCP
> encryption and signalling.
>
> This patch handles above requirement.
>
> For reusing the _intel_hdcp_disable from generic authentication flow,
> this patch retain the reference to connector till the generic hdcp
> flow.
> This will be handy to provide the connector details in HDCP enable
> debug info.
>
> Signed-off-by: Ramalingam C 
> ---
>drivers/gpu/drm/i915/intel_hdcp.c | 41
> +++
>1 file changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index b97184eccd9c..0021511ae4d7 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -16,6 +16,8 @@
>#define KEY_LOAD_TRIES   5
> +static int _intel_hdcp_disable(struct intel_connector *connector);
> +
>static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> *intel_dig_port,
> const struct intel_hdcp_shim *shim)
>{
> @@ -138,17 +140,24 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
> return true;
>}
> +static
> +struct intel_digital_port *conn_to_dig_port(struct intel_connector
> *connector)
> +{
> +   return enc_to_dig_port(>encoder->base);
> +}
> +
>/* Implements Part 2 of the HDCP authorization procedure */
>static
> -int intel_hdcp_auth_downstream(struct intel_digital_port
> *intel_dig_port,
> -  const struct intel_hdcp_shim *shim)
> +int intel_hdcp_auth_downstream(struct intel_connector *connector)
>{
> struct drm_i915_private *dev_priv;
> u32 vprime, sha_text, sha_leftovers, rep_ctl;
> u8 bstatus[2], num_downstream, *ksv_fifo;
> int ret, i, j, sha_idx;
> +   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
> +   struct intel_digital_port *intel_dig_port =
> conn_to_dig_port(connector);
> -   dev_priv = intel_dig_port->base.base.dev->dev_private;
> +   dev_priv = to_i915(connector->base.dev);
> ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
> if (ret) {
> @@ -385,8 +394,7 @@ int intel_hdcp_auth_downstream(struct
> intel_digital_port *intel_dig_port,
>}
>/* Implements Part 1 of the HDCP authorization procedure */
> -static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> -  const struct intel_hdcp_shim *shim)
> +static int intel_hdcp_auth(struct intel_connector *connector)
>{
> struct drm_i915_private *dev_priv;
> enum port port;
> @@ -405,9 +413,10 @@ static int intel_hdcp_auth(struct
> intel_digital_port *intel_dig_port,
> u8 shim[DRM_HDCP_RI_LEN];
> } ri;
> bool repeater_present;
> +   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
> +   struct intel_digital_port *intel_dig_port =
> conn_to_dig_port(connector);
> -   dev_priv = intel_dig_port->base.base.dev->dev_private;
> -
> +   dev_priv = to_i915(connector->base.dev);
> port = intel_dig_port->base.port;
> /* Initialize An with 2 random values and acquire it */
> @@ -498,19 +507,18 @@ static int intel_hdcp_auth(struct
> intel_digital_port *intel_dig_port,
>  * on those as well.
>  */
> -   if (repeater_present)
> -   return intel_hdcp_auth_downstream(intel_dig_port,
> shim);
> +   if (repeater_present) {
> +   ret = intel_hdcp_auth_downstream(connector);
> +   if (ret) {
> +   _intel_hdcp_disable(connector);

 If you just call this from _intel_hdcp_enable when intel_hdcp_auth()
 fails, you
 can avoid all of this code, it'd just be one line.
>>>
>>> Yes. Thought about that option too. Actually I would prefer having the
>>> reference of intel_connector untill generic hdcp auth implementation.
>>> we can pass the intel digital port for encoder specific shims.
>>>
>>> This will help me with
>>>  providing the connector details for state transitions as in next
>>> patches
>>>  next steps like SRM passing in for revocation and downstream

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Stop encryption for repeater with no sink

[Sean Paul]

On Fri, Feb 02, 2018 at 08:33:38PM +0530, Ramalingam C wrote:
> 
> 
> On Friday 02 February 2018 08:18 PM, Sean Paul wrote:
> > On Fri, Feb 02, 2018 at 07:42:47PM +0530, Ramalingam C wrote:
> > > 
> > > On Friday 02 February 2018 07:43 PM, Sean Paul wrote:
> > > > On Fri, Feb 02, 2018 at 04:15:14PM +0530, Ramalingam C wrote:
> > > > > If a HDCP repeater is detected with zero hdcp authenticated
> > > > > downstream devices, there are two option as below:
> > > > > 
> > > > > 1. Dont continue on second stage authentication. Disable encryption.
> > > > > 2. Continue with second stage authentication excluding the KSV list 
> > > > > and
> > > > >  continue encryption on success.
> > > > > 
> > > > > This patch adopts the option 1.
> > > > It doesn't seem that hard to adopt option 2 and avoid failure. That 
> > > > would result
> > > > in a better experience.
> > > True. Not too much effort for option 2. But I am not seeing any ROI out of
> > > it at this point.
> > > what is the benefit of encrypting if repeater cant use it, as it has 0 
> > > sinks
> > > attached to it.
> > > Still do we want option two?
> > Is it possible the repeater itself has video output? I'm also worried about
> > non-compliant displays which may report having a repeater. If these aren't
> > possible, I agree. Just beef up the comment like "If there are no downstream
> > devices, spec requires we disable all encryption. So fail here to ensure 
> > hdcp is
> > disabled"
> > 
> > Sean
> 
> When spec provide an option that we can disable the HDCP encryption incase
> of repeater with device count 0, that means repeaters cant have display.
> 
> Display which claims to be a repeater, mostly wont pass the second stage
> authentication meant for repeaters. So we need not worry about them.
> 
> Sure as you mentioned i will rephrase the commit message with these 
> informations.

Not just the commit message. Please also update the comment in the code so it's
clear.

Sean

> 
> --Ram
> 
> > 
> > > -Ram
> > > > > Signed-off-by: Ramalingam C 
> > > > > ---
> > > > >drivers/gpu/drm/i915/intel_hdcp.c | 4 ++--
> > > > >1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> > > > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > > index 0021511ae4d7..182a3c8a4e4a 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > > @@ -175,10 +175,10 @@ int intel_hdcp_auth_downstream(struct 
> > > > > intel_connector *connector)
> > > > >   return -EPERM;
> > > > >   }
> > > > > - /* If there are no downstream devices, we're all done. */
> > > > > + /* If there are no downstream devices, we're not encrypting. */
> > > > >   num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
> > > > >   if (num_downstream == 0)
> > > > > - return 0;
> > > > > + return -EINVAL;
> > > > >   ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, 
> > > > > GFP_KERNEL);
> > > > >   if (!ksv_fifo)
> > > > > -- 
> > > > > 2.7.4
> > > > > 
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Reauthenticate HDCP on failure

[Ramalingam C]

On Friday 02 February 2018 08:07 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 04:15:19PM +0530, Ramalingam C wrote:

When HDCP authentication fails, we add two more reauthentication.
This will address all reauth expectation from compliance perspective.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_hdcp.c | 18 +++---
  1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index a3463557f0f6..3caa548a9cad 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -566,7 +566,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
  static int _intel_hdcp_enable(struct intel_connector *connector)
  {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
-   int i, ret;
+   int i, ret, reauth = 1;
  
  	if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {

DRM_ERROR("PG1 is disabled, cannot load keys\n");
@@ -584,13 +584,17 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
return ret;
}
  
-	ret = intel_hdcp_auth(connector);

-   if (ret) {
-   DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
-   return ret;
-   }
+   do {
+   ret = intel_hdcp_auth(connector);
+   if (ret)
+   DRM_ERROR("Failed to authenticate HDCP (%d)\n", ret);
+   if (ret && reauth)
+   DRM_DEBUG_KMS("[%s:%d] HDCP Reauth... %d/1\n",
+   connector->base.name,
+   connector->base.base.id, reauth);
+   } while (ret && reauth--);
  
-	return 0;

+   return ret;


I think we can do something a little more straightforward, like:

 int i, ret, tries = 2;

 for (i = 0; i < tries; i++) {
 ret = intel_hdcp_auth(...);
 if (!ret)
 return 0;

 DRM_DEBUG_KMS("[%s:%d] HDCP Auth failure (%d)\n",
   connector->base.name, connector->base.base.id,
   ret);
 }

 DRM_ERROR("[%s:%d] HDCP authentication failed (%d tries/%d)\n",
   connector->base.name, connector->base.base.id, tries, ret);
 _intel_hdcp_disable(...);
 return ret;


Sure. I will do it.

-Ram

  }
  
  static void intel_hdcp_check_work(struct work_struct *work)

--
2.7.4



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Stop encryption for repeater with no sink

[Ramalingam C]

On Friday 02 February 2018 08:18 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 07:42:47PM +0530, Ramalingam C wrote:


On Friday 02 February 2018 07:43 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 04:15:14PM +0530, Ramalingam C wrote:

If a HDCP repeater is detected with zero hdcp authenticated
downstream devices, there are two option as below:

1. Dont continue on second stage authentication. Disable encryption.
2. Continue with second stage authentication excluding the KSV list and
 continue encryption on success.

This patch adopts the option 1.

It doesn't seem that hard to adopt option 2 and avoid failure. That would result
in a better experience.

True. Not too much effort for option 2. But I am not seeing any ROI out of
it at this point.
what is the benefit of encrypting if repeater cant use it, as it has 0 sinks
attached to it.
Still do we want option two?

Is it possible the repeater itself has video output? I'm also worried about
non-compliant displays which may report having a repeater. If these aren't
possible, I agree. Just beef up the comment like "If there are no downstream
devices, spec requires we disable all encryption. So fail here to ensure hdcp is
disabled"

Sean


When spec provide an option that we can disable the HDCP encryption incase
of repeater with device count 0, that means repeaters cant have display.

Display which claims to be a repeater, mostly wont pass the second stage
authentication meant for repeaters. So we need not worry about them.

Sure as you mentioned i will rephrase the commit message with these 
informations.

--Ram




-Ram

Signed-off-by: Ramalingam C 
---
   drivers/gpu/drm/i915/intel_hdcp.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 0021511ae4d7..182a3c8a4e4a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -175,10 +175,10 @@ int intel_hdcp_auth_downstream(struct intel_connector 
*connector)
return -EPERM;
}
-   /* If there are no downstream devices, we're all done. */
+   /* If there are no downstream devices, we're not encrypting. */
num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
if (num_downstream == 0)
-   return 0;
+   return -EINVAL;
ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
if (!ksv_fifo)
--
2.7.4



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Handle failure from 2nd stage HDCP auth

[Ramalingam C]

On Friday 02 February 2018 08:15 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 07:52:24PM +0530, Ramalingam C wrote:


On Friday 02 February 2018 07:39 PM, Sean Paul wrote:

On Fri, Feb 02, 2018 at 04:15:13PM +0530, Ramalingam C wrote:

We enable the HDCP encryption as a part of first stage authentication.
So when second stage authentication fails, we need to disable the HDCP
encryption and signalling.

This patch handles above requirement.

For reusing the _intel_hdcp_disable from generic authentication flow,
this patch retain the reference to connector till the generic hdcp flow.
This will be handy to provide the connector details in HDCP enable
debug info.

Signed-off-by: Ramalingam C 
---
   drivers/gpu/drm/i915/intel_hdcp.c | 41 
+++
   1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index b97184eccd9c..0021511ae4d7 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -16,6 +16,8 @@
   #define KEY_LOAD_TRIES   5
+static int _intel_hdcp_disable(struct intel_connector *connector);
+
   static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port 
*intel_dig_port,
const struct intel_hdcp_shim *shim)
   {
@@ -138,17 +140,24 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
return true;
   }
+static
+struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
+{
+   return enc_to_dig_port(>encoder->base);
+}
+
   /* Implements Part 2 of the HDCP authorization procedure */
   static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
   {
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, j, sha_idx;
+   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
-   dev_priv = intel_dig_port->base.base.dev->dev_private;
+   dev_priv = to_i915(connector->base.dev);
ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
if (ret) {
@@ -385,8 +394,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
   }
   /* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
   {
struct drm_i915_private *dev_priv;
enum port port;
@@ -405,9 +413,10 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
u8 shim[DRM_HDCP_RI_LEN];
} ri;
bool repeater_present;
+   const struct intel_hdcp_shim *shim = connector->hdcp_shim;
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
-   dev_priv = intel_dig_port->base.base.dev->dev_private;
-
+   dev_priv = to_i915(connector->base.dev);
port = intel_dig_port->base.port;
/* Initialize An with 2 random values and acquire it */
@@ -498,19 +507,18 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 * on those as well.
 */
-   if (repeater_present)
-   return intel_hdcp_auth_downstream(intel_dig_port, shim);
+   if (repeater_present) {
+   ret = intel_hdcp_auth_downstream(connector);
+   if (ret) {
+   _intel_hdcp_disable(connector);

If you just call this from _intel_hdcp_enable when intel_hdcp_auth() fails, you
can avoid all of this code, it'd just be one line.

Yes. Thought about that option too. Actually I would prefer having the
reference of intel_connector untill generic hdcp auth implementation.
we can pass the intel digital port for encoder specific shims.

This will help me with
     providing the connector details for state transitions as in next patches
     next steps like SRM passing in for revocation and downstream topology
gathering (perhaps will start with availability of complementing user space)

At this point if we dont want this code, I will disable hdcp from enable
functions.

Yes please. Let's not try to predict the future and keep things as simple as
possible.

Sean
but patch 3(adding connector info into hdcp state transition debug logs) 
still needs conenctor ref at auth.
Do we still want to drop the connector ref passing? If so we will lose 
patch 3 too.


-Ram




-Ram



+   return ret;
+   }
+   }
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
   }
-static
-struct intel_digital_port *conn_to_dig_port(struct intel_connector