[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: Disable automatic GuC firmware loading

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Disable automatic GuC firmware loading
URL   : https://patchwork.freedesktop.org/series/7577/
State : failure

== Summary ==

Series 7577v1 drm/i915/guc: Disable automatic GuC firmware loading
http://patchwork.freedesktop.org/api/1.0/series/7577/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> DMESG-WARN (ro-byt-n2820)
Test gem_busy:
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_flush:
Subgroup basic-wb-rw-default:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_suspend:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-bdw-i7-5600u)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (ro-skl-i7-6700hq)
Subgroup basic-rte:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:179  dwarn:0   dfail:0   fail:2   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:1   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:175  dwarn:8   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_981/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
2961287 drm/i915/guc: Disable automatic GuC firmware loading

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

Re: [Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.

[Ander Conselvan De Oliveira]

On Mon, 2016-05-23 at 10:42 -0700, Jim Bride wrote:
> On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> > 
> > On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > > 
> > > From: Jim Bride 
> > > 
> > > For DP compliance we need to be able to control the output color
> > > type for the pipe associated with the DP port. To do this we rely
> > > on the intel_dp_test_force_bpc debugfs file and the associated value
> > > stored in struct intel_dp. If the debugfs file has a non-zero value
> > > and we're on a display port connector, then we use the value from
> > > debugfs to calculate the bpp for the pipe.  For cases where we are
> > > not on DP or there has not been an overridden value then we behave
> > > as normal.
> > > 
> > > Signed-off-by: Jim Bride 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 32 ++-
> > > -
> > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > >  2 files changed, 31 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5ffccf6..1618d36 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -12102,11 +12102,39 @@ compute_baseline_pipe_bpp(struct intel_crtc
> > > *crtc,
> > >  
> > >   /* Clamp display bpp to EDID value */
> > >   for_each_connector_in_state(state, connector, connector_state, i)
> > > {
> > > + int type = 0;
> > > +
> > > + if (connector_state->best_encoder) {
> > > + struct intel_encoder *ienc;
> > > +
> > > + ienc = to_intel_encoder(connector_state-
> > > > 
> > > > best_encoder);
> > > + type = ienc->type;
> > > + }
> > > +
> > >   if (connector_state->crtc != >base)
> > >   continue;
> > >  
> > > - connected_sink_compute_bpp(to_intel_connector(connector),
> > > -    pipe_config);
> > > + /* For DP compliance we need to ensure that we can
> > > override
> > > +  * the computed bpp for the pipe.
> > > +  */
> > > + if (type == INTEL_OUTPUT_DISPLAYPORT) {
> > > + struct intel_dp *intel_dp =
> > > + enc_to_intel_dp(connector_state-
> > > > 
> > > > best_encoder);
> > > +
> > > + if (intel_dp &&
> > > + (intel_dp->compliance_force_bpc != 0)) {
> > > + pipe_config->pipe_bpp =
> > > + intel_dp->compliance_force_bpc*3;
> > > + DRM_DEBUG_KMS("JMB Setting pipe_bpp to
> > > %d\n",
> > > +   pipe_config->pipe_bpp);
> > > + } else {
> > > + connected_sink_compute_bpp(to_intel_conne
> > > ctor
> > > (connector),
> > > +    pipe_config);
> > This kind of thing should be done in the encoder compute_config hook.
> Even though it's really not specific to an individual encoder configuration?
> This seems to be the central place where we're ensuring that we have a sane
> value for bpp relative to the display, and thus a good place to set this
> override to make compliance happy (which needs a specific bpc value for some
> test cases rather than one that is deemed sane relative to the sink's
> capabilities.

Well, this code path is only reached when the DisplayPort associated with a
given encoder is in the middle of compliance testing. I'd say that's very
encoder specific.

The bpp computation happens in two phases. Here a baseline is computed,
considering what is generally supported by the hardware. The encoders are
allowed to override that value. You can look at HDMI for an example: it may
require a bpp override since HDMI doesn't supports 10 bpc, only 8 or 12. You can
 find similar code also in LVDS and even DP.

Unfortunately, there is very little documentation of what the hooks are supposed
to do. But for the question at hand, yes, it should really be in
intel_dp_compute_config().

Ander

> 
> > 
> > 
> > > 
> > > + }
> > > + } else {
> > > + connected_sink_compute_bpp(to_intel_connector(con
> > > nect
> > > or),
> > > +    pipe_config);
> > > + }
> > >   }
> > >  
> > >   return bpp;
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index e23eed7..10eaff8 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -865,6 +865,7 @@ struct intel_dp {
> > >   unsigned long compliance_test_type;
> > >   unsigned long compliance_test_data;
> > >   bool compliance_test_active;
> > > + unsigned long compliance_force_bpc; /* 0 for 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.

[Chris Wilson]

On Mon, May 23, 2016 at 06:09:31PM +0200, Maarten Lankhorst wrote:
> Op 23-05-16 om 17:43 schreef Chris Wilson:
> > On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
> >> Op 23-05-16 om 16:25 schreef Chris Wilson:
> >>> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
>  With nonblocking unpin there can be many cursor pins before they're
>  cleared by the next page flip.
> 
>  Fix this by extending pin_count to the full 32-bit to prevent a
>  WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> >>> This is a hack that affects non-KMS paths. Being able to process binding
> >>> in a single operation on all architectures is something we want to
> >>> preserve.
> >>>
> >>> Why is every cursor movement generating an unpin work? Should I just
> >>> start poking registers from userspace to avoid a silly kerenl?
> >>> -Chris
> >>>
> >> All the unpin work gets batched till after the next vblank, it's not very 
> >> efficient
> >> but if you want to fix it you should just add the vma to plane state 
> >> already.
> > I still don't see where the flush will occur, or why vblanks would be
> > running at all for cursor updates.
> Next page flip. All cursor updates are added to flip_work list and are 
> cleared on vblank.

Now knowing the trigger, I've written a reproducer: igt/kms_cursor_legacy
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/ilk: Don't disable SSC source if it's in use

[Lyude]

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf4
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.

Changes since v1:
 - Leave the SSC source clock on instead of just shutting it off on all
   of the DPLL configurations.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
Sorry about that! I misread danvet's suggestion as "disable the SSC" instead of
"don't disable the SSC".

 drivers/gpu/drm/i915/intel_display.c | 47 +++-
 1 file changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d500e6f..dff8511 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
-   u32 val, final;
+   int i;
+   u32 val, temp, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_panel = false;
bool has_ck505 = false;
bool can_ssc = false;
+   bool using_ssc_source = false;
 
/* We need to take the global config into account */
for_each_intel_encoder(dev, encoder) {
@@ -8283,9 +8285,26 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
else
final |= DREF_NONSPREAD_SOURCE_ENABLE;
 
-   final &= ~DREF_SSC_SOURCE_MASK;
final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
-   final &= ~DREF_SSC1_ENABLE;
+
+   /* Check if any DPLLs are using the SSC source */
+   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
+   temp = I915_READ(PCH_DPLL(i));
+
+   if (!(temp & DPLL_VCO_ENABLE))
+   continue;
+
+   if ((temp & PLL_REF_INPUT_MASK) ==
+   PLLB_REF_INPUT_SPREADSPECTRUMIN) {
+   using_ssc_source = true;
+   break;
+   }
+   }
+
+   if (!using_ssc_source) {
+   final &= ~DREF_SSC_SOURCE_MASK;
+   final &= ~DREF_SSC1_ENABLE;
+   }
 
if (has_panel) {
final |= DREF_SSC_SOURCE_ENABLE;
@@ -8348,7 +8367,7 @@ static void 

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Wait one vblank before enabling audio

[Lyude Paul]

On Mon, 2016-05-23 at 21:06 +0300, Ville Syrjälä wrote:
> On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote:
> > 
> > We no longer call ilk_audio_codec_enable() while we have vblanks
> > disabled. As such, we can finally fix this and stop the occasional pipe
> > underruns I'm seeing on this Dell OptiPlex 990.
> Hmm. Are you still getting underruns on -nightly?
For me the problem isn't just underruns, a lot of times the modeset results in a
blank monitor without this fix… afaict waiting for 1 vblank seems to fix the
issue entirely here, but I'll check more thoroughly in a bit and update you if I
manage to get it to underrun.

Cheers,
Lyude

> 
> I basically tried this same thing (+ a bunch of other tweaks to the
> audio enable sequence) when I was hunting the remaining underruns on
> my ILK, but in the end audio was a red herring. So I never found
> any real benefit from extra vblank waits in the audio enable sequence.
> They did appear to help sometimes, but with a enough repetitions it
> still failed.
> 
> > 
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Lyude 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 8 ++--
> >  1 file changed, 2 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 7d281b4..0d685fe 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -423,12 +423,8 @@ static void ilk_audio_codec_enable(struct drm_connector
> > *connector,
> >     if (WARN_ON(port == PORT_A))
> >     return;
> >  
> > -   /*
> > -    * FIXME: We're supposed to wait for vblank here, but we have
> > vblanks
> > -    * disabled during the mode set. The proper fix would be to push
> > the
> > -    * rest of the setup into a vblank work item, queued here, but the
> > -    * infrastructure is not there yet.
> > -    */
> > +   /* Need to wait one vblank before enabling audio */
> > +   intel_wait_for_vblank(connector->dev, pipe);
> >  
> >     if (HAS_PCH_IBX(connector->dev)) {
> >     hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
> > -- 
> > 2.5.5
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Disable SSC for DPLLs if we're not using it

[Ville Syrjälä]

On Mon, May 23, 2016 at 02:56:54PM -0400, Lyude wrote:
> Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
> 
> Unfortunately one of the sideaffects of having the refclk for a DPLL
> set to SSC is that as long as it's set to SSC, the GPU will prevent us
> from powering down any of the pipes or transcoders using it. A couple of
> BIOSes, despite the fact they don't actually need it, enable SSC both in
> PCH_DREF_CONTROL and on the DPLL configurations. This causes issues on
> the first modeset, since we don't expect SSC to be left on and as a
> result, can't successfully power down the pipes or the transcoders using
> it. Here's an example from this Dell OptiPlex 990:
> 
> [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says 
> disabled
> [drm:intel_modeset_init] 2 display pipes available.
> [drm:intel_update_cdclk] Current CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
> vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [drm:intel_crt_reset] crt adpa set to 0xf4
> [drm:intel_dp_init_connector] Adding DP connector on port C
> [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
> [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
> [drm:ironlake_init_pch_refclk] Disabling SSC entirely
> … later we try committing the first modeset …
> [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
> pipe A
> [drm:intel_dump_pipe_config] cpu_transcoder: A
> …
> [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
> fp0: 0x20e08, fp1: 0x30d07
> [drm:intel_dump_pipe_config] planes on this crtc
> [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
> [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
> [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 
> 800x600
> [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
> scaler_id = 0
> [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
> scaler_id = 0
> [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
> [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
> [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
> [drm:intel_disable_pipe] disabling pipe A
> [ cut here ]
> WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
> intel_disable_pipe+0x297/0x2d0 [i915]
> pipe_off wait timed out
> …
> ---[ end trace 94fc8aa03ae139e8 ]---
> [drm:intel_dp_link_down]
> [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
> 
> Later modesets succeed since they reset the DPLL's configuration anyway,
> but this is enough to get stuck with a big fat warning in dmesg.
> 
> Normally we'd need to add some sort of ref counting mechanism to the
> CRTCs so we avoid accidentally trying to shut off a shared resource, but
> since ignore what the BIOS does anyway and we shut off the refclks
> before any modesets, this workaround should suffice for now.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d500e6f..3fb6025 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8230,7 +8230,8 @@ static void ironlake_init_pch_refclk(struct drm_device 
> *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_encoder *encoder;
> - u32 val, final;
> + int i;
> + u32 val, temp, final;
>   bool has_lvds = false;
>   bool has_cpu_edp = false;
>   bool has_panel = false;
> @@ -8369,6 +8370,22 @@ static void ironlake_init_pch_refclk(struct drm_device 
> *dev)
>   I915_WRITE(PCH_DREF_CONTROL, val);
>   POSTING_READ(PCH_DREF_CONTROL);
>   udelay(200);
> +
> + /* Unset SSC as the refclk for all of the DPLLs */
> + for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> + temp = I915_READ(PCH_DPLL(i));
> +
> + if (!(temp & PLLB_REF_INPUT_SPREADSPECTRUMIN))

should be something like
(temp & (DPLL_VCO_ENABLE | PLL_REF_INPUT_MASK)) != (DPLL_VCO_ENABLE | 
PLL_REF_INPUT_SPREADSPECTRUMIN)

> + continue;
> +
> + DRM_DEBUG_KMS("Disabling SSC refclk for %s\n",
> +   dev_priv->shared_dplls[i].name);
> +
> + /* Change refclk to DREFCLK */
> + temp &= ~PLL_REF_INPUT_MASK;

I doubt that's safe. We need to just leave the SSC source enabled
instead if any DPLL depends on it. I think something along these 

[Intel-gfx] [PATCH] drm/i915/ilk: Disable SSC for DPLLs if we're not using it

[Lyude]

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL
set to SSC is that as long as it's set to SSC, the GPU will prevent us
from powering down any of the pipes or transcoders using it. A couple of
BIOSes, despite the fact they don't actually need it, enable SSC both in
PCH_DREF_CONTROL and on the DPLL configurations. This causes issues on
the first modeset, since we don't expect SSC to be left on and as a
result, can't successfully power down the pipes or the transcoders using
it. Here's an example from this Dell OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf4
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

Normally we'd need to add some sort of ref counting mechanism to the
CRTCs so we avoid accidentally trying to shut off a shared resource, but
since ignore what the BIOS does anyway and we shut off the refclks
before any modesets, this workaround should suffice for now.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_display.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d500e6f..3fb6025 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8230,7 +8230,8 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
-   u32 val, final;
+   int i;
+   u32 val, temp, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_panel = false;
@@ -8369,6 +8370,22 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
I915_WRITE(PCH_DREF_CONTROL, val);
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
+
+   /* Unset SSC as the refclk for all of the DPLLs */
+   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
+   temp = I915_READ(PCH_DPLL(i));
+
+   if (!(temp & PLLB_REF_INPUT_SPREADSPECTRUMIN))
+   continue;
+
+   DRM_DEBUG_KMS("Disabling SSC refclk for %s\n",
+ dev_priv->shared_dplls[i].name);
+
+   /* Change refclk to DREFCLK */
+   temp &= ~PLL_REF_INPUT_MASK;
+
+   I915_WRITE(PCH_DPLL(i), temp);
+   }
}
 
BUG_ON(val != final);
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH 00/21] drm/i915: SKL/KBL/BXT cdclk stuff

[Ville Syrjälä]

On Fri, May 13, 2016 at 11:41:19PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Here's my second installment of SKL+ cdclk stuff. I've picked up Clint's 
> latest
> SKL/KBL cdclk patch and expanded on it quite a bit. After this series we're
> capable of actually changing the DPLL0 VCO frequency dynamically, and a lot of
> the code gets a much more uniform feel to it between SKL/KBL vs. BXT. This
> should make it possible to land some future hardware work on top as well,
> without making the code an awful mess.
> 
> Series available here:
> git://github.com/vsyrjala/linux.git skl_bxt_cdclk_part_2
> 
> Clint Taylor (1):
>   drm/i915/skl: SKL CDCLK change on modeset tracking VCO
> 
> Ville Syrjälä (20):
>   drm/i915: Fix BXT min_pixclk after state readout
>   drm/i915: Move the SKL DPLL0 VCO computation into
> intel_dp_compute_config()
>   drm/i915: Extract skl_calc_cdclk()
>   drm/i915: Actually read out DPLL0 vco on skl from hardware
>   drm/i915: Report the current DPLL0 vco on SKL/KBL
>   drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL
>   drm/i915: Keep track of preferred cdclk vco frequency on SKL
>   drm/i915: Beef up skl_sanitize_cdclk() a bit
>   drm/i915: Unify SKL cdclk init paths
>   drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit
>   drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL
>   drm/i915: Rename skl_vco_freq to cdclk_pll.vco
>   drm/i915: Store cdclk PLL reference clock under dev_priv
>   drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()
>   drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv
>   drm/i915: Update cached cdclk state from broxton_init_cdclk()
>   drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE
> PLL vco/refclk
>   drm/i915: Make bxt_set_cdclk() operate in terms of the current vs
> target DE PLL vco
>   drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk
> check
>   drm/i915: Set BXT cdclk to minimum initially

Entire series pushed to dinq. Thanks for the reviews.

> 
>  drivers/gpu/drm/i915/i915_drv.h |   6 +-
>  drivers/gpu/drm/i915/intel_display.c| 623 
> +++-
>  drivers/gpu/drm/i915/intel_dp.c |  21 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  19 +-
>  drivers/gpu/drm/i915/intel_drv.h|   7 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  45 ++-
>  6 files changed, 443 insertions(+), 278 deletions(-)
> 
> -- 
> 2.7.4

-- 
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 22/21] drm/i915: Assert the dbuf is enabled when disabling DC5/6

[Ville Syrjälä]

On Thu, May 19, 2016 at 10:49:23PM +0300, Imre Deak wrote:
> On Mon, 2016-05-16 at 16:59 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling.
> > Let's make sure it has correctly restored the dbuf state to enabled
> > when we disable the DC states.
> > 
> > Cc: Imre Deak 
> > Suggested-by: Imre Deak 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index b70e123f67ca..27cb92c18bb5 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -806,6 +806,15 @@ static bool gen9_dc_off_power_well_enabled(struct 
> > drm_i915_private *dev_priv,
> >     return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
> >  }
> >  
> > +static void skl_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
> 
> I would've used gen9_ prefix. Either way:

Changed while applying.

> Reviewed-by: Imre Deak 
> 
> > +{
> > +   u32 tmp = I915_READ(DBUF_CTL);
> > +
> > +   WARN((tmp & (DBUF_POWER_STATE | DBUF_POWER_REQUEST)) !=
> > +    (DBUF_POWER_STATE | DBUF_POWER_REQUEST),
> > +    "Unexpected DBuf power power state (0x%08x)\n", tmp);
> > +}
> > +
> >  static void gen9_dc_off_power_well_enable(struct drm_i915_private 
> > *dev_priv,
> >       struct i915_power_well *power_well)
> >  {
> > @@ -814,6 +823,8 @@ static void gen9_dc_off_power_well_enable(struct 
> > drm_i915_private *dev_priv,
> >     WARN_ON(dev_priv->cdclk_freq !=
> >     dev_priv->display.get_display_clock_speed(dev_priv->dev));
> >  
> > +   skl_assert_dbuf_enabled(dev_priv);
> > +
> >     if (IS_BROXTON(dev_priv))
> >     broxton_ddi_phy_verify_state(dev_priv);
> >  }

-- 
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 11/21] drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit

[Ville Syrjälä]

On Thu, May 19, 2016 at 06:48:37PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > SKL and BXT have the same snippets of code for enabling disabling the
> > DBUF. Extract those into helpers and move the calls from
> > init/unit_cdclk() to the display core init/init since this stuff isn't
> > really about cdclk. Also doing the enable twice shouldn't hurt since
> > you're just setting the request bit again when it was already set.
> > 
> > We can also toss in a few WARNs about the register values into
> > skl_get_dpll0_vco() now that we know that things should always be
> > sane there.
> > 
> > Flatten skl_init_cdclk() while at it.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c| 58 
> > -
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 32 ++
> >  2 files changed, 38 insertions(+), 52 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index da903b718c11..e908f360da74 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5480,18 +5480,6 @@ static bool broxton_cdclk_is_enabled(struct 
> > drm_i915_private *dev_priv)
> >  
> >     /* TODO: Check for a valid CDCLK rate */
> >  
> > -   if (!(I915_READ(DBUF_CTL) & DBUF_POWER_REQUEST)) {
> > -   DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power not 
> > requested\n");
> > -
> > -   return false;
> > -   }
> > -
> > -   if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE)) {
> > -   DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power hasn't 
> > settled\n");
> > -
> > -   return false;
> > -   }
> > -
> >     return true;
> >  }
> >  
> > @@ -5518,26 +5506,10 @@ void broxton_init_cdclk(struct drm_i915_private 
> > *dev_priv)
> >      *   here, it belongs to modeset time
> >      */
> >     broxton_set_cdclk(dev_priv, 624000);
> > -
> > -   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
> > -   POSTING_READ(DBUF_CTL);
> > -
> > -   udelay(10);
> > -
> > -   if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE))
> > -   DRM_ERROR("DBuf power enable timeout!\n");
> >  }
> >  
> >  void broxton_uninit_cdclk(struct drm_i915_private *dev_priv)
> >  {
> > -   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) & ~DBUF_POWER_REQUEST);
> > -   POSTING_READ(DBUF_CTL);
> > -
> > -   udelay(10);
> > -
> > -   if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
> > -   DRM_ERROR("DBuf power disable timeout!\n");
> > -
> >     /* Set minimum (bypass) frequency, in effect turning off the DE PLL */
> >     broxton_set_cdclk(dev_priv, 19200);
> >  }
> > @@ -5759,15 +5731,6 @@ static void skl_sanitize_cdclk(struct 
> > drm_i915_private *dev_priv);
> >  
> >  void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
> >  {
> > -   /* disable DBUF power */
> > -   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) & ~DBUF_POWER_REQUEST);
> > -   POSTING_READ(DBUF_CTL);
> > -
> > -   udelay(10);
> > -
> > -   if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
> > -   DRM_ERROR("DBuf power disable timeout\n");
> > -
> >     skl_set_cdclk(dev_priv, 24000, 0);
> >  }
> >  
> > @@ -5785,24 +5748,15 @@ void skl_init_cdclk(struct drm_i915_private 
> > *dev_priv)
> >     if (dev_priv->skl_preferred_vco_freq == 0)
> >     skl_set_preferred_cdclk_vco(dev_priv,
> >     dev_priv->skl_vco_freq);
> > -   } else {
> > -   /* set CDCLK to the lowest frequency, Modeset follows */
> > -   vco = dev_priv->skl_preferred_vco_freq;
> > -   if (vco == 0)
> > -   vco = 8100;
> > -   cdclk = skl_calc_cdclk(0, vco);
> > -
> > -   skl_set_cdclk(dev_priv, cdclk, vco);
> > +   return;
> >     }
> >  
> > -   /* enable DBUF power */
> > -   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
> > -   POSTING_READ(DBUF_CTL);
> > -
> > -   udelay(10);
> > +   vco = dev_priv->skl_preferred_vco_freq;
> > +   if (vco == 0)
> > +   vco = 8100;
> > +   cdclk = skl_calc_cdclk(0, vco);
> >  
> > -   if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE))
> > -   DRM_ERROR("DBuf power enable timeout\n");
> > +   skl_set_cdclk(dev_priv, cdclk, vco);
> >  }
> >  
> >  static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index fefe22c3c163..6817a3cb5fbc 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2176,6 +2176,28 @@ static void intel_power_domains_sync_hw(struct 
> > drm_i915_private *dev_priv)
> >     mutex_unlock(_domains->lock);
> >  }
> >  
> > +static void skl_dbuf_enable(struct drm_i915_private *dev_priv)
> 
> I 

Re: [Intel-gfx] [PATCH 10/21] drm/i915: Unify SKL cdclk init paths

[Ville Syrjälä]

On Thu, May 19, 2016 at 06:43:32PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Currently we initialize cdclk on SKL from two different places,
> > depending on whether it's during driver init or resume. Let's
> > unify it to happen from the same place always, and that place will be
> > the display core init function.
> > 
> > To do this we first run through the cdclk sanitation code, which will
> > first verify that the PLL is programmed correctly, after which we can
> > read out the current cdclk frequency, and once the cdclk is known we
> > verify that the cdclk "decimal" frequency is programmed correctly. If
> > any of these fail we will force a cdclk change, and to be safe we also
> > force the PLL to be turned off and on again. If the sanitation step
> > didn't notice anything amiss, we'll skip the cdclk programming which
> > will prevent cdclk reprogramming when the displays might be active.
> > 
> > We can also toss in a few WARNs about the register values into
> > skl_update_dpll0() since we now know that the PLL state should
> > always be sane when that function is called.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c| 40 
> > +
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c   | 11 ++---
> >  drivers/gpu/drm/i915/intel_drv.h|  1 -
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  5 +
> >  4 files changed, 34 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 493160682b2a..da903b718c11 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5577,8 +5577,15 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
> >     return;
> >     }
> >  
> > +   WARN_ON((val & LCPLL_PLL_LOCK) == 0);
> > +
> >     val = I915_READ(DPLL_CTRL1);
> >  
> > +   WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> > +   DPLL_CTRL1_SSC(SKL_DPLL0) |
> > +   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
> > +   DPLL_CTRL1_OVERRIDE(SKL_DPLL0));
> > +
> >     switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
> >     case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, SKL_DPLL0):
> >     case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, SKL_DPLL0):
> > @@ -5748,6 +5755,8 @@ static void skl_set_cdclk(struct drm_i915_private 
> > *dev_priv, int cdclk, int vco)
> >     intel_update_cdclk(dev);
> >  }
> >  
> > +static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
> > +
> >  void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
> >  {
> >     /* disable DBUF power */
> > @@ -5764,10 +5773,19 @@ void skl_uninit_cdclk(struct drm_i915_private 
> > *dev_priv)
> >  
> >  void skl_init_cdclk(struct drm_i915_private *dev_priv)
> >  {
> > -   /* DPLL0 not enabled (happens on early BIOS versions) */
> > -   if (dev_priv->skl_vco_freq == 0) {
> > -   int cdclk, vco;
> > +   int cdclk, vco;
> > +
> > +   skl_sanitize_cdclk(dev_priv);
> >  
> > +   if (dev_priv->cdclk_freq != 0 && dev_priv->skl_vco_freq != 0) {
> > +   /*
> > +    * Use the current vco as out initial
> 
> typo above.

Fixed while applying.

> 
> Looks ok:
> Reviewed-by: Imre Deak 
> 
> > +    * guess as to what the preferred vco is.
> > +    */
> > +   if (dev_priv->skl_preferred_vco_freq == 0)
> > +   skl_set_preferred_cdclk_vco(dev_priv,
> > +   dev_priv->skl_vco_freq);
> > +   } else {
> >     /* set CDCLK to the lowest frequency, Modeset follows */
> >     vco = dev_priv->skl_preferred_vco_freq;
> >     if (vco == 0)
> > @@ -5787,7 +5805,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
> >     DRM_ERROR("DBuf power enable timeout\n");
> >  }
> >  
> > -int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> > +static void skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
> >  {
> >     uint32_t cdctl, expected;
> >  
> > @@ -5810,6 +5828,8 @@ int skl_sanitize_cdclk(struct drm_i915_private 
> > *dev_priv)
> >     DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
> >     goto sanitize;
> >  
> > +   intel_update_cdclk(dev_priv->dev);
> > +
> >     /* DPLL okay; verify the cdclock
> >      *
> >      * Noticed in some instances that the freq selection is correct but
> > @@ -5821,13 +5841,15 @@ int skl_sanitize_cdclk(struct drm_i915_private 
> > *dev_priv)
> >     skl_cdclk_decimal(dev_priv->cdclk_freq);
> >     if (cdctl == expected)
> >     /* All well; nothing to sanitize */
> > -   return false;
> > -sanitize:
> > +   return;
> >  
> > -   skl_init_cdclk(dev_priv);
> > +sanitize:
> > +   DRM_DEBUG_KMS("Sanitizing cdclk programmed 

Re: [Intel-gfx] i915 kernel panic

[Oliver Leitner]

On 2016-05-23 10:49, Jani Nikula wrote:
> On Mon, 23 May 2016, Oliver Leitner  wrote:
>> I am having a problem on my HP Compaq 610 Laptop with its built in intel
>> graphics chip. It is causing me a kernel Panic.
> 
> There is no kernel panic in your dmesg. There is a WARNING with a
> backtrace.
> 
> What other symptoms do you have besides the warning? Is the system
> usable? Black screen? What?
> 
> I suggest you file a bug at [1] and attach the logs there.
> 
> BR,
> Jani.
> 
> 
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
> 
> 

Thank you for asking, Jani.

Is this more like a kernel oops?

actually, the machine is eating slightly more battery then it should be
(the "quirks" are piling up) that i can confirm.

it *might* be getting hotter than usual (i had it on another os in the
past, under which it was behaving cooler).

thank you for the tip with the freedesktop drm/intel "community?" i
filed a bug report as you said there...

https://bugs.freedesktop.org/show_bug.cgi?id=95558

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

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Wait one vblank before enabling audio

[Ville Syrjälä]

On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote:
> We no longer call ilk_audio_codec_enable() while we have vblanks
> disabled. As such, we can finally fix this and stop the occasional pipe
> underruns I'm seeing on this Dell OptiPlex 990.

Hmm. Are you still getting underruns on -nightly?

I basically tried this same thing (+ a bunch of other tweaks to the
audio enable sequence) when I was hunting the remaining underruns on
my ILK, but in the end audio was a red herring. So I never found
any real benefit from extra vblank waits in the audio enable sequence.
They did appear to help sometimes, but with a enough repetitions it
still failed.

> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 7d281b4..0d685fe 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -423,12 +423,8 @@ static void ilk_audio_codec_enable(struct drm_connector 
> *connector,
>   if (WARN_ON(port == PORT_A))
>   return;
>  
> - /*
> -  * FIXME: We're supposed to wait for vblank here, but we have vblanks
> -  * disabled during the mode set. The proper fix would be to push the
> -  * rest of the setup into a vblank work item, queued here, but the
> -  * infrastructure is not there yet.
> -  */
> + /* Need to wait one vblank before enabling audio */
> + intel_wait_for_vblank(connector->dev, pipe);
>  
>   if (HAS_PCH_IBX(connector->dev)) {
>   hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 4/5] Add support for forcing 6 bpc on DP pipes.

[Jim Bride]

On Mon, May 23, 2016 at 11:22:17AM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> > From: Jim Bride 
> > 
> > For DP compliance we need to be able to control the output color
> > type for the pipe associated with the DP port. To do this we rely
> > on the intel_dp_test_force_bpc debugfs file and the associated value
> > stored in struct intel_dp. If the debugfs file has a non-zero value
> > and we're on a display port connector, then we use the value from
> > debugfs to calculate the bpp for the pipe.  For cases where we are
> > not on DP or there has not been an overridden value then we behave
> > as normal.
> > 
> > Signed-off-by: Jim Bride 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 32 ++--
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  2 files changed, 31 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5ffccf6..1618d36 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12102,11 +12102,39 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
> >  
> >     /* Clamp display bpp to EDID value */
> >     for_each_connector_in_state(state, connector, connector_state, i) {
> > +   int type = 0;
> > +
> > +   if (connector_state->best_encoder) {
> > +   struct intel_encoder *ienc;
> > +
> > +   ienc = to_intel_encoder(connector_state-
> > >best_encoder);
> > +   type = ienc->type;
> > +   }
> > +
> >     if (connector_state->crtc != >base)
> >     continue;
> >  
> > -   connected_sink_compute_bpp(to_intel_connector(connector),
> > -      pipe_config);
> > +   /* For DP compliance we need to ensure that we can override
> > +    * the computed bpp for the pipe.
> > +    */
> > +   if (type == INTEL_OUTPUT_DISPLAYPORT) {
> > +   struct intel_dp *intel_dp =
> > +   enc_to_intel_dp(connector_state-
> > >best_encoder);
> > +
> > +   if (intel_dp &&
> > +   (intel_dp->compliance_force_bpc != 0)) {
> > +   pipe_config->pipe_bpp =
> > +   intel_dp->compliance_force_bpc*3;
> > +   DRM_DEBUG_KMS("JMB Setting pipe_bpp to %d\n",
> > +     pipe_config->pipe_bpp);
> > +   } else {
> > +   connected_sink_compute_bpp(to_intel_connector
> > (connector),
> > +      pipe_config);
> 
> This kind of thing should be done in the encoder compute_config hook.

Even though it's really not specific to an individual encoder configuration?
This seems to be the central place where we're ensuring that we have a sane
value for bpp relative to the display, and thus a good place to set this
override to make compliance happy (which needs a specific bpc value for some
test cases rather than one that is deemed sane relative to the sink's
capabilities.

> 
> > +   }
> > +   } else {
> > +   connected_sink_compute_bpp(to_intel_connector(connect
> > or),
> > +      pipe_config);
> > +   }
> >     }
> >  
> >     return bpp;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e23eed7..10eaff8 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -865,6 +865,7 @@ struct intel_dp {
> >     unsigned long compliance_test_type;
> >     unsigned long compliance_test_data;
> >     bool compliance_test_active;
> > +   unsigned long compliance_force_bpc; /* 0 for default or bpc to use */
> 
> There's no code for setting compliance_test_active anywhere. The commit 
> message
> mentions debugfs, but I didn't see anything related in the patch. 

It appears that Manasi forgot to include one of the patches I had sent her.
The debugfs support code was in a separate patch.

Jim

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: SKL/KBL/BXT cdclk stuff

[Ville Syrjälä]

On Sat, May 14, 2016 at 05:25:57AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: SKL/KBL/BXT cdclk stuff
> URL   : https://patchwork.freedesktop.org/series/7169/
> State : failure
> 
> == Summary ==
> 
> Series 7169v1 drm/i915: SKL/KBL/BXT cdclk stuff
> http://patchwork.freedesktop.org/api/1.0/series/7169/revisions/1/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> fail   -> PASS   (ro-byt-n2820)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (ro-hsw-i3-4010u)

(kms_flip:8003) DEBUG: name = vblank
last_ts = 626.544176 usec
last_received_ts = 626.543125 usec
last_seq = 623
current_ts = 626.877510 usec
current_received_ts = 626.876400 usec
current_seq = 633
count = 9
seq_step = 10
(kms_flip:8003) CRITICAL: Test assertion failure function check_final_state, 
file kms_flip.c:1192:
(kms_flip:8003) CRITICAL: Failed assertion: count >= expected * 99/100 && count 
<= expected * 101/100
(kms_flip:8003) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:8003) CRITICAL: dropped frames, expected 99, counted 100, encoder 
type 2

https://bugs.freedesktop.org/show_bug.cgi?id=95380

> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-a:
> pass   -> DMESG-WARN (ro-ivb2-i7-3770)

[  531.288533] WARNING: CPU: 7 PID: 7836 at 
drivers/gpu/drm/i915/intel_display.c:13623 intel_atomic_commit+0x13b6/0x1460 
[i915]
[  531.288534] pipe A vblank wait timed out

https://bugs.freedesktop.org/show_bug.cgi?id=95125

> 
> ro-bdw-i5-5250u  total:219  pass:181  dwarn:0   dfail:0   fail:0   skip:38 
> ro-bdw-i7-5557U  total:219  pass:206  dwarn:0   dfail:0   fail:0   skip:13 
> ro-bdw-i7-5600u  total:219  pass:187  dwarn:0   dfail:0   fail:0   skip:32 
> ro-bsw-n3050 total:219  pass:175  dwarn:0   dfail:0   fail:2   skip:42 
> ro-byt-n2820 total:218  pass:175  dwarn:0   dfail:0   fail:2   skip:41 
> ro-hsw-i3-4010u  total:218  pass:192  dwarn:0   dfail:0   fail:1   skip:25 
> ro-hsw-i7-4770r  total:219  pass:194  dwarn:0   dfail:0   fail:0   skip:25 
> ro-ilk-i7-620lm  total:219  pass:151  dwarn:0   dfail:0   fail:1   skip:67 
> ro-ilk1-i5-650   total:214  pass:152  dwarn:0   dfail:0   fail:1   skip:61 
> ro-ivb2-i7-3770  total:219  pass:186  dwarn:1   dfail:0   fail:0   skip:32 
> ro-skl-i7-6700hq total:214  pass:190  dwarn:0   dfail:0   fail:0   skip:24 
> ro-snb-i7-2620M  total:219  pass:177  dwarn:0   dfail:0   fail:1   skip:41 
> ro-ivb-i7-3770 failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_900/
> 
> 1a536db drm-intel-nightly: 2016y-05m-13d-21h-21m-06s UTC integration manifest
> b974b6b drm/i915: Set BXT cdclk to minimum initially
> c75fe510 drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk 
> check
> ef3fb6c drm/i915: Make bxt_set_cdclk() operate in terms of the current vs 
> target DE PLL vco
> b8ee27d drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the 
> DE PLL vco/refclk
> 77095f2 drm/i915: Update cached cdclk state from broxton_init_cdclk()
> 7c27fe0 drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv
> 351a2e3 drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()
> dabb9dd drm/i915: Store cdclk PLL reference clock under dev_priv
> 995467c drm/i915: Rename skl_vco_freq to cdclk_pll.vco
> 19f5564 drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL
> 3499324 drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit
> 75083d8 drm/i915: Unify SKL cdclk init paths
> 0b482fa drm/i915: Beef up skl_sanitize_cdclk() a bit
> 5fe223b drm/i915: Keep track of preferred cdclk vco frequency on SKL
> b878f36 drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL
> 8fbef2c drm/i915: Report the current DPLL0 vco on SKL/KBL
> 244d5cc drm/i915: Actually read out DPLL0 vco on skl from hardware
> 7d03efe drm/i915: Extract skl_calc_cdclk()
> e2cd537 drm/i915: Move the SKL DPLL0 VCO computation into 
> intel_dp_compute_config()
> 732fab3 drm/i915/skl: SKL CDCLK change on modeset tracking VCO
> e53fa8e drm/i915: Fix BXT min_pixclk after state readout

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/4] drm/i915: Introduce intel_release_shared_dpll()

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Introduce 
intel_release_shared_dpll()
URL   : https://patchwork.freedesktop.org/series/7467/
State : failure

== Summary ==

Series 7467v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7467/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> DMESG-WARN (ro-ilk1-i5-650)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-ivb-i7-3770)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> DMESG-WARN (ro-ilk1-i5-650)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:144  dwarn:2   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:176  dwarn:0   dfail:0   fail:1   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-bsw-n3050 failed to connect after reboot
fi-byt-n2820 failed to connect after reboot
fi-hsw-i7-4770k failed to connect after reboot
fi-skl-i5-6260u failed to connect after reboot
fi-snb-i7-2600 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_980/

facf329 drm-intel-nightly: 2016y-05m-23d-15h-31m-43s UTC integration manifest
44e119e drm/i915: Update kerneldoc for intel_dpll_mgr.c
8d57ff3 drm/i915: Rename intel_shared_dpll->mode_set() to prepare()
0c0c2bb drm/i915: Rename intel_shared_dpll_commit() to _swap_state()
2730a6a drm/i915: Introduce intel_release_shared_dpll()

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

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

[Ville Syrjälä]

On Fri, May 20, 2016 at 04:06:17PM +0300, David Weinehall wrote:
> On Sat, May 07, 2016 at 09:18:24PM +0300, Ville Syrjälä wrote:
> > On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> > > On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device 
> > > > *dev, pm_message_t state)
> > > >  static int i915_drm_resume(struct drm_device *dev)
> > > >  {
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > +   int ret;
> > > >  
> > > > disable_rpm_wakeref_asserts(dev_priv);
> > > >  
> > > > +   ret = i915_ggtt_enable_hw(dev);
> > > > +   if (ret)
> > > > +   DRM_ERROR("failed to re-enable GGTT\n");
> > > 
> > > Would it not be fatal for resume as well? Failure means we can't use the
> > > GGTT, so all subsequent writes will be going into a random address.
> > 
> > Yeah, I assume things would blow up. The question is however, what can
> > we do in this case? We'd basically have to shut the entire driver down.
> > I don't think we have a way to do that?
> 
> panic() seems like the answer here.  If we risk scribbling into
> random memory we should make sure that we just drop everything.

Yeah, maybe. OTOH I really hate it when resume gives you hung machine, a
bit of memory corruption might be preferable. I wonder if we could
force a remount-ro for all disks to at least avoid scribbling over
anything permanently. But this might all be entirely theoretical, and
this will never happen. The fake agp code just ignored the return value
and peopled seemed happy.

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix NULL pointer deference when out of PLLs in IVB

[Patchwork]

== Series Details ==

Series: drm/i915: Fix NULL pointer deference when out of PLLs in IVB
URL   : https://patchwork.freedesktop.org/series/7458/
State : failure

== Summary ==

Series 7458v1 drm/i915: Fix NULL pointer deference when out of PLLs in IVB
http://patchwork.freedesktop.org/api/1.0/series/7458/revisions/1/mbox

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770k  total:184  pass:166  dwarn:0   dfail:0   fail:0   skip:17 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_979/

facf329 drm-intel-nightly: 2016y-05m-23d-15h-31m-43s UTC integration manifest
b214df4 drm/i915: Fix NULL pointer deference when out of PLLs in IVB

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

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [v2,1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Never fully mask the the EI up 
rps interrupt on SNB/IVB (rev2)
URL   : https://patchwork.freedesktop.org/series/7572/
State : warning

== Summary ==

Series 7572v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7572/revisions/2/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:180  dwarn:3   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-byt-n2820 failed to connect after reboot
fi-hsw-i7-4770k failed to connect after reboot
ro-ivb-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_978/

facf329 drm-intel-nightly: 2016y-05m-23d-15h-31m-43s UTC integration manifest
c2b85aa drm/i915: Make RPS enable immediate
ec7c1f6 drm/i915: Don't frob with RPS around GPU reset
7311f7d drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

___
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: Bump pin_count to UINT_MAX.

[Maarten Lankhorst]

Op 23-05-16 om 17:43 schreef Chris Wilson:
> On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
>> Op 23-05-16 om 16:25 schreef Chris Wilson:
>>> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
 With nonblocking unpin there can be many cursor pins before they're
 cleared by the next page flip.

 Fix this by extending pin_count to the full 32-bit to prevent a
 WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
>>> This is a hack that affects non-KMS paths. Being able to process binding
>>> in a single operation on all architectures is something we want to
>>> preserve.
>>>
>>> Why is every cursor movement generating an unpin work? Should I just
>>> start poking registers from userspace to avoid a silly kerenl?
>>> -Chris
>>>
>> All the unpin work gets batched till after the next vblank, it's not very 
>> efficient
>> but if you want to fix it you should just add the vma to plane state already.
> I still don't see where the flush will occur, or why vblanks would be
> running at all for cursor updates.
Next page flip. All cursor updates are added to flip_work list and are cleared 
on vblank.
>> According to Ville unpin count would still be too low on BXT/SKL, so it 
>> wouldn't
>> remove the need for this patch anyway..
> Increasing the count is one thing, taking all 32bits as a workaround for
> poor behaviour in the cursor update is another.
> -Chris
>

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

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/2] drm/i915/opregion: Convert to using native drm_i915_private

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/opregion: Convert to using native 
drm_i915_private
URL   : https://patchwork.freedesktop.org/series/7571/
State : success

== Summary ==

Series 7571v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7571/revisions/1/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
fail   -> PASS   (fi-byt-n2820)
Test kms_sink_crc_basic:
skip   -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:179  dwarn:0   dfail:0   fail:2   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_977/

54afd5a drm-intel-nightly: 2016y-05m-23d-13h-38m-05s UTC integration manifest
61e93fa drm/i915/opregion: Rename init/fini functions to register/unregister
b23b810 drm/i915/opregion: Convert to using native drm_i915_private

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Enable GSE interrupt on BDW+

[Ville Syrjälä]

On Mon, May 23, 2016 at 05:44:28PM +0300, Jani Nikula wrote:
> On Mon, 23 May 2016, Mark Kettenis  wrote:
> >> From: Jani Nikula 
> >> Date: Mon, 23 May 2016 17:04:48 +0300
> >> 
> >> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä 
> >> >
> >> > We've never actually enabled or unmasked the GSE interrupt on BDW+,
> >> > even though the interrupt handler was always prepared for it.
> >> > Let's enable it and see what happens.
> >> >
> >> > Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
> >> > driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
> >> > brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
> >> > Carbon" for them.
> >> >
> >> > Reviewed-by: Daniel Vetter 
> >> > References: 
> >> > http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
> >> > Reported-by: Mark Kettenis 
> >> > Cc: Mark Kettenis 
> >> > Cc: Jani Nikula 
> >> > Signed-off-by: Ville Syrjälä 
> >> > ---
> >> > Nothing changed, just reposted for CI.
> >> 
> >> As I noted previously, I don't think we need this, but if you insist on
> >> having it, please add a note about it in the commit message. With that,
> >
> > FWIW, this *is* needed if you want ACPI-based backlight control to
> > work.  On Linux you probably don't notice, since "hardware" backlight
> > control is preferred over "firmware" or "platform" backlight control.
> >
> > It would help me if this did land in the Linux tree though, as it will
> > make future imports of the i915 driver into OpenBSD easier.
> 
> Ville, there's your copy-paste for the logs. ;)

Copy-pasted and pushed to dinq. Thanks everyone.

> 
> BR,
> Jani.
> 
> 
> >
> >> >  drivers/gpu/drm/i915/i915_irq.c | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> > b/drivers/gpu/drm/i915/i915_irq.c
> >> > index f0d941455bed..4c271ea267bb 100644
> >> > --- a/drivers/gpu/drm/i915/i915_irq.c
> >> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> > @@ -3799,6 +3799,7 @@ static void gen8_de_irq_postinstall(struct 
> >> > drm_i915_private *dev_priv)
> >> >  uint32_t de_pipe_enables;
> >> >  u32 de_port_masked = GEN8_AUX_CHANNEL_A;
> >> >  u32 de_port_enables;
> >> > +u32 de_misc_masked = GEN8_DE_MISC_GSE;
> >> >  enum pipe pipe;
> >> >  
> >> >  if (INTEL_INFO(dev_priv)->gen >= 9) {
> >> > @@ -3834,6 +3835,7 @@ static void gen8_de_irq_postinstall(struct 
> >> > drm_i915_private *dev_priv)
> >> >de_pipe_enables);
> >> >  
> >> >  GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
> >> > +GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
> >> >  }
> >> >  
> >> >  static int gen8_irq_postinstall(struct drm_device *dev)
> >> 
> >> -- 
> >> Jani Nikula, Intel Open Source Technology Center
> >> 
> >> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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 2/2] drm/i915: Bump pin_count to UINT_MAX.

[Chris Wilson]

On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
> Op 23-05-16 om 16:25 schreef Chris Wilson:
> > On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> >> With nonblocking unpin there can be many cursor pins before they're
> >> cleared by the next page flip.
> >>
> >> Fix this by extending pin_count to the full 32-bit to prevent a
> >> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> > This is a hack that affects non-KMS paths. Being able to process binding
> > in a single operation on all architectures is something we want to
> > preserve.
> >
> > Why is every cursor movement generating an unpin work? Should I just
> > start poking registers from userspace to avoid a silly kerenl?
> > -Chris
> >
> All the unpin work gets batched till after the next vblank, it's not very 
> efficient
> but if you want to fix it you should just add the vma to plane state already.

I still don't see where the flush will occur, or why vblanks would be
running at all for cursor updates.
 
> According to Ville unpin count would still be too low on BXT/SKL, so it 
> wouldn't
> remove the need for this patch anyway..

Increasing the count is one thing, taking all 32bits as a workaround for
poor behaviour in the cursor update is another.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Disable automatic GuC firmware loading

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

New GuC code is logging errors at runtime suspend and resume which
causes CI testing to log "orange" status. Default to not trying to
load the firmware until this is resolved.

Example of the log:

 [drm] RC6 on
 [drm:intel_runtime_suspend] Suspending device
 [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. 
ret=-110 status=0x0501 response=0x4000
 ...
 [drm:intel_runtime_resume] Resuming device
 [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. 
ret=-110 status=0x0502 response=0x4000
 [drm:intel_runtime_resume] Device resumed

Signed-off-by: Tvrtko Ursulin 
Cc: Dave Gordon 
Cc: Ville Syrjälä 
Cc: Chris Harris 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 21a323c01cdb..9a5d58b251f5 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,7 +53,7 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = -1,
+   .enable_guc_loading = 0,
.enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
@@ -197,7 +197,7 @@ MODULE_PARM_DESC(edp_vswing,
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
 MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+   "(-1=auto, 0=never [default], 1=if available, 2=required)");
 
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
-- 
1.9.1

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Wait for flips to complete before returning.

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for flips to complete before returning.
URL   : https://patchwork.freedesktop.org/series/7569/
State : failure

== Summary ==

Series 7569v1 drm/i915: Wait for flips to complete before returning.
http://patchwork.freedesktop.org/api/1.0/series/7569/revisions/1/mbox

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> FAIL   (ro-byt-n2820)
Test kms_sink_crc_basic:
skip   -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:168  dwarn:0   dfail:0   fail:4   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
fi-byt-n2820 failed to connect after reboot
ro-snb-i7-2620M failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_976/

54afd5a drm-intel-nightly: 2016y-05m-23d-13h-38m-05s UTC integration manifest
0c72178 drm/i915: Bump pin_count to UINT_MAX.
4ce00ee drm/i915: Wait for flips to complete before returning.

___
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/opregion: Rename init/fini functions to register/unregister

[Chris Wilson]

On Mon, May 23, 2016 at 05:42:49PM +0300, Jani Nikula wrote:
> On Mon, 23 May 2016, Chris Wilson  wrote:
> > Current intel_opregion_init is called during the driver registration
> > phase and intel_opregion_fini from the unregistration phase. Rename the
> > functions show that this is clear from their names. The phases tell us
> > what we expect the existing hw state to be, e.g. whether interrupts are
> > still enabled etc.
> 
> Okay, for the naming per se,
> 
> Reviewed-by: Jani Nikula 
> 
> While not a problem in this patch, the whole init/cleanup of opregion is
> annoyingly asymmetric. You need to call both setup and init to make it
> work, but fini cleans up for both of them. So repeated init/fini pairs
> will fail. The setup also does some initialization that is only needed
> once (like INIT_WORK) so fini is not a complete counter-operation of
> setup+init either.

Yeah, that's was kind of my starting goal to try and make it fit into
the overarching init phases better. Looking at suspend/resume to try and
understand why it didn't just unregister/register (or why it needed to
do the acpi unregister at all) raised too many questions.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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: Bump pin_count to UINT_MAX.

[Maarten Lankhorst]

Op 23-05-16 om 16:25 schreef Chris Wilson:
> On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
>> With nonblocking unpin there can be many cursor pins before they're
>> cleared by the next page flip.
>>
>> Fix this by extending pin_count to the full 32-bit to prevent a
>> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> This is a hack that affects non-KMS paths. Being able to process binding
> in a single operation on all architectures is something we want to
> preserve.
>
> Why is every cursor movement generating an unpin work? Should I just
> start poking registers from userspace to avoid a silly kerenl?
> -Chris
>
All the unpin work gets batched till after the next vblank, it's not very 
efficient
but if you want to fix it you should just add the vma to plane state already.

According to Ville unpin count would still be too low on BXT/SKL, so it wouldn't
remove the need for this patch anyway..

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

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Wait for flips to complete before returning.

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for flips to complete before returning.
URL   : https://patchwork.freedesktop.org/series/7569/
State : warning

== Summary ==

Series 7569v1 drm/i915: Wait for flips to complete before returning.
http://patchwork.freedesktop.org/api/1.0/series/7569/revisions/1/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (fi-byt-n2820)
Subgroup basic-uc-pro-default:
pass   -> DMESG-WARN (ro-ivb-i7-3770)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (ro-bdw-i7-5600u)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:176  dwarn:1   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:180  dwarn:2   dfail:0   fail:0   skip:22 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_975/

54afd5a drm-intel-nightly: 2016y-05m-23d-13h-38m-05s UTC integration manifest
cd73854 drm/i915: Bump pin_count to UINT_MAX.
efefadf drm/i915: Wait for flips to complete before returning.

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

Re: [Intel-gfx] Building GVT-g as a sub-module of i915

[Wang, Zhi A]

Thanks Daniel and Joonas. : p See my replies below.

> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, May 23, 2016 5:18 PM
> To: Joonas Lahtinen 
> Cc: Wang, Zhi A ; Vetter, Daniel
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] Building GVT-g as a sub-module of i915
> 
> On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen
>  wrote:
> > On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
> >> Hi Guys:
> >>   I'm trying to make GVT-g as a sub-module of i915 in the next
> >> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
> >> state" in i915. I think it should be a kernel option.
> >>
> >
> > Could not the GGTT partitioning be done ad hoc by moving objects out
> > of the memory areas to be ballooned? This way gvt module could just be
> > loaded and it would work, instead of having to reboot and change
> > kernel parameters.
> 
> Yeah, if we want to make gvt loadable, then it should indeed not reserve
> anything if it's not loaded. Otherwise there's no point in that option, and 
> it's no
> better than just a static Kconfig+ maybe i915 module option.
> 
> If dynamic loading is too hard for v1, then I'd say we should postpone it to
> post-merging. GVT-g is already tricky to integrate as-is.
> 

Yes. We can try to reserve some portion of GGTT by allocating 2 gem object and 
pin them into mappable / high GGTT memory.

I think better we can postpone it to post-merging. For now statically partition 
only requires little changes. :)

> >> When this kernel option is enabled by user, i915 will do GGTT
> >> partition and save HW initial MMIO snapshot for gvt-g module during
> >> loading.
> >
> > Like discussed in the F2F, I really think taking a MMIO snapshot in
> > Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS
> > settings could very obscurely break VM booting, especially if
> > migration is at some point wanted. It will also leak the Dom0 boot
> > state to a VM, which I do not like either.
> >
> > I would be more comfortable if the VMs are booting to a driver-fixed
> > MMIO state.
> >
> > Any thoughts by others on these?
> 
> Golden MMIO state sounds like a good idea.

Yes. It's a good idea. I agree with that. But consider that each GT 
stepping/generation might need a dedicated MMIO snapshot. They could become 
huge, probably at the very beginning 2MB is OK, in future we should get them 
out of kernel.

BTW: It's not only MMIO bar needs a snapshot, PCI configuration space also 
needs a golden snapshot. :) So consider the GT/SKUs we have, maybe we should 
figure out a way to store them at first. :)

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Enable GSE interrupt on BDW+

[Mark Kettenis]

> From: Jani Nikula 
> Date: Mon, 23 May 2016 17:04:48 +0300
> 
> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > We've never actually enabled or unmasked the GSE interrupt on BDW+,
> > even though the interrupt handler was always prepared for it.
> > Let's enable it and see what happens.
> >
> > Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
> > driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
> > brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
> > Carbon" for them.
> >
> > Reviewed-by: Daniel Vetter 
> > References: 
> > http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
> > Reported-by: Mark Kettenis 
> > Cc: Mark Kettenis 
> > Cc: Jani Nikula 
> > Signed-off-by: Ville Syrjälä 
> > ---
> > Nothing changed, just reposted for CI.
> 
> As I noted previously, I don't think we need this, but if you insist on
> having it, please add a note about it in the commit message. With that,

FWIW, this *is* needed if you want ACPI-based backlight control to
work.  On Linux you probably don't notice, since "hardware" backlight
control is preferred over "firmware" or "platform" backlight control.

It would help me if this did land in the Linux tree though, as it will
make future imports of the i915 driver into OpenBSD easier.

> >  drivers/gpu/drm/i915/i915_irq.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index f0d941455bed..4c271ea267bb 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3799,6 +3799,7 @@ static void gen8_de_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> > uint32_t de_pipe_enables;
> > u32 de_port_masked = GEN8_AUX_CHANNEL_A;
> > u32 de_port_enables;
> > +   u32 de_misc_masked = GEN8_DE_MISC_GSE;
> > enum pipe pipe;
> >  
> > if (INTEL_INFO(dev_priv)->gen >= 9) {
> > @@ -3834,6 +3835,7 @@ static void gen8_de_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> >   de_pipe_enables);
> >  
> > GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
> > +   GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
> >  }
> >  
> >  static int gen8_irq_postinstall(struct drm_device *dev)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Enable GSE interrupt on BDW+

[Jani Nikula]

On Mon, 23 May 2016, Mark Kettenis  wrote:
>> From: Jani Nikula 
>> Date: Mon, 23 May 2016 17:04:48 +0300
>> 
>> On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä 
>> >
>> > We've never actually enabled or unmasked the GSE interrupt on BDW+,
>> > even though the interrupt handler was always prepared for it.
>> > Let's enable it and see what happens.
>> >
>> > Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
>> > driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
>> > brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
>> > Carbon" for them.
>> >
>> > Reviewed-by: Daniel Vetter 
>> > References: 
>> > http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
>> > Reported-by: Mark Kettenis 
>> > Cc: Mark Kettenis 
>> > Cc: Jani Nikula 
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> > Nothing changed, just reposted for CI.
>> 
>> As I noted previously, I don't think we need this, but if you insist on
>> having it, please add a note about it in the commit message. With that,
>
> FWIW, this *is* needed if you want ACPI-based backlight control to
> work.  On Linux you probably don't notice, since "hardware" backlight
> control is preferred over "firmware" or "platform" backlight control.
>
> It would help me if this did land in the Linux tree though, as it will
> make future imports of the i915 driver into OpenBSD easier.

Ville, there's your copy-paste for the logs. ;)

BR,
Jani.


>
>> >  drivers/gpu/drm/i915/i915_irq.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index f0d941455bed..4c271ea267bb 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -3799,6 +3799,7 @@ static void gen8_de_irq_postinstall(struct 
>> > drm_i915_private *dev_priv)
>> >uint32_t de_pipe_enables;
>> >u32 de_port_masked = GEN8_AUX_CHANNEL_A;
>> >u32 de_port_enables;
>> > +  u32 de_misc_masked = GEN8_DE_MISC_GSE;
>> >enum pipe pipe;
>> >  
>> >if (INTEL_INFO(dev_priv)->gen >= 9) {
>> > @@ -3834,6 +3835,7 @@ static void gen8_de_irq_postinstall(struct 
>> > drm_i915_private *dev_priv)
>> >  de_pipe_enables);
>> >  
>> >GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
>> > +  GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
>> >  }
>> >  
>> >  static int gen8_irq_postinstall(struct drm_device *dev)
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> 
>> 

-- 
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] [PATCH v2 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

[ville . syrjala]

From: Ville Syrjälä 

SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
that task, so let's never mask it.

v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris)

Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29bdd79d9039..96be0b6f5712 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
else
gen6_set_rps(dev_priv, dev_priv->rps.idle_freq);
dev_priv->rps.last_adj = 0;
-   I915_WRITE(GEN6_PMINTRMSK, 0x);
+   I915_WRITE(GEN6_PMINTRMSK, gen6_sanitize_rps_pm_mask(dev_priv, 
~0));
}
mutex_unlock(_priv->rps.hw_lock);
 
-- 
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/2] drm/i915/opregion: Rename init/fini functions to register/unregister

[Jani Nikula]

On Mon, 23 May 2016, Chris Wilson  wrote:
> Current intel_opregion_init is called during the driver registration
> phase and intel_opregion_fini from the unregistration phase. Rename the
> functions show that this is clear from their names. The phases tell us
> what we expect the existing hw state to be, e.g. whether interrupts are
> still enabled etc.

Okay, for the naming per se,

Reviewed-by: Jani Nikula 

While not a problem in this patch, the whole init/cleanup of opregion is
annoyingly asymmetric. You need to call both setup and init to make it
work, but fini cleans up for both of them. So repeated init/fini pairs
will fail. The setup also does some initialization that is only needed
once (like INIT_WORK) so fini is not a complete counter-operation of
setup+init either.

BR,
Jani.

>
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_dma.c   | 4 ++--
>  drivers/gpu/drm/i915/i915_drv.c   | 4 ++--
>  drivers/gpu/drm/i915/i915_drv.h   | 4 ++--
>  drivers/gpu/drm/i915/intel_opregion.c | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 363bd5884a56..07edaed9d5a2 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1376,7 +1376,7 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>  
>   if (INTEL_INFO(dev_priv)->num_pipes) {
>   /* Must be done after probing outputs */
> - intel_opregion_init(dev_priv);
> + intel_opregion_register(dev_priv);
>   acpi_video_register();
>   }
>  
> @@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct 
> drm_i915_private *dev_priv)
>   i915_audio_component_cleanup(dev_priv);
>   intel_gpu_ips_teardown();
>   acpi_video_unregister();
> - intel_opregion_fini(dev_priv);
> + intel_opregion_unregister(dev_priv);
>   i915_teardown_sysfs(dev_priv->dev);
>   i915_gem_shrinker_cleanup(dev_priv);
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7627bbec8e37..943d7b222fd4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -631,7 +631,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>   intel_opregion_notify_adapter(dev_priv, opregion_target_state);
>  
>   intel_uncore_forcewake_reset(dev_priv, false);
> - intel_opregion_fini(dev_priv);
> + intel_opregion_unregister(dev_priv);
>  
>   intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
>  
> @@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
>   /* Config may have changed between suspend and resume */
>   drm_helper_hpd_irq_event(dev);
>  
> - intel_opregion_init(dev_priv);
> + intel_opregion_register(dev_priv);
>  
>   intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index caf7e45ae663..17fe272e9ef8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3609,8 +3609,8 @@ bool intel_bios_is_port_hpd_inverted(struct 
> drm_i915_private *dev_priv,
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
>  extern int intel_opregion_setup(struct drm_i915_private *dev_priv);
> -extern void intel_opregion_init(struct drm_i915_private *dev_priv);
> -extern void intel_opregion_fini(struct drm_i915_private *dev_priv);
> +extern void intel_opregion_register(struct drm_i915_private *dev_priv);
> +extern void intel_opregion_unregister(struct drm_i915_private *dev_priv);
>  extern void intel_opregion_asle_intr(struct drm_i915_private *dev_priv);
>  extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
>bool enable);
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index f9cdec866e49..f6d8a21d2c49 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -778,7 +778,7 @@ static void intel_setup_cadls(struct drm_i915_private 
> *dev_priv)
>   } while (++i < 8 && disp_id != 0);
>  }
>  
> -void intel_opregion_init(struct drm_i915_private *dev_priv)
> +void intel_opregion_register(struct drm_i915_private *dev_priv)
>  {
>   struct intel_opregion *opregion = _priv->opregion;
>  
> @@ -805,7 +805,7 @@ void intel_opregion_init(struct drm_i915_private 
> *dev_priv)
>   }
>  }
>  
> -void intel_opregion_fini(struct drm_i915_private *dev_priv)
> +void intel_opregion_unregister(struct drm_i915_private *dev_priv)
>  {
>   struct intel_opregion *opregion = _priv->opregion;

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 1/2] drm/i915/opregion: Convert to using native drm_i915_private

[Jani Nikula]

On Mon, 23 May 2016, Chris Wilson  wrote:
> Prefer passing struct drm_i915_private to internal interfaces as this
> saves us having to dance between drm_device and our native struct. The
> savings hare are small (only 70 bytes of unrequired dancing), but
> progressive!
>
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 

Hmm, I've written this patch! But alas I've never actually sent it to
the list. I guess it conflicted with some of the didl stuff I was
playing with at the time.

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/i915_dma.c   |   6 +-
>  drivers/gpu/drm/i915/i915_drv.c   |  18 +++---
>  drivers/gpu/drm/i915/i915_drv.h   |  20 +++
>  drivers/gpu/drm/i915/intel_bios.c |   2 +-
>  drivers/gpu/drm/i915/intel_opregion.c | 105 
> +-
>  5 files changed, 74 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 31e859bc74b1..363bd5884a56 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1307,7 +1307,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
> *dev_priv)
>  
>   intel_uncore_sanitize(dev_priv);
>  
> - intel_opregion_setup(dev);
> + intel_opregion_setup(dev_priv);
>  
>   i915_gem_load_init_fences(dev_priv);
>  
> @@ -1376,7 +1376,7 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>  
>   if (INTEL_INFO(dev_priv)->num_pipes) {
>   /* Must be done after probing outputs */
> - intel_opregion_init(dev);
> + intel_opregion_init(dev_priv);
>   acpi_video_register();
>   }
>  
> @@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct 
> drm_i915_private *dev_priv)
>   i915_audio_component_cleanup(dev_priv);
>   intel_gpu_ips_teardown();
>   acpi_video_unregister();
> - intel_opregion_fini(dev_priv->dev);
> + intel_opregion_fini(dev_priv);
>   i915_teardown_sysfs(dev_priv->dev);
>   i915_gem_shrinker_cleanup(dev_priv);
>  }
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index dba03c026151..7627bbec8e37 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -628,10 +628,10 @@ static int i915_drm_suspend(struct drm_device *dev)
>   i915_save_state(dev);
>  
>   opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
> - intel_opregion_notify_adapter(dev, opregion_target_state);
> + intel_opregion_notify_adapter(dev_priv, opregion_target_state);
>  
>   intel_uncore_forcewake_reset(dev_priv, false);
> - intel_opregion_fini(dev);
> + intel_opregion_fini(dev_priv);
>  
>   intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
>  
> @@ -749,7 +749,7 @@ static int i915_drm_resume(struct drm_device *dev)
>   mutex_unlock(>struct_mutex);
>  
>   i915_restore_state(dev);
> - intel_opregion_setup(dev);
> + intel_opregion_setup(dev_priv);
>  
>   intel_init_pch_refclk(dev);
>   drm_mode_config_reset(dev);
> @@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
>   /* Config may have changed between suspend and resume */
>   drm_helper_hpd_irq_event(dev);
>  
> - intel_opregion_init(dev);
> + intel_opregion_init(dev_priv);
>  
>   intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
>  
> @@ -802,7 +802,7 @@ static int i915_drm_resume(struct drm_device *dev)
>   dev_priv->modeset_restore = MODESET_DONE;
>   mutex_unlock(_priv->modeset_restore_lock);
>  
> - intel_opregion_notify_adapter(dev, PCI_D0);
> + intel_opregion_notify_adapter(dev_priv, PCI_D0);
>  
>   drm_kms_helper_poll_enable(dev);
>  
> @@ -1596,14 +1596,14 @@ static int intel_runtime_suspend(struct device 
> *device)
>* FIXME: We really should find a document that references the arguments
>* used below!
>*/
> - if (IS_BROADWELL(dev)) {
> + if (IS_BROADWELL(dev_priv)) {
>   /*
>* On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
>* being detected, and the call we do at intel_runtime_resume()
>* won't be able to restore them. Since PCI_D3hot matches the
>* actual specification and appears to be working, use it.
>*/
> - intel_opregion_notify_adapter(dev, PCI_D3hot);
> + intel_opregion_notify_adapter(dev_priv, PCI_D3hot);
>   } else {
>   /*
>* current versions of firmware which depend on this opregion
> @@ -1612,7 +1612,7 @@ static int intel_runtime_suspend(struct device *device)
>* to distinguish it from notifications that might be sent via
>* the suspend path.
>*/
> - 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

[Ville Syrjälä]

On Mon, May 23, 2016 at 03:30:04PM +0100, Chris Wilson wrote:
> On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
> > in an infinite batch buffer loop. The GPU apparently hogs something
> > critical and CPUs start to lose interrupts and whatnot. We can keep
> > the system limping along by unmasking some interrupts in
> > GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
> > that task, so let's never mask it.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 29bdd79d9039..576e98744a2d 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
> > else
> > gen6_set_rps(dev_priv, dev_priv->rps.idle_freq);
> > dev_priv->rps.last_adj = 0;
> > -   I915_WRITE(GEN6_PMINTRMSK, 0x);
> > +   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, ~0));
> 
> gen6_sanitize_rps_pm_mask()

Doh. That's what I had on the other machine. Shouldn't copy patches
by retyping them by hand.

> 
> With that,
> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
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] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate

[Chris Wilson]

On Mon, May 23, 2016 at 05:09:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> On SNB (at least) it's dangeruopus to hang the GPU with an infinite
> batch buffer loop while RPS is disabled. The only thing that keeps
> the system going in such circumstances are the internal RPS timers,
> so we should never feed the GPU with RPS disabled unless we want to
> risk a total system hang.
> 
> Previously we didn't fully disable RPS, but that changes in
> commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> register")
> so we probably didn't see the problem so often previously. But
> even before that we were at the mercy of the BIOS for the initial
> RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
> upon boot could have been fatal.
> 
> To avoid the problems let's just make the RPS enable immediate.
> This renders the delayed_resume_work useless actually. We could perhaps
> just move the ring freq table initialization to the work and do the
> other stull synchronously?
> 
> Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> register")
> Signed-off-by: Ville Syrjälä 
> ---
> This is more and RFC at this point. Perhaps we might want to keep the delayed
> work but just for the ring freq table update (which is the main reson this 
> whole
> thing exists in the first place). Another factor is that wait_for() is not
> exactly optiomal currently, so it makes the operation slower than it needs to
> be. Would need some hard numbers to see if it's worth keeping the delayed work
> or not I suppose.

I am in favour - the entire chain should be async, not just this little
step to setup the ring freq.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset

[Chris Wilson]

On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Based on my observations GPU reset doesn't clobber the RPS state, so
> frobbing with RPS around GPU reset seems rather pointless. Just get
> rid of it.
> 
> Signed-off-by: Ville Syrjälä 

Testcase: igt/pm_rpm/reset ?

Looks like that is the desired test.

Maybe make it basic and see what CI says :)

Actually it probably should be a basic test considering how often we
hang.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,01/11] drm/i915: Rename struct intel_context (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context 
(rev2)
URL   : https://patchwork.freedesktop.org/series/7564/
State : failure

== Summary ==

Series 7564v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/2/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
fail   -> PASS   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> FAIL   (ro-snb-i7-2620M)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:196  dwarn:2   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:182  dwarn:2   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:179  dwarn:0   dfail:0   fail:2   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:180  dwarn:2   dfail:0   fail:0   skip:22 
ro-snb-i7-2620M  total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_974/

54afd5a drm-intel-nightly: 2016y-05m-23d-13h-38m-05s UTC integration manifest
0d3420b drm/i915/debugfs: Show context objects in i915_gem_objects
0f5ae8c drm/i915: Rearrange i915_gem_context
82b468f drm/i915: Merge legacy+execlists context structs
1dcca1e drm/i915: Put the kernel_context in drm_i915_private next to its friends
f225058 drm/i915: Show i915_gem_context owner in debugfs
d5050ea drm/i915: Move pinning of dev_priv->kernel_context into its creator
3e18a92 drm/i915: Name the inner most per-engine intel_context struct
ab016a4 drm/i915: Rename i915_gem_context_reference/unreference()
2358d91 drm/i915: Rename and inline i915_gem_context_get()
409ed24 drm/i915: Apply lockdep annotations to i915_gem_context.c
0616d56 drm/i915: Rename struct intel_context

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

[Chris Wilson]

On Mon, May 23, 2016 at 05:09:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
> in an infinite batch buffer loop. The GPU apparently hogs something
> critical and CPUs start to lose interrupts and whatnot. We can keep
> the system limping along by unmasking some interrupts in
> GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
> that task, so let's never mask it.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 29bdd79d9039..576e98744a2d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
>   else
>   gen6_set_rps(dev_priv, dev_priv->rps.idle_freq);
>   dev_priv->rps.last_adj = 0;
> - I915_WRITE(GEN6_PMINTRMSK, 0x);
> + I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, ~0));

gen6_sanitize_rps_pm_mask()

With that,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle

[Jani Nikula]

On Mon, 23 May 2016, Chris  wrote:
> On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
>> On Fri, 20 May 2016, Chris  wrote:
>> > I'm still seeing this periodically, previous to today it happened on
>> > April 24th. Doesn't matter what I'm doing the video will freeze however
>> > the cursor will still move. Only option is to SSH in to the system from
>> > my tablet and do a reboot.
>> >
>> > Note: This has been going on since Sept 13, 2014. There could be as
>> > little as a few hours between freezes or as much as 30 or more days. 
>> 
>> Your report is lacking in details... like which kernel you're running,
>> and have you tried a recent kernel.
>> 
>> Please file a bug at [1], and attach dmesg with drm.debug=14 on the bug.
>> 
>> BR,
>> Jani.
>> 
>> 
>> [1] 
>> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>> 
> Jani, I have previously filed a bug or added information to a bug on
> this:

How was I supposed to know...?

> [1] https://bugs.freedesktop.org/show_bug.cgi?id=75394
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=91495
>
> The kernel being run at the time of the freeze was when this post was
> made - 3.19.0-59-generic #65~14.04.1-Ubuntu SMP Tue Apr 19 18:57:09 UTC
> 2016
>
> The video froze again this morning, however the 'Hangcheck..render ring
> idle' error was not noted in my syslog. The kernel being run at the time
> this happened - 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri May 13
> 17:27:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> I've added drm.debug=14 to my grub.cfg file to get the output you asked
> for in the next freeze. Do you want me to open a new bug or add to [1]
> or [2]?

If you keep running 3.19, neither. Please grab the latest kernel, and
run that, and update your existing bug when it occurs on that one.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.

[Chris Wilson]

On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> With nonblocking unpin there can be many cursor pins before they're
> cleared by the next page flip.
> 
> Fix this by extending pin_count to the full 32-bit to prevent a
> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)

This is a hack that affects non-KMS paths. Being able to process binding
in a single operation on all architectures is something we want to
preserve.

Why is every cursor movement generating an unpin work? Should I just
start poking registers from userspace to avoid a silly kerenl?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Building GVT-g as a sub-module of i915

[Daniel Vetter]

On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen
 wrote:
> On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
>> Hi Guys:
>>   I'm trying to make GVT-g as a sub-module of i915 in the next
>> version patchset. The basic idea is to introduce a "gvt-g pre-enabled
>> state" in i915. I think it should be a kernel option.
>>
>
> Could not the GGTT partitioning be done ad hoc by moving objects out of
> the memory areas to be ballooned? This way gvt module could just be
> loaded and it would work, instead of having to reboot and change kernel
> parameters.

Yeah, if we want to make gvt loadable, then it should indeed not
reserve anything if it's not loaded. Otherwise there's no point in
that option, and it's no better than just a static Kconfig+ maybe i915
module option.

If dynamic loading is too hard for v1, then I'd say we should postpone
it to post-merging. GVT-g is already tricky to integrate as-is.

>> When this kernel option is enabled by user, i915 will do GGTT
>> partition and save HW initial MMIO snapshot for gvt-g module during
>> loading.
>
> Like discussed in the F2F, I really think taking a MMIO snapshot in
> Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS
> settings could very obscurely break VM booting, especially if migration
> is at some point wanted. It will also leak the Dom0 boot state to a VM,
> which I do not like either.
>
> I would be more comfortable if the VMs are booting to a driver-fixed
> MMIO state.
>
> Any thoughts by others on these?

Golden MMIO state sounds like a good idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset

[ville . syrjala]

From: Ville Syrjälä 

Based on my observations GPU reset doesn't clobber the RPS state, so
frobbing with RPS around GPU reset seems rather pointless. Just get
rid of it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c  | 11 ---
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 drivers/gpu/drm/i915/intel_pm.c  |  9 -
 3 files changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba03c026151..3794dc67caa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -930,8 +930,6 @@ int i915_reset(struct drm_i915_private *dev_priv)
unsigned reset_counter;
int ret;
 
-   intel_reset_gt_powersave(dev_priv);
-
mutex_lock(>struct_mutex);
 
/* Clear any previous failed attempts at recovery. Time to try again. */
@@ -994,15 +992,6 @@ int i915_reset(struct drm_i915_private *dev_priv)
 
mutex_unlock(>struct_mutex);
 
-   /*
-* rps/rc6 re-init is necessary to restore state lost after the
-* reset and the re-install of gt irqs. Skip for ironlake per
-* previous concerns that it doesn't respond well to some forms
-* of re-init after reset.
-*/
-   if (INTEL_INFO(dev)->gen > 5)
-   intel_enable_gt_powersave(dev_priv);
-
return 0;
 
 error:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0741b2d3aa65..ca3b69b61f06 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1652,7 +1652,6 @@ void intel_cleanup_gt_powersave(struct drm_i915_private 
*dev_priv);
 void intel_enable_gt_powersave(struct drm_i915_private *dev_priv);
 void intel_disable_gt_powersave(struct drm_i915_private *dev_priv);
 void intel_suspend_gt_powersave(struct drm_i915_private *dev_priv);
-void intel_reset_gt_powersave(struct drm_i915_private *dev_priv);
 void gen6_update_ring_freq(struct drm_i915_private *dev_priv);
 void gen6_rps_busy(struct drm_i915_private *dev_priv);
 void gen6_rps_reset_ei(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 576e98744a2d..817c84c22782 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6508,15 +6508,6 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
}
 }
 
-void intel_reset_gt_powersave(struct drm_i915_private *dev_priv)
-{
-   if (INTEL_INFO(dev_priv)->gen < 6)
-   return;
-
-   gen6_suspend_rps(dev_priv);
-   dev_priv->rps.enabled = false;
-}
-
 static void ibx_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-- 
2.7.4

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

Re: [Intel-gfx] Building GVT-g as a sub-module of i915

[Joonas Lahtinen]

On ma, 2016-05-23 at 07:03 +, Wang, Zhi A wrote:
> Hi Guys:
>   I'm trying to make GVT-g as a sub-module of i915 in the next
> version patchset. The basic idea is to introduce a "gvt-g pre-enabled 
> state" in i915. I think it should be a kernel option.
> 

Could not the GGTT partitioning be done ad hoc by moving objects out of
the memory areas to be ballooned? This way gvt module could just be
loaded and it would work, instead of having to reboot and change kernel
parameters.

> When this kernel option is enabled by user, i915 will do GGTT
> partition and save HW initial MMIO snapshot for gvt-g module during
> loading.

Like discussed in the F2F, I really think taking a MMIO snapshot in
Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS
settings could very obscurely break VM booting, especially if migration
is at some point wanted. It will also leak the Dom0 boot state to a VM,
which I do not like either.

I would be more comfortable if the VMs are booting to a driver-fixed
MMIO state.

Any thoughts by others on these?

Regards, Joonas

> When GVT-g modules is loaded, first it should check if the "gvt-g
> pre-eanbled state" is enabled in i915. If yes, then it will use the
> snapshot in i915 and continue to load. If no, then bail out.
> 
> Thanks,
> Zhi.-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate

[ville . syrjala]

From: Ville Syrjälä 

On SNB (at least) it's dangeruopus to hang the GPU with an infinite
batch buffer loop while RPS is disabled. The only thing that keeps
the system going in such circumstances are the internal RPS timers,
so we should never feed the GPU with RPS disabled unless we want to
risk a total system hang.

Previously we didn't fully disable RPS, but that changes in
commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
register")
so we probably didn't see the problem so often previously. But
even before that we were at the mercy of the BIOS for the initial
RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
upon boot could have been fatal.

To avoid the problems let's just make the RPS enable immediate.
This renders the delayed_resume_work useless actually. We could perhaps
just move the ring freq table initialization to the work and do the
other stull synchronously?

Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
register")
Signed-off-by: Ville Syrjälä 
---
This is more and RFC at this point. Perhaps we might want to keep the delayed
work but just for the ring freq table update (which is the main reson this whole
thing exists in the first place). Another factor is that wait_for() is not
exactly optiomal currently, so it makes the operation slower than it needs to
be. Would need some hard numbers to see if it's worth keeping the delayed work
or not I suppose.

 drivers/gpu/drm/i915/intel_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 817c84c22782..e65c5c2b9b4e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6505,6 +6505,7 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
if (schedule_delayed_work(_priv->rps.delayed_resume_work,
   round_jiffies_up_relative(HZ)))
intel_runtime_pm_get_noresume(dev_priv);
+   flush_delayed_work(_priv->rps.delayed_resume_work);
}
 }
 
-- 
2.7.4

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

Re: [Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle

[Chris]

On Mon, 2016-05-23 at 11:06 +0300, Jani Nikula wrote:
> On Fri, 20 May 2016, Chris  wrote:
> > I'm still seeing this periodically, previous to today it happened on
> > April 24th. Doesn't matter what I'm doing the video will freeze however
> > the cursor will still move. Only option is to SSH in to the system from
> > my tablet and do a reboot.
> >
> > Note: This has been going on since Sept 13, 2014. There could be as
> > little as a few hours between freezes or as much as 30 or more days. 
> 
> Your report is lacking in details... like which kernel you're running,
> and have you tried a recent kernel.
> 
> Please file a bug at [1], and attach dmesg with drm.debug=14 on the bug.
> 
> BR,
> Jani.
> 
> 
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
> 
Jani, I have previously filed a bug or added information to a bug on
this:

[1] https://bugs.freedesktop.org/show_bug.cgi?id=75394
[2] https://bugs.freedesktop.org/show_bug.cgi?id=91495

The kernel being run at the time of the freeze was when this post was
made - 3.19.0-59-generic #65~14.04.1-Ubuntu SMP Tue Apr 19 18:57:09 UTC
2016

The video froze again this morning, however the 'Hangcheck..render ring
idle' error was not noted in my syslog. The kernel being run at the time
this happened - 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri May 13
17:27:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I've added drm.debug=14 to my grub.cfg file to get the output you asked
for in the next freeze. Do you want me to open a new bug or add to [1]
or [2]?


-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
08:53:52 up 25 min, 1 user, load average: 0.42, 0.35, 0.53
Ubuntu 14.04.4 LTS, kernel 3.19.0-59-generic #66~14.04.1-Ubuntu SMP Fri
May 13 17:27:10 UTC 2016

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

[Intel-gfx] [PATCH 1/3] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

[ville . syrjala]

From: Ville Syrjälä 

SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
that task, so let's never mask it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29bdd79d9039..576e98744a2d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4719,7 +4719,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
else
gen6_set_rps(dev_priv, dev_priv->rps.idle_freq);
dev_priv->rps.last_adj = 0;
-   I915_WRITE(GEN6_PMINTRMSK, 0x);
+   I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, ~0));
}
mutex_unlock(_priv->rps.hw_lock);
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/2] Revert "drm/i915: Allow nonblocking update of pageflips."

[Maarten Lankhorst]

This reverts commit d55dbd06bb5e1399aba9ab5227465339d1bbefff.

It lacks a description, removes the flip trace point,
doesn't handle -EBUSY if a flip is already queued
and needs to be redone.

Signed-off-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
---
Patch 3/2 which CI probably doesn't handle correctly,
so trybot results should be on https://patchwork.freedesktop.org/series/7570/

 drivers/gpu/drm/i915/intel_display.c | 350 ++-
 1 file changed, 266 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 21c0a2f3102b..f49ef629c4a8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -108,6 +108,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
 static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
+static void intel_begin_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
+static void intel_finish_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
 static void skl_init_scalers(struct drm_device *dev, struct intel_crtc 
*intel_crtc,
struct intel_crtc_state *crtc_state);
 static void skylake_pfit_enable(struct intel_crtc *crtc);
@@ -10984,7 +10986,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *req;
-   int i, ret;
+   int i;
 
if (!needs_modeset(_state->base) && crtc_state->update_pipe) {
work->put_power_domains =
@@ -11006,14 +11008,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
_priv->rps.mmioflips));
}
 
-   ret = drm_crtc_vblank_get(crtc);
-   I915_STATE_WARN(ret < 0, "enabling vblank failed with %i\n", ret);
-
-   if (work->num_planes &&
-   work->old_plane_state[0]->base.plane == crtc->primary)
-   intel_fbc_enable(intel_crtc, work->new_crtc_state, 
work->new_plane_state[0]);
-
-   intel_frontbuffer_flip_prepare(dev, work->fb_bits);
+   intel_frontbuffer_flip_prepare(dev, crtc_state->fb_bits);
 
intel_pipe_update_start(intel_crtc);
if (!needs_modeset(_state->base)) {
@@ -11032,15 +11027,206 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct intel_plane_state *new_plane_state = 
work->new_plane_state[i];
struct intel_plane *plane = 
to_intel_plane(new_plane_state->base.plane);
 
-   if (new_plane_state->visible)
-   plane->update_plane(>base, crtc_state, 
new_plane_state);
-   else
-   plane->disable_plane(>base, crtc);
+   plane->update_plane(>base, crtc_state, new_plane_state);
}
 
intel_pipe_update_end(intel_crtc, work);
 }
 
+static struct fence *intel_get_excl_fence(struct drm_i915_gem_object *obj)
+{
+   struct reservation_object *resv;
+
+
+   if (!obj->base.dma_buf)
+   return NULL;
+
+   resv = obj->base.dma_buf->resv;
+
+   /* For framebuffer backed by dmabuf, wait for fence */
+   while (1) {
+   struct fence *fence_excl, *ret = NULL;
+
+   rcu_read_lock();
+
+   fence_excl = rcu_dereference(resv->fence_excl);
+   if (fence_excl)
+   ret = fence_get_rcu(fence_excl);
+
+   rcu_read_unlock();
+
+   if (ret == fence_excl)
+   return ret;
+   }
+}
+
+static int intel_crtc_page_flip(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t page_flip_flags)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane_state *old_state, *new_state = NULL;
+   struct drm_crtc_state *new_crtc_state = NULL;
+   struct drm_framebuffer *old_fb = crtc->primary->state->fb;
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_plane *primary = crtc->primary;
+   struct intel_flip_work *work;
+   int ret;
+
+   old_state = crtc->primary->state;
+
+   if (!crtc->state->active)
+   return -EINVAL;
+
+   /*
+* drm_mode_page_flip_ioctl() should already catch this, but double
+* check to be safe.  In the future we may enable pageflipping from
+* a disabled primary plane.
+*/
+   if (WARN_ON(intel_fb_obj(old_fb) == NULL))
+   return -EBUSY;
+
+   /* 

[Intel-gfx] [PATCH 2/2] drm/i915/opregion: Rename init/fini functions to register/unregister

[Chris Wilson]

Current intel_opregion_init is called during the driver registration
phase and intel_opregion_fini from the unregistration phase. Rename the
functions show that this is clear from their names. The phases tell us
what we expect the existing hw state to be, e.g. whether interrupts are
still enabled etc.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_dma.c   | 4 ++--
 drivers/gpu/drm/i915/i915_drv.c   | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h   | 4 ++--
 drivers/gpu/drm/i915/intel_opregion.c | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 363bd5884a56..07edaed9d5a2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1376,7 +1376,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
 
if (INTEL_INFO(dev_priv)->num_pipes) {
/* Must be done after probing outputs */
-   intel_opregion_init(dev_priv);
+   intel_opregion_register(dev_priv);
acpi_video_register();
}
 
@@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_audio_component_cleanup(dev_priv);
intel_gpu_ips_teardown();
acpi_video_unregister();
-   intel_opregion_fini(dev_priv);
+   intel_opregion_unregister(dev_priv);
i915_teardown_sysfs(dev_priv->dev);
i915_gem_shrinker_cleanup(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7627bbec8e37..943d7b222fd4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -631,7 +631,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_opregion_notify_adapter(dev_priv, opregion_target_state);
 
intel_uncore_forcewake_reset(dev_priv, false);
-   intel_opregion_fini(dev_priv);
+   intel_opregion_unregister(dev_priv);
 
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
 
@@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
 
-   intel_opregion_init(dev_priv);
+   intel_opregion_register(dev_priv);
 
intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index caf7e45ae663..17fe272e9ef8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3609,8 +3609,8 @@ bool intel_bios_is_port_hpd_inverted(struct 
drm_i915_private *dev_priv,
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
 extern int intel_opregion_setup(struct drm_i915_private *dev_priv);
-extern void intel_opregion_init(struct drm_i915_private *dev_priv);
-extern void intel_opregion_fini(struct drm_i915_private *dev_priv);
+extern void intel_opregion_register(struct drm_i915_private *dev_priv);
+extern void intel_opregion_unregister(struct drm_i915_private *dev_priv);
 extern void intel_opregion_asle_intr(struct drm_i915_private *dev_priv);
 extern int intel_opregion_notify_encoder(struct intel_encoder *intel_encoder,
 bool enable);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index f9cdec866e49..f6d8a21d2c49 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -778,7 +778,7 @@ static void intel_setup_cadls(struct drm_i915_private 
*dev_priv)
} while (++i < 8 && disp_id != 0);
 }
 
-void intel_opregion_init(struct drm_i915_private *dev_priv)
+void intel_opregion_register(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
 
@@ -805,7 +805,7 @@ void intel_opregion_init(struct drm_i915_private *dev_priv)
}
 }
 
-void intel_opregion_fini(struct drm_i915_private *dev_priv)
+void intel_opregion_unregister(struct drm_i915_private *dev_priv)
 {
struct intel_opregion *opregion = _priv->opregion;
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/opregion: Convert to using native drm_i915_private

[Chris Wilson]

Prefer passing struct drm_i915_private to internal interfaces as this
saves us having to dance between drm_device and our native struct. The
savings hare are small (only 70 bytes of unrequired dancing), but
progressive!

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_dma.c   |   6 +-
 drivers/gpu/drm/i915/i915_drv.c   |  18 +++---
 drivers/gpu/drm/i915/i915_drv.h   |  20 +++
 drivers/gpu/drm/i915/intel_bios.c |   2 +-
 drivers/gpu/drm/i915/intel_opregion.c | 105 +-
 5 files changed, 74 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 31e859bc74b1..363bd5884a56 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1307,7 +1307,7 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
 
intel_uncore_sanitize(dev_priv);
 
-   intel_opregion_setup(dev);
+   intel_opregion_setup(dev_priv);
 
i915_gem_load_init_fences(dev_priv);
 
@@ -1376,7 +1376,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
 
if (INTEL_INFO(dev_priv)->num_pipes) {
/* Must be done after probing outputs */
-   intel_opregion_init(dev);
+   intel_opregion_init(dev_priv);
acpi_video_register();
}
 
@@ -1395,7 +1395,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_audio_component_cleanup(dev_priv);
intel_gpu_ips_teardown();
acpi_video_unregister();
-   intel_opregion_fini(dev_priv->dev);
+   intel_opregion_fini(dev_priv);
i915_teardown_sysfs(dev_priv->dev);
i915_gem_shrinker_cleanup(dev_priv);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index dba03c026151..7627bbec8e37 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -628,10 +628,10 @@ static int i915_drm_suspend(struct drm_device *dev)
i915_save_state(dev);
 
opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
-   intel_opregion_notify_adapter(dev, opregion_target_state);
+   intel_opregion_notify_adapter(dev_priv, opregion_target_state);
 
intel_uncore_forcewake_reset(dev_priv, false);
-   intel_opregion_fini(dev);
+   intel_opregion_fini(dev_priv);
 
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
 
@@ -749,7 +749,7 @@ static int i915_drm_resume(struct drm_device *dev)
mutex_unlock(>struct_mutex);
 
i915_restore_state(dev);
-   intel_opregion_setup(dev);
+   intel_opregion_setup(dev_priv);
 
intel_init_pch_refclk(dev);
drm_mode_config_reset(dev);
@@ -794,7 +794,7 @@ static int i915_drm_resume(struct drm_device *dev)
/* Config may have changed between suspend and resume */
drm_helper_hpd_irq_event(dev);
 
-   intel_opregion_init(dev);
+   intel_opregion_init(dev_priv);
 
intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
 
@@ -802,7 +802,7 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->modeset_restore = MODESET_DONE;
mutex_unlock(_priv->modeset_restore_lock);
 
-   intel_opregion_notify_adapter(dev, PCI_D0);
+   intel_opregion_notify_adapter(dev_priv, PCI_D0);
 
drm_kms_helper_poll_enable(dev);
 
@@ -1596,14 +1596,14 @@ static int intel_runtime_suspend(struct device *device)
 * FIXME: We really should find a document that references the arguments
 * used below!
 */
-   if (IS_BROADWELL(dev)) {
+   if (IS_BROADWELL(dev_priv)) {
/*
 * On Broadwell, if we use PCI_D1 the PCH DDI ports will stop
 * being detected, and the call we do at intel_runtime_resume()
 * won't be able to restore them. Since PCI_D3hot matches the
 * actual specification and appears to be working, use it.
 */
-   intel_opregion_notify_adapter(dev, PCI_D3hot);
+   intel_opregion_notify_adapter(dev_priv, PCI_D3hot);
} else {
/*
 * current versions of firmware which depend on this opregion
@@ -1612,7 +1612,7 @@ static int intel_runtime_suspend(struct device *device)
 * to distinguish it from notifications that might be sent via
 * the suspend path.
 */
-   intel_opregion_notify_adapter(dev, PCI_D1);
+   intel_opregion_notify_adapter(dev_priv, PCI_D1);
}
 
assert_forcewakes_inactive(dev_priv);
@@ -1636,7 +1636,7 @@ static int intel_runtime_resume(struct device *device)
WARN_ON_ONCE(atomic_read(_priv->pm.wakeref_count));
disable_rpm_wakeref_asserts(dev_priv);
 
-   intel_opregion_notify_adapter(dev, PCI_D0);
+

Re: [Intel-gfx] [PATCH v2] drm/i915: Enable GSE interrupt on BDW+

[Jani Nikula]

On Thu, 19 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> We've never actually enabled or unmasked the GSE interrupt on BDW+,
> even though the interrupt handler was always prepared for it.
> Let's enable it and see what happens.
>
> Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
> driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
> brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
> Carbon" for them.
>
> Reviewed-by: Daniel Vetter 
> References: 
> http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
> Reported-by: Mark Kettenis 
> Cc: Mark Kettenis 
> Cc: Jani Nikula 
> Signed-off-by: Ville Syrjälä 
> ---
> Nothing changed, just reposted for CI.

As I noted previously, I don't think we need this, but if you insist on
having it, please add a note about it in the commit message. With that,

Acked-by: Jani Nikula 

>
>  drivers/gpu/drm/i915/i915_irq.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f0d941455bed..4c271ea267bb 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3799,6 +3799,7 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   uint32_t de_pipe_enables;
>   u32 de_port_masked = GEN8_AUX_CHANNEL_A;
>   u32 de_port_enables;
> + u32 de_misc_masked = GEN8_DE_MISC_GSE;
>   enum pipe pipe;
>  
>   if (INTEL_INFO(dev_priv)->gen >= 9) {
> @@ -3834,6 +3835,7 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
> de_pipe_enables);
>  
>   GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_masked, de_port_enables);
> + GEN5_IRQ_INIT(GEN8_DE_MISC_, ~de_misc_masked, de_misc_masked);
>  }
>  
>  static int gen8_irq_postinstall(struct drm_device *dev)

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

Re: [Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects

[kbuild test robot]

Hi,

[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
config: i386-randconfig-x011-201621 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: the 
linux-review/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
 HEAD 3dfdb2b9e47b5ee4dfd9a21f80014bd9de87c4cb builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:13:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/seq_file.h:6,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
   drivers/gpu/drm/i915/i915_debugfs.c: In function 'per_file_ctx_stats':
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to 
>> incomplete type 'struct i915_gem_context'
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   ^
   include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^~~
   In file included from include/linux/seq_file.h:6:0,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
>> include/linux/bug.h:34:45: error: bit-field '' width not an 
>> integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
   ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^~~
>> drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro 
>> 'ARRAY_SIZE'
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
 ^~
   drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_dump_lrc':
   drivers/gpu/drm/i915/i915_debugfs.c:2139:6: warning: suggest explicit braces 
to avoid ambiguous 'else' [-Wparentheses]
  if (ctx != dev_priv->kernel_context)
 ^

vim +432 drivers/gpu/drm/i915/i915_debugfs.c

   426  
   427  static int per_file_ctx_stats(int id, void *ptr, void *data)
   428  {
   429  struct i915_gem_context *ctx = ptr;
   430  int n;
   431  
 > 432  for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   433  if (ctx->engine[n].state)
   434  per_file_stats(0, ctx->engine[n].state, data);
   435  if (ctx->engine[n].ringbuf)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Wait for flips to complete before returning.

[Maarten Lankhorst]

Doing a page flip right after setcrtc would fail because part of the update is 
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on 
ro-bdw-i7-5600u.

Signed-off-by: Maarten Lankhorst 
---
Oops, stripped 1/2 from subject, fixed!

 drivers/gpu/drm/i915/intel_display.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a500f08ec0ac..21c0a2f3102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc 
*intel_crtc, struct intel_flip
queue_work(dev_priv->wq, >unpin_work);
 }
 
-static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
+static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool intr)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct 
drm_crtc *crtc)
 
WARN_ON(waitqueue_active(_priv->pending_flip_queue));
 
-   ret = wait_event_interruptible_timeout(
-   dev_priv->pending_flip_queue,
-   !intel_crtc_has_pending_flip(crtc),
-   60*HZ);
+   if (intr)
+   ret = wait_event_interruptible_timeout(
+   dev_priv->pending_flip_queue,
+   
!intel_crtc_has_pending_flip(crtc),
+   60*HZ);
+   else
+   ret = wait_event_timeout(dev_priv->pending_flip_queue,
+!intel_crtc_has_pending_flip(crtc),
+60*HZ);
 
if (ret < 0)
return ret;
@@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_flip_work *work;
 
if (!state->legacy_cursor_update) {
-   ret = intel_crtc_wait_for_pending_flips(crtc);
+   ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
 
@@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
int ret = 0, i;
+   unsigned crtc_mask = 0;
 
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
@@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
 
+   crtc_mask |= drm_crtc_mask(crtc);
+
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
@@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_schedule_update(crtc, intel_state, work, nonblock);
}
 
+   if (!nonblock && !state->legacy_cursor_update) {
+   drm_for_each_crtc(crtc, dev)
+   if (crtc_mask & drm_crtc_mask(crtc))
+   intel_crtc_wait_for_pending_flips(crtc, false);
+   }
+
/* FIXME: add subpixel order */
 
drm_atomic_state_free(state);
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects

[kbuild test robot]

Hi,

[auto build test ERROR on next-20160523]
[cannot apply to drm-intel/for-linux-next v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Chris-Wilson/drm-i915-debugfs-Show-context-objects-in-i915_gem_objects/20160523-210704
 HEAD 3dfdb2b9e47b5ee4dfd9a21f80014bd9de87c4cb builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:13:0,
from arch/x86/include/asm/bug.h:35,
from include/linux/bug.h:4,
from include/linux/seq_file.h:6,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
   drivers/gpu/drm/i915/i915_debugfs.c: In function 'per_file_ctx_stats':
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to 
>> incomplete type
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   ^
   include/linux/kernel.h:54:33: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
^
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to 
>> incomplete type
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   ^
   include/linux/kernel.h:54:48: note: in definition of macro 'ARRAY_SIZE'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
   ^
   In file included from include/linux/seq_file.h:6:0,
from drivers/gpu/drm/i915/i915_debugfs.c:29:
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to 
>> incomplete type
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   ^
   include/linux/bug.h:34:55: note: in definition of macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
  ^
   include/linux/compiler-gcc.h:64:46: note: in expansion of macro '__same_type'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
 ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^
   drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro 
'ARRAY_SIZE'
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
 ^
>> drivers/gpu/drm/i915/i915_debugfs.c:432:32: error: dereferencing pointer to 
>> incomplete type
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
   ^
   include/linux/bug.h:34:55: note: in definition of macro 'BUILD_BUG_ON_ZERO'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
  ^
   include/linux/compiler-gcc.h:64:46: note: in expansion of macro '__same_type'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
 ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^
   drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro 
'ARRAY_SIZE'
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
 ^
   include/linux/bug.h:34:45: error: bit-field '' width not an 
integer constant
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
   ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
  ^
   drivers/gpu/drm/i915/i915_debugfs.c:432:18: note: in expansion of macro 
'ARRAY_SIZE'
 for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
 ^
   drivers/gpu/drm/i915/i915_debugfs.c:433:10: error: dere

[Intel-gfx] [PATCH] drm/i915: Wait for flips to complete before returning.

[Maarten Lankhorst]

Doing a page flip right after setcrtc would fail because part of the update is 
run
asynchronously. This is a regression and is caused kms_flip to fails without
the atomic page flip patch, and kms_frontbuffer_tracking to fail on 
ro-bdw-i7-5600u.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a500f08ec0ac..21c0a2f3102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc 
*intel_crtc, struct intel_flip
queue_work(dev_priv->wq, >unpin_work);
 }
 
-static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
+static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool intr)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct 
drm_crtc *crtc)
 
WARN_ON(waitqueue_active(_priv->pending_flip_queue));
 
-   ret = wait_event_interruptible_timeout(
-   dev_priv->pending_flip_queue,
-   !intel_crtc_has_pending_flip(crtc),
-   60*HZ);
+   if (intr)
+   ret = wait_event_interruptible_timeout(
+   dev_priv->pending_flip_queue,
+   
!intel_crtc_has_pending_flip(crtc),
+   60*HZ);
+   else
+   ret = wait_event_timeout(dev_priv->pending_flip_queue,
+!intel_crtc_has_pending_flip(crtc),
+60*HZ);
 
if (ret < 0)
return ret;
@@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_flip_work *work;
 
if (!state->legacy_cursor_update) {
-   ret = intel_crtc_wait_for_pending_flips(crtc);
+   ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
 
@@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
int ret = 0, i;
+   unsigned crtc_mask = 0;
 
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
@@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
 
+   crtc_mask |= drm_crtc_mask(crtc);
+
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
@@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_schedule_update(crtc, intel_state, work, nonblock);
}
 
+   if (!nonblock && !state->legacy_cursor_update) {
+   drm_for_each_crtc(crtc, dev)
+   if (crtc_mask & drm_crtc_mask(crtc))
+   intel_crtc_wait_for_pending_flips(crtc, false);
+   }
+
/* FIXME: add subpixel order */
 
drm_atomic_state_free(state);
-- 
2.5.5

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

[Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.

[Maarten Lankhorst]

With nonblocking unpin there can be many cursor pins before they're
cleared by the next page flip.

Fix this by extending pin_count to the full 32-bit to prevent a
WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)

Cc: Ville Syrjälä 
Reported-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
---
 drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 62be77cac5cd..1d43cc290f71 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -218,8 +218,8 @@ struct i915_vma {
 *
 * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
 * bits with absolutely no headroom. So use 4 bits. */
-   unsigned int pin_count:4;
-#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
+   unsigned int pin_count;
+#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT UINT_MAX
 };
 
 struct i915_page_dma {
-- 
2.5.5

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

[Intel-gfx] [PATCH 0/2] drm/i915: Fix warnings from atomic nonblocking unpin.

[Maarten Lankhorst]

Some small fixes to make CI more happy.

First is a fix to make all blocking calls wait for update to complete, so any 
call
done right doesn't have to block on it or return -EBUSY.

pin_count was limited to 15, so many cursor updates in a single vblank would 
cause it to reach the limit
and a warning. Bump this upwards for the time being. The proper fix is > 1 
vblank depth, or passing
vma in the plane_state.

Maarten Lankhorst (2):
  drm/i915: Wait for flips to complete before returning.
  drm/i915: Bump pin_count to UINT_MAX.

 drivers/gpu/drm/i915/i915_gem_gtt.h  |  4 ++--
 drivers/gpu/drm/i915/intel_display.c | 26 --
 2 files changed, 22 insertions(+), 8 deletions(-)

-- 
2.5.5

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Enable GuC submission (rev3)

[Tvrtko Ursulin]

On 20/05/16 12:15, Patchwork wrote:

== Series Details ==

Series: Enable GuC submission (rev3)
URL   : https://patchwork.freedesktop.org/series/7153/
State : failure

== Summary ==

Series 7153v3 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/3/mbox

Test drv_module_reload_basic:
 dmesg-warn -> PASS   (ro-bdw-i7-5600u)
Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 pass   -> FAIL   (ro-byt-n2820)


Unrelated https://bugs.freedesktop.org/show_bug.cgi?id=94294


Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-b:
 dmesg-warn -> PASS   (ro-ivb-i7-3770)

fi-bdw-i7-5557u  total:217  pass:204  dwarn:0   dfail:0   fail:0   skip:13
fi-bsw-n3050 total:216  pass:172  dwarn:0   dfail:0   fail:2   skip:42
fi-byt-n2820 total:216  pass:173  dwarn:0   dfail:0   fail:2   skip:41
fi-hsw-i7-4770r  total:217  pass:191  dwarn:0   dfail:0   fail:0   skip:26
fi-skl-i7-6700k  total:217  pass:189  dwarn:0   dfail:0   fail:0   skip:28
ro-bdw-i5-5250u  total:217  pass:179  dwarn:0   dfail:0   fail:0   skip:38
ro-bdw-i7-5557U  total:217  pass:204  dwarn:0   dfail:0   fail:0   skip:13
ro-bdw-i7-5600u  total:217  pass:185  dwarn:0   dfail:0   fail:1   skip:31
ro-bsw-n3050 total:217  pass:172  dwarn:0   dfail:0   fail:3   skip:42
ro-byt-n2820 total:216  pass:171  dwarn:0   dfail:0   fail:4   skip:41
ro-hsw-i3-4010u  total:216  pass:191  dwarn:0   dfail:0   fail:0   skip:25
ro-hsw-i7-4770r  total:217  pass:191  dwarn:0   dfail:0   fail:0   skip:26
ro-ilk-i7-620lm  total:217  pass:148  dwarn:0   dfail:0   fail:2   skip:67
ro-ilk1-i5-650   total:212  pass:150  dwarn:0   dfail:0   fail:1   skip:61
ro-ivb-i7-3770   total:217  pass:181  dwarn:0   dfail:0   fail:0   skip:36
ro-ivb2-i7-3770  total:217  pass:185  dwarn:0   dfail:0   fail:0   skip:32
ro-skl-i7-6700hq total:212  pass:188  dwarn:0   dfail:0   fail:0   skip:24
ro-snb-i7-2620M  total:217  pass:175  dwarn:0   dfail:0   fail:1   skip:41
fi-snb-i7-2600 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_948/

9d15199 drm-intel-nightly: 2016y-05m-20d-07h-54m-59s UTC integration manifest
c1bdfec drm/i915/guc: change default to using GuC submission if possible
429ed03 drm/i915/guc: rework guc_add_workqueue_item()
7e031c7 drm/i915/guc: don't spinwait if the GuC's workqueue is full
274cb6c drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, 
submit}()
25aa845 drm/i915/guc: add enable_guc_loading parameter
b9dc454 drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
7bdfe0d drm/i915/guc: rename loader entry points


Merged up the next to last patch - so not enabling GuC by default yet. 
Thanks for pthe atches and review!


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH v6 3/7] drm/i915/guc: add enable_guc_loading parameter

[Nick Hoath]

On 20/05/2016 11:42, Tvrtko Ursulin wrote:

From: Dave Gordon 

Split the function of "enable_guc_submission" into two separate
options.  The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
  0  DISABLE  don't load/use the GuC
  1  BEST EFFORT  try to load/use the GuC, fallback if not available
  2  REQUIRE  must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.

v4:
 Changed some error-message levels, mostly ERROR->INFO, per
 review comments by Tvrtko Ursulin.

v5:
 Dropped one more error message, disabled GuC submission on
 hypothetical firmware-free devices [Tvrtko Ursulin].

v6:
 Logging tidy by Tvrtko Ursulin:
  * Do not log falling back to execlists when wedging the GPU.
  * Do not log fw load errors when load was disabled by user.
  * Pass down some error code from fw load for log message to
make more sense.

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  (v5)
Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Nick Hoath  (v6)

---
  drivers/gpu/drm/i915/i915_gem.c|   5 +-
  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
  drivers/gpu/drm/i915/i915_params.c |  14 +++-
  drivers/gpu/drm/i915/i915_params.h |   3 +-
  drivers/gpu/drm/i915/intel_guc_loader.c| 123 +
  5 files changed, 89 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 88dce5482f2f..1a3a07eca0d0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4868,11 +4868,8 @@ i915_gem_init_hw(struct drm_device *dev)
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC(dev)) {
ret = intel_guc_setup(dev);
-   if (ret) {
-   DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
-   ret = -EIO;
+   if (ret)
goto out;
-   }
}

/*
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a8adff..916cd6778cf3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];

-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];

-   if (!i915.enable_guc_submission)
+   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index cd74fb8e9387..21a323c01cdb 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,7 +53,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_submission = false,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -193,8 +194,15 @@ MODULE_PARM_DESC(edp_vswing,
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");

-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission 
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+   "Enable GuC firmware loading "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC submission "
+   "(-1=auto, 0=never [default], 1=if available, 2=required)");

  

[Intel-gfx] [PATCH v3] drm/i915/debugfs: Show context objects in i915_gem_objects

[Chris Wilson]

One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.

v2: Take filelist_mutex which requires a little dance with struct_mutex
to avoid nesting filelist_mutex inside struct_mutex.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..1300bad67f5c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,42 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
 }
 
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+   struct i915_gem_context *ctx = ptr;
+   int n;
+
+   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+   if (ctx->engine[n].state)
+   per_file_stats(0, ctx->engine[n].state, data);
+   if (ctx->engine[n].ringbuf)
+   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   }
+
+   return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
+{
+   struct file_stats stats;
+   struct drm_file *file;
+
+   memset(, 0, sizeof(stats));
+
+   mutex_lock(_priv->dev->struct_mutex);
+   if (dev_priv->kernel_context)
+   per_file_ctx_stats(0, dev_priv->kernel_context, );
+
+   list_for_each_entry(file, _priv->dev->filelist, lhead) {
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   idr_for_each(>context_idr, per_file_ctx_stats, );
+   }
+   mutex_unlock(_priv->dev->struct_mutex);
+
+   print_file_stats(m, "[k]contexts", stats);
+}
+
 #define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,10 +557,10 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)
 
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
-
mutex_unlock(>struct_mutex);
 
mutex_lock(>filelist_mutex);
+   print_context_stats(m, dev_priv);
list_for_each_entry_reverse(file, >filelist, lhead) {
struct file_stats stats;
struct task_struct *task;
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 i-g-t] tests/kms_flip: Check crcs during basic flip test

[ville . syrjala]

From: Ville Syrjälä 

Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.

v2: Just igt_warn() instead of igt_require() for unique crc check (Daniel)

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 132 ---
 1 file changed, 97 insertions(+), 35 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6ec97d0a8534..54e47e4b7b29 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
 #define TEST_BO_TOOBIG (1 << 28)
 #define TEST_HANG_ONCE (1 << 29)
 #define TEST_BASIC (1 << 30)
+#define TEST_CRC   (1U << 31)
 
 #define EVENT_FLIP (1 << 0)
 #define EVENT_VBLANK   (1 << 1)
@@ -151,6 +152,8 @@ static void dump_event_state(const struct event_state *es)
  es->seq_step);
 }
 
+#define N_FRAMES 8
+
 struct test_output {
int mode_valid;
drmModeModeInfo kmode[4];
@@ -160,14 +163,16 @@ struct test_output {
uint32_t _crtc[4];
int _pipe[4];
int count; /* 1:1 mapping between crtc:connector */
-   int flags;
+   unsigned int flags;
int pipe; /* primary pipe for vblank */
unsigned int current_fb_id;
unsigned int fb_width;
unsigned int fb_height;
-   unsigned int fb_ids[3];
+   unsigned int fb_ids[N_FRAMES];
int bpp, depth;
-   struct igt_fb fb_info[3];
+   struct igt_fb fb_info[N_FRAMES];
+   igt_pipe_crc_t *pipe_crc;
+   igt_crc_t crc[N_FRAMES];
 
struct event_state flip_state;
struct event_state vblank_state;
@@ -853,7 +858,9 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_DPMS_OFF_OTHERS)
dpms_off_other_outputs(o);
 
-   if (!(o->flags & TEST_SINGLE_BUFFER))
+   if (o->flags & TEST_CRC)
+   o->current_fb_id = (o->current_fb_id + 1) % N_FRAMES;
+   else if (!(o->flags & TEST_SINGLE_BUFFER))
o->current_fb_id = !o->current_fb_id;
 
if (o->flags & TEST_WITH_DUMMY_BCS)
@@ -1134,7 +1141,7 @@ found:
drmModeFreeCrtc(config[1].crtc);
 }
 
-static void paint_flip_mode(struct igt_fb *fb, bool odd_frame)
+static void paint_flip_mode(struct igt_fb *fb, int n_phases, int phase)
 {
cairo_t *cr = igt_get_cairo_ctx(drm_fd, fb);
int width = fb->width;
@@ -1142,10 +1149,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool 
odd_frame)
 
igt_paint_test_pattern(cr, width, height);
 
-   if (odd_frame)
-   cairo_rectangle(cr, width/4, height/2, width/4, height/8);
-   else
-   cairo_rectangle(cr, width/2, height/2, width/4, height/8);
+   cairo_rectangle(cr, phase * width/n_phases, height/2, width/n_phases, 
height/8);
 
cairo_set_source_rgb(cr, 1, 1, 1);
cairo_fill(cr);
@@ -1251,6 +1255,35 @@ static unsigned event_loop(struct test_output *o, 
unsigned duration_ms)
if (o->flags & TEST_HANG_ONCE)
hang = hang_gpu(drm_fd);
 
+   if (o->pipe_crc) {
+   igt_pipe_crc_stop(o->pipe_crc);
+   igt_pipe_crc_free(o->pipe_crc);
+   o->pipe_crc = NULL;
+   }
+
+   if (o->flags & TEST_CRC) {
+   bool unique_crcs = true;
+
+   o->pipe_crc = igt_pipe_crc_new_nonblock(o->pipe, 
INTEL_PIPE_CRC_SOURCE_AUTO);
+
+   for (int i = 0; i <  N_FRAMES; i++) {
+   igt_assert_eq(set_mode(o, o->fb_ids[i], 0, 0), 0);
+   igt_pipe_crc_collect_crc(o->pipe_crc, >crc[i]);
+
+   /* We want each frame to have a unique crc */
+   for (int j = 0; j < i; j++) {
+   if (igt_crc_equal(>crc[i], >crc[j]))
+   unique_crcs = false;
+   }
+   }
+   if (!unique_crcs)
+   igt_warn("CRCs not unique, unable to detect all CRC 
mismatches\n");
+   igt_assert_eq(set_mode(o, o->fb_ids[0], 0, 0), 0);
+   o->current_fb_id = 0;
+
+   igt_pipe_crc_start(o->pipe_crc);
+   }
+
start = gettime_us();
 
while (1) {
@@ -1262,6 +1295,20 @@ static unsigned event_loop(struct test_output *o, 
unsigned duration_ms)
check_all_state(o, completed_events);
update_all_state(o, completed_events);
 
+   if (o->flags & TEST_CRC) {
+   igt_crc_t *crcs;
+   int n_crcs;
+   int prev_fb_id = (o->current_fb_id + N_FRAMES - 1) % 
N_FRAMES;
+
+   n_crcs = igt_pipe_crc_get_crcs(o->pipe_crc, 2, );
+   igt_assert_eq(n_crcs, 1);
+
+   

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects

[Chris Wilson]

On Mon, May 23, 2016 at 01:31:25PM +0100, Tvrtko Ursulin wrote:
> 
> On 23/05/16 12:34, Chris Wilson wrote:
> 
> Blah blah blah, this, for that, etc... commit message ofc. :)
> 
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Joonas Lahtinen 
> >---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 35 
> > +++
> >  1 file changed, 35 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index 30cb26fe2fa9..3d14eb3215e1 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
> > print_file_stats(m, "[k]batch pool", stats);
> >  }
> >
> >+static int per_file_ctx_stats(int id, void *ptr, void *data)
> >+{
> >+struct i915_gem_context *ctx = ptr;
> >+int n;
> >+
> >+for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
> >+if (ctx->engine[n].state)
> >+per_file_stats(0, ctx->engine[n].state, data);
> >+if (ctx->engine[n].ringbuf)
> >+per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
> >+}
> >+
> >+return 0;
> >+}
> >+
> >+static void print_context_stats(struct seq_file *m,
> >+struct drm_i915_private *dev_priv)
> >+{
> >+struct file_stats stats;
> >+struct drm_file *file;
> >+
> >+memset(, 0, sizeof(stats));
> >+
> >+if (dev_priv->kernel_context)
> >+per_file_ctx_stats(0, dev_priv->kernel_context, );
> >+
> >+list_for_each_entry(file, _priv->dev->filelist, lhead) {
> 
> Existing code which iterates this list grabs dev->filelist_mutex ?

Recent invention, curses Daniel!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects

[Tvrtko Ursulin]

On 23/05/16 12:34, Chris Wilson wrote:

Blah blah blah, this, for that, etc... commit message ofc. :)


Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
  1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14eb3215e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
  }

+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+   struct i915_gem_context *ctx = ptr;
+   int n;
+
+   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+   if (ctx->engine[n].state)
+   per_file_stats(0, ctx->engine[n].state, data);
+   if (ctx->engine[n].ringbuf)
+   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   }
+
+   return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
+{
+   struct file_stats stats;
+   struct drm_file *file;
+
+   memset(, 0, sizeof(stats));
+
+   if (dev_priv->kernel_context)
+   per_file_ctx_stats(0, dev_priv->kernel_context, );
+
+   list_for_each_entry(file, _priv->dev->filelist, lhead) {


Existing code which iterates this list grabs dev->filelist_mutex ?


+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   idr_for_each(>context_idr, per_file_ctx_stats, );
+   }
+
+   print_file_stats(m, "[k]contexts", stats);
+}
+
  #define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,6 +555,7 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)

seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
+   print_context_stats(m, dev_priv);

mutex_unlock(>struct_mutex);




Regards,

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

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator

[Tvrtko Ursulin]

On 23/05/16 13:16, Chris Wilson wrote:

On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:

@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}

+   if (ctx->legacy_hw_ctx.rcs_state) {
+   int ret;
+
+   /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev_priv), 0);
+   if (ret) {
+   DRM_ERROR("Failed to pinned default global context (error 
%d)\n",
+ ret);


idr_remove here as well? Maybe we should split out the idr context
API from the GEM context to make it explicit - create context,
export it to userspace and back?


No, this one is not in an idr as file_priv is NULL for the kernel
context.


Oh right, you can claim in the commit you fixed a bug as well then! :))

-   const bool is_global_default_ctx = file_priv == NULL;
...
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
...
-   goto err_destroy;
...
-   idr_remove(_priv->context_idr, ctx->user_handle);

Regards,

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

[Intel-gfx] [PATCH i-g-t] lib/crc: Update doc for igt_pipe_crc_get_crcs

[Daniel Vetter]

Noticed while discussing CRC tests with Ville that this was totally
wrong.

v2: Ville pointed out that it only does not block when opened using
igt_pipe_crc_new_nonblocking. Still different from
igt_pipe_crc_collect_crc, which will always block.

v3: Fix type (Ville).

Cc: Ville Syrjälä 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 lib/igt_debugfs.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index a32ed7849199..2ea12a049d3a 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -567,15 +567,19 @@ void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc)
  * @n_crcs: number of CRCs to capture
  * @out_crcs: buffer pointer for the captured CRC values
  *
- * Read @n_crcs from @pipe_crc. This function blocks until @n_crcs are
- * retrieved. @out_crcs is alloced by this function and must be released with
- * free() by the caller.
+ * Read up to @n_crcs from @pipe_crc. This function does not block, and will
+ * return early if not enough CRCs can be captured, if @pipe_crc has been
+ * opened using igt_pipe_crc_new_nonblock(). It will block until @n_crcs are
+ * retrieved if @pipe_crc has been opened using igt_pipe_crc_new(). @out_crcs 
is
+ * alloced by this function and must be released with free() by the caller.
  *
  * Callers must start and stop the capturing themselves by calling
- * igt_pipe_crc_start() and igt_pipe_crc_stop().
+ * igt_pipe_crc_start() and igt_pipe_crc_stop(). For one-shot CRC collecting
+ * look at igt_pipe_crc_collect_crc().
  *
- * Returns: The number of CRCs captured. Should be equal to @n_crcs in blocking
- * mode, but can be less (even zero) in non-blocking mode.
+ * Returns:
+ * The number of CRCs captured. Should be equal to @n_crcs in blocking mode, 
but
+ * can be less (even zero) in non-blocking mode.
  */
 int
 igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
@@ -626,13 +630,18 @@ static void crc_sanity_checks(igt_crc_t *crc)
  * @out_crc: buffer for the captured CRC values
  *
  * Read a single CRC from @pipe_crc. This function blocks until the CRC is
- * retrieved.  @out_crc must be allocated by the caller.
+ * retrieved, irrespective of whether @pipe_crc has been opened with
+ * igt_pipe_crc_new() or igt_pipe_crc_new_nonblock().  @out_crc must be
+ * allocated by the caller.
  *
  * This function takes care of the pipe_crc book-keeping, it will start/stop
  * the collection of the CRC.
  *
  * This function also calls the interactive debug with the "crc" domain, so you
  * can make use of this feature to actually see the screen that is being CRC'd.
+ *
+ * For continuous CRC collection look at igt_pipe_crc_start(),
+ * igt_pipe_crc_get_crcs() and igt_pipe_crc_stop().
  */
 void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out_crc)
 {
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs

[Tvrtko Ursulin]

On 23/05/16 12:34, Chris Wilson wrote:

Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).

v2: Mark the file_priv as closed.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
  drivers/gpu/drm/i915/i915_gem_context.c |  3 ++-
  2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae28e6e9d603..945fe4710b37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
continue;

seq_printf(m, "HW context %u ", ctx->hw_id);
+   if (IS_ERR(ctx->file_priv)) {
+   seq_puts(m, "(deleted) ");
+   } else if (ctx->file_priv) {
+   struct pid *pid = ctx->file_priv->file->pid;
+   struct task_struct *task;
+
+   task = get_pid_task(pid, PIDTYPE_PID);
+   if (task) {
+   seq_printf(m, "(%s [%d]) ",
+  task->comm, task->pid);
+   put_task_struct(task);
+   }
+   } else
+   seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
-   if (ctx == dev_priv->kernel_context)
-   seq_printf(m, "(kernel context) ");

if (i915.enable_execlists) {
seq_putc(m, '\n');
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 474174c20be2..e552c936d262 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -468,6 +468,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
  {
struct i915_gem_context *ctx = p;

+   ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
return 0;
  }
@@ -936,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
return PTR_ERR(ctx);
}

-   idr_remove(>file_priv->context_idr, ctx->user_handle);
+   idr_remove(_priv->context_idr, ctx->user_handle);
i915_gem_context_put(ctx);
mutex_unlock(>struct_mutex);




Looks OK.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator

[Chris Wilson]

On Mon, May 23, 2016 at 01:09:02PM +0100, Tvrtko Ursulin wrote:
> >@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
> > return PTR_ERR(ctx);
> > }
> >
> >+if (ctx->legacy_hw_ctx.rcs_state) {
> >+int ret;
> >+
> >+/* We may need to do things with the shrinker which
> >+ * require us to immediately switch back to the default
> >+ * context. This can cause a problem as pinning the
> >+ * default context also requires GTT space which may not
> >+ * be available. To avoid this we always pin the default
> >+ * context.
> >+ */
> >+ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
> >+get_context_alignment(dev_priv), 0);
> >+if (ret) {
> >+DRM_ERROR("Failed to pinned default global context 
> >(error %d)\n",
> >+  ret);
> 
> idr_remove here as well? Maybe we should split out the idr context
> API from the GEM context to make it explicit - create context,
> export it to userspace and back?

No, this one is not in an idr as file_priv is NULL for the kernel
context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 02/12] drm: Read DPCD receiver capability for DP to VGA converter

[Ville Syrjälä]

On Mon, May 23, 2016 at 01:50:47PM +0300, Mika Kahola wrote:
> Read from DPCD receiver capability field the max allowed
> pixel clock and bits per component for DP to VGA converter.
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/drm_dp_helper.c  | 46 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  include/drm/drm_dp_helper.h  | 21 ++
>  3 files changed, 69 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eeaf5a7..c5bec6f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -412,6 +412,52 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, 
> struct drm_dp_link *link)
>  }
>  EXPORT_SYMBOL(drm_dp_link_power_down);
>  
> +/*
> + * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
> + * DP branch devices
> + * @aux: DisplayPort AUX channel
> + * @bd: pointer to a structure containing DP branch device information
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
> +{
> + uint8_t info[4];
> + uint8_t dfp;
> + bool detailed_cap_info;
> + int err, size;
> +
> + err = drm_dp_dpcd_read(aux, DP_DOWNSTREAMPORT_PRESENT, , 
> sizeof(dfp));
> + if (err < 0)
> + return err;
> +
> + bd->present = dfp & 0x1;
> +
> + if (!bd->present)
> + return 0;
> +
> + detailed_cap_info = dfp & DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + size = detailed_cap_info ? 4 : 1;
> +
> + err = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, info, size);
> + if (err < 0)
> + return err;
> +
> + bd->type = info[0] & DP_DS_PORT_TYPE_MASK;
> + bd->hpd = info[0] & DP_DS_PORT_HPD;
> +
> + if (detailed_cap_info) {
> + if (bd->type & DP_DS_PORT_TYPE_VGA) {
> + bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
> + bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_bd);
> +
>  /**
>   * drm_dp_link_configure() - configure a DisplayPort link
>   * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0741b2d..f85914b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -886,6 +886,8 @@ struct intel_dp {
>  
>   bool train_set_valid;
>  
> + struct drm_dp_bd bd;
> +
>   /* Displayport compliance testing */
>   unsigned long compliance_test_type;
>   unsigned long compliance_test_data;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index e384c7f..d3e78a5 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -802,10 +802,31 @@ struct drm_dp_link {
>   unsigned long capabilities;
>  };
>  
> +/*
> + * DP to VGA
> + */
> +struct drm_dp_vga {
> + int dot_clk;
> + uint8_t bpc;
> +};
> +
> +/*
> + * Branch device
> + */
> +struct drm_dp_bd {
> + bool present;
> + int type;
> + bool hpd;
> + union {
> + struct drm_dp_vga vga;
> + } dfp;

I still don't see any real point in adding this thing. I'd just keep
the common dp helper style and pass the port caps to each function
that parses one thing from there. Eg.

int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
etc.

> +};
> +
>  int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
>  
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
>  void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> -- 
> 1.9.1

-- 
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 v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator

[Tvrtko Ursulin]

On 23/05/16 12:34, Chris Wilson wrote:

Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.

v2: Throw away the user_handle on failure to allocate the ppgtt.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 53 +++--
  1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a4c6377eea32..474174c20be2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
  i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
  {
-   const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
-   int ret = 0;

BUG_ON(!mutex_is_locked(>struct_mutex));

@@ -313,30 +311,15 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;

-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
-   /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
-   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-   
get_context_alignment(to_i915(dev)), 0);
-   if (ret) {
-   DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
-   goto err_destroy;
-   }
-   }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);

-   if (IS_ERR_OR_NULL(ppgtt)) {
+   if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
 PTR_ERR(ppgtt));
-   ret = PTR_ERR(ppgtt);
-   goto err_unpin;
+   idr_remove(_priv->context_idr, ctx->user_handle);
+   i915_gem_context_put(ctx);
+   return ERR_CAST(ppgtt);
}

ctx->ppgtt = ppgtt;
@@ -345,14 +328,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);

return ctx;
-
-err_unpin:
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
-   i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
-   idr_remove(_priv->context_idr, ctx->user_handle);
-   i915_gem_context_put(ctx);
-   return ERR_PTR(ret);
  }

  static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}

+   if (ctx->legacy_hw_ctx.rcs_state) {
+   int ret;
+
+   /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev_priv), 0);
+   if (ret) {
+   DRM_ERROR("Failed to pinned default global context (error 
%d)\n",
+ ret);


idr_remove here as well? Maybe we should split out the idr context API 
from the GEM context to make it explicit - create context, export it to 
userspace and back?



+   i915_gem_context_put(ctx);
+   return ret;
+   }
+   }
+
dev_priv->kernel_context = ctx;

DRM_DEBUG_DRIVER("%s context support initialized\n",



Regards,

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

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [v2,01/11] drm/i915: Rename struct intel_context

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context
URL   : https://patchwork.freedesktop.org/series/7564/
State : success

== Summary ==

Series 7564v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/1/mbox

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (ro-ivb-i7-3770)
Test kms_sink_crc_basic:
skip   -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:183  dwarn:0   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_970/

eaa075a drm-intel-nightly: 2016y-05m-23d-08h-23m-34s UTC integration manifest
86197c5 drm/i915: Show context objects in debugfs/i915_gem_objects
0b5dacb drm/i915: Rearrange i915_gem_context
039cda6 drm/i915: Merge legacy+execlists context structs
1bc5739 drm/i915: Put the kernel_context in drm_i915_private next to its friends
0db38df drm/i915: Show i915_gem_context owner in debugfs
5646bb7 drm/i915: Move pinning of dev_priv->kernel_context into its creator
a7a13c2 drm/i915: Name the inner most per-engine intel_context struct
07d2480 drm/i915: Rename i915_gem_context_reference/unreference()
0c71a3e drm/i915: Rename and inline i915_gem_context_get()
b987d04 drm/i915: Apply lockdep annotations to i915_gem_context.c
9f66eaa drm/i915: Rename struct intel_context

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests

[Ander Conselvan De Oliveira]

On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:
> This video pattern test function gets invoked through the
> compliance test handler on a HPD short pulse if the test type is
> set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> reads to read the requested test pattern, video pattern resolution,
> frame rate and bits per color value. The results of this analysis
> are handed off to userspace so that the userspace app can set the
> video pattern mode appropriately for the test result/response.
> 
> The compliance_test_active flag is set at the end of the individual
> test handling functions. This is so that the kernel-side operations
> can be completed without the risk of interruption from the userspace
> app that is polling on that flag.
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 ++-
>  drivers/gpu/drm/i915/intel_dp.c | 76
> +
>  drivers/gpu/drm/i915/intel_drv.h|  9 +
>  include/drm/drm_dp_helper.h | 14 ++-
>  4 files changed, 111 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6ee69b1..c8d0805 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4458,7 +4458,19 @@ static int i915_displayport_test_data_show(struct
> seq_file *m, void *data)
>   if (connector->status == connector_status_connected &&
>   connector->encoder != NULL) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
> - seq_printf(m, "%lx", intel_dp->compliance_test_data);
> + if (intel_dp->compliance_test_type ==
> + DP_TEST_LINK_EDID_READ)
> + seq_printf(m, "%lx",
> +    intel_dp->compliance_test_data);
> + else if (intel_dp->compliance_test_type ==
> +  DP_TEST_LINK_VIDEO_PATTERN) {
> + seq_printf(m, "hdisplay: %lu\n",
> +    intel_dp->test_data.hdisplay);
> + seq_printf(m, "vdisplay: %lu\n",
> +    intel_dp->test_data.vdisplay);
> + seq_printf(m, "bpc: %u\n",
> +    intel_dp->test_data.bpc);
> + }
>   } else
>   seq_puts(m, "0");
>   }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 456fc17..134cff8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4018,6 +4018,82 @@ static uint8_t intel_dp_autotest_link_training(struct
> intel_dp *intel_dp)
>  static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
>  {
>   uint8_t test_result = DP_TEST_NAK;
> + uint8_t test_pattern;
> + uint16_t  h_width, v_height, test_misc;
> + int status = 0;
> +
> + /* Automation support for Video Pattern Tests has a dependency
> +  * on Link training Automation support (CTS Test 4.3.1.11)
> +  * Hence it returns a TEST NAK until the Link Training automation
> +  * support is added to the kernel
> +  */
> + return test_result;

We shouldn't merge this patch until this is resolved. There's no point in adding
dead code.


> +
> + /* Read the TEST_PATTERN (DP CTS 3.1.5) */
> + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN,
> +   _pattern, 1);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read test pattern from"
> +   "refernce sink\n");
> + return 0;
> + }
> + if (test_pattern != DP_COLOR_RAMP)
> + return test_result;
> + intel_dp->test_data.video_pattern = test_pattern;
> +
> + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_H_WIDTH,
> +   _width, 2);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read H Width from"
> +   "refernce sink\n");
> + return 0;
> + }
> + intel_dp->test_data.hdisplay = (h_width & DP_TEST_MSB_MASK) >> 8 |
> + (h_width << 8);

Just use the kernel endianness helpers, i.e.:

__le16 h_width;

drm_dp_dpcd_read(..., _width, 2)
hdisplay = le16_to_cpu(h_width);

> +
> + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_V_HEIGHT,
> +   _height, 2);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read V Height from"
> +   "refernce sink\n");

reference

> + return 0;
> + }
> + intel_dp->test_data.vdisplay = (v_height & DP_TEST_MSB_MASK) >> 8 |
> + (v_height << 8);

Same here.

> +
> + 

[Intel-gfx] [PATCH i-g-t] tests/kms_flip: Check crcs during basic flip test

[ville . syrjala]

From: Ville Syrjälä 

Allocate 8 distinct looking fbs for the basic flip test, and while
flipping, check that the crc for each frame is as expected. If we
were to present the wrong framebuffer by accident, this should catch it.

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 126 +++
 1 file changed, 91 insertions(+), 35 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6ec97d0a8534..5b4e27e49838 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -75,6 +75,7 @@
 #define TEST_BO_TOOBIG (1 << 28)
 #define TEST_HANG_ONCE (1 << 29)
 #define TEST_BASIC (1 << 30)
+#define TEST_CRC   (1U << 31)
 
 #define EVENT_FLIP (1 << 0)
 #define EVENT_VBLANK   (1 << 1)
@@ -151,6 +152,8 @@ static void dump_event_state(const struct event_state *es)
  es->seq_step);
 }
 
+#define N_FRAMES 8
+
 struct test_output {
int mode_valid;
drmModeModeInfo kmode[4];
@@ -160,14 +163,16 @@ struct test_output {
uint32_t _crtc[4];
int _pipe[4];
int count; /* 1:1 mapping between crtc:connector */
-   int flags;
+   unsigned int flags;
int pipe; /* primary pipe for vblank */
unsigned int current_fb_id;
unsigned int fb_width;
unsigned int fb_height;
-   unsigned int fb_ids[3];
+   unsigned int fb_ids[N_FRAMES];
int bpp, depth;
-   struct igt_fb fb_info[3];
+   struct igt_fb fb_info[N_FRAMES];
+   igt_pipe_crc_t *pipe_crc;
+   igt_crc_t crc[N_FRAMES];
 
struct event_state flip_state;
struct event_state vblank_state;
@@ -853,7 +858,9 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_DPMS_OFF_OTHERS)
dpms_off_other_outputs(o);
 
-   if (!(o->flags & TEST_SINGLE_BUFFER))
+   if (o->flags & TEST_CRC)
+   o->current_fb_id = (o->current_fb_id + 1) % N_FRAMES;
+   else if (!(o->flags & TEST_SINGLE_BUFFER))
o->current_fb_id = !o->current_fb_id;
 
if (o->flags & TEST_WITH_DUMMY_BCS)
@@ -1134,7 +1141,7 @@ found:
drmModeFreeCrtc(config[1].crtc);
 }
 
-static void paint_flip_mode(struct igt_fb *fb, bool odd_frame)
+static void paint_flip_mode(struct igt_fb *fb, int n_phases, int phase)
 {
cairo_t *cr = igt_get_cairo_ctx(drm_fd, fb);
int width = fb->width;
@@ -1142,10 +1149,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool 
odd_frame)
 
igt_paint_test_pattern(cr, width, height);
 
-   if (odd_frame)
-   cairo_rectangle(cr, width/4, height/2, width/4, height/8);
-   else
-   cairo_rectangle(cr, width/2, height/2, width/4, height/8);
+   cairo_rectangle(cr, phase * width/n_phases, height/2, width/n_phases, 
height/8);
 
cairo_set_source_rgb(cr, 1, 1, 1);
cairo_fill(cr);
@@ -1251,6 +1255,29 @@ static unsigned event_loop(struct test_output *o, 
unsigned duration_ms)
if (o->flags & TEST_HANG_ONCE)
hang = hang_gpu(drm_fd);
 
+   if (o->pipe_crc) {
+   igt_pipe_crc_stop(o->pipe_crc);
+   igt_pipe_crc_free(o->pipe_crc);
+   o->pipe_crc = NULL;
+   }
+
+   if (o->flags & TEST_CRC) {
+   o->pipe_crc = igt_pipe_crc_new_nonblock(o->pipe, 
INTEL_PIPE_CRC_SOURCE_AUTO);
+
+   for (int i = 0; i <  N_FRAMES; i++) {
+   igt_assert_eq(set_mode(o, o->fb_ids[i], 0, 0), 0);
+   igt_pipe_crc_collect_crc(o->pipe_crc, >crc[i]);
+
+   /* We want each frame to have a unique crc */
+   for (int j = 0; j < i; j++)
+   igt_require(!igt_crc_equal(>crc[i], 
>crc[j]));
+   }
+   igt_assert_eq(set_mode(o, o->fb_ids[0], 0, 0), 0);
+   o->current_fb_id = 0;
+
+   igt_pipe_crc_start(o->pipe_crc);
+   }
+
start = gettime_us();
 
while (1) {
@@ -1262,6 +1289,20 @@ static unsigned event_loop(struct test_output *o, 
unsigned duration_ms)
check_all_state(o, completed_events);
update_all_state(o, completed_events);
 
+   if (o->flags & TEST_CRC) {
+   igt_crc_t *crcs;
+   int n_crcs;
+   int prev_fb_id = (o->current_fb_id + N_FRAMES - 1) % 
N_FRAMES;
+
+   n_crcs = igt_pipe_crc_get_crcs(o->pipe_crc, 2, );
+   igt_assert_eq(n_crcs, 1);
+
+   /* crc will be for the previous frame */
+   igt_assert_crc_equal([0], >crc[prev_fb_id]);
+   free(crcs);
+   }
+
+
if (count && (gettime_us() - start) / 1000 >= duration_ms)
break;
 
@@ -1276,6 +1317,12 @@ static 

[Intel-gfx] [PATCH v2 08/11] drm/i915: Put the kernel_context in drm_i915_private next to its friends

[Chris Wilson]

Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 3 +--
 drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb62a02f933a..47b20069851d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1760,6 +1760,7 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
 
struct pci_dev *bridge_dev;
+   struct i915_gem_context *kernel_context;
struct intel_engine_cs engine[I915_NUM_ENGINES];
struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
@@ -2013,8 +2014,6 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
 
-   struct i915_gem_context *kernel_context;
-
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c29c1d19764f..78b70526c197 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -912,11 +912,12 @@ int i915_guc_submission_enable(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx = dev_priv->kernel_context;
struct i915_guc_client *client;
 
/* client for execbuf submission */
-   client = guc_client_alloc(dev, GUC_CTX_PRIORITY_KMD_NORMAL, ctx);
+   client = guc_client_alloc(dev,
+ GUC_CTX_PRIORITY_KMD_NORMAL,
+ dev_priv->kernel_context);
if (!client) {
DRM_ERROR("Failed to create execbuf guc_client\n");
return -ENOMEM;
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 11/11] drm/i915: Show context objects in debugfs/i915_gem_objects

[Chris Wilson]

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..3d14eb3215e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
 }
 
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+   struct i915_gem_context *ctx = ptr;
+   int n;
+
+   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+   if (ctx->engine[n].state)
+   per_file_stats(0, ctx->engine[n].state, data);
+   if (ctx->engine[n].ringbuf)
+   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   }
+
+   return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
+{
+   struct file_stats stats;
+   struct drm_file *file;
+
+   memset(, 0, sizeof(stats));
+
+   if (dev_priv->kernel_context)
+   per_file_ctx_stats(0, dev_priv->kernel_context, );
+
+   list_for_each_entry(file, _priv->dev->filelist, lhead) {
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   idr_for_each(>context_idr, per_file_ctx_stats, );
+   }
+
+   print_file_stats(m, "[k]contexts", stats);
+}
+
 #define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,6 +555,7 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)
 
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
+   print_context_stats(m, dev_priv);
 
mutex_unlock(>struct_mutex);
 
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 03/11] drm/i915: Rename and inline i915_gem_context_get()

[Chris Wilson]

i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 17 +++--
 drivers/gpu/drm/i915/i915_gem_context.c| 22 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a0f5f00f552f..d162bf86db7e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3417,11 +3417,24 @@ void i915_gem_context_reset(struct drm_device *dev);
 int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
 void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
 int i915_switch_context(struct drm_i915_gem_request *req);
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
 void i915_gem_context_free(struct kref *ctx_ref);
 struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
+
+static inline struct i915_gem_context *
+i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+   struct i915_gem_context *ctx;
+
+   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
+
+   ctx = idr_find(_priv->context_idr, id);
+   if (!ctx)
+   return ERR_PTR(-ENOENT);
+
+   return ctx;
+}
+
 static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
 {
kref_get(>ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index af747f14522e..aa329175f73a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -506,20 +506,6 @@ void i915_gem_context_close(struct drm_device *dev, struct 
drm_file *file)
idr_destroy(_priv->context_idr);
 }
 
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
-{
-   struct i915_gem_context *ctx;
-
-   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
-
-   ctx = idr_find(_priv->context_idr, id);
-   if (!ctx)
-   return ERR_PTR(-ENOENT);
-
-   return ctx;
-}
-
 static inline int
 mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
 {
@@ -951,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -977,7 +963,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, 
void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -1020,7 +1006,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -1072,7 +1058,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e61b92d7b0bc..84d990331abd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1075,7 +1075,7 @@ i915_gem_validate_context(struct drm_device *dev, struct 
drm_file *file,
if (engine->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
return ERR_PTR(-EINVAL);
 
-   ctx = i915_gem_context_get(file->driver_priv, ctx_id);
+   ctx = i915_gem_context_lookup(file->driver_priv, ctx_id);
if (IS_ERR(ctx))
return ctx;
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context into its creator

[Chris Wilson]

Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.

v2: Throw away the user_handle on failure to allocate the ppgtt.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 53 +++--
 1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a4c6377eea32..474174c20be2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
 i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
 {
-   const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
-   int ret = 0;
 
BUG_ON(!mutex_is_locked(>struct_mutex));
 
@@ -313,30 +311,15 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
 
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
-   /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
-   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-   
get_context_alignment(to_i915(dev)), 0);
-   if (ret) {
-   DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
-   goto err_destroy;
-   }
-   }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
 
-   if (IS_ERR_OR_NULL(ppgtt)) {
+   if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
 PTR_ERR(ppgtt));
-   ret = PTR_ERR(ppgtt);
-   goto err_unpin;
+   idr_remove(_priv->context_idr, ctx->user_handle);
+   i915_gem_context_put(ctx);
+   return ERR_CAST(ppgtt);
}
 
ctx->ppgtt = ppgtt;
@@ -345,14 +328,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);
 
return ctx;
-
-err_unpin:
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
-   i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
-   idr_remove(_priv->context_idr, ctx->user_handle);
-   i915_gem_context_put(ctx);
-   return ERR_PTR(ret);
 }
 
 static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
 
+   if (ctx->legacy_hw_ctx.rcs_state) {
+   int ret;
+
+   /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev_priv), 0);
+   if (ret) {
+   DRM_ERROR("Failed to pinned default global context 
(error %d)\n",
+ ret);
+   i915_gem_context_put(ctx);
+   return ret;
+   }
+   }
+
dev_priv->kernel_context = ctx;
 
DRM_DEBUG_DRIVER("%s context support initialized\n",
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 05/11] drm/i915: Name the inner most per-engine intel_context struct

[Chris Wilson]

We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers, the ringbuffer etc).

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Tvrtko Ursulin 
Reviewed-by Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++---
 drivers/gpu/drm/i915/intel_lrc.c   | 90 +++---
 3 files changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ce5e92ce9652..bb62a02f933a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -869,7 +869,7 @@ struct i915_gem_context {
} legacy_hw_ctx;
 
/* Execlists */
-   struct {
+   struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
int pin_count;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a292672f36d5..c29c1d19764f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -363,7 +363,6 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
-   enum intel_engine_id id;
u32 gfx_addr;
 
memset(, 0, sizeof(desc));
@@ -373,10 +372,10 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
 
-   for_each_engine_id(engine, dev_priv, id) {
+   for_each_engine(engine, dev_priv) {
+   struct intel_context *ce = >engine[engine->id];
struct guc_execlist_context *lrc = [engine->guc_id];
struct drm_i915_gem_object *obj;
-   uint64_t ctx_desc;
 
/* TODO: We have a design issue to be solved here. Only when we
 * receive the first batch, we know which engine is used by the
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 * for now who owns a GuC client. But for future owner of GuC
 * client, need to make sure lrc is pinned prior to enter here.
 */
-   obj = ctx->engine[id].state;
-   if (!obj)
+   if (!ce->state)
break;  /* XXX: continue? */
 
-   ctx_desc = intel_lr_context_descriptor(ctx, engine);
-   lrc->context_desc = (u32)ctx_desc;
+   lrc->context_desc = lower_32_bits(ce->lrc_desc);
 
/* The state page is after PPHWSP */
-   gfx_addr = i915_gem_obj_ggtt_offset(obj);
+   gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
 
-   obj = ctx->engine[id].ringbuf->obj;
+   obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
 
lrc->ring_begin = gfx_addr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9a55478e23ac..4b7c9680b097 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -300,7 +300,7 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
  *   descriptor for a pinned context
  *
  * @ctx: Context to work on
- * @ring: Engine the descriptor will be used with
+ * @engine: Engine the descriptor will be used with
  *
  * The context descriptor encodes various attributes of a context,
  * including its GTT address and some flags. Because it's fairly
@@ -318,16 +318,17 @@ static void
 intel_lr_context_descriptor_update(struct i915_gem_context *ctx,
   struct intel_engine_cs *engine)
 {
+   struct intel_context *ce = >engine[engine->id];
u64 desc;
 
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<ctx_desc_template;   /* bits  0-11 */
-   desc |= ctx->engine[engine->id].lrc_vma->node.start +   /* bits 12-31 */
-  LRC_PPHWSP_PN * PAGE_SIZE;
+   desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
+   /* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
 
-   

[Intel-gfx] [PATCH v2 10/11] drm/i915: Rearrange i915_gem_context

[Chris Wilson]

Pack the integers and related types together inside the struct.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d7a088efc16..5dbce15e6e4c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -829,7 +829,6 @@ struct i915_ctx_hang_stats {
 /* This must match up with the value previously used for execbuf2.rsvd1. */
 #define DEFAULT_CONTEXT_HANDLE 0
 
-#define CONTEXT_NO_ZEROMAP (1<<0)
 /**
  * struct i915_gem_context - as the name implies, represents a context.
  * @ref: reference count.
@@ -851,28 +850,31 @@ struct i915_ctx_hang_stats {
  */
 struct i915_gem_context {
struct kref ref;
-   int user_handle;
-   uint8_t remap_slice;
struct drm_i915_private *i915;
-   int flags;
struct drm_i915_file_private *file_priv;
-   struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
 
+   struct i915_ctx_hang_stats hang_stats;
+
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
+   uint32_t user_handle;
+   unsigned long flags;
+#define CONTEXT_NO_ZEROMAP (1<<0)
 
struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
-   int pin_count;
struct i915_vma *lrc_vma;
-   u64 lrc_desc;
uint32_t *lrc_reg_state;
+   u64 lrc_desc;
+   int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
 
struct list_head link;
+
+   uint8_t remap_slice;
 };
 
 enum fb_op_origin {
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 02/11] drm/i915: Apply lockdep annotations to i915_gem_context.c

[Chris Wilson]

Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 16 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff35e36599de..a0f5f00f552f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3429,6 +3429,7 @@ static inline void i915_gem_context_reference(struct 
i915_gem_context *ctx)
 
 static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
 {
+   lockdep_assert_held(>i915->dev->struct_mutex);
kref_put(>ref, i915_gem_context_free);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8484da26b5d4..af747f14522e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
 {
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
 
+   lockdep_assert_held(>i915->dev->struct_mutex);
trace_i915_context_free(ctx);
 
if (i915.enable_execlists)
@@ -181,6 +182,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
struct drm_i915_gem_object *obj;
int ret;
 
+   lockdep_assert_held(>struct_mutex);
+
obj = i915_gem_object_create(dev, size);
if (IS_ERR(obj))
return obj;
@@ -368,6 +371,8 @@ void i915_gem_context_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   lockdep_assert_held(>struct_mutex);
+
if (i915.enable_execlists) {
struct i915_gem_context *ctx;
 
@@ -433,6 +438,8 @@ void i915_gem_context_lost(struct drm_i915_private 
*dev_priv)
 {
struct intel_engine_cs *engine;
 
+   lockdep_assert_held(_priv->dev->struct_mutex);
+
for_each_engine(engine, dev_priv) {
if (engine->last_context == NULL)
continue;
@@ -451,6 +458,8 @@ void i915_gem_context_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct i915_gem_context *dctx = dev_priv->kernel_context;
 
+   lockdep_assert_held(>struct_mutex);
+
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
 
@@ -491,6 +500,8 @@ void i915_gem_context_close(struct drm_device *dev, struct 
drm_file *file)
 {
struct drm_i915_file_private *file_priv = file->driver_priv;
 
+   lockdep_assert_held(>struct_mutex);
+
idr_for_each(_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(_priv->context_idr);
 }
@@ -500,6 +511,8 @@ i915_gem_context_get(struct drm_i915_file_private 
*file_priv, u32 id)
 {
struct i915_gem_context *ctx;
 
+   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
+
ctx = idr_find(_priv->context_idr, id);
if (!ctx)
return ERR_PTR(-ENOENT);
@@ -852,10 +865,9 @@ unpin_out:
 int i915_switch_context(struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = req->i915;
 
WARN_ON(i915.enable_execlists);
-   WARN_ON(!mutex_is_locked(_priv->dev->struct_mutex));
+   lockdep_assert_held(>i915->dev->struct_mutex);
 
if (engine->id != RCS ||
req->ctx->legacy_hw_ctx.rcs_state == NULL) {
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs

[Chris Wilson]

Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).

v2: Mark the file_priv as closed.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  3 ++-
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ae28e6e9d603..945fe4710b37 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
continue;
 
seq_printf(m, "HW context %u ", ctx->hw_id);
+   if (IS_ERR(ctx->file_priv)) {
+   seq_puts(m, "(deleted) ");
+   } else if (ctx->file_priv) {
+   struct pid *pid = ctx->file_priv->file->pid;
+   struct task_struct *task;
+
+   task = get_pid_task(pid, PIDTYPE_PID);
+   if (task) {
+   seq_printf(m, "(%s [%d]) ",
+  task->comm, task->pid);
+   put_task_struct(task);
+   }
+   } else
+   seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
-   if (ctx == dev_priv->kernel_context)
-   seq_printf(m, "(kernel context) ");
 
if (i915.enable_execlists) {
seq_putc(m, '\n');
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 474174c20be2..e552c936d262 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -468,6 +468,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
 {
struct i915_gem_context *ctx = p;
 
+   ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_put(ctx);
return 0;
 }
@@ -936,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
return PTR_ERR(ctx);
}
 
-   idr_remove(>file_priv->context_idr, ctx->user_handle);
+   idr_remove(_priv->context_idr, ctx->user_handle);
i915_gem_context_put(ctx);
mutex_unlock(>struct_mutex);
 
-- 
2.8.1

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

[Intel-gfx] [PATCH v2 01/11] drm/i915: Rename struct intel_context

[Chris Wilson]

Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / user facing, and so carries the higher level GEM
information. The inner struct is hw facing. Thus we want to name the
inner struct intel_context and the outer one i915_gem_context. As the
first step, we need to rename the current struct:

s/struct intel_context/struct i915_gem_context/

which fits much better with its constructors already conveying the
i915_gem_context prefix!

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 10 +++---
 drivers/gpu/drm/i915/i915_drv.h| 22 ++---
 drivers/gpu/drm/i915/i915_gem.c|  8 ++---
 drivers/gpu/drm/i915/i915_gem_context.c| 52 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++
 drivers/gpu/drm/i915/i915_sysfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_trace.h  | 12 +++
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 22 ++---
 drivers/gpu/drm/i915/intel_lrc.h   | 10 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  4 +--
 12 files changed, 84 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c6b48dbd6e2..ae28e6e9d603 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,7 +199,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
 }
 
-static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
+static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
 {
seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
@@ -2000,7 +2000,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   struct intel_context *ctx;
+   struct i915_gem_context *ctx;
enum intel_engine_id id;
int ret;
 
@@ -2046,7 +2046,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
 }
 
 static void i915_dump_lrc_obj(struct seq_file *m,
- struct intel_context *ctx,
+ struct i915_gem_context *ctx,
  struct intel_engine_cs *engine)
 {
struct page *page;
@@ -2094,7 +2094,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   struct intel_context *ctx;
+   struct i915_gem_context *ctx;
int ret;
 
if (!i915.enable_execlists) {
@@ -2274,7 +2274,7 @@ static int i915_swizzle_info(struct seq_file *m, void 
*data)
 
 static int per_file_ctx(int id, void *ptr, void *data)
 {
-   struct intel_context *ctx = ptr;
+   struct i915_gem_context *ctx = ptr;
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 255d4c3e3eea..ff35e36599de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,7 +831,7 @@ struct i915_ctx_hang_stats {
 
 #define CONTEXT_NO_ZEROMAP (1<<0)
 /**
- * struct intel_context - as the name implies, represents a context.
+ * struct i915_gem_context - as the name implies, represents a context.
  * @ref: reference count.
  * @user_handle: userspace tracking identity for this context.
  * @remap_slice: l3 row remapping information.
@@ -849,7 +849,7 @@ struct i915_ctx_hang_stats {
  * Contexts are memory images used by the hardware to store copies of their
  * internal state.
  */
-struct intel_context {
+struct i915_gem_context {
struct kref ref;
int user_handle;
uint8_t remap_slice;
@@ -1710,7 +1710,7 @@ struct i915_execbuffer_params {
uint64_tbatch_obj_vm_offset;
struct intel_engine_cs *engine;
struct drm_i915_gem_object  *batch_obj;
-   struct intel_context*ctx;
+   struct i915_gem_context*ctx;
struct drm_i915_gem_request *request;
 };
 
@@ -2013,7 +2013,7 @@ struct drm_i915_private {
void (*stop_engine)(struct 

[Intel-gfx] [PATCH v2 09/11] drm/i915: Merge legacy+execlists context structs

[Chris Wilson]

struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.

v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i915.enable_execlists provides symmetry with the
cleanup functions).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 41 +-
 drivers/gpu/drm/i915/i915_drv.h |  7 ---
 drivers/gpu/drm/i915/i915_gem_context.c | 75 +++--
 drivers/gpu/drm/i915/intel_lrc.c| 26 
 drivers/gpu/drm/i915/intel_lrc.h|  1 -
 5 files changed, 55 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 945fe4710b37..30cb26fe2fa9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,13 +199,6 @@ describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
 }
 
-static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
-{
-   seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
-   seq_putc(m, ctx->remap_slice ? 'R' : 'r');
-   seq_putc(m, ' ');
-}
-
 static int i915_gem_object_list_info(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -2001,7 +1994,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
-   enum intel_engine_id id;
int ret;
 
ret = mutex_lock_interruptible(>struct_mutex);
@@ -2009,10 +2001,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
return ret;
 
list_for_each_entry(ctx, _priv->context_list, link) {
-   if (!i915.enable_execlists &&
-   ctx->legacy_hw_ctx.rcs_state == NULL)
-   continue;
-
seq_printf(m, "HW context %u ", ctx->hw_id);
if (IS_ERR(ctx->file_priv)) {
seq_puts(m, "(deleted) ");
@@ -2029,25 +2017,18 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
} else
seq_puts(m, "(kernel) ");
 
-   describe_ctx(m, ctx);
+   seq_putc(m, ctx->remap_slice ? 'R' : 'r');
+   seq_putc(m, '\n');
 
-   if (i915.enable_execlists) {
+   for_each_engine(engine, dev_priv) {
+   struct intel_context *ce = >engine[engine->id];
+   seq_printf(m, "%s: ", engine->name);
+   seq_putc(m, ce->initialised ? 'I' : 'i');
+   if (ce->state)
+   describe_obj(m, ce->state);
+   if (ce->ringbuf)
+   describe_ctx_ringbuf(m, ce->ringbuf);
seq_putc(m, '\n');
-   for_each_engine_id(engine, dev_priv, id) {
-   struct drm_i915_gem_object *ctx_obj =
-   ctx->engine[id].state;
-   struct intel_ringbuffer *ringbuf =
-   ctx->engine[id].ringbuf;
-
-   seq_printf(m, "%s: ", engine->name);
-   if (ctx_obj)
-   describe_obj(m, ctx_obj);
-   if (ringbuf)
-   describe_ctx_ringbuf(m, ringbuf);
-   seq_putc(m, '\n');
-   }
-   } else {
-   describe_obj(m, ctx->legacy_hw_ctx.rcs_state);
}
 
seq_putc(m, '\n');
@@ -2062,10 +2043,10 @@ static void i915_dump_lrc_obj(struct seq_file *m,
  struct i915_gem_context *ctx,
  struct intel_engine_cs *engine)
 {
+   struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct page *page;
uint32_t *reg_state;
int j;
-   struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
unsigned long ggtt_offset = 0;
 
seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 47b20069851d..9d7a088efc16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -862,13 +862,6 @@ struct i915_gem_context {
/* Unique identifier 

[Intel-gfx] Context churn

[Chris Wilson]

The essence of this series is to just rename the anonymous struct inside
intel_context. But since it involves churn, I added some sweetner into
the miex (and more churn)!

[PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference() 

Long term plan is to migrate all of our reference manipulation over to
the core kref_get/kref_put idiom. Whilst I was changing contexts, adding
the churn here seemed sensible.

Wants somebody to second my crazy plan for consistent naming.

[PATCH v2 06/11] drm/i915: Move pinning of dev_priv->kernel_context

Tvrtko spotted a missed idr_remove on an error path, v2 needs an r-b.

[PATCH v2 07/11] drm/i915: Show i915_gem_context owner in debugfs

Tvrtko spotted that we never mark the file_priv as closed, brought that
earlier in the queue (to this v2).

[PATCH v2 10/11] drm/i915: Rearrange i915_gem_context

Tvrkto has r-b this, I've just managed to forget to add it.

[PATCH v2 11/11] drm/i915: Show context objects in

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

[Intel-gfx] [PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference()

[Chris Wilson]

As these are wrappers around kref_get/kref_put() it is preferable to
follow the naming convention and use the same verb get/put in our
wrapper names for manipulating a reference to the context.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h|  6 --
 drivers/gpu/drm/i915/i915_gem.c|  7 +++
 drivers/gpu/drm/i915/i915_gem_context.c| 22 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +++---
 drivers/gpu/drm/i915/intel_lrc.c   |  4 ++--
 5 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d162bf86db7e..ce5e92ce9652 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3435,12 +3435,14 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
-static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
+static inline struct i915_gem_context *
+i915_gem_context_get(struct i915_gem_context *ctx)
 {
kref_get(>ref);
+   return ctx;
 }
 
-static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
+static inline void i915_gem_context_put(struct i915_gem_context *ctx)
 {
lockdep_assert_held(>i915->dev->struct_mutex);
kref_put(>ref, i915_gem_context_free);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 728b66911840..d7ae030e5a0b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1418,7 +1418,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
   request->engine);
}
 
-   i915_gem_context_unreference(request->ctx);
+   i915_gem_context_put(request->ctx);
i915_gem_request_unreference(request);
 }
 
@@ -2775,8 +2775,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
req->i915 = dev_priv;
req->engine = engine;
req->reset_counter = reset_counter;
-   req->ctx  = ctx;
-   i915_gem_context_reference(req->ctx);
+   req->ctx = i915_gem_context_get(ctx);
 
/*
 * Reserve space in the ring buffer for all the commands required to
@@ -2798,7 +2797,7 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
return 0;
 
 err_ctx:
-   i915_gem_context_unreference(ctx);
+   i915_gem_context_put(ctx);
 err:
kmem_cache_free(dev_priv->requests, req);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index aa329175f73a..a4c6377eea32 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -290,7 +290,7 @@ __create_hw_context(struct drm_device *dev,
return ctx;
 
 err_out:
-   i915_gem_context_unreference(ctx);
+   i915_gem_context_put(ctx);
return ERR_PTR(ret);
 }
 
@@ -351,7 +351,7 @@ err_unpin:
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
 err_destroy:
idr_remove(_priv->context_idr, ctx->user_handle);
-   i915_gem_context_unreference(ctx);
+   i915_gem_context_put(ctx);
return ERR_PTR(ret);
 }
 
@@ -363,7 +363,7 @@ static void i915_gem_context_unpin(struct i915_gem_context 
*ctx,
} else {
if (engine->id == RCS && ctx->legacy_hw_ctx.rcs_state)

i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-   i915_gem_context_unreference(ctx);
+   i915_gem_context_put(ctx);
}
 }
 
@@ -463,7 +463,7 @@ void i915_gem_context_fini(struct drm_device *dev)
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
 
-   i915_gem_context_unreference(dctx);
+   i915_gem_context_put(dctx);
dev_priv->kernel_context = NULL;
 
ida_destroy(_priv->context_hw_ida);
@@ -473,7 +473,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
 {
struct i915_gem_context *ctx = p;
 
-   i915_gem_context_unreference(ctx);
+   i915_gem_context_put(ctx);
return 0;
 }
 
@@ -785,10 +785,9 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
 
/* obj is kept alive until the next request by its active ref */
i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state);
-   i915_gem_context_unreference(from);
+   i915_gem_context_put(from);
}
-   i915_gem_context_reference(to);
-   engine->last_context = to;
+   engine->last_context = i915_gem_context_get(to);
 
/* GEN8 does *not* require an explicit reload if the PDPs have been
 * setup, and we do not wish to move them.
@@ -873,10 +872,9 @@ int 

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: DP branch devices (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: DP branch devices (rev3)
URL   : https://patchwork.freedesktop.org/series/6658/
State : success

== Summary ==

Series 6658v3 drm/i915: DP branch devices
http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/3/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (ro-ivb-i7-3770)
Test kms_sink_crc_basic:
skip   -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:183  dwarn:0   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_968/

eaa075a drm-intel-nightly: 2016y-05m-23d-08h-23m-34s UTC integration manifest
337a561 drm/i915: Add DP branch device info on debugfs
25f58c3 drm/i915: Read DP branch device SW revision
5a103c3 drm/i915: Read DP branch device HW revision
127ce17 drm/i915: Read DP branch device id
7c53d0d drm/i915: Check pixel rate for DP to VGA dongle
595beaf drm: Compute max pixel rate for DP sink
27394e7 drm: Read DPCD receiver capability for DP to Wireless Converter
3042dee drm: Read DPCD receiver capability for DP++
9ffd4f3 drm: Read DPCD receiver capability for DP to HDMI converter
bdb3668 drm: Read DPCD receiver capability for DP to DVI converter
92548e2 drm: Read DPCD receiver capability for DP to VGA converter
722a92f drm: Add missing DP downstream port types

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

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct

[Chris Wilson]

On Mon, May 23, 2016 at 11:55:16AM +0100, Tvrtko Ursulin wrote:
> 
> On 23/05/16 11:17, Chris Wilson wrote:
> >On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:
> >>>@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
> >>>* for now who owns a GuC client. But for future owner of GuC
> >>>* client, need to make sure lrc is pinned prior to enter here.
> >>>*/
> >>>-  obj = ctx->engine[id].state;
> >>>-  if (!obj)
> >>>+  if (!ce->state)
> >>>   break;  /* XXX: continue? */
> >>>
> >>>-  ctx_desc = intel_lr_context_descriptor(ctx, engine);
> >>>-  lrc->context_desc = (u32)ctx_desc;
> >>>+  lrc->context_desc = lower_32_bits(ce->lrc_desc);
> >>
> >>Could have kept use of intel_lr_context_descriptor for better separation.
> >
> >I was leaning the other way, since the code doesn't want
> >intel_lr_context_descriptor() just happens to want to reuse some of the
> >bits e.g. engine->ctx_desc_template | lrca
> 
> Thats true, but it was at least using an exported function with
> documented content, rather than directly fishing out stuff from
> essentially private data elsewhere.

It's still fishing out essentially private data though :)
If engine->ctx_desc_template considers GuC for its set of flags, it is
purely by happenstance.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct

[Tvrtko Ursulin]

On 23/05/16 11:17, Chris Wilson wrote:

On Mon, May 23, 2016 at 10:26:39AM +0100, Tvrtko Ursulin wrote:

@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 * for now who owns a GuC client. But for future owner of GuC
 * client, need to make sure lrc is pinned prior to enter here.
 */
-   obj = ctx->engine[id].state;
-   if (!obj)
+   if (!ce->state)
break;  /* XXX: continue? */

-   ctx_desc = intel_lr_context_descriptor(ctx, engine);
-   lrc->context_desc = (u32)ctx_desc;
+   lrc->context_desc = lower_32_bits(ce->lrc_desc);


Could have kept use of intel_lr_context_descriptor for better separation.


I was leaning the other way, since the code doesn't want
intel_lr_context_descriptor() just happens to want to reuse some of the
bits e.g. engine->ctx_desc_template | lrca


Thats true, but it was at least using an exported function with 
documented content, rather than directly fishing out stuff from 
essentially private data elsewhere.



i.e. lrc->context_desc != ce->lrc_desc and I would prefer it to be
clarified as to exactly what the GuC expects.


Yes that would be best. Cc-ed Dave for when he is back to comment what 
does GuC really wants in there.


Regards,

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

[Intel-gfx] [PATCH v3 11/12] drm/i915: Read DP branch device SW revision

[Mika Kahola]

SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 +
 include/drm/drm_dp_helper.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12ab26b..7e50d32 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3468,6 +3468,11 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
 sizeof(intel_dp->bd.hw_rev)) == 
sizeof(intel_dp->bd.hw_rev))
DRM_DEBUG_KMS("HW revision: %.2d.%.2d\n",
  intel_dp->bd.hw_rev & 0xf, 
(intel_dp->bd.hw_rev>>4) & 0xf);
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, 
intel_dp->bd.sw_rev,
+sizeof(intel_dp->bd.sw_rev)) == 
sizeof(intel_dp->bd.sw_rev))
+   DRM_DEBUG_KMS("SW revision: %.2d.%.2d\n",
+ intel_dp->bd.sw_rev[0], 
intel_dp->bd.sw_rev[1]);
}
 }
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d0965ca..c0ca0c9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -459,6 +459,7 @@
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
 #define DP_BRANCH_HW_REV0x509
+#define DP_BRANCH_SW_REV0x50A
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -873,6 +874,7 @@ struct drm_dp_bd {
bool hpd;
uint8_t id[6];
uint8_t hw_rev;
+   uint8_t sw_rev[2];
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 07/12] drm: Compute max pixel rate for DP sink

[Mika Kahola]

For DP branch devices DPCD register may define the max supported
pixel rate for VGA dongles. This patch adds a check if DPCD register
value is less than current setting for pixel rate.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 22 ++
 include/drm/drm_dp_helper.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c91771..b222aa0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -413,6 +413,28 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
 EXPORT_SYMBOL(drm_dp_link_power_down);
 
 /*
+ * drm_dp_max_sink_dotclock() - Compute max pixel rate
+ * @dotclk: reference pixel rate
+ * @bd: pointer to a structure containing DP branch device information
+ *
+ * Returns max supported pixel rate.
+ */
+int drm_dp_max_sink_dotclock(int dotclk, struct drm_dp_bd *bd)
+{
+   int max_dotclk = dotclk;
+
+   /* DP to VGA dongle may define max pixel rate in DPCD */
+   if (bd->present) {
+   if ((bd->type & DP_DS_PORT_TYPE_VGA) &&
+   (bd->dfp.vga.dot_clk > 0))
+   max_dotclk = min(dotclk, bd->dfp.vga.dot_clk);
+   }
+
+   return max_dotclk;
+}
+EXPORT_SYMBOL(drm_dp_max_sink_dotclock);
+
+/*
  * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
  * DP branch devices
  * @aux: DisplayPort AUX channel
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 831f944..ee4084d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -882,6 +882,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_max_sink_dotclock(int dotclk, struct drm_dp_bd *bd);
 int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 10/12] drm/i915: Read DP branch device HW revision

[Mika Kahola]

HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 +
 include/drm/drm_dp_helper.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2b768da..12ab26b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3463,6 +3463,11 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_ID, 
intel_dp->bd.id,
 sizeof(intel_dp->bd.id)) == 
sizeof(intel_dp->bd.id))
DRM_DEBUG_KMS("Device ID: %s\n", intel_dp->bd.id);
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, 
_dp->bd.hw_rev,
+sizeof(intel_dp->bd.hw_rev)) == 
sizeof(intel_dp->bd.hw_rev))
+   DRM_DEBUG_KMS("HW revision: %.2d.%.2d\n",
+ intel_dp->bd.hw_rev & 0xf, 
(intel_dp->bd.hw_rev>>4) & 0xf);
}
 }
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f1fc4e2..d0965ca 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -458,6 +458,7 @@
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
+#define DP_BRANCH_HW_REV0x509
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -871,6 +872,7 @@ struct drm_dp_bd {
int type;
bool hpd;
uint8_t id[6];
+   uint8_t hw_rev;
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 06/12] drm: Read DPCD receiver capability for DP to Wireless Converter

[Mika Kahola]

Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the

 - number of wde tx on device
 - the number of wde txs that can be concurrently active

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c |  7 +++
 include/drm/drm_dp_helper.h | 13 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f98e4be..2c91771 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -468,6 +468,13 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
bd->dfp.dual_mode.bpc = info[2] & 
DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] & 
FRAME_SEQ_TO_FRAME_PACK;
+   } else if (bd->type & DP_DS_PORT_TYPE_WIRELESS) {
+   bd->dfp.wireless.wireless_tech = info[1] & 
DP_DS_WIRELESS_TECH_MASK;
+
+   if (bd->dfp.wireless.wireless_tech == 0x0) {
+   bd->dfp.wireless.number_of_wde_tx_on_device = 
info[2] & WIRELESS_MASK;
+   bd->dfp.wireless.wde_tx_concurrency_cap = 
(info[2]>>2) & WIRELESS_MASK;
+   }
}
}
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index adf05a1..831f944 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -230,6 +230,9 @@
 # define YCBCR420_PASS_THROUGH  (1<<2)
 # define YCBCR444_TO_YCBCR422   (1<<3)
 # define YCBCR444_TO_YCBCR420   (1<<4)
+/* offset 3 for Wireless */
+# define DP_DS_WIRELESS_TECH_MASK   0xf
+# define WIRELESS_MASK  3
 
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
@@ -851,6 +854,15 @@ struct drm_dp_dual_mode {
 };
 
 /*
+ * DP to Wireless
+ */
+struct drm_dp_wireless {
+   int wireless_tech;
+   int number_of_wde_tx_on_device;
+   int wde_tx_concurrency_cap;
+};
+
+/*
  * Branch device
  */
 struct drm_dp_bd {
@@ -862,6 +874,7 @@ struct drm_dp_bd {
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
struct drm_dp_dual_mode dual_mode;
+   struct drm_dp_wireless wireless;
} dfp;
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 09/12] drm/i915: Read DP branch device id

[Mika Kahola]

Read device ID for DisplayPort branch devices. The device
ID is defined in DPCD register 0x503 and it is mandatory field
for DP branch devices.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 ++
 include/drm/drm_dp_helper.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5e16063..2b768da 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3458,6 +3458,12 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
  buf[0], buf[1], buf[2]);
+
+   if (intel_dp->bd.present) {
+   if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_ID, 
intel_dp->bd.id,
+sizeof(intel_dp->bd.id)) == 
sizeof(intel_dp->bd.id))
+   DRM_DEBUG_KMS("Device ID: %s\n", intel_dp->bd.id);
+   }
 }
 
 static bool
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ee4084d..f1fc4e2 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -457,6 +457,7 @@
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
+#define DP_BRANCH_ID0x503
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -869,6 +870,7 @@ struct drm_dp_bd {
bool present;
int type;
bool hpd;
+   uint8_t id[6];
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 04/12] drm: Read DPCD receiver capability for DP to HDMI converter

[Mika Kahola]

Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are

 - max TMDS characther clock rate
 - max bits per component
 - support for conversion from 3D frame sequential to frame pack
 - support for YCBCR422 pass through
 - support for YCBCR420 pass through
 - support for conversion from YCBCR444 to YCBCR422
 - support for conversion from YCBCR444 to YCBCR420

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c |  8 
 include/drm/drm_dp_helper.h | 19 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f5cf706..ccd0fcb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -456,6 +456,14 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
bd->dfp.dvi.hi_color_depth = info[3] & 
DP_DS_DVI_HI_COLOR_DEPTH;
+   } else if (bd->type & DP_DS_PORT_TYPE_HDMI) {
+   bd->dfp.hdmi.tmds_clk = info[1] * 2500;
+   bd->dfp.hdmi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+   bd->dfp.hdmi.frame_seq_to_frame_pack = info[3] & 
FRAME_SEQ_TO_FRAME_PACK;
+   bd->dfp.hdmi.ycbcr422_pass_through = info[3] & 
YCBCR422_PASS_THROUGH;
+   bd->dfp.hdmi.ycbcr420_pass_through = info[3] & 
YCBCR420_PASS_THROUGH;
+   bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 = 
info[3] & YCBCR444_TO_YCBCR422;
+   bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 = 
info[3] & YCBCR444_TO_YCBCR420;
}
}
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1a4e131..b8c4960 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -224,6 +224,12 @@
 /* offset 3 for DVI dual link and high color depth */
 # define DP_DS_DVI_DUAL_LINK(1<<1)
 # define DP_DS_DVI_HI_COLOR_DEPTH   (1<<2)
+/* offset 3 for HDMI */
+# define FRAME_SEQ_TO_FRAME_PACK(1<<0)
+# define YCBCR422_PASS_THROUGH  (1<<1)
+# define YCBCR420_PASS_THROUGH  (1<<2)
+# define YCBCR444_TO_YCBCR422   (1<<3)
+# define YCBCR444_TO_YCBCR420   (1<<4)
 
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
@@ -822,6 +828,18 @@ struct drm_dp_dvi {
bool dual_link;
bool hi_color_depth;
 };
+/*
+ * DP to HDMI
+ */
+struct drm_dp_hdmi {
+   int tmds_clk;
+   uint8_t bpc;
+   bool frame_seq_to_frame_pack;
+   bool ycbcr422_pass_through;
+   bool ycbcr420_pass_through;
+   bool conversion_from_ycbcr444_to_ycbcr422;
+   bool conversion_from_ycbcr444_to_ycbcr420;
+};
 
 /*
  * Branch device
@@ -833,6 +851,7 @@ struct drm_dp_bd {
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
+   struct drm_dp_hdmi hdmi;
} dfp;
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 05/12] drm: Read DPCD receiver capability for DP++

[Mika Kahola]

Read from DPCD receiver capability field for the
DP++ devices. The features are

 - max TMDS charachter clock
 - max bits per component
 - support for conversion from 3D frame sequential to
   frame pack

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c |  4 
 include/drm/drm_dp_helper.h | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ccd0fcb..f98e4be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -464,6 +464,10 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.hdmi.ycbcr420_pass_through = info[3] & 
YCBCR420_PASS_THROUGH;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 = 
info[3] & YCBCR444_TO_YCBCR422;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 = 
info[3] & YCBCR444_TO_YCBCR420;
+   } else if (bd->type & DP_DS_PORT_TYPE_DP_DUALMODE) {
+   bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
+   bd->dfp.dual_mode.bpc = info[2] & 
DP_DS_VGA_MAX_BPC_MASK;
+   bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] & 
FRAME_SEQ_TO_FRAME_PACK;
}
}
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b8c4960..adf05a1 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -842,6 +842,15 @@ struct drm_dp_hdmi {
 };
 
 /*
+ * DP to DP++
+ */
+struct drm_dp_dual_mode {
+   int tmds_clk;
+   uint8_t bpc;
+   bool frame_seq_to_frame_pack;
+};
+
+/*
  * Branch device
  */
 struct drm_dp_bd {
@@ -852,6 +861,7 @@ struct drm_dp_bd {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
+   struct drm_dp_dual_mode dual_mode;
} dfp;
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 12/12] drm/i915: Add DP branch device info on debugfs

[Mika Kahola]

Read DisplayPort branch device info from through debugfs
interface.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4c6b48d..74c6aa2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2923,6 +2923,43 @@ static void intel_dp_info(struct seq_file *m,
 
seq_printf(m, "\tDPCD rev: %x\n", intel_dp->dpcd[DP_DPCD_REV]);
seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
+   seq_printf(m, "\tbranch device: %s\n", yesno(intel_dp->bd.present));
+
+   if (intel_dp->bd.present) {
+   switch (intel_dp->bd.type) {
+   case DP_DS_PORT_TYPE_DP:
+   seq_printf(m, "\ttype: DisplayPort\n");
+   break;
+   case DP_DS_PORT_TYPE_VGA:
+   seq_printf(m, "\ttype: VGA\n");
+   break;
+   case DP_DS_PORT_TYPE_DVI:
+   seq_printf(m, "\ttype: DVI\n");
+   break;
+   case DP_DS_PORT_TYPE_HDMI:
+   seq_printf(m, "\ttype: HDMI\n");
+   break;
+   case DP_DS_PORT_TYPE_NON_EDID:
+   seq_printf(m, "\ttype: others without EDID support\n");
+   break;
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   seq_printf(m, "\ttype: DP++\n");
+   break;
+   case DP_DS_PORT_TYPE_WIRELESS:
+   seq_printf(m, "\ttype: Wireless\n");
+   break;
+   default:
+   seq_printf(m, "\ttype: N/A\n");
+   }
+
+   seq_printf(m, "\tHPD aware: %s\n", yesno(intel_dp->bd.hpd));
+   seq_printf(m, "\tDevice id: %s\n", intel_dp->bd.id);
+   seq_printf(m, "\tHW revision: %.2d.%.2d\n",
+  intel_dp->bd.hw_rev & 0xf, (intel_dp->bd.hw_rev>>4) 
& 0xf);
+   seq_printf(m, "\tSW revision: %.2d.%.2d\n",
+  intel_dp->bd.sw_rev[0], intel_dp->bd.sw_rev[1]);
+   }
+
if (intel_encoder->type == INTEL_OUTPUT_EDP)
intel_panel_info(m, _connector->panel);
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 03/12] drm: Read DPCD receiver capability for DP to DVI converter

[Mika Kahola]

Read from DPCD receiver capability field for the following
features:
 - max TMDS clock rate
 - max bits per component
 - single or dual link support
 - high color depth support

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c |  5 +
 include/drm/drm_dp_helper.h | 14 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c5bec6f..f5cf706 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -451,6 +451,11 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
if (bd->type & DP_DS_PORT_TYPE_VGA) {
bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+   } else if (bd->type & DP_DS_PORT_TYPE_DVI) {
+   bd->dfp.dvi.tmds_clk = info[1] * 2500;
+   bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+   bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
+   bd->dfp.dvi.hi_color_depth = info[3] & 
DP_DS_DVI_HI_COLOR_DEPTH;
}
}
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d3e78a5..1a4e131 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -221,6 +221,9 @@
 # define DP_DS_VGA_10BPC   1
 # define DP_DS_VGA_12BPC   2
 # define DP_DS_VGA_16BPC   3
+/* offset 3 for DVI dual link and high color depth */
+# define DP_DS_DVI_DUAL_LINK(1<<1)
+# define DP_DS_DVI_HI_COLOR_DEPTH   (1<<2)
 
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
@@ -811,6 +814,16 @@ struct drm_dp_vga {
 };
 
 /*
+ * DP to DVI
+ */
+struct drm_dp_dvi {
+   int tmds_clk;
+   uint8_t bpc;
+   bool dual_link;
+   bool hi_color_depth;
+};
+
+/*
  * Branch device
  */
 struct drm_dp_bd {
@@ -819,6 +832,7 @@ struct drm_dp_bd {
bool hpd;
union {
struct drm_dp_vga vga;
+   struct drm_dp_dvi dvi;
} dfp;
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 08/12] drm/i915: Check pixel rate for DP to VGA dongle

[Mika Kahola]

Prep work to improve DP branch device handling.

Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.

The register defines the pixel rate divided by 8 in MP/s.

v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cccf9bc..5e16063 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
+   max_dotclk = drm_dp_max_sink_dotclock(max_dotclk, _dp->bd);
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -4576,6 +4578,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
struct drm_i915_private *dev_priv = dev->dev_private;
enum intel_display_power_domain power_domain;
enum irqreturn ret = IRQ_NONE;
+   int err;
 
if (intel_dig_port->base.type != INTEL_OUTPUT_EDP &&
intel_dig_port->base.type != INTEL_OUTPUT_HDMI)
@@ -4600,6 +4603,10 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
 
+   err = drm_dp_bd(_dp->aux, _dp->bd);
+   if (err < 0)
+   DRM_DEBUG_KMS("error reading DPCD[0x80] for DP branch 
device\n");
+
if (long_hpd) {
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 02/12] drm: Read DPCD receiver capability for DP to VGA converter

[Mika Kahola]

Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c  | 46 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 include/drm/drm_dp_helper.h  | 21 ++
 3 files changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eeaf5a7..c5bec6f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -412,6 +412,52 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
 }
 EXPORT_SYMBOL(drm_dp_link_power_down);
 
+/*
+ * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
+ * DP branch devices
+ * @aux: DisplayPort AUX channel
+ * @bd: pointer to a structure containing DP branch device information
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
+{
+   uint8_t info[4];
+   uint8_t dfp;
+   bool detailed_cap_info;
+   int err, size;
+
+   err = drm_dp_dpcd_read(aux, DP_DOWNSTREAMPORT_PRESENT, , 
sizeof(dfp));
+   if (err < 0)
+   return err;
+
+   bd->present = dfp & 0x1;
+
+   if (!bd->present)
+   return 0;
+
+   detailed_cap_info = dfp & DP_DETAILED_CAP_INFO_AVAILABLE;
+
+   size = detailed_cap_info ? 4 : 1;
+
+   err = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, info, size);
+   if (err < 0)
+   return err;
+
+   bd->type = info[0] & DP_DS_PORT_TYPE_MASK;
+   bd->hpd = info[0] & DP_DS_PORT_HPD;
+
+   if (detailed_cap_info) {
+   if (bd->type & DP_DS_PORT_TYPE_VGA) {
+   bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
+   bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_bd);
+
 /**
  * drm_dp_link_configure() - configure a DisplayPort link
  * @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0741b2d..f85914b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -886,6 +886,8 @@ struct intel_dp {
 
bool train_set_valid;
 
+   struct drm_dp_bd bd;
+
/* Displayport compliance testing */
unsigned long compliance_test_type;
unsigned long compliance_test_data;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e384c7f..d3e78a5 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -802,10 +802,31 @@ struct drm_dp_link {
unsigned long capabilities;
 };
 
+/*
+ * DP to VGA
+ */
+struct drm_dp_vga {
+   int dot_clk;
+   uint8_t bpc;
+};
+
+/*
+ * Branch device
+ */
+struct drm_dp_bd {
+   bool present;
+   int type;
+   bool hpd;
+   union {
+   struct drm_dp_vga vga;
+   } dfp;
+};
+
 int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
 
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 00/12] drm/i915: DP branch devices

[Mika Kahola]

Prep work for DP branch device handling

This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards

 - DP to VGA
 - DP to DVI
 - DP to HDMI
 - DP++ dual mode
 - Wireless WiGig
 
DPCD register defines max pixel rate for VGA dongles. This
check is carried out during mode validation. 

What's new in the series:
 - Readout of branch device ID, HW, and SW revisions from DPCD register 

Acronyms:
BD Brand Device
DFPDownstream-Facing Port

v2: DPCD register read outs moved to drm (Ville, Daniel)
v3: Max pixel rate computation moved to drm (Daniel)

Mika Kahola (12):
  drm: Add missing DP downstream port types
  drm: Read DPCD receiver capability for DP to VGA converter
  drm: Read DPCD receiver capability for DP to DVI converter
  drm: Read DPCD receiver capability for DP to HDMI converter
  drm: Read DPCD receiver capability for DP++
  drm: Read DPCD receiver capability for DP to Wireless Converter
  drm: Compute max pixel rate for DP sink
  drm/i915: Check pixel rate for DP to VGA dongle
  drm/i915: Read DP branch device id
  drm/i915: Read DP branch device HW revision
  drm/i915: Read DP branch device SW revision
  drm/i915: Add DP branch device info on debugfs

 drivers/gpu/drm/drm_dp_helper.c | 92 +
 drivers/gpu/drm/i915/i915_debugfs.c | 37 +++
 drivers/gpu/drm/i915/intel_dp.c | 23 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 include/drm/drm_dp_helper.h | 86 ++
 5 files changed, 240 insertions(+)

-- 
1.9.1

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

[Intel-gfx] [PATCH v3 01/12] drm: Add missing DP downstream port types

[Mika Kahola]

Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.

Signed-off-by: Mika Kahola 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5a848e7..e384c7f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -211,6 +211,8 @@
 # define DP_DS_PORT_TYPE_DVI   2
 # define DP_DS_PORT_TYPE_HDMI  3
 # define DP_DS_PORT_TYPE_NON_EDID  4
+# define DP_DS_PORT_TYPE_DP_DUALMODE5
+# define DP_DS_PORT_TYPE_WIRELESS   6
 # define DP_DS_PORT_HPD(1 << 3)
 /* offset 1 for VGA is maximum megapixels per second / 8 */
 /* offset 2 */
-- 
1.9.1

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